Как оценить эффективность IT-команд и с умом задебажить процессы
Привет, Хабр! Это Оля Муттер, руководитель IT-проектного офиса в Купере (ex СберМаркет). Жизнь заставила меня научиться настраивать процессы как боженька. Я стартовала карьеру в роли бизнес-аналитика, доросла до директора продукта в финтехе, успела побывать наставником для проджектов, создать несколько проектных офисов и центров компетенций — всего за десять лет.
Сейчас я рулю проектным офисом в Купере (ex СберМаркет) — это 1300+ человек в IT-команде. Как понять, работает ли такая большая система эффективно? И что делать, если какая-то веточка этого гигантского дерева растет не в ту сторону? Об этом моя сегодняшняя статья.
Спойлер: надо дебажить процессы, а для этого придется много работать с цифрами и общаться с людьми. За это у нас в компании отвечают delivery-менеджеры.
Самые важные метрики
Как понять, эффективно ли настроены процессы в компании?
Для начала я бы посоветовала собрать следующие метрики на основе данных о работе ваших команд:
Lead time — время от точки принятия обязательств, когда мы сказали «Мы это сделаем», и до момента, когда эти изменения стали доступны нашим пользователям.
А также время на отдельные этапы работы.
Cycle Time — это Lead Time, разделённый на этапы. Для качественного планирования полезно знать, сколько времени занимает каждая часть процесса.
Всегда есть соблазн просто подкрутить Lead Time и сказать: «Раньше мы поставляли 5 проектов за 60 дней, а теперь поставляем за 10». Но как это влияет на здоровье бизнеса: крепнет оно или ухудшается?
Чтобы понять это нужно обратить внимание и на контрметрики.
Объем поставки (Throughput) — объем работ, поставленный за определенный период времени, который несет конечную ценность для пользователей. Измеряется в количестве выполненных задач или реализованных фич.
Точность поставки (Delivery on date) — процент проектов, которые завершаются в ожидаемый срок.
Эффективность потока (Flow Efficiency) — как эффективно проходят задачи или элементы процесса через систему. Оценивает время, фактически затраченное на выполнение задачи, по сравнению со временем, когда задача находилась в активной обработке.
Что делать с цифрами
Если вы собрали метрики и довольны результатами на 100%, то читать дальше не обязательно :) Но по опыту в крупных компаниях, заточенных на рост и развитие, так не бывает. Даже при достойных показателях, чтобы оставаться конкурентоспособной, компания должна совершенствоваться. Для этого существует замечательный инструмент — анализ цепочки поставок.
Он представляет собойоценку каждого этапа поставки ценности до конечного пользователя, то есть всех процессов, из которых состоит производство вашего продукта или предоставление вашей услуги.
Представьте людей, которые передают по цепочке мяч.
Почему посередине у кого-то были заняты руки и он пропустил пас?
Почему кто-то отошёл, когда должен был принять и передать его дальше?
Или передал так быстро, что следующий человек не успел среагировать?
Именно на такие «почему» отвечает анализ цепочки поставок. Он позволяет понять, какие проблемы возникают на каждом этапе работы и как они влияют на метрики.
Дальше я подробно расскажу, как грамотно провести такую оценку.
Анализ цепочки поставок по шагам
#1 Определяем уровни системы и количество оцениваемых элементов
С точки зрения структуры мы делимся на домены. Внутри них выделяется по несколько юнитов, а внутри юнитов — по несколько команд.
Если вы хотите полностью оценить процесс на уровне компании, лучше всего взять за единицу анализа юнит. Создаём роадмап и обозначаем, когда планируем оценить каждый из юнитов. Приоритизацию можно сделать на основе собранных метрик, где больше выбросов или показатели сильно выше таргетов.
#2 Готовим шаблон
Стартовый шаблон может выглядеть так:
Дальше скелет обрастает мясом:
Кто ответственный на каждом этапе?
Какие проблемы могут возникнуть на каждом этапе?
Что представляет из себя результат каждого этапа?
Какие метрики мы собираем на каждом этапе?
#3 Собираем метрики
Дальше начинается самое интересное. В юните, скажем, пять команд. В каждой команде есть продакты, тимлиды. Нужно не только назначить встречу, но и подготовить всех: рассказать, зачем это всё необходимо и какой результат мы ожидаем. Нельзя влететь с ноги и сказать: «Всё, идём оценивать цепочку». Поэтому важно настраивать доверительные отношения со всеми командами заранее, либо же в начале встрече снять все опасения и боли.
#4 Готовим почву под долгий созвон с важными участниками
Предупреждение, чёткая цель, планируемый успех. За кадром — надежда, что хоть кто-то придёт на мою фан-встречу:
#5 Ставим встречи в календарь
И, соответственно, проводим! Предлагаем план встречи в пяти частях.
1. В самом начале строим мостик. Люди должны понимать, что речь не о далёком будущем и не о том, чтобы просто повесить на них ещё один отчётик. Не забывайте о цели — понять, что происходит прямо сейчас в конкретных командах.
2. Дальше мы, естественно, расставляем тайминги. Время каждого сотрудника ценно, да и вряд ли кто-то выдержит встречу, которая затянется больше чем на два часа.
3. Начинаем собирать мнения и при этом транслируем открытость и доверие. Мы не навязываем решения, а выявляем и записываем проблемы. Разумеется, если у кого-то есть идеи преобразований, это надо записать и включить в фоллоу-ап, но всё же мы собираемся не за этим.
4. Вовлекаем всех участников. Желательно распределить время так, чтобы высказались все, кто участвует в доставке продукта. Пусть сначала активно включаются продакты, а тимлиды подсказывают, что они заметили. Потом, наоборот, активно включаются тимлиды, а подсказывают продакты. Так не нарушается динамика встречи.
Собирать продактов и тимлидов по отдельности — не вариант. Это размывает анализ, не даёт получить полную картинку, а нам нужно собрать максимум проблем и максимум статистики.
5. Обязательно определяем so what. Можно бесконечно долго проводить подобные встречи, чтобы все пожаловались, получили моральное удовлетворение и выдохнули, но какой будет прок?
Нормально, если вы не знаете, что будете делать с полученной информацией, когда идёте на первую встречу. В этом случае тоже можно дать прозрачную обратную связь: «Ребята, вы первый юнит, с которым я общаюсь. После вас я пообщаюсь со всеми остальными и тогда уже смогу вернуться и сказать, сколько у нас проблем, решаемы ли они и что можно сделать». Такая искренность заряжает людей, потому что они понимают, что встреча с ними будет особенно ценной для всего анализа.
#6 Фиксируем и кластеризуем всю информацию
Вот мы провели анализ цепочки поставок по пяти юнитам одного домена, сделали красивую доску в Miro. Куда с этим идти? Явно не к вице-президенту. Эта информация нужна прежде всего нам, проектному офису.
Если мы действуем на уровне компании, то нужно менять не конкретные команды или даже юниты, а вводить системные улучшения, которые уменьшат общий Lead Time без потери в Throughput и Value. Соответственно, после общения со всеми юнитами одного домена мы идём в другой, потом в третий и т. д.
Когда у нас будет информация по всем доменам, её нужно кластеризовать. В кластер входят все проблемы одного типа. Целесообразно брать только те проблемы, которые значительно влияют на метрики. Помимо проблем и влияния, важно прописать ответственных и возможные решения.
Допустим, мы выяснили, что средний объём поставки у одного юнита без потери Value — не более четырёх проектов в месяц, но многие юниты берут и восемь, и 16, а то и 32. То есть сотрудники явно переоценивают свои силы. Мы выделяем кластер «Планирование работ», заводим туда проблему «Смещение фокуса и частые переключения». Влияние: -10% к эффективности. Ответственность берём на себя как на проектный офис. Решение: внедрение WIP-лимитов, то есть ограничений по количеству проектов и задач, при верхнеуровневом масштабировании.
Могут быть проблемы, которые вы в принципе не способны решить. Например, если они связаны с внешним влиянием. Но чётко понимать свои ограничения и их роль — тоже важно.
#7. Прописываем действия
Все действия нужно разделить на проактивные, которые можно предпринять прямо сейчас, и на системные улучшения.
Проактивные действия:
• Работа с блокерами. Если вы ведёте какие-то проекты в Jira и не пользуетесь флагированием, рекомендую взять на заметку. Это даёт большой объём данных о том, почему работа зависает, в дополнение к ретроспективам.
• Расчёт предиктивного Lead Time.
• Нотификации. Много. Мой проектный офис даже работает над специальным сервисом для нотификаций. Иначе командам приходится изучать огромные дашборды, чтобы узнать, что Lead Time улетел в космос.
Системные улучшения, в свою очередь:
• Приоритезация проблем на основе влияния. Что хуже всего сказывается на бизнесе?
• Поиск ответственных.
• Выявление решений.
За планом действий идут сами действия. Важный совет: системные улучшения нельзя проводить резко, они ведут за собой непомерные скачки нагрузки. В случае каждого такого улучшения я рекомендую для начала провести пилот на одной команде. Так вы сразу увидите, что может пойти не так, и лишний раз задумаетесь, действительно ли это нужно компании.
Кто проводит системные улучшения?
У нас в компании за это отвечает направление delivery менеджеров, о них рассказывала в своей статье про проектный подход. Они выявляет блокеры на всем процессе доставки ценности, внедряет системные улучшения и обучает команды.
Надеюсь, что вдохновила вас на анализ цепочки поставок;) Буду рада ответить на вопросы в комментариях.
Tech-команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
