Частая ситуация: заказчик пишет «нужен удобный современный сайт с личным кабинетом», три подрядчика дают оценки, различающиеся в несколько раз, — и все по-своему правы, потому что каждый понял задачу по-своему. ТЗ нужно, чтобы этого не происходило.
Что должно быть в ТЗ
1. Цель и контекст
Зачем проект, какую проблему решает и как вы поймёте, что он удался. Одна-две фразы о бизнесе и о том, что сейчас работает плохо.
2. Пользователи и сценарии
Кто будет пользоваться и что делает. Пишите сценариями: «клиент выбирает услугу, видит свободное время, записывается и получает подтверждение». Сценарий понятнее списка функций и показывает, как части связаны.
3. Функции с приоритетами
Разделите на обязательные для запуска, желательные и «когда-нибудь». Это позволяет сократить сроки без споров о том, что важнее.
4. Данные и интеграции
- Откуда берутся данные: учётная система, CRM, таблицы.
- Куда должны уходить: заявки, заказы, оплаты.
- Какие внешние сервисы нужны: оплата, доставка, телефония, рассылки.
5. Дизайн и платформы
Есть ли фирменный стиль, на каких устройствах работает продукт, нужны ли мобильные приложения или хватит веб-версии. Примеры того, что нравится и не нравится, полезнее описаний словами.
6. Критерии приёмки
Как проверить, что работа выполнена: список сценариев, которые должны проходить без ошибок, скорость загрузки, поддерживаемые браузеры и устройства. Без этого раздела приёмка превращается в спор о вкусах.
Чего в ТЗ быть не должно
- Общих слов: «удобный», «современный», «быстрый» — без того, как это проверить.
- Выбора технологий, если вы в них не разбираетесь, — это задача исполнителя.
- Всего, что пришло в голову: лишние функции раздувают сроки и цену.
- Противоречий между разделами — их лучше вычитать до отправки.
Кто пишет ТЗ
| Кто пишет | Плюсы | Минусы |
|---|---|---|
| Вы сами | Лучше всех знаете задачу | Легко упустить технические детали |
| Исполнитель | Учтёт технические детали | Зависимость от одного подрядчика |
| Совместно на этапе аналитики | Баланс бизнеса и техники | Нужно отдельное время |
Хорошая практика — описать задачу своими словами и сценариями, а затем доработать ТЗ вместе с исполнителем на отдельном этапе аналитики. Если проект новый и неясно, что важно, начните с первой версии — об этом в статье что такое MVP.
Как проверить готовое ТЗ
- Дайте его прочитать человеку, не знакомому с проектом: понятно ли, что получится?
- Проверьте, что у каждой функции есть способ убедиться, что она работает.
- Отправьте нескольким исполнителям и сравните вопросы — они покажут слабые места.
- Убедитесь, что понятно, кому принадлежат код, доступы и данные.
Как принимать уже готовую работу — в статье сайт под ключ: что входит и как принимать работу. С ТЗ на сайт или приложение можно прийти к нам — оценим и зададим вопросы: разработка приложений, сайты и лендинги.
Частые вопросы
Можно ли начать разработку без ТЗ?
Можно при гибком подходе и оплате по этапам, но тогда объём и цена заранее не фиксируются. Для фиксированной цены нужно ТЗ.
Кто отвечает за ошибки в ТЗ?
Тот, кто его писал и утверждал. Поэтому ТЗ стоит согласовать с исполнителем до начала работ.
Можно ли менять ТЗ по ходу работы?
Можно, но каждое изменение влияет на сроки и цену. Изменения лучше фиксировать письменно.
Нужна такая же реклама для вашего бизнеса?
Разберу нишу, посчитаю бюджет и покажу, из чего сложится цена заявки.
