5 подписчиков
Многие проблемы проекта проявляются уже на этапе разработки, хотя их источник часто скрыт в первых строках технического задания.
Техническое задание часто воспринимают как формальность: документ есть, его утвердили, можно начинать разработку. На практике именно от качества ТЗ зависит, насколько прогнозируемыми будут сроки, бюджет и итоговый результат. Чем больше в документе размытых формулировок и недосказанности, тем выше риск, что подрядчик и бизнес по-разному понимают одну и ту же задачу.
Для B2B-проектов это особенно чувствительно. Здесь речь идет не только о красивом интерфейсе или новом канале коммуникации, а о влиянии на реальные процессы: продажи, сервис, аналитику, интеграцию с действующей инфраструктурой. Ошибки в районе ТЗ приводят к тому, что команда разработки делает «технически рабочий» продукт, который хуже встраивается в бизнес-логику компании. В итоге часть функций не используется, какие-то сценарии дублируют ручную работу, а метрики эффективности не меняются.
Типичный пример из практики: в ТЗ подробно описаны экраны и шаги бота, но почти ничего не сказано о том, как заявки будут попадать в CRM, кто будет их обрабатывать и какие поля обязательны для отчета. В процессе внедрения выясняется, что разные отделы по-разному трактуют понятие «новый лид», а часть важной информации не передается в систему вообще. Формально ТЗ выполнено, но для бизнеса это означает дополнительные согласования, переопределение полей, доработки интеграций и сдвиг сроков.
Чтобы снизить такие риски, перед началом разработки стоит проверить ТЗ по чек-листу типичных ошибок:
- в документе описаны фичи, но слабо сформулирована бизнес-цель и ожидаемые показатели: без этого сложно оценивать результат и принимать решения по доработкам;
- большая часть требований написана в духе «сделать удобный интерфейс» или «сделать бота для ответов», без конкретики по сценариям, ролям, данным и ограничениям;
- интеграции с CRM и другими системами упомянуты общими словами, но нет описания, какие данные откуда и куда передаются и на каком этапе;
- не разделены обязательные и желательные требования: в процессе неизбежных компромиссов сложно понять, что действительно критично для запуска;
- не зафиксированы ограничения по нагрузке, отказоустойчивости и окнам обслуживания, хотя для B2B это напрямую влияет на репутацию и SLA;
- отсутствует назначенный владелец продукта со стороны бизнеса, который принимает финальные решения по спорным вопросам;
- нет отдельного блока про сопровождение после запуска: кто отвечает за изменения сценариев, актуализацию контента, реакцию на новые кейсы.
Если при чтении своего ТЗ вы находите хотя бы часть этих пунктов, это хороший повод доработать документ до старта, а не в середине спринта. Это экономит время команды, снижает количество непредвиденных задач и помогает выстроить более прозрачный диалог с подрядчиком: обе стороны опираются на общий, достаточно конкретный контур.
Практический шаг на сейчас может быть простым. Возьмите актуальное ТЗ по ближайшему проекту, пройдитесь по чек-листу и отметьте, где формулировки требуют уточнения. Затем вынесите эти вопросы на короткую рабочую сессию с ответственными за бизнес-процесс и ИТ: цель не переписать документ с нуля, а закрыть пробелы, которые могут вырасти в задержки или лишние расходы.
Если вы недавно запускали цифровой проект, вспомните, на каком этапе стали понятны «дыры» в ТЗ — на старте, в середине разработки или уже после запуска.
Если хотите спокойно разобрать ваше текущее ТЗ и понять, где оно может создавать риски по срокам и результату, напишите в Telegram @sergio_4e — посмотрим на документ глазами архитектора и бизнеса одновременно.
3 минуты
10 марта