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

href="ch2.xhtml#id46">[24], так как текущая гипотеза оказалась ошибочной. В общем, всё является гибким, обсуждаемым и изменяемым на пользу бизнес-целей.

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

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

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

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

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

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

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

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

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

Более детальный взгляд

Можно провалиться глубже в сам процесс и посмотреть на фазы и активности: как и когда они начинаются, что в них происходит. В любой момент времени в процесс вовлечены все причастные к продукту – от разработчиков до стейкхолдеров (рис. 13).

Рис. 13. Постоянная обратная связь на каждом этапе

Постановка задачи

Повторюсь, для начала надо понять цели проекта. Для этого мы используем Impact Mapping. Обычно работа по созданию IM занимает от дня до недели в зависимости от размера проекта и свободного времени у всех заинтересованных лиц.

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

Во время обсуждения целей многие впервые по-настоящему задумываются об их измеримости. Если стейкхолдеров несколько, то в этот момент они узнают много нового друг о друге и о цели, которую каждый из них преследует. Таким образом, мы пытаемся увидеть проблему/задачу, которую на самом деле нас пригласили решить.

Точки соприкосновения и взаимосвязи

Чтобы продукт оставался целостным и не создавал препятствий на пути пользователей, важно увидеть его с высоты птичьего полёта. Для этого выявляются точки входа и выхода пользователя, а также переходы между экранами и состояниями. Мы описываем схему переходов и взаимодействий с помощью CJM (рис. 14).

Рис. 14. Фото доски с реальным Customer Journey Map

Результаты этапа:

1. Целостное видение IT-продукта.

2. Точки входа, точки выхода и переходы пользователей.

3. Линии жизни действующих лиц и точки их взаимодействия друг с другом.

Глазами пользователей

Примерно к финалу формирования CJM становится возможно дать старт работе по созданию User Story Map (рис. 15). Карта сценариев состоит из:

1. ролей (бухгалтер, менеджеры отдела маркетинга и т. п.);

2. активностей этих ролей (формирование отчёта, создание рекламной кампании);

3. задач, которые детализируют активности (задаётся временной период, активизируется подписка с помощью почты);

4. все сценарии приоритезированы по двум направлениям: время и важность.

Рис. 15. Способ расположения истории в User Story Map

Здесь идея в том, чтобы описать систему с точки зрения пользователя, а не технической реализации.

Создание User Story Map обычно не происходит с первого раза. Часто этот процесс занимает несколько итераций с постоянным уточнением ролей, активностей и приоритетов.

Первые прототипы

Когда User Story Map близок к полноте, UI/UX специалисты приступают к первым прототипам интерфейса. Важно быстрее проверить основные концепции, представленные в нашем User Story Map. Бывает, что эти прототипы рисуют просто на бумаге, сканируют и рассылают. Но даже благодаря таким простым прототипам возникают новые вопросы к сценариям и происходит возврат на переформатирование User Story Map. Пример прототипа на бумаге из нашего проекта:

Рис. 16. Прототип интерфейса, созданного на бумаге

В это же время разработчики пишут код, чтобы лучше понять предметную область. Разработчики пишут тесты, чтобы понять, как объекты будут влиять друг на друга, откуда возьмётся результат. Другими словами, разработчики моделируют предметную область через тесты. Из этих экспериментов, как и из UI-прототипов, тоже рождается много уточняющих вопросов к владельцам продукта[25].

Проектировщики интерфейса также нащупывают предметную область, собирая все виды данных для системы. Впоследствии этими данными будут бомбардироваться дизайн-макеты.

Результатом первой фазы является понимание измеримых целей, набор User Story на релиз и некоторое представление о системе за счёт прототипов интерфейса и кода, написанного через TDD.

Всё проектирование от выбора названия переменной в коде до абстракций в IT-архитектуре основано на Impact Map, Customer Journey Map и User Story Map. Эти три визуализации активно используются всеми членами команды, чтобы сохранять целостность понимания.

Работа над релизом

В этой фазе идёт активное печатание кода, настройка CI/CD, тестирование и другая активность, которая присуща разработке ПО. Мы часто используем TDD, CQRS, различные СУБД, чтобы точнее попасть в требования к системе в рамках стоимости инфраструктуры и гибкости. Большое внимание уделяем DDD[26].

Практически никогда не создаётся Big Design Up Front[27], то есть не создаётся наперёд всеобъемлющая архитектура с учётом всех самых мелких деталей. Работа над программной архитектурой происходит последовательно, небольшими шагами, методом постоянного приближения. Мы рисуем архитектуру, выбираем точки расширения и масштабирования, которые согласуются с целями системы. Цели системы периодически меняются, поэтому архитектура должна быть гибкой. В архитектуре важно, с одной стороны, не быть архитектурным астронавтом, а с другой – иметь опыт проектирования сложных систем и учитывать все нюансы.

UI/UX, разработчики и QA-инженеры постоянно взаимодействуют друг с другом. Промежутки от планирования до демо небольшие – всего одна-две недели, работа довольно плотная. Результатом каждой итерации является инкремент к релизу, который двигает нас в сторону достижения целей.

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

К чему готовить заказчика?

Далеко не все заказчики готовы к такому интенсивному взаимодействию. Гораздо проще закинуть ТЗ в команду и через полгода вернуться за результатом работы.

Нам такой вариант