Вторая часть поста про то, как сделать, чтобы продуктовая agile-команда выполнила задачу к определенному сроку, но при этом не изменила принципам работы по потоку. Первая часть поста посвящена описанию нашего подхода к работе продуктовых команд, а также тому, что в вытягивающей системе основными инструментами управления сроками становятся не перенос ответственности за сроки на исполнителя (команду), а прозрачность и прогнозируемость работы этой команды. Ниже остановимся на метриках команд и их использовании при прогнозировании сроков и синхронизации исполнения задач.
Метрики
Основной тип событий в нашей модели — перемещение задачи из одной области нашей карты в другую, их мы и будем оцифровывать в метриках.
Наша самая главная метрика — Lead Time: это характерное время, за которое задача доходит от одной из четырех контрольных точек (появление идеи, ТПР, Х и ТПО) до установки на продуктив.
Как видим, они образуют иерархию вложенности. Мы используем величины Lead Time, выраженные в рабочих, а не календарных днях. Если над одним продуктом работает больше одной команды, то TTM, Customer Lead Time и Х Lead Time относятся к продукту в целом, а Lead Time для потока у каждой команды может быть свой.
Устоявшейся терминологии для разных Lead Time пока нет, поэтому аналогичные по смыслу показатели у других авторов можно встретить под другими названиями, например, для потокового Lead Time (тот, который самый короткий) часто используется термин Cycle Time. Здесь буду придерживаться нашего варианта «жаргона», извините, если что.
Также часто используются метрики потока — количество задач, входящих и выходящих из области за период времени, и количество задач, находящихся в области на определенный момент. Эти показатели можно видеть на CFD-диаграмме или на диаграмме потока задач (которая, на наш взгляд, легче читается). Например, для области «Поток» диаграмма потока задач с шагом в неделю выглядит так:
Еще эту диаграмму называют «Бассейн», так как она построена по принципу «втекает-вытекает-оставшийся уровень». Inflow – поток задач, которые взяты в поток за неделю, Done – количество успешно выполненных задач, Discarded – количество отбракованных из потока задач, Unfinished – количество задач, оставшихся в потоке на конец недели (другое название - WiP – Work in Progress).
Прогнозирование с использованием показателей Lead Time разных уровней
В нашей визуализации движения по этапам жизненного цикла мы можем видеть текущее положение технических и бизнес-эпиков (серые) и входящих в них задач (персиковые, кажется, так этот цвет называется).
Если заглядывать сюда регулярно, то сможем отследить и их перемещение между областями.
Предположим, нас интересует один конкретный эпик, который уже находится в реализации, в области «Поток». Оставим на рисунке только его и подчиненные ему задачи:
В эпик входят четыре задачи, одна из которых уже завершена, две в работе и одна еще не взята в поток и находится в области «Готово к взятию», на вершине бэклога. Исходя из ситуации, дата завершения эпика будет определяться, скорее всего, выполнением задачи, которая еще не взята в поток. Эпики переводятся в область «Поток» после того, как хотя бы одна из вложенных задач попала в поток, и считаются завершенными, когда все вложенные задачи завершены.
Чтобы понять, сколько времени обычно нужно, чтобы провести задачу через поток, рассмотрим спектральную диаграмму Lead Time для потока этой команды за последние три месяца:
Для удобства рассчитываются и дополнительно выводятся на графике значения 50-го и 85-го перцентилей – это количество рабочих дней, которое у команды занимает решение одной задачи для 50% и 85% всех задач соответственно. В данном случае это 2 и 4 дня. Значит, только для 15% задач Lead Time составляет больше 4-х рабочих дней. Вспомнив про типизацию задач, посмотрим на спектральные диаграммы разных типов задач по отдельности (слева направо - Дефект, Эксплуатация, Технические и Бизнес), и увидим, что для бизнес-задач 85 перцентиль составляет не четыре, а шесть рабочих дней:
Таким образом, мы получаем достаточно обоснованный прогноз, что с вероятностью немного менее 85% эта задача и, как следствие, весь эпик будут выполнены за шесть рабочих дней. Меньше 85% получается из-за того, что есть небольшая вероятность, что какая-то из двух задач в потоке застрянет там больше, чем на шесть дней.
Теперь посмотрим, как можно мониторить движение эпика на всем жизненном цикле, от идеи до реализации при помощи статистики Lead Time разных уровней:
Представим себе руководителя проекта (РП), у которого есть план, содержащий несколько задач для разных команд, которые нужно выполнить к определенным датам. РП – не agile-роль, он может использовать дедлайны, более того, он не может их не использовать :). Вопрос в том, как он добьется выполнения этих сроков продуктовыми командами, которые не горят желанием брать на себя обязательства по достижению дедлайна.
Рассмотрим одну из таких задач. Плановую дату ее исполнения обозначим как день «Д». Построим «LeadTime-профиль» продукта/команды, которая будет ее выполнять, в виде таблицы:
Дни – рабочие, неделя соответствует 5 рабочим дням. 85% вероятность выполнения РП считает приемлемой.
Алгоритм работы РП заключается в том, что пока задача находится в зеленой зоне - РП только наблюдает и не предпринимает активных действий, когда она попадает в красную зону – РП включает «режим экспедирования» и предпринимает усилия, чтобы вернуть задачу в зеленую зону. Рассмотрим по шагам на примере:
РП приходит с новой задачей к Product Owner (PO) и договаривается о помещении ее в продуктовый бэклог с таким приоритетом, чтобы она, по предварительной экспертной оценке PO, была выполнена до дня «Д». PO создает соответствующий эпик. РП ставит себе календарное напоминание на «Д - 8 недель» - это «зеленая» дата попадания эпика в следующую область «Решили делать», и уходит заниматься другими делами.
При срабатывании напоминалки РП проверяет, что его эпик пересек ТПР. В этом случае он ничего не предпринимает и ставит себе следующую напоминалку на «Д - 14 дней» (дата перемещения в «Готово к взятию в поток» в «зеленой зоне»).
После очередной напоминалки РП видит, что эпик по-прежнему лежит в области «Решили делать», не пересек точку Х и не декомпозирован на задачи. В этом случае он включает «режим экспедирования»: идет к Product Owner’у и договаривается о том, чтобы эпику подняли приоритет. Затем он ежедневно отслеживает ситуацию, пока эпик не оказывается в области «Готово к взятию», декомпозированный на задачи. Предположим, что это случилось в дату «Д - 8 дней».
Далее имеет смысл отслеживать задачи, входящие в эпик, по отдельности. Предположим, что их три, в области «Готово к взятию» они расположены на втором, пятом и шестом месте по приоритетам (см. рисунок ниже). Мы уже знаем, что если задача находится на самом верху области «Готово к взятию», то с вероятностью 85% она будет выполнена не позже, чем через 6 дней. Остается понять, сколько нужно времени, чтобы все три задачи эпика попали в поток. Посмотрев на потоковую диаграмму, мы увидим, что команда берет в поток в среднем 15 задач в неделю, то есть примерно по три задачи в рабочий день. Шесть задач будут взяты в работу, скорее всего, не позднее, чем за два дня. Поскольку день «Д» близко, РП стоит проследить, чтобы в бэклог поверх «его» задач не были помещены дополнительные задачи. Не стоит забывать, что команда принимает обязательства выполнить задачу только в момент ее взятия в поток, а до этого возможны изменения приоритетов.
После того как все три задачи попали в поток команды, можно считать, что они вышли на баллистическую траекторию, ускорить их уже не получится, и РП остается только ожидать результата.
Если РП пришел со своей задачей не заранее, а со словами «Надо сделать вчера», то задача изначально находится в «красной зоне». В этом случае РП будет отказано в реализации задачи к этому сроку. Если у РП есть достаточный административный ресурс, продуктовая команда может быть временно переведена из штатного режима «работы по потоку» в режим «подвиг», с принудительным управлением работами по критической задаче. Эта конкретная задача, возможно, будет выполнена, но общая мотивация, производительность и качество работы команды пострадают и потребуют времени на восстановление.
Важно: при движении эпика по жизненному циклу все виды Lead Time нужно измерять для той части эпика, которая дошла до продуктива.
В процессе проработки от первоначальной идеи могут отделяться куски, которые предполагается сделать позже, а может быть, и никогда. Плохая практика, когда в одном эпике копятся все задачи по этой теме – первой, второй, … семнадцатой очереди реализации, просто чтобы их не забыть. Это делает эпик вечно незавершенным и непригодным к отслеживанию как отдельного элемента работ и ценности. В исходном эпике нужно оставлять только задачи первого приоритета, задачи всех остальных приоритетов надо выносить в отдельные эпики, которые переносятся обратно в область идей. В дальнейшем с ними работают как с новыми идеями по общим правилам. При этом информационно можно указать, какой эпик для него является родительским, или объединить их общей меткой, чтобы можно было отследить историю реализации первоначальной идеи.
Нужно ли автоматизировать прогнозирование сроков исполнения задач?
Посмотрим еще раз на нашу визуализацию. Возникает подозрение, что движение эпиков и задач внутри каждой области более или менее упорядочено: большинство эпиков и задач движутся слева направо по областям жизненного цикла и снизу вверх по приоритетам внутри области.
Можно ли спрогнозировать движение конкретной задачи от идеи к реализации, с учетом количества и характеристик задач, которые находятся выше нее по приоритетам и/или правее по ЖЦ? Получится ли в результате более точный прогноз, нежели мы можем получить из «LeadTime-профиля» продукта? Ведь пробабилистический прогноз с помощью «LeadTime-профиля» учитывает только в какой области находится задача , но не учитывает, сколько и каких задач команде предстоит сделать, прежде чем она приступит к интересующей нас задаче. Примерно как РП из предыдущей главы оценивал время, когда задачи 2, 5 и 6 будут взяты в поток, только автоматически, с учетом характеристик задач, подробных исторических данных.
Мы с командой портала метрик (особенная благодарность Диме Новикову!) попробовали сделать такой автоматический прогноз для задач в области «Готово к взятию». Идея была в следующем: для каждой задачи, которая сейчас находится в бэклоге, рассмотрим количество и типы задач, расположенных в бэклоге выше нее. В исторических данных по работе этой команды ищем похожие ситуации — когда выше некоторой задачи в бэклоге находился примерно такой же набор задач по количеству и типам. Смотрим, сколько времени у команды занимало выполнение такого набора задач в прошлом, получаем вероятностное распределение, из которого можно с разной степенью вероятности сделать прогноз дат, когда интересующая нас задача попадет на продуктив,
Полученные нами оценки сроков оказались весьма расплывчаты и малополезны. Сначала мы, естественно, пытались найти и исправить недостатки в прогнозной модели или подборе параметров, но существенного улучшения не происходило. Одной из основных причин этого было то, что задачи в бэклоге не двигались упорядоченно, как патроны в обойме, снизу вверх, а меняли приоритеты и перемещались вверх и вниз. В бэклог поступали новые задачи, которые брались в работу быстрее, чем те, что лежали в бкэлоге до них. В результате некоторые задачи "пролетали" существенно быстрее, а другие "зависали", и их положение в бэклоге на момент прогноза влияло на их судьбу гораздо меньше, чем мы ожидали. То есть наше базовое предположение, что задачи в бэклоге движутся в основном снизу вверх, не оправдалось.
Поэтому теперь мне кажется, что в данном случае применять такого рода способы прогнозирования нет смысла.
"Самосбывающийся прогноз"
Автоматизированное прогнозирование обычно применяют для тех событий, на которые потребитель прогноза повлиять не может – погода, покупательский спрос, движение автобуса в пробках, etc… А на движение продуктовых задач потребители прогноза (команда и заказчики) имеют большое влияние. Если прогноз не устраивает заказчика и/или команду, то есть как минимум три инструмента для исправления ситуации:
Договориться об изменении приоритета задачи.
Сократить скоуп и требования, реализовать сначала ту часть, которая дает наибольший эффект при меньших затратах.
Реализовать сначала менее трудоемкое, временное решение с образованием.
Достижение необходимого срока возможно без штурмовщины, если:
Изначальные сроки реалистичны - находятся в «зеленой зоне LeadTime-профиля» команды.
Задача действительно нужна, кто-то ждет ее выполнения и прилагает периодические усилия для поддержания ее приоритета.
Продуктовая команда работает в штатном режиме: осуществляет регулярное управление техническим долгом; большая часть задач команды не имеет жестких дедлайнов и их можно «подвинуть» в случае необходимости; команда не работает со 100% напряжением, у нее есть резерв для маневра.
При таких условиях любой реалистичный прогноз становится в некотором смысле самосбывающимся. Реалистичным считается прогноз, который не предполагает, что команда вдруг начнет решать задачи быстрее, чем она обычно это делает на текущей стадии своего развития. Достижение такого «самосбывающегося дедлайна» перестает быть «подвигом» и не несет существенных рисков.
Изменение зон ответственности при работе со сроками
Обратите внимание, как меняется общий подход к достижению определенных сроков в «проектной» и «продуктовой» парадигмах. Под «заказчиком» ниже понимаются все роли, которые заинтересованы в результате, но сами его не производят – заказчики, начальники подразделений, руководители проектов…
В «проектной» парадигме базовый алгоритм работы со сроками следующий.
Заказчик договаривается с исполнителем о скоупе и сроке - это называется планирование. После достижения договоренностей основная ответственность за сроки ложится на исполнителя. Пока не будет инициирована необходимость передоговориться, заказчик не обязан участвовать в процессе и, в идеале, может действовать в стиле «выстрелил и забыл».
Когда я высказал эту мысль своим коллегам, мне тут же возразили, что так не бывает. Роль руководителя проекта придумана как раз из-за того, что эта "пуля" сама по себе в цель не попадает почти никогда. Ее надо постоянно подруливать в полете, и кто-то должен этим заниматься. Но изначальный смысл именно в этом - после согласования плана ответственность за срок переносится на исполнителя, чтобы освободить заказчика для более важных дел.
В «продуктовой» парадигме:
Заказчик проявляет регулярное внимание к задаче, актуализирует ее приоритет и оценку ценности в сравнении с конкурирующими задачами. Команда (исполнитель), как правило, не берет на себя ответственность за выполнение задач к определенному сроку. Вместо приложения усилий для достижения сроков по отдельным задачам команда концентрируется та том, чтобы все свои задачи выполнять одинаково быстро и предсказуемо.
Таким образом в продуктовой парадигме ответственность за достижение сроков в большей степени ложится на сторону заказчика. Рабочая гипотеза состоит в том, что в обмен повышается общая эффективность приложения усилий заказчиком: выше вероятность получить то, что нужно, к нужному сроку, меньше неактуальных задач, сделанных потому, что их забыли отменить. Проверкой этой гипотезы мы сейчас и занимаемся в SM Lab :).
Что может сделать команда для повышения своей прогнозируемости.
Для того чтобы работа команды была прогнозируемой, нужно чтобы у показателей Lead Time разброс (дисперсия распределения) был поменьше. Даже при небольшом разбросе не нужно забывать, что это вероятностный, а не детерминистический прогноз, отклонения всегда возможны, и ни одна команда не может быть на 100% предсказуемой. Но если распределение имеет большую дисперсию, то этот показатель полностью теряет предсказательную силу.
Вернемся к таблице «LeadTime-профиля». По различию в 50-м и 85-м перцентилях легко понять, насколько силен разброс значений соответствующего Lead Time. Понятно, что по мере движения по жизненному циклу слева направо проработанность задач увеличивается, а степень неопределенности уменьшается. В нашем примере для Lead Time потока 85-й перцентиль больше 50-го в полтора раза (6 и 4 рабочих дня), а для Customer Lead Time - уже более чем в три раза (8 недель = 40 р.д. и 12 р.д.).
Для внешних интересантов интереснее всего предсказуемость задач как раз в левой части жизненного цикла, в областях «идеи» и «решили делать». От этих прогнозов зависят решения, которые принимаются при формировании дорожных карт и бизнес-планов. Будет ли готова новая функциональность к началу новой коллекции, или надо сразу отложить ее внедрение на полгода, до следующей коллекции? На какой период планировать дополнительные ресурсы, связанные с этим? И множество других важных вопросов. В идеале, заказчик хочет знать, «когда будет готово», сразу же, как только он высказал новую идею — в наших терминах это значит, что дисперсия распределения Time to Market должна быть как можно меньше. К сожалению, обеспечить такую предсказуемость в области идей для команды очень сложно, так как эта область в наименьшей степени подвержена ее влиянию. Если каждую идею прорабатывать сразу до такой степени, чтобы по ней можно было дать обоснованный срок реализации, у команды не останется времени на полезную работу – все уйдет на детальную проработку идей, которые никогда не будут реализованы.
Поэтому усилия по улучшению предсказуемости предлагается прилагать, начиная с области «Решили делать», куда задачи (они же - эпики) переносятся через Точку Принятия Решения с участием представителей команды. Поэтому на разброс Customer Lead Time повлиять уже возможно, и для этого подходит то же средство, которые команды привыкли использовать для стабилизации работы своего потока - ограничение количества задач, находящихся в работе. На область «Решили делать» можно установить WiP-лимиты, так же, как это делается большинством продуктовых команд для этапов работы в потоке и для области «Готово к взятию в поток».
Здесь удобно использовать WiP-лимит не только на максимально допустимое количество задач (эпиков), по которым принято решение начать проработку командой, но и на минимальное их количество в области. Это позволит автоматически включать процедуру пополнения области при достижении нижней границы.
Такой подход позволяет постоянно и предсказуемо работать с новыми идеями, не превращая область в свалку идей.
Предсказуемое поведение Customer Lead Time дает заказчикам хорошую точку опоры, «границу стакана», которую не стоит переходить, и позволяет заботиться о судьбе своих идей и обеспечивать их переход через ТПР раньше, чем они попадут в «красную зону».
Выводы
"Вытягивающий" принцип управления работами в продуктовой парадигме не позволяет возлагать ответственность за сроки на конечного исполнителя - продуктовые команды, кроме как в исключительных случаях. Команды концентрируются не на достижении сроков конкретных задач, а на повышении эффективности, стабильности и предсказуемости своей ежедневной работы.
Ответственность за сроки остается на стороне заказчика, в обмен на повышение вероятности и скорости получения необходимого результата.
Для контроля сроков применяются методы визуализации и прогнозирования. Управление осуществляется через динамическое изменение скоупа и приоритетов.
Условием применимости такого подхода является "антихрупкость" системы в целом, которая обеспечивается регулярным и превентивным применением технических и организационных практик, обязательных для продуктовых команд.
Это все. Спасибо, что дочитали!