Сайт А. Мокрышева

Почему проекты ломаются не в коде, а в ожиданиях людей?

В ИТ-проектах есть одна неприятная закономерность: команда может хорошо писать код, использовать правильную архитектуру, вести backlog, проводить встречи, согласовывать документы — и все равно в конце услышать от заказчика: «Мы ожидали не этого».

Формально все могло быть сделано правильно. Требования собраны. Таблицы заполнены. User story написаны. Макеты показаны. Документы согласованы. Статусы в Jira обновлены. Но продукт все равно не попадает в реальную потребность.

Почему так происходит?

На мой взгляд, проблема часто начинается с неправильного понимания самого слова «требование». Мы привыкли думать, что требование — это описание того, что должна делать система. Например: «пользователь должен иметь возможность сформировать отчет», «менеджер должен видеть список заявок», «администратор должен назначать роли».

На первый взгляд все логично. Но в реальном проекте такая формулировка опасно упрощает картину. Она заставляет команду смотреть на требования как на будущие функции интерфейса, а не как на отражение ожиданий конкретных людей относительно будущего процесса. А люди редко хотят функции. Они хотят решить проблему, снизить риск, ускорить работу, сохранить контроль, получить признание, избежать ручного труда, не потерять деньги, не выглядеть виноватыми перед руководством или просто перестать страдать от хаоса в процессе. Функция системы — это только один из возможных способов удовлетворить ожидание. И далеко не всегда лучший.

Требование рождается не в системе, а в голове человека

Если посмотреть на ИТ-проект глазами архитектора или разработчика, система состоит из модулей, данных, интеграций, экранов, ролей, прав доступа и бизнес-логики. Но если посмотреть на тот же проект глазами пользователя, он состоит из совсем других вещей: ответственности, дедлайнов, конфликтов, привычек, страхов, KPI, ручных обходных путей, неформальных договоренностей и личного опыта.

Именно там живут настоящие требования. Не в таблице. Не в ТЗ. Не в презентации. Не в диаграмме бизнес-процесса.

Требование возникает у конкретного человека, который находится в конкретной ситуации и ожидает, что новая система изменит эту ситуацию в его пользу. Поэтому хорошее требование — это не просто описание будущей кнопки или отчета. Это ответ на вопросы: зачем человеку это нужно; какую проблему он пытается решить; почему текущий способ работы его не устраивает; какой результат он считает успешным; что изменится в его работе после внедрения; какие риски он видит; чего он боится потерять; какие решения он будет принимать на основе системы.

Пока эти вопросы не заданы, команда работает не с требованиями, а с их тенями.

Почему заказчик не всегда знает, чего хочет

Есть популярная иллюзия: достаточно спросить пользователя или заказчика, что ему нужно, аккуратно записать ответы — и можно проектировать систему. На практике это почти никогда не работает.

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

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

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

В-четвертых, люди меняют мнение. Причем не потому, что они вредные или непрофессиональные. Просто их ожидания зависят от контекста: от новых вводных, разговоров с коллегами, давления руководства, увиденного прототипа, политической ситуации внутри компании и даже от того, насколько болезненной была последняя проблема в текущем процессе. Если будущий процесс не объяснять постоянно, каждый участник начинает достраивать его в своей голове самостоятельно. Сегодня ему кажется, что система должна работать одним образом. Завтра, после разговора с коллегой, он уже представляет ее иначе. Через месяц, увидев прототип, он вспоминает исключение, о котором раньше не говорил. Перед приемкой у него появляется новая версия «правильного» процесса. И это нормальное человеческое поведение. Проблема начинается тогда, когда команда делает вид, что ожидания можно один раз собрать, записать и заморозить.

Сбор требований начинается не с функций, а с карты влияния

Одна из самых частых ошибок в корпоративных и продуктовых проектах — разговаривать только с теми, кто громче всех формулирует задачу. Обычно это спонсор, руководитель направления, владелец бюджета или представитель бизнеса, назначенный «ответственным со стороны заказчика». Но система редко затрагивает только одного человека. У нее есть будущие пользователи, администраторы, руководители, служба безопасности, бухгалтерия, юристы, поддержка, интеграционные команды, владельцы данных, внешние партнеры, иногда клиенты и регуляторы. У каждого из них свои ожидания. Пользователь хочет удобства. Руководитель хочет контроля. Финансы хотят прозрачности. Безопасность хочет управляемых рисков. и так далее.

Если собрать требования только у одной группы, проект почти неизбежно столкнется с сопротивлением остальных. Причем это сопротивление может проявиться поздно: на приемке, пилоте, промышленном запуске или уже после релиза, когда начнутся доработки, обходные процессы и взаимные обвинения. Поэтому анализ требований должен начинаться с простой, но часто игнорируемой работы: нужно понять, кто имеет право быть недовольным будущей системой. И поговорить с этими людьми до того, как архитектура, сроки и бюджет стали слишком жесткими.

Требования нельзя просто собрать. Ими нужно управлять

Есть еще одна ловушка: относиться к требованиям как к статичному артефакту. Команда собирает пожелания, оформляет документ, получает подпись и считает, что важная часть работы завершена. Дальше начинается разработка. Но требования — это не камень. Это ожидания людей относительно будущего. А ожидания по своей природе нестабильны. Будущее меняется. Люди получают новую информацию. Организация пересматривает приоритеты. Появляются ограничения. Меняется рынок.

Команда показывает прототип, и заказчик впервые понимает, что именно он попросил. Руководитель смотрит на первые результаты и начинает хотеть большего. Пользователь видит интерфейс и понимает, что его реальная работа устроена сложнее, чем казалось на интервью. Это не исключение. Это нормальное состояние проекта. Поэтому зрелая команда не пытается «заморозить» требования любой ценой. Она строит процесс управления ожиданиями.

Но управление ожиданиями — это не рассылка протоколов и не периодическое напоминание, что «мы же это согласовали». Управлять ожиданиями — значит постоянно продавать участникам проекта образ будущего процесса. Не в смысле манипулировать людьми или рекламировать им красивую презентацию вместо реальности. А в смысле снова и снова объяснять, какую именно модель работы создает проект, почему она лучше текущей, какие роли в ней меняются, какие действия исчезают, какие решения будут приниматься иначе и какую выгоду получит каждый участник. Будущий бизнес-процесс нельзя просто нарисовать один раз на схеме и положить в Confluence. Его нужно регулярно проговаривать, показывать, защищать, уточнять и делать привычным для людей еще до запуска системы.

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

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

Продажа будущего процесса выявляет проблемы раньше, чем они ломают проект

У постоянной «продажи» целевой модели есть еще один важный эффект: она вытаскивает наружу возражения. И это хорошо. Возражение пользователя — не всегда сопротивление изменениям. Часто это информация о проблеме, которую команда не заметила. Человек может сказать: «Так не получится, потому что у нас есть исключения по крупным клиентам». Или: «Эти данные появляются только после ручной проверки». Или: «Этот шаг нельзя убрать, потому что его требует внутренний контроль». Или: «Если руководитель не увидит этот статус, он все равно заставит нас вести параллельную таблицу». На ранних стадиях таких деталей может просто не существовать в явном виде. О них могли забыть. Их могли считать неважными. Они могли появиться уже после старта проекта из-за изменений в организации, регуляторике, отчетности, персональном составе или политике руководства.

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

А если будущий процесс регулярно «продается» пользователям, у них появляется повод спорить с ним заранее. Именно в этих спорах проект получает самую ценную информацию. Не все возражения нужно принимать. Часть из них будет попыткой сохранить старые привычки, локальную власть или удобные обходные схемы. Но каждое серьезное возражение нужно разобрать: это субъективный дискомфорт от изменений или объективное ограничение процесса? Если ограничение объективное и команда его проигнорирует, оно не исчезнет. Оно вернется позже — в виде доработок, отказа от использования системы, параллельных Excel-файлов, ручных операций, конфликтов на приемке или провала внедрения.

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

Почему согласовать требования недостаточно

В waterfall-подходе часто есть соблазн спрятаться за формальным согласованием. Документ подписан — значит, заказчик подтвердил объем работ. Если потом возникли претензии, можно сказать: «Вы сами это утвердили». Юридически или управленчески такая позиция иногда работает. Но с точки зрения продукта она почти бесполезна.

Если система не решает реальную задачу, никого не спасет тот факт, что кто-то когда-то поставил подпись под документом. Бизнес не получает результата. Пользователи недовольны. Команда демотивирована. Руководство считает проект неуспешным. Возникают новые раунды доработок, конфликтов и объяснений. Формальная правота не равна успешному внедрению. В сильных проектах требования не просто согласуют. Их делают понятными, принимаемыми и выгодными для ключевых участников.

Именно поэтому в анализе требований есть элемент продажи. Не продажи в смысле давления или навязывания. А продажи в нормальном предпринимательском смысле: нужно объяснить людям ценность решения, показать, как оно учитывает их интересы, честно обозначить ограничения и добиться не пассивного согласия, а внутреннего принятия.

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

Если часть заинтересованных лиц остается равнодушной, обиженной или проигравшей, проект получает скрытый риск. Такие люди редко говорят прямо: «Я против системы». Чаще они начинают предлагать дополнительные требования, критиковать интерфейс, затягивать приемку, требовать исключений, поддерживать старые Excel-файлы или объяснять коллегам, почему новый инструмент неудобен. И в каком-то смысле они правы: если проект не решил их проблему и не продал им новую модель работы, они будут защищать старую.

Аналитик должен быть не секретарем, а переводчиком

Слабый анализ требований похож на протоколирование встреч. Люди что-то сказали, аналитик записал, команда реализовала. Сильный анализ требований больше похож на перевод между мирами. Нужно перевести язык бизнеса на язык системы, язык пользователей — на язык процессов, язык процессов — на язык данных, язык данных — на язык архитектуры, а затем обратно объяснить людям, почему предложенное решение действительно отвечает их интересам.

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

Способность работать с противоречиями нужна потому, что требования разных людей почти всегда конфликтуют. Один хочет свободы действий, другой — контроля. Один хочет гибкости, другой — стандартизации и тд Задача команды — не собрать все эти желания в один бесконечный список. Задача — предложить работающую конфигурацию будущего процесса, объяснить ее участникам и добиться того, чтобы они начали считать ее реалистичной и полезной.

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

Что должны делать руководители проектов, предприниматели и разработчики

Руководителю проекта важно понимать: риск требований — это не только риск неполного ТЗ. Это риск несформированной картины будущего у людей, которые будут жить в новом процессе. Поэтому план проекта должен включать не только разработку и тестирование, но и регулярную коммуникацию целевой модели: демонстрации, обсуждения сценариев, разбор возражений, объяснение компромиссов и повторное подтверждение того, что участники одинаково понимают будущий процесс.

Предпринимателю важно помнить: пользовательские интервью нужны не для того, чтобы собрать список фичей. Они нужны, чтобы обнаружить повторяющиеся проблемы, за которые рынок готов платить изменением поведения, денег или времени. Но после этого начинается другая работа: рынку нужно постоянно объяснять новый способ решения проблемы. Иначе каждый клиент будет тянуть продукт в сторону своего привычного процесса, а команда утонет в кастомизации.

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

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

Практический принцип

Перед тем как принять требование в работу, полезно проверить его не только на понятность, но и на происхождение. Кто именно этого хочет? Какую проблему человек пытается решить? Что произойдет, если это не сделать? Кто еще будет затронут? Не противоречит ли это ожиданиям других участников? Можно ли решить проблему проще? Как это требование связано с целевой моделью процесса? Усиливает ли оно будущий процесс или возвращает нас к старому? Как мы объясним пользователям, почему процесс должен работать именно так? Какие возражения уже прозвучали? Какие из них являются страхами, а какие — объективными ограничениями? Как мы поймем, что требование действительно удовлетворено? Кто должен принять результат не формально, а по-настоящему?

Эти вопросы иногда кажутся лишними. Особенно когда сроки горят, команда занята, а заказчик уверен, что «там все очевидно». Но именно «очевидные» требования чаще всего взрываются на поздних этапах. Потому что очевидность у каждого своя.

Финальный вывод

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

Поэтому анализ требований — это не разовая стадия перед разработкой. Это непрерывная работа с ожиданиями, конфликтами, компромиссами и образом будущего процесса. Собрать требования мало.

Нужно понять людей, которые за ними стоят.

Нужно выявить тех, чьи интересы будут затронуты.

Нужно отделить реальные проблемы от предложенных решений.

Нужно регулярно объяснять целевую модель процесса и добиваться того, чтобы люди не просто формально соглашались с ней, а начинали считать ее своей.

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