Разновидность ограничений. Это не функции системы, а то, что определяет, как конкретно эти функции должны быть реализованы.
Вигерс их относит к нефункциональным требованиям, и он, в общем прав, прав.
Я думаю, что мы должны в первую очередь определиться с терминологией.
Нефункциональные требования — это требования, которые определяют не функции, а характеристики системы: ее производительность, надежность, доступность, масштабируемость и ряд других параметров (здесь перечислены характеристики качества, но, как уже сказано в статье, есть и другие виды нефункциональных требований). Требование к времени отклика вашего приложения — это тоже нефункциональное требование («производная» от производительности). Думаю, пользователям вряд ли понравится, если реакции системы они будут ждать 4 минуты после нажатия на кнопку интерфейса. Но в течение 2-3 секунд они могут подождать. Это самый простой пример.
Нефункциональные требования самым непосредственным образом определяют архитектуру разрабатываемого приложения, поэтому определять их очень важно, хотя многие предпочитают этого не делать, полагаясь на то, что hardware и технологии, с которыми они работают, уже обладает какими-то характеристиками качества — следовательно, определенное качество уже можно гарантировать. Отсутствие должного внимания, уделяемого нефункциональным требованиям, часто приводило к серьезным последствиям — от перепроектирования системы до полного провала проекта.
Что касается «основных» и «не основных» требований — приоритеты задаются для всех требований, как функциональных, так и нефункциональных. Категория требований и важность — это просто две разные вещи. Как функциональные, так и нефункциональные требования могут иметь как высокий, так и низкий приоритет.
Так зачем тогда метрики?
Хороший вопрос. Мне кажется, первая фраза уже содержит ответ на него: чтобы понимать состояние проекта.
И сотни метрик, как мне кажется, не нужны. Нужны только те метрики, которые помогут нам ответить на вопросы:
1. Сколько денег мы должны иметь в распоряжении, чтобы они не закончились в самый неожиданный момент (нижняя и верхняя граница)?
2. Сколько людей и с какой квалификацией мы должны привлекать к работам, в какие сроки?
3. Каково общее состояние проекта, сколько работы сделано, сколько еще осталось?
Ответив на эти вопросы, мы получим искомое.
В качестве «формализатора условий SLA», я имею непосредственное отношение к двум видам деятельности:
1. Локализация программного обеспечения (нет, это не просто перевод ресурсных строчек, а изменение программного продукта для его адаптации к условиям российского рынка и требованиям законодательства). Руководство этими проектами. Разные компании в разное время, в основном до 2000 года. Иных уже нет, а те далече.
2. Разработка ПО. Тоже разные компании в разное время.
В их числе — проданная какому-то системному интегратору компания, являвшаяся «собственным» отделом разработки при Sybase CIS. Здесь я выступала в роли инициатора определения SLA для нас со стороны нашего заказчика.
«Высокие технологии и стратегические системы», компания, принадлежащая АФК «Система» (входит в концерн «РТИ Системы», наряду с NVision и Sitronics — компаниями, которые разрабатывают софт для крупных операторов мобильной связи) 2011 — 2012 г. Когда мы начинали отдавать часть работ на аутсорсинг, выяснилось, что только трое человек в компании знают, что такое SLA. Поэтому писать эти условия пришлось мне (под редакцией Дмитрия Новоселова, руководителя департамента разработки — здесь до некоторых пор я многое делала под его редакцией, и это было испытание почище «Баланса Белого» с его «Яндексом»).
Дмитрий Новоселов — человек, начавший свою карьеру как системный программист, лет 7 в совокупности посвятивший роли системного архитектора, и только потом ушедший в проектный менеджмент (последние 5 лет в роли PM — в компании КРОК). Знаю я его уже около 15 лет.
Поскольку о Новоселове я могу рассказывать долго и вдохновенно, надеюсь, что это был не вполне само-пиар.
Принимать ситуацию как явление природы и пытаться в ней выжить с пользой для кошелька — на мой взгляд, достойная задача. Но тогда нужно быть готовым к тому, чтобы несколько первых итераций работы с новым заказчиком провалились. Потом уже человек с аналитическим складом ума всегда сообразит в процессе этих мук, чего от него хочет заказчик (восстановление незапротоколированных требований, классика практики любого аналитика).
Проблема только в том, что это высокорисковые проекты. И вести их на условиях fixed price — на мой взгляд, просто инвестиции в будущего клиента, которого любишь-понимаешь. Опять же, смена вкуса Ивана Никифоровича на вкус Семена Ильича (при смене менеджмента на стороне клиента) может добаить еще три неожиданных проваленных итерации. У меня лично уже не всегда хватает терпения догадываться о предъявляемых требованиях методом проб и ошибок. Мне это скучно, и я обычно первой предлагаю договориться об SLA или изменить условия контракта — пусть даже с заметной выгодой для заказчика, но с четкими условиями «если — то».
При этом, когда я выполняю менеджерские функции, я всегда помню позитивный опыт работы с Microsoft и многие вещи «из прошлой жизни» использую, так или иначе видоизменив. Обычно и те, кто работает со мной на условиях субподряда, при этом не жалуются. Криков и воплей не раздается, ни одного субподрядчика пока по моей вине не пострадало. Правда, ни одного субподрядчика, не умеющего читать (особенно условия SLA), я тоже пока вокруг себя не видела. Быть может, мне повезло.
Про распределение власти в Microsoft мне ничего не известно — я у них никогда не работала.
А про качество — немного известно (в той области, которая относится к моей сфере компетенции). Они (Microsoft), заключая контракт, всегда оговаривают детали и выставляют что-то вроде SLA, где описывают то, чего они ждут, в плане требований к качеству готового продукта.
Описывают метрики, по которым оценивают это качество, разъясняют своим субподрядчикам смысл этих метрик, а также последствия нарушения SLA. И в списке замечаний и претензий ссылаются на пункты SLA. Если ссылки на пункт SLA нет, а замечание есть (например, что-то там не понравилось Джону Смиту, но пункта SLA «результат должен нравиться Джону Смиту» в контракте нет) — оно устраняется не за счет компании-поставщика сервиса, а за счет самой компании Microsoft. Но такое на моей памяти случалось ну крайне редко — от силы раз или два.
Возможно, мне повезло: в той области, к которой принадлежу я, разработать и внедрить метрики для SLA не очень сложно. Но там, где невозможно их разработать и формализовать — работа на условиях «вы сами делаете то, что мы закажем, и если нам не понравится, вы будете все переделывать заново, пока нам не понравится — и после этого получите деньги» — это не та работа, которую стоит вообще предлагать и уж конечно не та работа, за которую стоит браться. На мой взгляд, тут обе стороны должны были искать какой-то разумный компромисс. Иначе мы получим то, что и получили: на указанных условиях за работу согласны будут взяться только очень неопытные новички, которые и результата не достигнут, и потом будут вслух обижаться.
Вы сотрудник (бывший или настоящий) компании Yandex?
Тогда ваша (как и автора статьи) точка зрения мне вполне понятна. Я же говорю — различия в менталитете. Разруха-то не в клозетах, разруха-то в головах.
Когда в прошлом еще веке (1990-е годы) одна компания, в которой я работала в то время, начала сотрудничать с Microsoft, менеджеры из Microsoft почему-то не путали таких элементарных вещей, которые почему-то путают менеджеры из Yandex. Возможно, это потому, что компания с действительно достойной подражания западной корпоративной культурой (я имею в виду, конечно, не Yandex) не допускает того, чтобы начинать провальные проекты со своими субподрядчиками — а потом еще и рассказывать, какие они, субподрядчики, мерзкие — не могут выполнить свой первый убыточный проект.
Западная корпоративная культура очень отличается от местных полукустарных поделок (пусть даже очень крупных). В том числе и менталитетом («я пригласил вас не затем, чтобы мы оба ушли разочарованные друг в друге из-за непрофессионализма нас обоих — я пригласил вас для того, чтобы мы долго и плодотворно сотрудничали»), и степенью подготовки менеджеров в вопросах, относящихся непосредственно к менеджменту.
Я чего-то здесь не понимаю. Почему компания, которую просит сделать что-либо другая компания, должна вкладываться в первый убыточный проект? Только потому, что менеджеры из Yandex, упомянутые в статье по ссылке, не понимают элементарных вещей вроде отличия проекта с контрактом на условиях Fixed Price от проекта с контрактом на условиях Time and Material — но при этом все считают, что все кругом чем-то обязаны Yandex'у, достигающему своего качества за чужой счет?
Давайте что ли устроим альтернативную тусовку — что-то вроде «арбузника» 57-й, 179-й и 91-й московских физматшкол (для тех, кто в теме).
Соберемся в лесу и устроим НЕконференцию.
«Она пояснила, что в основе выбора работы, как и в основе выбора спутника (-цы) жизни, лежит потребность в комфортных человеческих отношениях, признании и гармонии с собой...»
Большое спасибо. Одной этой аналогии вполне достаточно, чтобы воздержаться от контактов с HR-службой «Яндекса» — по крайней мере до тех пор, пока там не сменят руководителя отдела подбора персонала, наняв кого-нибудь поумнее.
Я лично раз и навсегда зареклась иметь дело с девочками из кадровой службы, которые проводят такие странные аналогии — «найти работу, как выйти замуж».
Как я уже неоднократно говорила, задача девочки из HR — мило улыбнуться, организовать собеседование с техническими специалистами. Еще раз улыбнуться, пригласить на следующее собеседование (если такое будет проводиться), затем — прислать Job Offer с четко прописанными условиями контракта или вежливо сообщить о том, что, к сожалению, предложение о работе сделать в настоящий момент не представляется возможным. Принять документы, оформить на работу, а при увольнении — выдать документы. Вести кадровое делопроизводство, проводить мониторинг рынка труда. И все. Да. это — все, чем она может помочь (именно помочь, а не навредить) коллективу.
А «психологические этюды» с людьми, у которых IQ выше 160, девочка из HR разыгрывать по определению не может. Просто потому, что до понимания логики мышления и мотивов поведения таких людей она еще немножечко не доросла. Не тот уровень.
К стресс-интервью, проводимому профессиональными психологами с многолетним опытом в бизнес-консультировании (обычно привлекаются в качестве консультантов для собеседований с людьми, претендующими на ключевые роли в серьезных IT-компаниях), тем не менее, я отношусь положительно — это бывает забавно. Среди них встречаются достойные люди, с которыми бывает приятно поговорить. По крайней мере, видишь перед собой достойного собеседника, а не попугая, исполняющего попурри из популярной брошюрки по найму персонала.
У меня несколько дипломов о высшем образовании, есть среди них и диплом лингвиста (с правом преподавания английского языка).
Вот что я скажу об изучении языка и о словарях. Все дело в том, что лезть в словарь за переводом слов может быть хоть и «лениво» и «нетехнично» в наш век расцвета технологий, но, как ни странно, весьма полезно. В течение тех секунд, которые вы пролистываете словарь, вы сконцентрированы именно на этом слове, удерживаете его в голове, запоминаете, как оно пишется, и в результате оно лучше запоминается. Поэтому авторы лучших видеокурсов по изучению английского языка (для школьников и студентов) поступают следующим образом: приступая к повторению слов, которые нужно запомнить в одном уроке, они удерживают каждое слово на экране в течение как минимум 15-20 секунд, чтобы оно было перед глазами, и еще несколько раз повторяют его для лучшего запоминания.
Готовая же подсказка, да еще автоматическая, не мотивирует человека запоминать. Это примерно как с телефонной книжкой в мобильном телефоне: вот ответьте честно, кто-нибудь еще помнит наизусть 10 цифр, которые надо набрать, чтобы позвонить любимой девушке? старому приятелю? маме? Наверняка нет, или же вы помните далеко не все часто набираемые телефоны (а в школе, да и в институте, я прекрасно помнила телефоны полутора десятков своих подружек: сначала лезла в телефонную книжку, потом набирала номер, цифра за цифрой; так раз 10 телефон наберешь — и поневоле запомнишь, многие до сих пор из памяти не стерлись). Теперь не то, и это не потому, что память стала много хуже. Просто зачем мне их сейчас помнить наизусть, телефоны? Всплывающая подсказка на экране мобильного делает все за меня. Остается только нажать кнопку и позвонить.
Вот и со словами (особенно те, которые мы используем в каждодневной языковой практике чуть реже остальных) происходит примерно то же, что с номерами телефонов. Так что придется «довинчивать» вашу идею, чтобы человек получал искомое слово таким образом, который позволял бы ему не только быстро получить искомое, но еще и хорошо запоминать слова.
Многие люди, изучающие иностранный язык, заметили одну вещь: когда просто слушаешь аудиокнигу или смотришь фильм, запоминаешь гораздо меньше, чем когда слушаешь аудиокнигу и параллельно читаешь текст глазами. Вариант «слушать и читать одновременно» приводит к довольно быстрому прогрессу на средних уровнях. Так что мне кажется, если соединить аудио и чтение в один удобный и приятный для зрения и слуха поток, такая программа вполне может использоваться для самостоятельной работы по brushing up your English :)
Я думаю, что попасть в черные списки на любом почтовом сервере (не только на mail.ru) нетрудно, если нарушать довольно простые правила. Например, забывать удалять отписавшихся от рассылки из списков адресов, на которые вы продолжаете отсылать свои письма.
Так, например, отписавшись от рассылки, я продолжала получать длинные письма, в которых автор «Сола на клавиатуре» (или тот, кто выступал от его имени) спешил поделиться со мной мнением по разным вопросам, которые его, очевидно, сильно волновали. Я поступила просто: занесла в черный список адрес электронной почты, с которого приходили эти письма, и пожаловалась на спам. Полагаю, что моему примеру последовали и другие получатели таких писем, и администрация mail.ru приняла определенные глобальные меры против спама. Думаю, что администрация mail.ru вполне имеет право принимать такие меры.
Вигерс их относит к нефункциональным требованиям, и он, в общем прав, прав.
Нефункциональные требования — это требования, которые определяют не функции, а характеристики системы: ее производительность, надежность, доступность, масштабируемость и ряд других параметров (здесь перечислены характеристики качества, но, как уже сказано в статье, есть и другие виды нефункциональных требований). Требование к времени отклика вашего приложения — это тоже нефункциональное требование («производная» от производительности). Думаю, пользователям вряд ли понравится, если реакции системы они будут ждать 4 минуты после нажатия на кнопку интерфейса. Но в течение 2-3 секунд они могут подождать. Это самый простой пример.
Нефункциональные требования самым непосредственным образом определяют архитектуру разрабатываемого приложения, поэтому определять их очень важно, хотя многие предпочитают этого не делать, полагаясь на то, что hardware и технологии, с которыми они работают, уже обладает какими-то характеристиками качества — следовательно, определенное качество уже можно гарантировать. Отсутствие должного внимания, уделяемого нефункциональным требованиям, часто приводило к серьезным последствиям — от перепроектирования системы до полного провала проекта.
Что касается «основных» и «не основных» требований — приоритеты задаются для всех требований, как функциональных, так и нефункциональных. Категория требований и важность — это просто две разные вещи. Как функциональные, так и нефункциональные требования могут иметь как высокий, так и низкий приоритет.
Хороший вопрос. Мне кажется, первая фраза уже содержит ответ на него: чтобы понимать состояние проекта.
И сотни метрик, как мне кажется, не нужны. Нужны только те метрики, которые помогут нам ответить на вопросы:
1. Сколько денег мы должны иметь в распоряжении, чтобы они не закончились в самый неожиданный момент (нижняя и верхняя граница)?
2. Сколько людей и с какой квалификацией мы должны привлекать к работам, в какие сроки?
3. Каково общее состояние проекта, сколько работы сделано, сколько еще осталось?
Ответив на эти вопросы, мы получим искомое.
Вот, сижу, пока думаю.
1. Локализация программного обеспечения (нет, это не просто перевод ресурсных строчек, а изменение программного продукта для его адаптации к условиям российского рынка и требованиям законодательства). Руководство этими проектами. Разные компании в разное время, в основном до 2000 года. Иных уже нет, а те далече.
2. Разработка ПО. Тоже разные компании в разное время.
В их числе — проданная какому-то системному интегратору компания, являвшаяся «собственным» отделом разработки при Sybase CIS. Здесь я выступала в роли инициатора определения SLA для нас со стороны нашего заказчика.
«Высокие технологии и стратегические системы», компания, принадлежащая АФК «Система» (входит в концерн «РТИ Системы», наряду с NVision и Sitronics — компаниями, которые разрабатывают софт для крупных операторов мобильной связи) 2011 — 2012 г. Когда мы начинали отдавать часть работ на аутсорсинг, выяснилось, что только трое человек в компании знают, что такое SLA. Поэтому писать эти условия пришлось мне (под редакцией Дмитрия Новоселова, руководителя департамента разработки — здесь до некоторых пор я многое делала под его редакцией, и это было испытание почище «Баланса Белого» с его «Яндексом»).
Дмитрий Новоселов — человек, начавший свою карьеру как системный программист, лет 7 в совокупности посвятивший роли системного архитектора, и только потом ушедший в проектный менеджмент (последние 5 лет в роли PM — в компании КРОК). Знаю я его уже около 15 лет.
Поскольку о Новоселове я могу рассказывать долго и вдохновенно, надеюсь, что это был не вполне само-пиар.
Проблема только в том, что это высокорисковые проекты. И вести их на условиях fixed price — на мой взгляд, просто инвестиции в будущего клиента, которого любишь-понимаешь. Опять же, смена вкуса Ивана Никифоровича на вкус Семена Ильича (при смене менеджмента на стороне клиента) может добаить еще три неожиданных проваленных итерации. У меня лично уже не всегда хватает терпения догадываться о предъявляемых требованиях методом проб и ошибок. Мне это скучно, и я обычно первой предлагаю договориться об SLA или изменить условия контракта — пусть даже с заметной выгодой для заказчика, но с четкими условиями «если — то».
При этом, когда я выполняю менеджерские функции, я всегда помню позитивный опыт работы с Microsoft и многие вещи «из прошлой жизни» использую, так или иначе видоизменив. Обычно и те, кто работает со мной на условиях субподряда, при этом не жалуются. Криков и воплей не раздается, ни одного субподрядчика пока по моей вине не пострадало. Правда, ни одного субподрядчика, не умеющего читать (особенно условия SLA), я тоже пока вокруг себя не видела. Быть может, мне повезло.
А про качество — немного известно (в той области, которая относится к моей сфере компетенции). Они (Microsoft), заключая контракт, всегда оговаривают детали и выставляют что-то вроде SLA, где описывают то, чего они ждут, в плане требований к качеству готового продукта.
Описывают метрики, по которым оценивают это качество, разъясняют своим субподрядчикам смысл этих метрик, а также последствия нарушения SLA. И в списке замечаний и претензий ссылаются на пункты SLA. Если ссылки на пункт SLA нет, а замечание есть (например, что-то там не понравилось Джону Смиту, но пункта SLA «результат должен нравиться Джону Смиту» в контракте нет) — оно устраняется не за счет компании-поставщика сервиса, а за счет самой компании Microsoft. Но такое на моей памяти случалось ну крайне редко — от силы раз или два.
Возможно, мне повезло: в той области, к которой принадлежу я, разработать и внедрить метрики для SLA не очень сложно. Но там, где невозможно их разработать и формализовать — работа на условиях «вы сами делаете то, что мы закажем, и если нам не понравится, вы будете все переделывать заново, пока нам не понравится — и после этого получите деньги» — это не та работа, которую стоит вообще предлагать и уж конечно не та работа, за которую стоит браться. На мой взгляд, тут обе стороны должны были искать какой-то разумный компромисс. Иначе мы получим то, что и получили: на указанных условиях за работу согласны будут взяться только очень неопытные новички, которые и результата не достигнут, и потом будут вслух обижаться.
Тогда ваша (как и автора статьи) точка зрения мне вполне понятна. Я же говорю — различия в менталитете. Разруха-то не в клозетах, разруха-то в головах.
Западная корпоративная культура очень отличается от местных полукустарных поделок (пусть даже очень крупных). В том числе и менталитетом («я пригласил вас не затем, чтобы мы оба ушли разочарованные друг в друге из-за непрофессионализма нас обоих — я пригласил вас для того, чтобы мы долго и плодотворно сотрудничали»), и степенью подготовки менеджеров в вопросах, относящихся непосредственно к менеджменту.
Соберемся в лесу и устроим НЕконференцию.
Большое спасибо. Одной этой аналогии вполне достаточно, чтобы воздержаться от контактов с HR-службой «Яндекса» — по крайней мере до тех пор, пока там не сменят руководителя отдела подбора персонала, наняв кого-нибудь поумнее.
Как я уже неоднократно говорила, задача девочки из HR — мило улыбнуться, организовать собеседование с техническими специалистами. Еще раз улыбнуться, пригласить на следующее собеседование (если такое будет проводиться), затем — прислать Job Offer с четко прописанными условиями контракта или вежливо сообщить о том, что, к сожалению, предложение о работе сделать в настоящий момент не представляется возможным. Принять документы, оформить на работу, а при увольнении — выдать документы. Вести кадровое делопроизводство, проводить мониторинг рынка труда. И все. Да. это — все, чем она может помочь (именно помочь, а не навредить) коллективу.
А «психологические этюды» с людьми, у которых IQ выше 160, девочка из HR разыгрывать по определению не может. Просто потому, что до понимания логики мышления и мотивов поведения таких людей она еще немножечко не доросла. Не тот уровень.
К стресс-интервью, проводимому профессиональными психологами с многолетним опытом в бизнес-консультировании (обычно привлекаются в качестве консультантов для собеседований с людьми, претендующими на ключевые роли в серьезных IT-компаниях), тем не менее, я отношусь положительно — это бывает забавно. Среди них встречаются достойные люди, с которыми бывает приятно поговорить. По крайней мере, видишь перед собой достойного собеседника, а не попугая, исполняющего попурри из популярной брошюрки по найму персонала.
Вот что я скажу об изучении языка и о словарях. Все дело в том, что лезть в словарь за переводом слов может быть хоть и «лениво» и «нетехнично» в наш век расцвета технологий, но, как ни странно, весьма полезно. В течение тех секунд, которые вы пролистываете словарь, вы сконцентрированы именно на этом слове, удерживаете его в голове, запоминаете, как оно пишется, и в результате оно лучше запоминается. Поэтому авторы лучших видеокурсов по изучению английского языка (для школьников и студентов) поступают следующим образом: приступая к повторению слов, которые нужно запомнить в одном уроке, они удерживают каждое слово на экране в течение как минимум 15-20 секунд, чтобы оно было перед глазами, и еще несколько раз повторяют его для лучшего запоминания.
Готовая же подсказка, да еще автоматическая, не мотивирует человека запоминать. Это примерно как с телефонной книжкой в мобильном телефоне: вот ответьте честно, кто-нибудь еще помнит наизусть 10 цифр, которые надо набрать, чтобы позвонить любимой девушке? старому приятелю? маме? Наверняка нет, или же вы помните далеко не все часто набираемые телефоны (а в школе, да и в институте, я прекрасно помнила телефоны полутора десятков своих подружек: сначала лезла в телефонную книжку, потом набирала номер, цифра за цифрой; так раз 10 телефон наберешь — и поневоле запомнишь, многие до сих пор из памяти не стерлись). Теперь не то, и это не потому, что память стала много хуже. Просто зачем мне их сейчас помнить наизусть, телефоны? Всплывающая подсказка на экране мобильного делает все за меня. Остается только нажать кнопку и позвонить.
Вот и со словами (особенно те, которые мы используем в каждодневной языковой практике чуть реже остальных) происходит примерно то же, что с номерами телефонов. Так что придется «довинчивать» вашу идею, чтобы человек получал искомое слово таким образом, который позволял бы ему не только быстро получить искомое, но еще и хорошо запоминать слова.
Многие люди, изучающие иностранный язык, заметили одну вещь: когда просто слушаешь аудиокнигу или смотришь фильм, запоминаешь гораздо меньше, чем когда слушаешь аудиокнигу и параллельно читаешь текст глазами. Вариант «слушать и читать одновременно» приводит к довольно быстрому прогрессу на средних уровнях. Так что мне кажется, если соединить аудио и чтение в один удобный и приятный для зрения и слуха поток, такая программа вполне может использоваться для самостоятельной работы по brushing up your English :)
Восьмой класс.
Так, например, отписавшись от рассылки, я продолжала получать длинные письма, в которых автор «Сола на клавиатуре» (или тот, кто выступал от его имени) спешил поделиться со мной мнением по разным вопросам, которые его, очевидно, сильно волновали. Я поступила просто: занесла в черный список адрес электронной почты, с которого приходили эти письма, и пожаловалась на спам. Полагаю, что моему примеру последовали и другие получатели таких писем, и администрация mail.ru приняла определенные глобальные меры против спама. Думаю, что администрация mail.ru вполне имеет право принимать такие меры.