Стейкхолдеры, влияние без полномочий и операционка продакта

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

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

1. Влияние без полномочий

1.1. Почему у продакта нет власти — и почему это разумно

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

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

1.2. Шесть источников влияния

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

1.3. Формула доверия

Дэвид Майстер в «The Trusted Advisor» предлагает удобную рамку:

доверие = (надёжность + компетентность + близость) / ориентация на себя

Знаменатель — самая важная часть. Как только собеседник видит, что вы продвигаете свою идею ради себя (KPI, повышение, «мой проект»), всё, что в числителе, обесценивается. Отсюда практическая техника, которая звучит банально и работает: формулируйте решение в терминах цели собеседника, а не своей. «Это ускорит выход enterprise-сделок, которые стоят у вас в плане» — аргумент; «это важно для моего роадмапа» — не аргумент.

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

2.1. Кто вообще влияет на продукт

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

2.2. Четыре режима вовлечения

Для каждого стейкхолдера по каждому классу решений заранее определяется режим:

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

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

2.3. RACI и его вырождение

Матрица RACI (Responsible, Accountable, Consulted, Informed) полезна ровно до тех пор, пока в колонке A (accountable) один человек, а в C — не более трёх. На практике матрица вырождается: в «согласующие» попадают все, кто когда-либо возражал. Цена измерима — число согласований растёт линейно, а число связей между ними квадратично:

def coordination_cost(approvers: int, days_per_pair: float = 0.4,
                      days_per_approver: float = 1.5) -> dict:
    """Грубая модель времени согласования.

    Каждый согласующий требует своего времени (last-mile), а каждая пара
    согласующих порождает потенциальный конфликт мнений, который тоже
    надо разрешить: пар C(n,2) = n*(n-1)/2 — тот самый квадратичный рост
    коммуникационных связей, о котором писал Брукс в «Мифическом человеко-месяце».

    Время: O(1), память: O(1).
    """
    pairs = approvers * (approvers - 1) / 2
    days = approvers * days_per_approver + pairs * days_per_pair
    return {"approvers": approvers, "pairs": int(pairs), "days": round(days, 1)}


for n in (1, 2, 3, 5, 8):
    print(coordination_cost(n))
# {'approvers': 1, 'pairs': 0,  'days': 1.5}
# {'approvers': 2, 'pairs': 1,  'days': 3.4}
# {'approvers': 3, 'pairs': 3,  'days': 5.7}
# {'approvers': 5, 'pairs': 10, 'days': 11.5}
# {'approvers': 8, 'pairs': 28, 'days': 23.2}

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

3. Форматы: письменно и заранее

3.1. Почему письменно

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

Практика Amazon — шестистраничный нарратив, который участники молча читают первые 20 минут встречи, — решает главную проблему предварительной рассылки: документ на самом деле никто не читает заранее.

3.2. Какой формат под какую задачу

Общий принцип текста для стейкхолдеров — вывод в первом абзаце, детали ниже, приложения в конце. Читатель принимает решение, а не изучает вашу работу (https://courses.digitable.life/post/technical-writing/01-reader-and-decision/).

3.3. One-pager, который работает

Решение, которое требуется: <одно предложение, что именно нужно от читателя>
Срок: <до какой даты, иначе что произойдёт>

Проблема:      кто страдает, насколько это часто и дорого — с числами
Свидетельства: данные, интервью, сделки; что мы уже проверили
Варианты:      A / B / C — каждый с ценой, сроком и риском
Рекомендация:  какой и почему; что должно быть верно, чтобы это сработало
Обратимость:   можно ли откатить и за сколько
Что не делаем: явный список отказов, чтобы не обсуждать их снова

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

4. Как принимаются решения

4.1. Обратимость важнее важности

Джефф Безос предложил делить решения на два типа: Type 1 — необратимые или дорого обратимые (смена ценовой модели, публичное обещание, удаление данных, выход из сегмента); Type 2 — обратимые за разумные деньги (тексты, порядок экранов, эксперимент, флаг).

Ошибка, которая парализует организации, — применять к Type 2 процедуру Type 1: три согласования и комитет ради изменения, которое откатывается за час. Обратная ошибка встречается реже, но дороже: принять Type 1 «на бегу».

4.2. Несогласие и обязательство

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

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

4.3. Журнал решений

Практика ведения журнала решений (что решили, на основании чего, кто владелец, когда пересматриваем) подробно разобрана в https://courses.digitable.life/post/product-management/08-analytics-and-decisions/. Здесь добавим одну коммуникационную функцию: журнал — главная защита от переигрывания. Вопрос «почему мы делаем X, а не Y» получает ссылку вместо часового совещания, а новый руководитель видит контекст без археологии.

5. Работа с командой разработки

5.1. Что продакт решает, а что нет

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

Рабочая формулировка задачи выглядит так: проблема + для кого + как поймём, что решили + ограничения. Решение остаётся за командой.

5.2. Продуктовое трио

Устойчивая конфигурация — продакт, дизайнер и инженер, которые вместе ходят на discovery и вместе принимают решения о решении (Марти Каган называет это product trio). Смысл не в ритуале, а в том, что инженер, слышавший клиента лично, предлагает другие решения — дешевле и точнее, чем при пересказе.

Процессная сторона совместной работы — в треке по управлению проектами: https://courses.digitable.life/post/project-management/01-agile-and-scrum/ и https://courses.digitable.life/post/project-management/05-team-and-communication/; роль владельца продукта в Scrum и работа с бэклогом — https://courses.digitable.life/post/scrum-master/06-product-backlog/.

5.3. Зависимости между командами

Когда решение упирается в чужую команду, работают три инструмента, в порядке предпочтения:

1. Убрать зависимость: сделать иначе, дешевле, у себя. Часто оказывается быстрее, чем ждать.
2. Договориться об интерфейсе: контракт, который позволяет двигаться параллельно (обе стороны работают против согласованного API или флага).
3. Договориться об очереди: явное обязательство с датой и с ответной услугой. Обмен — не манипуляция, а нормальная валюта: у вас тоже что-то просят.

Организационная сторона (границы команд, когнитивная нагрузка, типы взаимодействий) разобрана в https://courses.digitable.life/post/engineering-leadership/13-team-topologies/.

6. Продажи, поддержка и входящий поток

6.1. Контур обратной связи

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

6.2. Триаж входящих

from dataclasses import dataclass


@dataclass(frozen=True)
class Request:
    title: str
    source: str            # 'support' | 'sales' | 'exec' | 'team'
    accounts_affected: int
    arr_blocked: float     # деньги, которые стоят из-за этого, ₽
    has_workaround: bool
    breaks_core_flow: bool
    strategic_fit: float   # 0..1 — работает ли на текущую стратегию


def triage(r: Request) -> dict:
    """Маршрутизация входящего запроса по фиксированным правилам.

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

    Время: O(1), память: O(1).
    """
    if r.breaks_core_flow and not r.has_workaround:
        return {"route": "инцидент/срочный фикс", "sla": "сегодня"}

    weight = r.arr_blocked / 1_000_000 + r.accounts_affected / 50
    weight *= 0.3 + 0.7 * r.strategic_fit          # вне стратегии — вес падает втрое

    if weight >= 3:
        route, sla = "в ближайший цикл планирования", "ответ за 2 дня"
    elif weight >= 1:
        route, sla = "в бэклог кандидатов, ревью через месяц", "ответ за 5 дней"
    else:
        route, sla = "отказ с объяснением и обходным путём", "ответ за 5 дней"

    return {"route": route, "sla": sla, "weight": round(weight, 2)}


print(triage(Request("Права на уровне строк", "sales", 6, 18_000_000, False, False, 0.9)))
# {'route': 'в ближайший цикл планирования', 'sla': 'ответ за 2 дня', 'weight': 5.9}

print(triage(Request("Экспорт в экзотический формат", "exec", 1, 0, True, False, 0.2)))
# {'route': 'отказ с объяснением и обходным путём', 'sla': 'ответ за 5 дней', 'weight': 0.01}

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

6.3. Как говорить «нет»

Формула из трёх частей: признать проблему → объяснить причину отказа в терминах компромисса → дать следующий шаг. «Понимаю: без этого отчёта их аналитик тратит день в неделю. Сейчас не берём — квартальная ёмкость уходит на enterprise-гигиену, которая держит 26 млн ₽ сделок. Обходной путь — выгрузка через API, инструкцию пришлю сегодня. Вернёмся к этому в ревью через месяц, если запрос повторится ещё у двух клиентов.»

Чего делать нельзя: обещать «когда-нибудь», молчать, ссылаться на анонимные «приоритеты компании» и — самое разрушительное — соглашаться, зная, что не сделаете.

7. Трудные ситуации

• HiPPO. Мнение самого высокооплачиваемого человека против данных. Работает не спор, а перевод разговора в проверку: «давайте включим это на 10% и посмотрим — если вы правы, раскатаем за неделю». Отказ от дешёвой проверки — сам по себе информация об организации.
• «Срочно, обещали клиенту». Сначала выясните, что именно обещано и кем: часто оказывается, что обещания не было. Если было — фиксируйте в журнал обязательств (https://courses.digitable.life/post/product-management/11-b2b-and-enterprise/) и меняйте процесс, а не только план.
• Два стейкхолдера с противоположными требованиями. Не ищите компромисс в продукте: он даст решение, которое не нравится обоим. Поднимайте противоречие на уровень, где оно разрешимо, с письменным описанием обеих позиций и цены каждого варианта.
• Реорганизация. Ваш стейкхолдер сменился, договорённости обнулились. Единственная защита — журнал решений и письменные критерии, по которым решения принимались.
• Постоянные внеплановые запросы. Это не проблема дисциплины, а отсутствие квоты: заложите 10–20% ёмкости на непредвиденное явно, тогда остальное перестанет ломаться.

8. Операционный ритм

8.1. Календарь продакта

8.2. Сводка, которую читают

Формат из четырёх блоков, не длиннее половины страницы:

1. Сделали — только то, что доехало до пользователей, с эффектом, а не список задач.
2. Узнали — результаты проверок, включая опровергнутые гипотезы (это самая ценная часть и единственная защита от «фабрики фич»).
3. Дальше — что в работе и почему именно это.
4. Риски и просьбы — что может сорваться и что нужно от читателя. Конкретно: кто, что, к какому сроку.

Регулярность важнее объёма: еженедельная сводка на 15 строк работает лучше, чем ежемесячная на пять страниц. Она же — накопитель предсказуемости из раздела 1.2.

8.3. Гигиена бэклога

Бэклог, в котором 800 элементов, — не бэклог, а свалка: его никто не читает, и приоритизация в нём невозможна. Рабочие правила: элементы старше 6–9 месяцев без движения закрываются автоматически (с уведомлением автора и возможностью вернуть); кандидаты хранятся отдельно от подтверждённого плана; у каждого элемента есть проблема и метрика, а не только название. Практики уточнения и декомпозиции — https://courses.digitable.life/post/scrum-master/06-product-backlog/.

9. Типичные ошибки

• Приходить только с просьбами. Влияние накапливается заранее, а не в момент нужды.
• Спорить мнением против мнения. Побеждает должность. Переводите спор в дешёвую проверку.
• Расширять список согласующих «на всякий случай». Каждый добавленный человек — дни цикла.
• Устно вместо письменно. Через месяц не останется ни решения, ни причины.
• Молчать в ответ на запросы продаж и поддержки. Канал обратной связи закрывается навсегда.
• Соглашаться, зная, что не сделаете. Один такой случай стоит дороже десяти отказов.
• Обсуждать обратимые решения как необратимые. Организация замедляется без всякой пользы.
• Считать операционку бюрократией. Без ритма продакт живёт в режиме реакции, и стратегия (https://courses.digitable.life/post/product-management/04-strategy-and-roadmap/) не выполняется никогда.

10. Мини-итог

• У продакта нет власти, и это правильно: отсутствие власти вынуждает обосновывать, а обоснование ловит плохие идеи.
• Влияние складывается из информации, ясности, экспертизы, предсказуемости, взаимности и доступа — и накапливается заранее.
• Карта стейкхолдеров и четыре режима вовлечения (информировать, консультировать, согласовывать, решать) экономят внимание; владелец решения всегда один.
• Число согласующих растёт линейно, а стоимость согласования — квадратично; сокращать список согласующих — продуктовая работа.
• Письменные форматы (one-pager, нарратив, ADR, RFC, постмортем) переносят обсуждение в место, где выигрывает аргумент, а не громкость.
• Решения делятся на обратимые и необратимые; процедура должна соответствовать типу, а не важности на вид.
• Команде дают проблему, критерий успеха и ограничения — а не готовое техническое решение.
• Входящий поток проходит один фильтр независимо от источника; ответ обязателен даже в случае отказа.
• Ритм (неделя — месяц — квартал) превращает всё перечисленное из героизма в процесс.

Источники

• David Maister, Charles Green, Robert Galford, «The Trusted Advisor» — формула доверия: https://trustedadvisor.com/why-trust-matters/understanding-trust/the-trust-equation
• Colin Bryar, Bill Carr, «Working Backwards» — нарративы вместо презентаций: https://www.workingbackwards.com/
• Jeff Bezos, письмо акционерам Amazon 2015 — решения Type 1 и Type 2: https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm
• Marty Cagan, «Inspired» и «Empowered» — продуктовое трио и команды с полномочиями: https://www.svpg.com/books/
• Fred Brooks, «The Mythical Man-Month» — рост коммуникационных связей: https://www.oreilly.com/library/view/mythical-man-month-the/0201835959/
• Matthew Skelton, Manuel Pais, «Team Topologies» — взаимодействие команд: https://teamtopologies.com/
• Ben Horowitz, «Good Product Manager / Bad Product Manager» — классический разбор роли: https://a16z.com/good-product-manager-bad-product-manager/

Что дальше

Это последняя статья трека «Product Management». Полная картина выглядит так: discovery (https://courses.digitable.life/post/product-management/01-discovery-and-research/) находит проблему, метрики (https://courses.digitable.life/post/product-management/02-metrics/) делают её измеримой, приоритизация (https://courses.digitable.life/post/product-management/03-prioritization/) и стратегия (https://courses.digitable.life/post/product-management/04-strategy-and-roadmap/) выбирают направление, MVP и эксперименты (https://courses.digitable.life/post/product-management/05-mvp-and-experiments/), требования и UX (https://courses.digitable.life/post/product-management/06-ux-and-requirements/), монетизация (https://courses.digitable.life/post/product-management/07-pricing-and-growth/) превращают выбор в продукт, аналитика (https://courses.digitable.life/post/product-management/08-analytics-and-decisions/) замыкает петлю обратной связи, рынок (https://courses.digitable.life/post/product-management/09-market-and-competition/) и go-to-market (https://courses.digitable.life/post/product-management/10-go-to-market-and-launch/) выводят его к людям, B2B-специфика (https://courses.digitable.life/post/product-management/11-b2b-and-enterprise/) описывает продажу организациям, жизненный цикл (https://courses.digitable.life/post/product-management/12-lifecycle-and-sunset/) — вторую половину жизни продукта, а эта статья — то, как всё перечисленное доживает до реализации.

Куда идти дальше:

• https://courses.digitable.life/post/project-management/00-overview/ — как доводить решения до релиза: планирование, риски, работа с командой и стейкхолдерами.
• https://courses.digitable.life/post/ux-design/00-overview/ — проектирование решения, к которому вы уже сформулировали требования.
• https://courses.digitable.life/post/data-analytics/00-overview/ — глубже в анализ данных, на которых строятся продуктовые решения.
• https://courses.digitable.life/post/systems-analysis/00-overview/ — соседняя профессия: требования, интеграции, работа со стейкхолдерами со стороны аналитика.
• https://courses.digitable.life/post/technical-writing/00-overview/ — письменные форматы, без которых влияние без полномочий не работает.
• https://courses.digitable.life/post/engineering-leadership/00-overview/ — если вас тянет в сторону управления командой.
• https://courses.digitable.life/post/business/00-overview/ — если тянет в сторону собственного продукта.

Общая карта портала и рекомендуемый порядок изучения — в https://courses.digitable.life/post/roadmap/.

Вернуться к обзору трека