E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Первый признак того, что начальства слишком много и им нечем заняться.
E>И что-то мне кажется, что такая оценка задач и разбор багов весьма трудоемки, это надо выделять отдельного и достаточно понимающего человека...
Отдел, отдел под это нужно выделять. Кстати, можешь эту мысль озвучить начальству с тонким намеком, что можешь этот отдел возглавить. Как ты уже сам понял, задача не из простых. Поэтому, когда оценка по KPI не приведет к улучшению финансовых показателей, на совещании у начальства потребуй прокачать отдел до управления, с отделами методологии, оперативного контроля, отдела информационной поддержки процессов оценки KPI, ну для начала хватит. Естественно с увеличением бюджета и штатных позиций. Итого у тебя будет в подчинении три отдела, человек по пять в каждом и строчка в резюме «создал процесс управления эффективностью бизнеса с нуля, руководил управлением из трех отделов» . Дальше можно подумать об аппарате управления, ну там секретариат (секретарша, делопроизводитель). В этот момент придет понимание, что работы очень много и три отдела уже не справляются, надо расширяться. Да и не забывай о себе, как начальнику такого важного, не побоюсь этого слова, ключевого управления, тебе потребуется постоянное повышение квалификации, ну там MBA (лучше, конечно, в чикагской школе бизнеса, но и стокгольмская тоже сойдет), естественно участие во всяких конференциях. Когда начальство начнет что-то подозревать можно уже свалить в другую контору, с солидным резюме.
Здравствуйте, enji, Вы писали:
E>Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
У нас давно работает Performance BI своей разработки. В свое время эта система привела к коммерческому прорыву компании, увеличила прибыль компании раза в два.
Но это не KPI. И работает только если ты делаешь не внутренний продукт, а внешние проекты.
Суть системы.
1. Каждый сотрудник заполняет отчет, на какой проект он сегодня сколько часов потратил.
2. Вся эта информация сливается в куб, где на основе нее рассчитывается себестоимость (в рублях), каждого проекта.
3. Когда завершается проект, считается чистая прибыль (деньги полученные от клиента — полная себестоимость проекта).
4. Определенный процент чистой прибыли формирует премиальный фонд проекта.
5. Премиальный фонд проекта выплачивается команде, пропорционально трудозатратам каждого участника на проект.
Например Петя потратил на проект 5 часов, Вася 3 часа, Миша 2 часа. Петя получит 50% премиального фонда, Вася 30% и т.п.
6. Премия идет в дополнение к зарплате. Фиксированная з.п. ни при каких условиях не может уменьшится.
Так, премия за 2 полугодие 2015 принесла сотрудникам от 1.5 до 4 зарплат. Премиальный фонд этого полугодия был равен двум месячным фондам оплаты труда. Т.е. премия может быть интересной.
К чему это привело?
А. Менеджеры проекта стали с большой неохотой брать доп. обязательства сверх контракта, т.к. это увеличит себестоимость и уменьшит премиальный фонд.
Б. Участники проекта стали заботиться о экономии трудозатрат. Да, ты можешь эту задачу сделать за 10 часов, а можешь и за 2. Если сделаешь за 2 — премиальный фонд будет выше.
В. Главное. Цели каждого участника проекта и цели бизнеса стали совпадать — все заинтересованы сделать прибыльный проект.
Есть важные нюансы.
1. У конкретного сотрудника может быть мотивация потратить больше времени на проект, тем самым увеличив свою долю в премии (но при этом премиальный фонд снизится).
Эту тему контролируют коллеги, которые не хотят чтобы раздувалсь трудозатраты их проекта.
2. Программист или аналитик могут иметь мотивацию сделать что-то быстро но не качественно. Но против этого работает контроль качества.
Т.е. мы никогда не выдадим заказчику не качественный модуль, может быть даже 5 возвратов программисту. Опять же у нас обязателен код ревью, поэтому написать какую-то хрень и отдать программист не сможет, это увидят идейные коллеги, в т.ч. из партнеров компании (что делает их заинтересованными в долгосрочном качестве а не краткосрочных выгодах).
3. Ну и важно понимать, что эта система не призвана повышать качество или еще что. Эти задачи решаются другими способами.
Ее ключевая задача — объединить цели сотрудников и бизнеса. Дать людям понимание в каждый момент времени как их работа приводит или не приводит к прибыли бизнеса, и соответственно, к собственному дополнительному доходу.
Вот так. Все это обслуживает автоматизированная система, все достаточно прозрачно для сотрудников и не плохо работает.
И еще моменты.
У нас есть такие задачи, как разработка наших продуктов. На этот проект тоже люди списывают часы, и определенная часть прибыли с продажи продукта также выплачивается команде.
И у нас есть проекты развития. Когда люди что-то делают, за что платит компания. На такие проекты мы тоже выделяем виртуальный бюджет, как будто за него платит внешний заказчик — составляется и план и смета. И, соответственно, при завершении проекта развития по нему также считается премия.
Здравствуйте, enji,
E>Есть ли на эту тему что-то вменяемое?
Нет.
Более того: программисты (да и любые другие вменяемые инженеры) обычно очень неглупые люди. Они быстро научаются максимизировать этот самый KPI при минимальном уровне работы. К сожалению, 99% мальчиков с дипломами MBA не понимают, что это очень редко одновременно максимизирует пользу для бизнеса; чаще же бывает ровно наоборот.
Здравствуйте, enji, Вы писали: E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
наряду со своими KPI, добавьте еще статистику сколько из под определенного начальника ушло людей за год количественно и в процентах
Здравствуйте, Джеффри, Вы писали:
Д>И кто будет доволен, если ты ничего не будешь делать? Твои коллеги — нет (т.к. им придется за тебя все делать), твой лид — тоже нет (т.к. ничего не делается), заказчики — вообще вряд ли будут знать о твоем существовании.
Аутсорс? В продуктовых компаниях часто бывает, что пока продукт продается, работу можно не делать, главное на митингах правильные вещи говорить.
Д>Другое дело, если ты будешь со всем соглашаться и все делать. Ну, тогда производительность вырастет, как и хотел ТС.
Тогда будешь вечной шестеркой, все будут недовольны, что не прочел мысли, помог другому быстрее, и т.п. И можешь забыть о повышении, ибо если тебя повысить, то кто будет работу делать? Плавали, знаем.
Д>На самом деле, за счет того, что в ревью вовлечены много людей, которые оценивают производительность с разных аспектов, то становится трудно подобрать стратегию, которая обманет их всех. Так что, на мой взгляд, единственная выигрышная стратегия здесь — просто делать свою работу хорошо и стараться исправить недостатки, на которые указывают в фидбеке.
В фидбеке укажут отговорки типа insufficient influence или not a strong team player, параллельно протащив наверх чувака, который с шефом ходил пиво пить, пока ты за него работу делал.
Здравствуйте, Джеффри, Вы писали:
Д>Здравствуйте, enji, Вы писали:
E>>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Д>Можно сделать регулярное performance review с использованием метода 360 градусов. В добавок, к обычному текстовому фидбеку ввести качественные оценки и использовать их среднее значение как KPI.
Ага, и самой выигрышной стратегией становится со всеми соглашаться и ничего не делать, чтобы никого не обидеть. Тогда ты добрый отзывчивый чувак и большинство коллег тобой довольны.
Здравствуйте, enji, Вы писали:
E>Есть ли на эту тему что-то вменяемое?
Есть. Мысль что это полная чушь
E>Какая-то популярная практика, что можно почитать?
Популярная и полезная практика — "не делай этого"
E>что можно почитать? Посмотреть.
Здравствуйте, enji, Вы писали:
E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Можно сделать регулярное performance review с использованием метода 360 градусов. В добавок, к обычному текстовому фидбеку ввести качественные оценки и использовать их среднее значение как KPI.
На мой взгляд, метод полезный и действительно может помочь оценить каждому сотруднику свои сильные и слабые стороны и таким образом повысить производительность. Конечно, требует усилий по внедрению и более-менее ответственного подхода со стороны сотрудников.
Но автоматического начисления премий по таким KPI все же лучше не делать.
E>Чисто гипотетически можно попытаться оценивать задачи в трекере в "попугаях" и установить норму — Х попугаев / месяц. Однако задачи все разные и попадаются такие, что неясно, как их оценить до завершения работы над ними.
Такое может подойти для саппорт проектов, для девелопмента — не очень.
Здравствуйте, enji, Вы писали:
E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
E>Есть ли на эту тему что-то вменяемое?
Здравствуйте, bazis1, Вы писали:
B>Ага, и самой выигрышной стратегией становится со всеми соглашаться и ничего не делать, чтобы никого не обидеть. Тогда ты добрый отзывчивый чувак и большинство коллег тобой довольны.
И кто будет доволен, если ты ничего не будешь делать? Твои коллеги — нет (т.к. им придется за тебя все делать), твой лид — тоже нет (т.к. ничего не делается), заказчики — вообще вряд ли будут знать о твоем существовании.
Другое дело, если ты будешь со всем соглашаться и все делать. Ну, тогда производительность вырастет, как и хотел ТС.
На самом деле, за счет того, что в ревью вовлечены много людей, которые оценивают производительность с разных аспектов, то становится трудно подобрать стратегию, которая обманет их всех. Так что, на мой взгляд, единственная выигрышная стратегия здесь — просто делать свою работу хорошо и стараться исправить недостатки, на которые указывают в фидбеке.
Здравствуйте, enji, Вы писали:
E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. таточно понимающего человека... E>Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Самое вменяемое решение тут — объяснить озабоченому начальсву что все уважающие себя инженеры сбегут к более адекватному работадателю а оставшиеся будут занимаца повышением KPI в место того чтобы работать.
Здравствуйте, enji, Вы писали:
E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Результат будет предсказуем на 100%, но совпадать с декларируемой целью будет примерно на 0%
Ну не натягивается на настоящую инженерную работу KPI. Пусть машинисткам в машбюро KPI приклеивают куда-нибудь.
Здравствуйте, zou, Вы писали:
zou>Здравствуйте, enji, Вы писали:
E>>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
E>>Есть ли на эту тему что-то вменяемое?
zou>Думаю, нет.
Есть. Единственное что будет работать — это каждый проект привязывать к деньгам, которые они принесут. Работал на денежном проекте — получи деньгу, работал на фиг знает чем — получи шиш. Ты скажешь "ну есть же проекты..." а я скажу "а нафиг заниматься тем, что деньги не приносит?"
Здравствуйте, sergey2b, Вы писали:
S>а если шеф неприятный тип (с нормальным то почему не сходить)
Неприятные шефы чаще всего вырастают одним и тем же образом: терпят неприятного шефа над собой, всячески ему угождают, стараются подлизываться и демонстрировать симпатию, рано или поздно их повышают, посое чего он продолжают это делать, компенсируя накопленные комплексы на подчиненных. К сожалению, это основополагающий столп, на котором построено практически любое человеческое общество (начиная от армии, заканчивая большой политикой). В быстро растущих компаниях, когда у руля idea person, это временно отходит на второй план, но потом рано или поздно возвращается ибо большинством активных людей движет именно желание власти и социального статуса.
Если не хочется участвовать в этой грязюке, достаточно просто работать, как все, не выделяясь, не блеща умом, и тратя большую часть времени именно на "понравиться окружающим". Если хочется именно блистать умом и стричь с этого дивиденды, то 99% усилий должно уходить на поиск окружения, где это окупится (своя компания? мифический стартап, не заточенный на exit с момента основания?) и сопутствующую политику (как не переблистать чьего-нибудь друга/родственника/протеже), т.к. в большинстве мест ничего кроме зависти и ненависти окружающих это не вызовет.
E>И что-то мне кажется, что такая оценка задач и разбор багов весьма трудоемки, это надо выделять отдельного и достаточно понимающего человека... E>Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Я не видел. Из того, что у нас используется
1. KPI есть, но они влияют на зарплату не на 100%. У технических вообще на оклад не влияют и влияют только на премию.
2. Они оценивают работу группу в целом. В результате определяется размер премии, которая выдается на группу и там руководитель группы может до некоторых пределов делить эту сумму между участниками.
Грубо говоря премия 50% от оклада. Т.к. были косяки выдали 40% от общей зарплаты группы. Руководитель группы может урезать до 10% кому-то конкретному, а остаток выдать другим. Руководитель группы не влияет на свою премию — получает ее в размере процентов группы.
3. Баги являются составной KPI для разработки. Но есть нюанс: сопровождение при нахождении и оформлении бага определяет его ранг. Если это критический баг, то он уменьшает KPI разработки. Если не критический — никак не влияет. Критичность — это нарушение работы системы в рабочей среде, т.е. система становится нерабочей.
Для сопровождения KPI — это скорость реакции и решения багов. Сроки решения в KPI устанавливались совместно с сопровождением. + оценка работы владельцем систем (не всеми пользователями, а именно владельцами).
Но еще раз подчеркну — это при условии, что в зарплата платится средняя (или даже несколько выше среднего) по рынку и 50% — это так, цифра для примера. Т.е. режется пряник, а не применяется кнут. Это позволяет уменьшить текучку. И даже при этом есть эффект привыкания к премии, когда сотрудники считают, что она им положена по умолчанию и обижаются, если ее резанули.
Здравствуйте, enji, Вы писали:
E>Спасибо за развернутый ответ. Хотелось бы узнать еще пару моментов E>* Если Петя — юниор, а Миша — сеньор — они все равно получат 50 и 20%? Или есть какие-то коэффициенты?
Да, все нюансы я не писал, у нас целый большой алгоритм все считает.
Суть какая — менеджер проекта + директор по качеству в конце проекта ставят оценки всем участникам. 1 — работал как ожидается. Можно поставить 1.2 (можно любое число) — тогда доля человека в премиальном фонде увеличится на 20%. Может поставить 0.5 — тогда премия человека уменьшится в 2 раза, а остаток соответственно распределиться по остальным участникам. По сути эти оценки просто перераспределяют премию между участниками, тогда как общая премия проекта не меняется.
По факту практчиески никогда оценки не ставят, у всех 1. Но если кто-то проштрафился — ему могут поставить и 0.7 и даже 0.4. Или если кто-то хардкорил, работал по ночам, ему могут поставить даже 2. Все подобные оценки я лично одобряю/заворачиваю, чтобы не было несправедливостей особых.
Так вот, юниорам система автоматом ставит оценку 0.25. Когда их переводят в категорию не юниоров, то уже оценка по умолчанию становится 1.
Есть еще нюансы. Опять же, полезные. Например, скажем, себестоимость часа Васи — 1000р. Но если он работал в этом месяце не 184 часа а 200 часов, то стоимость его часа для компании будет 920 рублей (снизится) а вклад в проект наоборот увеличится (все 200 часов, а не 184 часа). Это приводит к косвенной оплате переработок по сути через систему премий, т.к. мы явно переработки не оплачиваем.
E>* Как быть с поддержкой? В продукте обнаружена бага — как это учитывается? Все доработки — по отдельной смете, как отдельный проект?
Проекты поддержки у нас тоже — отдельные проекты. Прелесть в том, что за поддержку клиенты платят хорошие деньги, и там обычно кроме самой поддержки еще и много доработок за деньги.
Вот и получается, что например клиент платит 40 тыс.р. в мес поддержку + потратил за полугодие 1 млн. на доработки. Из этих 1.24 млн и считается премия, за вычетом себестоимости. Собственно багфиксы просто увеличивают себестоимость и снижают премию.
E>Наша ситуация — встроенное и обслуживающее ПО для оборудования, т.е. самостоятельной ценности оно не имеет. При этом обычно ПО пишется и потихоньку совершенствуется, продаются новые экземпляры оборудования. Как бы ты считал "деньги полученные от клиента" в таком случае? Это некий аналог вашего проекта развития? Но как считается его смета — т.е. начальство заинтересовано премии по нему снизить, программисты — завысить?
Ну да, это аналог нашего проекта развития. Я бы считал так. Скажем на выпуск новой версии нужно (допустим) 5000 часов. Собственно у нас это было бы аналог 12 млн.р., полученных от клиента. Этот бюджет проекта я бы и вбил в систему.
Тут ключевое — это правильно спланировать трудозатраты. Конфликт интересов конечно есть, но если руководители хотят создать действующую систему мотивации то найдут правильный баланс.
Здравствуйте, enji, Вы писали: E>Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Информации полно (видео, книги), а что вменяемое или нет нужно определять самому. Для примера упрощённая схема:
роли в программных проектах
В итоге всё это нужно лишь менеджеру проекта, так как только он может повлиять на ситуацию. Прочитав разные книги, насмотревшись видеолекций у меня появилось своё мнение на этот счёт, вот только я не менеджер, а отсюда не берусь оценивать степень вменяемости.
Представим чисто умозрительно, что есть человек получивший в процессе работы чуть ли не учёную степень по палиндромам, и работает в компании, которая специализируется на палиндромах в Big Data. И он всем кандидатам при приёме даёт задание написать палиндром, а потом оценивает их производительность и качество работы используя некие метрики.
И первый вопрос который бы задал я, какова цель этих метрик, изменить работу менеджера, или просто тупо посчитать конечный результат и выдать вознаграждение. Про последнее, кстати, тоже не мало понаписали, в том числе и о влиянии бессмысленных вознаграждений в виде звёзд и прочего. E>Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Этим, кстати, можно не только увеличить мотивацию, но и уменьшить её. Более того, как говорят, сегодня роскошь, завтра необходимость. К премиям можно быстро привыкнуть и их невыплата станет фактором демотивации. Или предположим один человек считается для компании полезнее другого, что и отразилось в коэффициенте, но тот кому не выплачивают премию, потому что по мнению начальства он малополезен это заметит. E>Можно попробовать считать баги, но дело тоже мутное. Код во многом унаследован, пишется несколькими людьми, начнутся разборки, кто виноват и попытки свалить все на ушедших.
Что касается текучки людей, то это уже показатель эффективности работы организации. У людей есть не только краткосрочная мотивация, но и долгосрочная специализация. Предположим менеджер даёт задание специалисту по отсечению непечатаемых символов на концах строк написать палиндром. С одной стороны у программиста появляется дополнительная специальность, со временем она может вырасти.
С другой в команде мог быть человек у которого данная специализация изначально находится на более высоком уровне. Что толку поручать сантехнику провести электрическую сеть, а потом высчитывать коэффициент его полезности.
Тут начальство KPI (числовыми показателями эффективности) озаботилось, в т.ч. программистов и прочих инженеров. Декларируемая цель — увеличить производительность и мотивацию путем начисления премии по KPI.
Чисто гипотетически можно попытаться оценивать задачи в трекере в "попугаях" и установить норму — Х попугаев / месяц. Однако задачи все разные и попадаются такие, что неясно, как их оценить до завершения работы над ними.
Можно попробовать считать баги, но дело тоже мутное. Код во многом унаследован, пишется несколькими людьми, начнутся разборки, кто виноват и попытки свалить все на ушедших. Опять же, сложная задача — вероятно и багов будет много.
И что-то мне кажется, что такая оценка задач и разбор багов весьма трудоемки, это надо выделять отдельного и достаточно понимающего человека...
Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Здравствуйте, landerhigh, Вы писали: L>Результат будет предсказуем на 100%, но совпадать с декларируемой целью будет примерно на 0% L>Ну не натягивается на настоящую инженерную работу KPI. Пусть машинисткам в машбюро KPI приклеивают куда-нибудь.
как тут правильно сказали, девелоперы — люди не глупые и всегда найдут способ обойти любую систему. одну вещь нельзя обмануть — текучку людей. когда девелопер изнутри понимает, что все это бесперспективо, дефективно и скоро развалится, ему бесполезно заговаривать зубы о скором неизбежном росте. его уход нельзя остановить. жуто хреновые тимлиды всегда имеют сильную текучку. есть люди от которых где-то половина людей за год уходит. хреново работающие направления или даже целые компании могут иметь тоже дичайшую текучку порядка 30% в год. жалко, что эти цифры никто никогда не публикует
Здравствуйте, Джеффри, Вы писали:
Д>И кто будет доволен, если ты ничего не будешь делать? Твои коллеги — нет (т.к. им придется за тебя все делать), твой лид — тоже нет (т.к. ничего не делается), заказчики — вообще вряд ли будут знать о твоем существовании.
Почему коллеги за тебя?
Они будут за себя делать.
Условно, если средний коллега фиксит в среднем N дефектов (тикетов) в день, то он и будет их фиксить столько же — независимо от того, его коллега Вася фиксит их втрое больше, или вообще сидит в потолок плюёт.
Если Вася плюёт в потолок — это значит, что тикеты будут в среднем фикситься медленней, или некоторые миноры так и не будут пофикшены (будут из раза в раз переноситься на след. релиз) — которые иначе могли бы быть пофикшены.
Д>Другое дело, если ты будешь со всем соглашаться и все делать. Ну, тогда производительность вырастет, как и хотел ТС.
У тебя есть предположение, что коллеги заинтересованы, чтоб их условный коллега Вася работал поусердней и делал всего побольше.
Причем не владелец бизнеса или начальник отдела разработки, а именно коллеги-разработчики.
Но зачем им это?
Если мой коллега Вася будет работать в усиленном ритме и делать втрое больше плана — я на его фоне со своим "обычным" ритмом буду выглядеть блекло.
Поскольку в разведшколе я ни разу не ездил на картошку, то очень боялся, что мое неумение обращаться с ней вызовет подозрение тех, кто обучался этому много лет в различных высших учебных заведениях. Поэтому я работал старательно, вкалывал без перекуров, за что в первый же день был избит коллегами по полю.
Здравствуйте, FlW, Вы писали:
FlW>>>3. Субъективная оценка руководителя, ежегодные аттестации.
FlW>Условно, есть в группе Вася, Петя и их руководитель Паша. Паше дали 100 000 рублей премиальных для его подчиненных, он выделил из них 60 000 рублей Васе и 40 000 рублей Пети.
FlW>Соответственно, если на следующей пьянке Вася похвастается перед Петей размером премии, Петя может сильно обидится.
В действительности в больших конторах это работает так:
Условно, есть в группе Вася, Петя и их руководитель Паша. Паше дали 100 000 рублей премиальных для его подчиненных, он выделил из них себе 90 000 рублей, а Васе с Петей дал по 5 тыр.
Соответственно, если на следующей пьянке Вася похвастается перед Петей размером премии, они оба будут спокойны и счастливы
А чаще всего это бывает так: "Паше дали 100 000 рублей премиальных. Паша выделил себе 100 000 рублей премиальных. И все счастливы"
Здравствуйте, enji, Вы писали:
E>Можно попробовать считать баги, но дело тоже мутное. Код во многом унаследован, пишется несколькими людьми, начнутся разборки, кто виноват и попытки свалить все на ушедших. Опять же, сложная задача — вероятно и багов будет много.
Ничего особо мутного нет, по крайней мере при статическом анализе E>И что-то мне кажется, что такая оценка задач и разбор багов весьма трудоемки, это надо выделять отдельного и достаточно понимающего человека...
и трудоёмкости тоже
E>Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Посмотри, например, это
По-моему, и на RSDN эти вопросы не раз поднимались.
Здравствуйте, 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 и написания фидбеков распространена в крупных компаниях. Во всяком случае, во всех компаниях, где я работал было именно так. Ну, а вообще — не хочешь писать фидбек, считаешь это глупостью? Не пиши, используй генераторы отзывов, только потом не стоит жаловаться на отсутствие карьерного роста, что тебя считают винтиком.
Здравствуйте, Джеффри, Вы писали:
Д> Я бы так не сказал, что прямо "никто". Конечно, это зависит от корпоративной культуры и процессов, но практика performance review и написания фидбеков распространена в крупных компаниях.
Да, и во всех этих компаниях она "для галочки", а не для людей. В эту игру могут играть только очень наивные инфантильные люди, коих в IT очень мало.
Д> Во всяком случае, во всех компаниях, где я работал было именно так. Ну, а вообще — не хочешь писать фидбек, считаешь это глупостью? Не пиши, используй генераторы отзывов, только потом не стоит жаловаться на отсутствие карьерного роста, что тебя считают винтиком.
Карьерный рост никак не зависит от фидбэка — надеюсь, ни для кого это не новость.
P.S. Впрочем, у описанной системы есть и положительные стороны — она очень быстро и эффективно вскрывает "гнойники".
Управляю вселенной не привлекая внимания санитаров.
Здравствуйте, Anton Batenev, Вы писали:
AB>Да, и во всех этих компаниях она "для галочки", а не для людей. В эту игру могут играть только очень наивные инфантильные люди, коих в IT очень мало.
Как по мне, это зависит от отношения, но воспринимать это как игру или самоцель точно не стоит. По сути обычная рутинная процедура, примерно как ретроспектива спринта. Или ретроспективы тоже для галочки делаются?
Здравствуйте, __kot2, Вы писали:
__>как тут правильно сказали, девелоперы — люди не глупые и всегда найдут способ обойти любую систему. одну вещь нельзя обмануть — текучку людей. когда девелопер изнутри понимает, что все это бесперспективо, дефективно и скоро развалится, ему бесполезно заговаривать зубы о скором неизбежном росте. его уход нельзя остановить. жуто хреновые тимлиды всегда имеют сильную текучку. есть люди от которых где-то половина людей за год уходит. хреново работающие направления или даже целые компании могут иметь тоже дичайшую текучку порядка 30% в год. жалко, что эти цифры никто никогда не публикует
у меня начальником был чел у которого в один день уволились все программеры и QA, только одна тетка осталась из QA
плюнуть ему в лицо при увольнении меня остановило только система реферинцисов у англосаксов
редкостная скотина была, хотя профессор MIT
Здравствуйте, Sammo, Вы писали:
S>Я не видел. Из того, что у нас используется S>1. KPI есть, но они влияют на зарплату не на 100%. У технических вообще на оклад не влияют и влияют только на премию. S>2. Они оценивают работу группу в целом. В результате определяется размер премии, которая выдается на группу и там руководитель группы может до некоторых пределов делить эту сумму между участниками. S>Грубо говоря премия 50% от оклада. Т.к. были косяки выдали 40% от общей зарплаты группы. Руководитель группы может урезать до 10% кому-то конкретному, а остаток выдать другим. Руководитель группы не влияет на свою премию — получает ее в размере процентов группы. S>3. Баги являются составной KPI для разработки.
А можно поподробней, из чего состоял КПИ? Критические баги его понижали, а что повышало? Был некий "базовый" уровень КПИ, выше — премия, ниже — предупреждение о несоответствии?
Еще вопрос — QA были в одной лодке с разработчиками? Т.е. баг — это по идее понижение в т.ч. и КПИ QA?
За какой период считался КПИ? Если условно, проект на полгода — то он добавляет КПИ каждый месяц или только после выпуска?
E>А можно поподробней, из чего состоял КПИ? Критические баги его понижали, а что повышало? Был некий "базовый" уровень КПИ, выше — премия, ниже — предупреждение о несоответствии? E>Еще вопрос — QA были в одной лодке с разработчиками? Т.е. баг — это по идее понижение в т.ч. и КПИ QA? E>За какой период считался КПИ? Если условно, проект на полгода — то он добавляет КПИ каждый месяц или только после выпуска?
Тут есть некая проблема — по умолчанию премия раз в квартал. Но это при условии, что не резанет владелец (такое было раза 3 за последние 5 лет). По умолчанию она равна фиксированному количеству процентов, но могут дать больше (опять же если владелец решает, что заработали достаточно денег).
Поэтому фактически КПИ могут только понизить премию — увеличить не могут. Это недостаток данной конкретной ситуации.
И это несколько демотивирует, когда понимаешь, что на наличие премии ты не влияешь — это решение других. Но вариант автоматического начисления премий в случае отсутствия крупных косяков не прокатил — Россия
QA идут в одном блоке с разработкой, потому что предполагается, что от отдела разработки интересен конечный продукт и с этой точки зрения за качество конечного продукта QA несет такую же ответственность, как и разработка.
Поскольку все работают либо по Скраму либо по Канбану (взависимости от группы), то это несколько нивелирует проектность — руководитель ИТ и так знает результаты и кто где прокосячил.
Хотя в конце квартала ему предоставляется от каждой группы информации об участии о крупных (в идеале законченных) проектах, в которых участвовала группа. Желательно чтобы проекты были "бизнесовые", а не "оптимизационные", т.к. по оптимизационным приходится еще показывать что получит/получил бизнес от них.
Здравствуйте, Sammo, Вы писали:
S>Тут есть некая проблема — по умолчанию премия раз в квартал. Но это при условии, что не резанет владелец (такое было раза 3 за последние 5 лет). По умолчанию она равна фиксированному количеству процентов, но могут дать больше (опять же если владелец решает, что заработали достаточно денег). S>Поэтому фактически КПИ могут только понизить премию — увеличить не могут. Это недостаток данной конкретной ситуации. S>И это несколько демотивирует, когда понимаешь, что на наличие премии ты не влияешь — это решение других. Но вариант автоматического начисления премий в случае отсутствия крупных косяков не прокатил — Россия
Т.е. ваше КПИ = "количеству крит. багов со знаком минус" и понижает премию отдела. Плюс к этому есть крупные/законченные проекты, без наличия которых премии не будет / она будет меньше. Я правильно понял?
Внутри критического уровня баги как-то разбиваются? К примеру "ПО вообще не работает" или "ПО падает раз в день на 5 минут" или "Нельзя сохранить настройки из формы, но их можно отредактировать вручную в файле" — это дает -3 попугая, или каждый баг оценивается отдельно? Как происходит оценка? А если баг к примеру вылез из-за сторонней либы или из-за кода, который был написан 5 лет назад уже уволившимся?
S>Хотя в конце квартала ему предоставляется от каждой группы информации об участии о крупных (в идеале законченных) проектах, в которых участвовала группа. Желательно чтобы проекты были "бизнесовые", а не "оптимизационные", т.к. по оптимизационным приходится еще показывать что получит/получил бизнес от них.
Я правильно понимаю, что это вполне себе субъективно, нет какого-то количественного показателя, который бы вычислялся автоматом по трекеру?
Здравствуйте, Mishka, Вы писали:
zou>>Думаю, нет.
M>Есть. Единственное что будет работать — это каждый проект привязывать к деньгам, которые они принесут. Работал на денежном проекте — получи деньгу, работал на фиг знает чем — получи шиш. Ты скажешь "ну есть же проекты..." а я скажу "а нафиг заниматься тем, что деньги не приносит?"
А назначать кто на какой проект пойдет — будет начальник отдела за откат на основании своего опыта и профессионального чутья, чтоб распределить людей по возможности наиболее справедливо?
Ты, Вася, пойдешь на денежный проект, а ты, Петя, пойдешь на тот говёный проект — его же тоже надо кому-то делать.
А еще среди программистов может оказаться молодая красивая девушка. Интересно, куда её распределят, на какой проект?
Здравствуйте, antonio_banderas, Вы писали:
_>Здравствуйте, Mishka, Вы писали:
zou>>>Думаю, нет.
M>>Есть. Единственное что будет работать — это каждый проект привязывать к деньгам, которые они принесут. Работал на денежном проекте — получи деньгу, работал на фиг знает чем — получи шиш. Ты скажешь "ну есть же проекты..." а я скажу "а нафиг заниматься тем, что деньги не приносит?"
_>А назначать кто на какой проект пойдет — будет начальник отдела за откат на основании своего опыта и профессионального чутья, чтоб распределить людей по возможности наиболее справедливо? _>Ты, Вася, пойдешь на денежный проект, а ты, Петя, пойдешь на тот говёный проект — его же тоже надо кому-то делать. _>А еще среди программистов может оказаться молодая красивая девушка. Интересно, куда её распределят, на какой проект?
Я тебе говорю "единственное что будет работать", а ты обиделся что из этого следует реальная жизнь. Да, красивые девушки и проворные парни с повышеным EQ всегда найдут путь к деньгам. Ты хочешь справедливый KPI для распределения денег? Таких не бывает.
Здравствуйте, Mishka, Вы писали:
M>Здравствуйте, antonio_banderas, Вы писали:
_>>Здравствуйте, Mishka, Вы писали:
zou>>>>Думаю, нет.
M>>>Есть. Единственное что будет работать — это каждый проект привязывать к деньгам, которые они принесут. Работал на денежном проекте — получи деньгу, работал на фиг знает чем — получи шиш. Ты скажешь "ну есть же проекты..." а я скажу "а нафиг заниматься тем, что деньги не приносит?"
_>>А назначать кто на какой проект пойдет — будет начальник отдела за откат на основании своего опыта и профессионального чутья, чтоб распределить людей по возможности наиболее справедливо? _>>Ты, Вася, пойдешь на денежный проект, а ты, Петя, пойдешь на тот говёный проект — его же тоже надо кому-то делать. _>>А еще среди программистов может оказаться молодая красивая девушка. Интересно, куда её распределят, на какой проект?
M>Я тебе говорю "единственное что будет работать", а ты обиделся что из этого следует реальная жизнь. Да, красивые девушки и проворные парни с повышеным EQ всегда найдут путь к деньгам. Ты хочешь справедливый KPI для распределения денег? Таких не бывает.
Собственно да, у нас именно этот подход и работает. И действительно, указанные нюансы есть. Но общий баланс преимущества-недостатки в большом плюсе.
Здравствуйте, sharpcoder, Вы писали:
S>Суть системы. S>1. Каждый сотрудник заполняет отчет, на какой проект он сегодня сколько часов потратил. S>2. Вся эта информация сливается в куб, где на основе нее рассчитывается себестоимость (в рублях), каждого проекта. S>3. Когда завершается проект, считается чистая прибыль (деньги полученные от клиента — полная себестоимость проекта). S>4. Определенный процент чистой прибыли формирует премиальный фонд проекта. S>5. Премиальный фонд проекта выплачивается команде, пропорционально трудозатратам каждого участника на проект. S>Например Петя потратил на проект 5 часов, Вася 3 часа, Миша 2 часа. Петя получит 50% премиального фонда, Вася 30% и т.п. S>6. Премия идет в дополнение к зарплате. Фиксированная з.п. ни при каких условиях не может уменьшится. S>Так, премия за 2 полугодие 2015 принесла сотрудникам от 1.5 до 4 зарплат. Премиальный фонд этого полугодия был равен двум месячным фондам оплаты труда. Т.е. премия может быть интересной.
Спасибо за развернутый ответ. Хотелось бы узнать еще пару моментов
* Если Петя — юниор, а Миша — сеньор — они все равно получат 50 и 20%? Или есть какие-то коэффициенты?
* Как быть с поддержкой? В продукте обнаружена бага — как это учитывается? Все доработки — по отдельной смете, как отдельный проект?
Наша ситуация — встроенное и обслуживающее ПО для оборудования, т.е. самостоятельной ценности оно не имеет. При этом обычно ПО пишется и потихоньку совершенствуется, продаются новые экземпляры оборудования. Как бы ты считал "деньги полученные от клиента" в таком случае? Это некий аналог вашего проекта развития? Но как считается его смета — т.е. начальство заинтересовано премии по нему снизить, программисты — завысить?
E>Есть ли на эту тему что-то вменяемое? Какая-то популярная практика, что можно почитать?
Сам заморачивался этим, и в целом получается так:
1. Оценка по "качеству/скорость" разработки.
Условно есть 2 программиста Вася и Петя. Вася делает стандартный сайт на шаблонах за неделю, в Петя за 3 дня. Зато Петя еще неделю разгребал 5 претензий от заказчика, а к Васи не было ни одной. Если задачи практически одинаковые, то Вася — молодец, Петя — нет.
Как видно из примера, неплохо работает на один простых и однотипных задачах.
2. Оценка по прибыли.
Тут фантазии бывают разные. Начиная от некоего фиксированного процента прибыли от продукта группе разработок, заканчивая акциями фирмы. Неплохо работает на стартапах, куда люди осознанно идут на определенные риски (меньше стабильности, меньше ЗП), но хотят получить прибыль в последствии.
Если у вас уже есть, условно, фрагманский проект приносящий 99% прибыли для конторы и куча новоделов, то практика работать не будет.
Может работать в больших конторах. На команду разработки выделяется какая-то сумма премиальных, а руководитель уже распределяет ее по программистам самостоятельно. В данном случае очень важно, чтобы программисты из одного отдела не делились друг с другом размером премиальных! В противном случае будет куча обид, а не подъем мотивации.
Разумеется, могут быть комбинации схем. Например формировании премиального фонда на основе прибыли проекта с дальнейшим распределением ее руководителем по подчиненным. Но по поводу эффективности любых схем мотивации для программистов есть большие вопросы!
Во-первых, люди могут начать работать на KPI, а не на результат. Во-вторых, от переманивания премии (даже регулярные) спасают мало. Условно, если у вас 100 000 рублей + премия плюс/минус 20 000 в месяц, то вы с большей охотой перейдете к конкурентам за 140 000, чем при стабильных и гарантированных 120 000.
Здравствуйте, FlW, Вы писали:
FlW>3. Субъективная оценка руководителя, ежегодные аттестации.
FlW>Может работать в больших конторах. На команду разработки выделяется какая-то сумма премиальных, а руководитель уже распределяет ее по программистам самостоятельно. В данном случае очень важно, чтобы программисты из одного отдела не делились друг с другом размером премиальных! В противном случае будет куча обид, а не подъем мотивации.
А с кем они будут делиться, если премиальные выделяются на отдел? Или неиспользованные премиальные отдаются обратно фирме?
FlW>>3. Субъективная оценка руководителя, ежегодные аттестации.
FlW>>Может работать в больших конторах. На команду разработки выделяется какая-то сумма премиальных, а руководитель уже распределяет ее по программистам самостоятельно. В данном случае очень важно, чтобы программисты из одного отдела не делились друг с другом размером премиальных! В противном случае будет куча обид, а не подъем мотивации.
E>А с кем они будут делиться, если премиальные выделяются на отдел? Или неиспользованные премиальные отдаются обратно фирме?
Условно, есть в группе Вася, Петя и их руководитель Паша. Паше дали 100 000 рублей премиальных для его подчиненных, он выделил из них 60 000 рублей Васе и 40 000 рублей Пети.
Соответственно, если на следующей пьянке Вася похвастается перед Петей размером премии, Петя может сильно обидится.
==менеджер проекта + директор по качеству в конце проекта ставят оценки всем участникам==
Вопрос возникает: Quis custodiet ipsos custodes? (с)
А кто и как оценивает работу менеджера? Получается, что он работает сто процентов времени в отличие от производственного состава ("Премиальный фонд проекта выплачивается команде, пропорционально трудозатратам каждого участника на проект").
Это обеспечивает менеджеру гарантированную премению. Он может вообще ничего не делать, а говорить, что он денно и нощно бдит
При этом Вася с Петей, работая в поте лица, как неглупые люди (см. ответы выше) будут это чётко видеть и огорчаться, у них будет падать мотивация.
Здравствуйте, Mishka, Вы писали:
M>Есть. Единственное что будет работать — это каждый проект привязывать к деньгам, которые они принесут. Работал на денежном проекте — получи деньгу, работал на фиг знает чем — получи шиш. Ты скажешь "ну есть же проекты..." а я скажу "а нафиг заниматься тем, что деньги не приносит?"
А сколько бабла приности, скажем, корпоративный фреймворк, используемый и в говённом, неприбыльном проекте и в кошерном, прибыльном?
M>В действительности в больших конторах это работает так:
Нууу, оно по-разному. Я приводил наш пример — премию выделяют на отдел, но руководитель получает премию не из этого пула — он получает отдельно.
А зарплата и премия объявляются коммерческой тайной и мягко говоря сильно не приветствуется ее раскрытие. Т.е. если узнают, что ты про свои деньги кому-то сказал — в следующий раз и без премии останешься. Поэтому все молчат. Даже на пьянках.
Здравствуйте, msk78, Вы писали:
M>Здравствуйте, sharpcoder, Вы писали:
M>==менеджер проекта + директор по качеству в конце проекта ставят оценки всем участникам== M>Вопрос возникает: Quis custodiet ipsos custodes? (с)
M>А кто и как оценивает работу менеджера? Получается, что он работает сто процентов времени в отличие от производственного состава ("Премиальный фонд проекта выплачивается команде, пропорционально трудозатратам каждого участника на проект").
M>Это обеспечивает менеджеру гарантированную премению. Он может вообще ничего не делать, а говорить, что он денно и нощно бдит
Есть такой нюанс, да. Но, менеджер проекта — лицо, принимающее решения. От его пешеий зависит прибыльность проекта. Например согласиться выполнить бесплатных доработок "т.к. клиент очень просит", прибыль проекта пошла вниз.
А в нашей ситуации цели менеджера и компании совпадают. А будет он плохо работать — об этом узнает наш контроль качества и, если проблемы большие, то и я.
S>А зарплата и премия объявляются коммерческой тайной и мягко говоря сильно не приветствуется ее раскрытие. Т.е. если узнают, что ты про свои деньги кому-то сказал — в следующий раз и без премии останешься. Поэтому все молчат. Даже на пьянках.
Вот потому чмо и терпилы и формируют уровень дохода в отрасли на индусском уровне
Весьма интересная система.
S>К чему это привело? S>А. Менеджеры проекта стали с большой неохотой брать доп. обязательства сверх контракта, т.к. это увеличит себестоимость и уменьшит премиальный фонд.
Это понятно, зачем что-то делать бесплатно, если это можно продать? Иногда не за деньги, а для получения каких-то уступок со стороны заказчика, за улучшение отношений, увеличение вероятности дальнейших заказов, положительных отзывов ну и т.д. То есть выгода, прямая или косвенная, должна быть всегда.
Странно, что менеджеры до введения этой системы так не делали.
S>Б. Участники проекта стали заботиться о экономии трудозатрат. Да, ты можешь эту задачу сделать за 10 часов, а можешь и за 2. Если сделаешь за 2 — премиальный фонд будет выше.
А вот тут непонятно.
Пусть 100 тугриков, которые делятся на 100 человеко-часов. Пусть над проектом работают 10 человек, каждый по 10 часов, т.е. каждый должен получить по 10 тугриков в итоге. Но если один из них растянет работу вместо 10 на 20 часов — то он получит чуть более 18 тугриков, а остальные — по 9 тугриков.
А если он вдруг увидел способ сделать свою задачу в 2 раза быстрее — за 5 часов, то, как не трудно посчитать — получит меньше остальных.
Т.е. становится выгодно хватать задачи из прибыльных проектов и делать их подольше, таки образом снижая общую прибыльность.
В то же время не выгодно работать над задачами неприбыльных проектов. А если уж назначили — то стараться сделать их побыстрее, при этом, как ни парадоксально, увеличивая прибыльность изначально невыгодного проекта)
Кроме того, если уж работаешь параллельно над проектами с разной прибыльностью, возникает соблазн дописывать часы неприбыльного проекта к приблыльному.
Если сильно не наглеть — то никто и не заметит.
Как вы с этим боретесь?
S>В. Главное. Цели каждого участника проекта и цели бизнеса стали совпадать — все заинтересованы сделать прибыльный проект.
Ну да, и при этом никто не хочет брать неприбыльный. Т.е. неприбыльным люди будут заниматься только из-под палки, стараясь скинуть его на других.
Что вы с этим делаете?
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
количественно и в процентах
