Иногда я буду писать «проект», а иногда «продукт». Для себя мы не разделяем два этих понятия. В книге «Бережливое производство программного обеспечения. От идеи до прибыли»[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). После описания сценариев приоритезируем их и выбираем самые важные для ближайшего релиза. Никогда не пытаемся охватить всё разом: слона надо есть по частям.