Всем привет! Меня зовут Соня Евстигнеева, я руководитель проектов в AGIMA. Расскажу почти детективную историю про нашу внутреннюю систему грейдирования и про то, какие метаморфозы с ней происходят. Сначала она просто помогала нам определять уровень знаний у новичков, а теперь мы используем ее, чтобы капитально обновить базу знаний компаний. Заодно покажу вопросы из нашего грейдового теста. Поехали!

Дисклеймер

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

Первая часть: как мы определяем грейд

Грейдирование менеджеров

Когда речь заходит о грейдировании в разработке, обычно в голову приходит стандартная схема: джуниор — миддл — сеньор. У каждого из них свой набор навыков, опыт и зарплатные ожидания. И в большинстве случаев мы как раз придерживаемся такой схемы. Но для руководителей проектов со временем ее пришлось расширить.

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

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

Глобально наша внутренняя система повторяет общепринятую:

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

• Далее менеджеру мы предлагаем сдать грейд JPM. Обычно сдача этого грейда входит в список необходимых достижений к концу стажировки или испытательного срока. Руководитель проектов к моменту сдачи должен знать, какими инструментами мы пользуемся, различать форматы работы, соблюдать правила согласования документации, работы с цехами, принципы тайм-менеджмента и т. д.

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

• Финальный этап грейдирования — прохождение тестирования для уровня SPM. На этом этапе менеджер уже хорошо понимает стандарты разработки, особенности стека и организации инфраструктуры, специфику формата SLA, знает принципы экстремального программирования, DevOps и CI/CD, методики информационной безопасности. Ему можно доверить сложные высоконагруженные проекты с непрерывной поддержкой.

Но несмотря на привычные слова типа «джуниор» и «сеньор», в ней много особенностей. Все они связаны как раз со спецификой корпоративного опыта и с теми инструментами, которые мы используем. Наша первостепенная задача при онбординге нового сотрудника — безболезненно погрузить его именно в наши процессы. В этом нам помогает грейдовое тестирование.

Грейдовое тестирование

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

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

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

Система с грейдовым тестированием работает не только для стажеров. Если менеджер хочет получить более высокий грейд и более сложные задачи — он тоже проходит тестирование. Но тут важно: 

система грейдов не привязана к зарплате

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

Что представляет собой тестирование

Всего в нашей базе более 200 вопросов для тестирования. Но на самом тесте ответить нужно на 20. Оно проходит онлайн в системе INDIGO. За его проведением наблюдает эйчар.

В тестах разные типы вопросов: с одним ответом, с несколькими ответами, с полем для свободного ввода. У каждого вопроса свой вес, они по-разному влияют на итоговый результат. Считается, что успешно пройденный тест -— это 80% баллов. Любой вопрос можно разобрать после тестирования. А если сотрудник не согласен с результатом — то и оспорить. Это важно!

Пересдавать тесты можно неоднократно. Поэтому перед стартом ментор объясняет менеджеру, что это не ЕГЭ и сильно переживать не стоит. Правда, от стажеров мы всё-таки ждем высоких баллов, хотя бы со второй попытки — от этого зависит результат стажировки.

У этой системы есть очевидные плюсы:

• помогает адаптировать стажеров;

• помогает менеджерам проанализировать свой опыт;

• мотивирует интересоваться, больше читать и погружаться в профессию;

• система не привязана к зарплате, и значит, не давит на человека;

• позволяет в игровой форме постепенно запоминать регламенты.

Но к сожалению, есть и недостатки:

• система не позволяет достоверно определить общепринятый грейд сотрудника;

• это дополнительная нагрузка на наставников и эйчаров;

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

Последний пункт особенно важен. Именно он в итоге помог нам найти кучу несостыковок в регламентах и начать их улучшать.

Вторая часть: как мы взялись за рефакторинг Wiki

В чем проблема

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

К примеру, поменялся регламент согласования документов. Теперь вместо Вани за согласование отвечает Петя, а срок согласования уменьшился с 5 до 3 рабочих дней. Мы обновили правила в Wiki, а в задании забыли. Человек прошел тест и указал нам на несоответствие. Или даже больше: после тестирования мы поняли, что и тест, и регламент не отражают действительность. Значит, менять нужно и то, и другое.

Кроме того, за тесты полностью отвечали эйчары. А они не всегда могли заметить недочеты в ответе. Банально: какая-то норма может уже не действовать, но обозначена как правильный ответ в тесте. В итоге мы путали и человека, который проходит тест, и самих себя. При этом проверить две сотни вопросов и все регламенты — это огромная задача.

Рефакторинг системы грейдирования

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

Мы составили схему рефакторинга:

Основными пунктами рефакторинга стали: 

• формирование списка ответственных и плана действий;

• проверка на актуальность и обновление статей;

• проверка на актуальность и обновление тестов.

Наш план обновления материалов предполагал три этапа. Мы зафиксировали их в нашей Wiki.

Первый этап

На этом этапе мы провели все подготовительные работы:

• выгрузили вопросы и ответы из INDIGO в Wiki, составили вопросы после общей проверки;

• составили схемы взаимодействия;

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

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

Когда нужно было обновить регламент, помощник самостоятельно вносил правки в статьи и указывал это в Wiki. Всем ответственным людям на почту автоматически приходило уведомление об изменении. При более сложных корректировках менеджер заводил задачу в таск-трекере и назначал ответственного специалиста от цеха.

Пример схемы взаимодействия при оспаривании результатов:

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

• ответственный менеджер прорабатывает эти вопросы: либо объясняет, что ошибки нет, либо берет в работу;

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

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

Второй этап

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

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

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

Третий этап

Здесь мы проверяли результаты рефакторинга грейдовой системы и подводили итоги. Так как у нас не было какого-то жесткого дедлайна, рефакторинг шел около 3 месяцев с заметными паузами перед Новым годом. Часто мы отдавали приоритет другим задачам, но имея на руках пространство и план действий, легко было не потерять изменения.

Дальнейшие планы

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

Мы надеемся, что в будущем сможем выдавать менеджерам сертификаты на соответствие грейдам от AGIMA. Указанный в них грейд не будет равен общепринятому стандарту. Но для компаний, которые работали с AGIMA, такой сертификат точно станет объективным бонусом в портфолио сотрудника. 

Если вам интересно управление проектами, следите за нашим телеграм-каналом.

Что еще почитать

• Что такое Agimaban и зачем он нам нужен

• Как PI-планирование помогло нам подружиться с заказчиком

• Как научить менеджеров прогнозировать

• Как наши аналитики сделали Wiki удобной для пользования