Читать книгу Антихрупкость в IT - Александр Васильевич Бындю - Страница 20

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

Why?

Корневым элементом нашей карты будет список бизнес-целей. Например, это может быть увеличение удовлетворённости пользователей в два раза. Важно, что удовлетворённость пользователей – это индекс, то есть конкретная цифра, которую можно взять из CRM, а не мнение/ощущение заказчика. Мы же хотим после поставки фич измерить достижение цели и понять, в том направлении мы идём или нет. Если бы удовлетворённость пользователей была не цифрой, то как бы мы узнали, что достигли цели? Важно, что мы написали именно в два раза, а не просто увеличение. Хорошие цели должны быть SMART[16] (рис. 6).

Рис. 6. Измеримая цель в Impact Map

Во время обсуждения головы кипят, потому что приходится много анализировать и рефлексировать. Первые пара часов работы довольно сложны, но на старте закладывается правильный импульс для составления остальной карты и создаётся атмосфера доверия среди участников. Что я могу посоветовать, исходя из своей практики[17]:

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. Понимание целей даёт возможность создавать более дешёвые и быстрые решения. С помощью карты мы начинаем использовать не только руки разработчиков, но и голову – каждый член команды может принимать обоснованные решения.

16

Метод SMART, https://byndyu.ru/footnote/16

17

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