Тройной трек разработки

Мы с командой исходим из больших целей, которые себе ставим. Эти цели направлены на решение проблем реальных людей (наших потребителей). Цели мы достигаем с помощью конкретных небольших изменений.

Каждое изменение проходит по трех этапному процессу:

1. Discovery
2. Design
3. Delivery

Ссылка на статью про AUX3.

• Такой подход нацелен на глубокое понимание сути проблемы для влияния на Поддерживающие структуры в концепции пирамиды системного мышления

• Помогает работать над декомпозицией и сокращением размера изменений

Как следствие изменения происходят быстрее и с большей вероятностью приводят к «положительному» результату.

Discovery

Это процесс погружения в проблему, ее формализация, понимание масштаба и причин.

Итоговая проблема может и чаще всего отличается от изначально заданой.

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

В итоге изначальное решение может привести к нескольким зависимым или независимым проблемам.

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

Отказ от решения проблемы — это тоже решение. 

Инструменты поиска решений:

• Смешанные методы исследований
• Моделирование проблемы
• Визуализация в виде диаграммы бизнес-процесса

Если решение планируется в ИТ системах:

• Архитектурные диаграммы
• Изучение спецификаций систем

Решение обязательно должно содержать следующие элементы:

1. Сформулированная проблема. С точки зрения конечного пользователя (клиента).
2. Понимание периметра изменений: архитектура, прототипы, схема бизнес-процесса.
3. Механизм объективной проверки результата изменений и учета последствий. Это самый важный компонент.
4. Уверенность в реализуемости изменений. Например, системы, которые мы хотим менять, понятны и есть люди способные их поменять. Если люди заняты, значит изменение нереализуемо.

Лучшей практикой является декомпозиция решения проблемы на множество мелких последовательных изменений, каждое из которых может реализовываться независимо. С помощью такого подхода появляется инструмент проверки реальности сформулированной проблемы и адекватности предложенных решений.

Грубо говоря, если реализовали хотя бы одно мелкое изменение из предложенных и механизмы его проверки сработали — скорее всего мы движемся в правильном направлении.

Если же все идет не по плану, мы еще не успели потратить много ресурсов и можем еще раз пересмотреть решения с новыми открывшимися данными.

Design

Это процесс проектирования и описания выбранного изменения.

В рамках этого этапа изменение декомпозируется на отдельные куски, которые можно воплощать в жизнь.

Артефакты на выходе:

• Описание изменений, спецификации
• Макеты
• Инструкции
• Обучения

⠀

В случае если мы меняем систему, необходимо провести PBR с командой разработки, чтобы подтвердить адекватность спецификации и предложенного решения, а также получить оценку затрат на изменение. Например, в Story Points (описание далее).

В результате изменение может вернуться на этап Discovery или отмениться, если оно не проходит проверку на адекватность или затраты на него слишком велики.

Delivery

Это процесс поставки описанных изменений.