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

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

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

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

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

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

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

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

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