Когда задача становится актуальной
- Оценки исполнителей невозможно сравнить по составу работ.
- Задача описана названиями систем без правил взаимодействия.
- В процессе разработки постоянно открываются новые исключения.
- Приёмка сводится к проверке наличия экранов.
Определить границы и ожидаемое поведение
В техническом задании сначала описывается результат для пользователей и бизнеса. Для каждой роли указываются действия и условия их выполнения. Затем устанавливаются границы: какие операции входят в текущий проект, что выполняют действующие системы и какие зависимости остаются у заказчика или внешних поставщиков.
Важные понятия получают единое определение. Заказ, бронирование, платёж и право доступа могут иметь разный жизненный цикл. Если объединить их в один статус, изменения и ошибки станут неразличимыми. Поэтому требования объясняют, какие объекты существуют, как они связаны и какое событие подтверждает изменение каждого из них.
Описать данные, ограничения и приёмку
Для интеграции нужны состав полей, источник подтверждённых сведений, направление обмена и реакция на недоступность. Проверяются возможности API, права и ограничения действующей конфигурации. Требование должно отделять известную возможность от зависимости, которую предстоит подтвердить до реализации.
Сценарии приёмки формулируются через исходное состояние, действие и наблюдаемый результат. Кроме обычного пути включаются повторная отправка события, неполные данные, изменение условий и отсутствие доступа у роли. Так качество оценивается по поведению системы, а не только по визуальному соответствию макета.
| Раздел требований | Что фиксировать | Пример проверки |
|---|---|---|
| Роли | Разрешённые действия и видимость | Сотрудник видит только нужные ему заказы |
| Данные | Обязательные поля и источник | Заказ связан с подтверждённой оплатой |
| Интеграция | Событие, обмен и реакция на ошибку | Повторное событие не создаёт дубль |
| Приёмка | Начальное состояние и результат | Отмена изменяет связанные права |
Пример требования к оплате бронирования
Клиент выбирает свободное время, создаёт бронирование и переходит к оплате. Требование определяет, сколько и при каких условиях резервируется ресурс согласно правилам бизнеса, какое подтверждение платежа принимается и что происходит после его получения.
Исключение — платёжное событие приходит повторно или после изменения брони. Система должна сопоставить его с нужным объектом, сохранить историю и выполнить согласованный сценарий. Для позднего платежа заранее определяется роль, принимающая решение. ТЗ не заменяет правила бизнеса: оно делает их явными и описывает, как проверить их реализацию без использования реальных платёжных данных.
Управлять изменениями после согласования
Даже подробное ТЗ может уточняться. Для изменений нужен порядок: какое требование затронуто, почему возникла новая потребность и как она влияет на данные, интерфейсы и приёмку. Небольшое изменение поля иногда меняет несколько связанных сценариев, поэтому оценивать его следует в контексте модели.
Документ должен быть пригоден для работы исполнителя: единые термины, ссылки между требованиями и доступные примеры. Объём определяется сложностью задачи, а не желаемым количеством страниц. После согласования становится проще оценить разработку по этапам и проверить, что каждый этап завершает определённый рабочий сценарий, а не только набор технических задач.
Что получит компания
- Границы проекта и описание пользовательских сценариев.
- Модель объектов, данных, ролей и состояний.
- Требования к интеграциям и обработке ошибок.
- Сценарии приёмки и необходимые тестовые данные.
- Порядок уточнения и согласования изменений.
Что подготовить к обсуждению
- Цель проекта и согласованные бизнес-правила.
- Перечень систем, конфигураций и доступной документации.
- Обезличенные примеры объектов и операций.
- Описание ролей, ограничений и ожидаемой нагрузки.
Вопросы о проекте
Можно ли заказать только техническое задание?
Да, если нужен самостоятельный результат для выбора реализации или исполнителя. При этом исходная бизнес-логика должна быть согласована либо включена в предмет работы. Нерешённые организационные вопросы нельзя надёжно заменить техническими формулировками.
Нужно ли ТЗ при поэтапной разработке?
Да, но глубина требований может соответствовать выбранному этапу. Общая модель и связи фиксируются заранее, а детали следующих частей уточняются по мере готовности. Это позволяет менять приоритеты без потери целостности решения.
От чего зависит стоимость подготовки?
От числа ролей, сценариев, систем и неопределённых зависимостей. Наличие проверенной модели процесса уменьшает объём предварительного исследования. Особое внимание требуется внешним интеграциям и исключениям, которые влияют на приёмку.