Как мы разработали систему грейдинга для системных аналитиков

Привет, Хабр! Сегодня я хочу поделиться опытом создания и внедрения системы грейдинга для системных аналитиков в моей компании. Эта история о том, как стремиться сделать оценку сотрудников объективной, прозрачной и мотивирующей, какие результаты получили в итоге, какие выявили недостатки. В рамках компании, система грейдинга коснулась нескольких направлений разработки, я же буду акцентировать внимание именно на системных аналитиках.

Предпосылки к созданию системы грейдинга

В какой-то момент к компании пришло осознание необходимости пересмотреть подход к оценке и развитию системных аналитиков. Существовало несколько причин, которые подтолкнули нас к этому решению.

Во-первых, требовалась объективная система оценки сотрудников. Хотелось избежать предвзятости и субъективности, которые могли возникать при традиционных методах оценки. Каждый аналитик должен был понимать, по каким критериям его оценивают, и видеть ясную связь между своими усилиями и результатами.

Во-вторых, команда росла быстрыми темпами. Направление, к которому в том числе относятся и системные аналитики, увеличилось с 20 до 200 человек за относительно короткий период. Это создавало новые вызовы в управлении персоналом, и нужна была структура, которая помогла бы эффективно оценивать и развивать сотрудников в условиях быстрого роста.

Кроме того, столкнулись с проблемой коммуникации между различными отделами. Не все в компании до конца понимали, чем именно занимаются системные аналитики, и как их работа влияет на общий успех. Хотелось говорить на языке цифр и объективных показателей, чтобы улучшить взаимодействие с бизнес-подразделениями и другими командами.

Наконец, было важно создать среду, в которой сотрудники чувствовали бы мотивацию к развитию и видели перспективы роста внутри компании. Прозрачная система оценки могла помочь в достижении этой цели.

Подход к разработке матрицы грейдинга

Первым шагом на пути к созданию системы грейдинга стало определение ключевых навыков и компетенций, необходимых системным аналитикам в нашей компании. Был проведен анализ потребностей бизнеса, обсудили ожидания от роли системного аналитика и сформировали перечень навыков, которые считали важными. Так родилась многоуровневая карта навыков системных аналитиков. 

Основное внимание уделили техническим навыкам, аналитическим компетенциям, софтам и лидерским качествам. 

• Технические навыки – понимание баз данных, интеграционных процессов и архитектуры систем. 

• Аналитические компетенции – умение собирать и анализировать требования, понимать бизнес-процессы компании и переводить их в технические решения, взаимодействовать с другими подразделениями. 

• Софты – коммуникативные способности, умение работать в команде, вести переговоры, представлять свои идеи, особые виды мышления. 

• Лидерские качества – особенно важны для senior-аналитиков, которым предстоит руководить командами и принимать тактические решения.

В итоге сформировались отдельные категории и навыки внутри них. Важно понимать что состав навыков может заметно отличаться в зависимости от ряда факторов, таких как:

• Сфера и компания

• Потребности бизнеса

• Состав ролей в команде

• Продукт, над которым будет работать

• Стек технологий и системы, с которыми надо работать

Поэтому в первую очередь вам надо задать вопросы: а кто такой системный аналитик именно для вас? Чем он будет заниматься сейчас и в будущем?

По итогу, для нашей компании категории и навыки получились следующие:

1. Работа с требованиями:

   1. Извлечение требований — как извлекать и собирать требования, методики сбора, критерии качества требований.

   2. Анализ требований — непосредственно сам процесс анализа, из каких этапов состоит, что применяется и т.д.

   3. Документирование — подходы к документированию требований, включая используемые инструменты, стандарты, способы формализации информации в удобном для прочтений виде

   4. Согласование требований — с кем, как и когда надо согласовывать требования

   5. Основы UI/UX — понимание что это, а также влияние дизайнеров на системный анализ и наоборот

2. Проектирование:

   1. Архитектура — архитектура современного программного обеспечения, по большей части речь о микросервисах, брокерах, монолитах и т.д.

   2. Схемы и визуализация — различные виды диаграмм и сфера их применения, diagrams-as-a-code, а также когда стоит или не стоит использовать диаграммы

   3. Базы данных — разновидности БД, основы моделирования данных, проектирование моделей данных, SQL, анализ данных

   4. Основы интеграции — основные виды интеграций, способы и форматы взаимодействия

   5. REST — отдельно и более углубленно про REST, так как почти все наши сервисы базируются на нем, аналитик должен уметь проектировать и описать контракт по нашим стандартам

   6. OpenAPI — OAS, swagger

   7. SOAP — в малой степени, т.к. часть систем в компании по другому интегрировать не умеют 🙂

3. Общие:

   1. Основы сети — базовое понимание работы сетей и основные протоколы

   2. Инструменты продуктивности — здесь больше инструментарий общего плана, который используется в компании и умение им правильно пользоваться

   3. Git — знать что это, как читать и как контрибутить (наши аналитики пишут документацию по подходу docs-as-code)

   4. Разработка технической документации —  что и как надо описывать, какие инструменты и стандарты использовать, как сделать информацию легко читаемой

   5. Понимание процессов разработки — тут подробнее про SDLC и его этапы

   6. Понимание Agile / Scrum / Kanban — здесь думаю итак понятно 

   7. Основы тестирования — для чего нужно тестирование, какие виды бывают, когда и что используется

4. Софты — перечень необходимых вам в зависимости от потребности и ценностей компании

Выше представлено краткое описание, на самом деле у нас есть отдельное дерево, в котором представлены категории, навыки и их составляющие. Это многоуровневое дерево помогает нам видеть полную карту и составлять планы развития. У всех сотрудников есть доступ к нему, для изучения.

После определения ключевых навыков разработали структуру грейдов. Мы разделили их на три основных уровня: 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, чтобы грейдинг основывался не только на знаниях и навыках, но и продуктивности сотрудника.

• Кроме того, хотим расширить систему грейдинга на другие роли внутри компании, которые пока не охвачены данным процессом, адаптируя ее под специфические требования и ожидания от разных позиций. Это поможет создать единую и согласованную систему оценки для всех сотрудников.

Рекомендации для внедрения грейдинга в других компаниях (даже если вы их не просили)

На основании опыта могу дать несколько рекомендаций тем, кто задумывается о внедрении подобной системы:

• Вовлекайте сотрудников в процесс разработки. Это поможет учесть их мнение, получить ценные идеи и снизить сопротивление изменениям.

• Обеспечьте прозрачность и открытость. Сотрудники должны понимать, по каким критериям их оценивают, и как они могут повлиять на свои результаты.

• Создайте свою карту навыков. В зависимости от ряда условий (сферы компании, технологического стека, ролей в команде и т.д.) требования к роли аналитика могут отличаться.

• Будьте гибкими и готовы к изменениям. Система должна адаптироваться к новым реалиям и потребностям бизнеса. Все равно возникнут случаи что сотрудники будут оцениваться по разным версиям матрицы, что неизбежно и практикуется при многих сертификациях.

• Поддерживайте постоянную коммуникацию. Регулярно общайтесь с сотрудниками, собирайте обратную связь, отвечайте на вопросы и решайте возникающие проблемы.

Заключение

Система грейдинга стала важным инструментом в развитии процессов развития сотрудников. Она помогла создать прозрачную и объективную систему оценки, повысить мотивацию сотрудников и улучшить взаимодействие внутри команды. Мы продолжаем работать над ее совершенствованием, адаптируя под новые вызовы и потребности.

Надеюсь, этот опыт будет полезен. Делитесь мнениями и комментариями, буду рад обсудить в комментах.