Как составить техническое задание на разработку

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

Что обязательно должно быть

Цель и границы. Какую проблему решаем и чего система точно не делает. Раздел «не входит в объём» экономит больше нервов, чем все остальные.
Процесс «как есть». Кто, что, как часто и сколько времени тратит сейчас. С цифрами: сто заявок в день, три минуты на заявку.
Процесс «как будет». Те же шаги после внедрения, с указанием, что делает система, а что человек.
Роли и права. Кто что видит и что может менять.
Данные. Какие сущности, откуда берутся, где хранятся, сколько их и как быстро растут.
Интеграции. С какими системами, в какую сторону, каким способом, кто владелец каждой системы.
Нефункциональные требования. Нагрузка, время отклика, требования к контуру, резервное копирование, журналирование.
Критерии приёмки. Список сценариев с ожидаемым результатом по каждому.

Про критерии приёмки отдельно

Это самый важный и самый пропускаемый раздел. Формулировка «система должна работать быстро» на приёмке не значит ничего. Формулировка «список из десяти тысяч записей открывается не дольше двух секунд на восьми одновременных пользователях» значит всё.

Если критерий нельзя проверить в присутствии двух человек за десять минут, это не критерий, а пожелание.

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

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

Кто должен писать

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

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

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

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

Частые вопросы

Насколько подробным должно быть ТЗ?

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

Можно ли начать без ТЗ?

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

Кто утверждает изменения ТЗ?

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