Pull to refresh
0

Тайны мадридского двора. Часть II: система материальной мотивации разработчиков

Reading time 7 min
Views 12K
Предыдущий текст серии, описывающий устройство бизнес-процесса постановки и выполнения задач, рекомендован для предварительного ознакомления.
Здесь же — о том, как и за что получают деньги программисты. Задачи, решаемые нашей системой мотивации разработчиков. KPI.

I.Цели и задачи


Система материальной мотивации разработчиков Ultima (СММР) ориентирована на достижение целей из трех групп:
-удовлетворенность заказчика результатом
-качество выдаваемого кода согласно стандартам
-стимулирование профессионального роста разработчиков
Цели СММР достигаются через трансляцию их в соответствующие KPI, значения которых, в свою очередь, определяют повышающие\понижающие коэффициенты и\или бонусы\малусы.
Специальное примечание от Ultima Consulting: СММ в компании Ultima (не только Р!) спроектирована таким образом, чтобы при формировании итогового дохода всех сотрудников без исключения 100% исключить субъективизм и высасываемую из пальца произвольную чушь.

Все считает компьютер в полностью автоматическом режиме — и, соответственно, исключительно на базе объективно измеряемых, фиксируемых и хранимых в базе данных показателей. Никаких “оценок босса”, “итогов встреч” и прочей корпоративно-идиотической ереси.

Каждый сотрудник предельно ясно знает, что ему нужно сделать, чтобы заработать больше. А также, чего НЕ.

Впрочем, это важно, но недостаточно. Намного важнее то, что СММ строится таким образом, чтобы синхронизировать личные интересы сотрудников и общие интересы бизнеса. То есть сотрудник зарабатывает больше денег вместе с компанией и никак иначе.

Строго математически из этого следует, что у нас нет и не может быть системы планирования, использующейся лобовым образом в управлении HR.

Еще одним непосредственным следствием из жирного принципа является отсутствие в штатном расписании должностей, экономическая отдача которых не может быть объективно подсчитана. Собственно, в предыдущей части этот подход демонстрировался на кейсе отказа от внутренних тестировщиков.


Далее все это разберем детально.

II. Зарплатная формула разработчика


Итоговый доход разработчика за период = Сумма Бонусов по выполненным задачам (2.1) + МалусЗаОшибки (2.2) + ОбщеДисциплинарныйБонус (2.3)

Бонус за выполненную задачу (2.1) = ЗатраченныеЧасы (2.1.1) * ТарифнаяСтавкаРазработчика (2.1.2) * КоэффициентПриоритета (2.1.3) * КоэффициентОценкиЗаказчика (2.1.4) * КоэффициентОшибки (2.1.5) * КоэффициентЗвездности (2.1.6) + МалусПросрочкиИсполненияЗаявки (2.1.7)

ОбщеДисциплинарныйБонус (2.3) = МалусЗаНЕСоответствиеСтандартамКодирования (2.3.1) + МалусНЕСоответствияРабочемуГрафику (2.3.2)

Сумма подразумевается алгебраическая: малусы, согласно названию, — отрицательные величины.

Теперь разберем каждый компонент формулы.

2.1 Бонус за выполненную задачу

2.1.1 Затраченные часы
Подробно — см. в предыдущей серии. Коротко — разработчик указывает сколько часов он потратил для решения задачи.

2.1.2 ТарифнаяСтавкаРазработчика
Собственно, базовая ставка часа для программиста (далее будем называть ее внутренний тариф). В предыдущей серии мы смотрели, как через выбор квалификации требуемого разработчика определяется стоимость часа для клиента (внешний тариф). С точки зрения компании, не кривя душой, первую можно назвать себестоимостью, а вторую — продажной ценой. Первая, безусловно, существенно меньше второй — именно на эти “два прОцента” мы и живем.

Внутренний и внешний тариф, естественно, связаны. Но не напрямую, а через таблицу соответствий грейдов разработчиков.

Одной ступени квалификации программиста для клиента (Junior, Developer, Senior) может соответствовать (и соответствует в реальности) несколько грейдов, а внутри каждого грейда может существовать (и существуют в реальности) несколько субгрейдов, для каждого из которых установлена своя базовая ставка часа.

Грейд разработчика является официальной оценкой его профессионального уровня.
Всего у нас шесть грейдов.
Первый грейд разработчик получает после прохождения первоначального обучения. Переходы между субгрейдами и грейдами происходят автоматически — по мере накопления опыта решения задач (экспириенс из Heroes) при условии разумного уровня качества.
Экспириенс считается через суммирование зачардженных часов, плохие оценки и ошибки идут в минус (тривиально — за каждую ошибку столько то часов в минус, за оценку ниже Х столько-то и тд)
Для получения высших грейдов сверх необходимого экспириенса требуется написание статей для внутренней базы знаний.
На практике разработчик получает 5-й грейд примерно через полтора-два года после трудоустройства.
Итак, система внутренних грейдов стимулирует работать больше и лучше тем, что параллельно с профессиональным ростом разработчик получает больше денег (за то же время работы).

2.1.3 КоэффициентПриоритета
За задачи повышенного приоритета разработчик получает усиленное питание (перечеркнуть) повышенный коэффициент, применяемый к базовой ставке, вытекающей из его грейда-субгрейда.

2.1.4 КоэффициентОценкиЗаказчика
При переводе задачи в “выполнено” заказчик выбирает оценку результата:

В нашей внутренней кухне удовлетворительной оценкой считается четверка, соответственно при этой оценке разработчик получит по базовой ставке грейда.
Оценка выше четырех — повышающей коэффициент по этой задаче, меньше — понижающий.
Коэффициент оценки — самый важный модулирующий коэффициент в итоговом доходе.
И разработчик это знает.
Соответственно, привлекательность расклада кнопочек на форме, корректность и своевременность контакта с заказчиком, проникновение в его мысли и желания и так далее — есть стимул за этим смотреть.
Или, по меньшей мере, не действовать “на отъ… бись”.

2.1.6 КоэффициентЗвездности
Напомню, заказчик в заявке может указать не только уровень разработчика, но и конкретного исполнителя для заявки.
Если какой-то из разработчиков пользуется повышенным спросом, повышающий коэффициент может быть применен к его базовой ставке, вытекающей из грейда. Коэффициент применяется только для тех заявок, в которых клиент выбирает только этого исполнителя и не касается заявок, распределенных роботом из общей очереди.

2.1.5 КоэффициентОшибки и 2.2 МалусЗаОшибки
Как я уже писал в прошлой части, задачи типа “Ошибка” обрабатываются специальным образом.
Есть два типа ошибок:
-Созданные как дочерние заявки — то есть на этапе фиксации ошибки в онлайн-трекере известно, в результате реализации какой заявки она возникла
-Отдельно стоящие заявки — когда факт ошибки есть, а источник происхождения не очевиден

“Дочерние” ошибки попадают напрямую к тому исполнителю, который делал основную заявку. Ошибки исправляются бесплатно — и для клиента, и для программиста.
Отдельно стоящие заявки распределяются в общей очереди в соответствии с приоритетом.
Исполнитель, на которого назначается такая задача, может указать виновника ошибки — если это возможно. Работы по исправлению в этом случае будут произведены за счет последнего (по себестоимости).
Если определить автора косяка не представляется возможным, то стоимость исправления равномерно распределяется между всеми разработчиками, участвовавшими в проекте пропорционально сумме зачардженных часов.
Сумма себестоимости исправления личных ошибок разработчика и его пропорциональная доля нераспределенных косяков и составляет его личный месячный МалусЗаОшибки.

Такая практика, несмотря на ее кажущуюся суровость (а, точнее, благодаря) однозначно мотивирует разработчиков действовать в соответствии с принципом “принимать, не создавать, не пропускать брак”.
Почему кажущуюся? Легко сравнить с практикой материальной ответственности кладовщиков или кассиров. У которых она является самой по себе разумеющейся.

Естественным следствием бескомпромиссной мотивации на минимизацию ошибок являются
-улучшение выходного кода в сторону его читаемости
-написание интеграционных тестов

Разработчики ясно видят связь между понятным кодом, в котором легко исправить ошибку (и понести незначительные потери) и невнятной белибердой.
В непонятном коде разработчик, получивший задачу с признаком ошибка, может потратить много времени на разбирательство. А если еще и будет определен виновный (а мотивация его определить тем больше, чем дороже вышло исправление косяка) по задаче, то…
Короче лучше быть богатым и здоровым, то бишь писать понятный код и учиться это делать у других.
Аналогичные рассуждения приводят разработчиков и к написанию интеграционных тестов.

2.1.7 МалусПросрочкиИсполненияЗаявки
Наверняка не только нам знаком вопрос: “Что с заявкой XXX? Уже 3 дня как она должна быть сделана!” Весьма недовольным тоном.
Важный компонент удовлетворенности заказчика — соблюдение прогнозных сроков.
На практике — соблюдение или своевременный перенос перенос этих сроков.

МалусПросрочкиИсполненияЗаявки направлен как раз на информированность заказчика, ибо в реальной жизни возникает много объективных причин для пересмотра срока.
Например — задача требует интеграции с оборудованием у заказчика. И это оборудование сломалось. Приходится ждать его починки или замены.

Итого, нам нужно мотивировать разработчика соблюдать сроки, или хотя бы держать заказчика в курсе изменений.
После многочисленных опытов заработала только отрицательная мотивация.
Для заявок с приоритетом обычная увеличивается МалусПросрочкиИсполненияЗаявки за каждый день сверх плановой даты заявки. Для срочных и критических задач — за каждый час.

Поскольку ожидаемый срок в заявке может перенести только заказчик, то необходимость надлежащего информирования последнего и обоснования при необходимости вытекают автоматически.

2.3 Общедисциплинарный бонус

2.3.1 МалусЗаНЕСоответствиеСтандартамКодирования
В распоряжении каждого разработчика есть Coding Standard. Что как чего надо делать, и чего делать нельзя.
Документ постоянно актуализируется — с одной стороны, от системщиков-ядерщиков при выпуске новых билдов платформы , с другой стороны — от прикладников при разборе причин всплывших косяков (собственно, типичный цикл PDCA).

Часть этого документа содержит достаточно формальные требования, которые мы проверяем автоматически. Например, все наши решения должны работать на русском и английском языках. А значит, в программе не должно быть константных строк (за исключением специально помеченных или однозначно определяемых — например SQL запросов), все строковые константы должны браться из ресурсов, и в ресурсах должны быть значения для всех поддерживаемых языков. Этот и подобные им проверки выполняются с использованием Roslyn в автоматическом режиме. Они реализованы так, что разработчик в принципе не может передать заказчику несоответствующую работу.

В свою очередь, мы стремимся максимально формализовать Coding Standard, чтобы по возможности сократить необходимость ручных проверок.

Малус рассчитывается как фиксированная сумма за каждый случай обнаружения косячного кода.
Полезные рекомендации предложения разработчиков по развитию Coding Standard не только позволяют сократить потери от бесплатного исправления, но и единоразово премируются.

2.3.2 МалусНЕСоответствияРабочемуГрафику
В предыдущей статье я упоминал, что разработчики вольны работать по своему, удобному им графику. Однако, сформировав собственный график, разработчик обязан его придерживаться и быть доступен в установленные им самим часы.
Если выяснится, что разработчик не был на связи в нужное время, плюсуем сабжевый малус — по Х рублей за каждый случай.

В заключение


В итоге многолетнего эволюционного развития СММР мы достоверно наблюдаем реальное повышение удовлетворенности заказчиков, качества и надежности кода, есть мотивационная платформа для введения code review и дальнейшего повышения качества кода и обслуживания.
Средняя оценка по задачам за 2015-й год составляет 4.4, двойка — крайне редкий форс-мажор.

В следующих сериях — что такое бизнес-аналитик (в целях создании интриги — у нас это понятие существенно отличается от общепринятого), зачем он нужен и его мотивация

Автор благодарит Ultima Consulting за неоценимую помощь, как собственно в построении бизнес-процессов компании, так и в создании настоящей серии.
Tags:
Hubs:
+1
Comments 67
Comments Comments 67

Articles

Information

Website
www.ultimaerp.com
Registered
Founded
Employees
51–100 employees
Location
Россия