Как мы разработали систему грейдинга для системных аналитиков
Привет, Хабр! Сегодня я хочу поделиться опытом создания и внедрения системы грейдинга для системных аналитиков в моей компании. Эта история о том, как стремиться сделать оценку сотрудников объективной, прозрачной и мотивирующей, какие результаты получили в итоге, какие выявили недостатки. В рамках компании, система грейдинга коснулась нескольких направлений разработки, я же буду акцентировать внимание именно на системных аналитиках.
Предпосылки к созданию системы грейдинга
В какой-то момент к компании пришло осознание необходимости пересмотреть подход к оценке и развитию системных аналитиков. Существовало несколько причин, которые подтолкнули нас к этому решению.
Во-первых, требовалась объективная система оценки сотрудников. Хотелось избежать предвзятости и субъективности, которые могли возникать при традиционных методах оценки. Каждый аналитик должен был понимать, по каким критериям его оценивают, и видеть ясную связь между своими усилиями и результатами.
Во-вторых, команда росла быстрыми темпами. Направление, к которому в том числе относятся и системные аналитики, увеличилось с 20 до 200 человек за относительно короткий период. Это создавало новые вызовы в управлении персоналом, и нужна была структура, которая помогла бы эффективно оценивать и развивать сотрудников в условиях быстрого роста.
Кроме того, столкнулись с проблемой коммуникации между различными отделами. Не все в компании до конца понимали, чем именно занимаются системные аналитики, и как их работа влияет на общий успех. Хотелось говорить на языке цифр и объективных показателей, чтобы улучшить взаимодействие с бизнес-подразделениями и другими командами.
Наконец, было важно создать среду, в которой сотрудники чувствовали бы мотивацию к развитию и видели перспективы роста внутри компании. Прозрачная система оценки могла помочь в достижении этой цели.
Подход к разработке матрицы грейдинга
Первым шагом на пути к созданию системы грейдинга стало определение ключевых навыков и компетенций, необходимых системным аналитикам в нашей компании. Был проведен анализ потребностей бизнеса, обсудили ожидания от роли системного аналитика и сформировали перечень навыков, которые считали важными. Так родилась многоуровневая карта навыков системных аналитиков.
Основное внимание уделили техническим навыкам, аналитическим компетенциям, софтам и лидерским качествам.
Технические навыки — понимание баз данных, интеграционных процессов и архитектуры систем.
Аналитические компетенции — умение собирать и анализировать требования, понимать бизнес-процессы компании и переводить их в технические решения, взаимодействовать с другими подразделениями.
Софты — коммуникативные способности, умение работать в команде, вести переговоры, представлять свои идеи, особые виды мышления.
Лидерские качества — особенно важны для senior-аналитиков, которым предстоит руководить командами и принимать тактические решения.
В итоге сформировались отдельные категории и навыки внутри них. Важно понимать что состав навыков может заметно отличаться в зависимости от ряда факторов, таких как:
Сфера и компания
Потребности бизнеса
Состав ролей в команде
Продукт, над которым будет работать
Стек технологий и системы, с которыми надо работать
Поэтому в первую очередь вам надо задать вопросы:, а кто такой системный аналитик именно для вас? Чем он будет заниматься сейчас и в будущем?
По итогу, для нашей компании категории и навыки получились следующие:
Работа с требованиями:
Извлечение требований — как извлекать и собирать требования, методики сбора, критерии качества требований.
Анализ требований — непосредственно сам процесс анализа, из каких этапов состоит, что применяется и т.д.
Документирование — подходы к документированию требований, включая используемые инструменты, стандарты, способы формализации информации в удобном для прочтений виде
Согласование требований — с кем, как и когда надо согласовывать требования
Основы UI/UX — понимание что это, а также влияние дизайнеров на системный анализ и наоборот
Проектирование:
Архитектура — архитектура современного программного обеспечения, по большей части речь о микросервисах, брокерах, монолитах и т.д.
Схемы и визуализация — различные виды диаграмм и сфера их применения, diagrams-as-a-code, а также когда стоит или не стоит использовать диаграммы
Базы данных — разновидности БД, основы моделирования данных, проектирование моделей данных, SQL, анализ данных
Основы интеграции — основные виды интеграций, способы и форматы взаимодействия
REST — отдельно и более углубленно про REST, так как почти все наши сервисы базируются на нем, аналитик должен уметь проектировать и описать контракт по нашим стандартам
OpenAPI — OAS, swagger
SOAP — в малой степени, т.к. часть систем в компании по другому интегрировать не умеют :)
Общие:
Основы сети — базовое понимание работы сетей и основные протоколы
Инструменты продуктивности — здесь больше инструментарий общего плана, который используется в компании и умение им правильно пользоваться
Git — знать что это, как читать и как контрибутить (наши аналитики пишут документацию по подходу docs-as-code)
Разработка технической документации — что и как надо описывать, какие инструменты и стандарты использовать, как сделать информацию легко читаемой
Понимание процессов разработки — тут подробнее про SDLC и его этапы
Понимание Agile / Scrum / Kanban — здесь думаю итак понятно
Основы тестирования — для чего нужно тестирование, какие виды бывают, когда и что используется
Софты — перечень необходимых вам в зависимости от потребности и ценностей компании
Выше представлено краткое описание, на самом деле у нас есть отдельное дерево, в котором представлены категории, навыки и их составляющие. Это многоуровневое дерево помогает нам видеть полную карту и составлять планы развития. У всех сотрудников есть доступ к нему, для изучения.
После определения ключевых навыков разработали структуру грейдов. Мы разделили их на три основных уровня: Junior, Middle и Senior, с возможностью детализации внутри каждого уровня для более точной оценки. Для каждого грейда были определены конкретные требования и ожидания по каждому навыку.
Например, для Junior аналитиков ожидаются базовые знания SQL, понимание основных принципов работы с базами данных и начальные знания в области интеграции систем. Они должны уметь понимать и формулировать простые требования под руководством наставника, быть готовыми учиться и работать в команде.
Для Middle аналитиков требования выше. Они должны уверенно владеть SQL, иметь опыт работы с различными базами данных, понимать интеграционные процессы и лучше знать архитектуру. В их обязанности входит самостоятельный сбор и анализ требований, предложение оптимальных технических решений, а также хорошие коммуникативные навыки и способность сотрудничать с различными отделами.
Senior аналитики, в свою очередь, должны обладать глубокими знаниями в области архитектуры систем, иметь опыт в сложных интеграционных проектах и быть экспертами в технологиях. Они должны влиять на стратегию, предлагать актуальные решения, понимать рыночные тенденции, а также обладать лидерскими качествами, «наставничать» менее опытных коллег и вести переговоры на высоком уровне.
Реализация системы оценок
Для объективной оценки навыков была внедрена шкала оценок от 0 до 9, где каждая оценка имеет описание, а не просто относительную шкалу. Ноль означает отсутствие знаний или навыков, а девять — высший уровень мастерства и признание эксперта в компании. Стоит отметить что в будущем планируем создать критерии того, что считается базовым, продвинутым, мастерским владением, в разрезе навыком.
Пока что оценки для Hard skills выглядят так:
0 — не знает
1 — знает о чем речь, может дать краткое описание
2 — знает базовую теорию
3 — умеет делать базовые вещи руками, но с использованием мануалов или поиска
4 — умеют делать базовые вещи руками без мануала
5 — продвинутое владение
6 — продвинутое владение + возможность передача знаний
7 — мастерское владение
8 — мастерское владение + возможность передачи знаний
9 — в дополнение к оценке 8 еще и лидирует развитие этого навыка в дирекции
Для Soft skills расшифровка оценок отличается и выглядит примерно следующим образом (промежуточные, пропущенные цифры, являются переходным состоянием):
0 — навык отсутствует
3 — неосознанное владение
5 — осознанное владение и применение
7 — мастерски владеет
9 — мастерски владеет и может обучать
Такая детализированная шкала позволяет более точно оценивать уровень компетенций сотрудников и избегать субъективности.
Мы также ввели весовые коэффициенты для каждого навыка, отражающие его значимость для конкретного грейда. Например, технические навыки имеют больший вес для Junior и Middle аналитиков, в то время как лидерские качества были более значимыми для Senior аналитиков и следовательно вес может быть повышен.
Процесс проведения грейдинга
Процесс грейдинга состоит из нескольких этапов. Сначала сотрудник, желающий пройти оценку, заполняет заявку и получает всю необходимую информацию о процессе и критериях. Это дает ему время подготовиться, изучить матрицу грейдов и понять, чего от него ожидают.
Затем проводится сам грейдинг, который включает техническую часть (4–6 часов для первичной оценки, повторные занимают гораздо меньше времени) и оценку софтов (45 минут). Техническая часть проходит в формате интервью и практических заданий. Сотрудник обсуждает реальные кейсы, решает задачи, демонстрирует свои знания и подходы к решению проблем. Обычно все проходит в составе тимлида, другого коллеги с более высоким грейдом и самого грейдируемого. Оценка софтов проводится HRом (обычно HRBP), который оценивает коммуникативные способности, лидерские качества и умение работать в команде.
После проведения грейдинга все участники процесса — тимлид, второй пилот, HR и сам сотрудник — выставляют оценки независимо друг от друга. Затем оценки сводятся в общую таблицу, учитываются весовые коэффициенты. Если возникают расхождения, проводится обсуждение для достижения согласия.
Сотруднику предоставляется подробная обратная связь с объяснением выставленных оценок, выделением сильных сторон и областей для развития. Это помогает ему понять, где он находится сейчас и что нужно сделать для перехода на следующий грейд.
Последний этап — это заведение заявки на изменение грейда и оклада, в случае успешной защиты.
Важно отметить, что прохождение грейдинга занимает почти целый день, это может вызывать вопросы у сотрудников: зачем тратить столько времени, если за пару часов можно пройти собеседование и получить повышение на рынке? Но если человек видит перспективы в компании, ему нравится коллектив и продукт, то один день на грейдинг — это разумная инвестиция. Любая компания ценит вовлеченность, и те, кто готов развиваться, могут получить условия, лучше чем на рынке. Если же сотрудник не готов к этому, возможно, ему не по пути с компанией.
Особенности процесса
Особое внимание было уделено тому, чтобы сделать процесс грейдинга максимально комфортным для сотрудников. Они могут выбирать место проведения оценки — в офисе, в кафе или даже на природе. Многие предпочитают неформальную обстановку, что помогает снизить напряжение и раскрыться полнее.
Кроме того, мы стремимся минимизировать стресс, связанный с оценкой. Для этого обеспечиваем прозрачность процесса, заранее предоставляем всю необходимую информацию и открыты для вопросов и обсуждений. В процессе грейдинга можно брать перерывы, чтобы отдохнуть и выпить кофе.
Результаты и выводы
Плюсы. За первые 17 месяцев работы системы 57 сотрудников прошли процедуру оценки, и 84% из них успешно защитили свой текущий грейд или повысили его. Конечно это не только системные аналитики, но и другие направления разработки, для которых есть другие матрицы компетенций, при сохранении общего подхода. Сотрудники отмечали, что система помогла им лучше понимать свои сильные и слабые стороны, видеть перспективы роста и планировать свою карьеру внутри компании.
Благодаря прозрачному грейдингу повысилась мотивация сотрудников к развитию и обучению. Они стали более активно участвовать в тренингах, искать возможности для улучшения своих навыков. Кроме того, улучшилось взаимодействие между различными отделами компании, так как общение на языке объективных показателей облегчило понимание и сотрудничество.
Система грейдинга также помогла снизить текучесть кадров среди системных аналитиков. Сотрудники видели, что компания инвестирует в их развитие и предлагает реальные перспективы роста, что повышало их лояльность и желание оставаться в команде.
Затронем минусы. Во-первых, процесс оценки является довольно затратным по времени. Как уже упоминалось, прохождение грейдинга может занимать почти целый день, что вызывает у сотрудников вопросы о целесообразности такого подхода. В некоторых случаях это может отвлекать от основной работы и приводить к временному снижению продуктивности.
Во-вторых, система не всегда отличается достаточной гибкостью. В условиях быстро меняющихся требований и технологий, фиксированные критерии оценки могут устаревать, что создает риски несоответствия текущим реалиям рынка. Потребность в постоянной адаптации системы может усложнить процесс и увеличить нагрузку на тех, кто отвечает за ее поддержание.
Кроме того, без надлежащей автоматизации системы оценок возникает риск путаницы и ошибок. При большом количестве сотрудников и множества критериев оценки, вручную собирать, обрабатывать и интерпретировать данные может быть сложно и неэффективно. Это также увеличивает нагрузку на HR-отдел и тимлидов, что может привести к задержкам и снижению точности оценки.
Планирование будущего
Ясно, что мир IT быстро меняется, и система грейдинга должна соответствовать этим изменениям.
Поэтому планируется регулярно пересматривать критерии оценки, добавлять новые навыки и технологии в матрицу грейдов, которые планируете использовать на проектах.
Также рассматриваем возможность автоматизации отдельных этапов процесса, чтобы сделать его более эффективным и менее трудоемким. Объединить с системой управления талантами.
Собираемся добавить в матрицу оценки performance review, чтобы грейдинг основывался не только на знаниях и навыках, но и продуктивности сотрудника.
Кроме того, хотим расширить систему грейдинга на другие роли внутри компании, которые пока не охвачены данным процессом, адаптируя ее под специфические требования и ожидания от разных позиций. Это поможет создать единую и согласованную систему оценки для всех сотрудников.
Рекомендации для внедрения грейдинга в других компаниях (даже если вы их не просили)
На основании опыта могу дать несколько рекомендаций тем, кто задумывается о внедрении подобной системы:
Вовлекайте сотрудников в процесс разработки. Это поможет учесть их мнение, получить ценные идеи и снизить сопротивление изменениям.
Обеспечьте прозрачность и открытость. Сотрудники должны понимать, по каким критериям их оценивают, и как они могут повлиять на свои результаты.
Создайте свою карту навыков. В зависимости от ряда условий (сферы компании, технологического стека, ролей в команде и т.д.) требования к роли аналитика могут отличаться.
Будьте гибкими и готовы к изменениям. Система должна адаптироваться к новым реалиям и потребностям бизнеса. Все равно возникнут случаи что сотрудники будут оцениваться по разным версиям матрицы, что неизбежно и практикуется при многих сертификациях.
Поддерживайте постоянную коммуникацию. Регулярно общайтесь с сотрудниками, собирайте обратную связь, отвечайте на вопросы и решайте возникающие проблемы.
Заключение
Система грейдинга стала важным инструментом в развитии процессов развития сотрудников. Она помогла создать прозрачную и объективную систему оценки, повысить мотивацию сотрудников и улучшить взаимодействие внутри команды. Мы продолжаем работать над ее совершенствованием, адаптируя под новые вызовы и потребности.
Надеюсь, этот опыт будет полезен. Делитесь мнениями и комментариями, буду рад обсудить в комментах.
