Що таке роадмапа (і чим вона не є)

Продуктова роадмапа (product roadmap) — це стратегічний інструмент комунікації. Вона показує, як продукт рухатиметься до свого бачення: які проблеми клієнтів і бізнес-цілі команда розв'язуватиме, приблизно в якому порядку і навіщо. Вона відповідає на три запитання для всіх, хто працює з продуктом: куди ми йдемо, навіщо і що буде першим.

Зверни увагу, чого тут немає: точних дат, виконавців завдань, стор-поінтів. Вони живуть деінде.

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

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

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

Порівняй дві сторінки для однієї команди. На першій — результати в широкому порядку: що зараз, що далі, що пізніше, з приміткою, що «далі» й «пізніше» зміняться, і датою останнього перегляду. На другій — фічі з точними днями поруч.

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

Час із такої роадмапи не зникає: читачі й далі бачать, що буде першим і приблизно коли. Зникає лише фальшива точність, яка перетворює план на борг команди.

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

• Продуктова роадмапа: куди ми йдемо, навіщо і що буде першим? Напрям і причини.
• План релізів (release plan): які рішення виходять у якому релізі, з обсягом, датами й ресурсами. Він відповідає на «як і коли» для роботи, яку роадмапа вже обґрунтувала через «що і навіщо».
• Беклог продукту (product backlog): впорядкований список історій і багів, які команда візьме в найближчих спринтах.
• План проєкту, часто у вигляді діаграми Ганта: хто виконує яке завдання і що від чого залежить.

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

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

У Котокормі CEO Ian просить роадмапу на наступний рік до п'ятниці: кожен із 40 запитів із командної таблиці з місяцем поруч, «щоб продажі й маркетинг могли під неї планувати». Прохання — дати. Причина — у другій половині повідомлення: раді директорів, продажам і маркетингу треба планувати.

Для планування потрібні чіткий напрям і порядок пріоритетів. Сорок здогадок, видаваних за зобов'язання, для цього не потрібні: до травня частина фіч посунеться, кілька виявляться непотрібними, а клієнт тицятиме продажникам березневою датою. Дай Ian напрям і порядок, а тверді дати лиши для роботи, за яку команда справді може поручитися.

Дати в кожному рядку роадмапи мають приховану ціну: щоб поставити дату в кожен рядок, хтось має оцінити кожен рядок, задовго до того, як стане зрозуміло, яким буде рішення. У Котокормі техлідка Lucy чує, що в роадмапі буде дата для кожної з 40 фіч, і питає, чи потрібні їй оцінки для всіх до п'ятниці. Половину з них її команда ледве розуміє.

Запит «оптові замовлення для клінік» може означати спільну таблицю, а може — цілу систему замовлень; оцінка повністю залежить від того, що команда зрештою будуватиме. Цифри, отримані так, — здогадки, вбрані в план, і вони приховують невизначеність замість того, щоб її показати.

Чесній роадмапі не потрібні оцінки на рік наперед. Вона називає проблеми та їхній порядок. Розробка оцінює рішення тоді, коли команда розуміє проблему й вибрала, як її розв'язати, а це зазвичай відбувається близько до самої роботи.

Роадмапа стає обіцянкою тієї миті, коли її дати починають читати як зобов'язання. Тоді дати потрапляють у договори, а кожна затримка коштує довіри клієнта. У Котокормі все починається з одного повідомлення в чаті: Brandon, менеджер ключових клієнтів, сказав PurrPoint, мережі з 14 ветклінік, що оптові замовлення будуть готові у квітні, і просить поставити це в роадмапу на квітень.

Гучні симптоми помітити легко:

• фічі й дати з роадмапи з'являються в договорах із клієнтами;
• продажі закривають угоди на фічі, яких ще не існує.

Тихі пропустити простіше:

• команда вчасно випускає все, а утримання й виручка не зрушують;
• фічі проходять приймання, але проблему не розв'язують;
• на запитання «а навіщо це в роадмапі?» чути лише, коли це має бути готово.

Оцінки на рік наперед, прихована ціна списку фіч із датами, — з тієї самої родини. Здорові ознаки протилежні: кожен пункт пов'язаний із бізнес-ціллю, а на сторінці прямо сказано, що плани змінюватимуться, коли команда дізнаватиметься більше.

Коли хтось просить поставити в роадмапу конкретне рішення з датою, спитай навіщо, перш ніж ставити дату. За проханням ховається проблема, і саме за неї команда може взяти зобов'язання.

Обіцянка Brandon для PurrPoint на квітень показує три погані варіанти. Сказати «так» — значить поставити в роадмапу дату, яку команда ніколи не перевіряла, для рішення, яке ніхто не розглядав. Пряма відмова підставить Brandon перед клієнтом, який от-от підпише договір на 14 клінік. Тихо відкласти це в «Пізніше», поки Brandon каже, що це в роадмапі, — просто розмитіша обіцянка.

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

Коли проблема зрозуміла, Котокорм може пообіцяти розв'язати саме її й поставити дату лише на ту частину, у якій команда впевнена. Наступний урок перетворить це «навіщо?» на метод.

Три швидкі перевірки покажуть, чи роадмапа робить свою роботу.

• Перевірка сліду: тицьни в будь-який рядок і спитай, якій цілі чи проблемі клієнта він служить. Якщо ніхто не може відповісти, цьому рядку тут не місце.
• Перевірка зміни: уяви, що в березні команда дізналася щось, що перетасовує план. Чи можна оновити сторінку, не порушивши нічиєї обіцянки? Якщо ні, вона написана як контракт.
• Перевірка читача: техлід, продажник, CEO і клієнт по черзі відкривають її. Чи кожен знаходить свою відповідь (навіщо, що першим, до чого готуватися), не кличучи тебе на зустріч?

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

Як це складається докупи: роадмапа, що проходить усі три перевірки, показує напрям, причини й порядок замість обіцянок із датами. Вона закриває потребу за проханнями, як у Ian і Brandon, і витримує все, що команда дізнається. Далі урок Результати (outcome) важливіші за вихід (output) покаже, що писати в кожному рядку.