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