Анализ метрик доставки на основе данных пайплайна Kaiten → ClickHouse. 5 команд: CRM&Loyalty, POS, Self-Service, Industry Solutions, Core Services.
Подготовлено 30 апреля 2026 г. · Источник данных: production telemetry, sync 11:00 МСК
Ключевые сдвиги Q4.25 → Q1.26
Снимок главных изменений между неполным Q4.25 (Nov–Dec) и полным Q1.26.
Поздних релизов
Q4.25 → Q1.26
100% → 67%
−33 пп
Среднее опоздание
Q4.25 → Q1.26
10.5д → 3.2д
−69%
Cycle time POS (median)
Q4.25 → Q1.26
31.8д → 13.2д
−58%
Cycle time Industry Solutions
Q4.25 → Q1.26
42.7д → 13.3д
−69%
Границы данных и оговорки
Что покрывает наша телеметрия и где приходится осторожничать с выводами.
Период
Покрытие
Что можно считать
Q3.25 (Jul–Sep 2025)
Нет
Никаких карточных метрик. Сравнение «до / после» с Q3 невозможно.
Q4.25 (Oct–Dec 2025)
Частично
Только Nov–Dec. Декабрь — единственный полный месяц для baseline.
Q1.26 (Jan–Mar 2026)
Полное
Все 3 месяца. Основа для всех сравнений.
Q2.26 (Apr 2026)
Частично
Только апрель. Цифры экстраполировать на квартал нельзя.
Что означает «релиз поздний».
Сравнение released_at с planned_date из Kaiten. Лаг > 0 → late.
Метрика учитывает только релизы, у которых заполнен planned_date в трекере (5 в Q4.25, 12 в Q1.26, 7 released + 6 planned в Q2.26).
Предсказуемость релизов
Самая чистая динамика, которую дают данные. Доля поздних релизов и среднее опоздание стабильно снижаются три квартала подряд.
Квартал
Релизов
Поздних
% поздних
Среднее опоздание
Avg readiness*
Q4.25
5
5
100%
10.5д
89%
Q1.26
12
8
67%
3.2д
77%
Q2.26 (apr)
13
6
46%
4.8д
74%
Q4.25
100%
Q1.26
67%
Q2.26 (apr)
46%
* Readiness — доля выполненных items в релизе на момент выхода. В Q4 было выше (89%), но релизы выходили в среднем на 10 дней позже плана. В Q1–Q2 readiness ниже (74–77%), но релизы выходят почти по плану. Команды стали лучше управлять scope-ом ради сроков.
Cycle time по командам
Median количество дней от старта работы по карте до завершения. Источник: cycle_time_log, агрегация по дате completion.
Команда
Q4.25 (Nov–Dec)
Q1.26
Q2.26 (apr)
Δ Q4 → Q1
Тренд
POS
31.8д
13.2д
23.5д
−58%
Откат в апреле
Industry Solutions
42.7д
13.3д
19.0д
−69%
Лидер по росту
Self-Service
29.5д
28.4д
23.0д
−4%
Стабильно
CRM&Loyalty
—
20.7д
30.8д
n/a
Просадка в Q2
Core Services
—
13.5д
14.2д
n/a
Сильный старт
Откаты, которые не скрываем. POS в апреле выдала медиану 23.5д против 13.2д в Q1 — возможный признак увеличения скоупа или изменения структуры задач. CRM&Loyalty в апреле просел с 20.7д до 30.8д. Оба тренда требуют наблюдения; одного апреля недостаточно для вывода.
Эффект разделения POS на POS + Core Services
Core Services заработала как отдельная команда в январе 2026. Сравнение throughput POS до и после, плюс совместный объём двух команд.
Месяц
POS
Core Services
Combined
Δ к декабрю
Дек.25 (baseline)
69
0
69
—
Янв.26
101
7
108
+57%
Фев.26
107
21
128
+86%
Мар.26
67
24
91
+32%
Апр.26
63
53
116
+68%
Q1.26 avg/мес
92
17
109
+58%
Что показывает таблица. POS сама по себе не уменьшилась пропорционально (отдала немного, но в Q1 в среднем даже выросла к декабрю). Core Services с нуля прибавила 53 карты в апреле — рост в 7.5× за квартал. Суммарно две команды выдают в среднем на 60% больше карт, чем POS делала одна.
Оговорка по baseline. Декабрь 2025 — единственный месяц до запуска Core Services, по которому у нас есть данные. Если в более ранние периоды POS работала с другой загрузкой, мы это не видим. Поэтому «+58%» нужно читать как «к декабрьскому baseline», а не «к историческому уровню POS».
Эффективность дизайн-команды
Самая сложная часть отчёта. Прямую цифру дать невозможно — объясняю почему.
В нашем Kaiten workflow нет колонки «Design» как отдельной фазы.
Стандартный набор колонок: Triage → New → Ready for Sprint → In Progress → Code Review → Testing (QA) → Ready for Release → Released. Дизайн — pre-sprint работа, в карточном трекере не отражается. Это значит: вытащить «время дизайна на задачу» из текущих данных нельзя.
Косвенный proxy — разница lead_time − cycle_time (время от создания карты до старта работы, включает дизайн / ревью / ожидание):
Квартал
N задач
Median prework
P75 prework
Q4.25 (Nov–Dec)
44
0.2д
10.9д
Q1.26
194
1.0д
12.7д
Q2.26 (apr)
126
1.0д
11.8д
Почему эта метрика не показывает улучшения, даже если дизайн ускорился.
Карта, созданная в Q4 и завершённая в Q1, попадает в Q1 bucket и тащит за собой всё своё длинное «pre-work» время. Это smearing-эффект на стыке кварталов. Малый N в Q4.25 (44 карты) дополнительно искажает картину. Делать вывод «дизайн не ускорился» по этим цифрам строго некорректно — не тот инструмент.
Что данные косвенно поддерживают. Резкое падение late% по релизам (100 → 67 → 46) и сокращение cycle time у команд, которые исторически зависели от дизайна (POS, IS), совместимо с гипотезой «дизайн-bottleneck снят». Но строго атрибутировать это конкретно дизайну, а не разделению POS / новой структуре команд / другим факторам, мы не можем.
Объём багов
Количество resolved bugs по кварталам. Интерпретировать осторожно.
Квартал
Resolved bugs
Δ к Q4.25
Q4.25 (Nov–Dec)
48
—
Q1.26
19
−60%
Q2.26 (apr)
28
−42%
Не использовать как сильный сигнал без отдельной проверки. Падение «resolved» может означать (а) меньше багов создаётся — это качественный рост, либо (б) хуже трекинг — баги создаются, но не закрываются формально. Чтобы различить, нужен анализ bug intake (created bugs per quarter), который в этот отчёт не входит.
Сводка
Что ship-able для разговора наверх и где границы честности.
Что подтверждается данными
Доля late-релизов: 100% → 67% → 46% (3 квартала подряд снижение)
Среднее опоздание релиза: 10.5д → 3.2д → 4.8д
Cycle time POS: −58% Q4 → Q1 (с откатом в апреле до −26%)
Cycle time Industry Solutions: −69% Q4 → Q1, удерживается
POS + Core Services combined throughput: +60% к декабрьскому baseline
Core Services с нуля до 53 карт/месяц за квартал — успешный запуск новой команды
Команды стали лучше управлять scope ради сроков (readiness ниже, on-time выше)
Где данных не хватает
Q3.25 baseline отсутствует целиком — сравнить «до Core» в полную силу нельзя
Q4.25 — только 2 из 3 месяцев, малый N (44 завершённые задачи)
Эффект дизайн-команды численно не выделить — нет соответствующей фазы в трекере
Эффект ИИ-инструментов численно не атрибутируется — карточные данные не различают AI-assisted от обычных
Соотношение «commit / release» по спринтам не агрегируется в текущем pipeline
Bug intake не покрыт этим отчётом — для разговора о качестве нужен отдельный анализ