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 і на помилках, які можу погубити всю ідею.

Why?


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



Перший етап досить складний, він повинен дати імпульс для складання решті карти і створити довіру між учасниками. Що я можу порадити, виходячи зі своєї практики:
  1. Не поспішайте пропонувати рішення на цьому етапі. Вислухайте замовника, по-справжньому вислухайте. У ході подальшого обговорення ви встигнете все відкоригувати і причесати, а поки запишіть те, що є у нього в голові.
  2. найпоширеніша проблема полягає в нав'язуванні рішень (етап What?) до того, як цілі стали зрозумілі. Інженерна думка летить зі швидкістю світла — замовник тільки відкрив рот, тільки почав говорити про свої цілі, а ми вже створили в голові БД з усіма таблицями, придумали архітектуру і накидали шматки коду. Навіщо слухати далі, якщо ми і так все придумали? Буде помилкою почати перебивати замовника і пропонувати рішення. Запам'ятайте анекдот на цю тему і постарайтеся уникнути проблеми: «Діма сказав «Привіт», а Даша подумки зіграла весілля і народила трьох дітей».
  3. Не переубеждайте заказчизка на цьому етапі. На самому початку ви не знаєте його бізнес у всіх тонкощах. Замовники можуть вам довіряти, як професіоналам в IT, і з-за цього швидко погоджуватися на ваші коригування. Ви самі не помітите, як на дошці виявляться лише ті цілі, які ви нав'язали, а не ті, з якими замовник жив весь цей час.
  4. Навіть якщо мета трудноизмерима, то постарайтеся придумати критерій її досягнення. Подумки перенесіться на фінал проекту і подумайте, як ви дізнаєтеся досягнута мета чи ні?
  5. ітераційний Процес вироблення цілей, не обов'язково выжамать з замовника всі цілі на першому колі.
  6. Не треба витягати штучні мети. Бувають проекти, які просто є, тому що інвесторам хочеться пограти у творців. З цим потрібно змиритися і згорнути роботу по складанню Impact Mapping.


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


Who?


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



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

How?


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



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


What?


Ми дійшли до самого несуттєвого в 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 або щось в цьому дусі. Останньою колонкою на дошці повинна стати — перевірка досягнення мети. Недостатньо просто залити фічу на сервер, нам потрібно перевірити, чи досягли ми мети, як припускали чи ні.

FAQ

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


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




Посилання:

How to get the most out of impact mapping, Gojko Adzic

How I Learned to Stop Worrying and Love Flexible Scope, Gojko Adzic

Impact Mapping — як dev-команді перестати робити те, що вимагають, і почати робити те, що потрібно?, Дмитро Петрашев

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.