Для гармоничного взаимодействия бизнеса, дизайна, разработки и тестирования необходим понятный алгоритм взаимодействия
🏛️ Компания
DLGroup — развивает продукты системы DLS, а также связанные с ними сервисы.
🛠️ Ситуация
В компании было принято решение внедрить E2E процесс, для оптимизации существующего процесса и ускорения разработки. Владельцы продуктов вступили в роли владельцев процесса, а с реализацией и контролем им помогают менеджеры процесса.
В ходе внедрения процесса появилась необходимость организации алгоритма передачи информации «из конца в конец».
Ввиду того, что в компании была внедрена гибкая методология разработки Scrum — основным инструментом постановки задачи для разработчиков стали User Stories.
💡 Решение
Мной было выдвинуто предложение о необходимости разработки и описания алгоритма передачи информации из конца в конец, между всеми задействованными подразделениями компании.
Процесс разработки продукта был разделён на два цикла «Дискавери» и «Деливери», входе первого цикла осуществляются исследования и проектирование, в ходе второго — разработка, тестирование, приёмка и поставка продукта.
Для бесшовной транспортировки требований из первого цикла во второй необходимо их сначала представить в формате JTBD. А в процессе проработки конвертировать Job Stories в User Stories, декомпозированные через фреймворк критического пути (CPM), таким образом, чтобы команда разработки смогла в ходе спринта выдать завершенный инкремент.
Разработка и описание алгоритма помогли определить пулл используемых инструментов, а также порядок взаимодействия команд, что улучшило коммуникацию, планирование и ускорило разработку
В ходе проработки алгоритма были использованы JBTD для фиксации свойств, которыми должен обладать продукт. Эти требования рождались из запросов пользователей, CustDev и исследований рынка.
Далее истории работы обрастают ролевой моделью и конвертируются в User Stories.
В ходе проработки пользовательских историй бизнес-аналитики и дизайнеры прибегают к методу CJM (в произвольной форме), для выявления корнер-кейсов и других сценариев, требующих проработки.
Кейсы требующие проработки фиксируются в документации аналитиков, после чего происходит формирование пула задач для дизайнеров на реализацию сценариев фич. Подготовленные сценарии прикладываются к User Stories в бэклоге.
В конечном итоге для разработчиков формируются бэклог с эпиками, в которые включены User Stories, охватывающими ключевые и вспомогательные сценарии, корнер кейсы.
При этом, в разработку могут сначала отправиться ключевые сценарии, а корнер кейсы могут находится на этапе проектирования или на паузе. Приоритизация бэклога спринта осуществляется по результатам завершенных спринтов, в ходе грумингов и других ритуалов Scrum.
Планирование спринта осуществляется в присутствии владельца продукта или менеджера, с учётом расставленных бизнесом приоритетов.
Такой алгоритм позволяет более точно определять объём предстоящих работ и ожидать конкретные результаты.
Я принял непосредственное участие в разработке фреймворка, описании его тезисов и внедрении, совместно с CPO, владельцами продуктов и техническими специалистами.
Внедрение алгоритма позволило ускорить разработку в два раза и повысить качество реализации критических задач.
