Измеряем программистов
Оригинал взят у pavel_koryagin в Измеряем программистов
Не измеряешь - не управляешь, да?
И ещё многие уверены, что измерить производительность программиста нельзя.
Я уверен, что можно. Но нельзя вводить демотивирующие и ломающие (то есть дурацкие) метрики. Поэтому я в течение двух лет не ввёл ни одной.
Однако процесс идёт. Давайте систематизировать знания.
Нормирование
Операции веб-программистов можно нормировать, как операции автослесаря. Но не все. Но часть - можно.
Именно эта часть существенно влияет на воспринимаемое качество. Выкатили прототип фичи за день? Круто. Оптимизировали и полировали её ещё две недели - ну, из бюджета же не выбились, да и пусть.
Такое нормирование может выступать драйвером обучения джуниоров - сделал всё правильно, сразу получил пряник.
Два типа услуги
Есть два принципиально разных цели у работы: обслуживание и проект.
В случае обслуживания (техподдержка, аптайм) в плане измерения всё крутится вокруг SLA. То есть SLA для клиента может быть однозначно спроецировано в показатели сотрудника. Или должно быть попилено, а части потом увязаны, если сотрудников несколько.
В случае проектов... возникают основные дискуссии. Но я вижу это так: уровень качества (не считая сроков) фиксированный, прибыль вариабельна. То есть доход сотрудника должен зависеть от его рентабельности и попадания в сроки. А вот качество должно быть фильтром: не проходит - доделывай, но рентабельность и сроки при этом начинают тлеть.
При обслуживании рентабельность также важна. То есть её тоже нужно считать.
Как не делать сотрудника предпринимателем против его воли
В учёте рентабельности есть два нюанса. Во-первых, сотрудник не должен заботиться о рентабельности бизнеса. Это писец, как сложно, и вне его контроля. Следовательно, это должен быть показатель, который кореллирует с его личным вкладом в общую рентабельность. Вот эту часть мне нужно предельно детализировать, но не в этом посте.
Плюс не убиваем личную безопасность. Если человек в конкретном месяце нерентабелен, он не должен остаться без приемлемой зарплаты. Ну и, чтоб два раза не вставать, внедрение новой системы не должно привести к снижению средней зарплаты - это шаг к развалу компании. Хотя, если у части сотрудников доход в результате радикально упал, и они ушли - это отлично. У хороших сотрудников доход не должен упасть после перехода на показатели.
Во-вторых, вспоминаем, что личный доход находится в оппозиции к рентабельности бизнеса. А должен положительно кореллировать. Пока формула имеет вид "оклад + производная от личного вклада в рентабельность" - всё ок. Когда же в неё добавляются члены для учёта SLA и сроков, нужно перепроверять формулу снова: нельзя ли, варьируя соотношения между параметрами вытянуть сумму в ущерб рентабельности. Вероятно, качество выполнения SLA и сроков (назовём этот показатель вариабельным качеством) должен умножаться на премию по рентабельности, а не складываться с ней. Но не забываем, что этот показатель пока не раскрыт, и там внутри может оказаться формула, которую снова нужно проверять, раскрыв скобки.