Антистресс для дизайн-агентства. Кейс по переделке грейдов с пошаговой инструкцией

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

Если у вас пока нет системы грейдов, эта статья пригодится для знакомства с процессом ее разработки. А если уже есть, вы сможете посмотреть на нее свежим взглядом и, возможно, найти какие-то идеи по доработке.

Антистресс для дизайн-агентства. Кейс по переделке грейдов с пошаговой инструкцией

Привет! Меня зовут Мария Чекмарева. Я помогаю командам мыслить эффективно и избавляться от стресса, выступая в роли бизнес-консультанта и бизнес-коуча. В ситуации, которую я опишу ниже, источником боли для команды стала устаревшая и несовершенная по своей логике система грейдов.

Грейд — это, если по-простому, профессиональный уровень специалиста, который напрямую влияет на размер его зарплаты и сложность доверяемых ему задач.

Вы, наверное, слышали термины Junior-дизайнер, Middle-дизайнер или Senior. Вот это все как раз про грейды. Лестница грейдов помогает ребятам видеть, куда и как именно они могут двигаться в плане развития в компании и увеличения своей зарплаты.

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

Что было до

До переделки основной принцип грейдов в проектном отделе и отделе дизайна был таким: чем больше проектов ты сделал за историю работы в агентстве, тем выше твой грейд и зарплата.

Процедура определения грейда называлась “эволюшн” и проводилась раз в полгода:

  • за каждый выполненный клиентский проект руководитель проектов (РП) или дизайнер получал определенное количество баллов, которые суммируясь переводили его со временем на новый грейд;
  • чем сложнее был проект, тем больше баллов за него полагалось. Сложность, например, для руководителя проектов определялась на основе объема проекта, сложности материалов от клиентов, срочности задачи и ее новизны для специалиста;
  • проект нужно было просто завершить. То, насколько качественно был выполнен проект, на балл никак не влияло;
  • специалисты сами считали баллы: собирали список проектов, определяли баллы за сложность, а потом “продавали” свой расчет руководителям;
  • дополнительно для каждого грейда был прописан небольшой список компетенций (например, уверенное владение принципами деловой переписки Ильяхова, соблюдение схемы работы агентства, умение разрешать конфликтные ситуации с клиентом и т.д.), но объективной системы их оценки не было, поэтому на них мало обращали внимания.

И это была большая печаль:

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

😫 сами исполнители чувствовали неуверенность из-за размытых правил определения сложности проектов и определенной субъективности расчетов;

😫 руководство раздражалось, потому что не отдавало себе отчета, кто что на самом деле из ребят умеет и на основе чего составлять для них план развития. Не складывалась картинка в голове по поводу умений отдела и баланса сил;

😫 ребята тратили время впустую, развиваясь хаотично и часто прокачивая не важные для развития агентства навыки;

😫 компания чувствовала бессилие в ситуациях, когда на более высоком грейде оказывались ребята с проблемами в базовых профессиональных навыках вроде соблюдения дэдлайнов или когда специалисты начинали терять свои навыки;

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

Что мы сделали

Шаг 1. Генеральная уборка, она же подготовка

Грейды — это часть общей системы бизнеса, долька в апельсине. И перед тем, как приступить к их разработке, важно позаботиться о том, чтобы эта общая система была в максимально актуальном состоянии. А именно, чтобы, как минимум, оргструктура, распределение функций внутри команды, требования к продукту и основные схемы работы находились в актуальном состоянии.

Если пропустить шаг с генеральной уборкой, грейды могут просто не встроиться в реальность компании, стать инородным объектом и довольно быстро засохнуть.

Поэтому на первом шаге мы обновили основные составляющие системы бизнеса и уверено пошагали дальше по этому фундаменту.

Шаг 2. Где мы сейчас и где будем

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

Все наши хотелки зафиксировали как идеальное будущее.

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

Шаг 3. Выбор основного принципа оценки

На этом шаге проанализировали, с какой стороны можно подобраться к определению грейда и поняли, что самым разумным решением будет использовать классический для HR-индустрии принцип: чем сильнее твои новыки (hard и soft), тем выше твой грейд и зарплата.

В таком подходе больше логики хотя бы потому что он соответствует экономическому принципу оценки любого актива компании (будь это специалист, станок или здание): чем больше дохода сможет принести актив в будущем, тем он дороже стоит. Мы не можем сказать наверняка, что дизайнер/РП, который выполнил множество крупных проектов в прошлом, однозначно будет рентабельнее менее опытного специалиста, который выполнил меньше проектов, но больше вкладывался в обучение. Сравнение будет более справедливым, если мы оценим их умения на сегодняшний день и сравним уровень их профессиональных активов, которые будут генерировать прибыль.

Для определения ценности профессионала для компании важен не сам его опыт, а те умения, которые из него формируются (или не формируются).

Шаг 4. Навыки (они же skills)

После генуборки мы точно понимали, какие работы будет выполнять каждый отдел для клиентов и самой компании, как будет выглядеть ее идеальный продукт, по какой схеме он будет создаваться и чем простой продукт будет отличаться от сложного. Из этого родились необходимые навыки ребят: что именно они должны уметь делать. Разбили их на 2 группы:

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

Например, для руководителей проектов в hard попали умения, необходимые для выполнения своей роли в процессе пресейла, управления командой проекта и бюджетом проекта. В soft — навыки деловой коммуникации, выстраивания партнерских отношений и стремление к оптимизации. Всего у РП получилось 25 hard и 14 soft навыков, у дизайнеров 17 и 11 соответственно. Да, довольно много. Но это было самое вкусное, что осталось после строгого отбора.

Для дизайнеров дополнительно к hard и soft навыкам мы добавили 17 технических (TECH), связанных с умением пользоваться конкретными программами и технологиями. Например, владением Figma, программами по анимации и языками программирования.

Если у вас получится слишком много навыков, отбрасывайте те, которые менее всего важны для текущих целей и стратегии компании.

Шаг 5. Индикаторы

Чтобы навыки можно было объективно оценить, мы добавили индикаторы или признаки, которые говорят о том, что навык действительно работает. Например, для компетенции РП “контроль качества программинга” выбрали такие индикаторы:

  • свободно владеет основной терминологией программинга;
  • ориентируется в базовых принципах/технологиях программинга;
  • умеет проверить ТЗ, составленное дизайнером;
  • умеет проверить, что программинг соответствует требованиям проекта.

Шаг 6. Регламенты

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

Шаг 7. Легенда для оценки навыков

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

Вот так выглядит легенда. Оценщик, ориентируясь на описание, выбирает уровень специалиста в конкретном навыке и проставляет соответствующий балл.
Вот так выглядит легенда. Оценщик, ориентируясь на описание, выбирает уровень специалиста в конкретном навыке и проставляет соответствующий балл.

Шаг 8. Диапазоны грейдов и зарплаты

Просчитали, в какой диапазон по баллам необходимо попасть специалисту, чтобы он оказался на конкретном грейде (Junior, Middle, Senior) и на конкретном уровне внутри грейда (у нас их было 4). Для каждого уровня в грейде определили уровень зарплат на основе анализа зарплат на рынке. В результате получилась вот такая табличка.

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

Шаг 9. Пороги входа

Чтобы не возникало перекоса в компетенциях специалистов (когда, например, дизайнер набирает максимум по soft, но в hard у него все не очень хорошо), определили пороги входа в грейд — проставили минимальные баллы по определенным навыкам, без достижения которых невозможно подняться по грейду. Например, дизайнер никак не мог перейти в Senior, не будучи профи в разработке визуальной концепции проекта или управлении своими задачами.

Шаг 10. Процедура оценки

Чтобы оценка была максимально объективной, внедрили метод «360 градусов», при котором в процедуре участвовали специалисты из разных отделов. Например, руководителя проекта оценивал не только его руководитель, но и аккаунт-менеджер, дизайнер и редактор, с которыми специалист часто встречался на проектах. Участники оценивали те компетенции, проявление которых они могли наблюдать на практике и поэтому могли оценить.

TECH скиллы дизайнеров могли оценить только другие дизайнеры или руководитель отдела дизайна, поэтому эта часть оценки их компетенций проходила внутри отдела.

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

Шаг 11. Упрощение процедур

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

  • Баллы достаточно было скопировать из оценочных листов команды в сводный файл, в который зашили логику определения грейда и прохождения порогов.
Это кусочек сводного файла, куда собирались оценки ребят из отдела дизайна. Здесь же по умолчанию проставлены пороги.
Это кусочек сводного файла, куда собирались оценки ребят из отдела дизайна. Здесь же по умолчанию проставлены пороги.
После добавления результатов оценки файл рассчитывает итоговый балл, определяет грейд, проверяет прохождение порогов и говорит, сколько баллов специалист не добрал по порогам.
После добавления результатов оценки файл рассчитывает итоговый балл, определяет грейд, проверяет прохождение порогов и говорит, сколько баллов специалист не добрал по порогам.
  • Файл также показывает картину по уровню навыков в отделе.
По диаграмме видно, как распределяются силы отдела дизайна по группам hard-скиллов. "И. д/организации работы" — умение пользоваться инструментами для организации работы вроде Asana и Notion. Дизайн-инструменты, напомню, у нас были в TECH-навыках.
По диаграмме видно, как распределяются силы отдела дизайна по группам hard-скиллов. "И. д/организации работы" — умение пользоваться инструментами для организации работы вроде Asana и Notion. Дизайн-инструменты, напомню, у нас были в TECH-навыках.
  • Зашили в шаблонный проект Asana весь процесс с задачами для всех участников — начиная от определения команды оценки до сообщения в финансовый отдел радостной новости об увеличении зарплат ребят. А еще настроили руководителям напоминания о запуске процедуры по шаблону.

Как новые грейды изменили ощущения команды

😊 Появилось чувство справедливости и объективности в определении грейда и соответственно уровня зарплаты.

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

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

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

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

😊 Появилось приятное предвосхищение перед составлением плана развития, ведь эта процедура стала прозрачной и быстрой: текущий уровень навыков на руках, остается выбрать, куда хочется прийти и занести разницу в план развития.

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

😊 У команды появилось больше уверенности в предоставлении обратной связи друг другу. Отделы теперь знали, какими навыками кто должен обладать и могли более объективно комментировать работу друг друга. А также почувствовали больше контроля над общей ситуацией, ведь у них появилась еще одна возможность выразить свое мнение о работе других отделов и повлиять на их работу.

Разработка системы грейдов — это довольно непростая задача, с которой крайне тяжело будет справиться одному специалисту (будь он HR, руководитель отдела или директор компании). Если вы хотите, чтобы система получилась подходящей именно вашей команде и легко менялась вместе с развитием компании, рекомендую собрать команду.

С учетом текущей загрузки руководства агентства новую системы мы разрабатывали еще 6 месяцев после окончания генеральной уборки и назвали ее скилл-чек. Периодичность проведения сохранили прежнюю — раз в полгода.

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

77
Начать дискуссию