У нас на работе разгорелась дискуссия на тему, какими должны быть идеальные требования к программному продукту. Насколько детально нужно прорабатывать требования? Какие аспекты надо описывать в требованиях (экранные формы, действия, контексты, переходы, особые случаи)? Как отслеживать изменения в требованиях?
Всем понятно, что без внятных требований сделать хороший продукт невозможно. Зависимость тут прямая – чем лучше определены и сформулированы требования, тем лучше получится продукт (ну, наверное, правильнее применить сослагательное наклонение - может получиться :). Отсюда простой и незамысловатый вывод – надо стараться собрать как можно более полные и детальные требования и будет нам счастье.
Не будет счастья. Не работает такой подход.
Когда вы слышите о 100% требований к системе, знайте это оксюморон. На одном из последних проектов мы разрабатывали систему, которая должна поддерживать некий новый бизнес процесс у заказчика. То есть компания заказчика занималась одной деятельностью, ну например, выращивала фанеру, и параллельно для своих нужд держала мастерскую по ремонту фанероводной техники. И так хорошо это мастерская работала, что решили они оказывать услуги по ремонту этой техники и зарабатывать на этом деньги. Ну а мы должны были сделать систему, которая будет поддерживать этот новый бизнес.
Нам повезло, человек, который занимается этим новым направлением, и которого назначили владельцем системы, оказался очень грамотным специалистом и просто приятным человеком. За пару встреч с ним мы (менеджер проекта, аналитик, и архитектор) обсудили контуры будущей системы и получили общее видение, которое и оформили в виде соответствующего документа, в придачу наши ребята за пару дней соорудили прототип на статическом HTML. Прототип очень понравился заказчику, и он готов был дать отмашку на начало разработки (система нужна была ему, как говориться «уже вчера»), но не тут-то было. Руководство потребовало описания всех требований, составления детального план графика проекта и назначения формального milestone «Утверждение требований».
Что поделаешь, во времена моей юности в таких случаях говорили «Партия сказала – надо, комсомол ответил – есть». Мы взялись за формирование детальных требований. Владелец системы, конечно, не мог уделять нашему аналитику много времени (ему надо было новый бизнес поднимать) и он назначил для этих целей пару своих экспертов. Мы начали расписывать детальные use case, а наш прототип начал усложняться и детализироваться. Мы детально расписали атрибуты документов и их жизненный цикл. Мы описали и реализовали в прототипе все экранные формы. Мы согласовывали все, вплоть до заголовков столбцов и надписей на кнопках. Но чем глубже мы погружались в детали, тем становилось хуже. Я уже говорил, о том, что бизнес процесс заказчика был новый, и существовал в основном лишь в головах людей, с которыми мы говорили. При детализации требований всплывали противоречия, которые наши собеседники на ходу пытались разрешить. Их решения аккуратно записывал наш аналитик. Когда мы рассматривали эти решения, всплывали новые противоречия, и этому не было конца. Хуже того, когда мы на следующей встрече показывали прототип того, что обсуждали на предыдущей встрече, обычно обсуждение начиналось по новой и принималось какое нибудь новое решение. Некоторые формы прототипа мы переделывали таким образом по три-четыре раза. Фактически мы уперлись в невидимую стену.
Чем больше у нас становилось требований, тем больше в них обнаруживалось противоречий. Так прошло два месяца, но от полной непротиворечивой картины нашей будущей системы мы были так же далеки, как и в тот день, когда в первый раз показали прототип системы заказчику. Не даром говорят, что дьявол кроется в деталях. Стоит ли говорить о том, что наши разработчики все это время нервно курили в сторонке :).
Тут многие спросят, а зачем мы вообще занимались этой, извините, ерундой. Вообще-то, такая ситуация повторяется из раза в раз, вовсе не из-за глупости и неопытности участвующих в ней людей, а под давлением объективных обстоятельств. От команды разработчиков руководство требует наличия полного описания всех требований к системе, и проведение формального approve этих бумаг заказчиком. Заказчика, в этих обстоятельствах, придавливает груз ответственности, которую на него взваливают тем же самым требованием формального утверждения всех требований. Понятно, что после этого шага
заказчик оказывается в заведомо невыгодном положении. У него нет уверенности в том, что собранные требования верны, а после формального утверждения команда разработчика смело может отфутболивать все его просьбы о внесении изменений в будущую систему. Получается, что и команда и заказчик находятся под давлением из-за необходимости утверждения всех требований к системе до начала разработки. Что поделаешь, среди менеджеров среднего звена распространено мнение, что это (milestone «Утверждение требований») хороший способ
минимизации проектных рисков. Можно сколько угодно цитировать высказывания Крэтчена, Лармана, Фаулера и других корифеев о бессмысленности этого шага (я бы добавил, что очевидна его вредность), но это действительно хороший способ прикрыть задницу менеджера в отношениях с заказчиком, и тут ничего не поделаешь.
Что же до нашего проекта, то все закончилось хорошо. Мы постарались успокоить заказчика, и заверили его, что калитка на внесение изменений в систему вовсе не будет нами захлопнута после утверждения требований. Мы продолжали уточнять детали по ходу разработки. Мы подсказывали заказчику лучшие решения для устранения противоречий, в общем, старались взаимодействовать с ним плотно и конструктивно. За время разработки практически во все собранные ранее требования были внесены изменения. Кроме того, мы предложили провести при запуске системы период пилотной эксплуатации, в ходе которой
система будет оставаться открытой для внесения изменений. Т.е. мы проявили
гибкость. Сейчас заканчивается пилотирование системы и заказчик ей вполне доволен. А для нас очевидно, что если бы мы тупо сидели и три месяца кодировали по первоначально собранным и утвержденным требованиям, результат оказался бы плачевный.
В заключение, небольшой case study:
- никогда не пытайтесь сформулировать 100% требований к системе. Есть очень ограниченное число случаев, когда это возможно сделать в принципе. Из своей практики я могу привести лишь пример портирования существующей системы на новую платформу. Даже традиционные «тяжелые» методологии наподобие RUP не требуют формирования 100% требований до начала разработки. Если кто-то требует от вас сделать это, значит этот человек недостаточно профессионален в области разработки софта. Уточняйте и формируйте требования до тех пор, пока не почувствуете что у вас и у заказчика сформировалось единое видение системы, и вы понимаете как ее сделать.
- если вы оказались в ситуации, когда с вас требуют 100% требований до начала разработки, не бодайтесь со стеной. Направьте свою энергию на установление хороших контактов с заказчиком и носителями экспертизы в предметной области. Требования все равно будут меняться и уточняться и хороший контакт с этими людьми поможет вам добиться успеха во время разработки.
- для ситуации, когда требования к будущей системе сформулировать сложно, или они быстро меняются, лучше всего подходят agile методики разработки. Однако не всегда удается их применить в рамках фиксированных сроков и бюджетов, либо из-за ограничений в контракте с заказчиком. Тем не менее, применяйте agile практики на уровне проектной команды (короткие итерации, постоянная интеграция, модульные тесты, архитектура, ориентированная на изменения). Старайтесь демонстрировать заказчику результаты разработки на самых ранних стадиях. Старайтесь получить от заказчика максимальный feedback. Это всегда производит на заказчика очень хорошее впечатление, не говоря уже о том, что благоприятно сказывается на качестве готового продукта.