Потребности озвучиваются разные. Если упростить, то всем хочется решить следующую задачу: взять разработанные критерии, посчитать показатели и сказать "Петя - 7 уровня, Коля - 9 уровня. Потому: Коля для проекта полезнее, ему дадим лычку поинтереснее и на +XYZ денежных знаков больше чем Пете".Возможно ли разработать такие метрики?
Если да, то почему каждый раз речь идет об очередной попытке "изобрести свой велосипед"?
Если же невозможно, то что же делать?
Вопрос сложный. И вот почему.
В чем проблема?
Я рассматриваю ситуацию с позиции проектного менеджера. С акцентом на "проектного".
Что такое проект? С точки зрения
"Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов... Каждый проект приводит к созданию уникального продукта, услуги или результата... Несмотря на то, что в результатах проекта могут присутствовать повторяющиеся элементы, их наличие не нарушает принципиальной уникальности работ по проекту. ...И, наоборот, по причине уникального характера проектов, возможна неопределенность в отношении продуктов, услуг или результатов, создаваемых в ходе проекта..."
Многое в IT software development либо организовано как проекты, либо обладает проектными признаками. Потому имеем такой фактор как "уникальность", а это приводит к сложности построения кросспроектных унифицированных метрик для оценки разработчика.
Сегодня разработчик пишет очередной (но все-таки хотя бы немного отличающийся) интернет магазин, завтра - решение для IoT, послезавтра - занимается разработкой решения для управления роботизированными высотными складами или блокчейном...В аутсорсе, в продукте, в стартапе...
Меняются технологии, команды, заказчики, требования к софтскиллам.
Слишком много переменных, что бы была возможность получить одну интегральную оценку применимую во всех ситуациях и однозначно трактуемую всеми.
Как мерять?
А если не пытаться сводить все к единственной оценке, а разложить на составляющие (компетенции)?
Можем столкнуться с другой проблемой - субъективностью и ситуативностью критериев оценивания.
Как померить все эти "знать", "понимать", "применять", "уметь", "сложные задачи" и т.д. придумать можно. Но это будет ваша оценка, понятная для вас и применимая в вашей ситуации/проекте/компании. Не более. И хорошо, если сумеете внятно разработчику разъяснить формальные признаки отличающие разные уровни, в рамках одной компетенции.
Можно же, конечно, оставить только метрики, которые измеримы.
Количество коммитов в github, количество закрытых багов в jira, количество успешно пройденных ревью кода с первого раза и т.д.
Если таких метрик мало, то повысим риск фокуса усилий на росте конкретных метрик. Вызывая проблемы в направлениях, которые остались без внимания в системе оценок.
Как же это исправить? Построить сложную систему взаимосвязанных метрик.
Сначала потратив много времени на разработку и внедрение.
А потом постоянно вкладывая в контроль правильности и актуальности базовой информации для их расчета.
Ну и на финале затратив время на то что бы таки посчитать итоговые показатели.
Посчитали и что же?
Смотришь на эти финальные цифры и видишь, у сотрудника, согласно оценкам, тот или другой уровень... а вот весь твой опыт работы с этим конкретным человеком так и пытается вставить "да, но...".
"Да, но задачи требующие использования новых технологий делаются медленно".
"Да, но ведь со сложными клиентами он находит язык гораздо проще остальных".
"Да, но ...".
Заключение
Разрабатывать такую систему нужно опираясь на аспекты, которые важны вашему проекту/компании/специфике работы.
Если модель компетенций на уровне компании не разработана, то создайте ее самостоятельно, для себя. Ведь это отличное подспорье в проведении one-to-one (вы же их проводите, правда?! ), performance review митингов.
Базовый список, который использую я, выглядит следующим образом:
- Техническая экспертиза
- Качество выполняемой работы
- Объем выполняемой работы
- Инициативность
- Коммуникация
- Самостоятельность
- Дисциплина
- Лидерство
- Лояльность
Да, это микс субъективных и измеряемых показателей. Да, он меняется от проекта к проекту. Да, меняется и количество уровней в рамках каждой компетенции.
Но наличие даже такого списка позволяет существенно упростить и повысить качество в части people management.
Улучшайте процессы, растите команды! :)
