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