Рабочее техническое задание отвечает на семь вопросов: зачем нужен продукт (бизнес-цель), кто им пользуется, какие сценарии закрывает, какие у него роли и права, с какими системами обменивается данными, что входит в первую очередь и — отдельным списком — что НЕ входит. Писать его можно обычными словами: задача заказчика описать бизнес, а не архитектуру. Техническую часть подрядчик достроит сам, и именно за это он отвечает.
Содержание
Зачем ТЗ, если можно «на словах»
Соблазн пропустить этот этап понятен: кажется, что всё и так ясно, а на бумагу уходит время. Но практика простая: пока задача не записана, у заказчика и исполнителя она разная — и разность обнаруживается на приёмке, когда переделывать дороже всего.
Пока задача не записана, у заказчика и исполнителя она разная — и разность обнаруживается на приёмке, когда переделывать дороже всего.
Второй смысл документа — сравнение предложений. Без ТЗ три подрядчика посчитают три разных продукта, и выбрать по цене невозможно: дешевле окажется тот, кто понял меньше всех.
Семь блоков рабочего ТЗ
Структура, которой достаточно для большинства проектов:
Бизнес-цель
- Что написать
- Какую задачу решает продукт и как вы поймёте, что он работает (заявки, экономия часов, снижение ошибок)
Пользователи
- Что написать
- Кто именно и в каком контексте пользуется — клиент с телефона в дороге и бухгалтер за компьютером требуют разного
Сценарии
- Что написать
- Пошагово, что человек делает от входа до результата. Это самая ценная часть документа
Роли и права
- Что написать
- Кто что видит и меняет — типичный источник скрытой сложности
Интеграции и данные
- Что написать
- С какими системами обмен (1С, CRM, платежи, Kaspi), откуда берутся данные, где источник правды
Первая очередь
- Что написать
- Что обязательно должно быть в первом релизе
Что НЕ входит
- Что написать
- Явный список отложенного — главный защитник бюджета и срока
Пишите бизнесом, а не технологиями
Частая ошибка — пытаться сформулировать задание на языке разработки: «нужна микросервисная архитектура на Kubernetes». Как только заказчик берёт на себя выбор технических решений, он берёт и ответственность за их последствия — а проверить эти решения обычно нечем.
Сравните две формулировки:
Указание технологиями
- «Сделайте REST API для синхронизации»
- Подрядчик выполнит его буквально
Требование бизнесом
- «Остатки на складе должны совпадать на сайте и в 1С в течение 15 минут»
- Из него инженер выведет решение и будет отвечать за результат
Типичные ошибки
Что чаще всего ломает даже старательно написанное задание:
- Всё сразу: сто функций без приоритетов. Оценка получается неподъёмной, а проект — бесконечным.
- Размытые формулировки: «удобно», «современно», «быстро» — их нельзя проверить на приёмке. Заменяйте измеримым: «страница открывается меньше двух секунд».
- Нет списка «не входит» — границы проекта будут рисоваться в споре.
- Скопированное чужое ТЗ: описывает чужой бизнес, а платить за него будете вы.
- Нет владельца решений: если задание согласует отдел из пяти человек без ответственного, каждая итерация удваивается.
- Забытые нефункциональные требования: нагрузка, доступность, требования к хранению данных — всплывают в конце и дорого.
Если ТЗ написать некому
Это нормальная ситуация, особенно когда продукт первый. Есть три пути:
Бриф с тем, что есть
- Что делать
- Принести на бриф идею, примеры чужих продуктов, описание процесса своими словами
- Что получится
- Толковый подрядчик достанет остальное вопросами
Проектирование
- Что делать
- Заказать его отдельным этапом
- Что получится
- Документ, прототип и оценка, с которыми можно идти к любому исполнителю
MVP
- Что делать
- Начать с MVP: сузить задачу до главного сценария, где и описывать особо нечего
- Что получится
- Детали проявятся на реальных пользователях
В InterLAB разбор задачи — часть брифа: приходите с идеей, уходите с картой «первая очередь / вторая очередь» и оценкой после изучения задачи. Даже если делать будете не с нами, документ останется у вас.
