Отчёт для заинтересованных лиц

Текст

---
name: stakeholder-update
description: Готовит отчёт для заинтересованных лиц с учётом аудитории и периодичности. Используй при написании еженедельного или ежемесячного статуса для руководства, при объявлении о запуске, при эскалации риска или блокирующего фактора, а также чтобы превратить один и тот же прогресс в версии для руководителей, для разработки или для клиентов.
argument-hint: "<update type and audience>"
---

Отчёт для заинтересованных лиц

Если встретишь незнакомые подстановки или понадобится узнать, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Подготовь отчёт для заинтересованных лиц с учётом аудитории и периодичности.

Использование

/stakeholder-update $ARGUMENTS

Рабочий процесс

1. Определи тип отчёта

Спроси пользователя, какой нужен отчёт:

• Еженедельный: регулярный отчёт о прогрессе, блокирующих факторах и следующих шагах
• Ежемесячный: сводка более высокого уровня с трендами, вехами и стратегическим соответствием
• О запуске: объявление о запуске функции или продукта с подробностями и влиянием
• Разовый (ad-hoc): единичный отчёт по конкретной ситуации (эскалация, смена курса, важное решение)

2. Определи аудиторию

Спроси, для кого отчёт:

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

3. Подтяни контекст из подключённых инструментов

Если подключён ~~project tracker:

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

Если подключён ~~chat:

• Найди важные обсуждения и решения команды
• Найди блокирующие факторы или проблемы, поднятые в каналах
• Выяви ключевые решения, принятые асинхронно

Если подключена ~~meeting transcription:

• Подтяни недавние заметки со встреч и сводки обсуждений
• Найди решения и задачи со встреч, имеющих отношение к делу

Если подключена ~~knowledge base:

• Найди недавние заметки со встреч
• Найди документы с решениями или разборы дизайна

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

• Что было сделано с прошлого отчёта
• Текущие блокирующие факторы или риски
• Ключевые принятые или необходимые решения
• Что дальше

4. Составь отчёт

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

Для руководителей: краткое резюме (TL;DR), цвет статуса (З/Ж/К), ключевой прогресс с привязкой к целям, принятые решения, риски с мерами снижения, конкретные просьбы и следующие вехи. Уложись в 300 слов.

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

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

Для клиентов: что нового (в формулировке выгод), что скоро появится, известные проблемы с обходными путями и как оставить отзыв. Без внутреннего жаргона.

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

5. Проверь и доставь

После составления отчёта:

• Спроси, хочет ли пользователь скорректировать тон, уровень детализации или акценты
• Предложи оформить под канал доставки (письмо, пост в чате, документ, слайды)
• Если подключён ~~chat, предложи подготовить сообщение для отправки

Шаблоны отчётов по аудиториям

Отчёт для руководителей

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

Формат:

Статус: [Зелёный / Жёлтый / Красный]

Кратко: [Одно предложение — самое важное, что нужно знать]

Прогресс:
- [Достигнутый результат с привязкой к цели/OKR]
- [Достигнутая веха и её влияние]
- [Движение ключевой метрики]

Риски:
- [Риск]: [План снижения]. [Просьба, если нужна].

Необходимые решения:
- [Решение]: [Варианты с рекомендацией]. Нужно к [дата].

Следующие вехи:
- [Веха] — [Дата]

Советы по отчётам для руководителей:

• Начинай с вывода, а не с пути. Руководители хотят «мы выпустили X, и это сдвинуло метрику Y», а не «мы провели 14 стендапов и закрыли 23 тикета».
• Уложись в 200 слов. Если захотят больше, спросят.
• Цвет статуса должен отражать ТВОЮ искреннюю оценку, а не то, что, по-твоему, хотят услышать. Жёлтый — не провал, а хорошее управление рисками.
• Включай только те риски, в которых тебе нужна помощь. Не перечисляй риски, с которыми ты уже справляешься, если им не нужно о них знать.
• Просьбы должны быть конкретными: «Решение по X к пятнице», а не «нужна поддержка».

Отчёт для команды разработки

Инженеры хотят: чёткие приоритеты, технический контекст, снятые блокировки, решения, влияющие на их работу.

Формат:

Выпущено:
- [Функция/исправление] — [Ссылка на PR/тикет]. [Влияние, если заметное].

В работе:
- [Пункт] — [Владелец]. [Ожидаемое завершение]. [Блокирующие факторы, если есть].

Решения:
- [Принятое решение]: [Обоснование]. [Ссылка на ADR, если есть].
- [Необходимое решение]: [Контекст]. [Варианты]. [Рекомендация].

Изменения приоритетов:
- [Что изменилось и почему]

Дальше:
- [Следующие пункты] — [Контекст: почему именно они следующие]

Советы по отчётам для разработки:

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

Отчёт для партнёров из других функций

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

Формат:

Что готовится:
- [Функция/запуск] — [Дата]. [Что это значит для вашей команды].

Что нам нужно от вас:
- [Конкретная просьба] — [Контекст]. К [дата].

Принятые решения:
- [Решение] — [Как оно влияет на вашу команду].

Открыто для отзывов:
- [Тема, по которой мы хотели бы получить отзыв] — [Как его дать].

Отчёт для клиентов и внешней аудитории

Клиенты хотят: что нового, что скоро появится, чем это им полезно, как начать пользоваться.

Формат:

Что нового:
- [Функция] — [Выгода в терминах клиента]. [Как пользоваться / ссылка].

Скоро:
- [Функция] — [Ожидаемые сроки]. [Почему это важно для вас].

Известные проблемы:
- [Проблема] — [Статус]. [Обходной путь, если есть].

Обратная связь:
- [Как поделиться отзывом или запросить функции]

Советы по отчётам для клиентов:

• Без внутреннего жаргона. Без номеров тикетов. Без технических деталей реализации.
• Формулируй всё через то, что клиент теперь может СДЕЛАТЬ, а не через то, что вы построили.
• Честно называй сроки, но не обещай лишнего. «Позже в этом квартале» лучше, чем дата, которую вы можете сорвать.
• Упоминай известные проблемы, только если они влияют на клиентов и у вас есть план решения.

Рамка отчётов о статусе

Статус «зелёный / жёлтый / красный»

Зелёный (по плану):

• Продвигается как запланировано
• Нет значимых рисков или блокирующих факторов
• Обязательства и сроки выполняются
• Используй зелёный, когда дела действительно идут хорошо, а не по умолчанию

Жёлтый (под риском):

• Прогресс медленнее запланированного или риск реализовался
• Меры снижения принимаются, но исход неопределён
• Без вмешательства или корректировки объёма обязательства могут быть сорваны
• Используй жёлтый заблаговременно — чем раньше ты сообщишь о риске, тем больше у тебя вариантов

Красный (вне плана):

• Значительное отставание от плана
• Крупный блокирующий фактор или риск без чётких мер снижения
• Обязательства будут сорваны без существенного вмешательства (сокращение объёма, добавление ресурсов, продление сроков)
• Используй красный, когда тебе действительно нужна помощь. Не жди, пока станет слишком поздно.

Когда менять статус

• Переходи на жёлтый при ПЕРВОМ признаке риска, а не когда уверен, что дела плохи
• Переходи на красный, когда исчерпал собственные варианты и нужна эскалация
• Возвращайся на зелёный, только когда риск действительно разрешён, а не просто приостановлен
• Документируй, что изменилось, когда меняешь статус: «Переведено на жёлтый, потому что [причина]»

Коммуникация рисков

Рамка ROAM для управления рисками

• Resolved (разрешён): риск больше не вызывает беспокойства. Задокументируй, как он был разрешён.
• Owned (закреплён за владельцем): риск признан, и кто-то активно им управляет. Укажи владельца и план снижения.
• Accepted (принят): риск известен, но мы сознательно идём дальше без мер снижения. Задокументируй обоснование.
• Mitigated (снижен): действия снизили риск до приемлемого уровня. Задокументируй, что было сделано.

Как эффективно сообщать о рисках

1. Чётко сформулируй риск: «Существует риск, что [что-то] произойдёт из-за [причина]»
2. Оцени влияние в числах: «Если это произойдёт, последствие — [влияние]»
3. Назови вероятность: «Это [вероятно/возможно/маловероятно], потому что [доказательства]»
4. Покажи меры снижения: «Мы управляем этим с помощью [действия]»
5. Сформулируй просьбу: «Нам нужна [конкретная помощь], чтобы ещё больше снизить этот риск»

Типичные ошибки в коммуникации рисков

• Хоронить риски среди хороших новостей. Начинай с рисков, когда они важны.
• Расплывчатость: «Возможны какие-то задержки» — уточняй, какие, на сколько и почему.
• Представлять риски без мер снижения. К каждому риску должен прилагаться план.
• Затягивать. Риск, о котором сообщили рано, — вводные для планирования. Риск, о котором сообщили поздно, — авральная тревога.

Документирование решений (ADR)

Формат записи об архитектурном решении (Architecture Decision Record)

Документируй важные решения для будущего:

# [Название решения]

## Статус
[Предложено / Принято / Устарело / Заменено ADR-XXX]

## Контекст
Какая ситуация требует решения? Какие силы действуют?

## Решение
Что мы решили? Сформулируй решение чётко и прямо.

## Последствия
Каковы последствия этого решения?
- Положительные последствия
- Отрицательные последствия или принятые компромиссы
- Что это даёт или не даёт сделать в будущем

## Рассмотренные альтернативы
Какие другие варианты оценивались?
По каждому: что это было, почему отвергнуто?

Когда писать ADR

• Стратегические продуктовые решения (какой сегмент рынка выбрать, какую платформу поддерживать)
• Значимые технические решения (выбор архитектуры, выбор поставщика, «строить или купить»)
• Спорные решения, по которым мнения разошлись (задокументируй обоснование на будущее)
• Решения, ограничивающие будущие варианты (выбор технологии, заключение партнёрства)
• Решения, которые, как ты ожидаешь, позже будут ставить под вопрос (зафиксируй контекст, пока он свеж)

Советы по документированию решений

• Пиши ADR ближе к моменту принятия решения, а не через несколько недель
• Укажи, кто участвовал в решении и кто принял итоговое решение
• Подробно документируй контекст — будущие читатели не будут знать сегодняшнего контекста
• Нормально документировать решения, которые задним числом оказались неверными, — добавь ссылку «заменено»
• Делай их короткими. Одна страница лучше пяти.

Проведение встреч

Стендап / ежедневная синхронизация

Цель: вынести на поверхность блокирующие факторы, координировать работу, поддерживать темп. Формат: каждый участник рассказывает:

• Что сделал с прошлой синхронизации
• Над чем будет работать дальше
• Что его блокирует

Советы по проведению:

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

Планирование спринта / итерации

Цель: взять обязательства по работе на следующий спринт. Согласовать приоритеты и объём. Формат:

1. Обзор: что выпущено в прошлом спринте, что перенесено, что отменено
2. Приоритеты: что самое важное нужно сделать в этом спринте
3. Ёмкость: сколько команда может взять на себя (с учётом отпусков, дежурств, встреч)
4. Обязательство: выбрать пункты из бэклога, которые укладываются в ёмкость и приоритеты
5. Зависимости: отметить любые зависимости между командами и внешние зависимости

Советы по проведению:

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

Ретроспектива

Цель: осмыслить, что прошло хорошо, что нет и что менять. Формат:

1. Задать рамку: напомнить команде о цели и создать психологическую безопасность
2. Собрать данные: что прошло хорошо, что нет, что было непонятно
3. Выработать выводы: выявить закономерности и первопричины
4. Решить действия: выбрать 1–3 конкретных улучшения для попытки в следующем спринте
5. Завершить: поблагодарить за честную обратную связь

Советы по проведению:

• Создавай психологическую безопасность. Людям должно быть безопасно говорить честно.
• Сосредоточься на системах и процессах, а не на людях.
• Ограничься 1–3 пунктами действий. Больше — и ничего не изменится.
• Отслеживай, как выполнены действия с прошлых ретроспектив. Если не отслеживать, люди перестают вовлекаться.
• Время от времени меняй формат ретроспективы, чтобы он не приедался.

Обзор для заинтересованных лиц / демо

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

1. Контекст: напомнить заинтересованным лицам о цели и о том, что они видели в прошлый раз
2. Демо: показать, что построено. Используй реальный продукт, а не слайды.
3. Метрики: поделиться ранними данными или отзывами
4. Обратная связь: структурированное время для вопросов и замечаний
5. Следующие шаги: что дальше и когда будет следующий обзор

Советы по проведению:

• Показывай реальный продукт, когда это возможно. Слайды — это не демо.
• Формулируй сбор обратной связи: «Какие у вас замечания по X?» лучше, чем «Есть мысли?»
• Записывай обратную связь на виду и обязуйся её учесть (или объяснить, почему нет)
• Задай ожидания о том, какая обратная связь применима на этом этапе

Формат результата

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

Советы

• Самая частая ошибка в отчётах для заинтересованных лиц — похоронить главное. Начинай с самого важного.
• Цвета статусов (зелёный/жёлтый/красный) должны отражать реальность, а не оптимизм. Жёлтый — не провал, а хорошая коммуникация рисков.
• Просьбы должны быть конкретными и выполнимыми. «Нам нужна помощь» — не просьба. «Нам нужно решение по X к пятнице» — просьба.
• Для руководителей формулируй всё через результаты и цели, а не через активность и задачи.
• Если есть плохие новости, начинай с них. Не прячь их за хорошими.
• Подгоняй длину под внимание аудитории. Руководителям — несколько пунктов. Разработке — подробности, которые им нужны.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/product-management/skills/stakeholder-update, лицензия Apache-2.0. Изменения: перевод на русский язык.