Как техническое задание спасает от ошибок и трат

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

Не все клиенты и коллеги понимают, зачем такая дотошность. В этой статье объясним, ради чего вкладывать столько сил в ТЗ.

Почему техническое задание не усложняет, а упрощает рабочие процессы

У меня в памяти навсегда останется случай, когда часть задач мы прописали в ТЗ, а остальные обсудили с клиентом устно. Когда мы выполнили работу, оказалось, что она стоит почти в два раза дороже, чем изначальная оценка. Нетрудно представить эмоции клиента, когда он это услышал. Перед нами встал выбор: или потребовать оплату, или сохранить с человеком хорошие отношения. Мы выбрали второе и кодили частично бесплатно, все-таки вина лежала на нас.

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

В чем выигрывает клиент:

• Объем работ понятен сразу и однозначно. Не надо ни о чем догадываться и переспрашивать.
• Цена точно уложится в озвученный диапазон. А если превысит верхнюю планку, клиенту не придется доплачивать. 
• Если что-то пойдет не так в процессе сотрудничества, клиент может забрать ТЗ и передать другой команде разработчиков.
• Сроки завершения работ можно оценить заранее. Если на выполнение задач потребуется больше времени, чем обещали, клиент имеет право вычесть пени из оплаты.
• ТЗ выполняет функцию гарантийного талона. Там расписано, как все должно работать. Если готовый продукт в чем-то не соответствует документу, разработчики бесплатно исправят баги.

В чем выигрывает исполнитель: 

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

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

Сколько стоит ТЗ и с чего начинается работа над ним

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

Стоимость ТЗ зависит от двух факторов: объеми и сложность функционала продукта, а также четкости видения у клиента. 

Чем яснее заказчик понимает, чего он хочет, тем проще составить ТЗ. Однако клиенты нередко приходят с абстрактными идеями, которые разработчикам приходится «докручивать». Бизнес-аналитик тратит много часов на то, чтобы уточнить нюансы и спланировать процессы. Из-за этого стоимость технического задания возрастает.

Чем сложнее и нестандартнее заказ, тем больше придется заплатить за ТЗ. Например, клиент хочет индивидуальный проект за миллион рублей. Навскидку можно предположить, что техническое задание обойдется в 10-15% от общей стоимости.

По времени ТЗ обычно отнимает 15–25% от продолжительности проекта. Например, если весь объем работ займет шесть месяцев, около полутора месяцев уйдет на написание технического задания.

Из чего состоит ТЗ

Для всех проектов мы в WAPP используем один и тот же шаблон ТЗ, рекомендуем поступать так и другим компаниям. Конечно, шаблон можно адаптировать под специфику заказа и пожелания клиента. Однако нежелательно фиксировать в этом документе все до самых мелочей, лучше прописать только значимые аспекты, а в деталях оставить свободу для маневра.

Вот стандартная структура ТЗ, которая подойдет практически для любой отрасли:

• Описание бизнеса клиента и цели продукта. Объяснение того, что делает компания и зачем она обратилась к разработчикам.
• Глоссарий. Клиент не обязан разбираться в IT. Составитель ТЗ раскрывает ему суть технических терминов, которые упоминает в тексте.
• Требования к работе продукта. Рассказ о том, как должен функционировать сайт или приложение, с какой нагрузкой справляться, как обрабатывать ошибки, и так далее. Пометка о том, в каких операционных системах и браузерах можно запустить продукт.
• Непосредственно ТЗ, которое описывает:
  • работу блоков на всех страницах;
  • логику модулей, которые будут использованы особенно часто;
  • сценарии пользовательского поведения;
  • работу системы при взаимодействии с ней пользователей.
• Схема архитектуры — если она нужна. В ней описывают взаимодействие разных элементов продукта.

Эта структура сосредоточена только на логике продукта. Визуал можно вынести в UX-мокап и дизайн-макет. 

Заключение

Не всех клиентов устраивает, когда составление ТЗ становится платной услугой. Раньше мы иногда сдавались под их напором и соглашались работать без технического задания. Теперь научились объяснять, насколько важен этот документ.

Благодаря ТЗ команда редко превышает заранее озвученный бюджет. Это может произойти, если клиент по ходу работы захочет добавить фичи, которых в продукте изначально не было. Тогда можно обсудить и согласовать изменения. Когда заказчик ясно видит, на что разработчики тратят каждый рубль, в 99% случаев он остается доволен их подходом.