惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V2EX - 技术
V2EX - 技术
P
Privacy International News Feed
Security Latest
Security Latest
H
Hacker News: Front Page
T
Tenable Blog
The Hacker News
The Hacker News
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
S
Security @ Cisco Blogs
Project Zero
Project Zero
O
OpenAI News
AI
AI
Spread Privacy
Spread Privacy
C
CERT Recently Published Vulnerability Notes
The Last Watchdog
The Last Watchdog
G
GRAHAM CLULEY
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Scott Helme
Scott Helme
Application and Cybersecurity Blog
Application and Cybersecurity Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
C
CXSECURITY Database RSS Feed - CXSecurity.com
NISL@THU
NISL@THU
A
Arctic Wolf
T
Threat Research - Cisco Blogs
PCI Perspectives
PCI Perspectives
N
News and Events Feed by Topic
C
Cyber Attacks, Cyber Crime and Cyber Security
C
Cybersecurity and Infrastructure Security Agency CISA
Simon Willison's Weblog
Simon Willison's Weblog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Know Your Adversary
Know Your Adversary
Google Online Security Blog
Google Online Security Blog
罗磊的独立博客
L
LINUX DO - 最新话题
U
Unit 42
S
Security Affairs
有赞技术团队
有赞技术团队
WordPress大学
WordPress大学
博客园 - 【当耐特】
T
The Exploit Database - CXSecurity.com
S
Schneier on Security
月光博客
月光博客
Engineering at Meta
Engineering at Meta
腾讯CDC
F
Full Disclosure
Cyberwarzone
Cyberwarzone
S
SegmentFault 最新的问题
Recorded Future
Recorded Future
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
博客园 - 司徒正美
The Cloudflare Blog

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь
Запускаем единую оценку компетенций в ИТ для найма и перевода между ролями: наш опыт
Solntseva_Solntseva · 2026-06-02 · via Все публикации подряд на Хабре

Запускаем единую оценку компетенций в ИТ для найма и перевода между ролями: наш опыт

Простой

8 мин

9.8K

Привет, Хабр! На связи Маша Солнцева, Head of Recruitment — руководитель найма, и Катя Проханова (@ekaterina_prokhanova), Head of T&D — руководитель отдела обучения и развития персонала в МТС Web Services. 

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

Что происходило в этот момент у нас? Мы очень активно нанимали! Изначально в MWS работало порядка 2 000 сотрудников. Для понимания, сейчас нас 10 000 человек, 8 000 из которых инженеры. Первичным отбором тогда занимались руководители, затем кандидат проходил техническое интервью и оценку резюме со стороны рекрутмента, по итогам которых нередко выяснялось, что он не соответствует позиции. И проблема зачастую была не в людях, а в некорректно сформулированных требованиях. Чтобы не потерять хороших кандидатов, мы старались найти для них место в других командах. А это весь процесс по новой, и как результат — дополнительная нагрузка и срывы планов по закрытию вакансий, при том что они были грандиозные. 

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

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

Новый процесс: диагностика и калибровка

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

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

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

Вместе собрались и разработали чек-лист запуска проекта общей оценки:

Первая попытка согласования с бизнесом

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

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

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

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

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

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

Разработка формата матрицы

Формат оценки мы выбирали долго. Просмотрели множество фреймворков, ничего не подошло — и в итоге выработали свой.

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

Разработка формата оценки

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

На тот момент мы выбрали первый вариант как наиболее оперативный с точки зрения масштабирования. В рамках этого подхода тестирование прошли около трех тысяч разработчиков. По итогам получили следующую картину распределения результатов: 3,4% участников показали существенно низкий уровень, 26,6% — результаты ниже ожидаемого, около 33% — выше ожидаемого уровня, из них 5,5% значительно превзошли ожидания.

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

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

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

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

Такой подход позволил сохранить воронку и добиться прохождения оценки на уровне 77%. При этом опыт показал, что задания в любом случае требовали последующей валидации через интервью по компетенциям, так что мы отдали предпочтение именно формату интервью.

И вновь презентация бизнесу

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

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

Ключевым аргументом в пользу подхода стала демонстрация его практического применения. В ходе анализа мы выявили, что около 10% внутренних перемещений происходили вне формального процесса — например, роль сотрудника изменялась за счет добавления нескольких требований без полноценной оценки. Такие случаи мы начали системно отслеживать, выносить на обсуждение с экспертами и использовать в качестве примеров при презентации роли техмастеров (о них рассказываем ниже) и новой модели оценки. Теперь лидам не нужно было доказывать, что их кандидат лучший — достаточно просто привести его к техмастеру, чтоб тот оценил и подтвердил компетенции.

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

Поиск и привлечение экспертов — техмастеров

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

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

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

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

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

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

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

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

Результаты

  • Ускорили оценку внутренних переходов. Мы запустили систему в третьем квартале 2025 года. За это время было подано только 40 заявок на оценку внутренних переходов. У нас стояла цель уложиться в целевое значение в десять рабочих дней. Мы справились за девять.

  • Ужесточили внутренние переходы и вывели стандарт. Теперь только каждый второй сотрудник подтверждает, что готов к переходу на следующий уровень, и нам удалось не уронить эту метрику.

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

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

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

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

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

А вы пробовали выстроить единую систему оценку кандидатов? Делитесь кейсами и результатами в комментариях.