Как составить техническое задание на разработку ПО
Зачем вообще нужно техническое задание
Техническое задание (ТЗ) — это документ, который превращает идею заказчика в проверяемый набор требований к продукту. Без него стороны почти всегда понимают проект по-разному: заказчик держит в голове одну картину, подрядчик строит другую, а на демонстрации выясняется, что половина ожидаемого функционала «подразумевалась», но нигде не зафиксирована.
На рынке Узбекистана это особенно болезненно. Значительная часть заказов на разработку идёт от компаний, у которых нет своего IT-отдела: торговля, логистика, частные клиники, образовательные центры, финтех-стартапы. Они хорошо знают свой бизнес, но не умеют формулировать требования к софту. В результате договариваются «на словах», а потом спорят, входила ли интеграция с Payme и Click в первоначальную смету.
ТЗ решает три задачи сразу: фиксирует объём работ (а значит и бюджет), даёт критерии приёмки и защищает обе стороны юридически. Это приложение к договору, на которое можно ссылаться при разногласиях.
Что должно быть в структуре ТЗ
Хорошее ТЗ не обязано быть толстым. Оно должно быть полным и однозначным. Минимальный рабочий состав выглядит так:
- Цель и контекст проекта. Какую бизнес-задачу решаем, кто пользователи, что считается успехом. Без этого подрядчик не сможет предлагать разумные альтернативы.
- Роли и права доступа. Кто такие администратор, оператор, клиент, что каждому из них можно и нельзя.
- Функциональные требования. Описание экранов и сценариев: что происходит при нажатии, какие поля обязательны, какие проверки. Лучше всего — в формате пользовательских сценариев.
- Нефункциональные требования. Нагрузка, скорость отклика, безопасность, языки интерфейса (для Узбекистана почти всегда узбекский, русский, часто английский), требования к хостингу.
- Интеграции. Платёжные системы (Payme, Click, Uzum), SMS-шлюзы (Eskiz, Play Mobile), 1С, Soliq/ЭСФ, Telegram. Указать версии API и кто предоставляет доступы.
- Дизайн и брендбук. Есть ли готовые макеты, фирстиль, или это тоже часть работ.
- Этапы, сроки и критерии приёмки. Что считается готовым результатом каждого этапа.
Важный выбор: насколько детально описывать. Для фиксированной цены (fixed price) ТЗ должно быть максимально подробным — подрядчик закладывает в смету все риски неопределённости. Для работы по времени (time & material) достаточно описать видение и приоритеты, а детали уточнять по ходу спринтов. Выбор модели определяет глубину документа.
Кто пишет техническое задание
Распространённое заблуждение: «ТЗ должен написать программист». На практике ответственность делится. Бизнес-сторона отвечает за что и зачем, техническая сторона — за как.
Идеальный вариант: заказчик готовит бизнес-требования (цели, процессы, ограничения), а аналитик или проектный менеджер подрядчика превращает их в техническое задание с экранами, сценариями и интеграциями. Затем документ согласуется заказчиком до подписи.
Если у заказчика нет внутренней экспертизы, разумно заказать ТЗ как отдельную платную услугу — отдельным небольшим этапом до основной разработки. Это дешевле, чем переделывать готовый продукт, и даёт документ, с которым можно идти и к другим подрядчикам для сравнения цен.
Частая ошибка: заказчик просит «сделать как у конкурента» и присылает ссылку вместо требований. Чужое приложение — это результат, а не спецификация: вы не видите его логику ролей, обработку ошибок, граничные случаи. Скриншот экрана не объясняет, что происходит при пустом списке, при потере связи или при дубле платежа.
Частые ошибки в техзаданиях
За годы работы повторяются одни и те же проблемы:
- Размытые формулировки. «Удобный интерфейс», «быстрая работа», «современный дизайн» — это не требования, их нельзя проверить. Заменяйте на измеримое: «список из 1000 записей открывается до 2 секунд».
- Отсутствие негативных сценариев. Описан только идеальный путь, а что делать при ошибке оплаты, отмене заказа, дубликате — не сказано. Именно тут рождается большинство багов и доработок.
- Нет приоритетов. Когда всё «критично важно», бюджет и сроки взрываются. Разделяйте на обязательное (MVP) и желательное.
- Игнор локальных реалий. Забыли про многоязычность, про особенности местных платёжек, про ЭСФ и отчётность для Soliq. Это всплывает в конце и срывает сроки.
- ТЗ без версионирования. Требования меняются — это нормально. Но изменения должны фиксироваться письменно как дополнения, иначе спор о доплате неизбежен.
Как принимать результат по ТЗ
Приёмка — это не «посмотрел и вроде работает». Это сверка готового продукта с критериями из ТЗ. Чтобы она прошла спокойно, критерии приёмки нужно прописать заранее, ещё на этапе согласования документа.
Рабочий порядок приёмки:
- Подрядчик разворачивает версию на тестовом стенде с доступом для заказчика.
- Заказчик проходит по сценариям из ТЗ — по каждому пункту фиксирует «принято / замечание».
- Замечания делятся на баги (несоответствие ТЗ — исправляет подрядчик в рамках сметы) и новые хотелки (изменение требований — оформляется как доплата).
- После закрытия багов подписывается акт по этапу.
Замечание против новой функции. Если поведение противоречит тому, что написано в ТЗ — это баг, и его правят бесплатно. Если в ТЗ об этом ничего не было, а заказчик хочет добавить — это новая работа, и она оплачивается отдельно. Чёткое ТЗ делает эту границу очевидной и убирает конфликты.
Именно поэтому ТЗ выгодно обеим сторонам. Заказчик защищён от «не доделали», подрядчик — от бесконечных бесплатных правок под расширяющиеся ожидания.
Вывод
Техническое задание — это не бюрократия, а инструмент управления бюджетом, сроками и ожиданиями. Чем точнее зафиксированы требования, интеграции и критерии приёмки, тем меньше сюрпризов на финише. Хорошее ТЗ окупается тем, что не приходится переделывать готовый продукт. Если вы планируете разработку и хотите, чтобы требования были собраны грамотно и с учётом реалий рынка Узбекистана, команда OneDev поможет составить ТЗ и оценить проект — напишите нам, обсудим вашу задачу.