Техническое задание на разработку: как составить, чтобы получить то, что нужно

Почти каждый спор «нам сделали не то, что мы просили» упирается в одно и то же — в момент подписания договора обе стороны понимали задачу по-разному, и ни у кого не было документа, к которому можно апеллировать. Хорошее техническое задание нужно не для бюрократии, а именно для этого: чтобы «сделали не то» просто не могло случиться незаметно.

Что должно быть в ТЗ

Цель проекта, а не список хотелок

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

Кто будет пользоваться

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

Сценарии использования

Самая полезная часть документа. Опишите обычным языком, шаг за шагом: «клиент открывает каталог → выбирает товар → добавляет в корзину → оформляет заказ → получает письмо». Отдельно — что происходит, когда что-то идёт не так: товара нет на складе, оплата не прошла, данные введены неверно.

Что не входит в проект

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

Технические требования и ограничения

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

Типичные ошибки

Слишком общее описание. «Сделать современный удобный сайт» — это не требование, а пожелание. Под него подойдёт что угодно, а значит, спорить о результате будет бессмысленно.

Слишком детальное описание реализации. Обратная крайность: заказчик расписывает, какие использовать технологии и как устроить базу данных. Если вы не технический специалист, это только связывает руки подрядчику. Ваша зона — что система должна делать; как — зона исполнителя.

Отсутствие приоритетов. Когда все требования одинаково важны, при нехватке времени режут не то. Помечайте: без чего запуск невозможен, что желательно, что можно во второй этап.

Игнорирование граничных случаев. Что происходит при пустом списке, при отмене заказа, при одновременном редактировании двумя пользователями? Именно на этих местах проекты потом переделывают.

Проверочный вопрос к готовому ТЗ: сможет ли человек, не участвовавший в обсуждениях, прочитать документ и сделать по нему систему так, как вы её представляете? Если для понимания нужно «ещё созвониться и объяснить» — документ не готов.

Если вы не технический специалист

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

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

ТЗ — живой документ

Требования почти всегда уточняются в процессе — это нормально и не означает, что планирование было плохим. Важно другое: изменения должны фиксироваться письменно, с пересчётом сроков и стоимости, а не оседать в устных договорённостях. Тогда к финалу проекта у обеих сторон одинаковая картина того, что было согласовано.

И последнее: время, потраченное на нормальное ТЗ, почти всегда меньше времени, которое уходит на переделку из-за его отсутствия.