Антихрупкость в IT

скачать книгу бесплатно


1. Не торопитесь предлагать решения на этом этапе. Выслушайте заказчика, по-настоящему выслушайте. В ходе обсуждения вы успеете всё скорректировать и причесать, а пока запишите то, что есть у него в голове.

2. Самая распространённая проблема заключается в навязывании решений (этап What?) до того, как цели стали понятны. Инженерная мысль летит со скоростью света – заказчик только открыл рот, только начал говорить о своих целях, а мы уже создали в голове БД со всеми таблицами, придумали архитектуру и накидали куски кода. Зачем слушать дальше, если мы и так всё придумали? Будет ошибкой начать перебивать заказчика и предлагать решения. Запомните анекдот на тему: «Дима сказал „Привет“, а Даша мысленно сыграла свадьбу и родила троих детей».

3. Не переубеждайте заказчика на этом этапе. В самом начале вы не знаете его бизнес во всех тонкостях. Заказчики могут вам доверять как профессионалам в IT, и из-за этого быстро соглашаться с вашими предложениями. Вы сами не заметите, как на доске окажутся только те цели, которые вы навязали, а не те, с которыми заказчик жил всё это время.

4. Даже если цель трудноизмерима, то постарайтесь придумать критерий её достижения. Мысленно перенеситесь на финал проекта и подумайте, как вы узнаете, достигнута цель или нет.

5. Процесс выработки целей итерационный, не обязательно выжимать из заказчика все цели на первом круге.

6. Не надо вытягивать искусственные цели. Бывают проекты, которые просто есть, потому что инвесторам хочется поиграть в создателей ПО. С этим нужно смириться и свернуть работу по составлению Impact Mapping.

Who?

На этом этапе мы должны выявить всех, кто поможет оказать влияние на цель, кто поспособствует её достижению или помешает. В нашем примере это будут Отдел маркетинга и Модератор форума. По мнению заказчика, именно они могут изменить удовлетворённость пользователей (рис. 7).

Рис. 7. Акторы в Impact Map, влияющие на цель

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

How?

Теперь нам надо определить с набором действий. Например, модератор форума может попробовать давать ответы на вопросы в течение одной минуты. Как вы думаете, повысит это удовлетворённость пользователей? У нас есть предположение, что повысит, поэтому записываем этот «impact». То же самое делаем для остальных ролей (рис. 8).

Рис. 8. Гипотезы, которые помогут в достижении цели

Несколько рекомендаций:

1. Необязательно, но желательно, чтобы воздействия тоже были измеримыми. Мы написали не просто Отвечать на форуме, а Отвечать на форуме в течение одной минуты.

2. Не записывайте все возможные воздействия каждой роли. Нам нужны только те активности, которые приводят к достижению цели.

What?

Мы дошли до самого несущественного в Impact Mapping. В последнем узле нашей карты находится та самая корзина с покупками, с которой обычно начинается работа над проектом. Разница в том, что теперь мы понимаем ценность каждой фичи, почему эта фича здесь и к чему приведёт её реализация (рис. 9).

Рис. 9. Финальная часть со списком задач

Несколько замечаний и лайфхаков:

1. В конечных узлах карты можно написать User Story или названия модулей/подсистем.

2. Эту часть карты можно подробно не расписывать, можно даже не заполнять, а лишь проговорить её основные моменты. Полный список всех User Story вы успеете создать на User Story Mapping'е.

3. Здесь необязательно описывать IT-задачи. Вместо этого можно написать организационные преобразования и попросту любые необходимые вам действия на пути к цели.

4. Понимание целей даёт возможность создавать более дешёвые и быстрые решения. С помощью карты мы начинаем использовать не только руки разработчиков, но и голову – каждый член команды может принимать обоснованные решения.

Результаты создания Impact Mapping

Вот и готов наш Impact Mapping. Осталось приоритизировать каждую колонку. Не все цели одинаково важны, то же самое можно сказать про остальные узлы карты. Есть разные способы. Так как мы идём по пути простоты и визуализации, я могу рекомендовать ставить звёздочки. Каждому участнику даётся по пять звёзд, и он может ставить их куда считает нужным. Таким образом можно выявить самые приоритетные узлы.

Результат работы нужно повесить у всех на виду. Если команда распределённая, то следует выложить Impact Mapping в общую базу знаний или повесить перед экраном, который видят все участники разработки. Главная цель – обеспечить видимость и достижимость задач, ведь мы опираемся на них при работе над проектом[18 - Когда я рассказывал про Impact Mapping на AgileClub, коллеги заметили, что есть и другие способы понять стратегические цели. Например, можно использовать Lean Canvas, JTBD или собрать требования в проектной документации с описанием целей и заинтересованных сторон. На самом деле Impact Mapping не противоречит другим подходам и может использоваться вместе с ними. Лично мне он больше нравится, потому что:1. Это простая техника, которая способствует общению и взаимодействию, в ней нет бюрократии.2. Заказчикам, которые не разбираются в IT и производстве ПО, такой подход очень просто объяснить, хватает пары минут.3. Визуализация в виде mind map.].

Фильтр входящих задач

Даже когда все согласились с целями проекта и способами их достижения, заказчик может добавить в проект фичу, которая ему очень нравится – pet feature. Мы можем отфильтровать её через цели, показать, что эта фича никаким образом не приведёт нас к достижению целей.

Аналогично мы будем фильтровать идеи по архитектуре и дизайну системы, которые исходят от команды разработки. Ведёт ли переделка архитектуры к более быстрому и дешёвому достижению цели? Если нет, то зачем нам это делать?

Обратите внимание, что мы двигаемся через прилаживание новых требований. Все входящие задачи должны пройти проверку на соответствие целям и должны «зацепиться» за одну из веток Impact Map. Такой подход даёт возможность обсуждать идеи: участники могут попробовать добавить свою задачу, видят проблему или ошибку в формулировке или в месте, куда они хотели её добавить, пробуют переформулировать и раскрывают новые грани своей идеи. Именно это обеспечивает антихрупкость нашей системы, потому что какие бы неожиданные требования или изменения не пришли извне, мы знаем, как их обработать и приладить к текущему видению.

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

Какая колонка идёт последней на вашей Kanban-доске? Могу поспорить, что это Release, Deploy, Done или что-то в этом духе. Последней колонкой на доске должна стать – «Проверка достижения цели». Недостаточно просто залить фичу на сервер, нам нужно проверить, как эта фича повлияла на продвижение к цели.

FAQ по Impact Mapping

Как продать создание Impact Mapping бизнесу перед началом проекта?

Лучше всего идти от проблемы. Попросите заказчика вспомнить случаи, когда было сделано много фич, а бизнес от этого только пострадал. Почему так произошло? Может, надо чётко описать цели?

Должна ли эта работа оплачиваться?

Да, обязательно. Составление Impact Mapping может занять несколько дней и имеет ценность для бизнеса.

Что если заказчик не хочет этого делать?

Вы как профессионал должны предоставить бизнесу прогноз на будущее. Расскажите о возможных проблемах и рисках. После этого дайте клиенту выбрать. Если вы донесли возможное проблемное будущее и клиент принял его, отказался от Impact Mapping'а при полной ясности последствий, то теперь это не ваша проблема; просто делайте ему фичу.

Всегда ли бизнес чётко знает свои цели?

Часто бизнес сам не до конца понимает свои истинные проблемы и цели. В ходе обсуждений представители бизнеса начинают спорить друг с другом: оказывается, что все по-разному себе представляют цели. Это нормально. На этом этапе надо просто дать им выговориться, просто слушать и фасилитировать. В результате у всех проясняются мысли и синхронизируется понимание, что даёт толчок к развитию общих идей.

Impact Mapping является одной из активностей, которые сделают и заказчика, и разработчиков более счастливыми и эффективными. Как вы увидите в следующих главах, визуализация целей, трассировка от задач к целям и возможность постоянно изменять эту карту являются одними из основных инструментов создания антихрупкости вашей системы. С помощью Impact Mapping и подобных практик вы только усилите ваш продукт от происходящих неожиданностей.

Глава 3. Углубление в Impact Map

Разбор нюансов создания Impact Map на примере притчи

Больше восьми лет я использую Impact Map для аналитики IT-продуктов. Я довольно активно делился знаниями об этой практике: писал статьи, выступал на конференциях с докладами и мастер-классами, рассказывал студентам в университетах и интернам в компании. Слушатели и участники мастер-классов легко улавливают, как создавать и использовать Impact Map – с теорией нет проблем. Тем не менее я вижу большие затруднения с применением этого подхода в реальной практике, когда нужно придумать и описать идеи для сложного IT-продукта.

Мы уже познакомились с этой техникой в прошлой главе, а сейчас я расскажу, каким образом формулируются идеи, которые являются самой сложной и самой ценной частью Impact Map. И ещё поделюсь своим ви?дением, как наиболее эффективно воспринимать каждую из частей Impact Map.

Нюансы Impact Mapping

В прошлой главе мы рассмотрели структуру Impact Map (рис. 5). Идея этого подхода в том, чтобы прорисовать связь от задач (Deliverable) к цели (Goal). По задумке, задачи оказывают воздействие (Impact) на какую-то группу (Actor), и это воздействие приводит бизнес к цели. Таким образом, нет бесполезных задач, и чётко видно, что и зачем мы собираемся делать.

В этой, казалось бы, понятной схеме кроется много нюансов, которые вызывают ступор. Я приведу свою интерпретацию каждой части Impact Map и подскажу, что конкретно надо вписывать в каждую из них.

Goal – здесь нужно описать измеримый результат. Ключом к этой части будет ответ на вопрос, который вы зададите себе и заказчику: «По каким критериям мы поймём, что достигли успеха?» Такой вопрос помогает перенестись в будущее и подумать, как мы собираемся оценивать результат. Формулировка выбрана так, чтобы человек начал рефлексировать, и это не то же самое, что спросить «какая у вас цель?». Цели могут быть разные, а вот конечный результат в будущем оценят по каким-то критичным для бизнеса параметрам. Это и есть Goal.

Actor – на кого мы собираемся оказывать воздействие. Обычно сюда предлагают[19 - ScrumTrek. Impact Mapping – инструкция по применению, https://byndyu.ru/footnote/19 (https://byndyu.ru/footnote/19)] писать тех, кто нам может помочь или помешать в достижении цели. Так можно делать, это неплохой совет, но он недостаточно нас фокусирует. Я предлагаю думать о том, чью жизнь мы хотим поменять с помощью воздействия, чтобы это изменение жизни привело нас к цели. Трюк в том, что мы не просто собираемся воздействовать, а надеемся, что сможем изменить поведение людей в нужную сторону. Такой взгляд заставляет точнее очерчивать границы для Actor и приходится тщательно обдумывать Impact.

Impact – воздействие, которое мы собираемся сделать. Это самая сложная часть, которая мало кому даётся. Я сравниваю её с созданием гипотезы в научном методе или рождением идеи в ТРИЗ, то есть техника понятна, но откуда берётся идея, как она рождается в голове, как научить человека эти идеи создавать, решительно неясно. Здесь ключом может стать понимание, что в этой колонке мы описываем ключевые идеи нашего продукта – то, что в итоге принесёт деньги. Если собрать все импакты из итоговой карты, то у нас должно получиться уникальное торговое предложение. Об этой части Impact Map будет вся остальная глава, где я расскажу на примере притчи, как описываются идеи.

Deliverable – это список задач или историй. В этой области все отлично умеют действовать.

Типичные ошибки Impact Mapping

Impact Map обычно не получается по следующим причинам.

Цели неизмеримы или неясны. Это тот случай, когда хочется сделать много чего, но непонятно зачем. Антипаттерном будет закрыть глаза на отсутствие цели и накидать задач в работу, как делали во времена «плоских» ТЗ.

Описаны абстрактные юзеры, но неясно, как наши воздействия поменяют их поведение. Антипаттерном будет указать просто «пользователей», потому что потеряется связь с реальностью, в этих «пользователях» нет жизни и настоящих потребностей. Это приведёт к тому, что мы опишем идеи, но не будем понимать, как они повлияют на мир.

Вместо идей и гипотез (Impact), написаны user story или задачи. Эта самая частая проблема. Ещё раз: это очень (!) частая проблема, которая убивает всю идею Impact Map! В этом случае происходит подмена идей задачами, аналитики по привычке пишут to-do list вместо продуктовых гипотез.

Приведу пример, который поможет вам во всём разобраться.

Impact Mapping гончара

Я взял старую и известную притчу о гончаре. Гончар столкнётся с проблемой, сформулирует цель и попробует придумать идею, как ему достигнуть цели.

Притча о гончаре и мальчишках

Жил на свете старый гончар. Он делал горшки, продавал их на базаре и на это жил. Но вот повадились соседские мальчишки бить его горшки. Он и просил их не делать этого, уговаривал, ругал, жаловался их родителям – ничего не помогало…

У гончара были три основные идеи и две группы людей, на которых он надеялся воздействовать, чтобы достичь своей цели. Изначально его Impact Map мог выглядеть как на рис. 10.

Рис. 10. Первые гипотезы и задачи гончара по достижению своей цели

Обратите внимание, что у каждой идеи есть блок «чтобы», который открывает практическую ценность идеи, показывает её основу.

Как следует из притчи, гончар проверил все три гипотезы и не добился результата. Не всегда гипотезы приводят к цели, это обычное дело, когда мы создаём продукты. Поэтому гончар продолжил поиск идей:

…Тогда он позвал мальчишек к себе во двор и сказал, что за каждый разбитый горшок будет платить им рубль. Мальчишки обрадовались, перебили все горшки, получили деньги и убежали. На следующий день гончар сказал, что денег у него мало, платить он может только 50 коп.

Мальчишки опять перебили все горшки, получили свои деньги и убежали. Следующий день опять повторилось то же самое, только за каждый разбитый горшок гончар заплатил всего 20 коп.

На следующее утро ребятня опять прибежала во двор. Старик вышел к ним и сказал: «Денег, ребятки, у меня почти совсем не осталось, потому что продавать мне было нечего. Теперь за каждый разбитый горшок я могу платить только одну копейку». – «Нашёл дураков бесплатно бить твои горшки!» – возмутились мальчишки. Больше горшков они не били.

Это очень важный момент! Я прошу вас не смотреть дальше, а самостоятельно сформулировать идею, которая помогла гончару достигнуть результата. Обязательно пропишите часть «чтобы». Опишите идею так, чтобы она была целиком и полностью понятна любому, кто её прочитает. Не оставляйте скрытых смыслов. К идее запишите набор задач, которые нужны для её реализации.

Ещё один абзац, пока вы думаете над формулировкой. Предлагаю вам собрать коллег и вместе попробовать сформулировать идею. Попробуйте записать несколько вариантов. Если у вас получится коротко и ясно записать идею, то можете считать, что вы готовы сделать Impact Map IT-продукта почти любой сложности.

Я надеюсь, что к этому моменту вы сформулировали минимум один вариант идеи, которая помогла гончару. На рис. 11 я приведу свой вариант, который кажется мне достаточно хорошим.

Рис. 11. Появление новой гипотезы у гончара

Когда гончар разочаровался в разговорах и угрозах (первые три гипотезы не сработали), ему пришлось искать идею, которая бы на самом деле воздействовала на мальчишек. Он понял, что бить горшки для них – это весело и забавно, поэтому нацелился на основу их мотивации. Он превратил весёлое хобби в работу, а потом перестал за неё платить.

Моя формулировка идеи звучит так: «Превратить хобби мальчишек в работу, а потом перестать за неё платить, чтобы убить их мотивацию». Здесь описано, что хочет сделать гончар и на чем основывается его надежда на достижение результата. Он надеется сильно снизить мотивацию мальчишек бить его горшки. Похоже, что он отличный психолог!

Почему так сложно сформулировать идею?

При создании IT-продукта нам тоже нужно понимать внутреннее устройство мотивации пользователей, чтобы воздействовать на ключевые точки. Нам нужно понимать взаимосвязи внутри нашей системы, во внешних системах и их пересечении. По сути, формулируя идеи или гипотезы, мы работаем как профессиональные инженеры, которые из всего многообразия вариантов действий, умеют выбрать наиболее эффективное решение, основываясь на ограничениях и принципах работы системы.

Из практики я вижу, что формулировка идей даётся очень тяжело. Почему так происходит? Мне на ум приходит аналогия с решением прямых и косвенных задач. Оказывается, дошкольники довольно легко могут решить прямые задачи типа: На ветке было три птицы, прилетело ещё шесть птиц. Сколько стало птиц на ветке? Дети отвечают: девять. Если эту же задачу с этими же цифрами сделать косвенной, то есть проблемно-ориентированной, то дети теряются: С ветки улетело три птицы, осталось шесть птиц. Сколько птиц изначально было на ветке? Во второй задаче нужно как бы задом наперёд взглянуть на ситуацию. У взрослых с описанием идей возникает такая же проблема: они хорошо пишут прямые задачи (Deliverable), но им тяжело даются косвенные/проблемные сценарии (Impact).

Рекомендую тренироваться в описании идей на простых жизненных сценариях и в повседневной жизни. Это очень помогает на реальной сессии Impact Map, когда нужно сформулировать идею достижения цели в сложном IT-продукте.

Глава 4. Пять самых важных составляющих процесса выпуска успешных продуктов

Практический подход к созданию IT-продуктов, которые достигают бизнес-целей

Опыт показывает, что нельзя просто взять и описать большой продукт в ТЗ, а потом реализовать его по описанию. Жизнь всегда оказывается шире, чем наше представление о ней. С другой стороны, эмпирический подход отражает постоянное углубление нашего понимания предметной области, бизнеса заказчика и изменений на рынке по мере создания и совершенствования продукта.

Нам посчастливилось создать успешные продукты, которые приносят прибыль заказчикам. Причём в самых разных областях: медицина, наружная реклама, госзакупки, налоги, логистика.

Я хочу рассказать про процесс создания таких продуктов и показать, что за магия приводит нашего заказчика к успеху. Не претендую на знание о самом совершенном процессе, который решает все проблемы, но конкретно этот подход работает, поэтому делюсь. После описания процесса мы возьмём реальный пример проекта, который прошёл по такому процессу.

Иногда я буду писать «проект», а иногда «продукт». Для себя мы не разделяем два этих понятия. В книге «Бережливое производство программного обеспечения. От идеи до прибыли»[20 - Мэри и Toм Поппендик. Бережливое производство программного обеспечения. От идеи до прибыли, https://byndyu.ru/footnote/20 (https://byndyu.ru/footnote/20)] есть интересная мысль о том, что любой проект можно рассматривать как продукт, поэтому при разработке ПО мы используем подходы по созданию продуктов.

Общий взгляд на процесс

Разработка ПО – это процесс создания знания. В начале работы неопределённость очень высока. Заказчик витает в облаках со своей идеей, разработчики неглубоко знают предметную область.

Мы много экспериментировали с разными методологиями – от жёстких до гибких, от Agile до Lean – и пришли вот к процессу, описанному на рис. 12.

Рис. 12. Схема работы со всеми инструментами и обратной связью

Вся работа должна быть визуализирована: от процесса и целей до мелких пожеланий и требований. Мы исходим из простого принципа: «You cannot improve what you cannot see».

Первое знакомство с проектом всегда начинаем с целей. Спрашиваем: «Как вы поймёте, что достигли успеха?», «Что для вас является успешным продуктом?», «По каким критериям вы оцените его успешность?» и так далее, пока цели не материализуются. Приоритезируем цели и строим пути их достижения.

Следующий шаг понимания будущей системы – Customer Journey Mapping (CJM), но не в классическом варианте, а в том, как его описал мой коллега Андрей Шапиро в статье «Схематизация опыта с CJM и Service Blueprint. Практика гибридной нотации»[21 - Андрей Шапиро. Схематизация опыта с CJM и Service Blueprint. Практика гибридной нотации, https://byndyu.ru/footnote/21 (https://byndyu.ru/footnote/21)]. С помощью схем мы видим все пути входа, выхода, точки соприкосновения с нашей системой, артефакты, барьеры и взаимосвязи.

1. Дальше прорабатываем User Story Mapping (USM). После описания сценариев приоритезируем их и выбираем самые важные для ближайшего релиза. Никогда не пытаемся охватить всё разом: слона надо есть по частям.