Что делать, если у заказчика Ambiguity — неопределённость требований?

Есть тип заказчика, знакомый каждому архитектору: он приходит с идеей, энтузиазмом и фразой «вы же архитектор, вам за это и платят». Формально задача звучит как «сделайте проект», но за ней стоит пустота: сырой материал, обрывки мыслей, отсутствие ТЗ. Как превратить эту неопределённость в рабочую архитектуру и где проходит граница ответственности специалиста — разберём по порядку.

Что такое ambiguity и почему это нормально

Ambiguity — неопределённость требований — это состояние любой идеи на раннем этапе. Человек приходит с ощущением продукта, но без его описания. Он видит результат, но не видит пути. Формулировать требования — отдельная компетенция, и она есть далеко не у всех.

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

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

Почему «я вам плачу, вы и решайте» — плохая позиция

Архитектура строится на информации. Когда информации нет, она строится на догадках. Догадки иногда попадают в цель, но чаще приводят к переделкам. Это не упрёк архитектору, это закономерность.

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

Светлые идеи и результативные решения — это часть работы архитектора. Но рождаются они в диалоге, где заказчик даёт знание предметной области, а архитектор — структуру и техническую логику. Когда одна из сторон выпадает, вторая работает вслепую.

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

Бриф с вопросами — обязательный этап

Архитектор готовит бриф с вопросами. Это must have, а не разговор по телефону, где ловишь идеи заказчика на лету. Разница огромная. В разговоре мысли теряются, детали забываются, а через неделю никто не помнит, о чём договорились. Бриф фиксирует: что спрашивали, что ответили, что осталось открытым.

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

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

Как превращать неопределённость в артефакты

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

Первый шаг — границы. Что входит в проект, что остаётся за его пределами. Самая частая зона неопределённости, потому что заказчик мыслит результатом, а не рамками.

Второй шаг — входные данные. Какие источники используются, кто их владелец, как часто они обновляются, в каком формате. Здесь важно явно фиксировать всё: не «данные из систем», а «данные из CRM через API, обновление раз в час, владелец — отдел продаж».

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

Четвёртый шаг — ограничения. Что нельзя делать, чего нет в наличии, какие сроки, какие бюджеты, какие регуляторные требования. Ограничения — основа для реалистичной архитектуры.

Пятый шаг — failure mode. Что произойдёт, если компонент сломается, данные не придут, модель ошибётся. Описание режимов отказа превращает архитектуру из картинки в рабочий документ.

Шестой шаг — измеримый критерий корректной работы. Как мы поймём, что система работает правильно. Точность, задержка, стоимость, доля успешных сценариев. Главное — критерий должен быть проверяемым, а не декларативным.

Handoff как критерий корректной работы

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

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

Колонка автора

Кульминация: где проходит граница

Работа с ambiguity — это дисциплина, а не терпение. Заказчик приходит с неопределённостью, архитектор превращает её в структуру. Но превращение требует участия обеих сторон. Без знания бизнеса архитектура превращается в набор допущений. Без структуры знание бизнеса остаётся набором желаний.

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

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

Глоссарий терминов

• Ambiguity (неопределённость требований) — состояние проекта, при котором заказчик не может точно сформулировать задачу и ожидаемый результат.
• Граница проекта — описание того, что входит в проект, а что остаётся за его пределами.
• Артефакт — материальный результат работы: документ, схема, реестр, критерий.
• Проверяемый критерий — условие, которое можно измерить и подтвердить, а не просто заявить.
• Входные данные — источники информации, на которых строится проект.
• Владелец элемента — человек, отвечающий за конкретный компонент или решение.
• Ограничения проекта — условия, которые определяют рамки реализации: сроки, бюджет, регуляторика, ресурсы.
• Failure mode (режим отказа) — описание того, как система ведёт себя при сбое компонента.
• Критерий корректной работы — измеримый показатель, по которому определяется успешность системы.
• Handoff — передача архитектуры и документации в команду реализации.
• Зона ответственности — область, за которую специалист отвечает лично и в границах которой принимает решения.
• Командная работа — процесс, в котором результат зависит от вклада всех участников.
• Допущение — явно зафиксированное предположение, которое используется при нехватке данных.
• Бизнес-процесс — последовательность действий, направленная на достижение результата в компании.
• Дорожная карта — план развития проекта во времени с этапами и приоритетами.
• API — программный интерфейс для взаимодействия между системами.
• Архитектура — структура системы: компоненты, их связи, распределение ответственности и границы.
• Реализуемость — свойство архитектуры, при котором система может быть построена в заданных условиях.
• Риск проекта — вероятность события, которое может негативно повлиять на проект.
• Согласование — процесс утверждения решений всеми участниками проекта.