Почему прежней модели найма уже недостаточно
Мы подготовили эту статью вместе с Дарьей Чукановой. Хотим затронуть тему компетенций, которыми должен обладать современный аналитик. Часто возникает вопрос: где найти уже готового крутого аналитика? Мне очень понравилась реплика о том, что не надо бояться брать аналитика без опыта работы или с минимальным опытом и развивать его внутри компании. Мы у себя идем именно по такому пути и хотим рассказать, как это делаем и как видим этот процесс.
Как и многие компании, мы сталкиваемся с серьезными ограничениями на рынке труда. Есть дефицит квалифицированных специалистов и большие вопросы к их профессиональной и образовательной подготовке. При этом к нам приходят младшие специалисты – молодые люди, которые не готовы работать просто потому, что «так надо», как многие привыкли. Я их в этом очень хорошо понимаю. Всем важно понимать, куда, когда и зачем они пришли расти и развиваться.
Если сделать небольшой экскурс в историю и вспомнить проекты в сфере 1С 10-15 лет назад, то в основном бизнес стремился автоматизировать учетные процессы. Многие процессы оставались в Excel, почте или вообще не автоматизировались – люди жили на блокнотиках. Но технологии менялись, существенно увеличивались мощности оборудования, менялась и линейка программ 1С. На смену, например, УПП пришла ERP, где автоматизируется уже не только учет, но и процессы управления – более высокого уровня.
Компании начали обрастать различными сервисами, появились интеграционные задачи. Если раньше мы могли зайти на средний проект командой из трех-пяти специалистов, то сейчас такой командой проекты уже не сделать. Требуется семь-десять человек. Кроме того, наша сфера очень динамична: постоянно появляются новые технологии, поэтому командам нужно не отставать и постоянно развиваться, чтобы оставаться актуальными.
Мы хотим поделиться практическими примерами и опытом того, как выстроили систему развития специалистов с учетом дефицита кадров на рынке и цифровых изменений. Расскажем, как подошли к адаптации к новым реалиям, как развиваем сотрудников с учетом поколенческих особенностей в командах, как обучаемся друг у друга и с помощью каких метрик контролируем этот процесс.
Роль HR и тимлида
HR в нашей компании формирует правила игры: как будет расти специалист и какие инструменты мы будем использовать для его развития. Совместно с тимлидами и руководителями мы выстраиваем систему адаптации и развития сотрудников, а также учитываем поколенческие особенности.
Тимлид в нашей команде – не просто руководитель, а в большей степени старший брат, одна из задач которого – отвечать за развитие команды. В этом помогают сетка грейдов, ABC-классификация задач – инструмент, который мы придумали внутри команды, – и индивидуальные планы развития.
Эти инструменты появились в компании не сразу. Раньше мы работали без них, но анализировали реальные ситуации с сотрудниками, в том числе негативные кейсы, и постепенно пришли к той системе, о которой рассказываем.
Кейс 1. «Не похвалили»: дефицит признания и поддержки
К нам в команду присоединился молодой специалист с двумя годами опыта в продажах, что для нас тоже важно, и достаточно уверенный пользователь 1С. Через полгода сотрудник решил увольняться. На экзит-интервью он объяснил это недостатком обратной связи: она давалась редко и зачастую носила негативный характер.
Вывод был простым: дефицит признания и обратной связи очень сильно демотивирует специалистов любого уровня и возраста. Кроме того, традиционные модели несовместимы с ожиданиями молодых людей. Им важно получать обратную связь, а не выходить на рынок в поисках компании, где они будут чувствовать себя более значимыми.
После этого мы внедрили практику регулярных встреч с сотрудниками. У таких встреч есть несколько ключевых правил. Мы стараемся создавать неформальную атмосферу, чтобы убрать пресловутую модель «начальник – подчиненный». Даем конкретную и развернутую обратную связь – не просто «хорошо» или «плохо», а на конкретных примерах. И, что немаловажно, совместно планируем дальнейшие шаги: процесс не идет в одностороннем порядке, мы учитываем пожелания самого сотрудника.
Это дает прозрачность прежде всего самому человеку: он понимает, где находится сейчас и какой будет следующая точка роста. Сотрудник чувствует вовлеченность компании, видит, что его развитие внутри организации действительно важно. Таким образом мы удерживаем таланты.
Сетка грейдов
Когда мы начали проводить регулярные встречи, перед нами встал вопрос: на них недостаточно просто спросить, как у человека дела и самочувствие, нужна предметная основа. Для этого мы решили использовать сетку грейдов.
Я уверен, что сетка грейдов есть почти в каждой компании. За свою трудовую деятельность я работал в нескольких компаниях, и она была буквально везде. Но обычно сетка оставалась формальным документом и в основном использовалась для индексации заработной платы.
Мы решили разговаривать с сотрудниками именно о грейдах: об их желаниях и стремлении переходить с одного уровня на другой, о том, что для этого нужно делать и какими компетенциями обладать.
Наша сетка представляет собой матрицу всех грейдов – от младшего аналитика до функционального архитектора. В ней перечислены хард-скиллы, требования к опыту и сертификации. Ключевой момент в том, что все показатели можно оценить достаточно объективно: это либо количественное значение, либо ответ «да» или «нет» – есть такой опыт или нет
Но даже после внедрения сетки грейдов негативные ситуации не исчезли.
Кейс 2. «Не показали дорогу»: неясность критериев роста
Второй кейс мы назвали «Не показали дорогу». В команде работал молодой специалист с базовыми навыками работы в 1С, который самостоятельно освоил курс «1С:Специалист-консультант». За год сотрудник успешно адаптировался внутри компании и вырос, но получил отказ в увеличении заработной платы с очень размытой формулировкой: «Недостаточно опыта». Какого именно опыта – непонятно. Мы не дали конкретного пути: что нужно сделать, чтобы получить это увеличение.
Мы поняли, что механизм повышения остается непрозрачным, а одной сетки грейдов недостаточно. Нужна не единая шкала для всех, а личный путь каждого сотрудника. Поэтому мы разработали ABC-классификацию задач и внедрили индивидуальные планы развития.
ABC-классификация задач и ИПР
ABC-классификацию удобнее объяснить на личном примере. Когда я в 2009 году пришел в сферу 1С сразу со студенческой скамьи, у меня не было практического опыта – только набор минимальных знаний. Меня начали привлекать к проектам, но начинающему специалисту, естественно, никто не дает сложную задачу. Все начинается с простого: настроить интерфейс, роли или написать инструкцию, когда в целом все понятно.
Человек проходит один проект, второй, нарабатывает практику, и ему начинают доверять более сложные задачи, где требуется погружение в контекст и возможен выбор из нескольких решений. Затем специалист растет дальше и уже может решать сверхсложные задачи.
Мы решили классифицировать все проектные задачи по уровню сложности:
-
Класс A – простые задачи: типовые операции с четкими инструкциями, минимальный риск ошибок.
-
Класс B – задачи средней сложности: требуют анализа контекста, выбора оптимального решения из нескольких вариантов.
-
Класс C – сложные и сверхсложные задачи: нестандартные кейсы, высокая степень неопределенности.
Затем мы проработали критерии, по которым задача относится к определенному классу. Всего у нас около сорока критериев. Они опираются на понятные для сферы 1С параметры: количество данных, объекты системы, которые нужно дорабатывать, наличие математической модели и уровень ее сложности. Одно дело – сложить два числа, другое – выполнить сложное распределение.
Следующим шагом мы встроили ABC-классификацию в сетку грейдов и определили, задачи каких классов должен уметь решать специалист каждого уровня. При этом мы начали учитывать персональный путь развития. Сетка грейдов остается ориентиром, но каждый человек может прийти из точки A в точку B совершенно разными путями.
Таким индивидуальным маршрутом для сотрудника является ИПР. В нем мы прописываем хард-скиллы и софт-скиллы, которые нужно развить, а также цели и измеримые показатели, которых необходимо достичь. По сути, ИПР – это чек-лист с конкретными задачами сотрудника.
Когда начинается проект, я отдельно встречаюсь с каждым членом команды, и мы составляем ИПР. Фиксируем задачи, выполнения которых я ожидаю от сотрудника, а также то, что он сам готов попробовать. Это может быть не обязательное требование, а возможность сделать следующий шаг.
После этого мы не ждем окончания проекта, чтобы оценить результат. Уже в ходе работы проводим регулярные встречи, отслеживаем динамику, смотрим, что получается, а что нет. Самое главное – совместно анализируем, почему что-то не получилось. Мы можем порекомендовать курсы, книги или профессиональную литературу, провести внутренние менторские сессии, чтобы человек научился выполнять определенную работу.
Например, на одном из последних проектов мне было нужно, чтобы специалист начал самостоятельно планировать спринт. Раньше девушка никогда не занималась планированием своих задач. Мы несколько раз встретились и вместе спланировали спринт, после чего она начала делать это самостоятельно и двигаться по своему ИПР.
ABC-классификация и ИПР позволяют:
-
Объективно определять зону ближайшего развития сотрудника: какие задачи он уже готов брать на себя.
-
Формировать персональные программы обучения: если сотруднику не хватает навыков для задач, мы подбираем курсы, закрывающие этот пробел.
-
Постепенно повышать уровень сложности поручений, избегая перегрузок.
-
Отслеживать динамику роста: переход к регулярному решению задач категории C – маркер готовности к повышению грейда.
После внедрения этих инструментов у нас начали появляться положительные кейсы.
Кейс 3. «Сама напросилась»: проактивность + структура = рост
Один из таких кейсов мы назвали «Сама напросилась». В команду пришел молодой специалист с базовыми навыками работы в 1С, но без реального опыта внедрения на проектах. Коммуникативные навыки были достаточно слабыми, но сотрудник старался, был трудолюбивым и усидчивым.
Адаптация прошла успешно, за год работы внутри компании произошел рост, и сотрудник попросил увеличить заработную плату. Мы провели оценку по сетке грейдов, выявили зоны роста и составили индивидуальный план развития с этапами и сроками.
Этот процесс контролирует в том числе HR-специалист. Такая связка с руководителями и командами важна: им тоже нужна поддержка. Мы установили контрольные точки движения по траектории сотрудника и проводили регулярные ретроспективы по результатам проектов. Для этого есть план и график встреч, согласованный с руководителем. Позитивный итог – рост этого сотрудника на два грейда за год.
Кейс 4. «Тише едешь, дальше будешь»: постепенный рост миллениала
В команде есть очень скромный сотрудник постарше. У нее были базовые навыки работы с 1С – даже уровень продвинутого пользователя, техническое образование, которое мы очень ценим, нулевой опыт аналитика и достаточно глубокое понимание бизнес-процессов. Мы называем таких специалистов «пришедшими от заказчика», поскольку работаем в консалтинге.
Сотрудница работала, ее все устраивало: постепенный рост, доход, стабильность. Она не требовала детальной обратной связи на регулярных встречах и ценила осязаемые шаги своего развития.
В этой ситуации мне пришлось немного подтолкнуть сотрудника к следующему грейду. Увидев перспективы роста, я предложил двигаться дальше. Она приняла этот вызов, и мы составили ИПР на основе требований следующего грейда. Сейчас мы находимся в динамике, проводим регулярные встречи и движемся к намеченной цели. Думаю, скоро мы вместе к ней придем, и сотрудница получит повышение.
Итоги
После внедрения инструментов у меня как у тимлида начали формироваться постоянные проектные команды. Сейчас в компании сформированы две команды, третья доукомплектовывается. Это хорошо, потому что при переходе с одного проекта на другой постоянной командой не нужно тратить время на притирку между людьми, которая всегда возникает, когда состав собирают заново.
В целом мы повысили производительность и улучшили коммуникацию внутри команд. Когда сотрудники знают способности друг друга, мы можем эффективнее планировать спринты и распределять задачи по исполнителям.
Для HR результаты тоже положительные. Текучесть специалистов в команде сократилась приблизительно на 40 %. Сформировался хороший кадровый резерв, благодаря которому мы можем планировать ресурсы: приблизительно знаем, кто и когда вырастет, кого можно поставить на ключевую роль в проекте.
Кроме того, уже на интервью с кандидатами мы часто показываем, как выстроен процесс развития. Получается откровенный, честный и дружеский диалог. Кандидаты отмечают, что им нравится такая прозрачность. Поэтому систему развития полезно демонстрировать и на рынке, и на встречах с кандидатами – для компании это тоже преимущество.
Философию нашего подхода можно представить в виде схемы. В ее центре находятся сетка грейдов и ABC-классификация задач – два инструмента, которые влияют практически на всю нашу деятельность.
Мы заходим в проекты, потому что проекты – самое эффективное обучение. В ходе проекта или по его результатам оцениваем достижение целей, зафиксированных в ИПР, планируем улучшения и формируем новую версию индивидуального плана для каждого сотрудника. С этой новой версией ИПР человек заходит в следующий проект или на новый этап текущего проекта.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
