Вы абсолютно правы. В случае наличия Quality Gate, автоматического запуска тестов для pull-request и политики зеленого билда - метрика теряет актуальность. Это уже другой уровень зрелости процессов в команде, тут и метрики нужны другие. Метрика валидна, если по результату прогона тестов баги не фиксятся сразу разработчиками, а заводятся тестировщиками в систему.
"Главное не упарываться только в какую то одну метрику" - это точно! Эффект Гудхарта в чистом виде: когда метрика становится целью, она перестает быть метрикой.
Читерство метрик - печальная история. Вроде бы помогать должны, а происходит наоборот( KPI цели на метрики часто становятся причиной подгона метрик, а не изменения процессов.
"Время команды" и "время клиента" - мне нравится! Кажется, что через такие метафоры смысл метрик можно проще доносить. Запомню.
В вашей трактовке не очень поняла, чем Lead Time отличается от ТТМ?
А вообще тема очень интересная про терминологическую путаницу. Иногда ведь даже в рамках одной компании термины отличаются.. Главное, думаю, чтобы участники одного процесса понимали друг друга. С фиксацией своего понимания в глоссарии, желательно.
Хорошее уточнение про разницу между заказчиком и пользователем - это действительно разные углы оценки качества. NPS я не советую отбрасывать. Говорю только, что из моей практики считают его редко. Это не значит, что считать не надо. Напротив. Если у команды есть силы и ресурсы считать на постоянной основе - это определенно стоит делать! Не включила в итоговый список метрик как раз по причине сложности внедрения. Думаю, NPS можно включить во вторую волну "ответственности за качество", когда начнется работа вглубь.
А какие метрики вы относите к "про технический долг"? И что бы еще добавили "про качество продукта"?
Вы абсолютно правы. В случае наличия Quality Gate, автоматического запуска тестов для pull-request и политики зеленого билда - метрика теряет актуальность. Это уже другой уровень зрелости процессов в команде, тут и метрики нужны другие.
Метрика валидна, если по результату прогона тестов баги не фиксятся сразу разработчиками, а заводятся тестировщиками в систему.
Спасибо и вам, что поделились примерами.
"Главное не упарываться только в какую то одну метрику" - это точно! Эффект Гудхарта в чистом виде: когда метрика становится целью, она перестает быть метрикой.
Читерство метрик - печальная история. Вроде бы помогать должны, а происходит наоборот( KPI цели на метрики часто становятся причиной подгона метрик, а не изменения процессов.
"Время команды" и "время клиента" - мне нравится! Кажется, что через такие метафоры смысл метрик можно проще доносить. Запомню.
В вашей трактовке не очень поняла, чем Lead Time отличается от ТТМ?
А вообще тема очень интересная про терминологическую путаницу. Иногда ведь даже в рамках одной компании термины отличаются.. Главное, думаю, чтобы участники одного процесса понимали друг друга. С фиксацией своего понимания в глоссарии, желательно.
Хорошее уточнение про разницу между заказчиком и пользователем - это действительно разные углы оценки качества. NPS я не советую отбрасывать. Говорю только, что из моей практики считают его редко. Это не значит, что считать не надо. Напротив. Если у команды есть силы и ресурсы считать на постоянной основе - это определенно стоит делать! Не включила в итоговый список метрик как раз по причине сложности внедрения. Думаю, NPS можно включить во вторую волну "ответственности за качество", когда начнется работа вглубь.
А какие метрики вы относите к "про технический долг"? И что бы еще добавили "про качество продукта"?