Техническое задание на разработку ПО отвечает на четыре вопроса: что строим, для кого, как проверить результат и что в проект не входит. Составляют его по шагам: цель, пользователи и сценарии, функции с критериями приёмки, интеграции, нефункциональные требования, границы проекта, порядок изменений. Готовое ТЗ подписывают как приложение к договору.
Хорошее ТЗ нужно агентству больше, чем клиенту. По нему вы даёте фикс, принимаете работу и спорите о доработках.
Что должно быть в ТЗ на разработку ПО
Минимальный набор разделов для коммерческого проекта:
| Раздел | Что внутри | Зачем агентству |
|---|---|---|
| Цель | Задача бизнеса и признак успеха | Понять, что важно, когда приходится резать объём |
| Роли и сценарии | Кто пользуется системой и что делает | Основа для оценки и тестов |
| Функции | Список с критериями приёмки | По нему подписывают акт |
| Интеграции и данные | Внешние API, миграция, форматы | Самая частая причина перерасхода |
| Нефункциональные требования | Нагрузка, безопасность, устройства | Без них клиент потом попросит «чтобы не тормозило» |
| Что не входит | Явный список исключений | Защита от «это же очевидно» |
| Изменения и приёмка | Порядок, сроки, ответственные | Деньги за доработки |
Как составить техническое задание: восемь шагов
- Зафиксируйте цель. Два-три предложения: какую задачу решает система и как клиент поймёт, что проект удался.
- Опишите пользователей и сценарии. Роли (покупатель, менеджер, администратор) и для каждой основные сценарии: кто, что делает, какой результат получает.
- Перечислите функции с критериями приёмки. «Фильтр по цене» плохо проверяется. «Фильтр по цене от и до, результат обновляется без перезагрузки страницы» проверяется.
- Опишите интеграции и данные. Какие внешние системы, есть ли у них документация и тестовая среда, кто даёт доступы, какие данные переносятся и в каком формате.
- Запишите нефункциональные требования. Нагрузка, время ответа, браузеры и устройства, безопасность, хостинг, требования к хранению персональных данных.
- Перечислите, что в проект не входит. Наполнение контентом, перенос старых данных, поддержка после запуска, SEO, тексты.
- Опишите порядок изменений и приёмки. Как клиент подаёт изменения, кто их оценивает, как меняются цена и срок, кто подписывает акт и за сколько дней.
- Подпишите ТЗ как приложение к договору. Пока ТЗ не подписано, это переписка. Обязательством сторон оно становится после подписи.
Нужен ли ГОСТ для технического задания
Для коммерческого проекта в РФ нет. Документы национальной системы стандартизации применяются добровольно (ч. 1 ст. 26 Федерального закона № 162-ФЗ «О стандартизации в Российской Федерации»).
Структура ТЗ для автоматизированных систем описана в ГОСТ 34.602-2020. Эта редакция заменила ГОСТ 34.602-89. Его разделы полезно пролистать как чек-лист, даже если вы пишете ТЗ в свободной форме.
- Пишите по ГОСТ, если этого требует заказчик (часто госсектор и крупные компании) или договор на него ссылается.
- Пишите в свободной форме, если клиент коммерческий и ему нужен короткий понятный документ.
Кто пишет ТЗ и кто за него платит
По договору подряда работу выполняют по заданию заказчика (ст. 702 ГК РФ). На практике клиент приходит с идеей и парой страниц текста. Превратить их в ТЗ может только тот, кто понимает разработку, то есть агентство.
Варианты, как это оформить:
- Бесплатно на пресейле. Работает для небольших проектов. На крупных вы рискуете отдать неделю аналитика и не получить контракт.
- Платный этап проработки. Отдельный договор или первый этап на фиксе. Результат - ТЗ, прототип и оценка. Клиент может унести их к другому подрядчику, и это честно: он за них заплатил.
- ТЗ внутри T&M. Аналитика оплачивается по часам вместе с разработкой.
Как ТЗ влияет на оценку и цену: стоимость разработки ПО.
Как ТЗ связано с договором и приёмкой
Заказчик обязан осмотреть и принять работу в порядке и сроки, которые указаны в договоре. Недостатки, которые он нашёл при приёмке, нужно оговорить в акте (п. 1 и 2 ст. 720 ГК РФ). Если заказчик принял работу без проверки, на явные недостатки он потом ссылаться не может, если договор не говорит иное (п. 3 ст. 720 ГК РФ).
Отсюда три правила для ТЗ:
- критерии приёмки пишите так, чтобы их можно было проверить по чек-листу;
- срок на приёмку и порядок подписания акта указывайте в договоре или ТЗ;
- изменения требований оформляйте письменно, с новой ценой и сроком.
Как это прописать в договоре: договор на разработку ПО.
Какие ошибки в ТЗ обходятся агентству дороже всего
- Нет раздела «что не входит». Клиент считает, что перенос данных и тексты включены.
- Функции без критериев. «Удобный личный кабинет» нельзя принять или не принять.
- Интеграции описаны одной строкой. «Интеграция с 1С» может занять и день, и месяц.
- Нет порядка изменений. Любая новая хотелка клиента становится спором о том, входит ли она в цену.
- ТЗ не подписано. Документ в общей папке, который никто не утвердил, ничего не доказывает при приёмке.
- Ничего о правах на код. ТЗ описывает, что строим. Договор описывает, чьё это будет потом.