Привет, Хабр! Сегодня я хочу поделиться опытом создания и внедрения системы грейдинга для системных аналитиков в моей компании. Эта история о том, как стремиться сделать оценку сотрудников объективной, прозрачной и мотивирующей, какие результаты получили в итоге, какие выявили недостатки. В рамках компании, система грейдинга коснулась нескольких направлений разработки, я же буду акцентировать внимание именно на системных аналитиках.
Предпосылки к созданию системы грейдинга
В какой-то момент к компании пришло осознание необходимости пересмотреть подход к оценке и развитию системных аналитиков. Существовало несколько причин, которые подтолкнули нас к этому решению.
Во-первых, требовалась объективная система оценки сотрудников. Хотелось избежать предвзятости и субъективности, которые могли возникать при традиционных методах оценки. Каждый аналитик должен был понимать, по каким критериям его оценивают, и видеть ясную связь между своими усилиями и результатами.
Во-вторых, команда росла быстрыми темпами. Направление, к которому в том числе относятся и системные аналитики, увеличилось с 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, чтобы грейдинг основывался не только на знаниях и навыках, но и продуктивности сотрудника.
Кроме того, хотим расширить систему грейдинга на другие роли внутри компании, которые пока не охвачены данным процессом, адаптируя ее под специфические требования и ожидания от разных позиций. Это поможет создать единую и согласованную систему оценки для всех сотрудников.
Рекомендации для внедрения грейдинга в других компаниях (даже если вы их не просили)
На основании опыта могу дать несколько рекомендаций тем, кто задумывается о внедрении подобной системы:
Вовлекайте сотрудников в процесс разработки. Это поможет учесть их мнение, получить ценные идеи и снизить сопротивление изменениям.
Обеспечьте прозрачность и открытость. Сотрудники должны понимать, по каким критериям их оценивают, и как они могут повлиять на свои результаты.
Создайте свою карту навыков. В зависимости от ряда условий (сферы компании, технологического стека, ролей в команде и т.д.) требования к роли аналитика могут отличаться.
Будьте гибкими и готовы к изменениям. Система должна адаптироваться к новым реалиям и потребностям бизнеса. Все равно возникнут случаи что сотрудники будут оцениваться по разным версиям матрицы, что неизбежно и практикуется при многих сертификациях.
Поддерживайте постоянную коммуникацию. Регулярно общайтесь с сотрудниками, собирайте обратную связь, отвечайте на вопросы и решайте возникающие проблемы.
Заключение
Система грейдинга стала важным инструментом в развитии процессов развития сотрудников. Она помогла создать прозрачную и объективную систему оценки, повысить мотивацию сотрудников и улучшить взаимодействие внутри команды. Мы продолжаем работать над ее совершенствованием, адаптируя под новые вызовы и потребности.
Надеюсь, этот опыт будет полезен. Делитесь мнениями и комментариями, буду рад обсудить в комментах.
Комментарии (5)
Gur_Gaz
03.12.2024 14:31Работая в компании, которая достояние России, читаешь подобные статьи и думаешь - неужели где-то так бывает... Подход интересный, наши HR кроме фиктивного ежегодного анкетирования не делают ничего, и это действительно сильно влияет на мотивацию.
Tiabzz Автор
03.12.2024 14:31Добрый день! Спасибо за комментарий. В целом вы всегда можете предложить в HR такого рода подход и совместно с ними проработать свой подход к грейдингу. Участие HR важно, т.к. это относится к управлению талантами и в целом к управлению персоналом. В свою очередь вы можете им помочь по карте навыков, т. к. вы лучше знаете требования к своей предметной области.
Dmitriy06
03.12.2024 14:31Меня в таких оценках смущает, что меня как сотрудника стимулируют развивать компетенции, а не выполнять рабочий задачи, не трубется становиться экспертом конкретной системы. Как сотруднику, с точки зрения своей денежной карьеры, мне выгодней тратить больше времени на чтение литературы, курсы и т.д., а рабочие задачи выполнять по минимуму чтобы не уволили. А даже если уволят, за это время я успею развить компетенции и устроюсь в другую фирму.
Tiabzz Автор
03.12.2024 14:31Добрый день! Спасибо за комментарий.
В подразделе "Планирование будущего", в третьем пункте, я говорю о том, что сейчас мы так же прорабатываем оцифрованный Performance review. Это делается для того, чтобы продуктивность человека так же влияла на результат грейдинга.
Если человек не продуктивен (работает по минимуму), тут скорее будет не грейдинг, а немного другой процесс и разговор. Одно другое не исключает.
На счет экспертности конкретной системы. У нас инхаус разработка, мы не специализируемся на какой то отдельной вендорской системе (типа SAP, Colvir и т.д.). Поэтому мы больше акцентируемся на тех или иных необходимых в именно нашей работе технологиях и компетенциях, навыках. Которые в свою очередь много где востребованы, поэтому сотрудник, изучая и используя их помогает компании, и себе.
ingvarotto
Странно. Анализ по классике — это про отклонения. вызванные нарушением требований.
Анализ имеет свой жизненный цикл и методологию. У вас про это ничего.
Ваше грейдирование делает акцент на технических знаниях, но не на том, как выявить и устранить отклонение. Это отдельный вид искусства. Мне кажется, что вы довольно многое упустили, возможно, даже и суть аналитической деятельности.
Tiabzz Автор
Добрый день! Спасибо за комментарий.
- Основную часть процессов, подходов и методик анализа мы тестируем в пунктах 1.1.-1.4. Эти пункты декомпозируются на составляющие, о которых я частично упоминал в кратком описании каждого навыка. У нас отдельно ведется карта навыков, где уровень детализации каждого навыка глубже, на пару уровней.
- BABOK как и многие руководства/стандарты достаточно избыточен для прикладного использования. Только некоторые вещи оттуда были использованы при разработке нашего грейдинга. Надо не забывать что BABOK в первую очередь ориентирован на БА.
- В статье я так же говорил про ролевую модель и факторы, которые влияют на состав навыков в грейдинге. О важности сначала определить роль СА в вашей команде/компании. Ролевая модель СА в нашей компании и вашей, может значительно отличаться и я не призываю вас просто копировать навыки из этой статьи. В нашей ролевой модели СА больше инженера, многие бизнес-требования им приходят уже на входе.