Меня зовут Филиппова Ольга, я ведущий разработчик и тимлид в компании Programming Store. В сфере 1С я уже 14 лет, а последние 5 лет активно участвую в работе корпоративного университета нашей компании. Вместе с коллегами мы выстраиваем системный подход к развитию и обучению разработчиков и всех сотрудников.
В этой статье я хочу рассказать о том, как у нас работала система наставничества: кто были наши наставники, как они помогали новичкам, и почему со временем этот подход перестал справляться с ростом компании. Вы узнаете, как мы пересмотрели подход к обучению, отказались от традиционного наставничества и построили новую, более масштабируемую систему развития. А также, где сейчас наши наставники, какие неожиданные сложности мы встретили по пути – и на какие «грабли» все-таки наступили, несмотря на все расчеты.
История наставничества: начало и успехи
Начнем с наставников. У нас действительно была полноценная система наставничества – и она отлично работала. В тот период в компании было около 30 человек.
Наставником обычно становился компетентный, инициативный сотрудник с длительным стажем в компании. Главное – он не только разбирался в процессах, культуре и ценностях Programming Store, но и, что особенно важно, был готов делиться своим опытом.
Наставники играли ключевую роль:
– помогали новичкам адаптироваться в команде и на проектах,
– решали вместе сложные рабочие задачи,
– передавали знания и лучшие практики,
– участвовали в составлении индивидуальных планов развития,
– подбирали полезные материалы, курсы, рекомендовали литературу.
Получалось что-то вроде персонального обучения в реальных рабочих условиях. Это было эффективно, глубоко и очень человечно. Казалось, что такая система может расти вместе с компанией.
Но на самом деле это было не так? Далее я расскажу, что изменилось – и почему мы приняли непростое решение отказаться от привычного наставничества.
Кризис наставничества: рост компании и перегрузка
В какой-то момент мы пережили значительный рост численности компании. К 2021 году нас стало больше ста человек. И мы столкнулись с тем, что количество новых сотрудников, нуждающихся в поддержке наставника, резко превысило число самих наставников. На одного наставника приходилось по два, три и даже больше подопечных. Все это привело к сильной перегрузке у тех, кто выполнял наставнические функции.
Наставниками у нас традиционно становились сотрудники, для которых обучение и сопровождение новичков не являлось основной обязанностью. Их основная задача – выполнение рабочих обязанностей на проектах, куда они привлечены. Наша компания – ресурсный центр разработки, и все сотрудники работают в командах заказчиков. При этом они задействованы на проектах в полном объеме – 8 часов в день. То есть весь рабочий день они должны быть полностью погружены в проектную деятельность.
Однако по мере роста числа подопечных нагрузка на наставников увеличивалась. В итоге большинство из них вынуждены были выполнять наставнические задачи за пределами рабочего времени. При этом уровень знаний у новых разработчиков был разным, и наставникам приходилось постоянно включаться в решение самых разных вопросов – часто спонтанно и в хаотичном порядке. Эти вопросы могли быть любыми: от устранения пробелов в базовых знаниях до помощи в построении индивидуального плана развития. Наставники сами подбирали материалы, помогали наращивать компетенции, но делали это без четкой структуры и поддержки со стороны компании.
Еще одной проблемой было отсутствие четких критериев подбора пар «наставник – подопечный». В результате формировались пары, в которых у участников не складывалась коммуникация – в некоторых случаях она вообще отсутствовала. Кроме того, не все, кто выступал в роли наставника, обладали опытом преподавания или передачи знаний. Умение хорошо кодить не всегда означает умение эффективно обучать.
Главной же проблемой стало то, что количество новых наставников не успевало за стремительным ростом команды. Существующие наставники были перегружены и одновременно вынуждены справляться с проектными задачами. В итоге оценить эффективность наставничества стало практически невозможно. И это, скорее всего, происходило потому, что изначально у нас не было четко определенных целей, задач и системы оценки для наставников.
Со временем мы перешли к ситуативному наставничеству: подопечный обращается к наставнику только тогда, когда возникает конкретная потребность. Наставник подключается точечно, решает вопрос – и на этом взаимодействие заканчивается. В некоторых случаях мы даже скатились к формальному наставничеству: пара назначена, но между ними нет никакого общения.
Если с точечной помощью дела обстояли еще более-менее нормально, то системное обучение и развитие сотрудников оставались практически неохваченными.
Необходимость системного подхода к обучению
Нам был остро необходим системный подход. В нашей компании система обучения – одна из ключевых и критически важных систем. Мы поняли, что ее нужно построить осознанно и структурированно. Есть несколько причин, почему это было так важно.
Во-первых, технологии стремительно развиваются, появляются новые знания и инструменты. Чтобы оставаться на передовой, нам нужно постоянно обновлять и расширять знания. Наши разработчики должны обладать не только широким, но и глубоким уровнем компетенций. Постоянное наращивание квалификации – это залог того, что мы будем предоставлять заказчикам действительно качественные и современные решения.
Во-вторых, компания, которая инвестирует в обучение своих сотрудников, становится привлекательной для специалистов. Мы хотели быть такой компанией – привлекательной, в первую очередь для наших текущих и будущих сотрудников. Кроме того, у нас есть стратегические цели. Одна из них – к 2025 году заложить основы корпоративного университета и разработать полноценные программы обучения для разработчиков.
И, наконец, общие знания сближают. Мы хотели стать более сплоченной, дружной и сильной командой. Нам была нужна единая, прозрачная и ориентированная на развитие система – такой инструмент, в котором каждый разработчик мог бы ясно понимать, где он находится сейчас, какие у него есть возможности и в каком направлении ему развиваться.
Мы поставили перед собой задачу запустить процесс непрерывного образования и постоянного роста уровня знаний. Ниже я расскажу, что у нас получилось.
Составляющие новой системы обучения
Сейчас наша система обучения состоит из четырех ключевых элементов: матрица компетенций, система оценки уровня знаний, обучающие треки и механизм закрепления знаний. Расскажу подробнее о каждом.
Начнем с матрицы компетенций. Это был самый первый и, пожалуй, самый длительный этап нашей работы. Мы создали матрицу, чтобы ответить на три главных вопроса: что именно нужно развивать (ведь компетенций много), до какого уровня и каков текущий уровень знаний у наших разработчиков.
Чтобы получить ответы, мы сформировали собственный перечень компетенций. Каждый навык в рамках компетенций мы распределили по уровням. На каждом уровне четко прописано, что разработчик должен знать и уметь. Всего у нас получилось четыре уровня – при этом мы не принимаем на работу специалистов с опытом менее трех лет в 1С.
В итоге у нас появилась матрица, охватывающая как hard skills, так и soft skills. В нее вошли компетенции, которые отвечают внутренним запросам наших сотрудников, пересекаются с потребностями клиентов, соответствуют ценностям компании, влияют на эффективность работы и которые, по нашему мнению, важно и даже необходимо развивать.
Все компетенции мы разделили на две группы:
– Hard skills – например, знание платформы, инструменты разработки, интеграции, участие в проектах в роли архитектора или техлида, вовлеченность во внутренние инициативы (например, код-ревью).
– Soft skills – коммуникативные навыки, управление собственным развитием, продуктивность, эффективность работы.
Мы также выделили ключевые компетенции, обязательные к оценке, и дополнительные, которые можно оценивать по запросу сотрудника или руководителя.
В итоге у нас появилась полноценная матрица компетенций – понятная, прозрачная и единая для всех разработчиков. При ее разработке мы руководствовались важными принципами: система должна быть безопасной, не создавать стресс, поддерживать ценности компании и, самое главное, мотивировать на развитие. И, как нам кажется, нам это удалось.
Система оценки уровня знаний
Следующий компонент нашей системы обучения – это система измерения уровня знаний. Перед тем как назначать обучение, крайне важно понимать, какими знаниями и навыками уже обладает разработчик. Этот этап принципиально важен, чтобы избежать обучения впустую.
Например, когда человек вынужден проходить материал, который он уже знает, – это неэффективно и скучно. А с другой стороны, если предложить ему сложный контент без базовой подготовки, он просто не поймет, о чем речь. Такое обучение тоже не принесет результата.
Поэтому мы используем систему оценки уровня знаний, чтобы подобрать максимально подходящий обучающий трек для каждого сотрудника. При разработке этой системы мы руководствовались тем, что она должна:
– точно соответствовать матрице компетенций и позиционировать сотрудника по уровням;
– оценивать не просто наличие навыка, а глубину его владения;
– позволять оценивать как отдельные навыки, так и группы компетенций, чтобы распределять оценку поэтапно;
– и, что особенно важно, вызывать доверие у сотрудников.
Именно поэтому в разработке системы активное участие принимали эксперты. Все методы оценки прошли отладку на фокус-группах. По каждой группе компетенций мы собирали отдельную группу сотрудников с разным уровнем подготовки – при этом уровень их знаний изначально был нам известен.
Мы тестировали разные методики и смотрели, насколько точно они позволяют определить реальный уровень. Цель была одна – чтобы результат оценки совпадал с изначально известным уровнем. О самих методах расскажу чуть позже. А пока – кто такие эксперты.
Эксперты – это специалисты с максимальной глубиной знаний и большим практическим опытом в конкретной компетенции. Они участвовали на всех этапах: в разработке матрицы компетенций, создании системы оценки и наполнении обучающих треков.
Для оценки hard skills мы используем три метода:
– самооценку,
– тестирование,
– интервью с экспертом.
Для soft skills применяется метод 360 градусов, в который также включена самооценка. Но подробно останавливаться на оценке soft skills не буду – сфокусируюсь на hard skills.
Начнем с самооценки. Здесь все просто: разработчик самостоятельно определяет свой уровень, ориентируясь на описание уровней в матрице компетенций. Он анализирует свои знания и умения и определяет уровень знаний.
Однако этот метод – не истина в последней инстанции. Его необходимо подтверждать. И основным способом подтверждения у нас стало тестирование – ключевой метод в системе оценки. Вопросы в тестах выстроены по принципу «от простого к сложному» и соответствуют таксономии Блума:
– Знание – способность воспроизводить факты;
– Понимание – способность объяснять их своими словами, приводить примеры, распознавать в разных контекстах;
– Применение – способность использовать знания для решения практических задач.
На каждый уровень по одной компетенции приходится от 3 до 5 вопросов. У нас четыре уровня, значит, на одну компетенцию – от 12 до 20 вопросов.
Тесты включают как задания с выбором ответа, так и вопросы с открытым ответом, который нужно формулировать самостоятельно.
При разработке вопросов мы придерживаемся строгих правил:
– формулировки должны быть простыми и однозначными;
– запрещены оценочные конструкции вроде «Как вы считаете?» или «На ваш взгляд»;
– вопрос не должен намекать на правильный ответ;
– он должен заставлять задуматься, а не угадывать.
Открытые ответы проверяются экспертами. Эксперты участвуют не только в создании тестов, но и в их проверке. В среднем разработчику требуется от 20 до 60 минут на прохождение теста. У эксперта на проверку ответов одного сотрудника уходит около 20 минут.
Третий метод – интервью с экспертом. Мы используем его не для всех, а только в спорных случаях.
Например, когда результаты самооценки и тестирования сильно расходятся: сотрудник оценивает себя на третьем уровне, а тест показывает первый. Согласитесь, ситуация неоднозначная. Чтобы не гадать – назначать ли обучение на первом или третьем уровне, – мы проводим интервью, чтобы получить более точную картину.
Это примерно 30-минутная беседа, в ходе которой эксперт задает те же вопросы, что и в тесте, но уже в диалоговом формате. Это позволяет глубже понять, насколько сотрудник действительно разбирается в теме:
– выявить примеры из практики,
– задать уточняющие вопросы,
– оценить глубину понимания,
– увидеть, как человек мыслит.
Кроме того, личная беседа создает доверительную атмосферу – сотрудник чувствует себя свободнее и может раскрыться, показав свои реальные знания и умения. У этого метода есть очевидные преимущества, но он очень трудоемкий и требует времени. Поэтому мы применяем его выборочно – только тогда, когда другие методы дают противоречивые результаты.
По итогам всех трех этапов у нас формируется объективный, согласованный и достоверный уровень знаний по каждой компетенции.
Теперь мы четко видим:
– какие у сотрудника сильные стороны,
– где у него пробелы.
Совокупность уровней по компетенциям дает нам его грейд.
А если посмотреть на данные по всей команде, мы можем выявить системные «узкие места» – области, где компании в целом не хватает компетенций. Это позволяет использовать систему обучения не только для индивидуального развития, но и для стратегического планирования.
Треки обучения и закрепление знаний
После того как определен текущий уровень знаний разработчика, ему назначается индивидуальный обучающий трек. Трек может включать разные форматы: литературу – книги, статьи, подкасты, а также курсы, как внутренние, так и внешние.
В качестве примера я приведу реальный трек обучения из нашей LMS-системы. Это трек по освоению интеграционного решения Datareon Platform. Он начинается с базового курса и изучения документации и инструкций. Следующий этап – тест с выбором ответов (не с открытыми ответами). Пройти его можно только после подтверждения выполнения двух предыдущих шагов: прохождения базового курса и изучения документации. Далее идет расширенный курс и блок практических задач.
Как видите, в структуру трека изначально заложена система закрепления знаний.
Методы оценки при закреплении знаний
Методы оценки в системе закрепления знаний немного отличаются от тех, что используются на этапе первичного позиционирования.
Первый метод – это PST-тестирование. Принцип его построения похож на тот, что я описывала ранее: вопросы выстроены по принципу «знание – понимание – применение». Но есть важное отличие: темы вопросов строго ограничены пройденным материалом. Если на этапе позиционирования мы охватываем всю компетенцию в целом, то при закреплении знаний тестирование касается только того, что было изучено в рамках конкретного трека.
Второй метод – практическое тестирование в симуляторе. Это одна, две или три задачи, которые нужно решить в тестовом контуре. В некоторых случаях, например при работе с Doterion Platform, этот контур нужно развернуть самостоятельно.
К каждой задаче прилагается:
– условие,
– описание ожидаемого результата,
– примеры выполнения.
Проверку практических заданий, как и прежде, проводят эксперты. Они продолжают активно участвовать в системе обучения на всех этапах – от разработки контента до оценки результатов.
Наставники и эксперты: в чем разница?
Многие из наставников естественным образом перешли в роль экспертов.
Чтобы четко понимать разницу между наставником и экспертом, давайте вспомним, что характеризовало успешное наставничество. Успешные отношения строились на личной связи, взаимном уважении, готовности помочь и общих ценностях.
Эксперт, напротив, – это специалист с глубокими знаниями в конкретной компетенции. Он должен быть готов не только делиться знаниями, но и участвовать в создании обучающих материалов, а также выступать в роли преподавателя.
Наставник традиционно строит более личные, доверительные отношения с подопечным. Эксперт же дает консультации по узкоспециализированным вопросам и при этом не обязан погружаться в личные или эмоциональные аспекты – его роль более техническая и формализованная.
Получается, если раньше у одного наставника было по три и более подопечных, то сейчас у нас – 11 экспертов на 140 сотрудников.
По нашему мнению, система стала по-настоящему масштабируемой. Мы предполагаем, что даже при росте до 250–300 человек количество экспертов останется примерно на том же уровне. Конечно, это зависит от количества компетенций, которые мы хотим охватить.
Не все наставники автоматически стали экспертами. Многие проходят дополнительное обучение, прокачивают свои технические навыки, проходят обучающие треки – так они постепенно переходят от роли наставника к роли эксперта, оставаясь при этом частью нашей системы развития.
Неожиданные сложности и ошибки при внедрении системы
Одним из самых важных этапов при разработке нашей системы обучения стала работа над матрицей компетенций. Однако здесь нас ждали неожиданные трудности – и мы, как говорится, «успешно прошлись по всем граблям».
Первая версия матрицы: грейды вместо уровней
Изначально мы построили матрицу на основе грейдов, а не уровней знаний. Это привело к тому, что наполнение велось под грейд, а не под компетенцию – подход, который оказался неэффективным. После пересмотра мы разделили эти понятия: теперь у нас есть независимые уровни знаний и грейды, которые формируются из этих уровней. Так появился гибкий «универсальный конструктор» – более гибкий и масштабируемый.
Имеет значение, кто создает матрицу
Еще одна ошибка – матрица была разработана не теми людьми. Мы не учли, что для корректного описания всех четырех уровней знаний нужны сотрудники с четвертым уровнем знаний – то есть настоящие эксперты. На момент создания первой версии у нас еще не было четкого понимания, кто такие эксперты и зачем они нужны. В итоге матрицу пришлось полностью переработать, уже с участием экспертов.
Разные подходы – разные результаты
Мы параллельно разрабатывали матрицы для hard skills и soft skills разными командами. Когда пришло время синхронизировать подходы, выяснилось, что каждая команда использовала свою логику: где-то применялись уровни знаний, где-то – грейды, а где-то вообще смешанные модели. Это привело к несогласованности. Пришлось многое исправлять. Сейчас у нас единая матрица компетенций, где hard и soft skills интегрированы и полностью синхронизированы.
Границы между уровнями: от размытости к четкости
На начальном этапе мы не смогли точно определить критерии перехода между уровнями: где заканчивается первый и начинается второй, и так далее. Четкое понимание этих границ появилось позже – при разработке системы оценки уровня знаний. Именно тогда мы осознали: матрица компетенций не должна быть статичной. Она – живой, динамически развивающийся инструмент. Компетенции могут меняться, добавляться, уточняться. Работа над ней ведется непрерывно.
Проблема честности в распределенной команде
Еще одна неожиданная сложность возникла при создании системы первичного позиционирования в матрице. Мы не учли, что тестовые вопросы могут быть легко найдены в интернете. Поскольку наша команда распределена по 60 городам, мы не можем контролировать процесс прохождения тестов физически – не посадишь же всех в один класс и не запретишь списывать.
Мы рассматривали разные решения: например, жесткое ограничение времени на ответ. Но отказались – не хотели добавлять стресс в рабочий процесс. Вместо этого мы полностью пересмотрели подход к формулированию вопросов: сделали их более ситуативными, кейсовыми, с открытыми ответами. Это значительно снизило возможность механического списывания и повысило качество оценки.
Итоги и перспективы
Подводя промежуточные итоги, могу сказать: у нас появилась единая система для всех разработчиков.
Мы систематизировали знания, собрали все материалы в одном месте, выделили ключевые компетенции и уровни подготовки. Теперь у каждого разработчика есть четкая «дорожная карта» – он может взять обучающий трек и встроить его в свой индивидуальный план развития.
Самое главное – процесс обучения стал управляемым. Мы видим прогресс, можем оценивать уровень знаний и вовлекать экспертов в развитие команды.
Работа еще не завершена. Впереди много задач, доработок и масштабирования. Но теперь у нас есть четкое понимание: как должен выглядеть системный подход к развитию специалистов. И что ключевой элемент этого подхода – вовлечение экспертов.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
