Работа со стейкхолдерами: конфликты интересов, приоритеты, согласования

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

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

Эта статья — про механику. Не про «умение выстраивать коммуникацию», а про конкретные процедуры: как составить карту стейкхолдеров, чтобы в ней не было дыр; как за три вопроса дойти от позиции до метрики; как отличить конфликт, который решается SQL-запросом, от конфликта, который решается только чужой подписью; как записать решение так, чтобы через полгода никто не сказал «мы так не договаривались».

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

1. Стейкхолдер — это не «начальник», а источник или владелец требования

Слово испорчено переводом. «Заинтересованное лицо» звучит как «человек, которого надо удовлетворить». Рабочее определение другое и куда полезнее:

Стейкхолдер — это тот, кто может дать вам требование, отменить его или сорвать его реализацию. Всё остальное — просто коллеги.

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

1.1. Четыре типа власти над требованием

Постоянная ошибка — путать эти роли и обращаться со всеми одинаково: рассылать всем всё и ждать от всех согласования.

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

1.2. Круги: кого вспоминают последним

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

Практический смысл картинки в одном: круг 3 нужно проверять первым, хотя вспоминают его последним. Круг 1 при пропуске стоит переделки спринта — неприятно, но обратимо. Круг 3 при пропуске стоит запрета на приёмке, когда разработка уже сделана: у безопасности, юристов и регулятора нет «мнения», у них есть требования, которые нельзя обойти голосованием.

1.3. Тест на полноту карты: восемь вопросов

Карта стейкхолдеров почти никогда не бывает полной с первого раза. Быстрый способ найти дыры — прогнать изменение по восьми вопросам. Каждый «не знаю» — это стейкхолдер, которого нет в вашем списке.

1. Кто платит за эту работу и из какого бюджета?
2. Кто будет этим пользоваться ежедневно — руками, а не в отчёте?
3. Кто это эксплуатирует и поддерживает — кому придут тикеты, когда сломается?
4. Кто может запретить — по закону, регламенту, договору, политике безопасности?
5. Кто теряет от изменения: работу, контроль, значимость, привычный порядок?
6. Чьи данные мы читаем или пишем и кто отвечает за их достоверность?
7. Кто узнает об этом от клиента — поддержка, продажи, аккаунты?
8. Кто будет это сопровождать через два года, когда все мы уйдём?

Восьмой вопрос — не философия. Будущий сопровождающий — реальный стейкхолдер с реальными требованиями (логи, наблюдаемость, миграция, отсутствие уникальных ручных шагов), и он никогда не приходит на совещания, потому что его ещё не наняли. Его требования обычно озвучивает разработка, и именно поэтому «нефункциональные хотелки разработчиков» — не хотелки, а голос отсутствующего стейкхолдера; подробнее — в НФТ.

Типовые забытые роли, по частоте: поддержка (её никогда не спрашивают, но она получит все последствия), бухгалтерия (узнаёт о фиче при закрытии периода), склад и логистика, обучение персонала (новый процесс требует инструкции и тренинга), ИБ, DPO и юристы, партнёры, у которых интеграция с вашим API, аналитики отчётности (вы поменяли поле — у них рассыпался дашборд).

2. Карта стейкхолдеров как рабочий артефакт, а не слайд

2.1. Реестр, который вы правда будете вести

Реестр полезен, когда в нём есть колонки, которыми вы пользуетесь. Классическая таблица «ФИО — должность — роль в проекте» бесполезна: она не помогает принять ни одного решения. Рабочий минимум:

Две колонки делают этот реестр рабочим, и обе часто пропускают.

Метрика, по которой человека оценивают. Это самый сильный предсказатель его поведения на любом согласовании. Человек не «упирается» — он защищает число, за которое отвечает перед своим руководителем. Пока вы не знаете это число, вы спорите с симптомом.

Отношение и его динамика. «Не знает о проекте» — тоже статус, и самый опасный, если рядом стоит «вето». Разница между «против» и «не знает» определяет ваш следующий шаг: с первым нужно разговаривать про интересы, второму нужно просто вовремя рассказать.

Реестр — живой документ на 10–20 строк, а не результат «анализа стейкхолдеров» на 60 слайдов. Он обновляется, когда меняется расстановка, и умирает вместе с проектом.

2.2. Власть и интерес: куда тратить своё время

Времени аналитика мало, и распределять его по всем поровну — верный способ не поговорить ни с кем достаточно глубоко. Матрица «власть — интерес» (её популяризовали Джонсон и Скоулз в «Exploring Corporate Strategy») отвечает не на вопрос «кто важнее», а на вопрос «какой формат общения выбрать».

Как это читается на практике:

• Верх-право (высокий интерес, высокое влияние). Ваш основной рабочий контакт. Регулярные короткие встречи, черновики до того, как они станут документами, никаких сюрпризов.
• Верх-лево (влияние есть, интереса нет). Самая коварная зона: ИБ и юристы не ходят на ваши демо, но могут остановить релиз. С ними работают форматом «одно ревью на входе и одно на выходе», предельно конкретно и по их языку — регламент, риск, ответственность.
• Низ-право (интерес есть, влияния нет). Операторы и клиенты — лучший источник фактов и неявных требований, и худший источник приоритетов. Их надо слушать и наблюдать, но не делать их выбор источником решений: у них нет ни бюджета, ни ответственности за компромисс.
• Низ-лево. Одно письмо, один вопрос, дальше — в рассылку «информируемые».

Осторожно с прямым переносом матрицы в поведение. У неё есть неприятное свойство: она подталкивает игнорировать «низ-лево», а именно там сидят люди, которые узнают о фиче последними и создают потом основную массу возражений. Полезная поправка — модель salience Митчелла, Эгла и Вуда (1997): у стейкхолдера три независимых признака — власть, легитимность и срочность. Тот, у кого есть легитимность без власти (например, конечный пользователь), обязан быть услышан по существу, даже если ничего не может.

2.3. Прокси и теневой заказчик

Две конфигурации, в которых карта врёт, даже когда формально заполнена.

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

Теневой заказчик. Формально решение принимает владелец продукта, фактически — человек, который ему звонит вечером. Симптомы: решения переворачиваются между встречами без новых фактов; на встрече все согласны, а потом «мы передумали»; формулировки в задаче меняются на лексику, которой не было в комнате. Ход простой и почти всегда работающий: попросить, чтобы этот человек пришёл, или чтобы его позиция была изложена письменно. Не разоблачать, а перевести неявное влияние в явное: «Похоже, по этому вопросу есть позиция Иванова. Давайте я подготовлю варианты и получим её до пятницы, чтобы не переделывать дважды».

3. Позиции, интересы и метрики: где на самом деле живёт решение

Ключевая техника всей статьи, и она одна даёт больше, чем любые фреймворки согласования. Взята она из переговорной практики — Фишер и Юри, «Getting to Yes» (williamury.com): различайте позицию (что человек требует) и интерес (зачем ему это). Позиции почти всегда несовместимы. Интересы — почти всегда совместимы. Аналитик добавляет к этому третий слой: метрику, по которой человека оценивают, потому что в корпоративной среде именно она определяет, насколько жёстко он держит позицию.

3.1. Скрипт, который работает

Дословно, четыре хода. Работает и в интервью, и посреди совещания, где спор пошёл по кругу.

1. Зафиксировать позицию без искажения:
   «Правильно понимаю: без подписанного акта списание не проходит — вообще никогда?»
   (Часто уже здесь: «ну, кроме случаев до тысячи рублей» — граница нашлась.)

2. Спросить про цель, а не про причину:
   «Что для вас изменится к лучшему, если так будет?»
   Не «почему вы так хотите» — этот вопрос звучит как обвинение и включает защиту.

3. Спросить про число:
   «По какому показателю оценивают вашу работу в этой части? Что вы объясняете,
   если он поедет?»

4. Спросить про страх:
   «Что самое неприятное произойдёт, если мы сделаем наоборот?
   Кто первым это заметит и что скажет?»

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

3.2. Почему компромисс по середине — худший из вариантов

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

Решение почти всегда имеет другую форму — разделение по условию, а не смешивание:

• по сумме: до порога автоматически, выше — вручную;
• по типу клиента: для проверенных — быстро, для новых — с контролем;
• по времени: сначала деньги, потом досбор документов асинхронно;
• по риску: рискованное подмножество отделяется правилом, остальные 90% идут быстро.

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

4. Диагностика: шесть типов конфликта и что с каждым делать

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

4.1. Конфликт факта: решается запросом, а не совещанием

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

-- Сколько заказов имеют больше одного плательщика и на какую сумму — за 12 месяцев.
-- Один такой запрос закрывает часовой спор о том, «бывает ли такое вообще».
SELECT date_trunc('month', o.created_at)   AS month,
       count(*)                            AS orders_multi_payer,
       round(sum(o.total_amount))          AS amount_rub
FROM orders o
JOIN (
    SELECT order_id
    FROM payments
    WHERE status = 'captured'
    GROUP BY order_id
    HAVING count(DISTINCT payer_id) > 1
) m ON m.order_id = o.id
WHERE o.created_at >= now() - interval '12 months'
GROUP BY 1
ORDER BY 1;

Правило: никогда не проводите встречу, чтобы обсудить то, что можно посчитать. Считайте до встречи и приносите цифру. Обратная сторона: цифра должна быть воспроизводимой — приносите запрос вместе с числом, иначе спор о факте превратится в спор о вашем запросе. Полезно заранее договориться, какой источник считается истиной: без этого «в CRM 4200, а в хранилище 3980» рождает новый конфликт вместо закрытия старого.

4.2. Конфликт словаря: два человека спорят о разных вещах

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

Лечение — не «давайте введём терминологию», а два конкретных хода: привести три примера на границе («вот это клиент? а вот это?») и записать различие в глоссарий с указанием контекста. Именно здесь смыкаются анализ и DDD: разные смыслы одного слова — это признак разных контекстов, а не небрежности людей (см. ограниченные контексты и event storming).

4.3. Конфликт цели: единственный, который вы не разрешите сами

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

Что вы можете и обязаны сделать: сформулировать конфликт письменно в терминах интересов, собрать 2–3 варианта, посчитать цену каждого в единицах, которые понимает владелец решения (деньги, срок, риск, люди) — и передать выбор наверх. Это не «спихнуть ответственность»: выбор между потерей клиентов и риском списаний — это управленческое решение, а не аналитическое. Ваша ответственность — чтобы выбор был осознанным, задокументированным и сделанным вовремя.

4.4. Конфликт ресурса: спор не о смысле, а об очереди

Оба отдела правы, оба нужны, ёмкость команды одна. Разбор — в разделе про приоритеты.

4.5. Конфликт полномочий: «а кто вообще это решает?»

Симптом: решение принимается, потом отменяется, потом принимается снова; каждый участник уверен, что последнее слово его. Пока владелец не назван явно, любое согласование — это черновик. Лечение — назначить владельца решения до обсуждения, а не после, и назвать его вслух: «по этому вопросу решает Соколова, мы — готовим варианты». Механику см. в 7.1.

4.6. Конфликт ответственности: человек защищает не процесс, а себя

Самый недооценённый тип. Человек блокирует удобное решение не потому, что не понимает выгоды, а потому, что при плохом исходе объясняться будет он. Аргументы про пользу клиента здесь не работают вообще. Работает изменение конструкции: автоматическая проверка вместо его подписи, лимит, порог, лог с обоснованием, отчёт, который он сможет предъявить, явная запись «решение принято таким-то, риск принят». Дайте человеку то, чем он сможет отчитаться, — и «нет» превращается в «да» без единого аргумента о ценности.

4.7. Сводная таблица

5. Карточка конфликта: как выглядит правильно зафиксированное расхождение

Пока противоречие живёт в переписке, оно неуправляемо. Первый инженерный шаг — сделать его объектом со своим идентификатором и владельцем, как дефект. Ровно поэтому «конфликт» попадает в трекер, а не остаётся «вопросом, который надо бы обсудить».

Плохо (сглажено формулировкой, противоречие спрятано):

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

Такой текст пройдёт любое согласование, потому что каждый прочитает в нём себя. И развалится на первой реализации, потому что «быстро» и «все процедуры» одновременно невозможны.

Хорошо (противоречие названо, стороны названы, цена посчитана, срок стоит):

C-05 · Конфликт: скорость возврата против подтверждённого основания
Тип: конфликт цели (метрики сторон несовместимы)

Сторона A — коммерция (Соколова): деньги клиенту в течение 1 часа.
  Интерес: не потерять клиента. Метрика: повторные покупки после возврата.
Сторона B — финансы (Петров): списание только после подтверждённого основания.
  Интерес: не платить дважды. Метрика: расхождения при закрытии месяца.
Почему одновременно невозможно: подтверждение основания занимает до 2 рабочих дней
  (замер по 40 обращениям за март, см. ссылку).

Затронуто: BR-3, US-142, US-147, NFR-9.
Владелец решения: Волкова (владелец продукта).
Нужно решение до: 14.05, иначе US-142 уходит из спринта 21 (команда не может
  реализовать обе трактовки).
Что делаем по умолчанию, если решения нет: остаётся текущий процесс (2 дня),
  US-142 переносится.

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

6. Приоритеты: одна очередь и цена отказа

6.1. Почему MoSCoW вырождается

Схема Must / Should / Could / Won’t (из DSDM, agilebusiness.org) хороша ровно до момента, когда приоритет назначает каждый стейкхолдер сам за себя. Итог предсказуем: 90% требований — Must, потому что «Should» читается как «вам это не нужно», а никто не хочет быть отделом, чьи требования необязательны.

Работает MoSCoW только с двумя дополнениями: Must определяется не важностью, а невозможностью выпустить релиз без этого («без этого мы не имеем права выпускать по закону / продукт физически не работает»), и на Must выделяется не больше 60% ёмкости — иначе первая же задержка съедает всё остальное. Оба дополнения есть в исходном DSDM и оба обычно теряются.

6.2. Приоритет — это не важность, это цена отказа

Вопрос «насколько это важно?» бесполезен: важно всё. Работающая переформулировка меняет предмет разговора с самолюбия на арифметику:

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

Ответы делятся на три категории, и это уже приоритет:

• «Ничего, подождём» — не приоритет, каким бы уверенным ни был тон запроса.
• «Отдел будет делать вручную, это 3 человеко-дня в неделю» — измеримая цена ожидания; сравнивается с ценой других задач напрямую.
• «Штраф регулятора / встанет отгрузка / нарушим договор с 12 мая» — жёсткий срок, идёт вне общего сравнения, в отдельную очередь.

Это ядро идеи cost of delay Дональда Рейнертсена («The Principles of Product Development Flow») и производного от неё WSJF: сравниваются не «важности», а отношение цены задержки к размеру работы. Формулу и её ограничения разбирает приоритизация в Product management; здесь важна политическая сторона: как только приоритет считается по цене отказа, спор перестаёт быть спором о статусе отделов.

6.3. Квоты вместо спора: механика, снимающая конфликт ресурса

Самое устойчивое решение конфликта ресурса — договориться заранее не о задачах, а о долях ёмкости. «Коммерция — 40% спринта, техдолг — 20%, поддержка и инциденты — 20%, регуляторика — 20%». Дальше внутри своей квоты отдел приоритизирует сам, и это его право. Спор «моя задача важнее вашей» превращается в спор внутри квоты, где стороны наконец имеют одинаковые цели.

from dataclasses import dataclass

@dataclass(frozen=True)
class Request:
    id: str
    source: str          # отдел-заказчик: за ним закреплена квота ёмкости
    delay_cost: float    # цена недели ожидания, тыс. руб. (потери или неполученная выгода)
    size: float          # оценка команды, человеко-дни
    hard_deadline: bool  # есть внешний срок: закон, договор, партнёрская интеграция


def score(r: Request) -> float:
    """Приоритет = цена недели ожидания на единицу работы (идея WSJF Рейнертсена).
    Дешёвое и болезненное обгоняет дорогое и терпимое — а не наоборот."""
    return r.delay_cost / max(r.size, 0.5)


def plan(requests: list[Request], capacity_days: float,
         quotas: dict[str, float]) -> tuple[list[Request], list[Request]]:
    """Раскладывает запросы по согласованным квотам источников.

    quotas — доли ёмкости спринта, о которых договорились ЗАРАНЕЕ, {'коммерция': 0.4, ...}.
    Сортировка O(n log n) по времени, раскладка O(n), память O(n).
    Смысл не в оптимальности плана, а в том, что отказ становится объяснимым:
    не «ваша задача неважная», а «квота отдела на этот спринт исчерпана».
    """
    budget = {src: capacity_days * share for src, share in quotas.items()}
    taken: list[Request] = []
    deferred: list[Request] = []

    for r in sorted(requests, key=score, reverse=True):
        if r.hard_deadline:
            # внешние сроки идут вне квот, но обязательно видимо: они съедают чужую ёмкость
            taken.append(r)
            budget[r.source] = budget.get(r.source, 0.0) - r.size
            continue
        if budget.get(r.source, 0.0) >= r.size:
            budget[r.source] -= r.size
            taken.append(r)
        else:
            deferred.append(r)  # не «отказ», а «не в этот спринт, причина — квота»

    return taken, deferred

Код здесь важен не как алгоритм (он тривиален), а как явная модель договорённости. Когда правило записано и считается одинаково для всех, разговор про приоритеты перестаёт зависеть от того, кто громче. И обратите внимание на строку с hard_deadline: жёсткие сроки не «весят больше» — они выносятся из общего сравнения и явно уменьшают чью-то квоту. Скрытый регуляторный проект, съевший половину спринта, — типовая причина, по которой «мы же договорились» перестаёт работать.

6.4. Форматы, которые работают в комнате

Когда нужно расставить приоритеты между людьми, а не в таблице:

• Принудительное ранжирование. Не «оцените важность от 1 до 5» (все поставят 5), а «разложите эти двенадцать карточек в один столбик, двух одинаковых мест нет». Дефицит мест делает всю работу.
• Сто очков. Каждому стейкхолдеру — 100 очков на распределение между требованиями. Показывает не только приоритеты, но и структуру интересов: кто вложил всё в одно, кто размазал.
• «Купи фичу». Требования получают цену в единицах ёмкости, бюджет группы заведомо меньше суммы цен, покупать дорогое можно только в складчину (Люк Хоманн, Innovation Games, innovationgames.com). Прекрасно вскрывает ложные Must: то, за что никто не готов платить своей долей, не было приоритетом.
• Impact mapping (Гойко Аджич, impactmapping.org) — когда спор идёт не о порядке задач, а о том, чья задача вообще ведёт к цели: цель → актёры → их изменения в поведении → и только потом фичи. Половина «критичных» требований на этой карте оказывается ни к какой цели не подключена.

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

7. Согласование: механика, которая не разваливается через неделю

7.1. «Согласовать» — это не «спросить мнение»

Главная причина зависших согласований — все участники в одной роли «те, кого спросили». Любая рабочая схема начинается с разделения ролей в решении. Простейшая — DACI (Atlassian Team Playbook):

Более подробная схема — RAPID от Bain (bain.com), где отдельно выделено право входа (Input) и право вето внутри Agree. Выбор схемы не важен; важны два инварианта, которые нарушают чаще всего:

1. Ровно один Approver. «Решают вместе руководители трёх департаментов» означает «не решает никто». Если владельца не удаётся назвать — это и есть находка, и первый вопрос на эскалации.
2. Согласующих должно быть мало, и у каждого должно быть основание для вето. Вето «мне не нравится» не является вето. Хорошая практика — писать рядом с каждым согласующим, чем именно он вправе заблокировать: ИБ — политикой обработки ПДн, юристы — договором, финансы — порядком списаний.

7.2. Путь спорного требования

Как это выглядит целиком, от запроса до обновлённых критериев приёмки.

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

7.3. Жизненный цикл спорного требования

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

Два перехода в этой схеме — профессиональные приёмы, а не формальность.

S8 → S5 «применён вариант по умолчанию». Молчание — тоже решение, и его надо сделать явным заранее: «если до 14.05 возражений не будет, реализуем вариант C». Это переносит издержку молчания на молчащего и радикально ускоряет согласования с перегруженными людьми. Формулировать нужно аккуратно: вариант по умолчанию должен быть безопасным и обратимым, иначе вы протаскиваете решение через чужую занятость.

S7 → S9 «по новым фактам, а не новым эмоциям». Условие пересмотра надо записать заранее: «вернёмся к порогу, если доля автоподтверждённых возвратов с расхождением превысит 2% за месяц». Без такого условия любое решение переоткрывается по желанию любой стороны, и работа превращается в бесконечное перерешивание.

7.4. Запись решения: минимум, который спасает через полгода

Формат — прямой родственник ADR из архитектуры (Майкл Найгард, cognitect.com, см. также архитектурные решения). Ключевая мысль та же: записывается не только выбор, но и отвергнутые варианты с причинами — иначе через полгода кто-то предложит вариант B как свежую идею.

id: D-014
title: Порог автоматического подтверждения возврата
status: accepted            # proposed | accepted | superseded
date: 2026-05-14
decision_owner: Волкова А., владелец продукта     # ровно один человек
context: >
  Коммерция требует возврата денег в течение часа, финансы — подтверждённого
  основания до списания. Подтверждение занимает до 2 рабочих дней (замер по 40
  обращениям за март), поэтому одновременно требования невыполнимы.  
options:
  - id: A
    summary: ручное подтверждение всех возвратов
    price: срок возврата 2 дня, дополнительный оператор, риск оттока
  - id: B
    summary: автоподтверждение всех возвратов
    price: оценка финансов — до 1,2 млн руб. в год невозвратных списаний
  - id: C
    summary: порог 5000 руб. плюс автоматическая сверка остатков
    price: 8 человеко-дней разработки; автоматически проходят 87% возвратов
decision: C
rationale: >
  Порог покрывает основную массу обращений и оставляет ручной контроль там,
  где сумма оправдывает его стоимость. Финансы получают лог оснований.  
consulted: [финансы (Петров), коммерция (Соколова), склад (Ким), ИБ (Раев)]
informed: [поддержка, бухгалтерия, обучение персонала]
affects: [BR-3, US-142, US-147, NFR-9]
review_trigger: >
    доля автоподтверждённых возвратов с расхождением по остаткам превысит 2% за месяц

Где это живёт — вопрос второй: страница в вики, файл в репозитории, поле в задаче. Важно одно: решение находится поиском по номеру требования. Решение, которое нельзя найти за минуту, не существует. И симметрично: протокол встречи — не место для решений. Ведите протокол решений, а не протокол обсуждения: три строки «решили — кто владелец — что дальше» полезнее двух страниц пересказа дискуссии, которые никто не откроет.

7.5. Реестр решений как модель данных

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

Два соотношения здесь содержательны. DECISION ||--o{ REQUIREMENT : изменяет — это трассировка в обратную сторону: по требованию видно, каким решением оно таким стало (подробнее о трассировке — документирование и моделирование данных). А DECISION }o--|| STAKEHOLDER с кардинальностью «ровно один» — не педантизм схемы, а то самое правило про одного Approver, выраженное в модели: два владельца одного решения структурно невозможны.

8. Эскалация без потери отношений

Эскалация имеет плохую репутацию, потому что её путают с жалобой. Разница простая:

• Жалоба приносит руководителю проблему и эмоцию: «финансы блокируют нам работу».
• Эскалация приносит подготовленный выбор: варианты, цена каждого, срок, вариант по умолчанию, если решения не будет.

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

Кому: Волкова А. (владелец продукта)
Копия: Соколова (коммерция), Петров (финансы)
Тема: Решение до 14.05 — порог автоподтверждения возврата (C-05, блокирует US-142)

Нужно ваше решение по одному вопросу. Обе стороны видели это письмо
и подтвердили, что позиции изложены верно.

Суть: возврат «в один клик» и обязательное подтверждённое основание одновременно
невыполнимы — подтверждение занимает до 2 дней (замер по 40 обращениям за март).

Варианты:
  A. Подтверждать всё вручную. Срок возврата 2 дня, нужен +1 оператор.
     Риск оттока — оценка коммерции 3–4% от вернувшихся клиентов.
  B. Подтверждать автоматически всё. Срок — 1 час.
     Риск невозвратных списаний — оценка финансов до 1,2 млн руб. в год.
  C. Порог 5000 руб. + автосверка остатков: 87% возвратов за час, остальное вручную.
     Стоимость 8 человеко-дней. Обе стороны считают вариант приемлемым, но
     расходятся в величине порога (коммерция — 15 000, финансы — 3000).

Что нужно от вас: выбрать вариант и, если C, — величину порога.
Срок: 14.05. Дальше US-142 уходит из спринта 21 — команда не может писать код
под две трактовки.
Если ответа не будет: остаётся текущий процесс (2 дня), задача переносится.

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

Отдельно: сначала предупредите стороны, потом эскалируйте, и никогда не наоборот. Формула на две фразы: «Мы с вами не сходимся по порогу, и это нормально — это управленческий выбор. Я опишу оба варианта с ценой и отправлю Волковой, вам в копии; проверьте, что вашу позицию я изложил правильно». После такого письма отношения не портятся почти никогда.

9. Что ломается чаще всего

Четыре классических класса поломок в требованиях (см. обзор трека) в разрезе людей выглядят иначе — и лечатся иначе тоже.

9.1. Неявные требования тех, кого не спросили

Механика: требование не «забыли записать» — его некому было произнести. Поддержка узнаёт о фиче из тикетов, бухгалтерия — при закрытии периода, ИБ — на предпродакшн-ревью. Их требования существуют и жёстки, просто их не было в комнате.

Лечение — процедурное, не героическое: восемь вопросов из 1.3 на входе в каждую заметную фичу и правило «ни одна фича не идёт в разработку, пока в списке участников нет представителя каждого затронутого круга». Дешёвый заменитель, если позвать некого: пройтись по чек-листу их типовых требований (журналирование, отчётность, обучение, ПДн, права доступа, что видит поддержка при разборе обращения).

9.2. Противоречие, спрятанное вежливостью

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

Приёмы, которые вскрывают тишину:

• Не «есть возражения?», а «кому это создаёт проблему?» Первый вопрос требует смелости, второй — компетентности; отвечать на второй социально безопасно.
• Проговорить решение от лица каждой стороны: «Значит, финансы согласны списывать до 5000 без акта — Пётр Сергеевич, это так звучит?» Пересказ чужой позиции своими словами вытаскивает несогласие, которое молчало.
• Письменное подтверждение асинхронно. Многие возражают в письме гораздо охотнее, чем в комнате при руководителе. Пятнадцать минут на прочтение резюме и ответ «да/нет/уточнение» находят больше расхождений, чем час обсуждения.
• Показать не текст, а прототип или схему. Одинаково прочитать картинку сложнее, чем одинаково кивнуть на абзац.

9.3. «Хотелка» как политика

Иногда запрос без задачи — не небрежность формулировки, а инструмент: нужна фича, чтобы обосновать бюджет отдела, показать активность в квартальном отчёте, «не отстать» от соседней команды. Признаки: требование сформулировано как решение и не выдерживает вопроса «что вы будете делать с результатом»; заявитель теряет интерес, как только вы предлагаете более дешёвый способ решить ту же задачу; срочность привязана к дате отчётности, а не к событию в бизнесе.

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

9.4. Непроверяемое требование как право на вето

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

Лечение — не спор о формулировке, а перевод в проверяемое вместе с автором и до разработки: «Давайте так: оператор оформляет возврат за 90 секунд без обращения к инструкции, 8 из 10 операторов на замере. Это будет означать «удобно»?» Если человек соглашается — у вас есть критерий приёмки. Если отказывается — вы обнаружили, что критерия не существует и приёмка будет по настроению; это находка, и её надо зафиксировать письменно вместе с риском. Техника перевода — НФТ, процедура приёмки — приёмка.

9.5. «Согласовали, но не читали»

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

9.6. HiPPO и самый громкий голос

HiPPO — highest paid person’s opinion. Мнение самого высокооплачиваемого человека в комнате весит больше данных не потому, что кто-то злоупотребляет властью, а потому, что остальные перестают спорить. Соседний паттерн — «самый громкий стейкхолдер»: приоритеты достаются тому, кто чаще пишет.

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

10. Разговор или документ: что решается голосом, а что письмом

Общее правило формальности артефактов разобрано в обзоре трека. Для согласований работает более узкое и очень практичное разделение:

Разговор — чтобы найти решение. Письмо — чтобы его зафиксировать. Попытка найти решение в переписке даёт тред на сорок писем; попытка зафиксировать решение голосом даёт «мы так не договаривались».

Три ошибки формата, стоящие дорого:

1. Решение в чате. Через месяц не найдёт никто, включая автора. Минимум — перенести в задачу или в реестр решений тем же днём.
2. Согласование по почте вкруговую. Восемь человек в копии, ни одного владельца: каждый ждёт, пока ответит другой. Лечится назначением Approver и явным «от вас нужно только одно: да или нет по порогу, до пятницы».
3. Встреча вместо письма. Если вам нужно только подтверждение, не собирайте людей: письмо с явным вариантом по умолчанию дешевле часа шестерых.

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

11. Сквозной кейс: от карты до обновлённых критериев приёмки

Соберём всё вместе на том же примере возвратов. Хронология одной рабочей недели.

Шаг 1. Карта (полдня). Восемь вопросов из 1.3 дают неожиданное: у фичи «возврат в один клик» есть склад (списание и приём товара), бухгалтерия (корректировочные документы), ИБ (ПДн в основании возврата) и партнёр-маркетплейс, у которого свой регламент возвратов. В исходном запросе не было никого, кроме коммерции.

Шаг 2. Интересы (один день, четыре разговора по 30 минут). Выясняется, что финансы не против скорости — они против списания без основания; склад не против скорости — он против расхождения остатков. Два «против» из четырёх снялись сами: это были конфликты словаря («возврат» для склада — приём товара, для финансов — движение денег; это два разных события, и их можно развести по времени).

Шаг 3. Диагноз (полчаса). Остался один настоящий конфликт цели: скорость денег против подтверждённого основания. Заводится карточка C-05 (раздел 5) со сроком и вариантом по умолчанию.

Шаг 4. Факты (два часа). Замер: сколько времени реально занимает подтверждение (до 2 дней), какая доля возвратов до 5000 (87%), сколько было списаний без основания за год и на какую сумму. Здесь же — SQL-проверка гипотезы про несколько плательщиков (раздел 4.1): таких заказов 0,3%, но это половина спорных возвратов, и правило для них придётся описать отдельно.

Шаг 5. Варианты и цена (полдня). A, B, C с ценой в понятных владельцу единицах. Вариант C сформулирован не как «компромисс», а как разделение по границе — и обе стороны считают его приемлемым, расходясь только в величине порога.

Шаг 6. Согласование (один день). Стороны видят текст, поправляют формулировку своих позиций, эскалация уходит владельцу продукта с одним вопросом: величина порога.

Шаг 7. Решение и запись (час). Решение D-014 записано (раздел 7.4), стороны уведомлены ссылкой, условие пересмотра зафиксировано.

Шаг 8. Требования обновлены. И вот главное, чем работа со стейкхолдерами отличается от переговоров вообще: решение обязано долететь до текста, по которому будут делать и принимать.

Было:

Сценарий: возврат средств за возвращённый товар
  Дано клиент оформил возврат
  Когда заявка обработана
  Тогда деньги возвращаются клиенту в кратчайшие сроки

Стало (решение D-014 «прошито» в критерии, каждый пункт проверяем):

Сценарий: сумма возврата в пределах порога автоподтверждения
  Дано заказ оплачен одним плательщиком на сумму 3200 руб.
  И расхождений по остаткам товара нет
  Когда оператор подтверждает заявку на возврат
  Тогда возврат средств инициируется без акта
  И запись об автоматическом основании появляется в журнале возвратов
  И статус заявки меняется на «возврат инициирован» не позднее 60 секунд

Сценарий: сумма возврата выше порога
  Дано заказ оплачен на сумму 12 400 руб.
  Когда оператор подтверждает заявку на возврат
  Тогда система запрашивает акт с подписью
  И возврат средств не инициируется до загрузки акта

Сценарий: заказ с несколькими плательщиками (решение D-014, п. 4)
  Дано заказ оплачен двумя плательщиками
  Когда оператор подтверждает заявку на возврат
  Тогда заявка направляется на ручное подтверждение независимо от суммы

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

12. Метрики здоровья согласований

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

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

Стандартная оговорка про закон Гудхарта: любую из этих метрик легко испортить, сделав целью. «Ноль конфликтов» — не здоровье, а слепота: конфликты есть всегда, вопрос лишь в том, находите вы их до разработки или после. Здоровое состояние — конфликты обнаруживаются рано, имеют владельца и срок и закрываются записанным решением.

Мини-итог

• Стейкхолдер — это тот, кто может дать требование, отменить его или сорвать реализацию. Различайте четыре типа власти: источник, владелец решения, вето, информируемый; путаница ролей — половина зависших согласований.
• Круг 3 (ИБ, юристы, регулятор, партнёры) вспоминают последним, а проверять надо первым: у них не мнения, а запреты.
• Позиции несовместимы, интересы обычно совместимы, метрики объясняют жёсткость. Докапывайтесь до числа, по которому человека оценивают, и до его страха.
• Компромисс по середине рождает требование-химеру. Решение почти всегда имеет форму «разделение по условию»: порог, тип, время, риск.
• Ставьте диагноз до лечения. Конфликт факта решается запросом, словаря — примерами на границе, ресурса — квотами, полномочий — назначением владельца, ответственности — защитой человека, цели — эскалацией с вариантами и ценой.
• Приоритет — это цена отказа, а не важность. Заранее согласованные квоты ёмкости снимают больше конфликтов, чем любая формула.
• Ровно один Approver. У каждого согласующего должно быть основание для вето; «мне не нравится» основанием не является.
• Эскалация — это подготовленный выбор с ценой и сроком, а не жалоба. Стороны видят текст заранее — всегда.
• Разговор — чтобы найти решение, письмо — чтобы зафиксировать. У решения есть владелец, дата, отвергнутые варианты и условие пересмотра.
• Решение обязано долететь до критериев приёмки. Если не долетело — его не было.

Источники

• IIBA. BABOK Guide v3 — iiba.org (задачи Stakeholder Analysis, Manage Stakeholder Collaboration, RACI).
• Karl Wiegers, Joy Beatty. Software Requirements, 3rd ed. — karlwiegers.com (главы о стейкхолдерах, о конфликтах приоритетов и «Requirements Bill of Rights» — список того, на что клиент вправе рассчитывать, и того, что он обязан делать сам).
• Roger Fisher, William Ury. Getting to Yes — williamury.com (позиции против интересов, объективные критерии, BATNA).
• Douglas Stone, Bruce Patton, Sheila Heen. Difficult Conversations — triadconsultinggroup.com (как вести разговор, где стороны расходятся в фактах, эмоциях и представлении о себе).
• Ellen Gottesdiener. Requirements by Collaboration — ebgconsulting.com (форматы воркшопов, где решение принимают несколько сторон).
• Ronald Mitchell, Bradley Agle, Donna Wood. Toward a Theory of Stakeholder Identification and Salience, AMR 1997 — doi.org/10.5465/amr.1997.9711022105 (власть, легитимность, срочность).
• Bain & Company. RAPID decision making — bain.com.
• Atlassian Team Playbook. DACI — atlassian.com.
• Donald Reinertsen. The Principles of Product Development Flow — reinertsenassociates.com (cost of delay как язык приоритетов); WSJF в SAFe — scaledagileframework.com.
• Agile Business Consortium (DSDM). MoSCoW prioritisation — agilebusiness.org (в оригинале Must ограничен долей ёмкости — то, что обычно теряют).
• Luke Hohmann. Innovation Games, «Buy a Feature» — innovationgames.com.
• Gojko Adzic. Impact Mapping — impactmapping.org (акторы и их изменения в поведении вместо списка фич).
• Michael Nygard. Documenting architecture decisions — cognitect.com; каталог форматов — adr.github.io.
• Amazon. Leadership Principles, «Have Backbone; Disagree and Commit» — amazon.jobs (несогласие проговаривается до решения, после решения его исполняют все).
• ISO/IEC/IEEE 29148:2018, Requirements engineering — iso.org (процесс определения требований стейкхолдеров, включая согласование и трассировку).

Что дальше

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

Аналитик в Agile: груминг, декомпозиция, работа с командой и с неопределённостью