Техническое задание начинается не с длинного списка экранов. Его задача — дать бизнесу и команде одинаковое понимание того, что строится, для кого, в каких границах и как будет принято. Если идея описана только словами «сделать удобно» или «добавить автоматизацию», разработчик вынужден угадывать правила, а заказчик — оценивать результат по разным ожиданиям.
Хороший документ не пытается предсказать каждую строку кода. Он фиксирует пользовательские сценарии, данные, ограничения, интеграции, критерии приёмки и открытые вопросы. Остальное можно уточнять итеративно, сохраняя видимую историю решений.
Шаг 1. Сформулируйте проблему и границу решения
Начните с текущего процесса: кто выполняет работу сейчас, какие инструменты использует, где возникают задержки и что считается ошибкой. Затем запишите желаемый результат и то, что сознательно не входит в первую версию. Граница важнее красивого названия продукта: она позволяет понять, где заканчивается ответственность команды и начинаются внешние условия.
- проблема и её последствия для бизнеса или пользователя;
- целевые роли и контекст использования;
- основной результат первой версии;
- что не входит в scope;
- ограничения по данным, платформам, срокам и доступам.
Нужна рабочая оценка? Опишите продукт, пользователей и ограничения в контактной форме — Paladin Engineering поможет отделить обязательное от желательного и собрать проверяемую модель бюджета.
Шаг 2. Описывайте сценарии, а не только функции
Функция «уведомления» ничего не говорит о событии, получателе, канале и повторной отправке. Сценарий отвечает на эти вопросы: менеджер меняет статус заявки, клиент получает сообщение, система сохраняет факт отправки, а при ошибке показывает задачу ответственному. Такой формат помогает увидеть не только интерфейс, но и правила, интеграции и исключения.
| Элемент сценария | Что зафиксировать |
|---|---|
| Роль | кто выполняет действие и какие права ему нужны |
| Триггер | что запускает процесс |
| Основной поток | какие шаги проходят до результата |
| Исключения | что происходит при ошибке, отмене или неполных данных |
| Результат | какая запись, нотификация или смена статуса появляется |
Для сложного процесса полезно пройти путь от начала до конца, включая ручные и офлайн-операции. GOV.UK Service Manual в discovery рекомендует смотреть на весь user journey и контекст пользователя; для коммерческого проекта это переводится в практический вопрос: не потеряли ли мы шаг, который находится за пределами будущего интерфейса, но влияет на результат.
Шаг 3. Разделите требования по типам
Не смешивайте в одном списке обязательное поведение, пожелания к интерфейсу и технические решения. Функциональное требование описывает, что система делает; нефункциональное — с какими свойствами; ограничение — в каких рамках это должно происходить. Такое разделение позволяет обсуждать приоритеты, не споря о вкусе.
- функциональные: создание заявки, согласование, поиск, экспорт;
- нефункциональные: доступность, производительность, аудит, поддерживаемые устройства;
- данные: поля, обязательность, справочники, жизненный цикл;
- интеграции: источник, направление обмена, авторизация, ошибки;
- организационные: роли согласования, владельцы данных, процесс релиза.
Шаг 4. Превратите пожелания в критерии приёмки
Критерий приёмки — это наблюдаемое условие, по которому можно решить, выполнена ли история. «Система работает быстро» нельзя проверить без контекста. «При заполненных обязательных полях заявка получает номер и появляется в списке автора» уже задаёт событие и результат; для performance, безопасности и доступности нужны отдельные измеримые условия.
| Слабая формулировка | Проверяемая формулировка |
|---|---|
| Сделать удобный поиск | Пользователь ищет по номеру и статусу, видит только разрешённые записи и получает понятный результат при отсутствии совпадений |
| Добавить интеграцию | При подтверждении заказа система отправляет согласованный набор полей, сохраняет идентификатор ответа и показывает ошибку при недоступности API |
| Защитить доступ | Пользователь видит только разрешённые объекты; смена роли вступает в силу по описанному правилу и фиксируется в журнале |
В agile-контрактовании acceptance criteria согласуются между владельцем продукта и командой. Для заказчика это означает: критерии должны появиться до завершения работы, а не впервые на демонстрации. Они защищают обе стороны от ситуации, когда одна и та же фраза означает разные результаты.
Обсудить следующий шаг можно в Telegram или через контактную форму: команда Paladin Engineering разложит идею на сценарии, данные, интеграции и критерии приёмки.
Шаг 5. Опишите данные и интеграции
Большинство неожиданностей скрывается не в макетах, а в данных. Для каждой сущности укажите владельца, обязательные поля, идентификатор, статусы, срок хранения и допустимые переходы. Для интеграции зафиксируйте систему-источник, направление обмена, частоту, авторизацию, повторный запрос, таймаут и владельца доступа.
- какие данные создаёт ваша система, а какие только читает;
- какой идентификатор связывает записи;
- что делать при дубле, пропуске или конфликте;
- как выглядит тестовый контур;
- кто отвечает за изменение внешнего API.
Шаг 6. Добавьте security и эксплуатационные требования
Техническое задание должно показывать, как продукт будет жить после разработки. Минимальный набор: роли и права, журналирование критичных действий, резервное копирование, обработка ошибок, мониторинг, порядок релиза и способ отката. NIST SSDF полезен как каркас вопросов к secure development lifecycle: требования безопасности должны быть частью работы, а не только финальной проверкой.
Не все значения нужно выдумывать заранее. Если показатель неизвестен, обозначьте его как открытый вопрос, назначьте владельца решения и укажите, на каком этапе он влияет на оценку. Непроверенное предположение должно быть заметно в документе, иначе оно превращается в скрытый scope.
Что не стоит включать в первую версию ТЗ
Чрезмерная детализация тоже создаёт риск. Если заказчик заранее описывает внутреннюю реализацию, не проверив пользовательскую потребность, документ становится тяжёлым и быстро устаревает. Лучше фиксировать результат, ограничения и критерии, а архитектурные решения принимать на основании discovery и технического анализа.
- неподтверждённые цифры нагрузки;
- конкретный фреймворк без причины и критериев выбора;
- дублирующиеся формулировки в разных разделах;
- все возможные будущие функции как обязательные;
- критерии «красиво», «быстро» и «удобно» без измеримого контекста.
Частые вопросы о техническом задании
Нужно ли писать ТЗ до выбора подрядчика?
Полный документ не всегда нужен. Для выбора команды достаточно структурированного brief с проблемой, пользователями, сценариями, ограничениями и вопросами. Детализация растёт вместе с пониманием решения и выбранным форматом работы.
Кто должен согласовывать требования?
Владелец продукта, представители ключевых ролей, технический специалист и ответственные за данные или безопасность, если они влияют на результат. Один автор не заменяет владельцев решений.
Можно ли заменить ТЗ прототипом?
Нет. Прототип показывает часть поведения и интерфейса, но не заменяет права, данные, интеграции, ошибки, эксплуатацию и критерии приёмки. Прототип и ТЗ дополняют друг друга.
Как обрабатывать изменения после согласования?
Фиксируйте запрос, причину, влияние на сценарии, сроки, бюджет и риски. Небольшие уточнения могут входить в итерацию, а новое обязательное поведение должно менять согласованную границу.
Сколько страниц должно быть в ТЗ?
У документа нет полезного универсального объёма. Он должен быть достаточно подробным для оценки и приёмки, но не повторять очевидное и не прятать открытые вопросы под формальными формулировками.
Что делать, если бизнес сам не знает всех требований?
Это нормальная причина начать с discovery. Исследуйте пользователей и процесс, соберите варианты, проверьте самые рискованные предположения и только потом фиксируйте объём первой реализации.
Комментарии