Комментарии 23
НЛО прилетело и опубликовало эту надпись здесь
Дмитрий, привет, а где-то встречали такое?
НЛО прилетело и опубликовало эту надпись здесь
Ага. Видел такое. Получается имитация бурной деятельности, спихивание ответственности на других (типа «у вас претензии к пуговицам есть?») и прочие прелести ввода KPI. :-)
Как только эти специальные люди начинают считать KPI программистов сидя в центральном офисе у PM «в полях» начинаются проблемы с командой проекта. Программисты очень не любят не понятных KPI, совещаний и прочих прелестей. Особенно когда их эффективность оценивает не понятно кто и не понятно как. Или уходят в другую крайность: формального достижения этих самих KPI без огонька и энтузиазма.
НЛО прилетело и опубликовало эту надпись здесь
Это ни разу не эффективно. Т.к. появляется еще одно звено в цепочке ПМ-..-разработчик. Причем, как правило, для Вашего случая не связанного с ПМ и самими людьми, кого обсчитывает.
Я не спорю, что метрики нужны, но в статье правильно написано, что это не вершина мастерства, а один из инструментов. Причем не самый главный. И для каждого проекта (команды) они могут иметь свои особенности. О которых Ваш специальный человек узнает, только после скандала из-за недоплаченных премий сотрудникам. И то не факт.
Я не спорю, что метрики нужны, но в статье правильно написано, что это не вершина мастерства, а один из инструментов. Причем не самый главный. И для каждого проекта (команды) они могут иметь свои особенности. О которых Ваш специальный человек узнает, только после скандала из-за недоплаченных премий сотрудникам. И то не факт.
По хорошему можно оценить только эффективность команды, а не отдельного члена команды.
НЛО прилетело и опубликовало эту надпись здесь
Не могли бы вы более полно раскрыть принципы измерения метрик? Как померить удовольствие от работы?!
Фокус-группы можно проводить, например.
Программировать им когда?
Интересно, присылайте ссылку.
а как же классификация задач и подходящих под них программистов?
у всех есть свои плюсы и минусы и неэффективно раздавая задачи производительность будет никакой
у всех есть свои плюсы и минусы и неэффективно раздавая задачи производительность будет никакой
А поясните мысль, пожалуйста, — круто, если на примере. Не до конца понятно, как вы видите такую классификацию
ну например, недалёкие, им можно давать простые задачи где надо, что-то добавить немного изменить или где много рутинной работы, что-то более сложное или если бага вдруг переходит в уровень сложных то такое им давать низя, скорее всего надо будет детально обьяснить как писать код с примерами, иногда такие учаться, а иногда вообще никак, но и для них работа найдётся
средненькие, которые не выдумывают новые подходы для решения задачи, а тупо делают по готовому шаблону, не особо задумываясь о будущем этого кода, делают обычно быстро если не возникает концептуальных вопросов
есть мегамозги которые делают довольно медленно по почти всегда очень хорошо, но может слишком сложно, им нужно давать сложные фичи и баги, но код надо ревьювить чтоб остальные тоже понимали что они натворили, и если совсем непонятно то пусть напишет попроще или обьяснит как с этим потом работать
и вот их всех надо как-то равномерно распределять между проэктами и задания давать подходящие по знаниям, а то будет неэффективно, одни могут заскучать другие обидеться если надо 10 раз подряд переделать, если же набирать только из одной категории, то получаем соответствующие минусы для этой категории, универсальных которые и умные и быстро делают там где надо и с рутинной работой готовы работать пока не встречал
средненькие, которые не выдумывают новые подходы для решения задачи, а тупо делают по готовому шаблону, не особо задумываясь о будущем этого кода, делают обычно быстро если не возникает концептуальных вопросов
есть мегамозги которые делают довольно медленно по почти всегда очень хорошо, но может слишком сложно, им нужно давать сложные фичи и баги, но код надо ревьювить чтоб остальные тоже понимали что они натворили, и если совсем непонятно то пусть напишет попроще или обьяснит как с этим потом работать
и вот их всех надо как-то равномерно распределять между проэктами и задания давать подходящие по знаниям, а то будет неэффективно, одни могут заскучать другие обидеться если надо 10 раз подряд переделать, если же набирать только из одной категории, то получаем соответствующие минусы для этой категории, универсальных которые и умные и быстро делают там где надо и с рутинной работой готовы работать пока не встречал
Почему все так любят измерять эффективность разработчиков? Почему никто не измеряет эффективность менеджеров?
Привет, так одно не отрицает другого — для оценки качества менеджмента есть свои подходы, частично пересекающиеся: опросы, достижение результатов в рамках квартала/года и пр, опять же, вопрос верно выбранных метрик и зачем мы их вводим. Но, кажется, Хабр просто меньше ресурс о менеджменте, поэтому мы больше говорим здесь о командах разработки)
Как можно измерить того, чего нет? :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как измерить эффективность и решать проблемы разработчиков, если у тебя их сто