Антихрупкость в IT
- -
- 100%
- +
…Тогда он позвал мальчишек к себе во двор и сказал, что за каждый разбитый горшок будет платить им рубль. Мальчишки обрадовались, перебили все горшки, получили деньги и убежали. На следующий день гончар сказал, что денег у него мало, платить он может только 50 коп.
Мальчишки опять перебили все горшки, получили свои деньги и убежали. Следующий день опять повторилось то же самое, только за каждый разбитый горшок гончар заплатил всего 20 коп.
На следующее утро ребятня опять прибежала во двор. Старик вышел к ним и сказал: «Денег, ребятки, у меня почти совсем не осталось, потому что продавать мне было нечего. Теперь за каждый разбитый горшок я могу платить только одну копейку». – «Нашёл дураков бесплатно бить твои горшки!» – возмутились мальчишки. Больше горшков они не били.
Это очень важный момент! Я прошу вас не смотреть дальше, а самостоятельно сформулировать идею, которая помогла гончару достигнуть результата. Обязательно пропишите часть «чтобы». Опишите идею так, чтобы она была целиком и полностью понятна любому, кто её прочитает. Не оставляйте скрытых смыслов. К идее запишите набор задач, которые нужны для её реализации.
Ещё один абзац, пока вы думаете над формулировкой. Предлагаю вам собрать коллег и вместе попробовать сформулировать идею. Попробуйте записать несколько вариантов. Если у вас получится коротко и ясно записать идею, то можете считать, что вы готовы сделать Impact Map IT-продукта почти любой сложности.
Я надеюсь, что к этому моменту вы сформулировали минимум один вариант идеи, которая помогла гончару. На рис. 11 я приведу свой вариант, который кажется мне достаточно хорошим.
Рис. 11. Появление новой гипотезы у гончара
Когда гончар разочаровался в разговорах и угрозах (первые три гипотезы не сработали), ему пришлось искать идею, которая бы на самом деле воздействовала на мальчишек. Он понял, что бить горшки для них – это весело и забавно, поэтому нацелился на основу их мотивации. Он превратил весёлое хобби в работу, а потом перестал за неё платить.
Моя формулировка идеи звучит так: «Превратить хобби мальчишек в работу, а потом перестать за неё платить, чтобы убить их мотивацию». Здесь описано, что хочет сделать гончар и на чем основывается его надежда на достижение результата. Он надеется сильно снизить мотивацию мальчишек бить его горшки. Похоже, что он отличный психолог!
Почему так сложно сформулировать идею?
При создании IT-продукта нам тоже нужно понимать внутреннее устройство мотивации пользователей, чтобы воздействовать на ключевые точки. Нам нужно понимать взаимосвязи внутри нашей системы, во внешних системах и их пересечении. По сути, формулируя идеи или гипотезы, мы работаем как профессиональные инженеры, которые из всего многообразия вариантов действий, умеют выбрать наиболее эффективное решение, основываясь на ограничениях и принципах работы системы.
Из практики я вижу, что формулировка идей даётся очень тяжело. Почему так происходит? Мне на ум приходит аналогия с решением прямых и косвенных задач. Оказывается, дошкольники довольно легко могут решить прямые задачи типа: На ветке было три птицы, прилетело ещё шесть птиц. Сколько стало птиц на ветке? Дети отвечают: девять. Если эту же задачу с этими же цифрами сделать косвенной, то есть проблемно-ориентированной, то дети теряются: С ветки улетело три птицы, осталось шесть птиц. Сколько птиц изначально было на ветке? Во второй задаче нужно как бы задом наперёд взглянуть на ситуацию. У взрослых с описанием идей возникает такая же проблема: они хорошо пишут прямые задачи (Deliverable), но им тяжело даются косвенные/проблемные сценарии (Impact).
Рекомендую тренироваться в описании идей на простых жизненных сценариях и в повседневной жизни. Это очень помогает на реальной сессии Impact Map, когда нужно сформулировать идею достижения цели в сложном IT-продукте.
Глава 4. Пять самых важных составляющих процесса выпуска успешных продуктов
Практический подход к созданию IT-продуктов, которые достигают бизнес-целей
Опыт показывает, что нельзя просто взять и описать большой продукт в ТЗ, а потом реализовать его по описанию. Жизнь всегда оказывается шире, чем наше представление о ней. С другой стороны, эмпирический подход отражает постоянное углубление нашего понимания предметной области, бизнеса заказчика и изменений на рынке по мере создания и совершенствования продукта.
Нам посчастливилось создать успешные продукты, которые приносят прибыль заказчикам. Причём в самых разных областях: медицина, наружная реклама, госзакупки, налоги, логистика.
Я хочу рассказать про процесс создания таких продуктов и показать, что за магия приводит нашего заказчика к успеху. Не претендую на знание о самом совершенном процессе, который решает все проблемы, но конкретно этот подход работает, поэтому делюсь. После описания процесса мы возьмём реальный пример проекта, который прошёл по такому процессу.
Иногда я буду писать «проект», а иногда «продукт». Для себя мы не разделяем два этих понятия. В книге «Бережливое производство программного обеспечения. От идеи до прибыли»[20] есть интересная мысль о том, что любой проект можно рассматривать как продукт, поэтому при разработке ПО мы используем подходы по созданию продуктов.
Общий взгляд на процесс
Разработка ПО – это процесс создания знания. В начале работы неопределённость очень высока. Заказчик витает в облаках со своей идеей, разработчики неглубоко знают предметную область.
Мы много экспериментировали с разными методологиями – от жёстких до гибких, от Agile до Lean – и пришли вот к процессу, описанному на рис. 12.
Рис. 12. Схема работы со всеми инструментами и обратной связью
Вся работа должна быть визуализирована: от процесса и целей до мелких пожеланий и требований. Мы исходим из простого принципа: «You cannot improve what you cannot see».
Первое знакомство с проектом всегда начинаем с целей. Спрашиваем: «Как вы поймёте, что достигли успеха?», «Что для вас является успешным продуктом?», «По каким критериям вы оцените его успешность?» и так далее, пока цели не материализуются. Приоритезируем цели и строим пути их достижения.
Следующий шаг понимания будущей системы – Customer Journey Mapping (CJM), но не в классическом варианте, а в том, как его описал мой коллега Андрей Шапиро в статье «Схематизация опыта с CJM и Service Blueprint. Практика гибридной нотации»[21]
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
Примечания
1
Александр Бындю. Проблем быть не должно, https://byndyu.ru/footnote/1
2
Cynefin framework, https://byndyu.ru/footnote/2
3
Situational leadership theory, https://byndyu.ru/footnote/3
4
Андрей Шапиро. Руководство по сбору требований в формате User Story Mapping, https://byndyu.ru/footnote/4
5
Product Owner по сути – это предприниматель внутри компании. Он ещё не вырос до создания своей компании либо не хочет рисковать созданием собственного бизнеса, при этом он уже мыслит и действует как предприниматель.
6
Five whys, https://byndyu.ru/footnote/6
7
Gojko Adzic. Fifty Quick Ideas To Improve Your User Stories, https://byndyu.ru/footnote/7
8
Impact Mapping, https://byndyu.ru/footnote/8
9
Byndyusoft. Анализ IT-продукта, https://byndyu.ru/footnote/9
10
Отрывок из выступления Жванецкого, https://byndyu.ru/footnote/10
11
Gojko Adzic. Impact Mapping, https://byndyu.ru/footnote/11
12
User Story, https://byndyu.ru/footnote/12
13
Gojko Adzic. Agile product management using Effect Maps, https://byndyu.ru/footnote/13
14
Gojko Adzic, https://byndyu.ru/footnote/14
15
Gojko Adzic. Specification by Example, https://byndyu.ru/footnote/15
16
Метод SMART, https://byndyu.ru/footnote/16
17
На HappyDev 2014 я проводил мастер-класс по составлению Impact Mapping и Story Mapping. Играть роль заказчика согласился руководитель проекта по обработке заявок на строительство. Все, кто пришёл на тренинг, были очень активны и сразу втянулись в процесс. Со временем мы осознали, что довольно сложно просто слушать заказчика и понять его проблему. Коллеги наперебой предлагали свои решения. В какой-то момент приходилось прерывать работу группы, напоминать, что мы должны больше слушать. Несколько раз из-за напряжённой атмосферы и давления участников заказчик принимал наши решения, отказываясь от своих. Я думаю, что все участники почувствовали важный баланс между тем, когда надо слушать заказчика, а когда надо предлагать решения.
18
Когда я рассказывал про Impact Mapping на AgileClub, коллеги заметили, что есть и другие способы понять стратегические цели. Например, можно использовать Lean Canvas, JTBD или собрать требования в проектной документации с описанием целей и заинтересованных сторон. На самом деле Impact Mapping не противоречит другим подходам и может использоваться вместе с ними. Лично мне он больше нравится, потому что:
1. Это простая техника, которая способствует общению и взаимодействию, в ней нет бюрократии.
2. Заказчикам, которые не разбираются в IT и производстве ПО, такой подход очень просто объяснить, хватает пары минут.
3. Визуализация в виде mind map.
19
ScrumTrek. Impact Mapping – инструкция по применению, https://byndyu.ru/footnote/19
20
Мэри и Toм Поппендик. Бережливое производство программного обеспечения. От идеи до прибыли, https://byndyu.ru/footnote/20
21
Андрей Шапиро. Схематизация опыта с CJM и Service Blueprint. Практика гибридной нотации, https://byndyu.ru/footnote/21