Как писать технические задания, которые действительно работают

«Мы имели в виду другое» — эта фраза в конце проекта обходится очень дорого. Причина почти всегда одна: плохое техническое задание.

За восемь лет работы агентством мы переписывали подход к ТЗ трижды. Вот где мы сейчас.

Почему ТЗ не работают

Типичная история: клиент подписывает ТЗ, не читая. Команда пишет ТЗ, не думая о читателе. Через два месяца — взаимное разочарование.

Корень проблемы: ТЗ пишут как юридический документ, а не как инструмент коммуникации.

Хорошее ТЗ отвечает на вопросы «что» и «зачем», а не «как». «Как» — это работа команды. «Что» и «зачем» — это то, что нужно согласовать.

Структура ТЗ, которая работает

1. Контекст и цели (1 страница)

Прежде чем описывать функциональность — объясните, зачем это вообще делается. Какую проблему решает проект? Какой бизнес-результат ожидается?

Этот раздел заставляет всех участников убедиться, что они понимают задачу одинаково.

2. Пользователи и сценарии

Кто будет пользоваться результатом? Опишите 2-3 ключевых персонажа и их основные сценарии использования.

Это не UX-исследование, а инструмент приоритизации. Когда непонятно, включать ли фичу — возвращайтесь к сценариям.

3. Функциональные требования

Структурируйте по модулям или экранам. Для каждого требования пишите:

• Что пользователь должен мочь сделать
• Ограничения и исключения
• Критерии приёмки

Пример плохого требования: «Форма обратной связи»

Пример хорошего: «Пользователь может отправить запрос, указав имя, email и текст сообщения. После отправки видит подтверждение и получает копию на email. Администратор получает уведомление в течение 5 минут.»

4. Вне рамок проекта

Явно напишите, что НЕ входит в проект. Это снижает количество споров про «а я думал, это само собой подразумевается».

5. Технические ограничения и интеграции

Это для команды, не для клиента. Но должно быть в документе: с какими системами интегрируемся, какие стандарты соблюдаем, какие ограничения учитываем.

Правила хорошего ТЗ

Пишите на языке пользователя, не технаря. Если клиент не понимает документ — он подпишет его не читая. Это риск для всех.

Используйте мокапы или вайрфреймы. Тысяча слов не заменит одну схему экрана. Мы всегда прикладываем хотя бы грубые скетчи.

Избегайте слов-паразитов. «Удобный», «современный», «интуитивный» — не требования. Это субъективные оценки без критериев измерения.

Добавляйте примеры. «Выпадающий список» — ок. «Выпадающий список, как на booking.com при выборе города» — гораздо лучше.

Главное: ТЗ — это живой документ

Требования меняются. Это нормально. Важно, чтобы изменения фиксировались в документе с датой и обоснованием.

Мы ведём лог изменений в конце ТЗ. Это защищает и клиента, и команду — всегда можно вернуться и понять, почему приняли то или иное решение.