0.53
1.4
Когда компании бронируют «людей», а не работу для команд, быстро всплывают типичные симптомы: перегрузка «звезд», простаивание редких ролей, вечные переназначения и конфликт приоритетов. В моем опыте roadmap дважды срывался: в одном квартале аналитика «перетягивали» между growth и регуляторикой — обе инициативы стояли, а «виноват» был человек; в другом — бэкенд «универсала» дергали на фаерфайты, и спринт превращался в бесконечную реактивщину. Итог — проседает качество, растет контекст switching, а бронирование ресурсов становится переговорной «битвой» без прозрачной приоритизации.
Практические сигналы для быстрого аудита: если у вас больше 15% задач переезжают между исполнителями за спринт, а реальный throughput системно ниже планового на 20–30%, вы бронируете по людям. Два быстрых шага уже завтра: 1) перестаньте менять исполнителя после старта слота без эскалации; 2) фиксируйте конфликт приоритетов как риск портфеля, а не «личную договоренность». 3) Проверьте подходит ли вам текущая система бронирования кабинета, возможно есть конфликты по рабочим местам.
Переход к стабильным командам и кластеризации спроса меняет игру: меньше переключений, выше пропускная способность, предсказуемые ожидания. Мы обещаем результат «команда ←→ кластер», а не «человек ←→ задача». В моих командах это дало +18–25% к throughput уже к третьему спринту и снижение незавершенного WIP на треть. Обещание формулирую так: «Команда А держит квоту X слотов по кластеру Growth в квартал с соблюдением SLA 90%+».
Критерии успеха просты и прозрачны: SLA соблюдаются (регуляторика — 95% в срок, growth — 85–90%), прогноз точнее (ошибка квартального прогноза ≤10%), а контекст switching падает (до 1–2 раз в спринт на роль). Два практических совета: 1) закрепите владельца кластера со стороны продукта и технического лидера со стороны команды; 2) публикуйте «обещание» команды бизнесу в виде публичной квоты слотов на период.
Команда — стабильная кросс функциональная единица, которая берет на себя слоты работы. Кластер — агрегат инициатив по единому признаку: бизнес цель, домен или регуляторика/риски. Слот — атом бронирования для команды: кусок работы среднего размера, который команда может завершить в пределах итерации или заранее оговоренного окна. Емкость команды — сколько слотов она может стабильно закрывать за период.
Простая формула емкости на итерацию: Емкость_слотов = (Доступные дни команды × Коэф. фокуса) / Средняя трудоемкость слота. Пример: 6 человек × 8 доступных дней × 0,7 фокуса ≈ 33 «человеко дня». Если один слот ~5 «человеко дней», команда берет 6 слотов на спринт. WIP лимит — максимально допустимое количество одновременно активных слотов или кластеров.
Пример WIP по кластерам: для команды из 6 человек — Growth: 2 слота одновременно, Retention: 1, Регуляторика: 1. Остальное — буфер и непредвиденные работы. Совет: определите «средний слот» по историческим данным (мода/медиана), а не по ощущению; и закрепите язык — чтобы «слот», «емкость» и «кластер инициатив» значили одно и то же для всех.
Главный принцип — не «растаскивать» людей, а бронировать работу к командам. Второй — ограничивать одновременно активные кластеры (WIP), чтобы снизить контекст switching и ускорить поток. В моей практике снижение параллельности с 5 до 3 активных кластеров на команду сократило медианный lead time с 21 до 14 дней без увеличения часов.
Два шага завтра: 1) заморозьте состав ядра команд на 2–3 спринта; 2) установите WIP лимит на кластеры и откажитесь запускать новую инициативу, пока не закрыт слот в текущем.
Я использую три уровня кластеризации портфеля: по бизнес целям (например, Growth, Retention, Monetization), по доменам (Платежи, Поиск, Профиль) и по регуляторике/рискам (KYC/AML, безопасность, доступность). Это помогает выстраивать приоритеты и квоты, не смешивая несопоставимое. Визуально представляю матрицу: строки — кластеры, столбцы — команды, в клетке — доступные/занятые слоты на период.
Словесно матрица читается так: «Команда Платформа — 4 слота Growth, 2 — Регуляторика; Команда Маркетплейс — 3 слота Retention, 1 — Growth». Цветом подсвечиваю SLA критичность. Советы: 1) не дробите кластеры ниже уровня бизнес смысла; 2) держите приоритеты кластера единой очередью, даже если задачи приходят из разных источников.
Единый шаблон заявки и Definition of Ready на уровне кластера экономят недели. Обязательные поля в моей intake форме: цель и метрика успеха, кластер, владелец, дедлайн/окно ценности, зависимости, оценка размера (S/M/L), риски, артефакты (дизайн, API, легал), предпосылки и план тестирования. DoR для кластера: все поля заполнены, артефакты приложены, согласован владелец, понятен «порог достаточности» для инкремента.
Советы: 1) отбрасывайте заявки без DoR — «не готово» значит «не бронируем»; 2) храните заявки в одном месте и связывайте с кластерами фильтром, чтобы портфель оставался читабельным.
Работаем окном планирования — квартал как базовый горизонт. Квоты по кластерам согласуем в начале квартала и уточняем на еженедельном triage. Механизм торга прозрачный: если один кластер просит дополнительный слот, он забирает его из резерва или у другого кластера по согласованному trade off. Ритуалы: квартальный планинг (квоты, цели, риски), еженедельный triage (переносы, срочные, выравнивание зависимостей).
Советы: 1) фиксируйте все решения торга в заметках к слоту; 2) держите резерв 10–20% на непредвиденное — это спасает SLA без hero mode.
Для сквозных инициатив назначаю «ведущий» кластер и синхронизирую слоты кросс команд. Правило: один владелец, общий план релиза и согласованные окна интеграций. Практический пример: интеграция с внешней платежной командой — мы забронировали 2 последовательных слота у Платформы и 1 у Платежей поставщика в общем календаре; SLA — общий, демо — совместное.
Советы: 1) делайте «точки стыка» артефактом слота (чек лист API/контракта); 2) планируйте буфер между зависимыми слотами минимум 20% от оценки, чтобы не сносить всю цепочку.
Цель — не 100% utilization, а устойчивый коэффициент ~0,8 с резервом. Мое правило «20% на непрогнозируемое» стабилизировало выполнение SLA и уменьшило пожарные переносы вдвое. Измеряю загрузку как долю занятых слотов от доступных и отдельно — долю экстренных.
Советы: 1) если загрузка стабильно >0,9 — это сигнал к пересмотру квот и WIP; 2) пересматривайте коэффициент фокуса ежеквартально с учетом праздников и обязательств команды.
Я меряю throughput и lead time на уровне кластера, а не отдельных задач. На дашборде — burn up по слотам в квартале и квантильные метрики lead time (P50/P85). Читаю так: если burn up отстает от плановой линии 2+ недели, инициирую triage; если P85 растет, значит растет вариативность — пересматриваю WIP и разрез кластеров.
Советы: 1) заведите «карту потока» для каждого кластера (стадии, WIP лимиты, handoff ы); 2) делайте ретро по кластерам, а не по командам — источник задержек чаще в портфельных решениях.
Разные кластеры — разные SLA и прозрачные trade offs. Пример из практики: Регуляторика — 95% инициатив в окне T+1 спринт, P85 lead time ≤14 дней; Growth — 85% в срок, P50 lead time ≤10 дней. Политика сервиса: уровни приоритетов P0/P1/P2, где P0 расходует буфер и требует эскалации до директора портфеля. Совет: публикуйте SLA на доске слотов и ежемесячно показывайте факт.
В трекере я использую метки/компоненты для кластеров и отдельные борды по командам. Кастомные поля: «Кластер», «Слот ID», «Размер слота (S/M/L)», «Окно планирования», «SLA класс», «Зависимости». Фильтры: «слоты текущего квартала по кластеру», «экстренные», «переносы с причиной», «просроченные SLA». Правило: любая инициатива имеет ровно один «Слот ID», а задачи ссылаются на него.
Советы: 1) заведите автоматизацию — нельзя начать задачу без заполненного «Кластера» и «Слот ID»; 2) борды делайте колонками стадий слота, а не задач — так видно поток.
Единый дашборд портфеля для руководителей и команд — must. Пять виджетов: 1) емкость vs занятость слотов по командам; 2) burn up по кластерам; 3) SLA соблюдение по кластерам (месячный и квартальный); 4) lead time P50/P85; 5) карта рисков и зависимостей. Совет: сделайте дрилаут до конкретного слота, чтобы обсуждение шло по фактам.
Соедините календарь слотов с ключевыми релизными событиями roadmap: визуально слоты «ложатся» на релизы и внешние дедлайны. Я использую цветовое кодирование кластеров (Growth — зеленый, Регуляторика — красный, Техдолг — серый) и иконки статуса (ожидает, в работе, на приемке). Совет: синхронизируйте календарь автоматически из трекера по полю «Окно планирования».
До: 12 команд, постоянный перенос релизов, незавершенный WIP ~45 слотов, SLA по регуляторике — 72%. После внедрения кластеров и квот: незавершенный WIP снизился до 28, SLA по регуляторике — 94%, разброс прогноза релизов сократился с ±5 до ±2 недель. Через два квартала медианный lead time по Growth упал с 19 до 13 дней. Неожиданный инсайт: больше всего выиграл саппорт — число эскалаций P0 упало на 40% благодаря буферу и единому triage.
Практические штрихи: мы зафиксировали «ядра» команд на 3 спринта, ввели лимит «не более 3 активных кластеров на команду» и еженедельный портфельный обзор 45 минут. Совет: начните с двух самых «болезненных» кластеров — эффект будет заметен уже через месяц.
Мы разделили клиентов на сегменты (Enterprise, Mid market, SMB) и ввели квоты слотов и SLA по сегментам. Enterprise получил фиксированный резерв и быстрый triage, SMB — пул по принципу best effort. С аккаунт тимами оформили соглашение: «каждый перенос — через общий календарь, срочные — в пределах буфера сегмента». Итог — конфликты между менеджерами сократились ощутимо, а загрузка стала ровнее. Совет: покажите сегментам их фактическое потребление — это меняет разговор.
Мы попробовали гибрид: бронировать и людей, и слоты. Вышло «ни то ни се»: скрытое перераспределение людей ломало стабильность, метрики плавали, SLA проседали. Вывод: матрица без жестких правил — анти паттерн. Сегодня я бы сразу заморозил составы, ввел WIP лимит на кластеры и запретил персональные брони вне слота.
Признаки: «временные» назначения людей между командами, невидимые договоренности, задачи меняют исполнителей после старта. Контрмеры: публичный календарь слотов, запрет на перенос исполнителя после входа в работу, эскалация конфликта приоритетов через портфельный комитет.
Когда команды бронируют «про запас» или делят слот на кусочки, слоты превращаются в фикцию. Лечение: регулярный обзор загрузки — снимаем пустые брони, объединяем фрагменты, возвращаем буфер. Пример: на ревью мы очистили 15% календаря и закрыли долг по SLA.
Риск — без владельца кластера и синхронизации окон инициатива «размазывается». Чек лист: назначен владелец, согласованы окна, прописаны точки стыка, добавлен буфер, согласовано общее демо.
Структура: столбцы — Команда, Кластер, Квота слотов на период, Забронировано, Остаток, SLA класс, Резерв. Условное форматирование: красный — превышение квоты, желтый — остаток
КОРОНАВИРУС