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

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

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

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

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

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

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

2. Выбираем список User Story для ближайшего релиза, делим истории на итерации[22] и начинаем разработку. В каждую итерацию обязательно входят: планирование на неделю, ежедневные стендапы, демо результатов работы в конце недели. Другие практики из Agile и Lean используются в зависимости от потребностей проекта. Например, ретроспектива[23] может быть раз в месяц или каждую итерацию.

3. В любой момент заказчик и/или команда могут остановиться и вернуться к пересмотру Impact Map или обновлению User Story Map. Или вообще сделать Pivot[24], так как текущая гипотеза оказалась ошибочной. В общем, всё является гибким, обсуждаемым и изменяемым на пользу бизнес-целей.

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

5. После релиза крайне важно вернуться к Impact Map и понять, достигли мы целей или нет.

6. Дальше весь цикл повторяется заново.

Если выделить ключевые точки, то у нас получается:

1. Impact Map для понимания целей и гипотез.

2. Customer Journey Map – чтобы увидеть систему целиком со всеми взаимосвязями.

3. User Story Map – чтобы понять конкретные сценарии, которые помогут достичь бизнес-целей.

4. Разработка с циклами обратной связи, которая затрагивает написание кода, тестирование, IT-архитектуру и другие части создания ПО.

5. Анализ результата, возврат с Impact Map с пересмотром гипотез и целей.