#вопрос Как измерить скорость работы разработчика?
Один мой знакомый CEO решил, что его разработчики работают не очень быстро и надо бы измерить их скорость. Для этого было предложено поставить следящий за экраном софт и смотреть сколько они провели в IDE за написанием кода. Если меньше 6 часов - значит он явно бездельничал.
Мы с вами понимаем, что это так не работает. Когда ты пишешь код, ты можешь час просидеть с листком бумаги, прикидывая архитектуру или ходя кругами по комнате обдумывая решение. Я уже не говорю про ночные озарения, когда тебе посреди ночи приходит простое решение задачи, на которой ты застрял ещё днём. Написание кода - процесс творческий. Так же и дизайнеры не сидят в фигме 100% времени, а ищут вдохновение и смотрят лучшие практики. Да, есть иногда монотонное написание кода, когда архитектура и компоненты готовы и надо фигачить одинаковые формы или верстать однотипные посадки. Но все равно изменять время проведённое в IDE нельзя.
Как же понять производительность разработчика? В первую очередь по результату. Упрощенно - готова ли задача к обещанному сроку. Если более сложно, то я, например, оцениваю по числу затраченных часов на 1 StoryPoint (далее SP). То есть на планировании команда согласилась что задача X займёт 2 SP (метрика сложности / времени задачи) методом Scrum Pocker (про него будет отдельный пост). Если на неё было потрачено 20 часов рабочего времени - то скорость такого разработчика 10 часов на 1 SP.
На интервале 3 месяца сразу видно, что Senior разработчики имеют скорость от 6 до 8, а junior около 20 (цифры могут быть разными в разных компаниях, так как понятие SP может разниться). И это как раз позволяет отслеживать прогресс отдельно взятого разработчика. Если метрика сокращается - значит он уже познакомился с кодовой базой и растёт в профессиональном плане.
Но важно, чтобы эта метрика не влияла на премии, иначе она перестаёт быть объективной и все начинают переоценивать задачи. А как у вас в компании отслеживается производительность? Было бы интересно в комментариях собрать разные метрики производительности.
Один мой знакомый CEO решил, что его разработчики работают не очень быстро и надо бы измерить их скорость. Для этого было предложено поставить следящий за экраном софт и смотреть сколько они провели в IDE за написанием кода. Если меньше 6 часов - значит он явно бездельничал.
Мы с вами понимаем, что это так не работает. Когда ты пишешь код, ты можешь час просидеть с листком бумаги, прикидывая архитектуру или ходя кругами по комнате обдумывая решение. Я уже не говорю про ночные озарения, когда тебе посреди ночи приходит простое решение задачи, на которой ты застрял ещё днём. Написание кода - процесс творческий. Так же и дизайнеры не сидят в фигме 100% времени, а ищут вдохновение и смотрят лучшие практики. Да, есть иногда монотонное написание кода, когда архитектура и компоненты готовы и надо фигачить одинаковые формы или верстать однотипные посадки. Но все равно изменять время проведённое в IDE нельзя.
Как же понять производительность разработчика? В первую очередь по результату. Упрощенно - готова ли задача к обещанному сроку. Если более сложно, то я, например, оцениваю по числу затраченных часов на 1 StoryPoint (далее SP). То есть на планировании команда согласилась что задача X займёт 2 SP (метрика сложности / времени задачи) методом Scrum Pocker (про него будет отдельный пост). Если на неё было потрачено 20 часов рабочего времени - то скорость такого разработчика 10 часов на 1 SP.
На интервале 3 месяца сразу видно, что Senior разработчики имеют скорость от 6 до 8, а junior около 20 (цифры могут быть разными в разных компаниях, так как понятие SP может разниться). И это как раз позволяет отслеживать прогресс отдельно взятого разработчика. Если метрика сокращается - значит он уже познакомился с кодовой базой и растёт в профессиональном плане.
Но важно, чтобы эта метрика не влияла на премии, иначе она перестаёт быть объективной и все начинают переоценивать задачи. А как у вас в компании отслеживается производительность? Было бы интересно в комментариях собрать разные метрики производительности.