Мы с командой исходим из больших целей, которые себе ставим. Эти цели направлены на решение проблем реальных людей (наших потребителей). Цели мы достигаем с помощью конкретных небольших изменений.
Каждое изменение проходит по трех этапному процессу:
- Discovery
- Design
- Delivery
Ссылка на статью про AUX3.
- Такой подход нацелен на глубокое понимание сути проблемы для влияния на Поддерживающие структуры в концепции пирамиды системного мышления
- Помогает работать над декомпозицией и сокращением размера изменений
Как следствие изменения происходят быстрее и с большей вероятностью приводят к «положительному» результату.
Discovery
Это процесс погружения в проблему, ее формализация, понимание масштаба и причин.
Итоговая проблема может и чаще всего отличается от изначально заданой.
Входящая проблема обычно на самом деле является одним из решений. Возврат к истокам и погружение в контекст в рамках процесса Дискавери позволяет понять, что на самом деле было триггером для поиска решения.
В итоге изначальное решение может привести к нескольким зависимым или независимым проблемам.
Процесс можно считать завершенным, когда есть хотя бы одно решение.
Отказ от решения проблемы — это тоже решение.
Инструменты поиска решений:
- Смешанные методы исследований
- Моделирование проблемы
- Визуализация в виде диаграммы бизнес-процесса
Если решение планируется в ИТ системах:
- Архитектурные диаграммы
- Изучение спецификаций систем
Решение обязательно должно содержать следующие элементы:
- Сформулированная проблема. С точки зрения конечного пользователя (клиента).
- Понимание периметра изменений: архитектура, прототипы, схема бизнес-процесса.
- Механизм объективной проверки результата изменений и учета последствий. Это самый важный компонент.
- Уверенность в реализуемости изменений. Например, системы, которые мы хотим менять, понятны и есть люди способные их поменять. Если люди заняты, значит изменение нереализуемо.
Лучшей практикой является декомпозиция решения проблемы на множество мелких последовательных изменений, каждое из которых может реализовываться независимо. С помощью такого подхода появляется инструмент проверки реальности сформулированной проблемы и адекватности предложенных решений.
Грубо говоря, если реализовали хотя бы одно мелкое изменение из предложенных и механизмы его проверки сработали — скорее всего мы движемся в правильном направлении.
Если же все идет не по плану, мы еще не успели потратить много ресурсов и можем еще раз пересмотреть решения с новыми открывшимися данными.
Design
Это процесс проектирования и описания выбранного изменения.
В рамках этого этапа изменение декомпозируется на отдельные куски, которые можно воплощать в жизнь.
Артефакты на выходе:
- Описание изменений, спецификации
- Макеты
- Инструкции
- Обучения
⠀
В случае если мы меняем систему, необходимо провести PBR с командой разработки, чтобы подтвердить адекватность спецификации и предложенного решения, а также получить оценку затрат на изменение. Например, в Story Points (описание далее).
В результате изменение может вернуться на этап Discovery или отмениться, если оно не проходит проверку на адекватность или затраты на него слишком велики.
Delivery
Это процесс поставки описанных изменений.