Для многих чёткая постановка задачи в виде Технического Задания (ТЗ) и Бизнес требований (БТ) является самым ненавистным, трудозатратным и бессмысленным занятием в работе.
⠀
Однако со временем, приходит осознание, что без этих документов не докажешь исполнителю:
- в чём он не прав;
- не передашь другому человеку тайное знание процесса;
- а причину возникновения проблем искать сложнее.
⠀
Приведённый ниже порядок, сформулирован одним из наших экспертов на основании многолетнего опыта ведения разработок и постоянно подтверждается на практике.
⠀
1. НЕОБХОДИМО ОПРЕДЕЛИТЬ ТИП ДОКУМЕНТА: БТ ИЛИ ТЗ.
БТ содержат желаемый результат, как его должен увидеть и ИСПОЛЬЗОВАТЬ бизнес.
ТЗ описывает методы, инструменты и источники, которыми будет пользоваться разработчик в процессе реализации задачи, поставленной бизнесом.
⠀
2. ОГЛАВЛЕНИЕ.
Начинать нужно с формирования структуры документа «в крупную клетку», при чём логическая составляющая имеет приоритет над хронологической.
Далее создаются подразделы, в т.ч. из расчёта на ссылки внутри документа.
⠀
3. УПРОЩЕНИЕ.
Не стесняйтесь пользоваться аббревиатурами и сносками. Лучше не прерывая повествование сделать сноску с пояснением, чем засорять тело документа авторскими ремарками.
Аббревиатуры и устоявшиеся сокращения нужно обязательно расшифровывать для целей конкретного документа. Например: «AR» для рисков – Approval rate, а для колл центра Abandonment rate, т.е. доля согласованных заявок и потерянных звонков соответственно.
⠀
4. НАПОЛНЕНИЕ.
Если предыдущие пункты были выполнены дОлжным образом, с написанием текста проблем возникнуть не должно. Конечный результат будет зависеть технических и/или литературных навыков автора.
⠀
5. ЛАЙФХАК.
По завершению написания и пары собственных перечитываний, найдите человека, максимально далёкого от темы документа (в первую очередь для БТ) и попросите вычитать, задать вопросы.
⠀
Будьте уверены, то что вы считаете очевидным, для многих окажется спорным или явно упущенной важной деталью. Тот же Approval rate можно считать десятком разных способов.
