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

Зачем вообще нужно техническое задание

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

На рынке Узбекистана это особенно болезненно. Значительная часть заказов на разработку идёт от компаний, у которых нет своего IT-отдела: торговля, логистика, частные клиники, образовательные центры, финтех-стартапы. Они хорошо знают свой бизнес, но не умеют формулировать требования к софту. В результате договариваются «на словах», а потом спорят, входила ли интеграция с Payme и Click в первоначальную смету.

ТЗ решает три задачи сразу: фиксирует объём работ (а значит и бюджет), даёт критерии приёмки и защищает обе стороны юридически. Это приложение к договору, на которое можно ссылаться при разногласиях.

Что должно быть в структуре ТЗ

Хорошее ТЗ не обязано быть толстым. Оно должно быть полным и однозначным. Минимальный рабочий состав выглядит так:

• Цель и контекст проекта. Какую бизнес-задачу решаем, кто пользователи, что считается успехом. Без этого подрядчик не сможет предлагать разумные альтернативы.
• Роли и права доступа. Кто такие администратор, оператор, клиент, что каждому из них можно и нельзя.
• Функциональные требования. Описание экранов и сценариев: что происходит при нажатии, какие поля обязательны, какие проверки. Лучше всего — в формате пользовательских сценариев.
• Нефункциональные требования. Нагрузка, скорость отклика, безопасность, языки интерфейса (для Узбекистана почти всегда узбекский, русский, часто английский), требования к хостингу.
• Интеграции. Платёжные системы (Payme, Click, Uzum), SMS-шлюзы (Eskiz, Play Mobile), 1С, Soliq/ЭСФ, Telegram. Указать версии API и кто предоставляет доступы.
• Дизайн и брендбук. Есть ли готовые макеты, фирстиль, или это тоже часть работ.
• Этапы, сроки и критерии приёмки. Что считается готовым результатом каждого этапа.

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

Распространённое заблуждение: «ТЗ должен написать программист». На практике ответственность делится. Бизнес-сторона отвечает за что и зачем, техническая сторона — за как.

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

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

Частые ошибки в техзаданиях

За годы работы повторяются одни и те же проблемы:

• Размытые формулировки. «Удобный интерфейс», «быстрая работа», «современный дизайн» — это не требования, их нельзя проверить. Заменяйте на измеримое: «список из 1000 записей открывается до 2 секунд».
• Отсутствие негативных сценариев. Описан только идеальный путь, а что делать при ошибке оплаты, отмене заказа, дубликате — не сказано. Именно тут рождается большинство багов и доработок.
• Нет приоритетов. Когда всё «критично важно», бюджет и сроки взрываются. Разделяйте на обязательное (MVP) и желательное.
• Игнор локальных реалий. Забыли про многоязычность, про особенности местных платёжек, про ЭСФ и отчётность для Soliq. Это всплывает в конце и срывает сроки.
• ТЗ без версионирования. Требования меняются — это нормально. Но изменения должны фиксироваться письменно как дополнения, иначе спор о доплате неизбежен.

Как принимать результат по ТЗ

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

Рабочий порядок приёмки:

• Подрядчик разворачивает версию на тестовом стенде с доступом для заказчика.
• Заказчик проходит по сценариям из ТЗ — по каждому пункту фиксирует «принято / замечание».
• Замечания делятся на баги (несоответствие ТЗ — исправляет подрядчик в рамках сметы) и новые хотелки (изменение требований — оформляется как доплата).
• После закрытия багов подписывается акт по этапу.

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