Уважаемые опытные коллеги, мне необходима ваша помощь в вопросе мотивации разработчиков.
Я руковожу достаточно долговременным проектом, который существует и развивается уже несколько лет.
Т.е. суть деятельности — это постоянное развитие, доработка, внедрение нового, улучшение старого функционала, выполнение доработки под некоторых заказчиков и пр.
Не могли бы вы помочь мне сформировать более-менее пригодную систему мотивации?
Как видите, у нас не вполне проектная деятельность — т.е. у нас нет как таковой сдачи проекта заказчику, после которой можно раздавать бонусы.
Соответственно, хотелось бы сформировать систему, которая побуждала бы разработчиков работать более эффективно и качественно.
В литературе упоминается, система мотивации должна быть привязана к целям компании. Но у нас условия таковы, что существует фиксированный фонд оплаты труда, который не особо зависит от результатов деятельности компании. Его, конечно, можно менять, но это достаточно длительный процесс и он не зависит от итогов работы за какой-то период короткий — например, за месяц.
Поэтому у меня нет возможности провести четкую связь между прибылью компании и премиями. Кроме того, эти вопросы решаю не я, а вышестоящее руководство.
Собственно и систему мотивации я тоже, естественно, буду согласовывать и утверждать у руководства.
Таким образом, вопрос стоит так — по каким объективным характеристикам работы программистов можно осуществлять их поощрение?
Я рассматривал некоторые варианты — кол-во строк кода, кол-во допущенных ошибок и т.п. — но они показались мне не достаточно эффективными, так как они не способны в полной мере показать результаты усилий и производительность труда.
Одним из показателей, которые я счел более-менее приемлемыми для поощрения — это результаты Code Review.
Т.е. раз в 1-2 месяца у каждого разработчика проводится Code Review "комиссией" из 3-х человек, где оценивается качество кода, комментирование, соответствие стандартам кодирования и пр., код оценивается по различным характеристикам и затем по результатам проверок выдаются небольшие премии.
Но этого, как я понимаю, недостаточно.
Хотелось бы стимулировать не только качество кода, но и интенсивность труда (личный пример действует не на всех, а стоять за спиной у каждого и контролировать его невозможно).
Поэтому, я буду очень благодарен за помощь в этом вопросе.
1. разрешить "совам" приходить по своему графику сна-бодрствовавния
2. создать условия для отдыха на рабочем месте — выделить помещение под небольшой спортзал — теннисный стол, базовые тренажеры
3. закупить удобные кресла и хорошие мониторы
4. провести перепланировку офиса с разбивкой его на кубиклы для 1-4х человек по желанию самих работников, чтобы каждый получил то, что хочет
5. закупить много вьющейся зелени (чтобы расставить еее по всему офису — не какие то кусты или грошки с цветами, а чтобы все стены были озеленены) и вентиляторов, чтобы вокруг была природная обстановка и легкий ветерок
думаю пункты 1,2, 4 и 5 потребуют вложений не более чем зарплата одного-двух хороших программистов в столице за 1 месяц
если у вас нет даже таких денег, то тогда ситуация безвыходная
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Уважаемые опытные коллеги, мне необходима ваша помощь в вопросе мотивации разработчиков.
еще такая вот мысль
6. хорошенько продизайнить офис подручными средствами
— копии хороших старых картин (можно и желательно с голыми женщинами и мужчинами — зависит от полового состава коллектива)
— бумажки с прикольными надписями и картинками — офисный юмор
— всякие прикольные стильные вещи, которые можно поставить на полки илиразвесить по стенам
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>Но у нас условия таковы, что существует фиксированный фонд оплаты труда, который не особо зависит от результатов деятельности компании.
Предлаю считать строчки кода. Это реально работает
«Чем больше думаешь о прибыльности, тем больше понимаешь, как сильно она зависит от талантливости ключевых персон в организации»
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>В литературе упоминается, система мотивации должна быть привязана к целям компании. Но у нас условия таковы, что существует фиксированный фонд оплаты труда, который не особо зависит от результатов деятельности компании. Его, конечно, можно менять, но это достаточно длительный процесс и он не зависит от итогов работы за какой-то период короткий — например, за месяц.
M_E>Поэтому у меня нет возможности провести четкую связь между прибылью компании и премиями. Кроме того, эти вопросы решаю не я, а вышестоящее руководство.
Система мотивации должна быть завязана на те факторы, над которыми человек имеет непосредственный контроль. Не думаю, что программист имеет прямой контроль над таким фактором, как финансовый результат компании. Будет ли такая мотивация заставлять их работать лучше? Не думаю. По крайней мере, эта часть не должна доминировать в мотивации.
M_E>Таким образом, вопрос стоит так — по каким объективным характеристикам работы программистов можно осуществлять их поощрение? M_E>Я рассматривал некоторые варианты — кол-во строк кода, кол-во допущенных ошибок и т.п. — но они показались мне не достаточно эффективными, так как они не способны в полной мере показать результаты усилий и производительность труда.
Ни в коем случае нельзя применять софтверные метрики для рассчета "коэффициентов мотивации". Вы добьетесь недостоверности метрики и ухудшения качества результата. Для KPI надо брать ту метрику, максимизируя которую человек делает пользу. Увеличение количества строк кода — идет во вред а не в пользу. Количество допущенных ошибок — вариант получше, но он не будет стимулировать разработчиков заниматься рискованными задачами. Все эти метрики — плохи, и помимо прочего вредят командообразованию.
M_E>Одним из показателей, которые я счел более-менее приемлемыми для поощрения — это результаты Code Review. M_E>Т.е. раз в 1-2 месяца у каждого разработчика проводится Code Review "комиссией" из 3-х человек, где оценивается качество кода, комментирование, соответствие стандартам кодирования и пр., код оценивается по различным характеристикам и затем по результатам проверок выдаются небольшие премии.
Тоже плохой вариант. Code review эффективен только тогда, когда он делается часто и регулярно — перед каждым коммитом в репозиторий, а также человеком, который в теме задачи. Кроме того, Code review должен быть перекрестным, а не проводится комиссией избранных. И в третьих, цель code review — находиждение ошибок, а не оценка "качества кода" по абстрактным критериям.
M_E>Но этого, как я понимаю, недостаточно. M_E>Хотелось бы стимулировать не только качество кода, но и интенсивность труда (личный пример действует не на всех, а стоять за спиной у каждого и контролировать его невозможно).
Лучше забудь об этом. Можно давать премии только за простые вещи — например, соблюдение стандарта кодирования, который закреплен документом и контроллируется на регулярных code review. Но это напрямую к результату не относится.
G>Лучше забудь об этом. Можно давать премии только за простые вещи — например, соблюдение стандарта кодирования, который закреплен документом и контроллируется на регулярных code review. Но это напрямую к результату не относится.
Да, но ведь как-то надо поднимать производительность труда.
0rc>Предлаю считать строчки кода. Это реально работает
Не думаю. Если ты пишешь больше кода, это не значит, что у тебя производительность или качество выше.
___>этосоздают комфортную психологическую обстановку
Комфортная обстановка — это понятно. Но она, как бы сказать, ни к чему не побуждает.
Т.е. да, она определенно помогает, устраняет отвлекающие факторы, создает в какой-то мере рабочий настрой и т.п.
Но все-таки этого мало.
V_S>А зачем? Какова конечная цель поднятия этой самой мифической "производительности труда"?
Ну тут сразу несколько целей.
1. Чтобы не расхолаживать коллектив. Если разработчики будут работать хуже то удовлетворенность пользователей и клиентов будет снижаться, и в результате компания будет терять свои конкурентные преимущества.
2. Соответственно, чтобы повысить объем выполняемых работ, через это предоставить больше сервиса пользователям и клиентам.
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>1. Чтобы не расхолаживать коллектив. Если разработчики будут работать хуже то удовлетворенность пользователей и клиентов будет снижаться, и в результате компания будет терять свои конкурентные преимущества.
И что? Какой прок от "конкурентных преимуществ компании" конкретно программисту Васе Пупкину?
M_E>2. Соответственно, чтобы повысить объем выполняемых работ, через это предоставить больше сервиса пользователям и клиентам.
Что-то я сомневаюсь, что "повышение объема выполняемых работ" и "больше сервиса пользователям и клиентам" шибко нужно Васе Пупкину. Типа "работай больше — получай столько же"?
Мне кажется, что твоя ошибка в том, что ты пытаешься выстроить некую идеальную систему мотивации, но смотришь на ситуацию с точки зрения довольно абстрактных (для работника) "ценностей компании" — т.е., с точки зрения работодателя. Попробуй изменить взгляд и посмотреть на ситуацию с точки зрения работника: что он должен делать, чтобы больше зарабатывать, и что он реально может из этого сделать? (Любые цели мотивации должны быть — достижимы. Иначе эта мотивация работника не просто заинтересует.)
V_S>И что? Какой прок от "конкурентных преимуществ компании" конкретно программисту Васе Пупкину?
В том то и проблема, что сейчас никакого проку. Т.е. как я написал сразу, что мы имеем фиксированный фонд оплаты труда, который конечно можно менять, но это, скажем так, не происходит автоматически при изменении прибыли компании.
V_S>Мне кажется, что твоя ошибка в том, что ты пытаешься выстроить некую идеальную систему мотивации, но смотришь на ситуацию с точки зрения довольно абстрактных (для работника) "ценностей компании" — т.е., с точки зрения работодателя. Попробуй изменить взгляд и посмотреть на ситуацию с точки зрения работника: что он должен делать, чтобы больше зарабатывать, и что он реально может из этого сделать? (Любые цели мотивации должны быть — достижимы. Иначе эта мотивация работника не просто заинтересует.)
Да, я полностью с вами согласен, цели должны быть достижимы, понятны, всем известны и желательно каким-то образом измеримы.
Давайте теперь поговорим более конкретно — что для этого лучше?
Т.е. какие цели следует формировать для разработчиков на такой стадии проекта, как это нужно делать, как с этими целями потом работать, т.е. контролировать их достижение?
Я был бы весьма признателен, если бы вы описали свой конкретный опыт — это было бы очень ценно для меня.
Здравствуйте, Michael_E_Smrinov, Вы писали:
V_S>>И что? Какой прок от "конкурентных преимуществ компании" конкретно программисту Васе Пупкину? M_E>В том то и проблема, что сейчас никакого проку. Т.е. как я написал сразу, что мы имеем фиксированный фонд оплаты труда, который конечно можно менять, но это, скажем так, не происходит автоматически при изменении прибыли компании.
Я думаю, что в вашем случае стоит позаниматься улучшением микроклимата в коллективе...
например, добавить элемент соревновательности между группами или отдельными программистами...
(устраивать конкурсы на решение задач с премиальным фондом, давать небольшие одинаковые задачи разным группам т.д.)
дать возможность рядовым программерам побыть немного в роли тимлидов, тимлидам в роли ПМ....
создать экспериментальный отдел, где любой желающий мо мере возможности мог бы поработать над решением новых задач....
В общем, трудно посоветовать что-либо конкретное, не зная ничего об обстановке в коллективе...
Завидую людям, которые могут себе позволить никуда не спешить.
Я согласен с постингом Gaperton'а 16.06.08 13:18. Система мотивации должна быть завязана на факторы, над которыми программист Вася Пупкин имеет непосредственный контроль, и достижение целей мотивации должно приносить пользу как Васе, так и компании.
Почему ты думаешь, что у вас "не вполне проектная деятельность"? Что-то мешает работу по доработке и сопровождению продукта или по кастомизации его под конкретного заказчика оформить как отдельный проект? Четко сформулировать фичи, которые должны быть введены (достигнуты) в этой итерации ЖЦ, сроки... Выполнили проект в срок, достигли всех поставленных целей — получите денюжку. Плохо, конечно, что вы имеете "фиксированный фонд оплаты труда, который конечно можно менять, но это, скажем так, не происходит автоматически при изменении прибыли компании." Попробуй с этим повоевать... убедить руководство. В противном случае, тебе останется только чисто моральное стимулирование, — типа вымпела "Ударника капиталистического труда", не более...
V_S>Почему ты думаешь, что у вас "не вполне проектная деятельность"? Что-то мешает работу по доработке и сопровождению продукта или по кастомизации его под конкретного заказчика оформить как отдельный проект? Четко сформулировать фичи, которые должны быть введены (достигнуты) в этой итерации ЖЦ, сроки... Выполнили проект в срок, достигли всех поставленных целей — получите денюжку. Плохо, конечно, что вы имеете "фиксированный фонд оплаты труда, который конечно можно менять, но это, скажем так, не происходит автоматически при изменении прибыли компании." Попробуй с этим повоевать... убедить руководство. В противном случае, тебе останется только чисто моральное стимулирование, — типа вымпела "Ударника капиталистического труда", не более...
В общем-то так оно и есть — действительно, большие доработки я веду по RUP, текущую деятельность — в рамках примерно 1-2 месячных циклов.
Т.е. ты предлагаешь сверять плановые и фактические трудозатраты и поощрять тех программистов, кто уложился в план.
Я все правильно понимаю?
Здравствуйте, Michael_E_Smrinov, Вы писали:
M_E>В общем-то так оно и есть — действительно, большие доработки я веду по RUP, текущую деятельность — в рамках примерно 1-2 месячных циклов. M_E>Т.е. ты предлагаешь сверять плановые и фактические трудозатраты и поощрять тех программистов, кто уложился в план. M_E>Я все правильно понимаю?
Это может стать очень хорошей демотивацией. На сложных задачах риск вылететь из срока выше. Следовательно больше получать будут те, кто делает задачи попроще.
Практически любую недооцененную задачу можно формально сдать к необходимому сроку. Вопрос только в качестве.
Возникает соблазн уменьшать фактические трудозатраты.
Могу предложить сырую идею, сам не пробовал. Покритикуйте:
Время от времени проводится конкурс решения проблем. Каждый желающий предлагает проблему и найденое им решение за последний период времени. Оценка результатов может производиться кем угодно в зависимости от ситуации. Результаты публикуются, первые места получают премию.
Z>Это может стать очень хорошей демотивацией. Z> Z> На сложных задачах риск вылететь из срока выше. Следовательно больше получать будут те, кто делает задачи попроще. Z> Практически любую недооцененную задачу можно формально сдать к необходимому сроку. Вопрос только в качестве. Z> Возникает соблазн уменьшать фактические трудозатраты. Z>
Да, мне тоже так кажется.
Кроме того, для того, чтобы железно вписаться в план, будет соблазн выдавать заранее завышенные оценки трудозатрат, которые потом будет нетрудно соблюсти.
Хотя, конечно, я контролирую эти оценки, но я не могу на 100% гарантировать, что в них не будет такого завышения.
Здравствуйте, Michael_E_Smrinov, Вы писали:
___>>этосоздают комфортную психологическую обстановку M_E>Комфортная обстановка — это понятно. Но она, как бы сказать, ни к чему не побуждает. M_E>Т.е. да, она определенно помогает, устраняет отвлекающие факторы, создает в какой-то мере рабочий настрой и т.п. M_E>Но все-таки этого мало.
ээээ
а на сколько процентов вы хотите поднять производительность?
10? 20? 30? 50? 100?
будем исходить из того, что у вас относительно нормальная среднестатистическая контора
при этом достаточно большая, чтобы отдельные личности не вносили больших погрешностей в статистику
это значит, что реально каждый человек отрабатывает 4-6 часов из 8часового рабочего дня в своем собственном индивидуальном ритме сообразно своим собственным возможностям
как можно увеличить отдачу, не увеличивая и кардинально не меняя штат работников
1. понаблюдать за рабочим процессом и посмотреть на чем можно выкроить приблизительно 1 дополнительный час
наверняка есть какие-то чисто организационные моменты, на которые уходит слишком много времени
но не думаю, что больше 1 часа в день в среднем для каждого на этом удастся выиграть
2. уволить откровенных бездельников и заменить их сотрудниками не ниже среднего
3. создать комфортную обстановку на рабочем месте — как именно, я уже описал
4. проявить индивидуальный подход к работникам, провести опрос на тему того, что именно каждый человек хочет получить от фирмы и дать каждому то, что он хочет
5. ввести систему отчетности, когда каждый человек должен раз в неделю сдавать отчет о проделанной работе, чтобы пункты 3 и 4 не пошли во вред, расхолаживая народ
6. если есть какие-то области в проекте, позволяющие резко поднять профессиональный уровень, то назначить на эти области людей, которым действительно нужно резко поднять профессиональный уровень, и не напрягатся тем, что после поднятия уровня они уйдут в др место
Мда. В такой схеме мотивации:
1. Ооочень существенно возрастает роль менеджера (правильность планирования). Одна ошибка менеджера в плане (ну дурак он, что поделаешь?) может запросто свести на нет все усилия разработчиков, — а они-то в чем виноваты?
2. Для более-менее адекватного планирования тебе нужно иметь банк данных о трудоемкости различных "элементарных" задач, набранный по прошлым проектам (задачам). Это же как-то защитит от преднамеренного завышения сроков.
3. Есть еще такой фактор: "сдать любой ценой, а после хоть трава не расти!". Подумай о применении двух показателей:
— коэффициент выполнения — соотношение планового срока и фактического, слишком большие отклонения как в плюс, так и в минус — сигнал тревоги для менеджера,
— коэффициент поддержки — соотношение времени разработки и времени поддержки и исправления ошибок (не путать с доработкой нового функционала!).
V_S>- коэффициент выполнения — соотношение планового срока и фактического, слишком большие отклонения как в плюс, так и в минус — сигнал тревоги для менеджера, V_S>- коэффициент поддержки — соотношение времени разработки и времени поддержки и исправления ошибок (не путать с доработкой нового функционала!).
Да, это интересные показатели, как мне кажется.
Коэффициент выполнения подсчитать достаточно просто — плановые трудозатраты есть, фактические тоже есть.
А вот с коэффициентом поддержки немного сложнее — конечно, мы ассоциируем ошибки в баг трекере с компонентами системы и назначем их на разработчиков. Но здесь получается, что ошибки еще должны быть ассоциированы с той задачей, решением которой они были порождены — сейчас у меня такой привязки нет. Затем мы сможет подсчитать сколько времени ушло на поддержку.
Получается так?
Да, и теперь, как следует поощрять на основе этих показателей? Морально (ну т.е. кому-то будет стыдно за плохие показатели)?
Или как-то материально?
