Александр Бындю - Антихрупкость в IT

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

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

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

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

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

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

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Александр Бындю. Проблем быть не должно, статья находится в моем блоге blog.byndyu.ru

Cynefin framework, https://byndyu.ru/footnote/2

Situational leadership theory, https://byndyu.ru/footnote/3

Андрей Шапиро. Руководство по сбору требований в формате User Story Mapping, https://byndyu.ru/footnote/4

Product Owner по сути – это предприниматель внутри компании. Он ещё не вырос до создания своей компании либо не хочет рисковать созданием собственного бизнеса, при этом он уже мыслит и действует как предприниматель.

Five whys, https://byndyu.ru/footnote/6

Gojko Adzic. Fifty Quick Ideas To Improve Your User Stories

Impact Mapping, https://byndyu.ru/footnote/8

Byndyusoft. Анализ IT-продукта, https://byndyu.ru/footnote/9

Отрывок из выступления Жванецкого, https://byndyu.ru/footnote/10

Gojko Adzic. Impact Mapping

User Story, https://byndyu.ru/footnote/12

Gojko Adzic. Agile product management using Effect Maps, https://byndyu.ru/footnote/13

Gojko Adzic, https://byndyu.ru/footnote/14

Gojko Adzic. Specification by Example

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

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

Когда я рассказывал про Impact Mapping на AgileClub, коллеги заметили, что есть и другие способы понять стратегические цели. Например, можно использовать Lean Canvas, JTBD или собрать требования в проектной документации с описанием целей и заинтересованных сторон. На самом деле Impact Mapping не противоречит другим подходам и может использоваться вместе с ними. Лично мне он больше нравится, потому что:

1. Это простая техника, которая способствует общению и взаимодействию, в ней нет бюрократии.

2. Заказчикам, которые не разбираются в IT и производстве ПО, такой подход очень просто объяснить, хватает пары минут.

3. Визуализация в виде mind map.

Стать в блоге компании ScrumTrek. Impact Mapping – инструкция по применению

Мэри и Toм Поппендик. Бережливое производство программного обеспечения. От идеи до прибыли

Андрей Шапиро. Схематизация опыта с CJM и Service Blueprint. Практика гибридной нотации, https://byndyu.ru/footnote/21