Какие выполнял месячные показатели на проекте?

Месячные показатели, которые я отслеживал на проектах

Меню проектом, бизнес смотрит на цифры. За 10+ лет я научился выбирать правильные KPI, которые показывают реальный прогресс, а не иллюзию активности. Расскажу о том, какие показатели я отслеживал и почему именно эти.

Категория 1: Метрики разработки (Product Delivery Metrics)

Это показатели того, как быстро мы доставляем фичи.

1.1 Velocity (Скорость разработки)

Определение: Сколько story points команда успевает сделать за спринт?

Как я отслеживаю:

Спринт 1: 32 поинта (плановали 40, не всё сделали)
Спринт 2: 38 поинтов
Спринт 3: 35 поинтов
Спринт 4: 40 поинтов

Средний Velocity: 36 поинтов в спринт

Почему это важно:

• Предсказываемость: если у нас 200 поинтов требований, то ~5-6 спринтов
• Тренд: Растёт ли velocity или падает? Если падает — команда устаёт или есть блокеры
• Планирование: Бизнес может планировать features на основе velocity

Пример действия: Если velocity падает с 40 до 25:

• Спрашиваю: Почему? (отпуск людей? техдолг? сложные фичи?)
• Если techdebt — нужно заложить спринты на рефакторинг
• Если отпуск — нормально, будет back up
• Если непредвиденные issues — нужно добавить буфер к плану

1.2 Burndown Rate (Сжигание задач за спринт)

Это график, показывающий как мы прогрессируем за спринт.

Идеальный burndown:

День 1: 40 поинтов осталось (спринт начался)
День 2: 36 поинтов (4 сожгли)
День 3: 32 поинта
День 4: 28 поинтов
День 5: 24 поинта
День 6: 20 поинтов
...
День 10: 0 поинтов (спринт закончился, всё сделали)

Плохой burndown:

День 1-5: Ничего не происходит (0 поинтов сожгли)
День 6-9: Срочно начинаем работать
День 10: Спешка, stress, багов

Как я реагирую: Если в день 5 спринта мы сожгли только 10% работы, вмешиваюсь:

• Встреча со scrum master: что блокирует?
• Может быть, нужна помощь?
• Может быть, scope слишком большой для этого спринта?

1.3 Defect Rate (Уровень багов)

Сколько багов находят в релизе?

Отслеживаю:

Релиз 1 (май): 15 багов за месяц на 5K пользователей
            = 3 бага на 1K пользователей

Релиз 2 (июнь): 8 багов на 7K пользователей
               = 1.1 бага на 1K пользователей

Тренд: Качество улучшается (меньше багов при больше пользователях)

Почему это важно:

• Качество разработки: если багов много, нужно улучшить testing
• Customer satisfaction: много багов = unhappy customers = churn
• Support нагрузка: каждый баг = поддержка calls

Действие: Если defect rate растёт:

• Добавляю тестирование в спринт (QA effort)
• Может быть, нужно замедлить разработку, чтобы более внимательно?
• Анализирую: какие баги? (вид багов может показать проблему в коде)

1.4 Release Frequency (Как часто выпускаем)

Отслеживаю:

• Май: 4 relеaseа (среда/пн/пт/чт)
• Июнь: 8 releases (в среднем 2 в неделю)
• Июль: 12 releases (почти каждый день)

Тренд: ускоряемся

Почему это важно:

• Agility: частые релизы = быстро реагируем на market changes
• Risk: частые relеaseа с меньшим набором фич = меньший риск каждого
• Customer feedback: быстрее видим feedback юзеров и итерируем

1.5 Lead Time (Время от идеи до production)

Как я отслеживаю:

Фича "Экспорт в CSV"
- Идея от客户: 1 марта
- Разработка начало: 3 марта (2 дня на планирование)
- Разработка финиш: 10 марта (7 дней кодирование)
- Testing: 10-13 марта (3 дня тестирование)
- Production: 13 марта

Lead Time = 12 дней от идеи до production

Цель: Уменьшить lead time:

• Месяц назад: 30 дней
• Сейчас: 12 дней
• Цель: 7 дней

Почему это KPI:

• Speed to market: быстрее доставляем ценность
• Конкуренция: если конкурент работает 20 дней, а мы 5 — мы выигрываем

Категория 2: Бизнес-метрики (Business Metrics)

Это показатели влияния на bottom line.

2.1 Feature Adoption Rate (Какой % пользователей использует новую фичу)

Отслеживаю:

Релиз "Темный режим" (30 июня)
- 1 июля: 5% пользователей включили
- 7 июля: 12% пользователей
- 14 июля: 18%
- 30 июля: 22%

Цель была 15% к концу месяца, достигли 22% - win!

Интерпретация:

• Низкая adoption: может быть, фича не нужна пользователям? или сложная?
• Высокая adoption: фича popular, может быть, стоит развивать дальше

Действие:

• Если adoption < 10% за месяц, интервью пользователей: почему не используют?
• Если adoption > 30%, может быть, эта фича заслуживает больше ресурсов

2.2 Revenue Impact (Какой доход принесла фича)

Пример:

Фича "Premium Features" (новые возможности за деньги)
- Разработка: $50K (оплата разработчикам)
- Revenue: $200K за первый месяц
- ROI: 4x за месяц

Это good investment!

Как я это отслеживаю:

• Сегментирую пользователей: who bought premium?
• Смотрю: какой revenue от этого segment за месяц?
• Вычитаю базовый revenue (что бы они потратили на базовый план)
• Оставшееся = revenue от новой фичи

2.3 Customer Retention (Удержание клиентов)

Отслеживаю 30-day retention:

Май: 45% (45% юзеров, пришедших в май, вернулись в июне)
Июнь: 48% (улучшилось)
Июль: 51% (продолжаем расти)

Почему это важно:

• Для SaaS/mobile это главный метрик
• Low retention = проблема с product (пользователям не нравится)
• High retention = пользователи ценят, будут платить

Действие:

• Если retention падает → анализирую: что изменилось? (может быть, новый релиз сломал что-то?)
• Если растёт → продолжаю в том же направлении

2.4 Customer Satisfaction (CSAT, NPS)

CSAT (Customer Satisfaction Score):

"Довольны ли вы нашим сервисом?"
- Май: 4.2/5 (84% happy)
- Июнь: 4.5/5 (90% happy)
- Июль: 4.6/5 (92% happy)

NPS (Net Promoter Score):

"Рекомендовали бы вы нас друзьям?"
Май: 35 (good)
Июнь: 42 (very good)
Июль: 48 (excellent)

Интерпретация:

• NPS < 0: вы теряете клиентов
• 0-30: okay, но нужны улучшения
• 30-70: good, держите этот темп
• 70+: excellent, вы лидер рынка

Действие: Если NPS падает, я:

• Провожу root cause analysis
• Беру 10 "detractors" (оценили 0-6) и интервьюирую их
• Узнаю, что не нравится
• Добавляю в roadmap улучшения

Категория 3: Финансовые метрики (Financial Metrics)

3.1 Cost per Feature (Стоимость разработки фичи)

Отслеживаю:

Фича "Export CSV":
- Разработка: 40 часов × $100/hour = $4000
- Testing: 10 часов × $80/hour = $800
- Итого: $4800
- Adoption: 30% пользователей
- Revenue impact: $5000/месяц

ROI: $5000 / $4800 = 1.04x за месяц (окупается)

Цель: Каждая фича должна иметь ROI > 1x в течение 3-6 месяцев.

3.2 Development Cost Velocity (Как меняется стоимость разработки)

Отслеживаю:

Май: $1000 per story point (32 поинта × $32K месячная зарплата)
Июнь: $950 per story point (velocity выросла)
Июль: $900 per story point (команда более efficient)

Позитивный тренд: Становимся дешевле на разработку (за счёт улучшения процесса).

3.3 Support Cost (Стоимость поддержки)

Отслеживаю:

Май: $2000 на support (50 тикетов × $40 на разрешение)
Июнь: $1500 на support
Июль: $1200 на support

Причина: После каждого релиза с улучшениями UX, количество support тикетов падает.

Action: Если support cost растёт, это signal что нужны улучшения продукта или документации.

Dashboard, который я ежемесячно показываю CEO/CTO

╔════════════════════════════════════════════════╗
║          MONTHLY METRICS DASHBOARD (JULY)      ║
╠════════════════════════════════════════════════╣
║ Velocity:              40 points/sprint ↑ +5%  ║
║ Defect Rate:           0.8 bugs/K users ↓     ║
║ Feature Adoption:      22% (exceeds 15%)  ✓   ║
║ Release Frequency:     12 releases/month ↑     ║
║ Lead Time:             12 days ↓ -2 days      ║
║ Customer Retention:    51% ↑ +3%               ║
║ NPS Score:             48 (excellent)          ║
║ Revenue from Features: $250K ↑ +25%            ║
║ Support Cost:          $1,200 ↓                ║
║ Dev Cost per Point:    $900 ↓ -10%             ║
╚════════════════════════════════════════════════╝

STATUS: All metrics trending positively
NEXT MONTH GOALS:
  → Lead Time < 10 days
  → Defect Rate < 0.7
  → NPS > 50

Как я использую эти метрики

Для планирования:

• Если velocity стабильна на 35 поинтов, я могу уверенно сказать: "Эти 140 поинтов займут 4 спринта"

Для принятия решений:

• Если feature adoption 5%, я не инвестирую в развитие этой фичи. Может быть, нужно улучшить
• Если revenue от feature $100/месяц, а стоила $5000, то это bad investment

Для мотивации команды:

• "Улучшили adoption на 10%, это значит, что наши пользователи ценят улучшения"
• "Снизили defect rate на 30%, значит, качество растёт"

Для общения с бизнесом:

• CEO спрашивает: "Можем ли мы запустить эту фичу в этом месяце?"
• Я отвечаю с данными: "У нас velocity 35 поинтов/спринт, фича оценена в 40 поинтов, её можем сделать за 6 дней, но это значит, что отложим то (показываю list других задач)"

Ошибки, которых я избегаю

Ошибка 1: Мусорные метрики

• "Мы потратили 1000 часов на разработку" — это не метрик, это просто потрачено
• Хороший метрик: "Потратили 1000 часов на разработку фичи, которая принесла $50K revenue"

Ошибка 2: Игнорирование тренда

• Если все метрики падают, это signal что что-то не так
• Не игнорирую, я расследую

Ошибка 3: Оптимизация не-того

• Если NPS низкий, оптимизировка lead time не поможет
• Нужно сначала разобраться, почему NPS низкий

Результат правильного отслеживания метрик

• Data-driven decisions — решения на основе фактов, не gut feeling
• Видимость для бизнеса — CEO видит реальный progress
• Видимость для команды — разработчики видят, что их работа важна и приносит результат
• Continuous improvement — каждый месяц улучшаем процесс
• Успешные проекты — когда всё измеренно и ясно, проекты успешны на 80%+

Метрики — это язык, на котором бизнес и технология общаются эффективно.