Agile Product Roadmapping - як це було в IPLand

1. Учасники
2. День перший - збір інформації
3. Демонстрація продукту і його розвитку за останні місяці
4. Розширений перерву на обід
5. Огляд инсайтов від ринку, користувачів, їх специфіки та потреб
6. Агрегація даних, відкриті питання, буфер часу
7. Складання карти розвитку продукту
8. Первинний грумінг ідей найближчих спринтів
9. Lessons learned

Стаття відображається на оригінальному мовою.

"Responding to change over following a plan" - важливий постулат філософії гнучкої розробки. Але він не має на увазі відсутність планів.

Плани або реакція на зміни? передбачуваність або адаптивність? довгострокова стратегія або тактичні цілі? - такі приклади вибору між двома істотними речами, і одне ціле, називають в науці "помилкової дихотомією", а в буддизмі "дуаліазмом". Нам важливі обидві складові. І одна не працює без іншого.

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

Проте - це дуже корисна вправа: відірватися від робочого столу і подивитися в далечінь. Тільки в product roadmapping'е ми це робить ні на самоті, а в колі колег і керівників.

Саме слово "roadmap" або як любить говорити наш солодкий президент "дорожня карта" - це не зовсім вірна метафора.

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

Тому тут і далі ми будемо використовувати слово "roadmapping", щоб підкреслити, що це не артефакт (roadmap, дорожня карта), але якийсь процес (~ ing) прояснення цілей, віх, метрик і інших важливих деталей розвитку продукту.

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

Як би ви гнучко НЕ налагоджували процеси в організації, як би ви не старалися домогтися крос-функціональності команд в Scrum, скільки б часу представники інтересів клієнтів, власник продукту, аналітики і команда розробки не працювали тісно разом - інформація завжди буде кілька фрагментована, а загальна картина або "bigger picture" відома лише по частинах і не всім.

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

1. попросіть кожного учасника воркшопу взяти листок паперу ручку або олівець і намалювати диван

2. коли дивани готові - пройдіть і дайте зворотний зв'язок: диван повинен бути невеликим, червоного кольору, стояти посередині кімнати

3. коли дивани готові, попросіть за диваном намалювати висить на стіні картину в рамі

4. спритні учасники воркшопу почнуть здогадуватися про каверзу і просити деталей картини, розміри, положення; додайте деталей: картина прямокутна, форм-фактор ландшафт, висить зліва

5. попросіть додати волосся - тут все зайдуть в безвихідь!

6. але варто показати всім фото з музею Далі (див нижче) і запевняю вас, все стане на свої місця!

7. тепер попросіть намалювати на стіні другу картину і учасники будуть готові це зробити без прояснення деталей

8. попросіть додати камін-ніс, і це теж не викличе особливих труднощів!

Особа Мей Уест, використане в якості сюрреалістичної кімнати, музей Сальвадора Далі. Вид збоку.

Та ж кімната. Вид через видаляє оптичний апарат.

У чому ж сіль?

Коли зрозуміла загальна картина потрібно набагато менше деталей, щоб коректно виконати роботу. І навпаки, коли не ясна загальна картина, скільки деталей не додавай, очікуваної якості без істотної кількості переробок і фрустрацій не добитися.

Для цього нам в продуктовій розробки час від часу і потрібні сесії побудови "більшої картини". Вони ж product roadmapping.

Опрацювання беклога продукту (в народі "грумінг беклога") - це корисна вправа спільної опрацювання деталей. Досвідчені Скрам-команди навчилися проводити його регулярно. І це непоганий шанс заглянути за завісу поточного спринту, подивитися трохи наперед, розібратися в деталях майбутньої роботи.

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

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

Грумінг не дають цілісної великої картини. Пам'ятайте вправу з фотографією з музею Далі? Коли немає загальної картини, деталей завжди буде мало. Тому грумінг без роудмаппінга не сильно ефективні. Грумінг ж, що проводяться після роудмаппінга, дуже добре підсилюють загальне розуміння - від більшого до меншого, від загального до конкретного.

Грумінг як частина роудмаппінга, друга половина другого дня.

Так як наша задача - скласти puzzle бачення продукту з розкиданих деталей, ми повинні зібрати в одному місці всіх, у кого є фрагменти інформації, а також тих, кому ця інформація буде корисна.

Ми називаємо таку групу "розширеним колом продукту", і в неї входять (в залежності від продукту і компанії) представили таких орг функцій як:

• marketing
• sales
• customer care
• product support
• development teams
• product management
• project management (якщо ця функція виділена в організації)
• top-management і executives

Спеціаліст з продажу розповідає всім присутнім частина болів користувачів.

У разі компанії IPLand і їх продукту effie> така команда склала близько 20 осіб, і ми працювали разом два дні.

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

Робота в групах по складанню портретів користувачів для аналізу їх поточних "болів".

Не зовсім. Вірніше, зовсім немає.

Не дивлячись на те, що в разі масштабної розробки (сотні учасників, десятки команд) ми теж радимо запрошувати всіх членів всіх команд на сесію roadmapping-а, не варто плутати це заходи з тим, що методологія SAFe називає "Program Increment Planning" або " PI-Planning ".

У чому ж відмінність?

Планування инкремента продукту в SAFe (на скільки я це розумію) ставить перед собою за мету складання детального плану розробки на наступні спринти і commitment від команд менеджменту. На нашому досвіді такий процес хоч і безсумнівно має позитивні сторони (все та ж bigger picture, обговорення цілей і прояснення тактики), його зворотною стороною є складання внутрішніх "контрактних зобов'язань" між командами і менеджментом про детальні плани спринтів.

На мій погляд це знижує гнучкість системи і призводить до відомим негативних ефектів Водоспадної розробки - цей процес фіксує як час так і обсяг роботи, а це небезпечно. Так як для того, для того, щоб виконати план, розробникам нічого не залишається, як розкрити свій "секретний скриньку хитрих інструментів" і почати зрізати кути техпроцесу - чистоту коду, написання тестів, і т.д. Від цього страждає якість і мотивація, а як наслідок - все, в тому числі менеджмент, замовники і кінцеві користувачі. Так що PI Planning в чистому вигляді - це не зовсім те, чого ми хочемо. Вірніше, зовсім не те!

Roadmapping - про колективне прояснення цілей і стратегії розвитку продукту. На виході - ясність довгострокової перспективи, на яку потім спринт за спринтом, день за днем, фичей за фичей команди і власник продукту і команда (або команди в разі масшабного скрам ) Будуть нанизувати ефективні тактичні рішення. Ніяких обіцянок тут ніхто нікому не дає. Що ми взагалі можемо один одному обіцяти про майбутнє? Хіба що те, що воно точно буде не таким, як ми його собі сьогодні малюємо! Тому ми малюємо великими мазками.

Складання карти - Product Owner і команда, день другий.

Як ми сказали вище, мета процесу роудмаппінга - зібрати разом розрізнені фрагменти загальної картини. Це включає в себе чотири вектора:

1. розуміння поточного стані продукту (звичайно, крім випадку самого початку розробки, коли продукту ще немає)
2. стратегія і цілі бізнесу
3. знання про ринок і потреби користувачів
4. технічні обмеження і ризики

Вкідиваніе чотирьох інгредієнтів роудмаппінга: розуміння продукту, користувачів, бізнесу і технічних деталей.

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

Звучить банально? Так воно, напевно, і є. Але це не скасовує дивного ефекту, який ми спостерігаємо в результаті роудмаппінгов з клієнтами.

Розробники демонструють усім учасникам роудмаппінга частина поточного продукту (версію для Android tablet).

Учасники

• весь круг продукту

цілі воркшопу

1. зібрати воєдино чотири вектора розвитку продукту: поточний стан продукту, користувачі, бізнес, інжиніринг
2. скласти високоуровненую стратегічну карту розвитку продукту з урахуванням трьох векторів на рівні епіків
3. почати рознесення епіків на тимчасові горизонти (літо, осінь, зима)

Розклад

Обидва дня: 10: 00-19: 00

День перший - збір інформації

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

Демонстрація продукту і його розвитку за останні місяці

10: 00-12: 00

Мета: познайомити всіх з поточним стан продукту, "погорду" досягненнями, почати разом думати про продукт і його подальший розвиток

12: 00-13: 30

Мета: описати поточний бачення продукту з точки зору бізнесу і ринку збуту

Розширений перерву на обід

13: 30-15: 00

Огляд инсайтов від ринку, користувачів, їх специфіки та потреб

15: 00-17: 00

Мета: описати основні типи-персони користувачів і їх потреби, для того щоб цей вектор потрапив в роудмап продукту

Агрегація даних, відкриті питання, буфер часу

17: 00-19: 00

Час для обдумування і опрацювання отриманої інформації.

Швидка візуальна сортування-ранжирування болів користувачів.

В цей день в IPLand ми працювали в основному з командою розробки та її Власником Продукту на підставі отриманої в перший день різнобічної інформації.

Складання карти розвитку продукту

10: 00-12: 00

Робота над побудова візуальної карти.

Первинний грумінг ідей найближчих спринтів

13: 00-16: 00

Міні-тренінг зі складання якісних елементів беклога і багато практики на свіжо-складеному роудмапе.

Lessons learned

17: 00-19: 00

Ми працювали цілий день - саме час зібратися знову великим колом, подивитися на отриманий роудмап і підвести підсумки.

Agile product roadmap

More Alignment: всі учасники процесу розробки продукту - стейкхолдери, представники бізнесу, менеджмент і інженери - отримують загальну картину. Це створює узгодженість на рівні стратегії, довго- та середньострокових цілей і гарантує, що всі будуть йти в одну сторону.

Less Management and Process: наявність узгодженості на рівні стратегії і планів знижує необхідність менеджменту (і зокрема документації). Коли цілі узгоджені і зрозумілі всім, потрібно набагато менше описаних деталей, щоб гарантувати загальне розуміння.

More Self-Organization: зрозумілі цілі (і їх схвалення всіма учасниками процесу) дозволяють командам розробки та їх учасникам приймати щоденні рішення і вільніше експериментувати без очікування "погоджень" зверху.

Better Products: і це, звичайно ж, наша мета! Але вона досяжна лише побічно ... Ми віримо в те, що регулярні (наша рекомендація: раз в квартал) сесії спільного поновлення і постронніх роудмапа продукту дозволяють робити кращі продукти.