Comments 8
В целом статья рассматривает качество не как на «поимку багов», а как на систему управления процессами - что гуд, но есть терминологическая путаница с Cycle Time и Lead Time. Lead Time — это время от возникновения потребности (заказ клиентом) до удовлетворения потребности (delivery). Это «время клиента». Cycle Time — это время, когда задача находится в работе команды (от момента, когда команда взяла задачу в работу, до момента готовности). Это «время команды».
Финальная оценка качества глазами заказчика и финальная оценка качества глазами пользователя — разные. Ваше замечание, что можно советовать «отбрасывать» NPS как неприменимый — что неправильно в последнем случае. Эту метрику сложнее внедрить в инженерный контур, но она критически важна.
Некоторые метрики скорее про технический долг, а не про качество продукта.
"Время команды" и "время клиента" - мне нравится! Кажется, что через такие метафоры смысл метрик можно проще доносить. Запомню.
В вашей трактовке не очень поняла, чем Lead Time отличается от ТТМ?
А вообще тема очень интересная про терминологическую путаницу. Иногда ведь даже в рамках одной компании термины отличаются.. Главное, думаю, чтобы участники одного процесса понимали друг друга. С фиксацией своего понимания в глоссарии, желательно.
Хорошее уточнение про разницу между заказчиком и пользователем - это действительно разные углы оценки качества. NPS я не советую отбрасывать. Говорю только, что из моей практики считают его редко. Это не значит, что считать не надо. Напротив. Если у команды есть силы и ресурсы считать на постоянной основе - это определенно стоит делать! Не включила в итоговый список метрик как раз по причине сложности внедрения. Думаю, NPS можно включить во вторую волну "ответственности за качество", когда начнется работа вглубь.
А какие метрики вы относите к "про технический долг"? И что бы еще добавили "про качество продукта"?
Достаточно интересная статья, спасибо.
Главное не упарываться только в какую то одну метрику - иначе будет плохой результат.
Работал в одном бигтехе и насмотрелся всякого страшного когда нужно было соблюсти чью-то лидовскою цель на рерфоманс ревью по метрикам забагованности мобильного приложения:
1) Выглядело как баг, звучало как баг - но заводится задачей т.к. функционал ещё не у пользователей.
Как итог, малое количество багов и красивая метрика забагованности продукта.
2) в таск-трекере все равно было много критов и блокеров - перед выставлением этого приоритета нужно было получать аппрувы от разрабов и менеджеров.
Естественно, это удлиняло правку багов (иногда не на один день), обязательно находилась причина почему краш приложения на старте на половине Самсунгов не должен правиться в этом релизе - зато метрика количества критов и блокеров была красивой.
Спасибо и вам, что поделились примерами.
"Главное не упарываться только в какую то одну метрику" - это точно! Эффект Гудхарта в чистом виде: когда метрика становится целью, она перестает быть метрикой.
Читерство метрик - печальная история. Вроде бы помогать должны, а происходит наоборот( KPI цели на метрики часто становятся причиной подгона метрик, а не изменения процессов.
Вы рекомендуете несколько метрик, основанных на том, сколько тесты поймали багов до релиза. Но если тесты автоматически запускаются для pull-request, то довольно сложно оценить сколько багов они поймали, потому что они будут запускаться и для совсем сырого кода. При этом мы скорее хотим так делать, чтобы как можно раньше выявить потенциальные проблемы и ловить их ветках разработчиков, а не в trunk/main.
Вы абсолютно правы. В случае наличия Quality Gate, автоматического запуска тестов для pull-request и политики зеленого билда - метрика теряет актуальность. Это уже другой уровень зрелости процессов в команде, тут и метрики нужны другие.
Метрика валидна, если по результату прогона тестов баги не фиксятся сразу разработчиками, а заводятся тестировщиками в систему.
У меня всегда начинает чесаться где-то под коленкой, когда что-то слышу про Качество и Эффективность, соответственно, выражения "с должным качеством" и "требуемой эффективностью" всегда забавляют, особенно, если далее или ранее нигде не расшифровано.
Спасибо, интересно было почитать
Что значит «отвечать за качество»?