Кластеризация зависимостей - обо что спотыкается ваше delivery
https://t.me/LeninKerrigan Илья Смирнов В hh отвечаю за эффективность поставки соискательских продуктов. Сайт hh.ru и мобильные приложения “hh работа”, маркетплейс экспертов и Карьерную Платформу (career.ru). А также занимаюсь системными процессами в Product & Tech департаменте. Delivery Lead в HeadHunter Организатор сообщества Delivery менеджеров в СПб. Приходите на наши митапы - https://t.me/delivery_community_spb Delivery Community SPB
Ключевая мысль. Системное управление зависимостями - один из ключевых процессов(!) повышения эффективности поставки ценности. Теория. Расскажу, что такое зависимости, как с ними работать, визуализировать и анализировать. Коротко, что будет в этом докладе и зачем вам его слушать. Практическая реализация. Поделюсь как мы обновили процесс работы с зависимостями в Jira и что нам это дало. З.Ы. На слайдах будет много текста. Можете не читать, самое главное я скажу словами, он нужен, чтобы все эти знания можно было получить только по презентации, без моего голоса. Презентацию я выложу в открытый доступ после митапа.
© Илья Смирнов
UpStream DownStream Точка принятия обязательств Problem Discovery Solution Discovery Solution Delivery Post Production Опцион Коммитмент Feature Feature Feature Feature Feature Feature Feature Feature Feature
Разный контекст. В интеллектуальном труде поставка каждого рабочего элемента происходит в отличном контексте, стек, legacy, экспертиза… Разные зависимости. В процессе работы над задачами сервисы будут сталкиваться с разными проблемами, которые будут блокировать их работу. Коротко - в интеллектуальном труде нет двух одинаковых работ. Разное время поставки. В конечном счёте, это будет приводить к тому, что все задачи решаются за очень разное время, которое может отличаться в разы, а не в пределах некоей небольшой погрешности в несколько процентов. Это делает невозможным аналоговое и параметрическое прогнозирование времени поставки готовой для клиента ценности.
Внутренние зависимости. То, что находиться в зоне влияния сервиса и может быть решено им самостоятельно и независимо от других сервисов. Типичные примеры: Отпуска, DayOff, больничные, праздники Переключения на более важные работы Узкое горлышко внутри сервиса (Ждём своего QA) Внешние зависимости. То, что находится за пределами влияния сервиса и не может быть решено самостоятельно. Типичные примеры: Функции - Юристы, Служба безопасности, бухгалтерия Сервисы - Другая команда внутри общей бизнес-линии Организации - Подрядчики, контрагенты, поставщики Заказчик… Все зависимости с которыми сталкиваются сервисы поставки делятся на два типа “по принадлежности” :
FS (Finish -> Start). Пока не будет устранено препятствие - невозможно начать работы, перевести задачу из буфера на следующий этап. FF (Finish -> Finish). Пока не будет устранено препятствие - невозможно закончить работы, перевести задачу из активного статуса в буфер. Также зависимости деляться по тому блокируют они начало работ или окончание работ : Solution Delivery Solution Discovery Discovery :: In Progress Discovery :: Done Delivery :: In Progress Delivery :: Done FS FF
Позволяет выявлять зависимости. Обычно вы будете слышать - “Ничего, мы работаем”. Но если это любой другой ответ, это потенциальная зависимость. В фокусе поставка - а не загрузка людей. Мы не концентрируемся не на том, кто чем занят, не утилизируем ресурс. Мы фокусируем команду на поставке ценности по конкретной задаче. “ Что нам мешает подвинуть эту задачу правее? ” © Джейсон Стэтхэм
В виде связи. Если препятствием является уже существующая в вашей система задача (редкий кейс) - эти работы нужно связать через связь с типом “блокирует”. В виде блокера. Если препятствие не является уже существующей задачей - рекомендуем вам создать отдельный проект “Blockers” в вашем таск трекере и заводить туда “Блокеры” о которые спотыкаются ваши задачи. Чтобы визуализировать факт зависимости, её сначала нужно зафиксировать
На доске. Даже беглый взгляд на доску должен давать понять, что та или иная работа - заблокирована. Физ доска - повесьте красный стикер поверх Jira - “Поставьте задачу на флаг” Другой таск трекер - покрасьте стикер в красный Уведомления. Если у вас есть стейкхолдеры, заказчики или иные лица которым важны эти работы - пришлите им автоматическое уведомления о блокировке в том формате, который будет им удобне. Теперь, все вокруг должны узнать, что ваша работа заблокирована
No Blame. Принимаем препятствие с которым столкнулись как данность, никого в этом не обвиняем. Пытаемся изменять систему, чтобы в ней больше не было таких проблем. Локус контроля. Отталкиваемся от возможностей нашего сервиса, нашей команды, что можем сделать мы. Внутренние зависимости - сами меняем правила своей работы. Внешние зависимости - эскалируем. “ Что мы можем сделать, чтобы больше не сталкиваться с такими препятствиями? ” Выделение типов. Наиболее частые причины блокировок стоит выделять в “типы” и присваивать их на обзоре сервиса поставки. Чтобы в последствии мы могли проводить анализ на их основе.
Локальные оптимумы. Есть ли “низко висящие фрукты” в сервисах или пора задумываться о системных изменениях? “ Соотношение количества внутренних и внешних зависимостей ” поможет ответить на этот вопрос. Условно, если 75+% зависимостей - внутренние, наверное рано говорить про локальные оптимумы… Проблемные этапы. У нас проблемы с Discovery или Delivery? Метрики: “ Соотношение кол-ва блокировок по этапам ” “ Соотношение длительности блокировок по этапам ” Помогут ответить на этот вопрос с помощью данных, а не ощущений. По мере работы с зависимостями начнёт копиться статистика, её анализ позволит найти системные проблемы и точки роста. Узкие горлышки. Какие самые проблемные точки в нашей системе? “ Соотношение блокировок по типам ” которые мы выявляли на обзоре сервиса поставки - поможет с ответом на этот вопрос. Это и есть, “та самая” кластеризация.
Время блокировок. А как много времени вообще задачи ждут в блоке ? Вы точно столкнётесь с таким вопросом. Метрики: “ Общая длительность блокировок за период ” “ Средняя длительность блокировки ” помогут в этом разобраться. Эти показатели хорошо бы отслеживать в динамике. Частота блокировок. Общее количество блокировок мало о чём говорит, этот показатель надо смотреть как “ Соотношение пропускной способности и кол-ва блокировок ” Например 25% от всех задач - имели зависимости, это - понятный ответ. Важно не только проводить анализ системы за некий выбранный период, но и следить за динамикой во времени. Хорошая динамика : Средняя длительность блокировок снижается, частота блокировок снижается, становиться больше внешних зависимостей. Ну и наоборот Плохая динамика : Средняя длительность растёт, частота растёт, становится больше внутренних зависимостей.
Типы внутри этапов. Выделите отдельные типы блокировок для каждого этапа поставки и работайте над эффективностью поставки каждого этапа независимо. Общее / частное. Частностность типов можно разложить по сервисам поставки. Например, что этот тип зависимостей встречается только в 20% сервисов, а другой в 90% и возможно, это общая для системы проблема, которую нужно решать сообща. Упороться в анализ блокировок можно очень глубоко, чаще у вас будут более очевидные источники проблем, но если вы их всё же исчерпали, то: Антирейтинги и SLE. СПОРНО. Вы можете выявить сервисы и команды, у которых частотность и длительность блокировок значительно выше, чем у других и поработать над этим.
Флаг. Задача считается заблокированной, если она “поставлена на флаг”. Флаг ставится прямо с доски через контекстное меню по клику ПКМ на карточку задачи. Автоматизация блокировки. На триггер постановки флага в проекте с продуктовыми фичами завязана автоматизация, которая создаёт задачу в проекте “Blocker” и линкует её с заблокированной. Как работал наш процесс в Jira раньше: Автоматизация разблокировки. По клику на “Remove Flag”, триггерится автоматизация которая ищет связанную задача в проекте Blocker в активном статусе и двигает её в Done. Рассчёт времени. Время блокировки считается как время задачи “блокера” в активном статусе.
Типизация не ведётся. У задач типа “блокер” есть типизация, но её заполняются в 0,2% случаев заведения блокеров. “Просто добавить” поле на экран установки флага - нельзя. Задачу закрыли - блокер нет. Блокировка не имеет никаких ограничений на передвижение задачи по статусам. По этому регулярны случаи, когда фича уже закрыта, а её блокер все ещё не нет. Начали более плотно заниматься Data Driven и поняли, что с данными беда… Не метчится с реальностью. Блокировки заводили не в момент появления зависимости, а в момент “Когда менеджер спросил”. Между этими временными точками иногда разница в пару часов, а иногда узнаём о том, что блокер вообще был постфактум, на обзоре сервиса или Operations Review…
Самое главное что нам было нужно - это получить 100% заполняемость типа блокировки. Для этого это поле нужно было сделать обязательным. А это можно сделать, если его заполнять при передвижение (transition) задачи. Благо, в Jira появились переводы, которые не изменяют статус. Мы добавили перевод “Блокер”
При использовании этого перевода появляется форма в которой “Тип блокировки” - это обязательное для заполнение поле.
После того как форма заполнена, происходит следующая магия: Создаётся задача. В проекте Blocker c выбранным типом блокировки и привязывается к заблокированной Устанавливается флаг. Чтобы заблокированная задача выделялась на доске Пишется комментарий. Чтобы все причастные получили уведомление Признак блокировки. Скрытое не редактируемое людьми поле “Is_Blocked”. На него делается проверка по доступности передвижения Копируется дата. Если дата начала была не заполнена - устанавливается now(). Если дата начала > now() - признак не ставится Если дата окончания < now() - блокер закрывается и признак не ставится CRON. Раз в сутки мы проходимся по не закрытым блокерам, и если у них дата начала блокировки = today() - то автоматически блокируем связанную задачу.
Теперь когда задача заблокирована, её обязательно придётся вручную разблокировать чтобы закрыть. Чтобы снять блокировку тоже отдельный переход.
В этот момент также появляется форма с аналогичным набором полей. Если в ней ничего не выбирать, то в блокере всё останется как есть, но можно перезаписать прежние значения, может мы синкаемся и снимаем блокер сейчас, а фактически над фичёй возобновили работу несколько дней назад?
Типы указываются. Повысили конверсию заполнения поля “Тип блокировки” с 0,2% до 100%. Теперь начинаем понимать, с какими проблемами системно сталкиваемся в поставке. Сначала закрыли блокер. А только потом что-то там делаем с задачей. Больше нет брошенных блокеров которые копят время бесконечно. Ожидаемые бенефиты по корректным данным Метч с реальностью. В зависимости фиксируется реальный промежуток времени, когда поставка была заблокирована.
Блокеры в будущем. Команда едет на конференцию? Супер, как только узнали, можно заранее поставить блокеры, что с такого по такое число над задачей работать не будут. При наступление даты задача автоматически заблочится. Блокеры в прошлом. Вспомнили о конференции только на обзоре сервиса поставки? Не проблема, можно поставить блокер “постфактум”. Дополнительные бенефиты за счёт этого изменения: Прозрачность. Из автоматического комментария к задаче всем сразу понятно, что произошло с задачей, на что заблочилась, когда ожидать разблокировки… Простота анализа. Не требуется плагин Time in Status или аналог для анализа. Делается обычная выгрузка в csv с полями начала и окончания блокировки, из даты окончания вычитается дата начала, вуаля. Можно автоматизировать и считать в отдельное поле при закрытие блокера.
Этот процесс можно дальше развивать, мы выделили следующие идеи Связь с другими работами. При блокировке добавим в форму поле для явного указания, на какую задачу которая уже есть в Jira заблочились. Можно будет смотреть, на эффективность потока работы с блокерами - соотносить время блокировки и время решения зависимой задачи. Масштабирование. На другие типы задач и функции департамента. Дополнительная коммуникация. “Эта задача заблокирована уже более 3 недель, может пора уже что-то с этим сделать?”... З.Ы. Ну и поделиться с вами ценными изменениями которые мы за счёт работы с зависимостями нашли.
