- PVSM.RU - https://www.pvsm.ru -
Часто ли мы слышим: “Я написал крутой код, но мне не заплатили” или “Эти программисты стОлько получают, но не ясно, какой от них толк”? К сожалению, да, потому что оценивать труд программиста количественно очень сложно из-за специфики самого ремесла создания программ.
Проблема весьма серьезная, потому что невозможность четко оценивать труд участников рабочего процесса или непрозрачность таких оценок ведет к демотивации как сотрудников отдела разработки, так и работников других отделов компании, и увеличивает пропасть непонимания между разработчиками и их коллегами.
И все же, такие оценки труда разработчика существуют:
Получается, что ни одна схема не может дать желаемого результата: прозрачности и справедливости оценки труда.
Хочу поделиться своими набросками, касающимися схемы оценки труда разработчика.
Мы будем рассматривать наиболее распространенную схему оплаты труда: оклад + премия. С одной стороны, она дает ощущение стабильности программисту, с другой мотивирует работать лучше.
Что касается оклада, он не столь интересен для рассмотрения в этой статье, потому что его величина вычисляется исходя из региона, возможностей работодателя, опыта и ожиданий разработчика, и я вряд ли скажу об этом что-то новое и интересное.
В предлагаемой схеме оклад изменяться не должен, такого программисты не простят: “урезание” зарплаты вызовет лишь чувство страха, неуверенности и недоверия, что отрицательно скажется на результатах работы.
Ясно, что любой проект может быть разделен на задачи, поэтому предположим, что мы решаем некую задачу; на ее примере будем оценивать, как же вознаграждать разработчика за участие в проекте.
Будем считать, что мы точно знаем:
Тогда, премия рассчитывается по формуле:
премиальная ставка + надбавка за скорость + стоимость помощи другим участникам — стоимость устранения дефектов
При выплатах учитываются только положительные значения надбавки за скорость и премии. В случае отрицательных значений используются неденежные порицания или меры, применяемые в компании в каче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
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/64801
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/229577/
Нажмите здесь для печати.