четверг, марта 27, 2008

100% требований. Или «дьявол кроется в деталях».

У нас на работе разгорелась дискуссия на тему, какими должны быть идеальные требования к программному продукту. Насколько детально нужно прорабатывать требования? Какие аспекты надо описывать в требованиях (экранные формы, действия, контексты, переходы, особые случаи)? Как отслеживать изменения в требованиях?
Всем понятно, что без внятных требований сделать хороший продукт невозможно. Зависимость тут прямая – чем лучше определены и сформулированы требования, тем лучше получится продукт (ну, наверное, правильнее применить сослагательное наклонение - может получиться :). Отсюда простой и незамысловатый вывод – надо стараться собрать как можно более полные и детальные требования и будет нам счастье.

Не будет счастья. Не работает такой подход. Когда вы слышите о 100% требований к системе, знайте это оксюморон.

На одном из последних проектов мы разрабатывали систему, которая должна поддерживать некий новый бизнес процесс у заказчика. То есть компания заказчика занималась одной деятельностью, ну например, выращивала фанеру, и параллельно для своих нужд держала мастерскую по ремонту фанероводной техники. И так хорошо это мастерская работала, что решили они оказывать услуги по ремонту этой техники и зарабатывать на этом деньги. Ну а мы должны были сделать систему, которая будет поддерживать этот новый бизнес.

Нам повезло, человек, который занимается этим новым направлением, и которого назначили владельцем системы, оказался очень грамотным специалистом и просто приятным человеком. За пару встреч с ним мы (менеджер проекта, аналитик, и архитектор) обсудили контуры будущей системы и получили общее видение, которое и оформили в виде соответствующего документа, в придачу наши ребята за пару дней соорудили прототип на статическом HTML. Прототип очень понравился заказчику, и он готов был дать отмашку на начало разработки (система нужна была ему, как говориться «уже вчера»), но не тут-то было. Руководство потребовало описания всех требований, составления детального план графика проекта и назначения формального milestone «Утверждение требований».

Что поделаешь, во времена моей юности в таких случаях говорили «Партия сказала – надо, комсомол ответил – есть». Мы взялись за формирование детальных требований. Владелец системы, конечно, не мог уделять нашему аналитику много времени (ему надо было новый бизнес поднимать) и он назначил для этих целей пару своих экспертов. Мы начали расписывать детальные use case, а наш прототип начал усложняться и детализироваться. Мы детально расписали атрибуты документов и их жизненный цикл. Мы описали и реализовали в прототипе все экранные формы. Мы согласовывали все, вплоть до заголовков столбцов и надписей на кнопках. Но чем глубже мы погружались в детали, тем становилось хуже. Я уже говорил, о том, что бизнес процесс заказчика был новый, и существовал в основном лишь в головах людей, с которыми мы говорили. При детализации требований всплывали противоречия, которые наши собеседники на ходу пытались разрешить. Их решения аккуратно записывал наш аналитик. Когда мы рассматривали эти решения, всплывали новые противоречия, и этому не было конца. Хуже того, когда мы на следующей встрече показывали прототип того, что обсуждали на предыдущей встрече, обычно обсуждение начиналось по новой и принималось какое нибудь новое решение. Некоторые формы прототипа мы переделывали таким образом по три-четыре раза. Фактически мы уперлись в невидимую стену. Чем больше у нас становилось требований, тем больше в них обнаруживалось противоречий. Так прошло два месяца, но от полной непротиворечивой картины нашей будущей системы мы были так же далеки, как и в тот день, когда в первый раз показали прототип системы заказчику. Не даром говорят, что дьявол кроется в деталях. Стоит ли говорить о том, что наши разработчики все это время нервно курили в сторонке :).

Тут многие спросят, а зачем мы вообще занимались этой, извините, ерундой. Вообще-то, такая ситуация повторяется из раза в раз, вовсе не из-за глупости и неопытности участвующих в ней людей, а под давлением объективных обстоятельств. От команды разработчиков руководство требует наличия полного описания всех требований к системе, и проведение формального approve этих бумаг заказчиком. Заказчика, в этих обстоятельствах, придавливает груз ответственности, которую на него взваливают тем же самым требованием формального утверждения всех требований. Понятно, что после этого шага заказчик оказывается в заведомо невыгодном положении. У него нет уверенности в том, что собранные требования верны, а после формального утверждения команда разработчика смело может отфутболивать все его просьбы о внесении изменений в будущую систему. Получается, что и команда и заказчик находятся под давлением из-за необходимости утверждения всех требований к системе до начала разработки. Что поделаешь, среди менеджеров среднего звена распространено мнение, что это (milestone «Утверждение требований») хороший способ минимизации проектных рисков. Можно сколько угодно цитировать высказывания Крэтчена, Лармана, Фаулера и других корифеев о бессмысленности этого шага (я бы добавил, что очевидна его вредность), но это действительно хороший способ прикрыть задницу менеджера в отношениях с заказчиком, и тут ничего не поделаешь.

Что же до нашего проекта, то все закончилось хорошо. Мы постарались успокоить заказчика, и заверили его, что калитка на внесение изменений в систему вовсе не будет нами захлопнута после утверждения требований. Мы продолжали уточнять детали по ходу разработки. Мы подсказывали заказчику лучшие решения для устранения противоречий, в общем, старались взаимодействовать с ним плотно и конструктивно. За время разработки практически во все собранные ранее требования были внесены изменения. Кроме того, мы предложили провести при запуске системы период пилотной эксплуатации, в ходе которой система будет оставаться открытой для внесения изменений. Т.е. мы проявили гибкость. Сейчас заканчивается пилотирование системы и заказчик ей вполне доволен. А для нас очевидно, что если бы мы тупо сидели и три месяца кодировали по первоначально собранным и утвержденным требованиям, результат оказался бы плачевный.

В заключение, небольшой case study:
  • никогда не пытайтесь сформулировать 100% требований к системе. Есть очень ограниченное число случаев, когда это возможно сделать в принципе. Из своей практики я могу привести лишь пример портирования существующей системы на новую платформу. Даже традиционные «тяжелые» методологии наподобие RUP не требуют формирования 100% требований до начала разработки. Если кто-то требует от вас сделать это, значит этот человек недостаточно профессионален в области разработки софта. Уточняйте и формируйте требования до тех пор, пока не почувствуете что у вас и у заказчика сформировалось единое видение системы, и вы понимаете как ее сделать.

  • если вы оказались в ситуации, когда с вас требуют 100% требований до начала разработки, не бодайтесь со стеной. Направьте свою энергию на установление хороших контактов с заказчиком и носителями экспертизы в предметной области. Требования все равно будут меняться и уточняться и хороший контакт с этими людьми поможет вам добиться успеха во время разработки.

  • для ситуации, когда требования к будущей системе сформулировать сложно, или они быстро меняются, лучше всего подходят agile методики разработки. Однако не всегда удается их применить в рамках фиксированных сроков и бюджетов, либо из-за ограничений в контракте с заказчиком. Тем не менее, применяйте agile практики на уровне проектной команды (короткие итерации, постоянная интеграция, модульные тесты, архитектура, ориентированная на изменения). Старайтесь демонстрировать заказчику результаты разработки на самых ранних стадиях. Старайтесь получить от заказчика максимальный feedback. Это всегда производит на заказчика очень хорошее впечатление, не говоря уже о том, что благоприятно сказывается на качестве готового продукта.

12 комментариев:

Илья Казначеев комментирует...

некий новый бизнес процесс
На всякий случай.
В русском языке составные слова (или как их там) пишутся всегда через дефис и никогда - через пробел.
То есть, "бизнес процесс", "турбо солярий" и "интернет кафе" не имеют права на жизнь, да и смотрятся по-дурацки.

snow комментирует...

Применили водопадную модель к сбору требований :)
Просто как и любой другой этап разработки по MSF или RUP, сбор, анализ и уточнение требований - процесс циклический. Все кому не лень уже об этом написал, начиная от Вигерса до ...

Анонимный комментирует...

Тут просто речь о недопонимании, что такое 100% требований с точки зрения менеджеров. Им просто важно, чтобы 100% expenses было покрыто. Т.е. детализацию нужно доводить до уровня, когда стоимость фичи становится ясной. Например уровень "Система рассчитана на 5-15 пользователей, вход должен быть авторизован, должна быть возможность управления аккаунтами" вполне достаточен - ведь видно, что это все дня три (идеальных) будет стоить. Независимо от того, как это конкретно решается: через OpenID, собственных четыре формочки нарисовать или какой-нибудь сканер сетчатки глаза прикрутить. А конкретику можно уже непосредственно в процессе разработки утрясать. Или (происходит чаще), делать простейший вариант не спрашивая заказчика вообще, показывать ему и в 50% случаев улучшать.

Sergey Rozovik комментирует...

> Применили водопадную модель к сбору требований :)

Это не мы применили, а нас применили к водопадной модели :( Ну, или, пытались применить :)
А пост, по большей части о том, как выкарабкиваться из этого водопада, в который вас может затянуть менеджмент или заказчик.

Sergey Samoylenko комментирует...

Трезво написано.

А вот говорят есть еще такие заказчики, которые понимают, что автоматизировать с помощью ИТ идеи, находящиеся в голове это неразумно. Ходят слухи, что они сначала тратят время на то, чтобы разработать, собственно, новый бизнес процесс, порожденный хорошей идеей. А процесс этот уже будет автоматизироваться сильно быстрее, так как то время на "додумывание" процесса, которое тратилось на уточнении требований будет уже вложено вначале и теми людьми, которые мыслят более абстрактно, чем привлеченные местечковые эксперты

glbl комментирует...

Клиент никогда не знает точно, что ему надо. Единственно надежный способ написать хорошую спецификацию - иметь внятный источник информации о сущностях и связях у клиента. Формы и кнопки - второстепенны. Первоначальный вариант кнопок и форм совершенно несуществен. Надо быстро клепать схемы БД прототипа, моделировать процессы принятия решений и запускать экспериментальную версию. Только после этого можно уточняться с кнопками и формами.
Так было двадцать лет назад.

Sergey Rozovik комментирует...

to glbl
> Так было двадцать лет назад.
Так и сейчас осталось.

Yury Skaletskiy комментирует...

То что вы пишете, очень созвучно моему собственному опыту.

Только в моей практике часто получалось не так радужно - заказчики очень любили использовать расхождения между продуктом и спецификацией для того, чтобы "протолкнуть" бесплатно по окончании работ какую-нибудь доработку, аргументируя тем, что "мы же имели в виду совершенно другое". Так что риски, к сожалению, приходится минимизировать с двух сторон :)

alexandroid комментирует...

>> А для нас очевидно, что если бы мы тупо сидели и три месяца кодировали по первоначально собранным и утвержденным требованиям, результат оказался бы плачевный.

Я так и не понял этот момент. Вы же вроде бы говорите, что вас заставили собрать множество деталей по требованиям, какие все равно потом менялись во время разработки, чем задержали начало разработки. Здесь "тупо сидели и кодировали" относится к этой задержке?

А не может ли быть так, что все-таки сбор требований и нахождение противоречий "до разработки" помог вам сэкономить время этой самой разработки, время которое иначе было бы намного дороже даже времени "курения программистов"? (Вообще комментарий о том, что программисты простаивали считаю лишним -- это никак не может быть аргументом для начала работы по кодированию проекта)

Sergey Rozovik комментирует...

to alexandroid
> Я так и не понял этот момент.

Сослагательное наклонение.
Несмотря на то, что мы довольно детально расписали первоначальные требования, они все равно изменились в процессе разработки. И мы учли эти изменения по ходу работы, потому что продолжади активно контактировать с заказчиком. А вот если бы мы положились на первоначальные требования и тупо их реализовывали.... далее по тектсу.

>А не может ли быть так, что все-таки сбор требований и нахождение противоречий "до разработки" помог вам сэкономить время этой самой разработки
Основной мой посыл в том что нельзя собрать все требования. Ждать и не начинать разработку до полного сбора требований - это ущербная практика. С другой стороны нельзя начать разработку пока не ясны требования. Вопрос, когда же можно начинать проектировать и кодировать решается эмпирически (как и многое в нашей профессии). Критерий определения этого момента - у вас сложилось целостное видение решаемых будущей системой проблем, и понимание как это сделать.

alexandroid комментирует...

Спасибо за ответ!

Основной посыл понятен. =) Просто все-таки не совсем понятно, что бы у вас вышло, если бы начальство не заставило вас продолжить собирать требования, и какой эффект это оказало на "утряску" вашего видения проекта и понимания всех его проблем...

Sergey Rozovik комментирует...

to alexandroid

Что бы произошло? Сдали бы проект на полтора месяца раньше. Возможно, успели реализовать еще несколько фич, которые были отложены на следующий релиз.