Кейс 03 · Skipp · CPO / руководитель отдела разработки
← Все кейсыПлатформа отслеживания эффективности разработки
Skipp объединяет несколько десятков российских веб-студий в единую систему поиска подрядчика. За сроки и качество перед клиентом отвечает платформа — а работают независимые команды с разной культурой и дисциплиной. Я спроектировал систему, которая делает здоровье каждого проекта измеримым, видимым каждый день и напрямую влияющим на деньги участников.
- Роль
- CPO / руководитель отдела разработки
- Домен
- Заказная разработка · аналитика · процессы
- Масштаб
- 20+ команд · ~30 сервисов на замерах
- Статус
- В ежедневной эксплуатации, 30 месяцев истории
- 20+
- продуктовых команд под контролем из одного окна
- ~30
- сервисов на ежемесячных DORA-замерах
- 30 мес
- непрерывных замеров эффективности разработчиков
- 46+
- шагов на BPMN-карте процессов платформы
Раздел 01
Задача: управлять двадцатью командами, не заглядывая в каждую
Skipp — платформа заказной разработки: клиент приходит с задачей, платформа подбирает исполнителей из нескольких десятков партнёрских веб-студий, контролирует этапность работ и гарантирует расчёты. Модель сильная, но у неё есть встроенная проблема: перед клиентом за сроки и качество отвечает платформа, а сами работы ведут 20+ независимых продуктовых команд — у каждой свои инструменты, привычки и уровень дисциплины.
Ручной контроль на таком масштабе не работает: невозможно сидеть на двадцати дейли одновременно, а узнавать о проблемах из письма недовольного клиента — слишком поздно и слишком дорого. Мне нужен был способ видеть состояние каждого проекта ежедневно, сравнивать команды объективно и вмешиваться до того, как проект «покраснеет».
Единственный способ управлять двадцатью командами — сделать качество процессов измеримым, видимым каждый день и напрямую влияющим на деньги участников. Эту систему я и построил.
Раздел 02
Решение: от одной бизнес-формулы до зарплатной ведомости
Я не начинал с графиков. Я начал с вопроса, за что клиент вообще платит платформе, — и свёл ответ к одной формуле: удовлетворённость заказчика определяется отношением фактической стоимости результата к ожидаемой. Дальше вся метрическая модель выведена из этой формулы: я разложил H на управляемые рычаги — точность прогноза, прозрачность работ в реальном времени, квалификация исполнителей — и под каждый рычаг завёл измеримую метрику с источником данных, триггером снятия и формулой.
Верхний уровень — PHI (Project Health Index), композитный индекс здоровья проекта. Каждый проект стартует с 80 баллов и живёт в трёх зонах: зелёная (90–100), жёлтая (70–90), красная (ниже 70). Индекс пересчитывается ежедневно: скрипт в 00:00 по Москве выгружает данные из Jira, консоли SKIPP и форм отчётности, склеивает их по единым правилам нейминга и двигает PHI по прописанным правилам начислений и штрафов.
Поверх индекса — четыре типа автоматических алертов, ролевой доступ и главный управленческий ход: бонус менеджера за спринт считается как ставка, умноженная на выработку и множители за выполнение плана, PHI и удержание заказчика. Метрики в этой системе не «для отчёта» — они двигают деньги. Инженерный слой я мерил отдельно — по DORA, отраслевому стандарту оценки зрелости процессов доставки кода.
Контур системы
H = F / D
удовлетворённость заказчика = фактическая стоимость результата / ожидаемая
↓
Рычаги: точность прогноза · прозрачность · квалификация исполнителей
↓
PHI — ежедневный индекс здоровья каждого проекта
↓
Алерты и вмешательство
↓
Бонусы менеджеров
↓
DORA-метрики и git-статистика — инженерный фундамент
Раздел 03
Артефакты
Рабочие документы системы — как есть, без глянца: техническое задание, процессная карта, замеры и экраны. По ним видно, как система устроена изнутри.
Артефакт 01
ТЗ на управленческий дашборд: 18 разделов, живой документ
Это продуктовая спецификация на ~19 страниц, по которой дашборд строился. Я сознательно писал её не по ГОСТ 34, а в формате «метрика → источник данных → формула → интерфейс»: каждый раздел доводится до конкретных значений по умолчанию, диапазонов и цветовых порогов — так документ читают и разработчики, и менеджеры, и финансист, который считает бонусы.
Документ живой: разделы дописывались итерациями по мере эксплуатации — внутри них отмечены доработки. Например, в разделе 3 Project health index позже разделён по типам синков — дейли, демо и спринт-планинг с разными допустимыми интервалами, а в разделе 7 бонус менеджера привязан к его собственной выработке. Поздние разделы — табели, оффер, баланс, аналитика — дописывались по мере роста платформы.
Products dashboard: техническое задание
Автор: Павел Мальцев, CPO · ~19 страниц
Оглавление — кликните раздел
Разворот · раздел 3 — Project health index
№ 3
PHI - универсальная композитная метрика оценки состояния здоровья проекта определяющая качество проектного менеджмента. Индекс будет формироваться на основании показателей всех ключевых проектных метрик. Текущее значение и динамику изменений PHI для каждого проекта можно будет отслеживать в консоли SKIPP.
PHI любого проекта стартует с 80 и может вырасти максимум до 100 (выше не растет)
Значение индекс определяет его цвет:
Зеленый: 90-100
Желтый: 70-90
Красный: < 70
Лог индекса должен содержать календарь изменений индекса с цветовой индикацией для каждого изменения.
| Метрика | Изменение PHI | Зеленый | Желтый | Красный |
| Командный синк | каждый день / зел + 1 (дейли проводится больше 2-х дней подряд) / желт -1 (вчера дейли не проведен) / красн - 5 (дейли не проводится больше 2-х дней) | Y > 0 (2 или более раб.дня) | Y = 0 (1 раб.день) | Y = 0 |
| Прогресс задач | каждый день за каждого разработчика с планом =>4 часа. в прошлый день / зел + 1 / желт -1 / красн - 2 / (Было движение тасков у Х исполнителей, не было у Y из которых у Я уже более 2х дней подряд) | Z > 0 | Z = 0 (1 день) | Z = 0 (2 или более раб.дня) |
| Планирование спринта | при старте нового спринта / зел +5 (цели спринта прописаны) / красн - 5 (цели спринта не прописаны) | J = 1 | J = 0 | |
| Удовлетворенность | при закрытии спринта / зел +2*(7-A) (заказчик доволен) / желт = 0 (заказчик сомневается) / красн -2*(A-7) (заказчик недоволен) | A >7 | A=7 | A < 7 |
| Загрузка | каждый день / зел +2 (текущая загрузка выше минимального плана на 20%) / желт = 0 (текущая загрузка находится в рамках плана) / красн - 2 (текущая загрузка ниже минимального плана на 20%) | С (выработка за текущий спринт) > план по часам *1.2 | else | С (выработка за текущий спринт) < C план по часам *0.8 |
| Задержка | каждый день / зел = 0 / желт -1 (задержка сдачи спринта) / красн - 5 (задержка сдачи спринта больше 2-х дней) | L<= 0 | 0 < L<= 2 | L > 2 |
В рамках данной задачи необходимо будет перейти на новый формат таблицы данных, в связи с изменением формы отчета. Новая форма разводит ссылки на записи разных активностей в разные поля, таким образом можно будет брать из таблицы и подтягивать в дашборд ссылку на последнюю запись звонка для каждого вида активности. Новая форма. Таблица данных для новой формы находится на втором листе (Ответы на форму (2)) текущей таблицы.
Выделяем из метрики “командный синк” новые метрики: “демо” и “спринт планинг”. Факт проведения “демо” и “спринт планинг” мы берем из таблицы данных - колонка “D” (в новом формате)
| Метрика | Изменение PHI | Зеленый | Желтый | Красный |
| Командный синк | ВСЕ ОСТАЕТСЯ КАК ЕСТЬ, УЧИТЫВАЕМ ВСЕ ТИПЫ АКТИВНОСТЕЙ ИЗ КОЛОНКИ F / каждый день / зел + 1 (дейли проводится больше 2-х дней подряд) / зел +0 (вчера дейли проведен) / желт -1 (вчера дейли не проведен) / красн - 5 (дейли не проводится больше 2-х дней) | Y < 2 (2 или более раб.дня подряд) | Y = 1 (1 раб.день) | Y = 0 (2 дня подряд) |
| Sprint planning | УЧИТЫВАЕМ ТОЛЬКО АКТИВНОСТЬ ТИПА СПРИНТ ПЛАНИНГ ИЗ КОЛОНКИ F / каждый день / зел + 1 (спринт планинг был проведен не больше 10 дней назад) / желт = 0 (спринт планинг не проводился 10 дней ) / красн - 5 (спринт планинг не проводится больше 10 дней) | Y < 10 ( более 10 раб. дней подряд) | Y = 10 (10 раб.дней подряд) | Y > 10 (дольше 10 раб. дней подряд) |
| Demo | УЧИТЫВАЕМ ТОЛЬКО АКТИВНОСТЬ ТИПА ДЕМО ИЗ КОЛОНКИ F / каждый день / зел + 1 (демо было проведено не больше 5 дней назад) / желт = 0 (демо не проводилось 5 дней ) / красн - 5 (демо не проводится больше 5 дней) | Y < 5 ( более 5 раб. дней подряд) | Y = 5 (5 раб.дней подряд) | Y > 5 (дольше 5 раб. дней подряд) |
Артефакт 02
BPMN-карта процессов: 46+ шагов от лида до расчётов
Метрики не живут в вакууме — они снимаются с процесса. Поэтому параллельно с дашбордом я описал операционку платформы как BPMN-карту: от входа лида до финальных расчётов со студиями, 46+ шагов с ролями, артефактами и точками контроля.
Карта — двухстраничный документ в нотации BPMN: дорожки ролей, шлюзы решений, привязка каждого шага к системам (Jira, SKIPP, формы отчётности). Именно она определяет, где и какие метрики снимаются — и почему им можно верить.
Тащите — двигать · колесо или щипок — масштаб
Рендер карты процессов…
Интерактивная доска · двухстраничная BPMN-карта Skipp · перетаскивание и масштаб
Артефакт 03
DORA-замеры: 30 сервисов, 26 месяцев данных
DORA — отраслевой стандарт метрик зрелости доставки кода. Я поставил их на ежемесячный замер по всем сервисам платформы — это большая история замеров: 30 сервисов × 26 месяцев непрерывных данных — и дополнил метриками под нашу операционку — точностью оценок и долей доработки. Связка давала три среза: Velocity и предсказуемость каждой команды, вклад и дисциплину отдельного разработчика и здоровье и устойчивость продукта (SLA). Ниже — определения и реальный фрагмент замера.
Отраслевые метрики DORA
Deployment Frequency
Частота деплоев — как часто код доезжает до продакшена
Lead Time for Changes
Время цикла изменений — от коммита до выката в продакшен
Change Failure Rate
Доля неудачных изменений — деплои, приведшие к инцидентам
MTTR
Время восстановления после инцидента
Добавил под операционку платформы
Оценка → факт
Разница между оценкой задачи и реальным фактом — точность планирования спринта
Коэффициент доработки
Доля усилий на исправление ошибок против плановых задач спринта — сколько уходит в реактивную работу
Uptime / SLA
Доступность сервиса — доля времени безотказной работы
Загрузка замеров…
Артефакт 04
Экраны платформы: обзор, аналитика и команда
Раздел · Проекты
Один экран отвечает на вопрос «куда смотреть сегодня»: строка — проект, цвет — зона PHI, тренд — стрелка динамики.
- 01 PHI-бейдж с трендом по каждому проекту
- 02 Счётчики дней с последнего демо и спринта
- 03 Прогресс-бары часов: план / факт спринта
- 04 Индикаторы алертов на строках проектов
- 05 Календарь-теплокарта активности за 30 дней
- 06 Ролевой доступ: админ видит всё, менеджер — своё
Артефакт 05
KPI: метрики, которые управляют мотивацией
Замыкающий элемент системы: бонус менеджера считается из тех же метрик, что светятся в дашборде. Состав формулы реальный; коэффициенты намеренно не публикуются.
Раздел 04
Что получилось
Система прожила достаточно долго, чтобы накопить историю, — а это для управленческого инструмента и есть главный результат: им пользовались каждый день.
20+ команд
управляются из одного окна: единый PHI, единые правила нейминга Jira ↔ SKIPP, ролевой доступ
30 месяцев
непрерывных помесячных замеров по разработчикам (~318 записей) с отбрасыванием 5% выбросов
26 × 30
месяцев × сервисов ежемесячных DORA-замеров: аптайм, деплои, неудачные, восстановление
10 750
коммитов и 383 267 добавленных строк за один четырёхмесячный срез git-аналитики
4 типа
алертов находят проблему раньше клиента: динамика PHI, красная зона, низкий NPS ×2
ЗП → PHI
качество процессов стало личным финансовым интересом менеджеров