скачать книгу бесплатно
Хочу останавливать работу, если баланс стал критично низким,
Чтобы не терять деньги.
Мы остановим работу пользователя и трату денег, когда баланс станет отрицательным. Когда мы озвучиваем предложение пользователям, они не верят, что можно автоматически остановить работу. Для пользователя боль потери денег настолько сильна, что они сами придумали скачивание отчёта, они готовы смотреть в отчёт, искать в нём ответ на вопрос об отрицательном балансе.
В последней версии User Story кнопочное решение убрано. Раскопана корневая проблема. Предложено решение, которое закроет корневую проблему. Появился шанс принести пользу после релиза, а не добавить ещё одну кнопку для скачивания ещё одного отчёта.
Преждевременные решения
Некоторым людям неймётся выпалить решение. Они как будто играют в «Свою Игру» или «Брейнринг». Ждут вопрос и на скорость предлагают решение.
В спешке между проблемой и идеей возникает слепая зона. Цепочка рассуждений и выводов остаётся за кадром (рис. 1).
Рис. 1. Отсутствие связи между целью и решением
Мы не принимаем первое поспешное решение, копаем корень проблемы, определяем действующих лиц. После прокладывания пути из цели через действующих лиц до корня проблемы кнопочное решение теряет былую прочность (рис. 2).
Рис. 2. Прорисовка связи между целью и решением
Увидев корневую проблему или потребность, накидываем много возможных решений (рис. 3).
Рис. 3. Множество решений для одной цели
Обратите внимание, что теперь налицо выбор, но сделать его сложнее. У меня есть предположение, что люди намеренно останавливаются на первом решении, которое кажется подходящим. Ведь если идти дальше, то придётся выбирать, оценивать риски каждого решения, его плюсы и минусы. Работы прибавится. Кроме того, чем шире выбор, тем меньше будет радость от итогового решения.
Глубокое бурение проблемы затратно, никто не стремится в это болото. Но если мы хотим создать полезное решение, то нужно пересилить себя и раскрыть слепую зону.
Истории из жизни
Кейс: Сужение видения
Идёт планирование релиза. Product Owner заканчивает фразу словами: «…можно отправить почтой». Я сразу останавливаю обсуждение, потому что одной фразой произошло сужение проблематики до одного решения. Остановились и раскопали корень потребности. Почему отправлять? Почему почтой? В мире ведь придумано много способов донесения информации до пользователей. В итоге предложили пять способов рассказать клиентам об обновлениях. Совет: не сводите решение к одному варианту.
Кейс: Решения без проблемы
Новый заказчик обсуждает с нами модернизацию IT-продукта. Пока рассказывает о продукте, вспоминает о проблеме – клиенты уходят в минус и перерасходуют ресурсы без оплаты. Сервис берёт деньги по мере выполнения операции, но предсказать расходы заранее нельзя. По мере рассказа заказчика посещает идея: обрубать доступ и оставлять клиента без результата.
Обсуждение прервали, раскопали проблему пользователей. Выяснилось, что пользователи не понимают, сколько денег остаётся в каждый момент времени, поэтому не могут оперативно принимать решения. Мы предложили показывать им расходы и текущий баланс в режиме онлайн. Заказчик удивился и сказал: «А что, так можно?»
Сколько стоят 1000 строк кода?
Представьте сцену в магазине. Вы набрали продуктов в корзину и подошли к кассе. Кассир пробил товары, взвесил фрукты и овощи, назвал стоимость. Отлаженный механизм.
Та же история с созданием IT-продукта. Вы сидите на кассе, приходит бизнес с корзиной фич и решений. Вы оцениваете, взвешиваете, говорите ему стоимость.
Давайте вернёмся в магазин и переиграем ситуацию. Вы подходите к кассе, выкладываете покупки. Продавец вам говорит: «Зря вы взяли помидоры „шеди леди“ для рагу из кролика. Этот сорт слишком сладкий, для рагу не подойдёт. Возьмите сорт „маленький принц“, рагу с ними отменное».
Посмотрим, что изменилось. Почему вы благодарны кассиру и хотите его обнять? Он узнал вашу цель. После этого он предложил решение, которое двигает вас к цели, а не просто молча согласился с предложенным решением. Ценность покупки в этом магазине выросла, удовлетворение выросло, вы захотите приходить в этот магазин снова.
Теперь вернёмся к IT. Для выявления целей, понимания пути достижения целей, формирования выбора из решений я рекомендую Impact Mapping[8 - Impact Mapping, https://byndyu.ru/footnote/8 (https://byndyu.ru/footnote/8)]:
Рис. 4. Разделение проблем и решений
Техника изучается за пару дней. С помощью Impact Mapping мы прокладываем путь от решений до цели, расставляем приоритеты, отсекаем Pet Feature, которые идут со стороны бизнеса и со стороны команды. Единственная сложность – процесс создания Impact Mapping: он требует навыков эффективной коммуникации.
Истории из жизни
Кейс: Требуется больше всплывающих окон
Представьте IT-отдел внутри компании. Руководители отдела маркетинга, финансов и прочих ставят ему задачи. Приходит начальник, который отвечает за точки продаж, и требует добавить всплывающее сообщение раз в 10 минут на рабочем месте. Работников на местах обяжут нажимать «ОК» в модальном окне каждые 10 минут, чтобы понять, на месте работник или нет. Задача как задача; IT-отдел взял да и сделал. Прошло время. Работники на местах ужились с новшеством.
В IT-отдел пришёл начальник маркетинга и попросил добавить всплывающее сообщение, чтобы работник выходил на улицу и раздавал листовки. Сообщение по задумке всплывает каждые 30 минут, в результате должны повыситься продажи. Задача как задача; IT-отдел взял да и сделал.
На местах это вылилось в противоречивый сценарий. Работник видит сообщение о том, что надо идти на улицу и раздавать листовки. Он выходит и раздаёт, а в это время всплывает сообщение: «Ты на месте?»
Почему так произошло? Никто не контролировал целостность системы. Многоголовый Product Owner приносил задачу, разработчики брали задачу, не создав целостной картинки поставки ценности, поэтому они не увидели противоречий.
Кейс: Зачем делаем?
Заказчик пришёл с идеей сделать приложение для курьеров. Заказчик – федеральная компания, сотни филиалов по стране. Цель продукта – оптимизация работы курьеров.
До работы с нами у проекта накопилась полугодовая история. Заказчику сделали ТЗ, реализовали часть мобильного клиента, но не сделали серверную часть. С этой историей заказчик пришёл к нам. Мы начали проект по нашему процессу[9 - Byndyusoft. Анализ IT-продукта, https://byndyu.ru/footnote/9 (https://byndyu.ru/footnote/9)], и уже к концу Customer Journey Mapping заказчика осенило. Они поменяли бизнес-модель, запустили ряд экспериментов в бизнесе и обещали вернуться к нам через три месяца. В итоге вернулись через полгода с перестроенной компанией, которая стала готова для создания нового продукта. Продукт мы сделали и успешно запустили. Мы считаем это успехом, так как не позволили потратить время на что-то бесполезное.
Движение без цели
Если цели IT-отдела или IT-продукта не сформулированы, то это благодатная почва для кнопочных решений. Перефразируя фразу из монолога Жванецкого[10 - Отрывок из выступления Жванецкого, https://byndyu.ru/footnote/10 (https://byndyu.ru/footnote/10)]: Если нет цели, то куда бы ты ни шёл – получается вперёд.
Когда мы берём задачу, то сопоставляем её стоимость с отдачей в достижении цели. А если цели нет? Значит, и соизмерять не с чем. Отсюда рождается стиль работы, при котором задачи реализуются, потому что прикольно эти задачи реализовывать. В таких отделах разработки кипит жизнь, фичи добавляются, идут непрерывные релизы. При этом бурном движении результат не просматривается.
Истории из жизни
Кейс: Покажем, потому что можем
Продукт – SaaS-инструмент для партнёров топовой e-commerce России. Диалог с IT-подразделением заказчика:
– Давайте выведем договоры в интерфейсе, – говорит разработчик со стороны заказчика.
– Чтобы что? – отвечаем мы.
– Они уже лежат в БД, можно легко вывести.
– Как это поможет достигнуть целей продукта?
– Без договоров невозможно заплатить!
– Чтобы заплатить, нужно начать пользоваться продуктом, а для пользователя в этот момент взаимодействия с системой никакого продукта еще нет.
В таких случаях помогает только возврат к целям проекта и фильтрация с помощью Impact Mapping (раздел l, глава 2).
Рефлексия и душевный покой
Чтобы уберечь ваши нервы, делюсь выработанной стратегией борьбы с кнопочным мышлением:
1. Когда к вам пришли с кнопочной идеей, спросите себя, почему они принесли такое решение, почему оно не нравится вам, какие вопросы выявят корень проблемы. Только после этого начинайте говорить.
2. Поймите, что коллеги не со зла лезут с кнопочными идеями. Никто не хочет навредить или саботировать. Все пытаются принести пользу.
3. Управляйте на уровне достижения бизнес-целей, а не задач.
4. Ставьте перед командой проблемы, а не приходите с решениями.
5. Делайте короткие итерации (одна неделя или короче), постоянно собирайте обратную связь от команды и от клиентов.
6. Проводите валидацию идей как можно раньше, убивайте идеи до этапа реализации.
Рекомендации одинаково банальные и действенные. Мне в работе помогает.
Здесь самое важное, что мы фильтруем «хрупкие» идеи, которые со временем разрушат целостность нашей системы. Мы требуем фильтровать входящие задачи вопросом «чтобы что?», а это создаёт в системе запас прочности и позволяет ей оставаться гибкой по отношению к новым изменениям.
Замечайте кнопочное мышление за собой, замечайте за коллегами, рассказывайте бизнесу и учитесь работать с запросами пользователей. Помогайте друг другу в преодолении недуга.
Глава 2. Impact Mapping на практике
Трассировка от задач до целей
Когда читал книгу Impact Mapping[11 - Gojko Adzic. Impact Mapping, https://byndyu.ru/footnote/11 (https://byndyu.ru/footnote/11)] первый раз, было желание бросить её на середине, настолько в ней всё очевидно. Я нашёл в себе силы и дочитал, благо книга короткая и с большими картинками. Как впоследствии оказалось, вся соль была в применении советов на практике. Я не применял. В моей практике заказчик иногда писал бизнес-цели в официальных документах к проекту; иногда мне казалось, что я и так понимаю цели бизнеса – они абсолютно очевидны. К чему уточнять очевидное? Разницу я почувствовал, когда начал применять Impact Mapping в работе.
История появления Impact Mapping
Раньше на старте проекта у нас были технические задания, схемы работы системы и в лучшем случае прототипы интерфейса. В этих документах не хватало понимания динамики развития проекта и приоритетов в работе.
Мы начали писать User Story[12 - User Story, https://byndyu.ru/footnote/12 (https://byndyu.ru/footnote/12)] и делать User Story Mapping. Эти практики добавили понимание логики развития проекта и наших приоритетов, дали возможность плодотворнее общаться с заказчиком. Чего не хватало? Продукты существуют не в вакууме: нужно уметь видеть более глобальные задачи, которые лежат где-то выше историй использования системы. Не хватало простой игровой практики по постановке целей проекта, из которых потом будут появляться User Story Map и список User Story на релиз.
Mijo Balic и Ingrid Ottersten в 2007 году написали статью «Effect Managing IT» (подробнее Agile product management using Effect Maps[13 - Gojko Adzic. Agile product management using Effect Maps, https://byndyu.ru/footnote/13 (https://byndyu.ru/footnote/13)]). Через четыре года Gojko Adzic[14 - Gojko Adzic, https://byndyu.ru/footnote/14 (https://byndyu.ru/footnote/14)] выпустил книгу «Specification by Example»[15 - Gojko Adzic. Specification by Example, https://byndyu.ru/footnote/15 (https://byndyu.ru/footnote/15)], где в главе «Deriving scope from goals» упоминает о технике под названием Effect mapping. Эта техника призвана помогать командам фокусироваться на бизнес-целях, выявлять заинтересованные стороны и их потребности.
Gojko Adzic со временем добавляет в Effect mapping несколько усовершенствований, таких как: приоритизация целей и воздействий, возможность уходить от технических деталей на уровне What, цикличность в предположениях и экспериментах. На мой взгляд, это действительно важные изменения, они помогают в реальной жизни. После этого техника стала называться по-новому – Impact Mapping.
Руки без головы
Представьте, что вы владелец магазина. К вам приходит заказчик. У него в голове уже есть набор фич на покупку, он знает чего хочет. Он берёт корзину для покупок, складывает в неё список технологий, десяток прототипов интерфейса, интеграцию с соцсетями и т. п. Подходит к кассе и просит всё взвесить, реализовать и выставить ему счёт.
Получается, что заказчик пришёл к вам с готовыми решениями каких-то своих проблем. В такой ситуации заказчик купит только руки разработчика, но не голову. Разработчик не сможет критически оценить предложенные решения. Будет ли успешным проект с подходом, где купили только «руки»? Шанс невысок.
Зато в наших силах увеличить шансы на успех за счёт того, что каждый в команде будет понимать и разделять цели бизнеса. Тогда любое решение – от именования переменной в коде до выбора архитектуры – будет приниматься с учётом реальных потребностей бизнеса.
Остаётся вопрос, как вытащить из бизнеса истинные цели, которых мы хотим достичь? Как сделать так, чтобы команда услышала их, приняла и начала с ними работать? Как провести трассировку от любой задачи до бизнес-цели, чтобы была видна логика выбранного решения?
Составляем Impact Map
Impact Map (Карта воздействий) – это mind map по целям проекта с картой влияний, которые должны подтолкнуть бизнес к достижению целей (рис. 5).
Рис. 5. Схема Impact Map
Why?
Центральный элемент нашей карты, который отвечает на ключевой вопрос: зачем мы это делаем? Это цель, которую бизнес пытается достичь.
Who?
На первом уровне мы отвечаем на вопросы: Кто может помочь достичь желаемого результата? Кто может помешать? Кто пользователи нашего продукта? Сюда войдут все заинтересованные стороны, способные повлиять на цели бизнеса.
How?
На втором уровне нужно описать действия заинтересованных сторон для достижения целей. Мы ищем ответ на вопросы: Как они помогут бизнесу достичь целей? Как они могут помешать успеху продукта?
What?
После ответа на основные вопросы можно обсудить конкретные задачи. Третий уровень отвечает на вопросы: Что мы можем сделать как организация или команда разработки, чтобы стимулировать действия? Здесь будет описано что-то вроде технического задания.
Организация процесса
Приглашайте не больше 10–15 человек на это мероприятие, иначе будет сложно проводить. Оптимально позвать по три-четыре человека со стороны бизнеса и со стороны команды продукта.
Со стороны бизнеса обязательно присутствие тех, кто принимает решения, а не только технических специалистов со сложившимся мнением насчёт конкретных реализаций поставленных целей.
Подготовьте карту и доску (или стену) заранее. Impact Mapping для решения задачи с объемом работы в полгода месяцев умещается на доске стандартного размера.
Составление карты займёт от одного часа до двух дней. Сроки сильно зависят от состава участников и ваших навыков проведения.
Каждый блок карты можно рисовать маркером или делать стикерами. Я предпочитаю стикеры, они более мобильны, а это важно, потому что Impact Map будет часто меняться по ходу погружения в продукт.
Перед началом обязательно проговорите правила и цели составления карты. Если есть время, то разошлите всем материал по теме.
Если есть возможность и обстоятельства позволяют, то сделайте несколько упражнений на знакомство друг с другом, потому что техника подразумевает открытое общение.
И самое главное – процесс должен проходить легко и весело. Не добавляйте в него бюрократии!
Пример из практики
Разберём пример, очень приближенный к реальному проекту, для которого мы сделали Impact Mapping. Остановимся на ключевых моментах при составлении Impact Mapping и фатальных ошибках.
Why?
Корневым элементом нашей карты будет список бизнес-целей. Например, это может быть увеличение удовлетворённости пользователей в два раза. Важно, что удовлетворённость пользователей – это индекс, то есть конкретная цифра, которую можно взять из CRM, а не мнение/ощущение заказчика. Мы же хотим после поставки фич измерить достижение цели и понять, в том направлении мы идём или нет. Если бы удовлетворённость пользователей была не цифрой, то как бы мы узнали, что достигли цели? Важно, что мы написали именно в два раза, а не просто увеличение. Хорошие цели должны быть SMART[16 - Метод SMART, https://byndyu.ru/footnote/16 (https://byndyu.ru/footnote/16)] (рис. 6).
Рис. 6. Измеримая цель в Impact Map
Во время обсуждения головы кипят, потому что приходится много анализировать и рефлексировать. Первые пара часов работы довольно сложны, но на старте закладывается правильный импульс для составления остальной карты и создаётся атмосфера доверия среди участников. Что я могу посоветовать, исходя из своей практики[17 - На HappyDev 2014 я проводил мастер-класс по составлению Impact Mapping и Story Mapping. Играть роль заказчика согласился руководитель проекта по обработке заявок на строительство. Все, кто пришёл на тренинг, были очень активны и сразу втянулись в процесс. Со временем мы осознали, что довольно сложно просто слушать заказчика и понять его проблему. Коллеги наперебой предлагали свои решения. В какой-то момент приходилось прерывать работу группы, напоминать, что мы должны больше слушать. Несколько раз из-за напряжённой атмосферы и давления участников заказчик принимал наши решения, отказываясь от своих. Я думаю, что все участники почувствовали важный баланс между тем, когда надо слушать заказчика, а когда надо предлагать решения.]:
