Як довести навичку? Модель 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 рівнів доказів компетентності є авторською концептуальною моделлю цього матеріалу й не подається як результат цих публікацій.