Модуль 6. Работа с требованиями и стейкхолдерами

Основной тезис модуля

Лид должен уметь не только отвечать на задачу, но и вскрывать задачу.

Входящий request почти никогда не является непосредственным предъявлением потребности. Обычно это уже чья-то форма решения:

Добавьте кнопку.
Сделайте отдельный микросервис.
Нужен экспорт в Excel.
Перенесите всё в облако.
Добавьте AI.
Сделайте как у конкурента.
Нужно ускорить систему.

За этой формой могут находиться разные реальные основания:

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

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

Слабая позиция лида:
"Бизнес сказал — команда сделала".

Другая слабая позиция:
"Бизнес ничего не понимает — мы сами решим, что ему нужно".

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

Лид не является переводчиком, который механически преобразует «язык бизнеса» в технические задачи. Он удерживает причинную связь между потребностью, решением, техническими последствиями и поставляемым результатом.

Главный вопрос модуля:

Как превратить входящее требование из чужой готовой формы в совместно проверяемую модель результата, не подменив собой ни Product Owner, ни стейкхолдера, ни команду?

Requirement не является самой реальностью

Requirement — это зафиксированное представление о том, какое условие, способность или поведение необходимо для достижения некоторого результата.

Он может быть:

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

Поэтому лид не должен относиться к требованию ни как к приказу, ни как к ошибке, которую нужно разоблачить. Это рабочая модель, которую необходимо проверить относительно:

потребности;
контекста;
стейкхолдеров;
ценности;
ограничений;
рисков;
доступных решений;
наблюдаемого результата.

IIBA описывает business analysis через шесть связанных понятий: Change, Need, Solution, Context, Stakeholder и Value. Эта рамка полезна именно как напоминание, что «решение» не равно «потребности», а требование существует внутри контекста и относительно ценности для стейкхолдеров. (IIBA BABOK Glossary)

Категории не заменяют реальность и не гарантируют правильного анализа. Они дают лидеру оси различения, по которым можно вскрыть преждевременно закрытую форму задачи.

Граница модуля

Этот модуль связан с delivery, но не совпадает с ним.

Модуль «Delivery: как доводить работу до результата» разбирает движение уже сформированной работы через систему: slicing, WIP, зависимости, блокеры, Done и production.

Здесь рассматривается предшествующий и непрерывно сопровождающий контур:

Кто предъявляет потребность?
Что именно должно измениться?
Почему выбран такой результат?
Какие интересы сталкиваются?
Какая часть неизвестна?
Кто имеет право принять решение?
Что команда обязуется построить?

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

1. Различать цель, потребность, способность, решение и реализацию

Большая часть подмен возникает, когда разные уровни описания изменения называются одним словом «требование».

Бизнес-цель

Какое изменение состояния организация хочет получить.

Пример: снизить число брошенных заказов после неуспешной оплаты.

Потребность пользователя или стейкхолдера

Какое ограничение существующего состояния необходимо устранить.

Пример: пользователь не может продолжить существующий заказ после отклонения первой попытки оплаты.

Требуемая способность

Что должно стать возможным после изменения.

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

Вариант решения

Какой механизм может предоставить требуемую способность.

Пример: предоставить действие повторной оплаты на странице существующего заказа.

Конкретная реализация

Как выбранное решение воплощается в системе.

Пример: новый endpoint, изменение state machine заказа, идемпотентная платёжная операция, feature flag и обновление web-интерфейса.

Эти уровни связаны, но не взаимозаменяемы:

Бизнес-цель → потребность → требуемая способность → вариант решения → конкретная реализация

Если входящий запрос звучит как «добавьте кнопку повторной оплаты», в нём уже предъявлена определённая форма решения. Лид должен уметь подняться от неё вверх по цепочке:

Форма запроса: кнопка повторной оплаты.

Требуемая способность: повторить оплату существующего заказа.

Потребность: продолжить существующий заказ после отклонения первой попытки оплаты.

Бизнес-цель: снизить число брошенных заказов после неуспешной оплаты.

После восстановления этой цепочки становится видно, что кнопка не является самим требованием. Это один из способов предоставить требуемую способность.

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

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

2. Как вскрывать входящую задачу

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

Кто

Кто сталкивается с проблемой?
Кто просит изменение?
Это один и тот же субъект?
Кого изменение затронет, хотя он не присутствует в разговоре?

Сейчас

Что происходит в существующем сценарии?
Где именно возникает невозможность, потеря, стоимость или риск?
Какие обходные действия используются сейчас?

Изменение

Что должно стать возможным после изменения?
Какое существующее поведение должно измениться?
Для кого оно должно измениться?

Ценность

Почему это изменение необходимо?
Какая потеря уменьшается или какая новая способность появляется?
Для кого возникает ценность?

Ограничения

Что нельзя нарушить?
Какие сроки, договоры, данные, платформы, бизнесовые правила и внешние условия ограничивают решение?

Неизвестность

Что сейчас является установленным фактом, а что предположением?
Какое предположение способно изменить выбранное решение?
Что необходимо выяснить до начала работы, а что допустимо выяснять уже во время реализации?

Scope

Что необходимо получить сейчас?
Что можно отложить?
Что явно не входит в текущее изменение?

Проверка результата

По какому наблюдаемому признаку станет понятно, что требуемое изменение действительно произошло?
Кто и каким образом сможет это проверить?

Завершение

Какое состояние работы будет считаться Done?
Что должно быть реализовано, поставлено, проверено и доступно для использования?

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

Задача лида состоит не в том, чтобы самостоятельно ответить на все вопросы. Он должен сделать видимым, какие ответы уже существуют, каких не хватает и кто способен или уполномочен их дать.

3. Кто такой stakeholder

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

Stakeholder — не синоним «заказчика» и не монолитный «бизнес».

Стейкхолдером является тот, кто:

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

IIBA предлагает определять не только список стейкхолдеров, но и их роли, ответственность, влияние на изменение, воздействие изменения на них, необходимую информацию и способ взаимодействия. (IIBA: Stakeholder Engagement)

Карта стейкхолдеров

Стейкхолдер	Интерес	Влияние	Что знает	Как затронут	Какие решения принимает
Product Owner	Ценность и продуктовый приоритет	Высокое	Цели продукта, потребности и продуктовый контекст	Отвечает за продуктовый выбор	Цель, приоритет, продуктовый scope и trade-off
Конечный пользователь	Выполнение сценария	Часто низкое формальное	Реальное использование	Получает или не получает ценность	Не всегда принимает формальное решение
Support	Диагностика обращений	Среднее	Повторяющиеся проблемы пользователей	Несёт операционную нагрузку	Требования к supportability
Security	Допустимый риск	Высокое в своей области	Модель угроз и стандарты	Несёт security-риск	Security constraints и исключения
Operations / SRE	Надёжность и восстановление	Среднее или высокое	Production-поведение	Эксплуатирует последствия	Operational readiness
Sales / Account	Обязательства клиенту	Высокое политическое	Контекст договора	Зависит от обещанной даты	Коммерческая договорённость, но не техническая оценка
Инженерная команда	Реализуемость и качество	Высокое техническое	Система и delivery	Строит и сопровождает решение	Способ реализации и прогноз

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

Источник требования не равен владельцу решения

Человек может первым обнаружить проблему или сообщить о потребности, но не иметь полномочий определить приоритет, архитектуру или допустимый риск.

Пример:

Support обнаружил повторяющуюся проблему.
Product Owner определяет её место относительно других продуктовых целей.
Команда определяет технические варианты и последствия.
Security определяет допустимость security-риска в своей границе.

Поэтому необходимо различать:

Stakeholder — тот, кого затрагивает изменение или кто способен на него влиять.

Источник требования — тот, от кого пришла информация о потребности, ограничении или необходимом изменении.

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

Один человек может одновременно находиться в нескольких этих ролях, но сами роли от этого не становятся одной ролью.

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

4. Границы решений: не подменять ответственности

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

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

Лид участвует во всей этой цепочке, но участие не делает его владельцем каждого решения.

Product Owner удерживает

продуктовую цель;
связь работы с создаваемой ценностью;
порядок продуктовых приоритетов;
выбор между конкурирующими потребностями;
решение о продуктовом scope;
принятие продуктовых trade-off.

Engineering Lead удерживает

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

Лид не определяет продуктовую ценность вместо Product Owner, но обязан сделать техническую цену продуктового решения видимой.

Инженерная команда удерживает

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

Лид не должен превращать участие команды в формальность, при которой все инженерные решения заранее приняты им самим.

Владельцы специализированных ограничений удерживают решения в своих областях

Security, Legal, Compliance, Operations, Data и другие участники могут обладать отдельными полномочиями относительно допустимого риска или обязательных ограничений.

Например, Product Owner может считать функцию продуктово необходимой, а Security определить, что предложенный способ её реализации создаёт недопустимый security-риск.

Это не означает, что Security становится владельцем продукта. Он принимает решение внутри своей области ответственности.

Подмена 1. Лид становится Product Owner

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

Следствие: техническая сторона незаметно присваивает решение о ценности.

Подмена 2. Product Owner становится владельцем технического решения

Product Owner предъявляет конкретный способ реализации как неизменяемую часть требования.

Например:

«Нужно сделать отдельный микросервис».

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

Следствие: форма решения фиксируется до того, как техническая сторона смогла оценить варианты и последствия.

Подмена 3. Лид принимает специализированный риск за другого владельца

Например, лид самостоятельно решает, что security-, compliance- или operational-риск допустим, потому что иначе работа не помещается в срок.

Инженерная оценка риска и право принять его — разные вещи.

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

Совместное решение не означает общую безразмерную ответственность

Одно решение может требовать участия нескольких сторон.

Например:

Product Owner определяет, какой результат необходимо сохранить;
Engineering Lead показывает технические варианты и их последствия;
команда уточняет реализуемость;
Security устанавливает допустимую границу риска;
Product Owner после этого выбирает между оставшимися продуктовыми вариантами.

Решение возникает совместно, но это не уничтожает границы ответственности.

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

5. Соединять продуктовую и инженерную причинность

Распределить полномочия недостаточно. Product Owner и Engineering Lead удерживают разные части причинной цепочки, но ни одна из сторон по отдельности не располагает достаточной моделью решения. Продуктовый выбор нельзя сделать осмысленно без понимания технических последствий, а технический вариант нельзя оценить без понимания результата, ради которого он создаётся.

Продуктовый контекст для инженерного решения

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

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

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

Инженерный контекст для продуктового решения

Чтобы Product Owner мог осмысленно выбрать продуктовый scope и trade-off, лид должен показать:

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

Лид не возвращает Product Owner сырую техническую сложность. Он превращает её в различимые варианты, между которыми можно принять продуктовое решение.

Как возникает граница поставки

Например, Product Owner считает дату критичной, а лид видит, что полный scope в эту дату не помещается.

Плохой разговор выглядит так:

Product Owner: «Команда обязана успеть».

Engineering Lead: «Это невозможно, бизнес опять ничего не понимает».

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

По итогам разговора должна быть сформирована и явно зафиксирована граница текущей поставки:

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

Совместное формирование этой границы не означает смешения полномочий. Product Owner определяет обязательный продуктовый результат и принимает продуктовые trade-off между ценностью, scope и доступными вариантами поставки. Engineering Lead вместе с командой формирует технически достижимые варианты, отвечает за честность прогноза и указывает инженерные свойства, которые нельзя исключить без разрушения результата. Если выбранный вариант оставляет security-, compliance- или иной специализированный риск, решение о его принятии принадлежит соответствующему владельцу.

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

6. Типы требований как оси проверки

Требование редко исчерпывается описанием функции.

Бизнесовые требования

Какая цель или изменение состояния организации необходимо.

Stakeholder requirements

Какая потребность конкретного класса стейкхолдеров должна быть удовлетворена.

Functional requirements

Какое поведение должна предоставлять система.

Quality attributes

Какими свойствами должно обладать поведение:

производительность;
доступность;
надёжность;
безопасность;
auditability;
accessibility;
scalability;
maintainability;
recoverability.

Business rules

Какие предметные ограничения и решения действуют независимо от конкретного интерфейса.

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

Constraints

Что ограничивает множество допустимых решений.

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

IIBA определяет constraint как влияющий фактор, который нельзя изменить и который ограничивает возможное решение. Это полезно, потому что многие предъявленные «ограничения» при проверке оказываются предпочтениями или предположениями, а не неизменяемыми условиями. (IIBA BABOK Glossary)

Transition requirements

Что необходимо только для перехода из текущего состояния в новое:

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

Operational requirements

Что необходимо для поддержки живой системы:

наблюдаемость;
аудит;
ручное восстановление;
support-инструменты;
runbook;
ограничения rollout;
rollback.

Assumptions и unknowns

Это не требования, но они определяют устойчивость всей модели.

Assumption:
партнёр гарантирует уникальность eventId.

Unknown:
как партнёр ведёт себя при повторном callback после 24 часов.

Классификация нужна не для заполнения документа, а чтобы функциональный happy path не скрывал качества, переход, эксплуатацию и предположения.

7. Находить скрытые ограничения

Скрытое ограничение обнаруживается поздно, когда уже выбранное решение сталкивается с реальностью.

Вопросы по сроку

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

Вопросы по данным

Какие данные используются?
Кому они принадлежат?
Где могут храниться?
Как долго?
Кто имеет право их видеть и изменять?
Как исправляется историческая ошибка?

Вопросы по масштабу

Сколько пользователей, объектов и операций?
Каков максимум, а не среднее?
Есть ли сезонные пики?

Вопросы по совместимости

Какие версии клиентов продолжают работать?
Кто потребляет текущий API?
Можно ли изменить схему атомарно?
Как долго живут старые сообщения?

Вопросы по эксплуатации

Кто увидит отказ?
Кто сможет исправить состояние?
Нужна ли ручная операция?
Как изменение отключается?

Вопросы по полномочиям

Кто имеет право выполнить действие?
Требуется ли разделение обязанностей?
Кто подтверждает исключение?

Вопросы по договору и регуляции

Какой точный текст обязательства?
Относится ли он к системе, процессу или результату?
Кто компетентен интерпретировать требование?

Hard, soft и assumed constraints

Hard constraint:
условие действительно нельзя изменить внутри данного решения.

Soft constraint:
условие желательно, но может быть обменено на другое преимущество.

Assumed constraint:
условие считается неизменяемым, хотя никто не проверял его основание.

Пример:

"Экспорт обязан быть синхронным".

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

8. Работа с неполными требованиями

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

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

Различить виды неполноты

Неизвестна сама потребность.
Не выбран вариант решения.
Не определено бизнесовое правило.
Не подтверждён внешний контракт.
Неизвестен объём данных.
Не определён edge case.
Не решён конфликт стейкхолдеров.
Неизвестен технический способ.

Для каждого вида требуется разное действие.

Инструменты уменьшения неизвестности

интервью с пользователем;
наблюдение существующего процесса;
анализ обращений support;
данные и метрики;
prototype;
spike;
contract test;
example mapping;
ограниченный pilot;
ручной сценарий до автоматизации;
ранний vertical slice;
решение владельца бизнесового правила.

Assumption Log

Предположение:

Почему мы сейчас его принимаем:

Что его подтвердит или опровергнет:

Последствие ошибки:

Владелец проверки:

Контрольная дата:

Open Questions

Вопрос:

Почему он влияет на решение:

Кто способен ответить:

До какого шага ответ необходим:

Какой временный вариант действует до ответа:

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

9. Acceptance criteria как наблюдаемая граница поведения

Acceptance criteria должны позволять сторонам одинаково различить, появилось требуемое поведение или нет.

Слабые критерии:

Работает корректно.
Интерфейс удобный.
Система быстрая.
Обработаны все ошибки.

Они создают видимость договорённости, не задавая наблюдаемой границы.

Критерий должен отвечать

При каком исходном состоянии?
Какое событие происходит?
Какое наблюдаемое поведение ожидается?
Какие инварианты сохраняются?

Пример

Rule: Повторная оплата возможна только пока резерв активен

Scenario: Пользователь повторяет оплату до истечения резерва
  Given заказ ожидает оплаты и резерв активен
  When пользователь выбирает другой способ оплаты
  Then создаётся новая платёжная попытка для существующего заказа
  And новый заказ не создаётся
  And сумма и состав заказа не изменяются

Scenario: Резерв уже истёк
  Given заказ ожидает оплаты и резерв истёк
  When пользователь открывает страницу заказа
  Then повторная оплата недоступна
  And пользователь видит необходимость создать новый заказ

Gherkin не является обязательной формой требований. Его ценность в различении исходного контекста, события и ожидаемого результата; Cucumber описывает Given, When, Then именно как context, event и expected outcome, а Rule — как бизнесовое правило, иллюстрируемое конкретными примерами. (Cucumber Gherkin Reference)

Acceptance criteria не заменяют

цель;
полный test plan;
Definition of Done;
quality attributes;
архитектурное решение;
исследование реального outcome после поставки.

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

10. Нефункциональные требования без пустых прилагательных

Фразы «быстро», «надёжно», «безопасно» и «масштабируемо» не дают команде проверяемого требования.

Производительность

Не:
"Отчёт должен формироваться быстро".

А:
"Для отчётов до 100 000 строк
95% запросов должны завершать подготовку файла не более чем за 2 минуты;
пользователь не обязан удерживать открытое соединение".

Доступность

Какой сценарий должен быть доступен?
В какой период?
Как измеряется недоступность?
Какие исключения действуют?

Надёжность

Какая потеря или дублирование недопустимы?
Как система восстанавливается?
Какой RPO и RTO действительно нужны?

Безопасность

Какие действия защищаются?
От какого субъекта?
Как проверяется право?
Какое событие аудируется?

Масштаб

Какой ожидаемый и предельный объём?
Как быстро он растёт?
Каков профиль нагрузки?

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

11. Как сказать «это не влезет» без театра

Фраза «не успеем» без модели выглядит как сопротивление команды. Обещание «постараемся» без модели скрывает реальность до момента провала.

Lead-позиция состоит в том, чтобы показать причинность прогноза и варианты решения.

Структура ответа

Цель:
что должно появиться и к какой дате.

Текущий scope:
какие способности включены.

Минимально обязательное качество:
что нельзя убрать без разрушения результата.

Ограничение:
какая зависимость, неизвестность или доступная способность команды
не позволяет выполнить весь scope.

Прогноз:
что реально может быть завершено.

Варианты:
какие оси можно изменить.

Решение:
кто должен выбрать вариант и когда.

Пример

Плохо:
"Это нереально, за неделю такое не делается".

Так же плохо:
"Хорошо, попробуем, но ничего не обещаем".

Точно:
"К 31 июля мы можем поставить экспорт заказов
для одного типа пользователя в CSV,
с асинхронным формированием и аудитом скачивания.

Полный scope сейчас включает ещё XLSX,
настраиваемые поля, сохранённые шаблоны
и объём до миллиона строк.

Последние две части требуют отдельной модели хранения
и проверки production-нагрузки;
в текущий горизонт они не помещаются.

Варианты:
1. Сохранить 31 июля и выпустить CSV для основного сценария.
2. Сохранить полный scope и перенести поставку после load test.
3. Сохранить дату и XLSX, но ограничить объём и отказаться от шаблонов.

Нужно решение Product Owner о первом пользовательском сегменте
до 22 июля".

Здесь нет театрального отказа и нет ложного обещания. Есть модель достижимого результата и точка решения.

Что нельзя молча превращать в переменную

Нельзя предлагать «сэкономить» срок через скрытое удаление:

security;
целостности данных;
обязательного regulatory compliance;
минимальной наблюдаемости;
возможности безопасного rollout;
критического тестирования.

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

12. Как предлагать альтернативы

Сильная альтернатива сохраняет цель, изменяя форму достижения.

Оси изменения решения

Пользовательский сегмент

Не все пользователи сразу,
а один тип клиента или внутренняя группа.

Сценарий

Сначала основной путь,
затем исключения и редкие случаи.

Канал

Сначала web,
затем mobile и API.

Уровень автоматизации

Основной пользовательский путь автоматизирован,
редкое исключение временно обрабатывается вручную.

Объём

Сначала 100 000 строк,
затем большой архивный экспорт.

Точность или свежесть

Предварительные данные сейчас,
финальный подтверждённый расчёт позже.

Интеграция

Стабильный файл или ручной import как первый контур,
автоматический API после подтверждения модели.

Rollout

Feature flag, pilot, процент трафика,
один регион или один клиент.

Покупка или создание

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

IIBA в актуальных материалах по design options подчёркивает необходимость исследовать разные способы удовлетворения business need и не замыкаться на «идеальном» solution design слишком рано. (IIBA: Requirements and Design)

Формат предложения

Цель сохраняется:

Меняется:

Что пользователь получает:

Что откладывается:

Какой риск уменьшается:

Какой новый риск принимается:

Как будет проверен первый результат:

Альтернатива не должна быть технически удобной подменой цели. Если бизнесу нужен юридически значимый XLSX с определённой структурой, предложение «давайте отдадим JSON, нам так проще» не сохраняет исходный результат.

13. Конфликт стейкхолдеров

Стейкхолдеры могут предъявлять несовместимые требования:

Sales требует дату для клиента.
Security требует второй фактор подтверждения.
Support требует возможность ручного исправления.
Operations требует ограниченный rollout.
Product хочет минимальный пользовательский friction.
Finance требует полный audit.

Это не обязательно плохая коммуникация. Участники удерживают разные реальные последствия.

Разложить конфликт

Какой интерес защищает каждая сторона?
Какое последствие она считает недопустимым?
На каком основании?
Какая часть является hard constraint?
Какая — предпочтением?
Кто имеет право принять остаточный риск?

Не стремиться к универсальному согласию

Консенсус не является самоцелью. Иногда после полного прояснения стороны продолжают хотеть несовместимые вещи. Тогда необходимо решение владельца соответствующей ответственности.

Задача лида:

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

Decision matrix

Вариант	Ценность	Срок	Технический риск	Операционный риск	Обратимость	Ограничение
Полный синхронный экспорт	Высокая	Дольше	Высокий	Высокий	Средняя	Большие объёмы
Асинхронный CSV	Средняя/высокая	Быстрее	Низкий	Низкий	Высокая	Нет XLSX
Ручной отчёт для одного клиента	Локальная	Быстро	Низкий	Средний	Высокая	Не масштабируется

Матрица не принимает решение автоматически. Она делает цену выбора видимой.

14. Фиксация договорённостей

Договорённость, существующая только в разговоре или личной переписке, не стала знанием команды.

Фиксировать нужно не весь разговор, а состояние решения.

Requirement Brief

Проблема:

Пользователь / стейкхолдер:

Текущее состояние:

Требуемая способность:

Business outcome:

Scope:

Non-goals:

Business rules:

Quality attributes:

Constraints:

Assumptions:

Open questions:

Acceptance criteria:

Способ проверки outcome:

Decision Record

Решение:

Дата:

Владелец решения:

Контекст:

Рассмотренные варианты:

Основание выбора:

Принятая цена и риск:

Условие пересмотра:

Change Log

Что изменилось в requirement:

Почему:

Как влияет на scope, прогноз и техническое решение:

Кто подтвердил:

Почему недостаточно ссылки на чат

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

Фиксация не нужна ради бюрократической доказательности. Она создаёт единую текущую модель, к которой могут обратиться Product Owner, команда, QA, support и будущий участник.

15. Как не дать хаосу пройти внутрь команды

Защита команды не означает построить стену между разработчиками и стейкхолдерами. Прямая связь необходима для понимания реальности. Но вход работы и изменение приоритета должны иметь явную архитектуру.

Единый контур intake

Должно быть понятно:

Куда поступает новый запрос?
Кто его первично разбирает?
Кто определяет продуктовый порядок?
Когда команда обязана немедленно реагировать?
Что не является задачей до принятия решения?

Отделить информацию от назначения работы

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

Прямая коммуникация:
да.

Скрытое переназначение приоритетов:
нет.

Определить emergency

Слово «срочно» должно иметь операционный смысл:

production недоступен;
теряются или искажаются данные;
активна security-угроза;
нарушается критическое договорное или регуляторное условие;
существует другой заранее определённый класс инцидента.

Желание стейкхолдера получить результат раньше не равно инциденту.

Изменение scope имеет цену

Если во время работы добавляется новое требование, команда не должна просто «учесть ещё маленький пункт».

Нужно установить:

Что добавилось?
Что теперь перестаёт помещаться?
Как меняется риск?
Кто подтверждает новый trade-off?

Владелец порядка должен быть один

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

Не делать лида единственным фильтром

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

16. Коммуникация сложного решения стейкхолдерам

Техническую реальность нельзя ни выгружать в виде сырого жаргона, ни сглаживать до ложной простоты.

Слабая техническая речь

"Мы не можем, потому что там legacy,
Kafka, eventual consistency и вообще большой refactoring".

Стейкхолдер слышит перечисление внутренних проблем без связи с решением.

Корпоративное замыливание

"Команда активно исследует оптимальные возможности
и стремится обеспечить максимально качественный результат".

Состояние реальности исчезает полностью.

Точная речь

"Сейчас статус заказа хранится независимо в двух системах.
При обычном сценарии они совпадают,
но повторная оплата создаёт второй переход,
который существующий контракт не различает.

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

Есть два варианта:
ограничить первый выпуск одним платёжным провайдером
или сначала изменить модель платёжной попытки.
Первый вариант быстрее, второй сразу поддержит все способы оплаты".

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

17. Метрики работы с требованиями

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

Rework из-за неверно понятого требования

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

Requirement clarification time

Сколько работа ждёт ответа или решения, необходимого для продолжения.

Scope change rate

Как часто и насколько существенно scope меняется после начала реализации.

Высокое значение не всегда плохо: оно может отражать реальное обучение. Важно различать discovery и хаотическое переназначение.

Decision latency

Сколько времени проходит между появлением явно сформулированного решения и его принятием владельцем.

Assumption failure rate

Какие существенные предположения оказались неверными и на каком этапе это обнаружилось.

Requirement defects after delivery

Сколько production-проблем связано с тем, что система реализовала зафиксированное поведение, но в requirement отсутствовал важный сценарий, инвариант или стейкхолдер.

Доля работы без проверяемого outcome

Для какой работы команда не способна назвать даже локальный признак результата.

Опасные метрики

Количество написанных requirements.
Процент заполненных полей шаблона.
Количество проведённых stakeholder meetings.
Число страниц спецификации.
Количество изменений requirement как автоматически плохой показатель.

Они измеряют производство формы, а не качество различения.

Итоги модуля

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

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

Stakeholder знает свою потребность и последствия.

Product Owner удерживает ценность и порядок.

Engineering Lead удерживает техническую причинность и варианты.

Команда удерживает способ реализации и качество.

Профильные владельцы удерживают ограничения своих областей.

Главное различение модуля:

Лид не превращает бизнесовый запрос в техническую задачу.

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

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

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

Источники

IIBA BABOK Glossary