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
• Тестируй предположения, не идею целиком