всем привет

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

Для примера, что я видел:
- cycle time (среднее время от взятия в работу и до завершения) только части процесса по подготовке требований занимает 2 недели, прежде чем задача будет готова к планированию в спринт
- код ревью занимает 2-3 дня, деплой на стейдж - еще 2-3
в итоге задача от ее создания и до деплоя занимает в среднем около месяца.
Это при том, что разработка занимает в среднем 2-3 дня

Это среднее, само собой при все этом вариабельность (разброс времени) тоже достаточно широкий.
К этому можно добавить влетающие срочные задачи, потери на переключения и псевдо скрам.

Все это создает слабо предсказуемый пайплайн поставки задач и выполнение каких то планов на несколько месяцев можно считать случайной величиной)

Такое положение дел вызывает логичное беспокойство руководства. Руководство не погружено в детали SDLC (жизненного цикла) разработки и не может самостоятельно решить вопрос.
Получается ситуация когда верхи не могут, а низы тоже не могут. Тут как раз и полезна роль Деливери менеджера, который может проанализировать текущий флоу работы, узкие места и сделать поставку более предсказуемой, выстроить каденцию и обеспечить более эффективный поток.

Процесс анализа:
- интервью с ключевыми участниками разработки - ПМ, техлид, СТО, продакт/аналитик и тд
- анализ таск трекера, например JIRA - выгрузка данных по задачам за последние пару месяцев, анализ приблизительных метрик потока, если есть достаточно информации и вокрфлоу более менее понятный, без откровенных костылей, с последовательным переходом между статусами до done
- анализ встроенных отчетов трекера. В JIRA это - CFD (кумулятивная диаграмма потока) и Control Chart. Оба этих репорта должен обязательно уметь читать и анализировать каждый ПМ выше уровня джуниора (ну или понимать что спрашивать у ИИ по отчету)
- анализ зон ответственности и точек передачи (RACI матрица если есть, если нет, то опрос участников)
- анализ самих задач: полнота описание, наличие DoR и DoD
- анализ процессе деплоя, покрытия тестами, процесса тестирования

Это позволяет сформировать набор гипотез об узких местах процесса и их влиянии на поток работу.
Далее валидируем каждую гипотезу погружаясь на уровень глубже, обычно с помощью интервью и получения дополнительных данных из других источников (например планы в google sheets и другие заметки вне трекера задач)

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

В аудите хорошо помогает ИИ, особенно когда надо проанализировать выгрузку из JIRA или подготовить список вопросов для интервью из собственных заметок.

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

Всем отличного дня и наступающей недели!