В пилоте Codenrock Vibe в «Клерке» участвовали 15 backend- и frontend-разработчиков. У 12 результаты полностью или почти полностью совпали с моими наблюдениями, двое показали результаты выше ожиданий, один — ниже. Подготовка, запуск и разбор заняли около 8–10 часов моей работы, без учёта времени участников.
Разработчик может успешно выполнять привычные задачи, а его знания в других областях остаются за пределами наблюдений руководителя. Я решил дополнить своё представление о команде оценкой технических навыков. Меня интересовало, что покажет тестирование знакомых мне сотрудников и сколько усилий потребует его организация.
Для пилота мы использовали Codenrock Vibe — AI-платформу полного цикла оценки персонала: сотрудники и кандидаты. В нашем случае задача касалась оценки и развития действующей команды.
Что показала оценка технических навыков
После тестирования я сравнил отчёты с тем, что вижу в ежедневной работе. У 12 из 15 разработчиков результаты полностью или почти полностью совпали с моим представлением об их уровне.
Двое показали результаты выше ожиданий — в том числе благодаря знаниям SQL-оптимизации и интеграций, которые не были очевидны в рутинных задачах. Один показал результат ниже ожиданий. Оценка выявила пробелы по ключевым компетенциям: в обычной работе они были менее заметны, поскольку соответствующие задачи закрывали другие участники команды.
Меня удивило, что результаты и индивидуальные планы развития (ИПР) плюс-минус совпали с моим представлением о реальном положении дел.
Баллы, статус прохождения и рекомендации — в одном отчёте.
Как результаты оценки использовали в ИПР
После оценки платформа сформировала ИПР. Я изучил результаты по отдельным компетенциям и предложенные планы. Практическую пользу дали конкретные направления, на которых стоило сосредоточить развитие сотрудников.
Например, у одного backend-разработчика результат тестирования по RabbitMQ составил 5 из 100 баллов, по MySQL — 22 из 100. В ежедневной работе сотрудник не сталкивался с асинхронной обработкой и сложными запросами, поэтому эти пробелы оставались незаметными. В ИПР включили освоение RabbitMQ, усиление MySQL и рефакторинг по SOLID.
У другого разработчика результат по PHP составил 24 из 100 баллов при хороших показателях по REST API и RabbitMQ. Это повлияло на приоритеты развития: в план добавили работу над базовым PHP-модулем с unit-тестами.
При предварительном разборе части отчётов я выделил и повторяющиеся зоны роста backend-разработчиков: RabbitMQ и асинхронную обработку, MySQL, безопасность и авторизацию. Внимания требовали транзакции, уровни изоляции, оптимизация запросов, проверка прав и работа с токенами. У двух frontend-разработчиков в зоны роста попал TypeScript, у одного из них — также Git. Эти наблюдения относятся к разобранной части отчётов, а не ко всей группе из 15 человек.
По итогам разбора сотрудники получили конкретные направления и практические задачи вместо общей рекомендации подтянуть технические навыки. Проверить, как работа по этим планам повлияет на компетенции и повседневные результаты, предстоит на следующем этапе.
Зоны развития и практические задачи для работы над навыками.
Сколько времени я потратил на оценку команды
До Vibe в «Клерке» использовали ручные аттестации и внутренние обсуждения с участием HR и техлидов, иногда привлекали внешних экспертов. Подготовка занимала недели: нужно было согласовать критерии, собрать обратную связь руководителей, организовать собеседования или тестовые задания. По моему опыту, итоговая оценка во многом зависела от мнения конкретного руководителя.
Для пилота я самостоятельно создал профили backend- и frontend-разработчиков, сгенерировал банк вопросов, проверил материалы и запустил тестирование. HR и другие подразделения к организации не подключались. Затем я разобрал результаты и сопоставил их со своими наблюдениями.
По моей оценке, суммарно эта работа заняла около 8–10 часов. Это время моей работы: без пауз на другие задачи и без учёта времени прохождения тестов сотрудниками.
Что потребовало экспертной проверки
По моей оценке, в банке было около 50 вопросов, из которых 2–3 потребовали корректировки. Автоматически сформированные материалы я проверял перед запуском оценки.
Один из примеров касался приведения типов в PHP 8. На мой взгляд, формулировка не учитывала условия, влияющие на поведение кода, в том числе режим строгой типизации. Другой вопрос — о поведении ALTER TABLE внутри транзакции с последующим ROLLBACK — участники трактовали по-разному.
Замечания передавали в поддержку Codenrock Vibe. Исправления занимали несколько часов. Проверка технического контента и точечная работа с поддержкой стали частью пилота.
Как мы планируем использовать результаты оценки
По итогам триала мы планируем распространить подход на другие подразделения и продолжить работу с индивидуальными планами развития.
Результат нас воодушевил. Мы планируем масштабировать этот подход на другие команды и продолжить сотрудничество с Codenrock.
На мой взгляд, повторную оценку имеет смысл проводить не раньше чем через квартал, а в большинстве случаев — примерно раз в полгода. Сотруднику нужно время, чтобы поработать с выявленными зонами развития и применить новые навыки.
