Часто ли мы слышим: “Я написал крутой код, но мне не заплатили” или “Эти программисты стОлько получают, но не ясно, какой от них толк”? К сожалению, да, потому что оценивать труд программиста количественно очень сложно из-за специфики самого ремесла создания программ.
Проблема весьма серьезная, потому что невозможность четко оценивать труд участников рабочего процесса или непрозрачность таких оценок ведет к демотивации как сотрудников отдела разработки, так и работников других отделов компании, и увеличивает пропасть непонимания между разработчиками и их коллегами.
И все же, такие оценки труда разработчика существуют:
- Выполнение плана.
Да, но: план можно выполнить и перевыполнить, при этом качество кода может быть таковым, что потребуется много времени на исправление багов и приведение кода к состоянию, соответствующему метрикам качества, принятым в проекте. - Отсутствие багов.
Да, но: насколько быстро этого удалось добиться. Позволить месяц писать кусок кода из 20 строк, не содержащий ошибок – непозволительная роскошь для большинства компаний. - Оценка руководителя.
Да, но: оценка руководителя не всегда бывает объективной, а необъективная оценка является демотивирующим фактором для команды разработчиков и, при этом, ставит под угрозу и эффективность бизнеса в целом. - Количество строк кода или коммитов.
Совсем смешная оценка, потому что слишком легко накрутить свою эффективность, что в конце концов демотивирует программиста, а у заказчика возникает вопрос “Раз у вас все такие эффективные, где же решение моих задач?”
Получается, что ни одна схема не может дать желаемого результата: прозрачности и справедливости оценки труда.
Что же делать?
Хочу поделиться своими набросками, касающимися схемы оценки труда разработчика.
Мы будем рассматривать наиболее распространенную схему оплаты труда: оклад + премия. С одной стороны, она дает ощущение стабильности программисту, с другой мотивирует работать лучше.
Что касается оклада, он не столь интересен для рассмотрения в этой статье, потому что его величина вычисляется исходя из региона, возможностей работодателя, опыта и ожиданий разработчика, и я вряд ли скажу об этом что-то новое и интересное.
В предлагаемой схеме оклад изменяться не должен, такого программисты не простят: “урезание” зарплаты вызовет лишь чувство страха, неуверенности и недоверия, что отрицательно скажется на результатах работы.
Ясно, что любой проект может быть разделен на задачи, поэтому предположим, что мы решаем некую задачу; на ее примере будем оценивать, как же вознаграждать разработчика за участие в проекте.
Итак, схема
Будем считать, что мы точно знаем:
- Базовую стоимость выполнения задачи.
Эта стоимость может быть вычислена по окладам интересующих участников разработки. - Премиальную ставку (не важно, в процентах от базовой стоимости или фиксированную)
- Сроки выполнения задачи.
При условии, что эти сроки были определены по оценкам всех участников, они контролируются экспертом и все пожелания в отношении сроков были учтены в процессе обсуждения, предполагаем, что мы можем их “застолбить”, то есть, сроки выполнения задачи не могут быть изменены ни при каких обстоятельствах.
Тогда, премия рассчитывается по формуле:
премиальная ставка + надбавка за скорость + стоимость помощи другим участникам — стоимость устранения дефектов
При выплатах учитываются только положительные значения надбавки за скорость и премии. В случае отрицательных значений используются неденежные порицания или меры, применяемые в компании в качеcтве “кнута” :-), а разработчик получает только оклад.
Рассмотрим подробнее расчет составляющих схемы.
Стоимость устранения дефектов разработки
Какие дефекты могут быть:
- непосредственно ошибки
- ухудшение производительности проекта в связи с внедрением решения
- допущенные несоответствия метрикам качества, принятым в проекте
Оценка времени устранения дефектов может или обсуждаться (на это нужно не так много времени) или определяться по багтрекеру, что тоже не запредельно сложно. Раз мы знаем время, затраченное на устранение дефекта участниками и базовую стоимость работы каждого участника устранения дефекта, мы можем вычислить общую стоимость устранения всего дефекта. Для усиления мотивации умножим эту стоимость на 2.
Получается, что величина стоимости устранения всех дефектов, порождаемых интересующим разработчиком вычисляется, хоть и с некоторой погрешностью.
Надбавка за скорость
Мы знаем базовую ставку участника за единицу времени. Поэтому легко можем получить надбавку за скорость, умножив эту ставку на выигранное время.
Стоимость помощи другим участникам
Опять же, зная базовую ставку каждого участника за единицу времени и какой процент задачи и кто выполнил, мы легко получаем стоимость помощи для интересующего разработчика.
Отмечу, что премия должна выплачиваться с некоторым опозданием, чтобы количество известных допущенных разработчиком ошибок и недоработок было близко к истинному. Каково это опоздание, сильно зависит от стадии проекта, наличия отдела тестирования и количества людей, которые используют решение.
Пример расчета
Рассчитаем вознаграждение программиста Василия за задачу. Пусть базовая стоимость выполнения задачи Василием 20 000 руб. Задача должна быть выполнена за 5 дней. Зафиксирована премия в размере 5 000 руб. Василий выполнил задачу за 3 дня и помог начинающему программисту Петру, стоимость участия которого 2 000 руб., сделав за него 35% задачи. При этом в процессе тестирования было обнаружено багов и недочетов, на исправление которых затрачен 1 день Василием и 1 день Иваном, стоимость участия которого 40 000 руб.
надбавка за скорость = 5 000 * 0.4 = 2 000 руб.
стоимость помощи другим участникам = (2 000 * 0.35) = 700 руб.
стоимость устранения дефектов = (4 000 * 1 + 8 000 * 1) * 2 = 24 000 руб.
Премия Василия = 5 000 (сама премия) + 2 000 (надбавка за скорость) + 700 (стоимость помощи другим участникам) — 24 000 (стоимость устранения дефектов) = — 16 300 руб.
Василий остался без премии и за задачу получит только 20 000 руб. Василию нужно, по всей видимости, быть внимательнее и работать над собой.
Результат
В результате, помимо столь желанной прозрачности и справедливости оценки труда мы получаем:
- повышение ответственности за оценку сроков разработчиками.
Никто не хочет работать сверхурочно, а ошибки при оценке сроков приведут именно к таким последствиям. - снижение к минимуму сроков разработки и повышение качества решения
Разработчик будет пытаться минимизировать разницу между положительной и отрицательной дельтами премиальной составляющей, чтобы увеличить свой доход. - повышение самостоятельности разработчиков
Кому приятно признать, что работу за него сделал другой человек, тем более, если это оформлено документально и обсуждается вне отдела.
Казалось бы, простая арифметика может привести к глубокой перестройке системы мотивации и изменению атмосферы к коллективе. Внедрение такой схемы, конечно же, требует некоторых затрат, но профит, согласитесь, манящий – слаженные и здоровые процессы в компании.
Где можно применить?
Эта формула, конечно же, приближенная и упрощенная, однако, на мой взгляд, может с некоторыми адаптирующими поправками использоваться в любом проекте, касающемся разработки программного обеспечения.
Благодарю за внимание. Мне бы хотелось услышать ваше мнение об изложенном материале.
Автор: eugena
