Impact Mapping на практиці

Коли перший раз читав книгу Impact Mapping, у мене було бажання кинути її на середині. Все, що там написано, надто очевидне. Я знайшов у собі сили і дочитав, благо книга коротка і з великими картинками. Як згодом з'ясувалося, вся сіль була в тому, що всі ці очевидні та прості практики з книги я не застосовував у своїй роботі.

Іноді замовники писали свою мету в офіційних документах до проекту. Іноді мені здавалося, що я й так розумію цілі замовника – вони є абсолютно очевидними. Навіщо уточнювати очевидне? Різницю я відчув, коли почав застосовувати Impact Mapping у роботі.

Історія появи Impact Mapping

Раніше на старті проекту у нас були технічні завдання, схеми роботи системи та, у хорошому варіанті, прототипи інтерфейсу. У цих документах не вистачало розуміння динаміки розвитку проекту та пріоритетів у роботі.

Ми почали писати User Story та робити Story Mapping. Ці практики додали розуміння того, як проект розвиватиметься, які зараз пріоритети, дали нам можливість продуктивніше спілкуватися із замовником. Чого не вистачало? Продукти існують не у вакуумі, потрібно бачити більш глобальні завдання, які лежать десь вище від історій використання системи. Не вистачало простої ігрової практики щодо постановки цілей проекту, з яких потім з'являтимуться Story Mapping і список User Story.

Mijo Balic та Ingrid Ottersten у 2007 році написали статтю Effect Managing IT (докладніше Agile product management using Effect Maps). Через 4 роки у 2011 році Gojko Adzic випустив книгу Specification by Example, де у розділі «Deriving scope from goals» згадує про техніку під назвою Effect mapping. Ця техніка покликана допомагати командам фокусуватися на бізнес-цілях, виявляти зацікавлені сторони та їх потреби.

Gojko Adzic згодом додає в Effect mapping кілька вдосконалень, таких як: пріоритизація цілей та впливів, можливість уникати технічних деталей на рівні What, циклічність у припущеннях та експериментах тощо. Особисто мені здається, що це важливі зміни, вони додають корисності у реальному житті. Після цього техніка стала називатися по-новому Impact Mapping.

Скільки коштує кілограм коду?

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

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

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

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

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

Складаємо Impact Mapping

Impact Mapping — це mind map з метою проекту з картою впливів, які мають підштовхнути бізнес замовника до досягнення цілей.

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

Who?На першому рівні ми відповідаємо на запитання:Хто може допомогти досягти бажаного результату? Хто може завадити? Хто користувачі нашого продукту? Сюди увійдуть всі зацікавлені сторони, які можуть вплинути на цілі бізнесу.

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

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

Організація процесу

1. Запрошуйте не більше 10-15 осіб на цей захід, інакше буде важко проводити. Оптимально покликати 3-4 особи з боку замовника та стільки ж з боку команди.
2. З боку замовника обов'язково взяти представників бізнесу, а не лише технічних фахівців, у яких уже склалася думка щодо конкретних реалізацій усіх цілей.
3. Карту будуватимете на дошці або стіні, підготуйте їх заздалегідь. Impact Mapping для завдання тривалістю 6-8 місяців уміщається на дошці стандартного розміру. Онлайн варіант цієї техніки я ще не пробував, аледумаю підійде будь-який інтерактивний інструмент. Комунікація буде не та, але вас може врятувати, якщо ви особисто знаєте замовника або є чудовим фасилітатором/модератором.
4. Складання картки займе від однієї години до двох днів. Ця цифра сильно залежить від складу учасників та ваших навичок проведення.
5. Кожен блок картки можна малювати маркером або робити наклейками. Я віддаю перевагу стікерам, тому що вони більш мобільні, а impact map буде часто сортуватися і змінюватися в процесі занурення в проект.
6. Перед початком обов'язково проговоріть правила та цілі складання картки. Якщо є час, то розішліть усім матеріал на тему для підготовки
7. Якщо є можливість та обставини дозволяють, то зробіть кілька Icebreaker'ів.
8. І найголовніше — сам процес має відбуватися легко та весело. Не додавайте до нього бюрократії!

Приклад із практики

Розберемо приклад, дуже наближений до реального проекту, для якого на початку ми зробили Impact Mapping. Зупинимося на ключових моментах при складанні Impact Mapping та на помилках, які можу занапастити всю ідею.

Кореневим елементом нашої картки буде список бізнес-цілей. Наприклад, це може бутизбільшення задоволеності користувачів у 2 рази. Важливо, щозадоволеність користувачівце індекс, тобто. конкретна цифра, яку можна взяти із CRM, а не думка/відчуття замовника. Ми ж хочемо після поставки фічвимірятидосягнення мети і зрозуміти, у тому напрямку ми йдемо чи ні. Якбизадоволеність користувачівбула не цифрою, то як би ми дізналися, що досягли мети? Ще важливо, що ми написали самеу 2 рази, а не простозбільшення. Хороші цілі мають бути SMART:

На HappyDev 2014 япроводив майстер-клас зі складання Impact Mapping та Story Mapping. Грати роль замовника погодився керівник проекту з обробки заявок на будівництво. Усі, хто прийшов на тренінг, були дуже активними та одразу втягнулися у процес. Згодом ми усвідомили, що досить складно просто слухати замовника та зрозуміти його проблему. Колеги навперебій пропонували свої рішення. Якоїсь миті доводилося переривати роботу групи, нагадувати, що ми маємо більше слухати. Кілька разів через напружену атмосферу та тиск учасників, замовник приймав наші рішення, відкликаючись від своїх. Я думаю, що всі учасники відчули важливий баланс тим часом, коли треба слухати замовника, а коли треба пропонувати рішення.

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

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

Тепер нам треба визначити ті дії, які будуть зроблені для досягнення мети. Наприклад, модератор форуму може спробувати відповідати на запитання протягом 1 хвилини. Як ви вважаєте, підвищить це задоволення користувачів? Ми маємоприпущення, що підвищить, тому записуємо цей «impact». Теж саме робимо для інших ролей:

Декілька рекомендацій:

1. Необов'язково, але бажано, щоб дії теж були вимірними. Ми написали не простоВідповідати на форумі, аВідповідати на форумі протягом 1 хвилини.
2. Незаписуйте всі можливі дії кожної ролі. Нам потрібні ті активності, які призводять до досягнення мети.

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

Декілька зауважень та рекомендацій:

1. У кінцевих вузлах картки можна написати User Story або назви модулів/підсистем.
2. Цю частину карти можна детально не розписувати, навіть взагалі не заповнювати, лише проговорити її основні моменти. Повний список всіх User Story ви встигнете створити на Story Mappging'і.
3. Тут не обов'язково описувати IT-завдання. Натомість можна написати якісь організаційні перетворення і взагалі будь-які дії для реалізації впливу на ціль.
4. Розуміння цілей дає нам можливість створювати більш дешеві та швидкі рішення щодо досягнення цих цілей. За рахунок картки ми починаємо використовувати не тільки руки розробників, а й голову – кожен член команди може приймати обґрунтовані рішення.

Результати створення Impact Mapping

Ось готовий наш Impact Mapping. Залишилося пріоритизувати кожну колонку. Не всі цілі однаково важливі, теж можна сказати про інші вузли карти. Існують різні способи пріоритизувати. Т.к. ми йдемо шляхом простоти і візуалізації, то я можу рекомендувати ставити зірочки. Кожному учаснику даєте по 5 зірок і може ставити їх куди хоче. Таким чином, можна виявити найпріоритетніші вузли.

Результат роботи потрібно повісити у всіх на очах. Якщо команда розподілена, треба викласти Impact Mapping взагальну базу знань чи повісити перед екраном, який бачать усі учасники розробки. Головна мета — забезпечити видимість та досяжність цієї інформації, адже ми спираємось на неї під час роботи над проектом.

Коли я розповідав про Impact Mapping на AgileClub, колеги помітили, що є інші способи зрозуміти стратегічні цілі. Наприклад, можна використовувати Lean Canvas або зібрати вимоги до проектної документації з описом цілей та зацікавлених сторін. Насправді Impact Mapping не суперечить іншим підходам і може використовувати разом з ними. Особисто мені він більше подобається, бо:

• Це проста техніка, яка сприяє спілкуванню та взаємодії, у ній немає бюрократії.
• Замовникам, які не розуміються на IT та виробництві ПЗ, такий підхід дуже просто пояснити, вистачає кілька хвилин.
• Візуалізація у вигляді mind map

Фільтр вхідних завдань

Навіть коли всі погодилися з цілями проекту та способами їх досягнення, замовник може додати до проекту фічу, яка йому дуже подобається – pet feature. Ми можемо відфільтрувати її через цілі, показати що ця фіча аж ніяк не приведе нас до досягнення цілей.

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

Модернізація Kanban-дошки

Яка колонка йде останньою на вашій Kanban-дошці? Можу посперечатися, що це Release, Deploy, Done або щось таке. Останньою колонкою на дошці має стати перевірка досягнення мети. Недостатньо просто залити фічу на сервер, нам потрібно перевірити чи досягли ми мети, як припускали чи ні.

• Як продати створення Impact Mapping замовнику перед початком проекту?Найкраще йти від проблеми. Попросіть замовника згадати випадки, коли було зроблено багато фіч, а бізнес від цього лише постраждав. Чому так сталося? Може, треба явно описати цілі?
• Чи має ця робота оплачуватись?Так, обов'язково. Упорядкування Impact Mapping може зайняти кілька днів і несе цінність бізнесу, не рекомендую робити це безкоштовно.
• Що якщо замовник не хоче цього робити?Ви, як професіонал, маєте надати замовнику прогноз на майбутнє. Розкажіть про можливі проблеми, опишіть ризики та їхню небезпеку. Після цього дайте клієнту вибрати. Якщо ви донесли можливе проблемне майбутнє і клієнт прийняв його, відмовився від Impact Mapping'а за повної ясності наслідків, то тепер це не ваша проблема, просто робіть йому фіч.

Impact Mapping є однією з активностей, які зроблять і замовників та розробників більш щасливими та ефективними. Ставте правильні цілі правильно!

---