Как доказать навык? Модель 6 уровней подтверждения компетенций

Подход Skills First переносит внимание с формальных ярлыков на компетенции, которые человек способен реально продемонстрировать. Но это не решает автоматически вопрос их оценки.

OECD описывает skills-first как подход, при котором практики найма и управления талантами адаптируются так, чтобы оценивать людей по продемонстрированным навыкам. В отчете также говорится о необходимости подходящих инструментов оценки и моделей компетенций. [1]

Поэтому просто заменить раздел "Education" более длинным разделом "Skills" недостаточно. Нужен и более надежный способ объяснять, почему конкретной компетенции можно доверять.

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

Представим двух специалистов, которые пишут:

Angular - продвинутый уровень

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

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

В обычном списке навыков они могут выглядеть почти одинаково.

Только доказательства в контексте начинают показывать реальную разницу.

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

Задача модели проще:

насколько сильны материалы, на основании которых конкретная компетенция представлена как достоверная?

Самый простой уровень - собственное заявление пользователя.

Примеры:

• Angular
• Figma
• SEO
• управление командой
• B2B-переговоры

Эта информация полезна для поиска и discovery, но ее доказательная сила невелика.

Мы пока не знаем:

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

Заявление - это отправная точка, а не конец оценки.

Доказательство становится сильнее, когда мы знаем, где и в каком контексте использовался навык.

Вместо:

Angular

получаем:

Angular использовался 2 года при разработке SaaS-приложения для логистики.

Это еще не доказывает качество работы, но добавляет важный контекст:

• реальный проект,
• длительность использования,
• область применения,
• характер среды.

На этом уровне навык перестает быть просто ярлыком.

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

В зависимости от профессии это может быть:

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

Артефакт отвечает на важный вопрос:

можем ли мы увидеть что-то, что действительно было создано с использованием этого навыка?

Это не означает, что портфолио является формальным тестом компетенций. Однако исследования в области отбора персонала показывают, что методы, тесно связанные с реальной работой, включая work samples и тесты профессиональных знаний, могут быть полезными предикторами эффективности. Авторы также подчеркивают необходимость учитывать контекст, стоимость и ограничения каждого метода. [2]

Даже артефакт может не отвечать на один из самых сложных вопросов:

что именно сделал этот человек?

Это особенно важно в командных проектах.

Приложение могли создавать 20 человек. Кампанию могла вести команда из 8. Ребрендинг мог включать агентство, внутренний маркетинг и внешних консультантов.

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

Хорошее case study должно разделять как минимум:

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

Вместо:

Я создал e-commerce платформу.

лучше:

Я отвечал за frontend-архитектуру, реализацию checkout и интеграцию платежного процесса. Проект выполняла команда из пяти человек.

Второе описание полезнее, потому что не приписывает одному человеку работу всей команды.

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

Примеры:

Frontend
Время загрузки главного экрана сокращено с 4,2 с до 1,8 с.

UX
Снижена доля брошенных форм регистрации после переработки процесса.

Marketing
Снижена стоимость лида при сохранении сопоставимого качества трафика.

Sales
Открыт новый сегмент клиентов и заключено определенное количество контрактов.

Operations
Процесс сокращен с нескольких дней до нескольких часов.

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

Полезный вопрос:

что изменилось благодаря этой работе?

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

Это может быть:

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

Это не означает, что каждый проект должен быть публичным.

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

Отсутствие публичного доказательства не означает отсутствие компетентности.

Это означает лишь меньшую степень независимой проверяемости.

Уровень 1 - заявление
Angular.

Уровень 2 - контекст
Angular использовался 3 года в SaaS-приложениях.

Уровень 3 - артефакт
Публичное приложение, репозиторий или другой пример работы, который можно показать.

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

Уровень 5 - результат
Оптимизация сократила время запуска основного модуля с 4,2 с до 1,8 с. Значения иллюстративные.

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

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

1. Релевантность - относится ли доказательство именно к оцениваемой компетенции?

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

3. Авторство и ответственность - знаем ли мы, что именно сделал человек?

4. Контекст - каковы были масштаб, сложность, ответственность, ресурсы и условия работы?

5. Проверяемость - есть ли независимый способ подтвердить хотя бы часть информации?

Релевантность

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

Актуальность

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

Авторство и ответственность

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

Контекст

Один и тот же результат может иметь разный вес в зависимости от масштаба, сроков, ресурсов, ответственности и сложности задачи.

Проверяемость

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

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

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

Поэтому полезно разделять три вещи:

1. Компетенция
Может ли человек выполнять определенный вид работы?

2. Вклад
За какую часть он реально отвечал?

3. Результат
Что изменилось вследствие этой работы?

Только сочетание этих элементов дает более полную картину.

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

Например, оно может подтверждать:

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

Европейская комиссия описывает micro-credentials как подтверждение результатов обучения, полученных в рамках короткого образовательного опыта. Европейский подход подчеркивает, в частности, прозрачность и качество. [3]

Сертификат не следует автоматически приравнивать к доказательству способности самостоятельно выполнять сложную работу в реальной профессиональной среде.

Формальное подтверждение - это один из возможных элементов доказательства, значение которого зависит от контекста.

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

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

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

Если раскрытие разрешено, можно рассмотреть описание:

• отрасли в достаточно общей форме,
• характера проблемы без конфиденциальной информации,
• собственной роли и ответственности,
• использованных компетенций,
• масштаба только в допустимых пределах,
• типа результата без защищенных данных,
• подхода в достаточно общей форме.

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

Систему доказательств компетенций не следует проектировать так, будто любая профессия - это разработка ПО.

Дизайнер может показать процесс, дизайн-решения, прототип и результат.

Разработчик может показать продукт, код, архитектуру или техническую зону ответственности.

Маркетолог может показать кампанию, подход, ответственность и изменение результатов.

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

Project Manager может показать объем проекта, организацию работы, ограничения и влияние на delivery.

Фотограф может представить готовые работы без искусственных KPI.

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

1. Проверьте, где компетенция реально использовалась.

2. Найдите рабочий артефакт или конкретный пример реализации.

3. Отделите вклад специалиста от работы всей команды.

4. Посмотрите на результат, если его можно содержательно описать.

5. Оцените актуальность и сходство предыдущего опыта с задачей, которую нужно решить.

6. Ищите независимое подтверждение там, где это возможно и уместно.

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

Модель предназначена для структурирования информации и поддержки человеческого решения. Ее не следует использовать как автоматический вердикт о найме, отказе кандидату или начале профессионального сотрудничества.

Не для каждой компетенции нужен уровень 6.

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

• где я применял этот навык?
• какую проблему решал?
• что именно сделал?
• есть ли у меня артефакт работы?
• каков был результат?
• могу ли я описать его без нарушения конфиденциальности?
• может ли человек или источник подтвердить мой вклад?

Даже переход от:

Figma - продвинутый уровень

к:

Я спроектировал onboarding для B2B-приложения и отвечал за research, прототипирование, usability testing и финальную design system

заметно повышает качество информации для посетителя профиля.

Подход Skills First имеет смысл только тогда, когда за словом "skill" стоит не просто еще один тег.

Если компетенции должны стать одним из основных способов поиска и сравнения специалистов, их стоит связывать с лучшим доступным контекстом:

опыт -> портфолио -> личный вклад -> результат -> проверяемость.

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

Цель не в создании бюрократии вокруг каждой строки профиля.

Цель - дать специалистам возможность объяснить, почему их компетенции заслуживают доверия, а тем, кто ищет экспертизу, помочь принять более информированное решение.

1. Конкретика вместо заявления - покажите, где и как применялась компетенция.

2. Личный вклад вместо успеха всей команды - отделите свою работу от результата всей организации.

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

4. Контекст вместо одиночного числа - метрика без условий может привести к неверным выводам.

5. Проверка там, где она возможна - независимое подтверждение усиливает доверие, но его отсутствие не отменяет компетентность.

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

Заявление помогает обнаружить компетенцию. Доказательство помогает ее понять.

Шесть уровней можно свести к простому пути:

1. Я говорю, что умею.
2. Показываю, где это применял.
3. Показываю, что создал.
4. Объясняю, что именно сделал.
5. Показываю результат.
6. Даю возможность независимого подтверждения там, где это возможно.

Чем больше вопросов мы можем закрыть, тем меньше зависим только от заявления.

Именно тогда Skills First становится чем-то большим, чем просто другой порядок информации в профиле.

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
Открыть источник

[2] Sackett, Zhang, Berry, Lievens - Revisiting the design of selection systems in light of new findings regarding the validity of widely used predictors, Cambridge University Press, 2023
Открыть источник

[3] European Commission - A European approach to micro-credentials
Открыть источник

Методологическое примечание: источники [1]-[3] дают более широкий контекст по Skills First, оценке компетенций и формальным подтверждениям. Сама Модель 6 уровней подтверждения компетенций является авторской концептуальной моделью этого материала и не представляется как результат этих публикаций.