Замеряем Cycle Time в команде дизайна или почему это не про «поругаться» на команду, чтобы работали быстрее?

Что такое Cycle Time в продуктовом дизайне, зачем он вообще нужен и почему это не про скорость сборки макетов. Рассказали лид продуктового веб-дизайна и менеджер-эксперт по развитию цифровых проектов T2.Digital.

Любая компания нацелена на то, чтобы выпускать свои крутые продукты на рынок как можно быстрее. И в этом деле важна скорость и производительность каждого этапа работы над продуктом. Сегодня расскажем про свой путь к замеру Cycle time команды продуктового дизайна, и про то, какие инсайты мы получили.

Cycle Time (далее по тексту CT) — это метрика, показывающая, сколько времени нужно кому-либо на решение задачи с момента ее появления до готовности. Иначе говоря, какова длина цикла работы над задачей.

Саму метрики мы считаем давно, но не всегда были в ней уверены, а еще у нас совсем не было автоматизации. Работая над автоматизацией измерения СТ и сопутствующих метрик, мы понимали, что будем искать в этих цифрах. Есть два варианта, чему может понадобиться лечение:

Второе лечится одновременно сложно и просто: выделением доп. ресурса. А вот у первого есть много развилок, и вы сами определяете, что именно поможет конкретно в вашем кейсе:

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

В конце прошлого года мы пошли на радикальные изменения в подходе к измерению СТ. Вот какие вопросы нам пришлось решить на «нулевом» шаге этого подхода:

1. Нужно четко договориться, что для вас «момент появления задачи», а что «готовность задачи». Для разных команд это могут быть разные отметки.

Например, для нас «момент появления задачи» — это время, когда заказчик принес задачу лиду дизайна на планирование. А «готовность задачи» — это время, когда она согласована по всем инстанциям и готова для передачи команде разработки.

2. Нужно быть технически готовыми к измерению СТ, иначе метрика будет грязной.

Например, если ваша команда все еще не вовремя двигает карточки в Jira, то у нас для вас плохие новости — ваш СТ может быть грязным и, как следствие, неправдивым. С таким СТ работать нет никакого смысла.

3. Нужно договориться, как вы будете считать и интерпретировать метрику, и какие у вас финальные цели измерения СТ.

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

Формула измерения СТ для нас:

СТ = ПЕРЦЕНТИЛЬ([выборка]; 0,75)

Почему перцентиль, а не среднее арифметическое? Потому что это позволяет нам откинуть выбросы и с уверенностью интерпретировать метрику так: «задачи такого объема в 75% случаев мы делаем за n дней».

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

Как мы к этому пришли, и как это работает? Сейчас расскажем.

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

Примерно 3 года назад мы отмечали время по задачам в табличке Excel. Там мы описывали, сколько у нас займет задача. В столбцах у нас были даты спринта. Мы отмечали, сколько часов потратили в тот или иной день на задачу и писали комментарии, что было сделано. Это было не очень удобно, на каждый спринт была отдельная страничка. И в какой-то момент их стало слишком много — нам стало трудно ориентироваться. А если задача не закрывалась за спринт (а такое бывает, и это нормально), было неудобно переносить ее на другую страницу и переоценивать.

Позже у нас появилась доска в таск-трекере со статусами задач, но их было очень мало: бэклог, doing (активная работа над задачей), согласование и закрытие. В целом, для верхнеуровневой декомпозиции СТ по этапам этого достаточно. Но нам казалось, что на таком уровне декомпозиции «мы и сами знаем, что у нас хромает». На доске мы могли вписывать, сколько времени планируем потратить на задачу и сколько фактически затратили. При этом мы все равно продолжали параллельно пользоваться Excel, для нас это было удобнее, привычнее. На тот момент мы не видели пользы в таск-трекере по сравнению с Excel. А еще давайте признаем, что все новое и непонятное внедряется с большим трудом, и нам просто не хватило мотивации.

Около года назад команда дизайна пришла к проджект-менеджерам за помощью по доске и отслеживанию этого самого CT. Тогда мы всерьез взялись за дело, и вот, что внедрили:

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

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

Это очень удобно и пол — мы регулярно собираемся, чтобы вместе поштормить над данными. В первых итерациях было очень интересно на цифрах увидеть то, что мы чувствовали интуитивно. У нас не сразу появилась декомпозиция СТ по этапам в дашборде. Вручную считать это было технически невозможно. Но нам сразу хотелось видеть, где еще задерживается задача, поэтому мы придумали хитрое решение. Мы внедрили регулярную активность в начале каждого месяца. Мы смотрим на СТ закрытых за прошлый месяц задач, по которым мы выбиваемся из референсного значения (и их, к сожалению, оказалось очень много). Как это было:

Во-первых, мы разделили задачи на 4 категории: s, m, l и xl. Категории присваивали задачам в соответствии с объемом списанного времени на них в часах. Категории в каждой компании (или даже каждой команде) могут быть свои. Вот, какие получились у нас:

Во-вторых, для каждой категории определили, сколько дней мы готовы сейчас заложить на задачу: от ее постановки заказчиком до финального согласования. Покрутив ретроспективные данные мы поняли, какие цифры для нас будут давать объективный срез. Важно, что те цифры, которые мы подобрали, были очень лояльными, потому что мы только делаем первый подход к этой активности. Вот, что мы взяли за основу:

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

По очень многим задачам команда веба выбивалась из референсных значений CT. Первая мысль — значит, на нашем этапе мы задерживаем всю остальную работу, хотя точно можем быстрее и эффективнее. И, казалось бы, уже пора бежать к команде и говорить «работайте быстрее, цифры должны быть меньше». Но не тут-то было. Ко всему надо подходить осознанно. Что мы и сделали.

Напомним, что у нас не сразу была декомпозиция СТ по этапам. Внутреннее «путешествие» задачи по статусам и столбцам на доске оставалось только у дизайнеров и лидов в памяти. А это не самый надежный источник, если мы захотим вспомнить, что было несколько месяцев назад.

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

Покопавшись в данных, мы выявили несколько причин, по которым cycle time дизайна выходил за пределы референсных значений:

Все это значит, что Cycle time гораздо более обширное понятие, чем «быстрая работа дизайнеров». Он про полный цикл проектирования интерфейса, а не только про то, сколько дизайнер «рисует» интерфейс руками. Поэтому бежать к команде за тем, чтобы поторопить с проектированием и ускорить работу, не всегда правильная стратегия.

Конечно же, ближайшие шаги — это поработать с теми зонами роста, которые мы нашли в процессе анализа. Давайте по пунктам.

Если вы переживаете за размер нашей доски, то не переживайте! Мы на том этапе, когда доска — наш подручный инструмент, и мы к нему уже привыкли.