Давно задумывал поделиться нашим опытом мотивирования программистов и написать эту философско-практическую статью про показатели в денежной мотивации программистов, но все как-то руки не доходили. Честно сказать, даже побаиваюсь ее писать, по моим наблюдениям, тема мотивация IT-специалиста IT-сообществом часто встречается в штыки.
Поэтому, в первой части предлагаю сделать легкое лирическое отступление.
«А надо ли вообще мотивировать деньгами? IT-специалисты работают хорошо не из-за денег их нужно мотивировать по другому! »
Читал в комментариях, слышал на конференциях, задавал вопрос себе, наблюдал за коллегами, и сделал вывод: да, возможно есть IT-спецы, для которых деньги действительно не являются мотивирующим фактором, но их меньшинство.
У нас в компании внедрено денежное стимулирование всех сотрудников, в том числе программистов. Условно говоря, кто больше и лучше работает, тот больше получает. И вот в чем парадокс — я редко видел, что бы за рабочим местом кто-то играл в «Counter-Strike» или растрачивал рабочее время иначе. Зато неоднократно видел это в других компаниях, где денежная мотивация не применялась.
Когда мы 31 декабря решили устроить маленький новогодний турнир по «StarСraft», то после последней игры я сел закрывать задачи, так как это влияло на декабрьскую ЗП.
Когда я сам был программистом, я часто задерживался на работе, что бы повысить свои показатели и получить большее вознаграждение.
Я оставил два своих личных проекта, потому что была возможность зарабатывать больше на основном месте. Возможно, я сам что-то потерял, забросив их, но моя компания то выиграла. Т.е. она добилась того, что бы я больше времени тратил на ее проекты.
В общем, я пришел к достаточно уверенному выводу, что стимулировать сотрудников деньгами нужно. А что вы думаете на этот счет?
Какие показатели мы придумали для стимулирования программистов?
Просто расскажу, какие показатели у нас сейчас есть для денежной мотивации программиста.
Оценка руководителя.
Безумно полезный и логичный показатель, у нас он дифференцированный, т.е. можно поставить «Отлично» (150%), «Хорошо» (100%), «Удовлетворительно» 50%, «Плохо» (0%) и «Опасно» (-50%).
На моей памяти «Опасно» никто не ставил, поэтому я эту оценку считаю лишней.
Еще этот показатель бьется на периоды (4 раза в месяц), это позволяет более дифференцированно оценивать сотрудника.
Через этот же показатель дается обратная связь сотруднику о его работе за период и, с недавних пор, было принято решение об обязательной обратной связи от руководителя к подчиненному в конце месяца, даже если руководитель поставил оценку «Хорошо».
В общем, это безумно полезный субъективный показатель, которым руководитель может влиять на ЗП сотрудника.
Выполнение ДИ и регламентов
Никогда его не понимал, но у нас он есть. Отличается от оценки руководителя тем, что за него нельзя поставить оценку «Отлично». Предполагается, что нужно снижать оценку сотруднику, если тот пришел пьяным на работу, например, ну или нарушил какие либо другие регламенты. Не помню, что бы у программиста хоть раз этот показатель отличался от значения «Хорошо».
Личный план работ (85%)
Этот показатель может принести как массу положительных результатов, так и массу отрицательных.
Основная идея в том, что бы скорость разработки росла. Предполагается, что программист должен сделать задач на 85% своего рабочего времени. Остальные 15% даются, что бы сходит в туалет и попить кофе.
Программисту планируются задачи в часах в разрезе месяца, если он сделал больше, то значение этого показателя пропорционально увеличивается, если меньше, то – уменьшается.
Все бы хорошо, если бы не одна проблема – «Как точно оценить стоимость одной задачи в часах?»
С моей точки зрения, этот вопрос ответа не имеет, поэтому показатель задуманный как объективный, по факту, превращается в субъективный.
Этот показатель полезный – он заставляет сотрудников работать больше, и наглядно показывает каждому сотруднику, как он может влиять на свою заработную плату.
Но и вреда он может наделать много: завышение оценочных часов задач, ухудшение качества кода, формальный подход к реализации задач.
Такой показатель нужно обязательно уравновешивать, в идеале показателями качества SLA. У нас он формально уравновешивается оценкой руководителя.
Оценка заказчика по задачам
На мой взгляд, очень полезный показатель, направленный на повышения качества и клиент ориентированность.
В своей прошлой статье я описывал жизненный цикл задач habrahabr.ru/post/227507/, кому интересно можно почитать. Суть в том, что у каждой задачи есть заказчик, и только заказчик может закрыть задачу. Во время закрытия заказчик должен поставить оценку выполнения и написать комментарий. Затем, все эти оценки заказчика по задачам усредняются и попадают в результативность программиста.
Программист видит развернутую картинку по оценке.
Минус я заметил только один — неразборчивый заказчик, который ставит оценки как попало потому что не хочет понять, что было выполнено в рамках задачи.
Из нашего опыта можно сказать, что по этому показателю очень редко ставят плохие оценки. Еще есть сотрудники, которые завышают его искусственно (но это уже проблема контроля).
Оценка проверки задач
Это тоже полезный показатель. Отличается от предыдущего тем, что на него может влиять тестеровщик или руководитель проекта. Я обычно повышаю оценку, когда программист отказался от формального подхода к задаче и решил ее творчески. Например, хорошо проработал интерфейс.
Средняя задержка по задачам
Этот показатель мотивирует сотрудников сдавать задачи вовремя, в те сроки, которые нужны бизнесу. У нас планирование помесячное, но иногда задачу нужно сделать раньше конца месяца. В таком случае, у задачи изменяется дата выполнения.
В задаче фиксируется дата, когда она была проверена. По этой дате считается задержка выполнения задачи.
Минусы у показателя похожи на минусы личного плана работ: ухудшение качества кода, формальный подход к реализации задач. Но показатель в целом полезный, он позволяет указать deadline.
На мой взгляд, наша система расчета эффективности не сбалансирована и имеет перекос в сторону скорости разработки. Поэтому мы подумываем вводить SLA-показатели (показатели качества), которые будут уравновешивать показатели скорости.
Мы используем Redmine как единую информационную среду и в нем каждый может посмотреть свой расчёт, матрица программиста выглядит вот так.
От каких показателей отказались и почему.
Общая прибыл компании по все направлениям
Когда я был программистом, меня сильно удивляло, почему у меня в системе мотивации есть показатель общей прибыли компании, а у людей, которые эту прибыль приносили – нет! Это было довольно странно и объяснялось тем, что любой программист может повлиять на прибыль тем, что положит какой-нибудь сервер в продакшене.
Но на практике этот показатель был чем-то вроде рулетки в казино. Один месяц ты заработал больше, другой меньше. Но как влиять на показатель в положительную сторону понимания нет.
В результате от показателя отказались.
Грейдирование и степирование.
Еще у нас в компании введено грейдирование. Грейдирование может являться темой отдельной статьи, но поскольку оно связано с материальной мотивации программиста, я коротко расскажу об этом.
Все должности в компании привязываются к грейдам. Грейд — это зарплатная вилка, минимум и максимум, который можно получать в данной должности. Сотрудники привязаны к степам. На основе степа, максимума и минимума грейда вычисляется базовый оклад.
Сотруднику показывается не только его базовый оклад, но и вся линейка окладов по грейду его должности. Просматривая свою заработную плату, каждый сотрудник видит, что он в долгосрочной перспективе может зарабатывать больше.
Руководитель сотрудника может указать глобальные цели, которые должен выполнить его подчиненный, что бы перейти на следующий степ.
Пожаловаться и похвалить
Очень действенная штука, которая позволяет любому сотруднику пожаловаться или похвалить любого сотрудника в рамках компании. Принимать эту жалобу или нет, решает руководитель сотрудника, когда ставит оценку руководителя. Помимо помощи в проставлении оценки, инструмент очень помогает бороться с хамством.
Что следует учесть, вводя материальную мотивацию
Руководители чаще любят хвалить, чем наказывать. Эта природа большинства людей. Хвалить просто и легко и ведёт к позитиву. А вот наказывать неприятно, может вылиться в конфликт, но иногда необходимо, потому что в долгосрочной перспективе последствия могут быть хуже.
Обратная связь, донесенная до сотрудников в качестве пояснения к оценке — это сильный механизм управления и стимулирования сотрудника, но не все это понимают.
Система расчета должна быть автоматизирована и иметь хороший прозрачный интерфейс, что бы конечному сотруднику было понятно, почему он в этом месяце получил именно эту сумму денег. Иначе мотивация может обернуться демотивацией.
Технические специалисты пытаются обойти систему мотивации и искусственно повысить себе значения показателей.
Периодически появляются перманентные конфликты из-за оценок между заказчиком и исполнителем, между руководителем и подчиненным.
Личный план работ мотивирует делать много, но приводит к зацикленности на задачах. В результате время на собрания и другие мероприятия приходится оформлять в виде задачи.
Некоторые программисты сильно мотивируются деньгами, и работаю много. В конце месяца коэффициент эффективности у некоторых может достигать 135%. Поэтому мы все, что больше 120% обрезаем до 120%. Что бы можно было влезть в бюджет и что бы люди успевали отдыхать.
Внедряя расчет KPI, первое время лучше переплатить сотрудникам, иначе можно демотивировать, и будут думать, что систему мотивации внедряют ради экономии.
Плохая оценка воспринимается более обоснованно и ставить ее легче, если плохой инцидент возникает повторно. А первое возникновение этого инцидента зафиксировано в пояснении к оценке «Хорошо».
Это все что хотелось бы сказать в рамках данной статьи. Надеюсь она будет вам полезна.
Автор: tdvsdv
