Comments 12
С метриками не сталкивался, но как понимаю это лучше чем "палить" каждого сотрудника программами слежения.
Есть конторы, для которых KPI - это всё. Полезно знать, как отбиваться с девелоперского уровня :-)
А теперь вопрос.
Как вот эти метрики:
Time to market (TTM) — время доставки до рынка.
Time to lead (TTL) — время производства.
Committed vs Delivered (C\D) — соблюдение сроков.
Velocity — скорость.
Delivery — кол-во доставок до прома.
Rollback — кол-во откатов с прома.
Duration — нахождение задачи в статусе.
Quantity — кол-во сделанных задач.
Показатель качества — работа с инцидентами прома
Влияют на:
Скорость генерации дохода
Операционные расходы
Связанный капитал
А если не влияют, то зачем мереем?
Что бы ответить на этот вопрос предлагаю посмотреть на данный набор метрик с т.з. влияния или мотивации. В результате мы увидим всего два вектора: рост скорости доставки фичей, качество/доступность сервиса для клиента. При удачной бизнес-модели, влияние показателей на скорость генерации дохода достаточно ощутимое. Что касается операционных расходов и связанности капитала, то данные показатели нам позволяют оценивать внутренний потенциал организации в части ИТ (сделать больше тем же ресурсом).
Почему по дороге потеряли T2M и LT?
Почему отказались от идеи считать Duration, его же тоже можно считать относительно. Если вы на метрике Velocity увидите проблему, вам все равно придется опускаться на уровень ниже. И тут время нахождения в статусах позволяет быстро найти проблемную зону.
Почему не использовали плагины Jira, у самой Jira есть свои BI инструменты. Самое важное что из отчета можно сразу открыть задачи, на основании которых посчиталась метрика. Часто это важно, когда появляется отклонение и надо быстро понять в чем причина.
В целом уход от абсолютных величин тоже проповедуем. Они в том числе решают проблему, когда метрика воспринимается как карательный механизм. Относительные величины показывают динамику и отклонение, а не ситуацию в моменте без контекста.
Почему пока не используем T2M и LT? Когда мы собрали статистику по ретро данным, увидели в ней крайнюю разнородность данных: фичи, тех таски, работы, оценки, исследования и тд. - и поняли, что без формализации правил ведение объектов и процессов эти метрики не снять. Сейчас как раз работаем над формализацией.
Duration - так же из-за качества данных оказалась не репрезентативной, но мы используем для дриллдоуна декомпозицию на подзадачи (об этом я опубликую отдельную статью)
Я упомянул в статье причину использования более мощных аналитических инструментов. Мы берём данные не только из jira
Рекомендую использовать измеряемую Бизнес-ценность в качестве метрики эффективности разработки ( Aeilus ). Остальные показатели это про эффективность планирования , работу с издержки производства, но они все легко поддаются манипуляция со стороны самой разработки.
потому что 1 sp у каждой команды свой и они не сравнимы.
А почему у вас получился разный sp у разных команд? Ведь в таком случае не получится оптимизировать работу отдельного сотрудника в рамках группы/отдела/направления.
Это не у нас получился разный sp. Сама суть относительной оценки подразумевает, что она работает для конкретной команды и конкретного беклога, т.к. она (оценка) подтверждается эмпирически, а опыт это субъективная вещь.
По поводу оптимизации процессов конкретных компетенций будет отдельная статья (спойлер: мы тоже с этим работаем). В данной раскрыли, как можно работать с эффективностью команды
Метрики для оценки эффективности команд на удаленке и не только