Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Чисто гипотетически можно попытаться оценивать задачи в трекере в "попугаях" и установить норму — Х попугаев / месяц. Однако задачи все разные и попадаются такие, что неясно, как их оценить до завершения работы над ними.
Можно попробовать считать баги, но дело тоже мутное. Код во многом унаследован, пишется несколькими людьми, начнутся разборки, кто виноват и попытки свалить все на ушедших. Опять же, сложная задача — вероятно и багов будет много.
И что-то мне кажется, что такая оценка задач и разбор багов весьма трудоемки, это надо выделять отдельного и достаточно понимающего человека...
Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Здравствуйте, enji, Вы писали:
E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
E>Есть ли на эту тему что-то вменяемое?
Здравствуйте, enji, Вы писали: E>Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Информации полно (видео, книги), а что вменяемое или нет нужно определять самому. Для примера упрощённая схема:
роли в программных проектах
В итоге всё это нужно лишь менеджеру проекта, так как только он может повлиять на ситуацию. Прочитав разные книги, насмотревшись видеолекций у меня появилось своё мнение на этот счёт, вот только я не менеджер, а отсюда не берусь оценивать степень вменяемости.
Представим чисто умозрительно, что есть человек получивший в процессе работы чуть ли не учёную степень по палиндромам, и работает в компании, которая специализируется на палиндромах в Big Data. И он всем кандидатам при приёме даёт задание написать палиндром, а потом оценивает их производительность и качество работы используя некие метрики.
И первый вопрос который бы задал я, какова цель этих метрик, изменить работу менеджера, или просто тупо посчитать конечный результат и выдать вознаграждение. Про последнее, кстати, тоже не мало понаписали, в том числе и о влиянии бессмысленных вознаграждений в виде звёзд и прочего. E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Этим, кстати, можно не только увеличить мотивацию, но и уменьшить её. Более того, как говорят, сегодня роскошь, завтра необходимость. К премиям можно быстро привыкнуть и их невыплата станет фактором демотивации. Или предположим один человек считается для компании полезнее другого, что и отразилось в коэффициенте, но тот кому не выплачивают премию, потому что по мнению начальства он малополезен это заметит. E>Можно попробовать считать баги, но дело тоже мутное. Код во многом унаследован, пишется несколькими людьми, начнутся разборки, кто виноват и попытки свалить все на ушедших.
Что касается текучки людей, то это уже показатель эффективности работы организации. У людей есть не только краткосрочная мотивация, но и долгосрочная специализация. Предположим менеджер даёт задание специалисту по отсечению непечатаемых символов на концах строк написать палиндром. С одной стороны у программиста появляется дополнительная специальность, со временем она может вырасти.
С другой в команде мог быть человек у которого данная специализация изначально находится на более высоком уровне. Что толку поручать сантехнику провести электрическую сеть, а потом высчитывать коэффициент его полезности.
Здравствуйте, enji, Вы писали:
E>Есть ли на эту тему что-то вменяемое?
Есть. Мысль что это полная чушь
E>Какая-то популярная практика, что можно почитать?
Популярная и полезная практика — "не делай этого"
E>что можно почитать? Посмотреть.
Здравствуйте, enji, Вы писали:
E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Можно сделать регулярное performance review с использованием метода 360 градусов. В добавок, к обычному текстовому фидбеку ввести качественные оценки и использовать их среднее значение как KPI.
На мой взгляд, метод полезный и действительно может помочь оценить каждому сотруднику свои сильные и слабые стороны и таким образом повысить производительность. Конечно, требует усилий по внедрению и более-менее ответственного подхода со стороны сотрудников.
Но автоматического начисления премий по таким KPI все же лучше не делать.
E>Чисто гипотетически можно попытаться оценивать задачи в трекере в "попугаях" и установить норму — Х попугаев / месяц. Однако задачи все разные и попадаются такие, что неясно, как их оценить до завершения работы над ними.
Такое может подойти для саппорт проектов, для девелопмента — не очень.
Здравствуйте, enji, Вы писали: E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
наряду со своими KPI, добавьте еще статистику сколько из под определенного начальника ушло людей за год количественно и в процентах
Здравствуйте, enji,
E>Есть ли на эту тему что-то вменяемое?
Нет.
Более того: программисты (да и любые другие вменяемые инженеры) обычно очень неглупые люди. Они быстро научаются максимизировать этот самый KPI при минимальном уровне работы. К сожалению, 99% мальчиков с дипломами MBA не понимают, что это очень редко одновременно максимизирует пользу для бизнеса; чаще же бывает ровно наоборот.
Здравствуйте, Джеффри, Вы писали:
Д>Здравствуйте, enji, Вы писали:
E>>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Д>Можно сделать регулярное performance review с использованием метода 360 градусов. В добавок, к обычному текстовому фидбеку ввести качественные оценки и использовать их среднее значение как KPI.
Ага, и самой выигрышной стратегией становится со всеми соглашаться и ничего не делать, чтобы никого не обидеть. Тогда ты добрый отзывчивый чувак и большинство коллег тобой довольны.
Здравствуйте, bazis1, Вы писали:
B>Ага, и самой выигрышной стратегией становится со всеми соглашаться и ничего не делать, чтобы никого не обидеть. Тогда ты добрый отзывчивый чувак и большинство коллег тобой довольны.
И кто будет доволен, если ты ничего не будешь делать? Твои коллеги — нет (т.к. им придется за тебя все делать), твой лид — тоже нет (т.к. ничего не делается), заказчики — вообще вряд ли будут знать о твоем существовании.
Другое дело, если ты будешь со всем соглашаться и все делать. Ну, тогда производительность вырастет, как и хотел ТС.
На самом деле, за счет того, что в ревью вовлечены много людей, которые оценивают производительность с разных аспектов, то становится трудно подобрать стратегию, которая обманет их всех. Так что, на мой взгляд, единственная выигрышная стратегия здесь — просто делать свою работу хорошо и стараться исправить недостатки, на которые указывают в фидбеке.
Здравствуйте, enji, Вы писали:
E>Можно попробовать считать баги, но дело тоже мутное. Код во многом унаследован, пишется несколькими людьми, начнутся разборки, кто виноват и попытки свалить все на ушедших. Опять же, сложная задача — вероятно и багов будет много.
Ничего особо мутного нет, по крайней мере при статическом анализе E>И что-то мне кажется, что такая оценка задач и разбор багов весьма трудоемки, это надо выделять отдельного и достаточно понимающего человека...
и трудоёмкости тоже
E>Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Посмотри, например, это
По-моему, и на RSDN эти вопросы не раз поднимались.
Здравствуйте, enji, Вы писали:
E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. таточно понимающего человека... E>Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Самое вменяемое решение тут — объяснить озабоченому начальсву что все уважающие себя инженеры сбегут к более адекватному работадателю а оставшиеся будут занимаца повышением KPI в место того чтобы работать.
Здравствуйте, Джеффри, Вы писали:
Д>И кто будет доволен, если ты ничего не будешь делать? Твои коллеги — нет (т.к. им придется за тебя все делать), твой лид — тоже нет (т.к. ничего не делается), заказчики — вообще вряд ли будут знать о твоем существовании.
Аутсорс? В продуктовых компаниях часто бывает, что пока продукт продается, работу можно не делать, главное на митингах правильные вещи говорить.
Д>Другое дело, если ты будешь со всем соглашаться и все делать. Ну, тогда производительность вырастет, как и хотел ТС.
Тогда будешь вечной шестеркой, все будут недовольны, что не прочел мысли, помог другому быстрее, и т.п. И можешь забыть о повышении, ибо если тебя повысить, то кто будет работу делать? Плавали, знаем.
Д>На самом деле, за счет того, что в ревью вовлечены много людей, которые оценивают производительность с разных аспектов, то становится трудно подобрать стратегию, которая обманет их всех. Так что, на мой взгляд, единственная выигрышная стратегия здесь — просто делать свою работу хорошо и стараться исправить недостатки, на которые указывают в фидбеке.
В фидбеке укажут отговорки типа insufficient influence или not a strong team player, параллельно протащив наверх чувака, который с шефом ходил пиво пить, пока ты за него работу делал.
Здравствуйте, bazis1, Вы писали:
B>В фидбеке укажут отговорки типа insufficient influence или not a strong team player, параллельно протащив наверх чувака, который с шефом ходил пиво пить, пока ты за него работу делал.
Здравствуйте, bazis1, Вы писали:
B>Аутсорс? В продуктовых компаниях часто бывает, что пока продукт продается, работу можно не делать, главное на митингах правильные вещи говорить.
Как по мне, о результатах и производительности нужно думать, что в аутсорсе, что в продуктовых компаниях. В противном случае рано или поздно начнется застой, а потом будет крах.
B>Тогда будешь вечной шестеркой, все будут недовольны, что не прочел мысли, помог другому быстрее, и т.п. И можешь забыть о повышении, ибо если тебя повысить, то кто будет работу делать? Плавали, знаем.
Вообще-то я поставил там смайлик, что говорит о моем отношении к подобному подходу. Даже не знаю, что хуже, программист, который ни с чем не соглашается и ничего не хочет, или программист, который со всем согласен и на все готов. Кстати, я чаще последнее замечал за ПМ-ами и вот здесь, кстати, фидбек очень пригождается.
B>В фидбеке укажут отговорки типа insufficient influence или not a strong team player, параллельно протащив наверх чувака, который с шефом ходил пиво пить, пока ты за него работу делал.
Для этого и делают 360 градусов фидбек, чтобы мнение о сотруднике формировалось не одним только его менеджером. Вдобавок не забывай, что фидбек пишут не только о сотруднике, но и сотрудник пишет фидбек о своем менеджере и коллегах.
Здравствуйте, sergey2b, Вы писали:
B>>В фидбеке укажут отговорки типа insufficient influence или not a strong team player, параллельно протащив наверх чувака, который с шефом ходил пиво пить, пока ты за него работу делал. S>и какой из этого выход ?
Вероятно такой, что в данном случае продвигают того, кому начальство доверяет и считает лично себе полезным. И если продвижение и будет зависеть от технических навыков, то далеко не в первую очередь, а может даже и в последнюю. Следовательно из мотивации можно вычеркнуть такое понятие как карьерный рост. Ещё есть такие факторы как денежное вознаграждение (зарплата), условия труда (окружающая среда, удобство), атмосфера в коллективе (отношения с коллегами), личный интерес к проекту (собственные амбиции) и так далее.
Конечный же вывод каждый человек делает для себя сам, например, сменить работу, прикладывать меньше усилий, или ему вообще всё это фиолетово и он просто делает своё дело в прежнем темпе. Опять же всё это субъективные суждения конкретных людей. Не факт, что тот кто пил пиво с шефом плохой работник, а другой так прямо гений, может всё как раз наоборот. Но именно субъективная оценка участников процесса влияет на их дальнейшие действия.
А в целом первейший показатель неудовлетворённости работников это высокий уровень текучки. Это однозначно свидетельствует о том, что в компании не всё в порядке, то есть существуют какие-то сильно демотивирующие факторы.
Здравствуйте, Джеффри, Вы писали:
Д> Вдобавок не забывай, что фидбек пишут не только о сотруднике, но и сотрудник пишет фидбек о своем менеджере и коллегах.
Никто в обычной жизни не занимается такой фигней, как написание фидбэка за исключением случаев, если это является обязанностью (но для этих случаев уже придуманы генераторы отзывов).
Управляю вселенной не привлекая внимания санитаров.
Здравствуйте, Anton Batenev, Вы писали:
AB>Никто в обычной жизни не занимается такой фигней, как написание фидбэка за исключением случаев, если это является обязанностью (но для этих случаев уже придуманы генераторы отзывов).
Я бы так не сказал, что прямо "никто". Конечно, это зависит от корпоративной культуры и процессов, но практика performance review и написания фидбеков распространена в крупных компаниях. Во всяком случае, во всех компаниях, где я работал было именно так. Ну, а вообще — не хочешь писать фидбек, считаешь это глупостью? Не пиши, используй генераторы отзывов, только потом не стоит жаловаться на отсутствие карьерного роста, что тебя считают винтиком.
Здравствуйте, enji, Вы писали:
E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Результат будет предсказуем на 100%, но совпадать с декларируемой целью будет примерно на 0%
Ну не натягивается на настоящую инженерную работу KPI. Пусть машинисткам в машбюро KPI приклеивают куда-нибудь.
Здравствуйте, Джеффри, Вы писали:
Д> Я бы так не сказал, что прямо "никто". Конечно, это зависит от корпоративной культуры и процессов, но практика performance review и написания фидбеков распространена в крупных компаниях.
Да, и во всех этих компаниях она "для галочки", а не для людей. В эту игру могут играть только очень наивные инфантильные люди, коих в IT очень мало.
Д> Во всяком случае, во всех компаниях, где я работал было именно так. Ну, а вообще — не хочешь писать фидбек, считаешь это глупостью? Не пиши, используй генераторы отзывов, только потом не стоит жаловаться на отсутствие карьерного роста, что тебя считают винтиком.
Карьерный рост никак не зависит от фидбэка — надеюсь, ни для кого это не новость.
P.S. Впрочем, у описанной системы есть и положительные стороны — она очень быстро и эффективно вскрывает "гнойники".
Управляю вселенной не привлекая внимания санитаров.
