👀 Чем измерить качество своей работы, кроме строк кода и закрытых задач? Количество строк кода — метрика, которая давно стала мемом. Кто-то до сих пор шутит про «чем больше строк, тем лучше», кто-то всерьез пытался ее запретить. С закрытыми тикетами та же история: можно закрыть сто задач по исправлению опечаток в документации, и это не изменит продукт. А можно закрыть одну задачу, которая долго блокировала команду, — и после нее разработка пойдет в разы быстрее. Если отбросить эти две крайности, остается несколько рабочих способов понять, приносишь ли ты пользу. 🔴 Время от идеи до продакшена Период от попадания задачи в бэклог до момента, когда она заработала у пользователей. Метрика показывает зрелость процессов не только в разработке, но и в смежных областях. Если релиз тормозят согласования, а не код, это повод пересмотреть процессы. 🔴 Частота релизов Количество выкаток на прод за единицу времени. Чем выше частота, тем ниже риски каждой отдельной выкатки. Метрика отражает не скорость написания кода, а выстроенность процесса доставки изменений. 🔴 Количество откатов и инцидентов после релиза Если каждый релиз сопровождается сбоями, то качество страдает. Динамика важнее абсолютных значений: если месяц назад инцидентов было три, а сейчас один, процессы улучшаются. 🔴 Время восстановления после сбоя Сбои неизбежны. Ключевой параметр — скорость возвращения системы в рабочее состояние. Разработчик влияет на эту метрику через качество кода, логи, документацию. 🔴 % переделок Процент задач, которые возвращаются на доработку не из-за багов, а из-за изменения требований. Высокий % указывает на разрывы в коммуникации с заказчиком или нечеткие формулировки на старте. 🔴 Код-ревью: время и глубина Скорость ревью — тоже показатель. Если твой код висит два дня без обратной связи, работа однозначно тормозится. Качество ревью сложнее померить, но можно хотя бы отслеживать, сколько замечаний приходит на этапе ревью и сколько багов улетает в прод. Со временем хорошая команда выявляет большинство проблем до того, как код попал к пользователям. 🔴 Возвращаемость к коду Через месяц после того, как ты сдал задачу, приходится к ней возвращаться, чтобы разобраться, как она работает, или починить то, что сломалось? Если да — возможно, стоило лучше задокументировать или написать понятнее. Хороший код не требует постоянных экскурсов. Его читают, понимают и идут дальше. Какими метриками пользуешься ты? Или предпочитаешь вообще не заморачиваться измерениями? 🧐 💃 Подписывайся на GeekOn | GeekSourceJobs