Работа с требованиями и стейкхолдерами - Деконструкция реальности

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

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

Входящий 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?
Что должно быть поставлено, проверено и наблюдаемо?

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

3. Кто такой stakeholder

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

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

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

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

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

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

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

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

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

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

4. Product Owner, лид и Scrum Master: не подменять ответственности

В Scrum Guide нет отдельной accountability Tech Lead или Team Lead. Поэтому реальная организация должна явно определить, как лидерская роль соотносится с формальными accountabilities Scrum Team.

Scrum Guide возлагает на Product Owner ответственность за максимизацию ценности продукта, Product Goal, ясность и порядок Product Backlog. Developers планируют, как превратить выбранную работу в Increment, соответствующий Definition of Done. Scrum Master отвечает за установление Scrum и эффективность Scrum Team через развитие её практик. Вся Scrum Team создаёт ценный Increment и вместе со стейкхолдерами исследует результат. (Scrum Guide)

Для лида здесь важно не религиозное воспроизведение Scrum, а граница решений.

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

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

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

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

Developers удерживают

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

Scrum Master удерживает

способность команды использовать Scrum как контур transparency, inspection и adaptation;
устранение системных препятствий процессу;
развитие self-management;
продуктивность событий и взаимодействия.

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

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

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

Подмена 2. Product Owner становится архитектором

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

Следствие: технические последствия решения отделяются от того, кто способен их оценить.

Подмена 3. Лид становится Scrum Master

Лид единолично управляет всеми встречами, назначает работу и контролирует участников, одновременно утверждая, что команда self-managed.

Подмена 4. Лид становится памятью системы

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

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

5. Разговаривать с Product Owner как с владельцем другой причинности

Разговор Product Owner и лида не должен быть отношением «заказчик — исполнитель» или борьбой «бизнес против технологий».

Они удерживают разные части причинной цепочки:

Product Owner:
почему это изменение нужно продукту
и какое место оно занимает среди других целей.

Engineering Lead:
что именно придётся изменить в технической системе,
какие варианты существуют
и какие последствия создаёт каждый вариант.

Вопросы лида к Product Owner

Какой Product Goal поддерживает эта работа?
Какую проблему мы наблюдаем?
Для какого сегмента пользователей?
Как часто она возникает?
Какова цена существующего состояния?
Почему решение нужно именно к этой дате?
Что является минимально полезным результатом?
Что можно не делать сейчас?
Кто принимает решение при конфликте scope и даты?

Информация лида для Product Owner

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

Нормальный конфликт

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

Плохой исход — одна сторона замолкает:

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

Лид:
"Это невозможно, бизнес опять ничего не понимает".

Нормальный исход:

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

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?

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

Scrum Guide прямо говорит, что Product Owner — один человек, а не комитет; желающие изменить Product Backlog должны влиять на решение Product Owner, а не создавать параллельные очереди. (Scrum Guide)

Вне Scrum название роли может быть другим. Системный принцип остаётся: команда не может одновременно исполнять несколько независимых источников приоритета и сохранять осмысленный delivery.

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

Если только лид знает, какие запросы разрешено принимать, хаос исчезает лишь пока он присутствует. Правила 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 как автоматически плохой показатель.

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

Системные дисфункции работы с требованиями

1. Ticket taker

Команда принимает готовую форму решения и оценивает только трудоёмкость реализации.

2. Solution laundering

Чьё-то предпочтение проходит через Product Backlog и после записи в Jira начинает восприниматься как объективная потребность.

3. Лид как теневой Product Owner

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

4. Product Owner как технический диспетчер

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

5. Комитет вместо владельца

Несколько стейкхолдеров способны добавлять scope, но никто не отвечает за итоговый выбор.

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

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

7. Бесконечный discovery

Команда требует прояснить все возможные edge cases до первого поставляемого среза. Неизвестность не уменьшается через реальный результат.

8. Acceptance criteria после реализации

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

9. Срочность как канал власти

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

10. Обещание до анализа

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

11. Техническое запугивание

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

12. Бизнесовое давление как истина

Коммерческое желание предъявляется как отменяющее техническую причинность: «дата уже обещана, значит, возможность существует».

13. «Нет» без альтернативы

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

14. Документационное кладбище

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

15. Traceability theatre

Каждая строка связана идентификаторами с задачами и тестами, но причинная связь между business need, решением и результатом не восстанавливается.

16. Stakeholder consensus theatre

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

Практический разбор

Исходный запрос

Account Manager пишет:

"Ключевому клиенту срочно нужна кнопка экспорта в Excel.
Они ждут её к пятнице,
иначе могут не продлить контракт".

Если передать это напрямую команде, получится задача:

Добавить кнопку Export to Excel до пятницы.

Но пока неизвестно почти всё существенное.

Шаг 1. Кто пользователь

После разговора выясняется:

экспорт нужен финансовому аналитику клиента;
Account Manager не является пользователем;
файл передаётся во внутреннюю систему сверки;
support уже вручную формирует похожий отчёт дважды в месяц.

Шаг 2. Какая потребность

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

Шаг 3. Почему Excel

Формат XLSX был назван потому, что аналитик открывает отчёты в Excel. При этом внутренняя система клиента принимает CSV. Следовательно, Excel — привычная форма, а не подтверждённое hard constraint.

Шаг 4. Что означает дата

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

Шаг 5. Скрытые ограничения

до 300 000 заказов за период;
персональные данные не должны попадать в файл;
суммы должны соответствовать финансовому закрытию, а не текущему UI-состоянию;
выгрузка должна быть доступна только роли Finance Analyst;
формирование может занимать несколько минут;
каждое скачивание должно аудироваться;
support должен видеть статус генерации.

Шаг 6. Конфликт

Sales:
нужен результат к пятнице.

Пользователь:
нужен файл для сверки.

Security:
нельзя раскрывать персональные данные.

Finance:
нужны данные из закрытого финансового snapshot.

Engineering:
синхронная генерация 300 000 строк не помещается
в существующий request timeout.

Шаг 7. Варианты

Вариант A. Полный production XLSX

Не помещается к пятнице: требуется асинхронная генерация, хранение файла, новый permission, audit, supportability и нагрузочная проверка.

Вариант B. CSV pilot для одного клиента

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

Вариант C. Ручная выгрузка

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

Requirement Brief

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

Требуемая способность:
получить машинно читаемый файл
по закрытому финансовому периоду.

Business outcome:
подтвердить поддержку процесса клиента
до встречи о продлении
и уменьшить ручную работу support.

Первый scope:
CSV, один клиент, один тип отчёта,
до 300 000 строк, асинхронная генерация.

Non-goals:
универсальный конструктор отчётов,
XLSX formatting,
все пользовательские роли.

Constraints:
finance snapshot,
исключение PII,
role-based access,
audit download.

Success:
клиент импортирует pilot-файл
и подтверждает соответствие полей процессу сверки.

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

Практическое задание: Stakeholder & Requirement Brief

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

1. Исходная форма

Как звучит запрос:

Кто его предъявил:

Какое решение уже встроено в формулировку:

2. Причинная цепочка

Business goal:

Потребность:

Пользователь или получатель результата:

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

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

Возможные альтернативы:

3. Stakeholder Map

Стейкхолдер	Интерес	Влияние	Знание	Воздействие изменения	Решения

4. Граница ответственности

Product Owner решает:

Engineering Lead решает:

Developers решают:

Профильные владельцы решают:

Нерешённые конфликты передаются:

5. Текущее состояние

Как сценарий работает сейчас:

Где возникает невозможность или стоимость:

Какие workaround используются:

Какие данные подтверждают проблему:

6. Требуемое состояние

Что должно стать возможным:

Какое поведение изменяется:

Какой outcome ожидается:

Как outcome будет наблюдаться:

7. Требования

Business requirements:

Stakeholder requirements:

Functional requirements:

Business rules:

Quality attributes:

Transition requirements:

Operational requirements:

8. Ограничения

Ограничение	Hard / Soft / Assumed	Основание	Владелец интерпретации	Влияние

9. Assumptions и unknowns

Предположение:
Способ проверки:
Последствие ошибки:
Владелец:
Дата:

Открытый вопрос:
Почему влияет:
Кто отвечает:
Когда блокирует:

10. Scope

Обязательный первый результат:

Можно отложить:

Non-goals:

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

Rollout:

11. Acceptance criteria

Основной сценарий:

Граничный сценарий:

Отказный сценарий:

Сохраняемые инварианты:

12. Альтернативы

Вариант	Сохраняемая цель	Scope	Срок	Риски	Обратимость

13. Если полный scope не помещается

Цель и дата:

Почему полный scope не помещается:

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

Реалистичный первый результат:

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

Кто выбирает:

Когда решение необходимо:

14. Decision Record

Решение:

Владелец:

Основание:

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

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

Командные артефакты после модуля

1. Stakeholder Map

Карта интересов, влияния, знания, воздействия и полномочий.

2. Requirement Brief

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

3. Assumption & Open Questions Log

Неизвестность с владельцами, способом проверки и контрольными точками.

4. Decision Log

Текущие решения с основанием, владельцем, принятой ценой и условием пересмотра.

5. Scope Change Record

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

6. Stakeholder Update Template

Цель:
Текущий результат:
Изменение requirement:
Ограничение:
Варианты:
Необходимое решение:
Следующая контрольная точка:

7. Intake Policy

Способ принятия запросов, владелец порядка, определение emergency и правила прямого взаимодействия с командой.

Критерии выполненного задания

Lead-level работа с requirement считается выполненной, если:

входящая форма решения отделена от потребности;
бизнес-цель, пользовательская потребность, способность, solution и implementation не смешаны;
определён реальный пользователь, а не только источник запроса;
найдены стейкхолдеры, которые влияют или будут затронуты;
интерес отделён от полномочия принять решение;
Product Owner, лид, Developers и профильные владельцы не подменяют друг друга;
функциональное требование дополнено quality, transition и operational requirements;
hard constraints отделены от предпочтений и непроверенных предположений;
неизвестность имеет владельца и способ уменьшения;
acceptance criteria выражают наблюдаемое поведение;
полный scope не объявлен возможным только потому, что дата уже обещана;
отказ сопровождается моделью и вариантами;
альтернативы сохраняют исходную цель;
конфликт стейкхолдеров разложен по интересам и ответственности;
принятое решение зафиксировано вместе с его ценой;
прямое общение не превращается в скрытое изменение приоритетов;
команда защищена от нескольких независимых очередей работы;
requirement сохраняет связь с outcome после delivery.

Что лид должен унести из этого модуля

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

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

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

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

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

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

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

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

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

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

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

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