Способность стабильно выдавать ожидаемый результат и выполнять взятые на себя обязательства - это действительно базовый показатель работы разработчика. Это важно для бизнеса и если этого нет, то дальше идти смысла нет. Но статья всё-таки больше не про метрики, а про то, как можно достаточно просто настроить контроль за ними с помощью Grafana. Сами метрики каждый может выбирать исходя из своих соображений. Кроме того, никто не говорит, что метрики должны быть всегда одинаковыми. Если вы видите проблемы - вы решаете с помощью какой метрики можно их отследить и выносите её на борд. Начинаете следить, ставите команде в KPI, если у вас в компании это принято. Со временем ситуация начинает выравниваться, главное при этом не уронить другие важные показатели.
Разработчик ведь не сам выбирает проекты, которые он должен делать, для этого Продукт есть. Если человек не приносит ценности бизнесу - это проблема Продукта, который нерационально использует его ресурсы. Если человек качественно и вовремя делает свою работу - то да, повышать при наличии возможности.
А про любимчиков вывод напрашивается сам собой. Т.к. не измеряя фактическую производительность человека у тимлида складывается лишь поверхностное ощущение. Да и указанный вами кейс происходит далеко не со всеми и уж точно не регулярно. Что вы будете делать, когда ничего выдающегося никто не сделал, но все хотят повышения?
Т.е. в вашем случае тимлид выбирает себе любимчиков и карьерный рост строится на основе хороших отношений с тимлидом. Мне вот не кажется это справедливым.
Ок. Вот вы тимлид. У вас нет грейдирования, в принципе нет каких либо измерений производительности. Вот приходит к вам сотрудник и говорит - хочу больше денег. Что вы ему ответите?
Хакнуть то можно. Вопрос в том, зачем делать это поощряемым поведением, создавая прямую связь между завышением оценок и повышением по грейду.
Нормальное поведение, где разработчик старается оценивать задачи честно, при этом, наоборот, оказывается невыгодным
Для грейдирования у нас каждый разработчик проходит оценку разными респондентами. Указанные 3 метрики - это только часть из показателей, которые можно легко измерить. Насколько мне известно, пока ни у одной компании в мире нет объективного способа оценки разработчиков. Но при этом у каждой компании есть потребность в их оценке, иначе нельзя будет понять можно ли увеличить сотруднику оклад или нет, подходит ли он по результатам испытательного срока на выбранный уровень или его уровень ниже/выше. Поэтому метрики нужны, а бороться с злоупотреблением нужно за счёт культуры.
Секрет повышения в Skyeng - завышать эстимейты по задачам. Чем сильнее завысишь, тем лучше.
Это так не работает. Если завышаешь оценки по задачам, то их не берут в работу, т.к. проект становится не таким экономически привлекательным. Да и тимлид есть, который может спросить почему оценка настолько высока. Впрочем, хакнуть возможно любую метрику по отдельности при желании. В данной метрике можно логировать время на 5 минут меньше изначальной оценки, а остальное списывать на митинги, например. Если задача заняла примерно то же самое время, то никто этого и не заметит. Но если мы практически уложились по задаче в оценку, то это ведь хорошо, не так ли? А вот чтобы избежать более серьёзных отклонений нужно смотреть и на другие метрики, например, на количество времени, потраченных на митинги.
Как метрики чтобы оценивать грейд разработчиков - написание автотестов, кажется, должно быть более важной задачей, чем попытка вывести разработчика который баги не производит.
Тут не всё так просто, как кажется на первый взгляд. Автотесты делают разработку дороже в 1,5 - 2 раза, а если автотесты пишут сами разработчики, то ещё и увеличивает на столько же время выполнения задач. Поэтому к автотестам нужно подходить обдуманно. Я считаю, что точно нужно покрывать критически важный функционал и писать тесты по найденным багам, особенно если они были найдены на проде. Но ставить себе планку в какой-то процент покрытия тестами кода не стоит, т.к. это приведёт к излишним тратам. Автотесты - это как страховка, можно купить себе полное КАСКО и застраховаться от всего или почти от всего (читаем условия, написанные мелкими буквами), а можно застраховать только отдельные риски - угон, тотал. Каждый сам решает в соответствии с его бизнесом что ему важнее - принять риск или заплатить больше, но застраховаться от всего.
На сколько, по вашему мнению, улучшился рабочий процесс? Стали ли они укладываться в сроки?
Я бы не сказал, что дашборд сам по себе улучшает рабочий процесс. Скорее он облегчает работу тимлиду и позволяет вовремя находить аномалии. Результаты улучшаются за счёт того, что становится понятным с кем и над чем работать. Например, проблемы с долгим Code Review мы убрали в большинстве случаев. Дашборд делает процессы и результаты по ним более прозрачными. Одно дело сказать человеку: "мне кажется, что ты плохо перформишь", и совсем другое показать на графике результаты в сравнении с другими членами команды.
Повлияли ли на мотивацию ребят эта дашборда?
Да, писал про это, когда описывал виджет "Top sprint performance developers". Ребята начинают соревноваться друг с другом за лучший perfomance. Плюс тут появляется неплохое поле для дополнительной мотивации. Например, наградить лучшего перформера за спринт / квартал. Или хотя бы просто похвалить человека, который первым выполнил взятый на себя объем работ.
Что происходит с ребятами, у которых низкие показатели?
У нас собралась довольно сильная команда. Если новенький видит, что он не дотягивает до уровня остальных, то он всячески пытается как можно быстрее нагнать, чтобы остаться в команде профессионалов. Реальный кейс - у меня человек самостоятельно проанализировал свои результаты на основе борда и нашёл причину из-за которой у него не получалось работать с достаточной производительностью. Немного поменяв свой образ жизни, ему удалось повысить свою производительность почти в два раза, да и на общем самочувствии сказалось положительно. Я бы точно не смог это сделать за него, особенно учитывая удалённый формат работы. Конечно, не всегда всё может закончиться хорошо, но на это и есть испытательный срок.
Способность стабильно выдавать ожидаемый результат и выполнять взятые на себя обязательства - это действительно базовый показатель работы разработчика. Это важно для бизнеса и если этого нет, то дальше идти смысла нет. Но статья всё-таки больше не про метрики, а про то, как можно достаточно просто настроить контроль за ними с помощью Grafana. Сами метрики каждый может выбирать исходя из своих соображений. Кроме того, никто не говорит, что метрики должны быть всегда одинаковыми. Если вы видите проблемы - вы решаете с помощью какой метрики можно их отследить и выносите её на борд. Начинаете следить, ставите команде в KPI, если у вас в компании это принято. Со временем ситуация начинает выравниваться, главное при этом не уронить другие важные показатели.
Разработчик ведь не сам выбирает проекты, которые он должен делать, для этого Продукт есть. Если человек не приносит ценности бизнесу - это проблема Продукта, который нерационально использует его ресурсы. Если человек качественно и вовремя делает свою работу - то да, повышать при наличии возможности.
А про любимчиков вывод напрашивается сам собой. Т.к. не измеряя фактическую производительность человека у тимлида складывается лишь поверхностное ощущение. Да и указанный вами кейс происходит далеко не со всеми и уж точно не регулярно. Что вы будете делать, когда ничего выдающегося никто не сделал, но все хотят повышения?
Т.е. в вашем случае тимлид выбирает себе любимчиков и карьерный рост строится на основе хороших отношений с тимлидом. Мне вот не кажется это справедливым.
Ок. Вот вы тимлид. У вас нет грейдирования, в принципе нет каких либо измерений производительности. Вот приходит к вам сотрудник и говорит - хочу больше денег. Что вы ему ответите?
Результат работы руководителя - это результат работы его команды. Можно те же самые графики взять и посмотреть общие цифры.
Для грейдирования у нас каждый разработчик проходит оценку разными респондентами. Указанные 3 метрики - это только часть из показателей, которые можно легко измерить. Насколько мне известно, пока ни у одной компании в мире нет объективного способа оценки разработчиков. Но при этом у каждой компании есть потребность в их оценке, иначе нельзя будет понять можно ли увеличить сотруднику оклад или нет, подходит ли он по результатам испытательного срока на выбранный уровень или его уровень ниже/выше. Поэтому метрики нужны, а бороться с злоупотреблением нужно за счёт культуры.
Это так не работает. Если завышаешь оценки по задачам, то их не берут в работу, т.к. проект становится не таким экономически привлекательным. Да и тимлид есть, который может спросить почему оценка настолько высока. Впрочем, хакнуть возможно любую метрику по отдельности при желании. В данной метрике можно логировать время на 5 минут меньше изначальной оценки, а остальное списывать на митинги, например. Если задача заняла примерно то же самое время, то никто этого и не заметит. Но если мы практически уложились по задаче в оценку, то это ведь хорошо, не так ли? А вот чтобы избежать более серьёзных отклонений нужно смотреть и на другие метрики, например, на количество времени, потраченных на митинги.
Тут не всё так просто, как кажется на первый взгляд. Автотесты делают разработку дороже в 1,5 - 2 раза, а если автотесты пишут сами разработчики, то ещё и увеличивает на столько же время выполнения задач. Поэтому к автотестам нужно подходить обдуманно. Я считаю, что точно нужно покрывать критически важный функционал и писать тесты по найденным багам, особенно если они были найдены на проде. Но ставить себе планку в какой-то процент покрытия тестами кода не стоит, т.к. это приведёт к излишним тратам. Автотесты - это как страховка, можно купить себе полное КАСКО и застраховаться от всего или почти от всего (читаем условия, написанные мелкими буквами), а можно застраховать только отдельные риски - угон, тотал. Каждый сам решает в соответствии с его бизнесом что ему важнее - принять риск или заплатить больше, но застраховаться от всего.
Я бы не сказал, что дашборд сам по себе улучшает рабочий процесс. Скорее он облегчает работу тимлиду и позволяет вовремя находить аномалии. Результаты улучшаются за счёт того, что становится понятным с кем и над чем работать. Например, проблемы с долгим Code Review мы убрали в большинстве случаев. Дашборд делает процессы и результаты по ним более прозрачными. Одно дело сказать человеку: "мне кажется, что ты плохо перформишь", и совсем другое показать на графике результаты в сравнении с другими членами команды.
Да, писал про это, когда описывал виджет "Top sprint performance developers". Ребята начинают соревноваться друг с другом за лучший perfomance. Плюс тут появляется неплохое поле для дополнительной мотивации. Например, наградить лучшего перформера за спринт / квартал. Или хотя бы просто похвалить человека, который первым выполнил взятый на себя объем работ.
У нас собралась довольно сильная команда. Если новенький видит, что он не дотягивает до уровня остальных, то он всячески пытается как можно быстрее нагнать, чтобы остаться в команде профессионалов. Реальный кейс - у меня человек самостоятельно проанализировал свои результаты на основе борда и нашёл причину из-за которой у него не получалось работать с достаточной производительностью. Немного поменяв свой образ жизни, ему удалось повысить свою производительность почти в два раза, да и на общем самочувствии сказалось положительно. Я бы точно не смог это сделать за него, особенно учитывая удалённый формат работы.
Конечно, не всегда всё может закончиться хорошо, но на это и есть испытательный срок.