Комментарии 21
Дениел Пинк. «Драйв.» Рекомендую почитать и сэкономить в будущем время, избавив себя от необходимости подобных расчетов.
Ясное дело, деньги не для всех главный мотиватор. Но пирамиду Маслоу тоже никто не отменял. Приятно иметь команду, которая уже перешагнула несколько первых ступеней и подумывает о самореализации. Но, увы, не всегда так везет:)
По моему, деньги для разработчиков далеко не последний мотивирующий фактор. Когда я был разработчиком, то для меня материальное стимулирование было одним из основных в работе. Я просиживал на работе много часов напролет, что бы перевыполнить план.
У нас в компании введена мотивационная схема для программистов. Она не идеальная, но она дает четкое представление о том, что деньги хорошо мотивируют определенную категорию людей.
Так, например, у нас есть показатель личного плана работ, который оценивается как отношение оценочных часов по выполненным задачам к оценочным часам по запланированным задачам. У программистов большой вес этого показателя, поэтому они стараются сделать большее количество задач в месяц. Это конечно опасный подход, который может привести к потере качества продукта, поэтому такие показатели обязательно должны уравновешиваться другими (в нашем случае это субъективная оценка руководителя и заказчика задачи).
Но могу сказать, что деньги, как правило, мотивируют программистов, просто потому что потребности людей на этом уровне не удовлетворены.
У нас в компании введена мотивационная схема для программистов. Она не идеальная, но она дает четкое представление о том, что деньги хорошо мотивируют определенную категорию людей.
Так, например, у нас есть показатель личного плана работ, который оценивается как отношение оценочных часов по выполненным задачам к оценочным часам по запланированным задачам. У программистов большой вес этого показателя, поэтому они стараются сделать большее количество задач в месяц. Это конечно опасный подход, который может привести к потере качества продукта, поэтому такие показатели обязательно должны уравновешиваться другими (в нашем случае это субъективная оценка руководителя и заказчика задачи).
Но могу сказать, что деньги, как правило, мотивируют программистов, просто потому что потребности людей на этом уровне не удовлетворены.
Подскажите пожалуйста — хаб Agile указан случайно, или Ваши рассчёты Вы предполагаете использовать (и) в Agile командах — к примеру в Scrum командах?
Есть очень хорошая статья у Джоэла Спольски, про материальную мотивацию. Если еще не читали, то почитайте, рекомендую.
Теперь про формулы.
1. Как вы будите учитывать работу «экспертов»? Например, у вас есть сотрудник великолепно разбирающийся в технологии, да, он делает меньше работы чем остальные, но остальные делают свою работу только по тому, что этот эксперт им помогает. Не дали бонус эксперту? Ок, развалили взаимопомощь в команде.
2. Как вы будите бороться с тем, что сначала все будут выбирать наиболее легки, но переоцененные задачи, что будет приводить к тому, что наиболее сложные задачи будут оставаться на конец? А в них как правило прогнозы самые плохие, да и количество ошибок будет намного больше, что приведет к затягиванию на итерации тестирование-исправление, а следовательно к срыву сроков.
3. Разработчики, боясь не получить бонус начнут завышать оценки на задачи. Что делать?
И т.д. и т.п.
Теперь про формулы.
1. Как вы будите учитывать работу «экспертов»? Например, у вас есть сотрудник великолепно разбирающийся в технологии, да, он делает меньше работы чем остальные, но остальные делают свою работу только по тому, что этот эксперт им помогает. Не дали бонус эксперту? Ок, развалили взаимопомощь в команде.
2. Как вы будите бороться с тем, что сначала все будут выбирать наиболее легки, но переоцененные задачи, что будет приводить к тому, что наиболее сложные задачи будут оставаться на конец? А в них как правило прогнозы самые плохие, да и количество ошибок будет намного больше, что приведет к затягиванию на итерации тестирование-исправление, а следовательно к срыву сроков.
3. Разработчики, боясь не получить бонус начнут завышать оценки на задачи. Что делать?
И т.д. и т.п.
1. Эксперты обычно получают более высокую зп, а в данной системе чем выше зп (т.е профессионализм) тем выше ставка бонуса. в моей команде Тим Лид и является экспертом. Ту сумму, что он не дополучил сделав меньше работы, он получает за счет более высокой ставки зп
2. Просто сортануть задачи по оценке и брать в начале самые трудозатратные. Кроме того, иногда важна последовательность выполнения задач, приходится за этим следить
3. Задачу обсуждают все, чтобы выяснить подводные камни, но оценку проводит один человек — эксперт. Он и вся команда должны понимать, что именно за свои знания и точные оценки он получает более высокую зп (а ставка бонуса зависит от зп). У команды есть стимул выполнять работу быстрее, потому как, чем больше оценочной работы они сделают тем выше бонус. Итак берем первый спринт, если команда уж очень сильно переплюнула план — налицо завышенная оценка, зовем эксперта просим его быть более объективным (а то, возможно, не такой уж он и эксперт и, возможно, его зп завышена).
Задача эксперта дать максимально точную оценку. Заниженная оценка тоже плоха, потому как, если люди даже стараясь, не могут вложиться в план, то никакой мотивации не будет. Если же оценка будет сильно завышена, это видно из результатов первого же спринта. (но на первом спринте, пока все втягиваются, это еще допустимо)
Далее оценка задач второго спринта строится на основании реально затраченного времени на первом спринте — сравнивается сложность задач и тут уже становиться сложнее читить с оценкой. Оценка третьего делается в сравнении с задачами второго и тд
В общем, если команда уж сильно переплюнула план — это не в интересах эксперта (ему могут снизить зп или поменять эксперта). Зато перевыполнить план -это в интересах команды, чем больше оценочной работы делается, тем выше бонус. На противоборстве этих интересов строится более и менее адекватная оценка проекта.
2. Просто сортануть задачи по оценке и брать в начале самые трудозатратные. Кроме того, иногда важна последовательность выполнения задач, приходится за этим следить
3. Задачу обсуждают все, чтобы выяснить подводные камни, но оценку проводит один человек — эксперт. Он и вся команда должны понимать, что именно за свои знания и точные оценки он получает более высокую зп (а ставка бонуса зависит от зп). У команды есть стимул выполнять работу быстрее, потому как, чем больше оценочной работы они сделают тем выше бонус. Итак берем первый спринт, если команда уж очень сильно переплюнула план — налицо завышенная оценка, зовем эксперта просим его быть более объективным (а то, возможно, не такой уж он и эксперт и, возможно, его зп завышена).
Задача эксперта дать максимально точную оценку. Заниженная оценка тоже плоха, потому как, если люди даже стараясь, не могут вложиться в план, то никакой мотивации не будет. Если же оценка будет сильно завышена, это видно из результатов первого же спринта. (но на первом спринте, пока все втягиваются, это еще допустимо)
Далее оценка задач второго спринта строится на основании реально затраченного времени на первом спринте — сравнивается сложность задач и тут уже становиться сложнее читить с оценкой. Оценка третьего делается в сравнении с задачами второго и тд
В общем, если команда уж сильно переплюнула план — это не в интересах эксперта (ему могут снизить зп или поменять эксперта). Зато перевыполнить план -это в интересах команды, чем больше оценочной работы делается, тем выше бонус. На противоборстве этих интересов строится более и менее адекватная оценка проекта.
Мой опыт работы руководителем центра разработки показывает, что любые синтетические методики оценки не работают эффективно. Они либо требуют неоправданного расхода ресурсов на поддержание, либо становятся источником демотивации.
Я не вижу решения, кроме как построить вертикаль руководителей команд, групп и т.п. Так, чтобы каждый руководитель на своем уровне знал и понимал своих подчиненных (не более 7-8 человек) и мог грамотно их мотивировать (как материально, так и нематериально). Для этого руководитель должен быть именно руководителем, а не просто самым лучшим кодером.
А систем расчета бонусов можно много придумать, только лично я не поверю, что они работают без чистого продолжительного положительного опыта (на протяжении более года минимум).
Я не вижу решения, кроме как построить вертикаль руководителей команд, групп и т.п. Так, чтобы каждый руководитель на своем уровне знал и понимал своих подчиненных (не более 7-8 человек) и мог грамотно их мотивировать (как материально, так и нематериально). Для этого руководитель должен быть именно руководителем, а не просто самым лучшим кодером.
А систем расчета бонусов можно много придумать, только лично я не поверю, что они работают без чистого продолжительного положительного опыта (на протяжении более года минимум).
Все, что вы говорите, не исключает использования подобной системы расчета бонусов. Конечно, не значит, что она решает все на свете проблемы. Интересно, какие методики оценки вы находите эффективными?
Я бы разделил обсуждение на две темы — метрики и бонусы (хотя эти темы часто связывают).
1. Метрики. Безусловно, производительность разработчиков оценивать нужно. И руководство компании, и непосредственный руководитель, и самое главное, сам разработчик должны понимать, насколько хорошо/плохо он справляется со своими задачами и достигает своих целей. Вот только работающих KPI для разработчиков еще никто не придумал. Почему это так — тема слишком общирная для обсуждениях в комментариях. Это хорошо изложено у классиков, таких как ДеМарко, Листер, Брукс и т.п., и весь мой личный опыт и опыт коллег это подтверждает. И даже тот факт, что в некоторых компаниях метрики используются, доказывает, на мой взгляд, лишь то, что метрики могут в лучшем случае не мешать.
2. Бонусы. Я считаю, что бонусы для разработчиков оправданы только в том случае, когда их производительность четко связаны с финансовым результатом. А это бывает крайне редко и применимо только для индивидуальных разработчиков и очень маленьких команд, готовых брать на себя бизнес-риски. Потому что в команде из 5-10 человек, работающих над одним проектом, уже невозможно выделить вклад каждого (потому что метрик не существует). Да и финансовый результат уже зависит не только от разработчиков, но и от продажников, менеджеров, да и просто от ситуации на рынке (а это вообще случайный фактор). Вот и получается, что бонусы становятся неиссякаемым источников демотивации и несправедливости. Я считаю, что разработчикам необходимо обеспечивать достойную, честную зарплату для их уровня профессионализма. Ну может, с возможностью депремирования за серьезные нарушения дисциплины (у меня такое в практике понадобилось один раз). Также нужно давать четкую обратную связь, четкое понимание целей и давать возможность развития (с бонусами это уже не связано). И как раз для этого нужен сильный непосредственный руководитель (потому что метрики, опять же, не работают).
1. Метрики. Безусловно, производительность разработчиков оценивать нужно. И руководство компании, и непосредственный руководитель, и самое главное, сам разработчик должны понимать, насколько хорошо/плохо он справляется со своими задачами и достигает своих целей. Вот только работающих KPI для разработчиков еще никто не придумал. Почему это так — тема слишком общирная для обсуждениях в комментариях. Это хорошо изложено у классиков, таких как ДеМарко, Листер, Брукс и т.п., и весь мой личный опыт и опыт коллег это подтверждает. И даже тот факт, что в некоторых компаниях метрики используются, доказывает, на мой взгляд, лишь то, что метрики могут в лучшем случае не мешать.
2. Бонусы. Я считаю, что бонусы для разработчиков оправданы только в том случае, когда их производительность четко связаны с финансовым результатом. А это бывает крайне редко и применимо только для индивидуальных разработчиков и очень маленьких команд, готовых брать на себя бизнес-риски. Потому что в команде из 5-10 человек, работающих над одним проектом, уже невозможно выделить вклад каждого (потому что метрик не существует). Да и финансовый результат уже зависит не только от разработчиков, но и от продажников, менеджеров, да и просто от ситуации на рынке (а это вообще случайный фактор). Вот и получается, что бонусы становятся неиссякаемым источников демотивации и несправедливости. Я считаю, что разработчикам необходимо обеспечивать достойную, честную зарплату для их уровня профессионализма. Ну может, с возможностью депремирования за серьезные нарушения дисциплины (у меня такое в практике понадобилось один раз). Также нужно давать четкую обратную связь, четкое понимание целей и давать возможность развития (с бонусами это уже не связано). И как раз для этого нужен сильный непосредственный руководитель (потому что метрики, опять же, не работают).
Как раз в этой системе описано, как можно измерить эффективность работника — сравниваем планируемую оценку с фактом. Притом оценивает задачи эксперт и его точность оценки увеличивается. Пока не вижу объективных аргументов против данной системы. Если показатели KPI не работают, важно понимать, почему они не работают. Возможно просто нет понимания, что именно мешает им работать…
Точность оценок трудоемкости задач разработки (а точнее, ее отсутствие) — это отдельная тема для разговора. Но даже если предположить, что такие оценки в вашем случае существуют (я немного пофантазирую), то как только к ним будут привязаны значимые для людей бонусы, возникнет обратная связь, влияющая на оценки. Вместо того чтобы работать, люди начнут оптимизировать и продавливать оценки, которые им нужны для бонусов. Придется дорабатывать систему бонусов до тех пор, пока рядовые сотрудники вообще не перестанут понимать, как рассчитывается их доход, а руководителям придется тратить половину времени на доработку и контроль системы метрик.
Я, конечно, немного утрировал, но мысль, думаю, ясна. Я бы не посоветовал внедрять такую систему. В любом случае, лучший судья в этом деле — практика, а решение за вами — попробуйте, расскажете через полгода-год, что получилось.
Я, конечно, немного утрировал, но мысль, думаю, ясна. Я бы не посоветовал внедрять такую систему. В любом случае, лучший судья в этом деле — практика, а решение за вами — попробуйте, расскажете через полгода-год, что получилось.
На моем уже двухгодичном проекте работает:) я вроде обосновала, что именно мешает всяким там продавливаниям оценок. Буду, конечно, тестить еще на паре разных проектов.
Это интересно, хотя буду честен, верится мне с трудом. А если не секрет, какой в среднем процент от совокупного дохода на руки составляют бонусы (за год, например)? И как вы определяете факт, что система работает?
В любом случае — вам успехов!
В любом случае — вам успехов!
Насчет процента, боюсь, это секрет. Насчет, определения факта работы системы. На моем проекте есть своя определенная специфика:) И мне самой интересно будет ли она работать в общем случае. Хочу посмотреть на комментарии и потом в общих чертах опишу почему она работает на моем проекте. И, если ее не разбомбят (чем я и мои коллеги сейчас тоже занимаются) мы попробуем ее на еще паре проектов. Вот такая я хитрюга:)
Несколько дополнений к данной системе:
1. Не стоит привязывать выдачу бонусов чисто к факту попадания/непопадания в план. Лучше рассчитывать на то, что бонусы команда будет получать все время, если не натворили совсем уж капитальных косяков. Т.е, если клиент вцелом доволен, то бонусы выплачиваются команде в любом случае. Но все же остается возможность не выплатить бонусы кому-то одному, опять же только за явные косяки.
Таким образом, факт получения бонуса становиться постоянным, но каждый член команды получит из нее разный кусок — кто больше и лучше работал, у того и сумма бонуса выше. А значит вариант договориться с командой, чтоб в случае выполнения задачи быстрее, каждый пошел покурить и не показывал факт перевыполнения плана уже не выйдет, все равно бонусы команда в общем случае получит.
2. Насчет качества кода. Опасность состоит в том, что стремясь сделать работу быстрее, чем в оценке, качество кода может страдать. Как с этим бороться: после каждого спринта обязательно вылазят баги. Нет смысла оставлять их фикс на конец проекта, обычно в начало каждого последующего спринта включают фикс каких либо багов. Так вот загвоздка в том, что как раз за время потраченное на фикс багов бонусы не даются.
Таким образом пока команда не пофиксит баги в начале спринта она не может приступить к задачам, за которые даются бонусы. Что мотивирует чинить баги быстрее. И чем больше багов, тем меньше задач будет выполняться в спринте- это опять же не выгодно команде, а значит каждый будет стараться минимизировать кол-во багов и повысить качество кода. Кроме того, многие баги фиксят те же люди, которые занимались данным багнутым куском функционала — получается в общем случае, кто накосячил тот и чинит. Естественно есть разные баги и не все можно привязать к конкретному куску функционала, но пока команда не починит их к задачам приступить они не смогут.
3. Конечно вопрос о целесообразности денежной мотивации остается. Но данная система позволяет контролировать проект и поощрять старания каждого члена команды. И показать, что не нельзя полагаться на то, что эффективность каждого оценить нельзя, значит можно расслабиться — все равно в общей куче виноватого не найдут. Если уровень зарплаты призван отражать общий профессионализм, то бонусы призваны показывать эффективность на данном конкретном проекте в данный промежуток времени — сразу видно, кто начал расслабляться
1. Не стоит привязывать выдачу бонусов чисто к факту попадания/непопадания в план. Лучше рассчитывать на то, что бонусы команда будет получать все время, если не натворили совсем уж капитальных косяков. Т.е, если клиент вцелом доволен, то бонусы выплачиваются команде в любом случае. Но все же остается возможность не выплатить бонусы кому-то одному, опять же только за явные косяки.
Таким образом, факт получения бонуса становиться постоянным, но каждый член команды получит из нее разный кусок — кто больше и лучше работал, у того и сумма бонуса выше. А значит вариант договориться с командой, чтоб в случае выполнения задачи быстрее, каждый пошел покурить и не показывал факт перевыполнения плана уже не выйдет, все равно бонусы команда в общем случае получит.
2. Насчет качества кода. Опасность состоит в том, что стремясь сделать работу быстрее, чем в оценке, качество кода может страдать. Как с этим бороться: после каждого спринта обязательно вылазят баги. Нет смысла оставлять их фикс на конец проекта, обычно в начало каждого последующего спринта включают фикс каких либо багов. Так вот загвоздка в том, что как раз за время потраченное на фикс багов бонусы не даются.
Таким образом пока команда не пофиксит баги в начале спринта она не может приступить к задачам, за которые даются бонусы. Что мотивирует чинить баги быстрее. И чем больше багов, тем меньше задач будет выполняться в спринте- это опять же не выгодно команде, а значит каждый будет стараться минимизировать кол-во багов и повысить качество кода. Кроме того, многие баги фиксят те же люди, которые занимались данным багнутым куском функционала — получается в общем случае, кто накосячил тот и чинит. Естественно есть разные баги и не все можно привязать к конкретному куску функционала, но пока команда не починит их к задачам приступить они не смогут.
3. Конечно вопрос о целесообразности денежной мотивации остается. Но данная система позволяет контролировать проект и поощрять старания каждого члена команды. И показать, что не нельзя полагаться на то, что эффективность каждого оценить нельзя, значит можно расслабиться — все равно в общей куче виноватого не найдут. Если уровень зарплаты призван отражать общий профессионализм, то бонусы призваны показывать эффективность на данном конкретном проекте в данный промежуток времени — сразу видно, кто начал расслабляться
В порядке легкого конструктивного троллинга)
То есть если в команде все работают примерно одинаково, то нет разницы, насколько велика производительность команды в целом — бонусы все равно все получат такие же? Я считаю, что команда должна быть нацелена в целом на результат — а уж они сами пусть разбираются, кто молодец, а кто тянет всех на дно. У меня подход такой — провалили спринт — ответственность тимлида. Кто-то там что-то не сделал? Ничего не знаю — ты набираешь команду и отвечаешь за нее и за результат. Уволь, возьми другого. Конечно, чтобы такой подход работал, тимлид должен иметь соответствующие полномочия. А для внутренних разборок в команде хорошо работает метод ретроспективы, который помогает сосредоточиться на решении проблем, а не на взаимных обвинениях.
Кстати, сделанными задачи у нас считаются тогда, когда они оттестированы, а найденные critical и major баги исправлены. Еще важно ставить критерии выполнения задачи, иначе при сдаче спринта тоже много эмоций возникнуть может.
То есть если в команде все работают примерно одинаково, то нет разницы, насколько велика производительность команды в целом — бонусы все равно все получат такие же? Я считаю, что команда должна быть нацелена в целом на результат — а уж они сами пусть разбираются, кто молодец, а кто тянет всех на дно. У меня подход такой — провалили спринт — ответственность тимлида. Кто-то там что-то не сделал? Ничего не знаю — ты набираешь команду и отвечаешь за нее и за результат. Уволь, возьми другого. Конечно, чтобы такой подход работал, тимлид должен иметь соответствующие полномочия. А для внутренних разборок в команде хорошо работает метод ретроспективы, который помогает сосредоточиться на решении проблем, а не на взаимных обвинениях.
Кстати, сделанными задачи у нас считаются тогда, когда они оттестированы, а найденные critical и major баги исправлены. Еще важно ставить критерии выполнения задачи, иначе при сдаче спринта тоже много эмоций возникнуть может.
эт да, задачи считаем выполненными после починки critical и major багов, просто потом еще вылазят обычно:) Да сумма бонуса в данной системе должна быть как-то фиксирована, например процент от суммы договора (если разработка для кого-то). Если разработка для себя, придется сразу прикинуть сумму, которую готовы выделить на бонусы. Только распределится эта сумма неравномерно между членами команды- в зависимости от сделанной работы и зп. Ретроспектива, да полезно.
Против вашего подхода ничего не имею, будем думать:)
Против вашего подхода ничего не имею, будем думать:)
Поддержу мнение. В мотивации программиста самое сложное — правильно оценить время необходимое на исполнение задачи.
Немного запоздалый итог по моей же статье:
1. Вышеприведенная система расчета бонусов неплохо показала себя в проекте по разработке графики. Почему?
Потому как задачи на проекте были стандартные и заранее хорошо оценены. Плюс одну задачу обычно выполнял один человек.
Достаточно легко было оценить вклад каждого и соответственно рассчитать вознаграждение. Всем членам команды была очевидна связь между быстротой+качеством их работы и вознаграждением. Таким образом, для проектов с типовыми многократно повторяющимися задачами вполне может сгодится.
2. Тем не менее, не вижу перспектив для такой системы на проектах с более сложной структурой, где оценка задач по времени не является стандартизированной. Плюс, если предполагается активная командная работа над одной задачей, такая система вознаграждения и мотивации заставляет скатываться в микро-менеджмент и теряет всякий смысл. Гораздо эффективнее иметь хорошую слаженную команду.
Всем спасибо за комментарии и критику!
1. Вышеприведенная система расчета бонусов неплохо показала себя в проекте по разработке графики. Почему?
Потому как задачи на проекте были стандартные и заранее хорошо оценены. Плюс одну задачу обычно выполнял один человек.
Достаточно легко было оценить вклад каждого и соответственно рассчитать вознаграждение. Всем членам команды была очевидна связь между быстротой+качеством их работы и вознаграждением. Таким образом, для проектов с типовыми многократно повторяющимися задачами вполне может сгодится.
2. Тем не менее, не вижу перспектив для такой системы на проектах с более сложной структурой, где оценка задач по времени не является стандартизированной. Плюс, если предполагается активная командная работа над одной задачей, такая система вознаграждения и мотивации заставляет скатываться в микро-менеджмент и теряет всякий смысл. Гораздо эффективнее иметь хорошую слаженную команду.
Всем спасибо за комментарии и критику!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эффективность команды. Расчет бонусов