Посвящается С.Нековалю
На мой взгляд – очевидные вещи, но поскольку вопрос этот постоянно всплывает и постоянно приходится что-то доказывать и убеждать, я решил аргументацию выбить в камне, раз и навсегда 🙂
Для непосвященных – что такое FRD или Functional Requirements Document? Это документ, детально описывающий функциональные возможности системы с упором на «как». Обычно этот документ расширяет и детализирует BRD или Business requirements document, менее детализированные требования, описывающие «что» система должна делать. Имея хорошее FRD разработчики даже самой средней квалификации садятся и пишут систему без лишних вопросов. Т.е. это – главный документ на проекте.
Большинство проектов у нас запускается по конвейеру: VisionBRD -> предварительная оценка -> FRD -> точная оценка -> технические спецификации -> Поехали!
Сама разработка может идти в рамках RUP или Agile в зависимости от проекта и требований заказчиков, при этом документация либо пишется заранее и по ходу дела уточняется, либо разрабатывается в рамках итерации.
Однако время от времени, особенно когда речь идет о долгоиграющих проектах, возникает соблазн пропустить фазу FRD. Действительно, если у нас есть список требований и макеты экранов, зачем собственно нам еще и FRD? И так прекрасно оценим и разработаем.
Однако по опыту я знаю, что вероятность успешности проекта в этом случае значительно ниже. Итак, что же дают хорошо проработанные функциональные требования?
Улучшают коммуникацию с заказчиком
В 100 случаях из 100 — даже если заказчик хотел сэкономить на требованиях, при получении от нас требований, картина всегда одна. Заказчик внимательнейшим образом их изучает, и «вдруг» выясняется, что мы задачи понимаем по-разному. Всегда выясняется. Процентов 20 как минимум, а то и 40 приходится перерабатывать. При этом трудозатраты на разработку (часто уже подписанные) обычно возрастают.
Ну и зачем вам это нужно, спрашивается. Кто вас за язык дергал, сидели бы тихо-мирно, разрабатывали бы себе потихоньку, ведь обо всем уже договорились.
А затем, что мы все-таки (А) хотим, чтобы наши системы шли в работу, а не коту под хвост, и (Б) – это выгодно в т.ч. и нам. Синхронизируя наше понимание с клиентом, мы избегаем конфликтов, мы избегаем недовольства на заключительной стадии и мы избегаем крупных переделок. Если речь идет о долгоиграющих отношениях с клиентом, а не о том, чтобы схватить и убежать, переделывать все равно придется. Может быть заказчик с неохотой раскошелится на переделки, но даже в этом случае, нам от этого сильно лучше не будет. Вряд ли нас выберут во второй раз.
Зато уже на втором совместном проекте, вопросов не будет, и ТЗ не будет восприниматься как очередной сравнительно честный способ отъема денег.
Подключают интеллект команды
Когда есть документ, его можно дать почитать одному члену команды, другому, можно его обсудить, можно даже устроить мозговой штурм. Результаты не пропадут. Они будут добавлены в виде комментариев или интегрированы в документ. Опять же по опыту, такие «разговоры вокруг стола», коллективный опыт и интеллект команды улучшают стабильность и сбалансированность технического задания и конечной системы.
Час-два такого «пробалтывания» могут спасти тонны головной боли на последующих стадиях разработки. Если же документа нет, то непонятно о чем говорить и что обсуждать. К такому разговору можно привлечь и заказчика, если с ним стабильные отношения и хорошее взаимопонимание.
Конечно лучше, когда все это происходит до оценки стоимости проекта, поскольку всегда появляются новые идеи и иногда приходится реально себя сдерживать, чтобы не нафантазировать на убыточный проект.
Аналитику
Я думал провести сравнение со строительством дома, где есть архитектурно-планировочное решение и есть инженерные коммуникации. И эти коммуникации можно сравнить с аналитикой по проекту. Особенно если дом строится в климате с холодной зимой, нужно просчитать крышу, чтобы не рухнула под снегом, и как сделать, чтобы трубы не замерзли, если вдруг котел выйдет из строя и т.д.
Но разница в том, что все эти проблемы однотипные, решения тоже однотипные. Их несколько, но они все известны.
Наши системы все уникальные. Нет двух не только одинаковых, но и похожих. Управление городским освещением и контроль расходов, интернет-трейдинг и анализ пост-клика.
Короче есть бутылки с пивом, есть линии по разливу пива в бутылки, есть заводы, которые производят линии для разлива пива в бутылки . Мы даже не такой завод. Нет, конечно, мы можем построить линию для разлива пива (CMS), но при этом мы делаем еще и роботы для разводки печатных плат и ракету-носитель для телескопа. И многое другое. Уникальное.
Аналитика в частности состоит в том, чтобы рассмотреть продукт в разных проекциях, найти связи между характеристиками и компонентами, провести обобщения, которые в дальнейшем могут сэкономить много головной боли при разработке. Пусть это звучит как тавтология, аналитик производит анализ требований и из их аморфной массы, из хаоса строит более-менее гармоничную конструкцию. При этом всегда выявляются новые характеристики, иногда существующие схлопываются, оказываются либо избыточными, либо схожими.
Обычно после проработки аналитиком оценка трудоемкости проекта возрастает по сравнению с оценкой, проведенной по линейному списку требований. Это происходит потому, что многомерная картина всегда выявляет дополнительные характеристики, скрытые при поверхностном анализе. Список требований – это рентгеновский снимок, аналитика – это томограмма.
Хороший аналитик широко пользуется графическим представлением информации, одна продуманная диаграмма состояний заменяет 5 страниц текста.
После того, как поработал аналитик, систему можно спокойно отдавать разработчикам, даже не самым квалифицированным. Не это ли кстати причина, того что наши разработчики часто недолюбливают детальные FRD? Не желают быть низведенными в статус кодеров?
Это понятное опасение, тем не менее, в данном случае лучше пожертвовать комфортом разработчиков, которым на самом деле и без аналитики всегда есть, где применить свои таланты, чем гарантированным успехом проекта.
Кстати, в нашей команде мы всегда при желании даем разработчику проявить себя в роли аналитика. Но это будет другая роль. Результатом его работы в этой роли будет не код, а документ.
Возможность аутсоурсинга
Когда у нас не хватает рук, имея FRD, мы всегда можем привлечь сторонних разработчиков, будь то разработческая компания или отдельные фрилансеры, и отдать им кусок проекта.
Точность оценки
Стоимость проекта может быть оценена гораздо более точно.
Качество тестирования
Ну это наверное и объяснять не надо. Я бы на месте руководителя тестовой группы вообще не брал бы проекты на тестирование без функциональных требований. Иначе непонятно, а что собственно мы тестируем? Как разрабатывать тесты? Что с чем сравнивать? Что значит, что система работает? Что есть баг, а что есть фича в конце концов.
То что Леша берет такие проекты, говорит о его высоком морально-политическом облике, но и его терпение может кончиться.
Пользовательскую документацию
Last but not least, заказчик получает как побочный продукт великолепную документацию даже об этом не догадываясь. Когда дело дойдет до внедрения системы, заказчик позовет технического писателя и имея этот документ и работающую систему, оный писатель левой ногой сделает такой хелп, что все пользователи будут жить долго и щастливо и любить друг друга. Аминь!
