roadmap-methodology

---
name: roadmap-methodology
description: Use when planning product roadmaps, shaping scope, mapping outcomes, or applying roadmap frameworks such as Shape Up, Impact Mapping, User Story Mapping, OKRs, and RICE.
---

# Roadmap Methodology

Справочник методологий для построения roadmap. Использовать как reference при работе с пользователем.

## Shape Up (Ryan Singer, Basecamp)

### Appetite vs Estimate
- **Appetite** — "сколько мы готовы потратить" (бюджет). Число первое, дизайн потом.
- **Estimate** — "сколько это займёт" (оценка). Дизайн первый, число потом.
- Всегда спрашивай: "Сколько ты готов потратить на это?" — не "сколько это займёт?"

### Shaping — три свойства хорошей работы
1. **Rough** — намеренно грубая, оставляет место для решений команды
2. **Solved** — основные элементы продуманы, rabbit holes найдены
3. **Bounded** — чётко что входит и что НЕ входит

### Fixed Time, Variable Scope
- Дедлайн фиксирован, скоуп — нет
- Создаёт давление для компромиссов
- "Лучшее" всегда относительно ограничений

### Scopes (вертикальные срезы)
- Интегрированные куски: фронт + бэк вместе
- НЕ "слоёные" (layer cakes): отдельно UI, отдельно API
- Каждый scope имеет имя и может быть завершён независимо

### Scope Hammering — вопросы для сокращения
- Это must-have? Можно отшиппить без этого?
- Что случится если НЕ делать?
- Core use case или edge case?
- Новая проблема или существующая?
- Насколько часто это будет происходить?

### Hill Chart — прогресс
- Левый склон (uphill): неизвестность, исследование
- Вершина: "я знаю что делать"
- Правый склон (downhill): исполнение, уверенность

### Circuit Breaker
- Если не готово к дедлайну — не продлевать автоматически
- Либо шипим, либо переформируем как новый проект

## Impact Mapping (Gojko Adzic)

### Четыре уровня
```
ЦЕЛЬ (ЗАЧЕМ?) → АКТОР (КТО?) → ВЛИЯНИЕ (КАК?) → ФУНКЦИОНАЛ (ЧТО?)
```

### Вопросы по уровням
**Цель:** Какой бизнес-результат? Как измерить? К какому сроку?
**Актор:** Кто выиграет? Кто проиграет? Кто использует?
**Влияние:** Как должно измениться поведение актора?
**Функционал:** Что построить чтобы поддержать влияние?

### Двойная гипотеза
Каждая фича — это: (1) если сделаем X, актор изменит поведение + (2) если изменит, цель будет достигнута.

## User Story Mapping (Jeff Patton)

### Структура карты
- **Горизонталь** = путь пользователя слева направо
- **Вертикаль** = приоритет (сверху — важнее)
- **Backbone** = верхняя строка, главные шаги
- **Releases** = горизонтальные срезы

### Три уровня декомпозиции
1. **Activities** — крупные блоки (Публикация, Управление)
2. **Steps** — подшаги (Загрузить, Отправить, Подтвердить)
3. **Details** — конкретные истории (edge cases, варианты)

### "Миля вширь, дюйм вглубь"
- Сначала backbone целиком (все шаги)
- Потом углубляйся в каждый шаг

### Walking Skeleton
- Первый release: один тонкий сквозной путь через всю систему
- Минимум чтобы работало end-to-end

## The Mom Test (Rob Fitzpatrick) — техника вопросов

### Три правила
1. Говори о жизни собеседника, не о своей идее
2. Спрашивай о конкретных событиях в прошлом, не о гипотетическом будущем
3. Меньше говори, больше слушай

### Хорошие вопросы
- "Расскажи как ты решаешь это сейчас?"
- "Когда это происходило в последний раз?"
- "Что самое сложное в этом?"
- "Почему это сложно?"
- "Сколько это стоит тебе сейчас — временем?"
- "Что произойдёт если не решишь?"

### Плохие вопросы (никогда не задавай)
- "Тебе нравится эта идея?"
- "Ты бы использовал X?"
- "Это проблема, правда?"
- "Оцени по шкале от 1 до 5"

## Theory of Constraints (Eliyahu Goldratt)

### 5 шагов фокусировки
1. **Найди** ограничение (bottleneck) системы
2. **Используй** его по максимуму без доп. затрат
3. **Подчини** всё остальное ограничению
4. **Расширь** ограничение если предыдущих шагов мало
5. **Повтори** — не дай инерции стать новым ограничением

### Применение к roadmap
- Найди самый узкий ресурс (один разработчик = он bottleneck)
- Не загружай его мелочами — только throughput-задачи
- Cognitive load = ограничение соло-разработчика

## Continuous Discovery (Teresa Torres)

### Opportunity Solution Tree
```
[Desired Outcome]
    ↓
[Opportunity Space] (боли, потребности)
    ↓
[Solutions] (несколько вариантов на каждую opportunity)
    ↓
[Experiments] (проверка гипотез)
```

### Правила
- Opportunity ≠ solution ("нужна функция X" это solution, не opportunity)
- Формулируй с точки зрения пользователя
- Всегда генерируй 3+ решений на одну opportunity
- Тестируй предположения, не идею целиком