Роадмапінг

Роадмап на одному екрані — готовий

Більшість тих, хто шукає роадмапінг, хоче побачити роадмап, який переживе зустріч зі стейкхолдерами. Ось один — роадмап клієнтської команди інтернет-магазину, що проходить крізь сторінки розділів «Декомпозиція», «Процес релізу» і Product Discovery, у вигляді, в якому його переглянули в понеділок 19 жовтня 2026 року. Це власна версія команди; розділ про читачів показує, що отримують двоє інших. Наступні розділи посилаються на рядки за номерами.

1. 1.Чому він служить

   1. 1.1Купувати повторно легко: повернення на 2-му тижні з 18% до 25% — key result 1.1 на сторінці про OKROKRObjectives and Key Results — ціль із вимірюваними результатамиМетод постановки цілей, що поєднує одну якісну ціль із двома-п’ятьма вимірюваними key results, які доводять, що її досягнуто; їх ставлять і переглядають щокварталу. Він перестає працювати, коли key results стають списком задач або оцінки впливають на оплату.Докладніше в статті →Усі терміни, aspirational
   2. 1.2Оплата не підводить клієнта: частка успішних оплат щонайменше 97,5% щотижня — committed key result 2.1 на сторінці про OKR
   3. 1.3Під стратегією компанії на рік: зростати на постійних клієнтах, а не купувати нових

2. 2.Now — будується або виходить; рішення відоме

   1. 2.1Повторне замовлення з історії — фіча 1 епіка про повторні замовлення; клієнти бачать її поетапно з 26 жовтня до 16 листопада, за планом релізу
   2. 2.2Автоматичний повтор і повернення коштів, коли платіжний провайдер не відповідає, — служить 1.2; будується за прапорцем, виходить після заморозки з 5.1

3. 3.Next — проблему й результат обрано; рішення ще перевіряється

   1. 3.1Збережені кошики — фіча 2 епіка, із січня; discovery залишив це рішення другим для «знайти кожну річ знову — ціла вічність»
   2. 3.2«Я згадую про замовлення, лише коли щось закінчилося» — нагадування, фіча 3, будуються, лише якщо зрушать випереджальні показники 2.1
   3. 3.3«Оплата не пройшла, і я не знаю, чи з мене списали гроші» — що бачить клієнт після тайм-ауту, коли 2.2 вже прибере подвійні списання; служить 1.2

4. 4.Later — напрямок; без рішення й без дати

   1. 4.1Клієнтам, які купують той самий кошик раз на кілька тижнів, взагалі не доводиться починати замовлення, — підписки, відкладені discovery як рішення D
   2. 4.2Постійним клієнтам допомагають обирати, а не лише повторювати, — епік називає це окремою ставкою

5. 5.Дати, які команда захищає, — небагато, і кожну взято після discovery

   1. 5.1Передсезонна заморозка змін, з 19 листопада до 1 грудня, — дата компанії, а не команди; нічого нового за цей час до клієнтів не доходить
   2. 5.2Подарункові картки для кампанії партнера, запуск 1 березня 2027 року, — попросили 21 вересня, зобов’язання взяли 9 жовтня після двотижневого спайку, записано в договір із партнером
   3. 5.3Поле zip зникає з бібліотеки замовлень не раніше 15 березня 2027 року — нижня межа, яку винні чотирьом іншим командам, а не обіцянка прибрати його саме тоді

6. 6.Просили, але цього тут немає — кожну відмову дано щодо результату

   1. 6.1Купівля одним дотиком — відкинуто на discovery, бо закон про кнопки замовлення її виключає
   2. 6.2Бонусні бали, про які просили продажі, — у дереві над ними немає можливості, і вони рухали б суму замовлення, а не 1.1
   3. 6.3Перелік фіч із датами для звіту правлінню — замінено на 7.2

7. 7.Хто бачить яку версію — і як вона змінюється

   1. 7.1Команда: ця версія, щопонеділка, з перевірками, що йдуть під кожним пунктом Next
   2. 7.2Стейкхолдери: усі групи, Next — лише як проблеми, на п’ятнадцятихвилинному огляді в перший четвер кожного місяця
   3. 7.3Клієнти: три теми в довідковому центрі — без дат і без нічого з Next
   4. 7.4Перегляд щокварталу щодо OKR; наступний — у вівторок 12 січня 2027 року
   5. 7.5Пункт переходить із Next у Now лише тоді, коли його результат має число, а рішення пережило перевірку

Що таке роадмап — і два способи, якими датований роадмап помиляється

Брюс Маккарті й співавтори визначають роадмап у книжці «Product Roadmaps Relaunched» (2017) як заяву про намір і напрямок. Їхні основні компоненти лягають просто на хук. Бачення продукту й бізнес-цілі — це група 1. Часові рамки — три широкі горизонти замість місяців. Теми — проблеми з груп 3 і 4. А застереження — рядок 7.4: документ уголос каже, що зміниться.

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

Два незалежні способи, якими роадмап із фічами й датами помиляється

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

Другий важить більше. Марті Кейган сказав це прямо 2013 року: «щонайменше половина наших ідей просто не спрацює», а «навіть з ідеями, що виявляються цінними, зручними й здійсненними, зазвичай потрібно кілька ітерацій», перш ніж вони дадуть очікувану бізнесову цінність. Цифри експериментів на сторінці про Product Discovery ще суворіші. Тож навіть якби всі дати витримали, роадмап із фічами й датами був би обіцянкою вчасно поставити конкретний набір здогадок.

Саме тому суперечка між продуктом і стейкхолдерами так часто ходить по колу. Обидві сторони мають рацію: стейкхолдеру справді треба на щось спиратися в планах, а команда справді не може обіцяти фічі, яких не перевірила. Альтернатива Кейгана, описана у вересні 2015 року, змінює те, що обіцяють. Кожна команда отримує бачення продукту й бізнес-цілі — на практиці свої OKR — і її оцінюють за тим, чи рухаються числа. Небагато речей, яким справді потрібна дата, отримують те, що він називає високоцінним зобов’язанням (high-integrity commitment), і група 5 — перелік таких речей у магазині.

Now, Next, Later — горизонти впевненості замість дат

Джанна Бастоу і Саймон Каст створили роадмап Now-Next-Later 2012 року, коли будували ProdPad, після років спостереження за тим, як роадмапи-таймлайни породжують очікування, яких ніхто не виконує. Три колонки замінюють місяці впевненістю. Визначення самого ProdPad варто зберегти точними. У Now — «перевірені ініціативи, над якими команда активно працює, де проблему добре зрозуміли, а фокус перемістився на рішення». У Next «discovery звужує варіанти й починається дослідження рішень». У Later — «стратегічні проблемні області, що важливі команді, але ще не набули форми, з якою можна працювати».

Звуження — і є вся ідея. Рядок 2.1 зафіксовано й конкретно, бо роботу зрозуміли і план релізу існує. Рядок 3.2 називає проблему словами клієнта й результат, але не рішення, бо нагадування — досі ставка на випереджальні показники. Рядок 4.1 — напрямок, без дати й без обіцянки, що його переглядають щокварталу в міру появи даних.

Одне правило тримає формат чесним під тиском, і це рядок 7.5: пункт переходить із Next у Now лише тоді, коли його результат має число, а рішення пережило перевірку. Збережені кошики, рядок 3.1, перейдуть у січні, бо discovery їх перевірив, а епік дає їхньому результату число. Без цього шлагбаума Now наповнюється тим, що було терміновим, а не тим, що було готовим, і три колонки стають чергою з гарнішими заголовками.

Три читачі — три версії

Один файл не може обслужити всіх, хто просить роадмап, і саме через спробу так багато роадмапів одночасно надто розмиті, щоб планувати, і надто конкретні, щоб бути правдою. Три читачі хочуть різного й терплять різну міру невизначеності. Група 7 дає кожному власну версію, вирізану з одного джерела, тож версії ніколи не суперечать одна одній.

Версію для стейкхолдерів більшість команд робить неправильно — і зазвичай тим, що прибирає групу 6. Керівник продажів, який просив бонусні бали й не бачить їх без пояснення, вирішує, що запит загубився, і просить знову, гучніше. Побачивши його в переліку з причиною — над ним немає можливості, і він рухає не те число, — він або закриває розмову, або переносить її на правильний рівень, тобто до рядка стратегії 1.3.

Публічна версія

Найбільше дисципліна окупається у версії для клієнтів. Усе опубліковане назовні прочитають як зобов’язання, хоч би що казало застереження поруч, а продажі це процитують. GitHub публікує свій роадмап як публічний репозиторій, упорядкований за кварталами й фазами релізу, і його README прямо каже, що роадмап «не є зобов’язанням, гарантією чи обіцянкою випустити будь-який продукт чи функцію або випустити їх до певної дати». Компанія з юристами рівня GitHub однаково потребує цього речення — і це все, що треба знати про те, як читають публічний роадмап.

Звідси рядок 7.3: три теми, без дат, нічого з Next. Публікуйте менше пунктів, ніж робите, ніколи не публікуйте дату, яку не вирішили захищати, і чекайте питань про пункт, який ви прибрали. Обидві публічні обіцянки далі на цій сторінці коштували значно дорожче відкликати, ніж коштувало б їх не давати.

Порядок — чотири моделі, чотири думки про те, що означає «першим»

Формат не відповідає на питання, через яке насправді сперечаються: що з цього йде першим. Чотири моделі покривають майже кожну таку розмову. Кожна — інша думка про те, що означає «першим»: найбільше цінності на одиницю зусиль, найбільше грошей, утрачених через очікування, чого клієнти не пробачать або без чого проєкт помре.

Категорії Кано варто назвати поіменно, бо кожна передбачає іншу помилку. Обов’язкова фіча не отримує похвали, коли працює, і втрачає клієнта, коли не працює, — знати, чи списали гроші після невдалої оплати, саме така. Лінійна фіча тішить пропорційно: що швидше повторне замовлення, то краще. Захоплива фіча радує, коли вона є, і за нею не сумують, коли її немає, — тому підписки можуть почекати в Later. Байдужа нічого не змінює, а зворотна дратує частину клієнтів самим своїм існуванням. Тест MoSCoW для Must найпряміший: спитайте, що станеться, якщо вимогу не виконати, і лише якщо відповідь — «скасувати проєкт», це Must.

Шість кандидатів, оцінених двома способами

Ось шість пунктів, які команду магазину попросили впорядкувати у вересні, оцінені обома моделями. Reach — у постійних клієнтах за квартал, з приблизно 15 000. Складники вартості затримки — відносні бали за шкалою SAFeSAFeScaled Agile Framework — фреймворк, що веде багато agile-команд як однуScaled Agile Framework — ролі, події та практики для координації десятків agile-команд, побудовані навколо Agile Release Train: пʼять-дванадцять команд, що планують разом раз на вісім-дванадцять тижнів. Це найбільш приписовий і найпоширеніший фреймворк масштабування — і саме тому його можна встановити, не змінивши того, хто ухвалює рішення.Докладніше в статті →Усі терміни. Кожне вхідне число — здогад, про який команда сперечалася, і саме ця суперечка є корисним результатом.

Читайте розбіжності, а не рейтинги. Подарункові картки падають із другого місця на останнє, коли модель забуває про час, бо в RICE немає колонки для дати з договору, — бал критичності в часі, 20, і є вся причина, чому вони в групі 5. Нагадування на другому місці за RICE, а епік однаково каже не будувати їх, доки не зрушать випереджальні показники: бал не знає про залежності. Допис самого Intercom каже те саме: «бали RICE не варто застосовувати як жорстке правило». Єдиний пункт, щодо якого обидві моделі згодні, — статус після невдалої оплати — водночас обов’язкова фіча за Кано. Коли три думки про «першим» збігаються, можна припинити суперечку.

Друга половина впорядкування — відмови, і в них своя техніка. Запит, відхилений через брак рук («у нас немає часу»), запрошує прохача знайти вам більше рук — а він часто може. Запит, відхилений щодо результату («бонусні бали рухали б суму замовлення, а квартал — про повернення; якщо ціль хибна, то саме про це й треба говорити»), переносить розмову на рівень, де її справді можна вирішити. Кожен рядок групи 6 написано саме так.

Дати — небагато, після discovery, і їх захищають

Відмова від будь-яких дат — теж провал. Деякі дати справжні: договір, регуляторний дедлайн, запуск на події, партнер, що виходить у продакшн. Відповідь Кейгана в есеї 2015 року і в його наступних книжках — високоцінне зобов’язання: його беруть свідомо, для небагатьох речей і після достатнього discovery, щоб розуміти обрис роботи. Його словами: «Ми робимо це в тих ситуаціях, коли справді потрібно зобов’язатися щодо дати чи конкретного результату».

Порядок подій важить не менше за кількість. Рядок 5.2 це показує. Партнер попросив подарункові картки 21 вересня. Чесною відповіддю того дня була не дата, а дата для дати: «ви отримаєте її до 9 жовтня». Команда два тижні провела на спайку — APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни подарункових карток у платіжного провайдера, бухгалтерський облік, правила проти шахрайства, — розбила роботу на історії й спрогнозувала її за власною пропускною здатністю. Лише тоді вона взяла зобов’язання — на 1 березня, із запасом понад 85-й перцентиль прогнозу.

Basecamp пішов далі й перевернув оцінку. У «Shape Up» (2019) Раян Сінгер замінює оцінку апетитом — «кількістю часу, яку ми хочемо витратити на проєкт, на противагу оцінці» — і підсумовує: «Оцінки починаються з дизайну й закінчуються числом. Апетити починаються з числа й закінчуються дизайном». На роботу ставлять шеститижневими циклами, а запобіжник тримає дату чесною: «Якщо вони не встигли, за замовчуванням проєкт не отримує продовження». Поступається обсяг, а не дата. Саме це робить фіксовану дату сумісною з тим, що роботу не знають наперед.

Звідси практичне правило. У команди одночасно має бути дуже мало таких зобов’язань, і кожне треба трактувати як справжню обіцянку, а не рядок на діаграмі. У команди магазину їх три, і одне з них, 5.1, навіть не її власне. Роадмап, де дата стоїть біля кожного пункту, не має жодного високоцінного зобов’язання — він має тридцять низькоцінних, і ніхто не скаже, за якими з них компанію справді судитимуть.

Дві публічні обіцянки — і дві команди, що змінили формат

Перші два кейси — публічні дати, названі раніше, ніж стала відома найважча частина роботи. Інші два — команди, що змінили те, що публікують і обіцяють. Кожен прив’язано до рядка хука, який на нього відповідає.

AirPower — публічний рік раніше за відповідь про здійсненність

12 вересня 2017 року прес-реліз Apple про iPhone X дав «попередній погляд на AirPower — розроблений Apple аксесуар для бездротового заряджання, що з’явиться 2018 року», здатний одночасно заряджати iPhone, Apple Watch і AirPods у будь-якому місці килимка. 2018 рік минув без нього. 29 березня 2019 року Ден Річчо, керівник апаратної інженерії Apple, сказав: «Після чималих зусиль ми дійшли висновку, що AirPower не досягне наших високих стандартів, і скасували проєкт». Що саме не вдалося, Apple публічно так і не сказала. У цьому й річ: рік опублікували тоді, коли ризик, який Product Discovery називає здійсненністю, ще був відкритим, і Apple — компанія, якій не бракує інженерів, — з’ясовувала це півтора року під заголовками в пресі.

Cyberpunk 2077 — дату захищали, зберігаючи обсяг

9 червня 2019 року CD PROJEKT оголосила, що Cyberpunk 2077 вийде 16 квітня 2020 року на PC, PlayStation 4 і Xbox One. Її власні регуляторні звіти фіксують, що було далі: 16 січня реліз перенесли на 17 вересня 2020 року, «щоб тестувати, виправляти помилки й шліфувати гру»; 18 червня — на 19 листопада, і компанія наголосила, що це «не впливає на фіналізований вміст гри»; 27 жовтня — на 10 грудня. На момент релізу передзамовлень було понад 8 мільйонів. Гра вийшла 10 грудня, а версія для старих консолей потрапила до оглядачів, за словами компанії, «лише за день до релізу».

Через чотири дні після релізу правління прямо сказало інвесторам: «Після трьох переносів ми як правління надто зосередилися на тому, щоб випустити гру. Ми недооцінили масштаб і складність проблем, ми проігнорували сигнали про потребу в додатковому часі, щоб довести гру на базових консолях попереднього покоління». 18 грудня Sony прибрала гру з PlayStation Store після обговорення з компанією повного повернення коштів. Кожен перенос рухав дату й зберігав обсяг: ті самі консолі й завершений вміст. Важіль, який рядок 5.2 називає заздалегідь, — що вріжуть першим, якщо прогноз зсунеться, — так і не потягнули.

Basecamp і GitHub — змінити те, що обіцяють

Відповідь Basecamp, описана 2019 року як «Shape Up», узагалі прибирає довгий перелік. Там «немає беклогів»: перед кожним шеститижневим циклом «стіл ставок» обирає серед кількох опрацьованих пропозицій, а все необране просто не переходить далі. Дату фіксує цикл, а обсяг підлаштовується під неї, тож компанія нікому не винна перелік фіч. GitHub робить протилежне на публіці — публікує роадмап за кварталами й фазами релізу — і захищає себе застереженням, процитованим у розділі про читачів. Удвох вони позначають два чесні варіанти: не обіцяти нічого конкретного або публікувати, попередивши кожного читача, що це не обіцянка.

Де він вироджується — і чого роадмап не може

Зміна самого формату не працює, і саме на цьому більшість команд вивчає другу половину уроку. Стейкхолдери, які просили фічі з датами, а отримали Now/Next/Later, читатимуть це як ухиляння, доки щось не замінить утрачену визначеність. Замінює її ритм — щомісячний огляд із рядка 7.2, де вони бачать, як рухаються числа. Передбачувана інформація краща за передбачену дату, але лише якщо інформація справді надходить.

• Now/Next/Later, де до кожного пункту тихо додали дату, — старий роадмап у нових колонках.
• Later як кладовище запитів, яким ніхто не хоче відмовити вголос.
• Next, під яким не йде жодна перевірка, — тож пункти там чекають, а не вирішуються.
• Один роадмап для клієнтів, стейкхолдерів і команди — тож він не пасує нікому.
• Бал пріоритизації, сприйнятий як рішення, а не як привід до суперечки.
• Дата, названа того ж дня, коли її попросили, раніше, ніж хтось подивився на роботу.
• Відмови через брак рук — тож той самий запит повертається з більшою кількістю людей.
• Його ніколи не переглядають — і роадмап описує те, у що вірили два квартали тому.
• Результати без вимірювання за ними — ті самі фічі, лише краще сформульовані.

Коли це застосовувати

Пов’язані сторінки

• МенеджментProduct DiscoveryProduct discovery — це безперервна робота з вирішення, що варто будувати, через перевірку ідей на реальних клієнтах до того, як на них витрачено інженерний час. Це не фаза перед розробкою і не збір вимог: команда щотижня говорить із клієнтами й розкладає почуте як можливості, щоб рішення конкурували, а не приходили вже ухваленими. Сторінка починається з одного готового кварталу discovery; далі — discovery поруч із delivery, дерево можливостей і рішень, інтерв’ю, чотири ризики й карта припущень, перевірки від найдешевшої до найдорожчої, п’ять продуктів і перевірка, яка обійшлася б дешевше, та де практика вироджується.
• МенеджментМетрики та KPIМетрика — це число із записаним визначенням, за яким команда керує, а KPI — одна з небагатьох метрик, за якими команда чи компанія погодилася, щоб її оцінювали. Майстерність — у тому, щоб збудувати ланцюг від того, що команда може зрушити цього тижня, до того, що потрібне бізнесу цього року, тримати кожне число чесним під тиском і читати його, не обманюючи себе. Сторінка починається з готового набору метрик однієї команди; далі — слова й ланцюг, як записати визначення, закон Гудхарта й захисні метрики, одне число нагорі й дерево під ним, як читати число, чотири числа, що ввели в оману своїх власників, і де все це вироджується.
• МенеджментПланування релізуПланування релізу — це рішення про те, що потрапляє до користувачів, коли і як ви дізнаєтесь, що щось пішло не так. Найкорисніший крок у ньому — перестати вважати деплой і реліз однією подією: код потрапляє в production вимкненим, а відкриття доступу стає окремим, зворотним рішенням, яке ухвалюють поетапно. Сторінка починається з готового плану одного релізу; далі — деплой проти релізу, фіксована дата проти фіксованого обсягу, стратегії викочування, чотири види feature flag, шлях назад, чотири релізи, що провалилися, і рядок, якого бракувало кожному, та як вимірювати процес.