Как делать ТЗ, чтобы результат не был ХЗ

Это выступление посвящено опыту взаимодействия заказчиков и разработчиков в проектах, связанных с внедрением и разработкой IT-решений. Цель — показать типовые точки недопонимания между сторонами и объяснить, почему формализация требований и техническое задание являются не бюрократией, а инструментом достижения качественного результата и взаимного удовлетворения от проекта.

Разные цели и разный контекст заказчика и разработчика

На старте проекта заказчик и разработчик почти всегда находятся в разных контекстах. У заказчика есть бизнес-цели, внутренние ограничения и причины срочности, о которых он часто не говорит напрямую. Разработчик же видит только внешнюю формулировку задачи и вынужден догадываться о настоящих причинах требований.

Часто заказчик формулирует запрос в виде готового технического решения, хотя на самом деле за ним скрывается бизнес-проблема. В таких ситуациях ключевая задача разработчика — вытащить из заказчика реальные цели и критерии успеха, а не просто реализовать озвученный набор технологий.

Признаки неясного запроса:

• «Нужно, чтобы всё работало хорошо»
• «Нам нужен конкретный компонент, потому что так делают другие»
• «К сроку, без объяснения причин»

Без прояснения этих моментов невозможно объективно оценить результат проекта.

Роль технического задания как точки синхронизации

Техническое задание — это не формальный документ «для галочки» и не обязательно ГОСТ. Его основная функция — синхронизировать понимание результата между всеми участниками проекта.

Формат ТЗ может быть любым, но в нём обязательно должно быть отражено:

• что именно должно быть реализовано;
• какие задачи заказчика это решает;
• по каким критериям стороны поймут, что результат достигнут.

Важно понимать, что разработчик отвечает за техническое решение, а заказчик — за формулировку бизнес-потребности. Когда заказчик начинает диктовать архитектуру или алгоритмы, не объясняя «зачем», риск ошибки резко возрастает.

Иллюзия простоты и недооценка состава работ

Многие проекты выглядят простыми только на словах. Особенно это заметно в задачах, связанных с IP-телефонией и интеграциями. Формулировка «нужно внедрить телефонию» часто скрывает целый комплекс работ, который заказчик не учитывает.

На практике в проект могут входить:

• анализ архитектуры и требований;
• выбор и совместимость оборудования и ПО;
• разработка и доработка логики;
• тестирование перед запуском;
• передача в поддержку и документация.

Отказ от аналитики и тестирования обычно объясняется доверием, но именно эти этапы чаще всего предотвращают критические ошибки после запуска.

Процесс формирования требований и уточнения ожиданий

В зрелых проектах работа с требованиями строится итеративно. Даже если заказчик присылает собственное ТЗ, оно редко бывает полным или однозначным. Поэтому процесс обычно выглядит так:

На этом этапе иногда выясняется, что реализация вообще не требуется, либо задачу можно решить гораздо проще. Это тоже результат качественной аналитики, а не её провал.

Документация как основа доверия и долгосрочной работы

Доверие в проектах важно, но оно не заменяет документацию. Устные договорённости, даже при полной уверенности в партнёре, со временем искажаются. Техническое задание защищает обе стороны: разработчик понимает границы ответственности, а заказчик видит, что именно он получит на выходе.

Даже в небольших проектах внутренняя документация необходима для передачи задач команде и последующей поддержки. Вопрос лишь в том, кто и в каком объёме за неё платит — заказчик напрямую или исполнитель, закладывая затраты в проект.