Глибше: фічі, стадії розробки й рівень упевненості

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

На роадмапі, орієнтованій на результат, фіча (feature) ніколи не стоїть окремо. Вона стоїть під темою, якій служить, тож «навіщо» видно над нею. Листи-нагадування з'являються не окремим рядком у Now, а під темою «Підписники не залишаються без корму між доставками» — як рішення, яке команда будує для цієї потреби.

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

Фіча заслуговує на місце під темою з однієї з трьох поширених причин.

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

Робота-передумова (enabling work), яку, як завжди, оцінюють за ключовими результатами, що вона відмикає: системна потреба, яку інженери вже перетворили на конкретне, перевірене рішення, як-от заміна складської системи.

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

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

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

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

Місяці біля перших рядків — другий тривожний знак. «Нагадування (листопад) · портал для клінік (грудень)» — це графік релізів, ще й із датою для порталу, якого пілот навіть не обрав.

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

Стадія розробки (stage of development) показує, наскільки пункт просунувся від проблеми до рішення. Обери кілька стадій, що пасують твоїй команді, і один раз визнач кожну, щоб усі читали їх однаково. Котокорм має чотири:

• Досліджуємо: проблему ще вивчають; нічого не обрано.
• Тестуємо: кілька клієнтів пробують рішення; деталі ще зміняться.
• Будуємо: рішення обрано, його розробляють.
• Шліфуємо: воно вже працює, і команда доводить його до ладу, стежачи, чи рухається сигнал.

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

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

Рівень упевненості (confidence) показує, наскільки ймовірно, що пункт буде зроблено у своєму часовому горизонті й приблизно в такому вигляді. Колонки вже на це натякають, бо Now певніший за Later, але якщо записати, пропустити неможливо: скажімо, Now — близько 80%, Next — близько 50%, Later — близько 20%. А 100% не заявляй ніколи.

Упевненість для колонки — чесна. Упевненість для кожного пункту з точністю до відсотка — зазвичай ні. Цифра на кшталт 73% виглядає виміряною, але це відчуття в лабораторному халаті. Це хибна точність (false precision): план здається певнішим, ніж є, а люди починають сприймати цифру як дані — цитують її й вимагають від команди її дотримати.

Краща альтернатива — назвати докази: що в нас насправді є за цим пунктом? Наша власна думка, кілька запитів, закономірність у даних чи результати клієнтів, які це спробували. «Тестуємо у двох клініках, перші результати в грудні» каже читачеві набагато більше, ніж «73%»: що відомо, що ні і коли це зміниться.

Що більше доказів, то вища впевненість, і примітка може про це сказати.

Навіть добре відрізана Now часто містить трохи більше, ніж команда напевно встигне за квартал. Замість удавати, що це не так, проведи в колонці лінію впевненості (confidence line).

Над лінією — те, що команда бере на себе в цьому кварталі. Для Котокорму: листи-нагадування, пілот у клініках і робота над складом. Під лінією — те, до чого команда дотягнеться, якщо все піде добре, як-от гнучкі дати доставки.

Лінія змінює те, як сприймається зсув. Якщо пункт під нею не вийде, він просто переходить на верх Next, і ніхто не порушив обіцянки, бо всі заздалегідь бачили, які пункти були бонусом. Без лінії той самий зсув виглядає як провал, і наступний план роздувають «про всяк випадок».

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

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

Для Котокорму це два пункти. Інженери впевнені щодо листів-нагадувань (друга половина листопада) і першого огляду пілоту (початок грудня), тож обидва отримують орієнтовну дату. Склад — поки що ні: команда знатиме після тесту перенесення даних у листопаді. Запуск для всіх 14 клінік — теж ні, бо він залежить від результатів пілоту й від складу.

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

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

Продуктові напрями (product areas) позначають, якої частини продукту стосується пункт: для Котокорму це підписка, замовлення для клінік, склад і доставка. Це один із додаткових елементів, і, як кожен із них, він заслуговує на місце, лише коли він потрібен справжньому читачеві.

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

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

Тож перевірка та сама, що й для кожного додаткового елемента: хто про це просив і на яке його питання це відповідає? Якщо не можеш назвати читача, не додавай. Додати завжди можна пізніше, коли організація виросте.

Кожне доповнення на роадмапі має відповідати на питання, яке поставив справжній читач. Цільові клієнти (target customers) позначають, якій групі служить кожна тема: підписникам, новим власникам чи партнерським клінікам. Продажам це найшвидший спосіб знайти те, що важить клієнтові на дроті; керівникам — перевірка, чи якусь групу тихо не залишили поза увагою.

• Інженери питають: що ми будуємо і наскільки це вирішено? Фічі під темами й стадії.
• Продажі питають: що можна сказати цьому клієнтові? Цільові клієнти й стадії.
• CEO й рада директорів питають: наскільки певний план? Упевненість для колонок і мало що понад те.

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

Як це складається докупи: Доповнення лежать поверх п'яти компонентів, і кожне відповідає на питання одного читача. Версія 3: теми з фічами під ними, стадії, упевненість для колонок із лінією всередині Now, дати лише там, де команда впевнена. Модуль 4 вирішує, які можливі рішення йдуть першими, на основі доказів.