Коли читав книгу 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?
Після відповіді на основні питання можна обговорити конкретні завдання. Третій рівень відповідає на питання: Що ми можемо зробити як організація або команда розробки, щоб створити необхідні впливи? Тут буде описаний кінцевий результат нашої роботи.
Організація процесу
- Запрошуйте не більше 10-15 осіб на цей захід, інакше буде складно проводити. Оптимально покликати 3-4 людини з боку замовника і стільки ж з боку команди.
- З боку замовника обов'язково взяти представників бізнесу, а не тільки технічних фахівців, у яких вже склалася думка з приводу конкретних реалізацій всіх цілей.
- Карту будете будувати на дошці або стіні, підготуйте їх заздалегідь. Impact Mapping для завдання тривалістю в 6-8 місяців вміщується на дошці стандартного розміру.
Онлайн варіант цієї техніки я ще не пробував, але думаю підійде будь-який інтерактивний інструмент. Комунікація буде не та, але вас може врятувати, якщо ви особисто знаєте замовника або є відмінним фасилітатором/модератором.
- Складання карти займе від однієї години до двох днів. Ця цифра сильно залежить від складу учасників і ваших навичок проведення.
- Кожен блок карти можна малювати маркером або робити стікерами. Я вважаю за краще стікери, тому що вони більш мобільні, а impact map буде часто сортуватися і змінюватися по ходу занурення в проект.
- Перед початком обов'язково проговоріть правила і цілі складання карти. Якщо є час, розішліть всім матеріал по темі для підготовки
- Якщо є можливість і обставини дозволяють, то зробіть кілька Icebreaker'ів.
- І найголовніше - сам процес повинен проходити легко і весело. Не додавайте в нього бюрократії!
Приклад практики
Розберемо приклад, дуже наближений реальному проекту, для якого на початку ми зробили Impact Mapping. Зупинимося на ключових моментах при складанні Impact Mapping і на помилках, які можу погубити всю ідею.
Why?
Кореневим елементом нашої карти буде список бізнес-цілей. Наприклад, це може бути збільшення задоволеності користувачів в 2 рази. Важливо, що задоволеність користувачів - це індекс, тобто конкретна цифра, яку можна взяти з CRM, а не думка/відчуття замовника. Ми ж хочемо після поставки фіч виміряти досягнення мети і зрозуміти, в тому напрямку ми йдемо чи ні. Якби задоволеність користувачів була не цифрою, то як би ми дізналися, що досягли мети? Ще важливо, що ми написали саме в 2 рази, а не просто збільшення. Хороші цілі повинні бути SMART:
Перший етап досить складний, він повинен дати імпульс для складання решти карти і створити довіру між учасниками. Що я можу порадити, виходячи зі своєї практики:
- Не поспішайте пропонувати рішення на цьому етапі. Вислухайте замовника, по-справжньому вислухайте. Під час подальшого обговорення ви встигнете все відкоригувати і причесати, а поки запишіть те, що є у нього в голові.
- Найпоширеніша проблема полягає в нав'язуванні рішень (етап What?) до того, як цілі стали зрозумілі. Інженерна думка летить зі швидкість світла - замовник тільки відкрив рот, тільки почав говорити про свої цілі, а ми вже створили в голові БД з усіма таблицями, придумали архітектуру і накидали шматки коду. Навіщо слухати далі, якщо ми і так все придумали? Буде помилкою почати перебивати замовника і пропонувати рішення. Запам'ятайте анекдот на цю тему і постарайтеся уникнути проблеми: «Діма сказав» Привіт «, а Даша подумки зіграла весілля і народила трьох дітей».
- Не переконуйте заказчизка на цьому етапі. На самому початку ви не знаєте його бізнес у всіх тонкощах. Замовники можуть вам довіряти, як професіоналам в IT, і через це швидко погоджуватися на ваші коригування. Ви самі не помітите як на дошці опиняться тільки ті цілі, які ви нав'язали, а не ті, з якими замовник жив весь цей час.
- Навіть якщо мета важковимірна, то постарайтеся придумати критерій її досягнення. Подумки перенесіться на фінал проекту і подумайте, як ви дізнаєтеся досягнута мета чи ні?
- Процес вироблення цілей ітераційний, не обов'язково витискати з замовника всі цілі на першому колі.
- Не треба витягати штучні цілі. Бувають проекти, які просто є, тому що інвесторам хочеться пограти в творців ПЗ. З цим потрібно змиритися і згорнути роботу по складанню Impact Mapping.
На HappyDev 2014 я проводив майстер-клас зі складання Impact Mapping і Story Mapping. Грати роль замовника погодився керівник проекту з обробки заявок на будівництво. Всі, хто прийшов на тренінг, були дуже активними і відразу втягнулися в процес. З часом ми усвідомили, що досить складно просто слухати замовника і зрозуміти його проблему. Колеги навперебій пропонували свої рішення. У якийсь момент доводилося переривати роботу групи, нагадувати, що ми повинні більше слухати. Кілька разів через напружену атмосферу і тиск учасників, замовник приймав наші рішення, відмовляючись від своїх. Я думаю, що всі учасники відчули важливий баланс між тим, коли треба слухати замовника, а коли треба пропонувати рішення.
Who?
На цьому етапі ми повинні виявити всіх, хто допоможе вплинути на мету, хто посприяє її досягненню або завадить. У нашому прикладі це будуть Відділ маркетингу і Модератор форуму. На думку замовника саме вони можуть змінити задоволеність користувачів:
Тут ми можемо вказувати конкретних людей, назви відділів, сегменти ринку тощо. Вибирайте будь-який рівень абстракції, аби він був адекватний вашому проекту.
How?
Тепер нам треба визначити ті впливи, які будуть зроблені для досягнення мети. Наприклад, модератор форуму може спробувати давати відповіді на питання протягом 1 хвилини. Як ви думаєте, підвищить це задоволеність користувачів? У нас є припущення, що підвищить, тому записуємо цей «impact». Теж саме робимо для інших ролей:
Кілька рекомендацій:
- Не обов "язково, але бажано, щоб дії теж були вимірюваними. Ми написали не просто Відповідати на форумі, а Відповідати на форумі протягом 1 хвилини.
- Не записуйте всі можливі дії кожної ролі. Нам потрібні тільки ті активності, які призводять до досягнення мети.
What?
Ми дійшли до найбільш несуттєвого в Impact Mapping. В останньому вузлі нашої карти знаходиться той самий кошик з покупками, з якого зазвичай починається робота над проектом. Різниця в тому, що тепер ми розуміємо цінність кожної фічі, чому ця фіча тут і до чого призведе її реалізація:
Кілька зауважень і рекомендацій:
- У кінцевих вузлах карти можна написати User Story або назви додатків/підсистем.
- Цю частину карти можна підбробно не розписувати, можна навіть взагалі не заповнювати, а тільки проговорити її основні моменти. Повний список всіх User Story ви встигнете створити на Story Mappging'e.
- Тут не обов'язково описувати IT-завдання. Замість цього можна написати якісь організаційні перетворення і взагалі будь-які дії для реалізації впливу на мету.
- Розуміння цілей дає нам можливість створювати більш дешеві і швидкі рішення щодо досягнення цих цілей. За рахунок карти ми починаємо використовувати не тільки руки розробників, але і голову - кожен член команди може приймати обґрунтовані рішення.
Результати створення 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'a при повній ясності наслідків, то тепер це не ваша проблема, просто робіть йому фіч.
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-команді перестати робити те, що вимагають, і почати робити те, що потрібно?, Дмитро Петрашев