Техническое или функциональное задание? Как составлять документ, продающий услугу заказчику, и защищающий исполнителя

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

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

Поэтому для заказчика стоит составлять отдельную проектную документацию. Понятную и наглядную. Ее принято называть функциональным заданием. В нем просто и понятно должны быть описаны основные модули будущего продукта, основные возможности для пользователя.

Чем корректнее и понятнее составлено функциональное задание, тем проще клиенту сдавать готовый проект. Он видит, что на деле получилось ровно то, что он подписывал. Игнорируя создание ФЗ и экономя время на предварительном заверении, менеджер только усложняет проект и ворует у всей команды время на будущие доработки из-за недопонимания заказчика.

Начинать оформление любого ФЗ я рекомендую с формулировки бизнес-требований. Это задачи, которые предъявляет заказчик к будущему продукту. Именно от этих тезисов должен отталкиваться исполнитель при проектировании и разработке. Конечный продукт должен решать конкретные «боли» бизнеса.

Следующий этап — описание ролей пользователей и основных пользовательских сценариев. И менеджеру проекта и команде специалистов, которая его будет реализовывать, важно знать, кто и как будет пользоваться готовым продуктом. От особенностей аудитории зависит необходимый функционал. Например, можно взять интернет-магазин. В зависимости от его специфики, основными пользователями могут быть:

• Розничные покупатели, которые будут выбирать товары для себя. Причем делать они это могут как гость и как зарегистрированный пользователь (а это разные сценарии)
• Оптовые покупатели, приобретающие крупные партии для формирования складских запасов.
• Администратор интернет-магазина и операторы, вводящие информацию о товарах.

И другие категории пользователей. Для разработки качественного продукта важно знать, кто именно будет его использовать и какие задачи решать.

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

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

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

• Не нужно впадать в крайности. Слишком подробное описание до мельчайших деталей сильно увеличивает время на подготовку функционального задания, и увеличивает его объем. Слишком большое ФЗ непригодно для использования, ни заказчиком, ни исполнителем.

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

• Избегайте оценочных суждений в описаниях. Формулировки из разряда «кнопка должна быть заметной» или «форма должна быть удобной для пользователя» могут трактоваться по-разному. В итоге это может вызвать разногласия между менеджером и заказчиком, у которого свои ожидания и своё понимание субъективных оценок.
• Также избегать нужно формулировок, обозначающих опцию выполнения: «Можно сделать», «было бы неплохо добавить». Они неуместны в проектной документации, поскольку ее цель — четкое обозначение фронта работ.
• Все, что описано в проектной документации, должно отвечать на 3 вопроса: «Что?», «Где?» и «Как?». Суть действия, где оно должно быть произведено, и какой результат оно должно дать. Проверяя все записи по этим трем вопросам, можно убедиться в том, что не возникнет упущенных деталей.
• Все существенные условия должны быть описаны. В этом заключается одна из ключевых задач менеджера проектов. Он должен получить от заказчика максимум информации, даже когда клиент упускает важные моменты. Специалист должен лучше знать, какая именно информация ему нужна для реализации проекта.

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

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

Менеджер проекта — это в том числе продавец. Об этом не стоит забывать. Чем больше функциональности специалист сможет продать клиенту в рамках одного проекта, тем больше заработает компания. Но с предложениями дополнительных функций и опций нужно быть осторожным, особенно если бюджет и сроки ранее были обозначены. Клиенту дополнение нужно «продать» — объяснить его пользу и обоснованность цены. Если заказчик итак согласился на максимальный для решения задачи бюджет, или неохотно обсуждает изменение сметы, лучше на него не давить. Это может испортить впечатление о сотрудничестве, а у нас другая задача — сделать клиента постоянным.

Все вышесказанное можно резюмировать в один простой тезис: Функциональное задание — это документ, в котором понятно для всех сторон описан проект. ФЗ решает сразу несколько задач: демонстрирует и «продает» клиенту будущий продукт, помогает точно сформулировать и утвердить задачу для исполнителей, а также защитить компанию от недопониманий и проблем при сдаче проекта клиенту.

Источник — Курс «Как стать классным менеджером проектов и не ох..еть»

Ссылка на курс для жителей России