- SDM заранее анализирует графики Kanban для своей доски:
- Смотрите ваш Lead Time (здесь и далее всегда смотрим 85% персентиль) — вносите в таблице проектов в колонку "LeadTime #1"
- SDM создаёт документ по прошедшему периоду: указываете название команды, продукта, исследуемый период, Lead Time, Customer Lead Time. Также в документ вставляете скриншоты ВСЕХ доступных в вашем инструменте графиков, если там есть хоть какая-то полезная информация и статистика. Если статистики нет — бьёте тревогу почему она не считается, возможно какие-то косяки с ведением доски. Ссылку на документ вставляете в «Результаты "ревью сервиса" #1» в таблице проектов.
- SDM по итогам анализа графиков ищет где у вас в процессе затыки и узкие места, готовит предложения где в каком месте подкрутить, чтобы уменьшить Lead Time, готовит соответствующие предложения
- Проводите собрание "ревью сервиса поставки":
- SDM демонстрирует графики, найденные им узкие места и озвучивает свои предложения по уменьшению Lead Time
- Команда обсуждает, выносит свои решения, фиксируете принятые решения в вашем документе
- В дополнение проводите стандартную ретроспективу. Результаты также отражаете в документе. Можно совместить всё в формате одной ретроспективы, тогда в процессе ретро в "проблемах / что не понравилось" SDM/SRM фиксируют узкие места, которые их тревожат и думаете в "предложениях" как их расшить. Впрочем, на первый раз лучше развести эти две активности, чтобы не путаться.
- По результатам обсуждения SDM меняет доску (например, вводит WIP-лимиты или новые классы обслуживания или добавляет колонки, или добавляет чеклисты для карточек и т.п. — всё что необходимо отражаете на вашей доске, в Definition of Done и прочих правилах, которыми вы руководствуетесь).
- В документе фиксируете что сделано (задачи по продукту за период и что каждый член команды сделал в отдельности).
Напоминаю, что на встрече (а точнее, ещё заранее SDM этим занимается и к встрече готовится), вы смотрите графики, разбираете конкретные задачи, сколько в каких статусах / колонках они находились, где задачи тормозяться и выполняются слишком долго, что можно сделать, чтобы ускориться. Также SRM, поскольку он общается с заказчиками и слышит их "боли", может выкатить свои претензии по качеству (в дополнение к скорости).
В таблице проектов в колонке «LeadTime / Customer LeadTime #1» должны быть цифры Lead Time и Customer Lead Time (всегда 85 персентиль) в формате через слеш: "4 / 11"
В документе по прошедшей встрече (колонка «Результаты "ревью сервиса" #1») вы проводите аналитику: где у вас есть конкретные затыки, какие метрики необходимо улучшить (например задачи застаиваются в определённых колонках и вы это видите), как именно вы будете это дедать.
То, чего мы добиваемся как результат всех этих встреч — отладка потока, чтобы задачи выполнялись:
- быстрее
- более предсказуемо: у заказчика должно быть понимание, сколько выполняются те или иные классы задач. Потом по итогам наработанной статистики вы можете выкатить заказчикам конкретный SLA по тем или иным классам задач, чтобы заказчик понимал, когда ждать в "готово". Например "карточки с багами закрываем за 3 дня максимум, карточки с новыми фичами класса ABC за 10 дней (85 персентиль), класса DEF — за 15 дней (85 персентиль)".
Ещё — Lead Time и Customer Lead Time можно считать в календарных днях, можно в рабочих. Выбираете любой удобный вариант, можно тот, который инструмент по умолчанию поддерживает. Заказчику удобнее, если сроки в календарных днях, вам как команде удобнее, если в рабочих.