Комментарии 21
На сколько, по вашему мнению, улучшился рабочий процесс? Повлияли ли на мотивацию ребят эта дашборда? Стали ли они укладываться в сроки? Что происходит с ребятами, у которых низкие показатели?
На сколько, по вашему мнению, улучшился рабочий процесс?
Стали ли они укладываться в сроки?
Я бы не сказал, что дашборд сам по себе улучшает рабочий процесс. Скорее он облегчает работу тимлиду и позволяет вовремя находить аномалии. Результаты улучшаются за счёт того, что становится понятным с кем и над чем работать. Например, проблемы с долгим Code Review мы убрали в большинстве случаев. Дашборд делает процессы и результаты по ним более прозрачными. Одно дело сказать человеку: "мне кажется, что ты плохо перформишь", и совсем другое показать на графике результаты в сравнении с другими членами команды.
Повлияли ли на мотивацию ребят эта дашборда?
Да, писал про это, когда описывал виджет "Top sprint performance developers". Ребята начинают соревноваться друг с другом за лучший perfomance. Плюс тут появляется неплохое поле для дополнительной мотивации. Например, наградить лучшего перформера за спринт / квартал. Или хотя бы просто похвалить человека, который первым выполнил взятый на себя объем работ.
Что происходит с ребятами, у которых низкие показатели?
У нас собралась довольно сильная команда. Если новенький видит, что он не дотягивает до уровня остальных, то он всячески пытается как можно быстрее нагнать, чтобы остаться в команде профессионалов. Реальный кейс - у меня человек самостоятельно проанализировал свои результаты на основе борда и нашёл причину из-за которой у него не получалось работать с достаточной производительностью. Немного поменяв свой образ жизни, ему удалось повысить свою производительность почти в два раза, да и на общем самочувствии сказалось положительно. Я бы точно не смог это сделать за него, особенно учитывая удалённый формат работы.
Конечно, не всегда всё может закончиться хорошо, но на это и есть испытательный срок.
Чтобы определить грейд, необходимо знать точные цифры по каждому разработчику:
...
% задач, которые были сделаны быстрее, чем их оценивали.
Секрет повышения в Skyeng - завышать эстимейты по задачам. Чем сильнее завысишь, тем лучше.
А если без сарказма, от всей статьи ощущение будто разработчиков по строчкам кода оценивают. Метрики то подобрали посложнее, но суть та же.
Как показатели для нахождения узких мест в процессе - да, конечно.
Как возможность заметить, что поведение конкретного разработчика изменилось, и спросить, что у него случилось - ок.
Как метрики чтобы оценивать грейд разработчиков - написание автотестов, кажется, должно быть более важной задачей, чем попытка вывести разработчика который баги не производит.
Секрет повышения в Skyeng - завышать эстимейты по задачам. Чем сильнее завысишь, тем лучше.
Это так не работает. Если завышаешь оценки по задачам, то их не берут в работу, т.к. проект становится не таким экономически привлекательным. Да и тимлид есть, который может спросить почему оценка настолько высока. Впрочем, хакнуть возможно любую метрику по отдельности при желании. В данной метрике можно логировать время на 5 минут меньше изначальной оценки, а остальное списывать на митинги, например. Если задача заняла примерно то же самое время, то никто этого и не заметит. Но если мы практически уложились по задаче в оценку, то это ведь хорошо, не так ли? А вот чтобы избежать более серьёзных отклонений нужно смотреть и на другие метрики, например, на количество времени, потраченных на митинги.
Как метрики чтобы оценивать грейд разработчиков - написание автотестов, кажется, должно быть более важной задачей, чем попытка вывести разработчика который баги не производит.
Тут не всё так просто, как кажется на первый взгляд. Автотесты делают разработку дороже в 1,5 - 2 раза, а если автотесты пишут сами разработчики, то ещё и увеличивает на столько же время выполнения задач. Поэтому к автотестам нужно подходить обдуманно. Я считаю, что точно нужно покрывать критически важный функционал и писать тесты по найденным багам, особенно если они были найдены на проде. Но ставить себе планку в какой-то процент покрытия тестами кода не стоит, т.к. это приведёт к излишним тратам. Автотесты - это как страховка, можно купить себе полное КАСКО и застраховаться от всего или почти от всего (читаем условия, написанные мелкими буквами), а можно застраховать только отдельные риски - угон, тотал. Каждый сам решает в соответствии с его бизнесом что ему важнее - принять риск или заплатить больше, но застраховаться от всего.
Впрочем, хакнуть возможно любую метрику по отдельности при желании
Хакнуть то можно. Вопрос в том, зачем делать это поощряемым поведением, создавая прямую связь между завышением оценок и повышением по грейду.
Нормальное поведение, где разработчик старается оценивать задачи честно, при этом, наоборот, оказывается невыгодным.
Автотесты - это как страховка, можно купить себе полное КАСКО и застраховаться от всего или почти от всего (читаем условия, написанные мелкими буквами), а можно застраховать только отдельные риски - угон, тотал. Каждый сам решает в соответствии с его бизнесом что ему важнее - принять риск или заплатить больше, но застраховаться от всего.
Имхо, автотесты это одно из обязательных условий для того чтобы:
а) Иметь хоть какие-то гарантии в долгосрочной перспективе;
б) Иметь возможность поддерживать короткий цикл обратной связи.
Без них цена и время ручного регрессионного тестирования будет постоянно увеличиваться.
Но ставить себе планку в какой-то процент покрытия тестами кода не стоит, т.к. это приведёт к излишним тратам.
Действительно, не стоит. К любым метрикам нужно относиться настороженно, чтобы они не приводили к излишним тратам.
Работа не ради метрик делается, всё таки - об этом оба мои комментария под вашей статьёй.
Хакнуть то можно. Вопрос в том, зачем делать это поощряемым поведением, создавая прямую связь между завышением оценок и повышением по грейду.
Нормальное поведение, где разработчик старается оценивать задачи честно, при этом, наоборот, оказывается невыгодным
Для грейдирования у нас каждый разработчик проходит оценку разными респондентами. Указанные 3 метрики - это только часть из показателей, которые можно легко измерить. Насколько мне известно, пока ни у одной компании в мире нет объективного способа оценки разработчиков. Но при этом у каждой компании есть потребность в их оценке, иначе нельзя будет понять можно ли увеличить сотруднику оклад или нет, подходит ли он по результатам испытательного срока на выбранный уровень или его уровень ниже/выше. Поэтому метрики нужны, а бороться с злоупотреблением нужно за счёт культуры.
Грейдирование это какой-то полный ад.
Ну т.е.вместо желания поработать, 100% все люди будут перезакладываться в сроки. И норм сеньор объяснит тимлиду, почему они такие завышенные) если тимлид норм сеньер, то его надо уволить и взять нормального, который будет команду качать, а не код писать. Убрать все три метрики из грейдирования, еще лучше убрать код-ревью, но это слишком зрелая команда должна быть)
Ок. Вот вы тимлид. У вас нет грейдирования, в принципе нет каких либо измерений производительности. Вот приходит к вам сотрудник и говорит - хочу больше денег. Что вы ему ответите?
Ну если у вас либо никак, либо только так, то лучше никак:) но вообще в каждом случае что-то индивидуальное отвечу. Опираться нужно на какие-то достижения, проактивность и всякое такое, что мы в рамках 1-1 и активностей команды будем обсуждать и за что ему будут давать обратную связь. может быть он что-то новое выучил и от этого бизнес получил стопицот миллионов или придумал какую-то крутую штуку, которая позволила избежать потерь. Все очень индивидуально. Это просто примеры. Когда всех одинаково оцениваешь, получается как в школе. Для джунов еще с горем можно применить, кроме попадения в срок. Это вообще полный провал в плане kpi. Куча литературы на эту тему написана, можно почитать.
Т.е. в вашем случае тимлид выбирает себе любимчиков и карьерный рост строится на основе хороших отношений с тимлидом. Мне вот не кажется это справедливым.
А в каком месте вы прочитали про любимчиков? Где было про бизнес-результаты, наверное) если человек не приносит ценности бизнесу, но круто попадает в сроки, то ему из-за этого пересматривать зарплату чтоль?
Разработчик ведь не сам выбирает проекты, которые он должен делать, для этого Продукт есть. Если человек не приносит ценности бизнесу - это проблема Продукта, который нерационально использует его ресурсы. Если человек качественно и вовремя делает свою работу - то да, повышать при наличии возможности.
А про любимчиков вывод напрашивается сам собой. Т.к. не измеряя фактическую производительность человека у тимлида складывается лишь поверхностное ощущение. Да и указанный вами кейс происходит далеко не со всеми и уж точно не регулярно. Что вы будете делать, когда ничего выдающегося никто не сделал, но все хотят повышения?
Хорошо. Попробую с другой стороны. Что вы хотите от сотрудника, когда нанимаете и чтобы он делал хорошо?
Неужели вы реально хотите чтобы он точно попадал в сроки, даже если это вдруг бы стало возможным?
Подумайте просто, что именно для вас хорошое результаты от сотрудника и как это можно померить.
Плюс, что именно ожидается от команды в рамках результата, точно ли нужны прям конкретные показатели или хватит просто вероятности выполнения на основе исторических данных и можно вообще не делать оценку, чтобы не тратить время?
Точно ли не существует других способов для ответа на вопрос когда?
Есть ли еще какие-то подходы по оценке, которые могут быть полезны людям?
Я не вижу смысла в споре, когда человек даже не пытается понять чужую точку зрения, сорямба.
Желаю удачи вам:)
Тут классическая управленческая управленческая ошибка. Мерять не рутину, как рутину. Вы потратили время зря.
Вопросы на котором вы засыпетесь. Вот, вы руководитель. От ваших решений в первую очередь зависит успех команды. Соответственно, в первую очередь надо оценивать собственные решения. Есть ли у вас такой дашборд о себе? Какие решения удачные, какие неудачные, сколько времени вы реально в день работаете концентрированно и над какими задачами, на что входит больше всего времени, как это коррелирует с финансами личными и компании? В виде графика и цифр, пожалуйста.
На самом деле очень не плохая статья в плане получения ответа на вопрос "А стоит ли идти разработчиком в команду Teachers Platform в SkyEng?"
Кроме логворка стоит еще добавить мониторинг активности приложений на рабочем месте разработчика, а то вдруг они говорят, что работают, а сами хабр читают. Еще из похожих практик можно еще попробовать измерять Code Churn - как часто меняется тот или иной участок кода в пределах задачи. А то пишут сразу в лоб, а потом переделывают и растяuивают задачу </сарказм>
А если серьезно, из статьи непонятно из каких предпосылок выросла такая аналитика. Почему основным показателем эффективности считается попадание в часы и зачем они меряется на столько точно? Неужели основной выхлоп разработчика это количество закрытых часов в проекте?
Способность стабильно выдавать ожидаемый результат и выполнять взятые на себя обязательства - это действительно базовый показатель работы разработчика. Это важно для бизнеса и если этого нет, то дальше идти смысла нет. Но статья всё-таки больше не про метрики, а про то, как можно достаточно просто настроить контроль за ними с помощью Grafana. Сами метрики каждый может выбирать исходя из своих соображений. Кроме того, никто не говорит, что метрики должны быть всегда одинаковыми. Если вы видите проблемы - вы решаете с помощью какой метрики можно их отследить и выносите её на борд. Начинаете следить, ставите команде в KPI, если у вас в компании это принято. Со временем ситуация начинает выравниваться, главное при этом не уронить другие важные показатели.
Есть такое понятие - вариативность процесса. Вариативность процесса разработки ПО очень высока. Одну и ту же задачу разработчик может сделать и за один час - и за десять. И это нормально - если время находится в пределах вариативности процесса. При этом, вариации бывают системными и несистемными. Не меняя процесса - можно как-то бороться с несистемными вариациями. Если же пробовать изменить системную вариацию, не меняя процесса - т.е. несистемными методами - результат будет только хуже. Это наглядно демонстрирует эксперимент Деминга "Воронка и мишень" - https://advanced-quality-tools.ru/deming-funnelexperiment.html
Измеряем команду с JIRA и Grafana: sprint reports, грейдирование и не только