Привет! Меня зовут Егор Стремоусов, я тимлид команды продуктовых дизайнеров платформы TWork Обслуживания в Т-Банке. Расскажу, как моя команда повысила предсказуемость поставки дизайн-задач, какие методы и инструменты мы для этого использовали.
Дисклеймер. В статье делюсь опытом, который получил с моей командой в начале 2024 года. На момент публикации и в ретроспективе последних 18 месяцев предсказуемость работы команды продолжает планомерно улучшаться. Это еще раз подтверждает эффективность подходов.
Контекст и проблематика
В нашей команде семь дизайнеров, мы работаем с 10 продуктовыми командами TWork Обслуживания. Под нашей неустанной заботой — все операторские интерфейсы, при помощи которых коллеги решают проблемы клиентов банка по телефону, электронной почте и в чатах.
Каждый дизайнер в команде работает над одним или более продуктами в тесной связке с продактом и бизнес-аналитиками. Он глубоко вовлечен в процессы продуктовых команд: разрабатывает макеты и прототипы, участвует в синхронизационных встречах, подключается или инициирует исследования, контролирует качество реализации в коде, следит за влиянием на продуктовые и бизнес-метрики и участвует в других активностях.
Мы работаем, используя канбан-систему: у нас нет итеративного планирования, а задачи на дизайн поступают в наш поток выполнения постоянно. По статистике, мы завершаем от 20 до 30 задач в месяц.
Львиную долю из них занимают новые фичи, которые в трекере задач мы обозначаем как New Feature, и улучшения существующей функциональности — Improvement. Реже выполняем задачи по концептуальному проектированию (Idea) и проведению исследований (Research).
При этом время выполнения отдельных дизайн-задач носило непредсказуемый характер. Отслеживая статистику в трекере задач, я видел, что команда могла закрыть задачу как за пару дней, так и за две недели или за три месяца. Отдельные задачи занимали до 100 дней!
Такой подход к работе не устраивал продуктовые команды. Потому что от своевременного выполнения наших обязательств зависят планирование дальнейших шагов и сроки появления инкрементов ценности в наших продуктах. В частных беседах продакты регулярно просили повысить предсказуемость поставки дизайна.
Анализируя этот запрос, я пришел к выводу, что для его выполнения и повышения эффективности команды мне нужно совмещать экспертную оценку происходящего с анализом процессных метрик и начать использовать data-driven-подход в управлении на полную мощь. Процессные метрики более объективны, а их применение позволит мне улучшать процессы с более точным целеполаганием и результатом.
Lead Time и предсказуемость поставки
Давайте разберемся, что такое предсказуемость поставки. Для этого нужно сначала рассмотреть одну из ключевых метрик канбан-системы — Lead Time.
Lead Time — это время выполнения задачи от точки принятия обязательств до их исполнения в точке завершения работы.
В нашей команде точка принятия обязательств и начала работы не совсем классическая и находится между статусами Planned, когда аналитик полностью описал дизайн-задачу, и Specification — дизайнер взял задачу в работу и анализирует полноту постановки. Завершение задачи — статус Done.
Между точкой начала работы и завершением типовая задача проходит череду рабочих статусов: Specification, To Do, Hold, Design, Customer Review и Design Review.
Предсказуемость, в свою очередь, — это характеристика распределения времени Lead Time для выделенной группы задач за анализируемый период.
Мы определяем ее как соотношение 98%-го процентиля к 50%-му процентилю Lead Time за выбранный период. Возможны варианты, когда предсказуемость определяется соотношением других процентилей: 95 к 50% или 85 к 50%. Это зависит от того, насколько жесткую шкалу предсказуемости вы хотите использовать.
Предсказуемость = LT(98%) / LT(50%)
Если полученное соотношение меньше или равно 5,6 (такой ориентир мы выбрали в нашей компании), то поставка считается предсказуемой. Иначе поставка непредсказуема, а риски команды велики.
Чтобы влиять на предсказуемость, в первую очередь надо научиться влиять на Lead Time. Но перед этим стоит определить, а каково значение этой метрики в текущий момент? Может, с ней все хорошо и влиять на нее и не нужно?
Для удобства анализа процессных метрик в компании разработан сервис «Т-Метер».
Ежедневно в Т-Метер «проливаются» данные о задачах в Jira, после чего мы получаем возможность анализировать их в виде графиков, таблиц и чартов и генерировать гипотезы по улучшению процессов.
Т-Метер помогает проводить ретроспективный анализ, моделирование и повышать прозрачность процессов. Он позволяет выявлять динамику спроса, находить точки улучшения, анализировать качество поставок, определять сроки выполнения задач и проектов и многое другое.
Этот инструмент особенно полезен для решения проблем в управлении, таких как неэффективные процессы, недостаточная видимость и риски качества, которые могут приводить к задержкам и снижению ценности проектов.
Используя готовые шаблоны, разработанные коллегами, я за полчаса настроил дашборд и получил возможность оценить Lead Time и другие процессные метрики нашей команды.
Подтверждение проблемы
Предсказуемость поставки в нашей команде до начала изменений выглядела следующим образом.
С октября 2023 по январь 2024 мы регулярно выходили за нормаль предсказуемости 5,6 по любой из методик расчета.
График динамики изменения процентилей Lead Time за тот же период также говорил о том, что система идет в легкий разнос, а вместе с этим снижается предсказуемость нашей поставки.
Чем дальше друг от друга находятся точки линий процентиля Lead Time, тем менее предсказуемо команда выполняет задачи. Особенно смущали растущие тренды для 85%-го и 95%-го процентиля.
Спектральная диаграмма Lead Time подтверждала этот факт в статике. На ней виден «длинный хвост», то есть какое-то количество задач, которые мы делаем слишком долго. На графике они находятся правее и выбиваются из более предсказуемой левой части.
Я провалидировал наличие плохой предсказуемости статистикой. Далее предстояло самое интересное — исправить сложившуюся ситуацию.
Алгоритм повышения предсказуемости
Канбан-метод — метод улучшения процессов. В рамках применения метода мы решили использовать активное обсуждение в режиме реального времени и создание среды с полной прозрачностью рабочих процессов.
Поскольку мы уже работаем по этому методу, логично использовать для улучшения процессов принципы сервисной парадигмы, которые он поддерживает:
Определить потребности и ожидания заказчика. Продуктовым командам, для которых мы выполняем сервисную функцию, важна предсказуемость поставки с сохранением качества. Для нас это ключевая метрика при улучшении процессов.
Управлять работой, дать людям организоваться вокруг нее. Общий инструментарий в виде канбан-доски реализован через таск-трекер. Контроль за работой можно было вести через метрики канбан-метода, визуализированные с помощью сервиса «Т-Метер».
Развивать правила, чтобы улучшить показатели. Используя практику выдвижения и проверки гипотез улучшения процессов, проводя улучшения итеративно, мы можем закреплять хорошо работающие правила и отказываться от неэффективных.
Первые два принципа уже были сформированы и внедрены в работу. Основной вектор приложения усилий я видел в изменении и развитии правил работы.
Для выработки новых или изменения существующих правил работы я определил итеративный алгоритм действий:
Анализ задач, которые попадают в «длинный хвост» спектрального распределения Lead Time.
Определение причин увеличения Lead Time в этих задачах, группировка причин в паттерны.
Создание гипотезы нового правила работы, которое поможет устранить причину роста Lead Time.
Проверка гипотезы на практике: работа команды по новому правилу.
Анализ результатов, подведение итогов и принятие решения об эффективности гипотезы.
Возврат к пункту 1.
Повышение предсказуемости заключается в уменьшении дисперсии разброса по Lead Time. На эту метрику у нас влияло несколько факторов: формат работы над дизайном, вектор развития продуктов, рост и перестройка процессов в продуктовых командах и многое другое.
Условно эти факторы можно разделить на две группы:
Внутренние — наш формат работы, процессы в команде, правила работы в потоке выполнения задач. То, что находится в прямой зоне влияния нашей команды и что мы можем улучшить самостоятельно, без выхода в надсистему.
Внешние — процессы и факторы вне контура нашей команды, на которые не всегда можно или трудно повлиять. Это процессы межкомандного взаимодействия, изменение которых требует больше времени и усилий.
В первой итерации улучшения процессов лучше начинать с внутренних факторов. Это «низко висящие фрукты», которые могут привести к быстрым победам.
Поэтому я сосредоточился на улучшении работы внутри нашего потока выполнения задач. И для начала проанализировал аномалии в статистике, которые легко увидеть даже при беглом осмотре метрик в Т-Метере.
Блокировки
Первичный анализ долгих задач и логика подсказывали, что, если у задачи большой Lead Time, в ходе ее выполнения есть статусы, в которых она регулярно подвисает.
График времени нахождения задачи в статусах говорил о том, что аномальный по длительности статус в нашем процессе — Hold.
Как правило, мы переводили задачи в Hold из-за блокировки со стороны постановщика, смежных департаментов или партнеров. Мы отправляли задачу на паузу и ждали ответа. При этом либо ответ затягивался, либо про задачу забывали, либо вовсе могли отменить, не сообщив нам.
Основная гипотеза звучала так:
Если мы сократим время нахождения задачи в статусе Hold, мы сократим ее Lead Time и повысим предсказуемость поставки.
Для сокращения задержек задачи в статусе Hold я ввел несколько новых правил работы.
Флаг блокировки вместо статуса Hold. Я убрал колонку Hold с нашей канбан-доски. Вместо этого дизайнер должен отмечать задачу флагом блокировки и добавлять к нему комментарий с причиной этого.
Это дало нам не просто понимание, что задача зависла, но и:
знание, в каком статусе зависла задача непосредственно на канбан-доске;
причины блокировки, которые можно группировать по паттернам и анализировать;
возможность вести реестр блокировок и вырабатывать улучшения в правилах работы, направленные на устранение причин блокировки.
Политика нетерпимости к блокировкам. Если раньше дизайнер «отдавал мячик» на сторону блокиратора и спокойно ждал ответа по задаче, теперь он обязан спрашивать у него точную дату ответа (дату разблокировки) и фиксировать ее в комментариях вместе с причиной.
Мы просим коллег, от которых зависит снятие блока, давать обязательство по времени исполнения их обязательств. Многих это очень дисциплинирует. Такая политика помогает оживить процесс работы над зависшими задачами. Мы держим руку на пульсе и стремимся избавиться от блокера как можно скорее. При крайней необходимости можем эскалировать проблему выше по оргструктуре.
Реестр блокировок — инструмент ретроспективы и оперативной работы с действующими блокировками.
В реестре все блокеры записываются в отдельную табличку, в которой указываются:
длительность блокировки;
ответственные лица;
причина и ее паттерн («группа зависимости»);
статус для оперативного трекинга и контроля.
Причины блокеров анализируются на предмет общих паттернов, а для паттерна вырабатывается решение: как сделать так, чтобы блокеры такой категории не возникали в будущем.
Ретроспектива потока
Я ввел регулярную каденцию «Ревью потока», чтобы сделать ретроспективный анализ постоянным.
Каждые три месяца на «1-2-1» я обсуждаю с дизайнером все его долгие задачи за прошедший период, Lead Time которых превышает порог в 10 дней (примерно 50%-й процентиль, согласно статистике нашей команды).
На этих встречах мы ретроспективно вспоминаем и озвучиваем истинные причины задержек и, что самое главное, вырабатываем и фиксируем новые правила работы, чтобы избегать аналогичных ситуаций в будущем.
Вот примеры правил, которые мы проверили за последнее время и которые дали эффект в нашей команде:
Статистика. Правильно определяем тип задачи и своевременно двигаем ее по канбан-доске. Статистика важна для корректного анализа данных и принятия последующих решений.
Планирование и декомпозиция. Вместе с постановщиком декомпозируем задачи-монстры (как правило, эпики и проекты) на более мелкие задачи, несущие ценности.
Разбиваем работу над новым проектом на этапы: исследования, концепты, проработку дизайна и так далее. Каждому этапу — отдельная дизайн-задача. Мы не делаем все подряд в рамках одной задачи.
Спецификация задачи. Тратим больше времени на этап спецификации и анализа входящей дизайн-задачи до или сразу после точки принятия обязательств (на самом деле чем раньше, тем лучше).
Дизайнер проверяет постановку от аналитика по общему чек-листу. Наша гипотеза заключается в том, что чем больше времени мы тратим на анализ задачи и устранение ее неопределенности, тем быстрее она будет сделана и тем меньше будет ее итоговый Lead Time.
Экспертная оценка. Если в дизайн-задаче не учтена, например, экспертная оценка разработчиков ее технической реализуемости, повышается риск блокировки этой задачи на последующих этапах.
Поэтому требуем от продуктовой команды привлечения к анализу будущего инкремента разработчиков, инфобез и системных аналитиков на самых ранних этапах.
Самоорганизация. Если дизайнер берет в работу слишком много задач, часть из них будет простаивать, поскольку ресурс исполнителя не безграничен.
Другие негативные факторы при одновременном выполнении слишком большого числа задач: потеря фокуса, «транзакционные издержки» при переключении между задачами и большое число отвлекающих коммуникаций.
В качестве инструмента самоорганизации надо использовать лимиты на одновременное количество задач в потоке. Например, не брать в него следующую задачу, пока в потоке есть уже три-четыре задачи, независимо от их статуса.
Для каждого дизайнера этот лимит индивидуален, зависит от грейда и опыта, является выражением баланса между максимальной производительностью и количеством задач в работе.
Новые фичи. Особое внимание по всем перечисленным выше пунктам уделяем задачам с типом New Feature, для которых время выполнения менее предсказуемо по сравнению с другими типами.
Новая фича представляет собой бо́льший объем работ, который трудно за короткое время обработать как дизайнеру, так и команде на последующих этапах.
Долгая задача содержит в себе и бо́льшие риски. Объемный инкремент функциональности, доставленный пользователю за один раз, может:
не попасть в потребности пользователей и не оправдать заявленную ценность;
привести к некорректным результатам тестирования и откату всей фичи.
Ситуацию осложняет и то, что новая фича содержит гораздо больше неопределенности, чем улучшение. Добавить еще одну кнопку в готовый блок понятнее и проще, чем сделать функциональность, которой ранее не было.
Чистый бэклог
Параллельно ретроспективе потока я обнаружил, что в нашем бэклоге есть большое количество неактуальных задач.
За пару последних лет там накопилась масса устаревших и забытых планов. Проведя мягкую актуализацию (я просил аналитиков и продактов самостоятельно переводить в статус Trashed свои тикеты), мы сократили бэклог на 100+ задач.
Сокращение бэклога не дало существенного эффекта для повышения предсказуемости поставки, но это был повод еще раз синхронизироваться с продуктовыми командами по планам, да и в целом дышать стало легче.
Как показывает практика, дизайн-задача в бэклоге за три-четыре месяца без изменений теряет актуальность и корректность постановки. Для отслеживания таких задач я сделал специальный фильтр в Jira и ввел в команде совместную практику их проверки на актуальность.
Внедрение правил
Любые изменения в правилах работы команды сопровождаются определенным сопротивлением и имеют отложенный эффект, поскольку трансформации в социальных средах довольно инертны.
Тема внедрения изменений широка и выходит за рамки этой статьи. Отмечу только, что от начала изменений до достижения удовлетворительных результатов в улучшении предсказуемости поставки у нас ушло порядка шести месяцев.
Результаты
Описанные новые политики и изменения в процессах работы дали свои плоды. Несмотря на нестабильные внешние факторы, предсказуемость поставки существенно выросла и приближается к хорошим показателям.
Продуктовые команды стали получать результат нашей работы более предсказуемо и без потери качества. Дизайнеры в моей команде отмечают, что даже на субъективном уровне оценки работать стало проще и прозрачнее.
В 2025 году предсказуемость продолжает расти. Если посмотреть на график последних 18 месяцев, можно увидеть, что положительная динамика в виде нисходящего тренда сохраняется.
Идеальных процессов не существует, но к ним можно и нужно стремиться. Мы продолжаем работать над улучшением наших процессов и итеративно, в режиме эксперимента, ищем новые способы улучшения правил работы.
Все в ваших руках
В Т-Банке есть замечательные люди, которые занимаются улучшением процессов под заданный контекст, — деливери-менеджеры. Но их ресурс не бесконечен, а многие процессы тимлиды могут улучшать и самостоятельно.
Я верю, что руководитель любого уровня должен разбираться в доставке ценности, быть сам себе деливери-менеджером или частично выполнять его функции.
Начните анализировать ваши процессные метрики и изучать ваши процессы объективно. Улучшайте и формируйте новые правила работы итеративно, методом выдвижения и проверки гипотез. Наберитесь терпения, анализируйте и рефлексируйте.
Неравнодушие к процессным метрикам потока и проактивная дизайнерская позиция по улучшению всего, до чего можно дотянуться, — залог не только эффективной работы, но и комфорта вашей команды.
Рекомендованные материалы
Для более глубокого погружения в тему улучшения процессных метрик и повышения предсказуемости поставки рекомендую изучить следующие ресурсы:
Как прогнозировать время выполнения задач? Методики прогноза
Стимулирование эволюционных изменений с помощью канбан-метода
Illustrated Essential Kanban Codenced Notebook, Kanban Univercity
Спасибо
Хочу выразить благодарность деливери-менеджерам, которые помогали мне в работе и отвечали на вопросы: Оле Захаровой, Тамаре Рогачевой и Денису Вайткусу. А также Павлу Ахметчанову — за ценные советы и уроки.