Обновление дорожной карты продукта

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

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

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

Входит в плагин product-management. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку roadmap-update в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: roadmap-update
description: Обновляет, создаёт или переприоритизирует дорожную карту продукта. Используй при добавлении новой инициативы и решении, что сдвинуть ради неё, при смене приоритетов после получения новой информации, при переносе сроков из-за срыва зависимости или при построении вида «Сейчас / Дальше / Потом» с нуля.
argument-hint: "<update description>"
---

Обновление дорожной карты

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

Обнови, создай или переприоритизируй дорожную карту продукта.

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

/roadmap-update $ARGUMENTS

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

1. Пойми текущее состояние

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

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

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

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

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

Спроси, что пользователь хочет сделать:

Добавить пункт: новая функция, инициатива или рабочий пункт в дорожную карту

Собери: название, описание, приоритет, оценку трудозатрат, целевой срок, владельца, зависимости
Предложи, куда он встраивается, исходя из текущих приоритетов и ёмкости

Обновить статус: изменить статус существующих пунктов

Варианты: не начат, в работе, под риском, заблокирован, завершён, отменён
Для «под риском» или «заблокирован»: спроси про блокирующий фактор и план его снятия

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

Спроси, что изменилось (новая информация, смена стратегии, изменение ресурсов, отзывы клиентов)
Примени рамку приоритизации, если это поможет — см. Рамки приоритизации ниже: RICE, MoSCoW, ICE и «ценность против трудозатрат»
Покажи сравнение «до и после»

Сдвинуть сроки: перенести даты пунктов

Спроси почему (изменение объёма, срыв зависимости, нехватка ресурсов)
Определи последствия для зависимых пунктов
Отметь пункты, которые уходят за жёсткие дедлайны

Создать новую дорожную карту: построить дорожную карту с нуля

Спроси про горизонт (квартал, полугодие, год)
Спроси про предпочитаемый формат («Сейчас / Дальше / Потом», квартальные колонки, привязка к OKR) — см. Форматы дорожных карт ниже
Собери список инициатив для включения

3. Составь сводку по дорожной карте

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

Обзор статусов

Краткая сводка: X пунктов в работе, Y завершено за период, Z под риском.

Пункты дорожной карты

По каждому пункту покажи:

Название и однострочное описание
Индикатор статуса (по плану / под риском / заблокирован / завершён / не начат)
Целевой срок или дату
Владельца
Ключевые зависимости

Группируй пункты по:

Горизонту («Сейчас / Дальше / Потом») или кварталам, в зависимости от формата
Либо по темам или целям, если пользователь предпочитает так

Риски и зависимости

Заблокированные пункты и пункты под риском, с подробностями
Зависимости между командами и их статус
Пункты, приближающиеся к жёстким дедлайнам

Изменения в этом обновлении

Если это обновление существующей дорожной карты, подведи итог изменений:

Добавленные, удалённые или переприоритизированные пункты
Сдвиги сроков
Изменения статусов

4. Дальнейшие шаги

После составления дорожной карты:

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

Форматы дорожных карт

«Сейчас / Дальше / Потом» (Now / Next / Later)

Самый простой и часто самый эффективный формат дорожной карты:

Сейчас (текущий спринт или месяц): взятая в работу задача. Высокая уверенность в объёме и сроках. Это то, что команда активно строит.
Дальше (следующие 1–3 месяца): запланированная работа. Хорошая уверенность в том, что делать, меньшая — в том, когда именно. Объём и приоритеты определены, но работа ещё не начата.
Потом (3–6+ месяцев): направление. Это стратегические ставки и возможности, которые мы намерены реализовать, но объём и сроки гибкие.

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

Квартальные темы

Организуй дорожную карту вокруг 2–3 тем на квартал:

Каждая тема представляет стратегическое направление вложений (например: «Готовность к крупным клиентам», «Улучшение активации», «Расширяемость платформы»)
Под каждой темой перечисли конкретные запланированные инициативы
Темы должны соответствовать OKR компании или команды
Этот формат позволяет легко объяснить, ПОЧЕМУ вы строите то, что строите

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

Дорожная карта, привязанная к OKR

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

Начни с OKR команды на период
Под каждым ключевым результатом перечисли инициативы, которые сдвинут эту метрику
Укажи ожидаемое влияние каждой инициативы на ключевой результат
Это создаёт чёткую подотчётность между тем, что вы строите, и тем, что измеряете

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

Вид «лента времени / диаграмма Ганта»

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

Показывает даты начала, окончания и длительности
Визуализирует параллельность и последовательность
Хорош для выявления конфликтов ресурсов
Показывает зависимости между пунктами

Когда использовать: для планирования исполнения вместе с разработкой. Для выявления конфликтов в расписании. НЕ годится для коммуникации вовне (создаёт ожидания ложной точности).

Рамки приоритизации

Оценка RICE

Оцени каждую инициативу по четырём измерениям, затем рассчитай RICE = (Охват x Влияние x Уверенность) / Трудозатраты

Reach (охват): сколько пользователей или клиентов это затронет за заданный период? Используй конкретные числа (например: «500 пользователей в квартал»).
Impact (влияние): насколько это сдвинет ситуацию для каждого охваченного человека? Оценка по шкале: 3 = огромное, 2 = высокое, 1 = среднее, 0,5 = низкое, 0,25 = минимальное.
Confidence (уверенность): насколько мы уверены в оценках охвата и влияния? 100% = высокая уверенность (подкреплена данными), 80% = средняя (есть некоторые подтверждения), 50% = низкая (интуиция).
Effort (трудозатраты): сколько человеко-месяцев работы? Включай разработку, дизайн и любые другие функции.

Когда использовать: когда нужна количественная, защитимая приоритизация. Хорош для сравнения большого бэклога инициатив. Хуже подходит для стратегических ставок, где влияние трудно оценить.

MoSCoW

Раздели пункты на «обязательно» (Must have), «желательно» (Should have), «можно» (Could have), «не будет» (Won't have):

Must have (обязательно): без них дорожная карта провалена. Безусловные обязательства.
Should have (желательно): важно и ожидаемо, но поставка возможна и без них.
Could have (можно): желательно, но явно менее приоритетно. Включай, только если позволяет ёмкость.
Won't have (не будет): явно вне объёма на этот период. Важно перечислить для ясности.

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

Оценка ICE

Проще, чем RICE. Оцени каждый пункт от 1 до 10 по трём измерениям:

Impact (влияние): насколько это сдвинет целевую метрику?
Confidence (уверенность): насколько мы уверены в оценке влияния?
Ease (лёгкость): насколько легко это реализовать? (обратная величина трудозатрат — чем выше, тем легче)

Оценка ICE = Влияние x Уверенность x Лёгкость

Когда использовать: для быстрой приоритизации бэклога функций. Хорош для продуктов на ранней стадии или когда данных для RICE недостаточно.

Матрица «ценность против трудозатрат»

Расположи инициативы на матрице 2×2:

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

Когда использовать: для наглядной приоритизации на планировании команды. Хорош для выработки общего понимания компромиссов.

Карта зависимостей

Выявление зависимостей

Ищи зависимости в следующих категориях:

Технические зависимости: функция B требует инфраструктурной работы из функции A
Зависимости от команд: функция требует работы другой команды (дизайн, платформа, данные)
Внешние зависимости: ожидание поставщика, партнёра или интеграции со сторонним сервисом
Зависимости от знаний: нужны результаты исследования или расследования до начала
Последовательные зависимости: нужно выпустить функцию A до начала функции B (общий код, пользовательский сценарий)

Управление зависимостями

Явно перечисли все зависимости в дорожной карте
Назначь владельца каждой зависимости (кто отвечает за её разрешение)
Задай срок «нужно к»: когда зависящему пункту нужно, чтобы это было решено
Закладывай запас вокруг зависимостей — это самые рискованные пункты в любой дорожной карте
Рано отмечай зависимости, пересекающие границы команд — они требуют координации
Имей запасной план: что делать, если зависимость сорвётся?

Сокращение зависимостей

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

Планирование ёмкости

Оценка ёмкости

Начни с числа инженеров и периода времени
Вычти известные накладные расходы: встречи, дежурства, собеседования, праздники, отпуска
Распространённое эмпирическое правило: инженеры тратят 60–70% времени на запланированную работу над функциями
Учти время вхождения в работу для новых членов команды

Распределение ёмкости

Здоровое распределение для большинства продуктовых команд:

70% запланированных функций: пункты дорожной карты, продвигающие стратегические цели
20% технического здоровья: технический долг, надёжность, производительность, удобство разработки
10% незапланированного: запас на срочные проблемы, быстрые победы и просьбы других команд

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

Новый продукт: больше работы над функциями, меньше технического долга
Зрелый продукт: больше вложений в технический долг и надёжность
После инцидента: больше надёжности, меньше функций
Быстрый рост: больше масштабируемости и производительности

Ёмкость и амбиции

Если обязательства в дорожной карте превышают ёмкость, чем-то придётся пожертвовать
Не решай проблемы с ёмкостью, делая вид, что люди могут больше, — решай сокращением объёма
Добавляя пункт в дорожную карту, всегда спрашивай: «Что убираем?»
Лучше взять на себя меньше и выполнить надёжно, чем взять слишком много и разочаровать

Коммуникация изменений дорожной карты

Когда дорожная карта меняется

Типичные поводы для изменения дорожной карты:

Новый стратегический приоритет от руководства
Отзывы клиентов или исследования, меняющие приоритеты
Технические открытия, меняющие оценки
Срыв зависимости от другой команды
Изменение ресурсов (команда растёт или сокращается, уходит ключевой человек)
Ход конкурента, требующий ответа

Как сообщать об изменениях

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

Как избежать «качелей» дорожной карты

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

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

Используй понятный формат, удобный для беглого просмотра. Для пунктов дорожной карты хорошо подходят таблицы. Используй текстовые метки статуса: Готово, По плану, Под риском, Заблокирован, Не начат.

Советы

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

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

Оригинал на английском

---
name: roadmap-update
description: Update, create, or reprioritize your product roadmap. Use when adding a new initiative and deciding what moves to make room, shifting priorities after new information comes in, moving timelines due to a dependency slip, or building a Now/Next/Later view from scratch.
argument-hint: "<update description>"
---

# Roadmap Update

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

Update, create, or reprioritize a product roadmap.

## Usage

```
/roadmap-update $ARGUMENTS
```

## Workflow

### 1. Understand Current State

If **~~project tracker** is connected:
- Pull current roadmap items with their statuses, assignees, and dates
- Identify items that are overdue, at risk, or recently completed
- Surface any items without clear owners or dates

If no project management tool is connected:
- Ask the user to describe their current roadmap or paste/upload it
- Accept any format: list, table, spreadsheet, screenshot, or prose description

### 2. Determine the Operation

Ask what the user wants to do:

**Add item**: New feature, initiative, or work item to the roadmap
- Gather: name, description, priority, estimated effort, target timeframe, owner, dependencies
- Suggest where it fits based on current priorities and capacity

**Update status**: Change status of existing items
- Options: not started, in progress, at risk, blocked, completed, cut
- For "at risk" or "blocked": ask for the blocker and mitigation plan

**Reprioritize**: Change the order or priority of items
- Ask what changed (new information, strategy shift, resource change, customer feedback)
- Apply a prioritization framework if helpful — see **Prioritization Frameworks** below for RICE, MoSCoW, ICE, and value-vs-effort
- Show before/after comparison

**Move timeline**: Shift dates for items
- Ask why (scope change, dependency slip, resource constraint)
- Identify downstream impacts on dependent items
- Flag items that move past hard deadlines

**Create new roadmap**: Build a roadmap from scratch
- Ask about timeframe (quarter, half, year)
- Ask about format preference (Now/Next/Later, quarterly columns, OKR-aligned) — see **Roadmap Frameworks** below
- Gather the list of initiatives to include

### 3. Generate Roadmap Summary

Produce a roadmap view with:

#### Status Overview
Quick summary: X items in progress, Y completed this period, Z at risk.

#### Roadmap Items
For each item, show:
- Name and one-line description
- Status indicator (on track / at risk / blocked / completed / not started)
- Target timeframe or date
- Owner
- Key dependencies

Group items by:
- Timeframe (Now / Next / Later) or quarter, depending on format
- Or by theme/goal if the user prefers

#### Risks and Dependencies
- Items that are blocked or at risk, with details
- Cross-team dependencies and their status
- Items approaching hard deadlines

#### Changes This Update
If this is an update to an existing roadmap, summarize what changed:
- Items added, removed, or reprioritized
- Timeline shifts
- Status changes

### 4. Follow Up

After generating the roadmap:
- Offer to format for a specific audience (executive summary, engineering detail, customer-facing)
- Offer to draft communication about roadmap changes
- If project management tool is connected, offer to update ticket statuses

## Roadmap Frameworks

### Now / Next / Later
The simplest and often most effective roadmap format:

- **Now** (current sprint/month): Committed work. High confidence in scope and timeline. These are the things the team is actively building.
- **Next** (next 1-3 months): Planned work. Good confidence in what, less confidence in exactly when. Scoped and prioritized but not yet started.
- **Later** (3-6+ months): Directional. These are strategic bets and opportunities we intend to pursue, but scope and timing are flexible.

When to use: Most teams, most of the time. Especially good for communicating externally or to leadership because it avoids false precision on dates.

### Quarterly Themes
Organize the roadmap around 2-3 themes per quarter:

- Each theme represents a strategic area of investment (e.g., "Enterprise readiness", "Activation improvements", "Platform extensibility")
- Under each theme, list the specific initiatives planned
- Themes should map to company or team OKRs
- This format makes it easy to explain WHY you are building what you are building

When to use: When you need to show strategic alignment. Good for planning meetings and executive communication.

### OKR-Aligned Roadmap
Map roadmap items directly to Objectives and Key Results:

- Start with the team's OKRs for the period
- Under each Key Result, list the initiatives that will move that metric
- Include the expected impact of each initiative on the Key Result
- This creates clear accountability between what you build and what you measure

When to use: Organizations that run on OKRs. Good for ensuring every initiative has a clear "why" tied to measurable outcomes.

### Timeline / Gantt View
Calendar-based view with items on a timeline:

- Shows start dates, end dates, and durations
- Visualizes parallelism and sequencing
- Good for identifying resource conflicts
- Shows dependencies between items

When to use: Execution planning with engineering. Identifying scheduling conflicts. NOT good for communicating externally (creates false precision expectations).

## Prioritization Frameworks

### RICE Score
Score each initiative on four dimensions, then calculate RICE = (Reach x Impact x Confidence) / Effort

- **Reach**: How many users/customers will this affect in a given time period? Use concrete numbers (e.g., "500 users per quarter").
- **Impact**: How much will this move the needle for each person reached? Score on a scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal.
- **Confidence**: How confident are we in the reach and impact estimates? 100% = high confidence (backed by data), 80% = medium (some evidence), 50% = low (gut feel).
- **Effort**: How many person-months of work? Include engineering, design, and any other functions.

When to use: When you need a quantitative, defensible prioritization. Good for comparing a large backlog of initiatives. Less good for strategic bets where impact is hard to estimate.

### MoSCoW
Categorize items into Must have, Should have, Could have, Won't have:

- **Must have**: The roadmap is a failure without these. Non-negotiable commitments.
- **Should have**: Important and expected, but delivery is viable without them.
- **Could have**: Desirable but clearly lower priority. Include only if capacity allows.
- **Won't have**: Explicitly out of scope for this period. Important to list for clarity.

When to use: Scoping a release or quarter. Negotiating with stakeholders about what fits. Good for forcing prioritization conversations.

### ICE Score
Simpler than RICE. Score each item 1-10 on three dimensions:

- **Impact**: How much will this move the target metric?
- **Confidence**: How confident are we in the impact estimate?
- **Ease**: How easy is this to implement? (Inverse of effort — higher = easier)

ICE Score = Impact x Confidence x Ease

When to use: Quick prioritization of a feature backlog. Good for early-stage products or when you do not have enough data for RICE.

### Value vs Effort Matrix
Plot initiatives on a 2x2 matrix:

- **High value, Low effort** (Quick wins): Do these first.
- **High value, High effort** (Big bets): Plan these carefully. Worth the investment but need proper scoping.
- **Low value, Low effort** (Fill-ins): Do these when you have spare capacity.
- **Low value, High effort** (Money pits): Do not do these. Remove from the backlog.

When to use: Visual prioritization in team planning sessions. Good for building shared understanding of tradeoffs.

## Dependency Mapping

### Identifying Dependencies
Look for dependencies across these categories:

- **Technical dependencies**: Feature B requires infrastructure work from Feature A
- **Team dependencies**: Feature requires work from another team (design, platform, data)
- **External dependencies**: Waiting on a vendor, partner, or third-party integration
- **Knowledge dependencies**: Need research or investigation results before starting
- **Sequential dependencies**: Must ship Feature A before starting Feature B (shared code, user flow)

### Managing Dependencies
- List all dependencies explicitly in the roadmap
- Assign an owner to each dependency (who is responsible for resolving it)
- Set a "need by" date: when does the depending item need this resolved
- Build buffer around dependencies — they are the highest-risk items on any roadmap
- Flag dependencies that cross team boundaries early — these require coordination
- Have a contingency plan: what do you do if the dependency slips?

### Reducing Dependencies
- Can you build a simpler version that avoids the dependency?
- Can you parallelize by using an interface contract or mock?
- Can you sequence differently to move the dependency earlier?
- Can you absorb the work into your team to remove the cross-team coordination?

## Capacity Planning

### Estimating Capacity
- Start with the number of engineers and the time period
- Subtract known overhead: meetings, on-call rotations, interviews, holidays, PTO
- A common rule of thumb: engineers spend 60-70% of time on planned feature work
- Factor in team ramp time for new members

### Allocating Capacity
A healthy allocation for most product teams:

- **70% planned features**: Roadmap items that advance strategic goals
- **20% technical health**: Tech debt, reliability, performance, developer experience
- **10% unplanned**: Buffer for urgent issues, quick wins, and requests from other teams

Adjust ratios based on team context:
- New product: more feature work, less tech debt
- Mature product: more tech debt and reliability investment
- Post-incident: more reliability, less features
- Rapid growth: more scalability and performance

### Capacity vs Ambition
- If roadmap commitments exceed capacity, something must give
- Do not solve capacity problems by pretending people can do more — solve by cutting scope
- When adding to the roadmap, always ask: "What comes off?"
- Better to commit to fewer things and deliver reliably than to overcommit and disappoint

## Communicating Roadmap Changes

### When the Roadmap Changes
Common triggers for roadmap changes:
- New strategic priority from leadership
- Customer feedback or research that changes priorities
- Technical discovery that changes estimates
- Dependency slip from another team
- Resource change (team grows or shrinks, key person leaves)
- Competitive move that requires response

### How to Communicate Changes
1. **Acknowledge the change**: Be direct about what is changing and why
2. **Explain the reason**: What new information drove this decision?
3. **Show the tradeoff**: What was deprioritized to make room? Or what is slipping?
4. **Show the new plan**: Updated roadmap with the changes reflected
5. **Acknowledge impact**: Who is affected and how? Stakeholders who were expecting deprioritized items need to hear it directly.

### Avoiding Roadmap Whiplash
- Do not change the roadmap for every piece of new information. Have a threshold for change.
- Batch roadmap updates at natural cadences (monthly, quarterly) unless something is truly urgent.
- Distinguish between "roadmap change" (strategic reprioritization) and "scope adjustment" (normal execution refinement).
- Track how often the roadmap changes. Frequent changes may signal unclear strategy, not good responsiveness.

## Output Format

Use a clear, scannable format. Tables work well for roadmap items. Use text status labels: **Done**, **On Track**, **At Risk**, **Blocked**, **Not Started**.

## Tips

- A roadmap is a communication tool, not a project plan. Keep it at the right altitude — themes and outcomes, not tasks.
- When reprioritizing, always ask what changed. Priority shifts should be driven by new information, not whim.
- Flag capacity issues early. If the roadmap has more work than the team can handle, say so.
- Dependencies are the biggest risk to roadmaps. Surface them explicitly.
- If the user asks to add something, always ask what comes off or moves. Roadmaps are zero-sum against capacity.

Источник: anthropics/knowledge-work-plugins / product-management / roadmap-update ↗. Ссылка проверена 2026-10-10.

---
name: roadmap-update
description: Обновляет, создаёт или переприоритизирует дорожную карту продукта. Используй при добавлении новой инициативы и решении, что сдвинуть ради неё, при смене приоритетов после получения новой информации, при переносе сроков из-за срыва зависимости или при построении вида «Сейчас / Дальше / Потом» с нуля.
argument-hint: "<update description>"
---

# Обновление дорожной карты

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

Обнови, создай или переприоритизируй дорожную карту продукта.

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

```
/roadmap-update $ARGUMENTS
```

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

### 1. Пойми текущее состояние

Если подключён **~~project tracker**:
- Подтяни текущие пункты дорожной карты с их статусами, исполнителями и датами
- Выяви просроченные пункты, пункты под риском и недавно завершённые
- Покажи пункты без чётких владельцев или дат

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

### 2. Определи операцию

Спроси, что пользователь хочет сделать:

**Добавить пункт**: новая функция, инициатива или рабочий пункт в дорожную карту
- Собери: название, описание, приоритет, оценку трудозатрат, целевой срок, владельца, зависимости
- Предложи, куда он встраивается, исходя из текущих приоритетов и ёмкости

**Обновить статус**: изменить статус существующих пунктов
- Варианты: не начат, в работе, под риском, заблокирован, завершён, отменён
- Для «под риском» или «заблокирован»: спроси про блокирующий фактор и план его снятия

**Переприоритизировать**: изменить порядок или приоритет пунктов
- Спроси, что изменилось (новая информация, смена стратегии, изменение ресурсов, отзывы клиентов)
- Примени рамку приоритизации, если это поможет — см. **Рамки приоритизации** ниже: RICE, MoSCoW, ICE и «ценность против трудозатрат»
- Покажи сравнение «до и после»

**Сдвинуть сроки**: перенести даты пунктов
- Спроси почему (изменение объёма, срыв зависимости, нехватка ресурсов)
- Определи последствия для зависимых пунктов
- Отметь пункты, которые уходят за жёсткие дедлайны

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

### 3. Составь сводку по дорожной карте

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

#### Обзор статусов
Краткая сводка: X пунктов в работе, Y завершено за период, Z под риском.

#### Пункты дорожной карты
По каждому пункту покажи:
- Название и однострочное описание
- Индикатор статуса (по плану / под риском / заблокирован / завершён / не начат)
- Целевой срок или дату
- Владельца
- Ключевые зависимости

Группируй пункты по:
- Горизонту («Сейчас / Дальше / Потом») или кварталам, в зависимости от формата
- Либо по темам или целям, если пользователь предпочитает так

#### Риски и зависимости
- Заблокированные пункты и пункты под риском, с подробностями
- Зависимости между командами и их статус
- Пункты, приближающиеся к жёстким дедлайнам

#### Изменения в этом обновлении
Если это обновление существующей дорожной карты, подведи итог изменений:
- Добавленные, удалённые или переприоритизированные пункты
- Сдвиги сроков
- Изменения статусов

### 4. Дальнейшие шаги

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

## Форматы дорожных карт

### «Сейчас / Дальше / Потом» (Now / Next / Later)
Самый простой и часто самый эффективный формат дорожной карты:

- **Сейчас** (текущий спринт или месяц): взятая в работу задача. Высокая уверенность в объёме и сроках. Это то, что команда активно строит.
- **Дальше** (следующие 1–3 месяца): запланированная работа. Хорошая уверенность в том, что делать, меньшая — в том, когда именно. Объём и приоритеты определены, но работа ещё не начата.
- **Потом** (3–6+ месяцев): направление. Это стратегические ставки и возможности, которые мы намерены реализовать, но объём и сроки гибкие.

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

### Квартальные темы
Организуй дорожную карту вокруг 2–3 тем на квартал:

- Каждая тема представляет стратегическое направление вложений (например: «Готовность к крупным клиентам», «Улучшение активации», «Расширяемость платформы»)
- Под каждой темой перечисли конкретные запланированные инициативы
- Темы должны соответствовать OKR компании или команды
- Этот формат позволяет легко объяснить, ПОЧЕМУ вы строите то, что строите

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

### Дорожная карта, привязанная к OKR
Сопоставь пункты дорожной карты напрямую с целями и ключевыми результатами:

- Начни с OKR команды на период
- Под каждым ключевым результатом перечисли инициативы, которые сдвинут эту метрику
- Укажи ожидаемое влияние каждой инициативы на ключевой результат
- Это создаёт чёткую подотчётность между тем, что вы строите, и тем, что измеряете

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

### Вид «лента времени / диаграмма Ганта»
Календарный вид с пунктами на шкале времени:

- Показывает даты начала, окончания и длительности
- Визуализирует параллельность и последовательность
- Хорош для выявления конфликтов ресурсов
- Показывает зависимости между пунктами

Когда использовать: для планирования исполнения вместе с разработкой. Для выявления конфликтов в расписании. НЕ годится для коммуникации вовне (создаёт ожидания ложной точности).

## Рамки приоритизации

### Оценка RICE
Оцени каждую инициативу по четырём измерениям, затем рассчитай RICE = (Охват x Влияние x Уверенность) / Трудозатраты

- **Reach (охват)**: сколько пользователей или клиентов это затронет за заданный период? Используй конкретные числа (например: «500 пользователей в квартал»).
- **Impact (влияние)**: насколько это сдвинет ситуацию для каждого охваченного человека? Оценка по шкале: 3 = огромное, 2 = высокое, 1 = среднее, 0,5 = низкое, 0,25 = минимальное.
- **Confidence (уверенность)**: насколько мы уверены в оценках охвата и влияния? 100% = высокая уверенность (подкреплена данными), 80% = средняя (есть некоторые подтверждения), 50% = низкая (интуиция).
- **Effort (трудозатраты)**: сколько человеко-месяцев работы? Включай разработку, дизайн и любые другие функции.

Когда использовать: когда нужна количественная, защитимая приоритизация. Хорош для сравнения большого бэклога инициатив. Хуже подходит для стратегических ставок, где влияние трудно оценить.

### MoSCoW
Раздели пункты на «обязательно» (Must have), «желательно» (Should have), «можно» (Could have), «не будет» (Won't have):

- **Must have (обязательно)**: без них дорожная карта провалена. Безусловные обязательства.
- **Should have (желательно)**: важно и ожидаемо, но поставка возможна и без них.
- **Could have (можно)**: желательно, но явно менее приоритетно. Включай, только если позволяет ёмкость.
- **Won't have (не будет)**: явно вне объёма на этот период. Важно перечислить для ясности.

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

### Оценка ICE
Проще, чем RICE. Оцени каждый пункт от 1 до 10 по трём измерениям:

- **Impact (влияние)**: насколько это сдвинет целевую метрику?
- **Confidence (уверенность)**: насколько мы уверены в оценке влияния?
- **Ease (лёгкость)**: насколько легко это реализовать? (обратная величина трудозатрат — чем выше, тем легче)

Оценка ICE = Влияние x Уверенность x Лёгкость

Когда использовать: для быстрой приоритизации бэклога функций. Хорош для продуктов на ранней стадии или когда данных для RICE недостаточно.

### Матрица «ценность против трудозатрат»
Расположи инициативы на матрице 2×2:

- **Высокая ценность, малые трудозатраты** (быстрые победы): делай в первую очередь.
- **Высокая ценность, большие трудозатраты** (крупные ставки): планируй тщательно. Стоят вложений, но требуют правильного определения объёма.
- **Низкая ценность, малые трудозатраты** («заполнители»): делай, когда есть свободная ёмкость.
- **Низкая ценность, большие трудозатраты** («ямы для денег»): не делай. Убери из бэклога.

Когда использовать: для наглядной приоритизации на планировании команды. Хорош для выработки общего понимания компромиссов.

## Карта зависимостей

### Выявление зависимостей
Ищи зависимости в следующих категориях:

- **Технические зависимости**: функция B требует инфраструктурной работы из функции A
- **Зависимости от команд**: функция требует работы другой команды (дизайн, платформа, данные)
- **Внешние зависимости**: ожидание поставщика, партнёра или интеграции со сторонним сервисом
- **Зависимости от знаний**: нужны результаты исследования или расследования до начала
- **Последовательные зависимости**: нужно выпустить функцию A до начала функции B (общий код, пользовательский сценарий)

### Управление зависимостями
- Явно перечисли все зависимости в дорожной карте
- Назначь владельца каждой зависимости (кто отвечает за её разрешение)
- Задай срок «нужно к»: когда зависящему пункту нужно, чтобы это было решено
- Закладывай запас вокруг зависимостей — это самые рискованные пункты в любой дорожной карте
- Рано отмечай зависимости, пересекающие границы команд — они требуют координации
- Имей запасной план: что делать, если зависимость сорвётся?

### Сокращение зависимостей
- Можно ли построить более простую версию, которая обходит зависимость?
- Можно ли распараллелить работу с помощью контракта интерфейса или заглушки?
- Можно ли изменить последовательность, чтобы зависимость решалась раньше?
- Можно ли взять эту работу на свою команду, чтобы убрать межкомандную координацию?

## Планирование ёмкости

### Оценка ёмкости
- Начни с числа инженеров и периода времени
- Вычти известные накладные расходы: встречи, дежурства, собеседования, праздники, отпуска
- Распространённое эмпирическое правило: инженеры тратят 60–70% времени на запланированную работу над функциями
- Учти время вхождения в работу для новых членов команды

### Распределение ёмкости
Здоровое распределение для большинства продуктовых команд:

- **70% запланированных функций**: пункты дорожной карты, продвигающие стратегические цели
- **20% технического здоровья**: технический долг, надёжность, производительность, удобство разработки
- **10% незапланированного**: запас на срочные проблемы, быстрые победы и просьбы других команд

Корректируй соотношения по контексту команды:
- Новый продукт: больше работы над функциями, меньше технического долга
- Зрелый продукт: больше вложений в технический долг и надёжность
- После инцидента: больше надёжности, меньше функций
- Быстрый рост: больше масштабируемости и производительности

### Ёмкость и амбиции
- Если обязательства в дорожной карте превышают ёмкость, чем-то придётся пожертвовать
- Не решай проблемы с ёмкостью, делая вид, что люди могут больше, — решай сокращением объёма
- Добавляя пункт в дорожную карту, всегда спрашивай: «Что убираем?»
- Лучше взять на себя меньше и выполнить надёжно, чем взять слишком много и разочаровать

## Коммуникация изменений дорожной карты

### Когда дорожная карта меняется
Типичные поводы для изменения дорожной карты:
- Новый стратегический приоритет от руководства
- Отзывы клиентов или исследования, меняющие приоритеты
- Технические открытия, меняющие оценки
- Срыв зависимости от другой команды
- Изменение ресурсов (команда растёт или сокращается, уходит ключевой человек)
- Ход конкурента, требующий ответа

### Как сообщать об изменениях
1. **Признай изменение**: говори прямо, что меняется и почему
2. **Объясни причину**: какая новая информация привела к этому решению?
3. **Покажи компромисс**: что было понижено в приоритете, чтобы освободить место? Или что сдвигается?
4. **Покажи новый план**: обновлённая дорожная карта с отражёнными изменениями
5. **Признай последствия**: кого это затрагивает и как? Заинтересованные лица, которые ждали пункты с пониженным приоритетом, должны услышать об этом напрямую.

### Как избежать «качелей» дорожной карты
- Не меняй дорожную карту при каждой новой информации. Установи порог для изменений.
- Объединяй обновления дорожной карты в естественные циклы (месячные, квартальные), если только дело не действительно срочное.
- Различай «изменение дорожной карты» (стратегическая переприоритизация) и «корректировку объёма» (обычное уточнение при исполнении).
- Отслеживай, как часто меняется дорожная карта. Частые изменения могут говорить о нечёткой стратегии, а не о хорошей отзывчивости.

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

Используй понятный формат, удобный для беглого просмотра. Для пунктов дорожной карты хорошо подходят таблицы. Используй текстовые метки статуса: **Готово**, **По плану**, **Под риском**, **Заблокирован**, **Не начат**.

## Советы

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

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