Как стать автором
Обновить

Метрики для оценки эффективности команд на удаленке и не только

Уровень сложностиПростой
Время на прочтение5 мин
Количество просмотров14K
Всего голосов 24: ↑19 и ↓5+14
Комментарии12

Комментарии 12

С метриками не сталкивался, но как понимаю это лучше чем "палить" каждого сотрудника программами слежения.

Есть конторы, для которых KPI - это всё. Полезно знать, как отбиваться с девелоперского уровня :-)

А теперь вопрос.
Как вот эти метрики:

  • Time to market (TTM) — время доставки до рынка.

  • Time to lead (TTL) — время производства.

  • Committed vs Delivered (C\D) — соблюдение сроков.

  • Velocity — скорость.

  • Delivery — кол-во доставок до прома.

  • Rollback — кол-во откатов с прома.

  • Duration — нахождение задачи в статусе.

  • Quantity — кол-во сделанных задач.

  • Показатель качества — работа с инцидентами прома

    Влияют на:

  • Скорость генерации дохода

  • Операционные расходы

  • Связанный капитал

А если не влияют, то зачем мереем?

Что бы ответить на этот вопрос предлагаю посмотреть на данный набор метрик с т.з. влияния или мотивации. В результате мы увидим всего два вектора: рост скорости доставки фичей, качество/доступность сервиса для клиента. При удачной бизнес-модели, влияние показателей на скорость генерации дохода достаточно ощутимое. Что касается операционных расходов и связанности капитала, то данные показатели нам позволяют оценивать внутренний потенциал организации в части ИТ (сделать больше тем же ресурсом).

Согласен, что в случае правильно построенного бизнеса TTM влияет на скорость генерации дохода, а остальные сильно не влияют. Но я спрашивал про вашу компанию, как у вас? А не про сферического бизнеса в вакуме

Я не могу раскрывать конкретных цифр, но наблюдается ощутим рост бизнеса из года в год и инвестиций в развитие, по этому нам важно следить за своей «формой»

Почему по дороге потеряли T2M и LT?

Почему отказались от идеи считать Duration, его же тоже можно считать относительно. Если вы на метрике Velocity увидите проблему, вам все равно придется опускаться на уровень ниже. И тут время нахождения в статусах позволяет быстро найти проблемную зону.

Почему не использовали плагины Jira, у самой Jira есть свои BI инструменты. Самое важное что из отчета можно сразу открыть задачи, на основании которых посчиталась метрика. Часто это важно, когда появляется отклонение и надо быстро понять в чем причина.

В целом уход от абсолютных величин тоже проповедуем. Они в том числе решают проблему, когда метрика воспринимается как карательный механизм. Относительные величины показывают динамику и отклонение, а не ситуацию в моменте без контекста.

Почему пока не используем T2M и LT? Когда мы собрали статистику по ретро данным, увидели в ней крайнюю разнородность данных: фичи, тех таски, работы, оценки, исследования и тд. - и поняли, что без формализации правил ведение объектов и процессов эти метрики не снять. Сейчас как раз работаем над формализацией.

Duration - так же из-за качества данных оказалась не репрезентативной, но мы используем для дриллдоуна декомпозицию на подзадачи (об этом я опубликую отдельную статью)

Я упомянул в статье причину использования более мощных аналитических инструментов. Мы берём данные не только из jira

Рекомендую использовать измеряемую Бизнес-ценность в качестве метрики эффективности разработки ( Aeilus ). Остальные показатели это про эффективность планирования , работу с издержки производства, но они все легко поддаются манипуляция со стороны самой разработки.

Если имеются в виду бизнес показатели, они используются, но не дают полной картины. Вопрос стоит так: «ок, мы достигаем бизнес планы, но могли бы мы сделать больше текущим ресурсом и объемом инвестиций?»

потому что 1 sp у каждой команды свой и они не сравнимы.

А почему у вас получился разный sp у разных команд? Ведь в таком случае не получится оптимизировать работу отдельного сотрудника в рамках группы/отдела/направления.

Это не у нас получился разный sp. Сама суть относительной оценки подразумевает, что она работает для конкретной команды и конкретного беклога, т.к. она (оценка) подтверждается эмпирически, а опыт это субъективная вещь.

По поводу оптимизации процессов конкретных компетенций будет отдельная статья (спойлер: мы тоже с этим работаем). В данной раскрыли, как можно работать с эффективностью команды

Зарегистрируйтесь на Хабре, чтобы оставить комментарий