Как правило, внедрение грейдов помогает компаниям систематизировать оценку разработчиков и удержать ценных сотрудников. При высокой конкуренции между работодателями за хороших ИТ-специалистов квалифицированные работники идут туда, где видят четкую карьерную перспективу. Грейды дают им понимание, как и куда они могут расти в карьерном плане. Компания, в свою очередь, получает структурированный подход к планированию зарплат.
В теории, польза грейдов выглядит неоспоримой. Но на практике ситуация несколько иная, в первую очередь из-за необходимости постоянного их пересмотра. К примеру, мы использовали эту систему для оценки квалификации разработчиков почти 6 лет. Пересмотр грейдов проходил раз в полгода и состоял из двух этапов.
Первый — предварительная самооценка. Каждый сотрудник получал матрицу компетенций, которая охватывала как технические навыки, так и софт-скилы, и выставлял себе оценки по каждому из критериев.
Второй — индивидуальное интервью. Первоначально интервью проводил технический директор, затем к процессу подключились руководители направлений. На пике развития системы каждого разработчика интервьюировали три человека — его непосредственный руководитель, технический директор и главный менеджер.
За это время компания на практике выявила слабые места методики, которые, так или иначе, характерны для всех представителей малого и среднего бизнеса в ИТ.
При штате в 25-30 разработчиков проведение индивидуальных интервью превращалось в недельный марафон, который выбивал из рабочего процесса ключевых сотрудников компании. На одно интервью технический директор и руководители направлений тратили от 4 до 6 часов. Для небольшого бизнеса такие затраты времени становятся непозволительной роскошью, поскольку существенно замедляют работу над важными проектами.
Пересмотр грейдов во многом осложняется разницей в восприятии одних и тех же навыков разными людьми. На интервью, где присутствуют несколько руководителей, возникают ситуации, когда они по-разному оценивают уровень одних и тех же компетенций сотрудника. Дополнительную сложность создает самооценка: опытные разработчики, как правило, выставляют себе более скромные оценки, а начинающие специалисты иногда их завышают. В результате система требует обсуждения и согласования различающихся мнений, что увеличивает временные затраты на проведение интервью.
ИТ-агентства часто берут в работу проекты, в которых используются разные стеки технологий. Программист может быть ценным специалистом в одном проекте, но иметь ограниченные компетенции в другом. Это создает сложности при использовании единой шкалы оценки к сотрудникам, выполняющим принципиально разные по сложности задачи или работающим с разными технологиями. Кроме того, компании с аутстаф-разработчиками в штате часто не могут провести их грейдирование из-за непрерывного рабочего процесса на стороне клиента или потому что стандартная матрица компетенций не учитывает особенности внешних проектов.
Строгая привязка зарплаты к грейду не всегда оправдана. Сотрудники, которые не повышают грейд годами, но стабильно выполняют свои задачи, рискуют остаться без актуализации зарплаты, что может привести к их потере. Даже когда разработчик показывает одинаковый результат на протяжении нескольких оценочных периодов, необходимо регулярно пересматривать его вознаграждение, поскольку рыночная стоимость труда ИТ-специалистов растет.
Принцип «нет повышения грейда — нет повышения оплаты» редко мотивирует сотрудников получать новые знания, зато может навредить бизнесу в условиях высокой конкуренции за кадры.
Иногда самооценка соискателей не соответствует требованиям компании. Хороший опыт на одном проекте не означает, что специалист обладает достаточной практикой и широтой знаний для более высокого грейда. Например, соискатель с годовым опытом коммерческой разработки часто позиционирует себя как мидл-разработчик, хотя для этого уровня компания обычно ожидает минимум двухлетнего опыта работы. Процесс найма усложняется, когда на собеседовании приходится согласовывать разницу между самооценкой кандидата и реальными требованиями позиции.
Практика грейдирования угасла, когда возник тревожный практический кейс: один из клиентов пожаловался на баги в продакшене. Это стало катализатором для создания нового независимого метода оценки качества работы команды и отдельных специалистов - учет процентного соотношения багов к объему выполненной работы.
Эта идея лежит на поверхности и применяется в более крупных компаниях. Существует объем работы и количество ошибок при ее выполнении, и это объективный индикатор качества труда разработчика. Если специалист затратил 10 часов на разработку и 3 часа на исправление ошибок, то эффективность его работы составляет 70%.
Трехуровневая система оценки учитывает:
Количество багов в продакшене (не более одного за релиз);
Плотность багов на задачу (соотношение количества багов к числу задач);
Плотность багов на разработчика (соотношение количества ошибок к числу задач).
Чтобы не перегружать разработчиков дополнительными регламентами, процесс сбора данных постепенно автоматизируется. Самописный скрипт собирает информацию по двум первым уровням с трекера в конце каждого спринта и передает руководителям направлений.
Важный аспект новой методики — правильная интерпретация результатов с учетом специфики проекта. Процент ошибок существенно различается в зависимости от типа проекта. Для стартапов, где главная задача — быстрый запуск, допустимо большее количество багов, чем для стабильных продуктовых команд.
Для обнаружения проблемных зон и контроля качества разработки используется комплекс инструментов: линтеры, статистические анализаторы и архитектурные метрики. Тем не менее, цифры это только ориентир, а не самоцель.
Главное в таком подходе — регулярные встречи с разработчиками для обсуждения конкретных показателей. В отличие от традиционного грейдирования, таких встреч требуется значительно меньше, и они занимают не больше часа, поскольку целью является обсуждение конкретных метрик, а не анализ длинного списка компетенций. При обнаружении задачи с большим числом багов руководители не делают поспешных выводов, а тщательно анализируют причины проблемы. В этом случае не стоит спешить с выводами. Нужно разобраться в корне проблемы. Возможно, разработчику не хватает знаний, и тогда можно организовать обучение. Или процессы сломались, и нужно их чинить. Иными словами, метрики служат не инструментом давления, а отправной точкой для совершенствования навыков команды и рабочих процессов.
Принцип «мужик сказал - мужик сделал» срабатывает не всегда. Попасть в свою оценку — особый навык. Творческие проекты с неизвестными участками почти всегда вынуждают разработчиков корректировать первоначальные оценки.
При этом 100%-ное попадание в оценки не всегда является хорошим показателем, поскольку может говорить о работе по шаблону. Для некоторых специалистов комфортной зоной являются предсказуемые задачи, но порой разработчики страдают от отсутствия профессионального роста при работе над однотипными задачами. Иными словами, метрику можно рассматривать в контексте общего профессионального развития сотрудника и его удовлетворенности работой.
Универсального решения для оценки разработчиков не существует, каждая компания должна найти свой баланс. Например, для небольших агентств традиционное грейдирование часто оказывается избыточным, поскольку руководители обычно хорошо знают потенциал своих сотрудников.
Практика оценки через соотношение багов имеет большой потенциал для закрепления на рынке, поскольку применима во всех проектах. Главное здесь - правильно выбрать ключевые метрики, которые помогают понять, где нужно усилить контроль и оптимизировать процессы.
Для средних и небольших ИТ-агентств метод измерения процента багов служит более объективным инструментом, который может дополнять классические грейды или быть независимой системой оценки качества работы специалистов. В условиях растущей конкуренции на рынке такие инновационные подходы к управлению могут стать важным фактором конкурентоспособности.
Обсудить