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

Метрики

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

Наша самая главная метрика — Lead Time: это характерное время, за которое задача доходит от одной из четырех контрольных точек (появление идеи, ТПР, Х и ТПО) до установки на продуктив.

Привет! Меня зовут Петр Александров, я много лет работал руководителем проектов и живо интересовался вопросами календарного планирования, достижения дедлайнов и координации работ во времени. Сейчас я лидер продукта «Портал метрик продуктовых команд» в SM Lab и работаю с продуктовыми agile-командами. Такие команды делают задачи не к определенному сроку, а по потоку. 

Что это значит?

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

2. Есть только один источник задач — бэклог команды. Никто не может передать задачу в работу команде иначе, чем поместив ее в бэклог.

3. Задачи в бэклоге приоритезирует Product Owner (заказчик), а не команда.

4. В работу берется самая приоритетная задача из бэклога, и только после того, как обработана и передана дальше по потоку предыдущая задача.

5. Завершение уже начатой задачи приоритетнее взятия в работу новой. Нельзя принудительно заталкивать в поток задачу раньше, чем команда готова ее взять. Нельзя откладывать текущую задачу ради новой, пусть даже очень важной.

6. Команда не стремится как можно быстрее решить конкретную задачу, но прилагает регулярные усилия по ускорению потока в целом.

Конечно, есть оговорки и исключения, но это базовые правила для подавляющего большинства случаев. 

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