Оценка персонала помогает решить сразу несколько задач. Во-первых, что важно для самого сотрудника — он будет знать, насколько хорошо справляется с работой, какие навыки стоит подкачать, а какие уже в порядке. Во-вторых, обратная связь внутри команды или подразделения — это всегда важно, с какой стороны ни посмотри. В-третьих, от оценки и зависят такие приятные штуки, как премии, да и карьерный рост в целом.
Поэтому оценка сотрудников должна быть тщательной, достоверной, учитывать специальность человека и ряд других объективных факторов. То есть с историей вида «Привет, оцени Саню по десятибалльной шкале» тут лучше даже не начинать.
Меня зовут Женя, я разработчик продуктов в QIWI, и в этом посте я расскажу, как в компании появился Грейдер — решение для оценки сотрудников, которые существенно упростило жизнь и эйчарам, и менеджерам команд, и самим ребятам, которых оценивают.
Как было раньше
Собственно, ситуация «До» как раз и прозрачно намекнула, что пора что-то менять. Вот как выглядел процесс оценки в компании до создания Грейдера:
менеджер или тимлид формировали специальный список с указанием, что конкретного человека должны оценить конкретные люди;
эйчары вместе с менеджерами составляли excel-файлы, которые и отправляли коллегам того, кого надо оценить;
коллеги ловили у себя в почте эти монструозные таблицы (вопросы были довольно подробными, и их было немало, штук 50);
после заполнения этих excel-файлов их передавали назад эйчарам;
эйчары сводили все эти таблицы воедино, так получалась единая сводная оценка.
Минусов тут было достаточно. Представьте, как бы вы были воодушевлены, если бы вам в разгар рабочего дня упал такой excel в почту с просьбой оценить коллегу. Если подходить к делу ответственно (а иначе зачем вообще к нему подходить?), то ответить на 50 вопросов о коллеге, расставив в табличке оценки в нужных графах, это не час и не два. А ещё могут быть опечатки — не ту оценку поставил, потому что устал уже от таблицы, и прочее, прочее, прочее. Про прозрачность и говорить нечего — было сложно понять, к кому вообще идти и с кем говорить, если у тебя есть предложения по переоценке в рамках компании. Было непонятно, где и как хранились результаты, соответственно, историю посмотреть тоже было нельзя. В общем, приятного немного.
Поэтому было решено максимально оптимизировать этот процесс, чтобы можно было быстро накликать в форме свою оценку коллеги, все это сохранить и быстренько послать в базу, которая потом и сформирует единую средневзвешенную оценку.
Как именно и что Грейдер оценивает
Есть матрица компетенций, которая заточена под профиль продуктового разработчика и учитывает T-shape развитие под направления (бэкенд, фронтенд и прочее), и под уровень сотрудника.
Например, оценивают бэкендера. Есть общий софтовый блок компетенций плюс харды по направлениям. Внутри оценка каждой компетенции состоит из вопросов — допустим, если мы оцениваем знание Kotlin, то на джуна надо хорошо знать базовый синтаксис и подобное. На мидла — уже понадобится что-то посерьезнее, скажем, ООП. На сениора — reflection и так далее.
Всё это мы внутри называем матрицей компетенций и адаптируем ее под каждую специализацию.
Здесь у нас набор софт-скиллов, оценка того, как человек работает в команде, как проявляет себя, как коммуницирует и прочее. При запуске оценки менеджер выбирает необходимые направления, в которых сотрудник проявил себя; само собой, все разработчики проходят оценку по софтовой части. Например, если человек за время работы проявил себя и в бэкенде, и во фронтенде, то оцениваться он будет по компетенциям из этих направлений.
И тут есть важная история — вес вопросов разный. Скажем, если мы оцениваем бэкендера, то знание условного CSS для него будет плюсом, но небольшим. Такая вишенка сверху в торте его навыков. А вот знание того, как устроена работа с памятью — это уже мастхев специальности, поэтому значение этого вопроса будет оказывать большее влияние на итоговую оценку.
Благодаря автоматизации, у нас теперь есть:
возможность создания и отправки опросников, оповещений;
база знаний;
исторические данные;
удобное визуальное представление.
Как ставятся оценки
Тут не стали ничего усложнять и оставили три градации:
0 — человек вообще не проявлял указанный навык за период оценивания.
1 — проявляет время от времени, в целом неплохо.
2 — проявляет компетенцию везде, где может, и хорошо.
Кроме этих градаций, у сотрудника есть возможность поставить «n/a», если он не может оценить коллегу.
Что за софт используется
Как вы понимаете, вопрос качественной оценки персонала стоит у многих компаний (у некоторых — особенно остро). Так что профильный софт на рынке есть. Но есть нюанс — всё это уже готовые сервисы с минимальным уровнем кастомизации.
И получится, что, взяв готовый сервис, даже самый-самый лучший, вам придется затачивать специфику своего процесса оценки под этот сервис. А это плохая история, нужно наоборот — затачивать сервис под существующий процесс оценки.
А так как процесс оценки у нас уже был (причем выстроенный годами), и как-то менять его в угоду возможностям софта не хотелось, мы просто пошли и с нуля написали свой собственный. В процессе на разных этапах участвовали 5-6 разработчиков. Основной язык в компании сейчас Kotlin, но нам хотелось сделать все побыстрее силами доступных разработчиков, так что использовали JS. От начала сбора требований до выхода в прод первой версии прошло месяца 2—3, а до массового применения около 6.
Прозрачность процесса
Одно из следствий внедрения Грейдера — прозрачность. И это очень важная штука. По умолчанию всё происходит вот так:
коллеги, которым надо оценить сотрудника, заполняют опросник по этому сотруднику, ставят оценки,
это всё сохраняется в базу,
на основе общих оценок выводится усредненная.
И по умолчанию этот процесс анонимен, скажем, как вот вы оцениваете водителя в Яндекс Go — там его средний балл формируется как средняя оценка на базе последних, кажется, 50.
Сотрудник, которого оценивали, в своем личном кабинете видит менюшку «Мои оценки».
Раньше ему для этого надо было идти к менеджеру, спрашивать эти результаты. Менеджер в итоге шел за ними к эйчару. И таким макаром могло пару дней уйти на всё про всё. А сейчас это — один клик в личном кабинете и сразу вывод подробных оценок. И, как я писал, по умолчанию это анонимно, то есть человек не знает не только, кто какую оценку поставил, но и сколько вообще было оценивающих.
Почему я пишу «по умолчанию» — потому что это опционально, и в некоторых командах для максимальной прозрачности решили эту анонимность убрать. Но это, скорее, исключение из правил.
Для всех технических вопросов мы завели специальный чатик, куда можно прийти как с конструктивной критикой, так и с предложениями по улучшению Грейдера.
Такая прозрачность играет только на руку продукту.
Ну и да, еще из важного — финальное решение насчет оценки, а значит, и повышения зарплаты или должности, всё равно принимает человек (тимлид, менеджер). И такого, как в том году было в одной компании, а-ля «Наша бигдата посчитала вашу активность в рабочих чатах» тут не будет. Грейдер — полезный инструмент для людей, а не финальная инстанция.
Планы
Во-первых, мы продолжаем активно собирать обратную связь от разработчиков, которые оценивают коллег (и которых оценивают).
Во-вторых, более 80% менеджеров ИТ пришли к нам с запросом о создании матрицы и 100% из них выбирают грейдер для автоматизации.
А как в вашей компании устроен процесс оценки сотрудников?
