किसी कौशल को कैसे साबित करें? योग्यता प्रमाण का 6-स्तरीय मॉडल

Skills First दृष्टिकोण औपचारिक लेबल से ध्यान हटाकर उन क्षमताओं पर लाता है जिन्हें व्यक्ति वास्तव में दिखा सकता है। लेकिन इससे उन्हें मापने की समस्या अपने आप हल नहीं होती।

OECD skills-first को ऐसी पद्धति के रूप में वर्णित करता है जिसमें hiring और talent management प्रक्रियाओं को इस तरह बदला जाता है कि लोगों का मूल्यांकन demonstrated skills के आधार पर हो। रिपोर्ट उपयुक्त assessment tools और skill frameworks की आवश्यकता भी बताती है। [1]

इसलिए केवल "Education" की जगह लंबी "Skills" सूची लिख देना पर्याप्त नहीं है। हमें यह भी बेहतर तरीके से दिखाना होगा कि किसी कौशल के दावे पर भरोसा क्यों किया जाए।

दो लोग बिल्कुल एक ही कौशल लिख सकते हैं, जबकि उनका वास्तविक अनुभव पूरी तरह अलग हो सकता है।

मान लें दो विशेषज्ञ लिखते हैं:

Angular - advanced

पहले व्यक्ति ने एक course किया, कुछ personal projects बनाए और framework की basics जानता है।

दूसरे ने तीन साल production application पर काम किया, system के एक हिस्से की architecture संभाली, Angular versions के बीच migrations कीं और अपने काम के ठोस परिणाम दिखा सकता है।

साधारण skills list में दोनों लगभग समान दिख सकते हैं।

सिर्फ context में रखे गए प्रमाण वास्तविक अंतर दिखाना शुरू करते हैं।

यह मॉडल लोगों को एक universal score देने के लिए नहीं है। अलग-अलग पेशों में अलग प्रकार के प्रमाण होते हैं और हर project को public नहीं किया जा सकता।

इसका उद्देश्य एक सरल प्रश्न का उत्तर देना है:

किसी योग्यता को विश्वसनीय रूप से प्रस्तुत करने के पीछे मौजूद सामग्री कितनी मजबूत है?

सबसे सरल स्तर व्यक्ति का अपना दावा है।

उदाहरण:

• Angular
• Figma
• SEO
• team leadership
• B2B negotiation

यह जानकारी search और discovery के लिए उपयोगी है, लेकिन इसकी प्रमाणिक ताकत सीमित है।

हम अभी नहीं जानते:

• कौशल कहाँ इस्तेमाल हुआ,
• कितने समय तक,
• किस scale पर,
• कितनी responsibility के साथ,
• किस result के साथ।

दावा शुरुआत है, मूल्यांकन का अंत नहीं।

प्रमाण तब मजबूत होता है जब हम जानते हैं कि कौशल कहाँ और किस संदर्भ में इस्तेमाल हुआ।

सिर्फ:

Angular

की जगह:

Logistics sector की SaaS application के development में Angular का 2 साल उपयोग।

यह अभी काम की गुणवत्ता साबित नहीं करता, लेकिन महत्वपूर्ण context देता है:

• वास्तविक project,
• उपयोग की अवधि,
• application area,
• environment की प्रकृति।

इस स्तर पर कौशल सिर्फ label नहीं रह जाता।

अगला स्तर तब आता है जब दावा और अनुभव वास्तविक work artifact से जोड़े जा सकें।

पेशा देखकर यह हो सकता है:

• working application,
• code sample,
• repository,
• interface design,
• prototype,
• report,
• analysis,
• campaign,
• article,
• documentation,
• financial model,
• photograph,
• engineering design,
• completed work की recording।

यह artifact महत्वपूर्ण सवाल का जवाब देता है:

क्या हम कुछ ऐसा देख सकते हैं जो वास्तव में इस कौशल से बनाया गया हो?

इसका मतलब यह नहीं कि portfolio formal competency test है। फिर भी personnel-selection research बताती है कि वास्तविक job tasks से जुड़ी methods, जैसे work samples और job-knowledge tests, performance के उपयोगी predictors हो सकते हैं। साथ ही results को context, cost और method की limitations के साथ समझना चाहिए। [2]

Artifact के बाद भी एक कठिन सवाल बच सकता है:

इस व्यक्ति ने वास्तव में क्या किया?

Team projects में यह विशेष रूप से महत्वपूर्ण है।

एक application 20 लोगों ने बनाई हो सकती है। Campaign में 8 लोगों की team हो सकती है। Rebranding में agency, internal marketing और external consultants शामिल हो सकते हैं।

इसलिए मजबूत प्रमाण है case study जिसमें व्यक्तिगत contribution स्पष्ट हो।

अच्छे case study में कम से कम अलग होना चाहिए:

• problem या goal,
• पूरे project का scope,
• specialist की personal responsibility,
• वास्तव में किए गए actions,
• इस्तेमाल किए गए skills,
• दूसरों के साथ collaboration,
• result।

सिर्फ:

मैंने e-commerce platform बनाया।

की जगह बेहतर है:

मैं frontend architecture, checkout implementation और payment flow integration के लिए जिम्मेदार था। Project पाँच लोगों की team ने deliver किया।

दूसरा विवरण पूरे team के काम को एक व्यक्ति के नाम नहीं करता।

प्रमाण तब और मजबूत होता है जब काम से ठोस परिणाम निकले जिसे अस्पष्ट भाषा के बिना बताया जा सके।

उदाहरण:

Frontend
Main view loading time 4.2 s से 1.8 s किया।

UX
Registration flow redesign के बाद form abandonment घटा।

Marketing
Comparable traffic quality रखते हुए cost per lead घटाया।

Sales
नया customer segment खोला और निश्चित संख्या में contracts बंद किए।

Operations
कई दिनों की process को कुछ घंटों में बदला।

हर पेशे का परिणाम percentage या money में नहीं बताया जा सकता और न ही बताया जाना चाहिए। Profile बेहतर दिखाने के लिए metrics गढ़ना गलत है।

सही सवाल है:

इस काम से क्या बदला?

सबसे मजबूत स्तर तब आता है जब कम से कम कुछ जानकारी profile owner के अपने दावे से स्वतंत्र रूप से verify की जा सके।

उदाहरण:

• public project,
• contribution history वाला repository,
• public publication,
• project participation की पुष्टि,
• client या colleague reference जिसे कानूनी रूप से publish किया जा सके,
• independently confirm किया जा सकने वाला result,
• relevant official credential,
• कोई अन्य source जो specific work की पुष्टि करे।

हर project public होना जरूरी नहीं है।

कई महत्वपूर्ण projects NDA, trade-secret या अन्य confidentiality obligations के अंतर्गत होते हैं।

इसलिए public evidence का न होना competence का न होना नहीं है।

इसका अर्थ केवल independent verifiability कम होना है।

स्तर 1 - दावा
Angular।

स्तर 2 - context
SaaS applications में Angular का 3 साल उपयोग।

स्तर 3 - artifact
Public application, repository या कोई अन्य work sample जिसे दिखाया जा सके।

स्तर 4 - व्यक्तिगत योगदान
Selected modules की architecture, shared components और application migration की जिम्मेदारी।

स्तर 5 - result
Optimization ने main module startup time 4.2 s से 1.8 s कर दिया। Values illustrative हैं।

स्तर 6 - verification
Result और contribution को public project, change history, reference या independent source से confirm किया जा सकता है।

एक ही level पर दो evidence pieces की value बहुत अलग हो सकती है। पाँच अतिरिक्त dimensions उन्हें समझने में मदद करती हैं।

1. Relevance - क्या evidence वास्तव में उसी competency से जुड़ा है?

2. Recency - skill कब इस्तेमाल हुई और इस field में recent experience कितना महत्वपूर्ण है?

3. Authorship और responsibility - क्या हमें पता है व्यक्ति ने वास्तव में क्या किया?

4. Context - scale, complexity, responsibility, resources और working conditions क्या थे?

5. Verifiability - क्या information के कुछ हिस्से को independently confirm किया जा सकता है?

Relevance

जिस project में technology का बहुत सीमित उपयोग हुआ, वह उस project से कमजोर evidence है जहाँ वही skill central थी।

Recency

इसका महत्व field पर निर्भर करता है। कुछ क्षेत्रों में दस साल पुराना experience अभी भी valuable है, जबकि कुछ में tools और practices तेजी से बदलते हैं।

Authorship और responsibility

Project और team जितने बड़े हों, overall result को individual contribution से अलग करना उतना महत्वपूर्ण होता है।

Context

एक ही result का महत्व scale, deadlines, resources, responsibility और complexity के अनुसार बदल सकता है।

Verifiability

Independent verification हमेशा संभव नहीं है और हमेशा mandatory भी नहीं होना चाहिए। लेकिन independent source result या contribution confirm करे तो credibility बढ़ती है।

कोई व्यक्ति project में अपना हिस्सा बहुत अच्छी तरह कर सकता है, भले project business स्तर पर fail हो जाए।

वह किसी बहुत successful project में भी हो सकता है लेकिन final success पर उसका प्रभाव सीमित हो।

इसलिए तीन चीज़ें अलग करें:

1. Competency
क्या व्यक्ति यह काम कर सकता है?

2. Contribution
वास्तव में किस हिस्से के लिए जिम्मेदार था?

3. Outcome
उस काम से क्या बदला?

इन तीनों को मिलाकर अधिक complete picture मिलता है।

Certificate या अन्य formal credential उपयोगी evidence हो सकता है, लेकिन उसकी value इस बात पर निर्भर है कि वह वास्तव में क्या confirm करता है और कैसे मिला।

यह उदाहरण के लिए confirm कर सकता है:

• training completion,
• defined learning outcomes,
• specific assessment pass करना,
• किसी standard की knowledge,
• formal requirements पूरा करना।

European Commission micro-credentials को short learning experience से प्राप्त learning outcomes के records के रूप में वर्णित करती है और transparency तथा quality पर जोर देती है। [3]

Certificate को इस बात का automatic proof नहीं मानना चाहिए कि व्यक्ति real professional environment में complex work independently कर सकता है।

इसलिए credential evidence का एक possible element है जिसका अर्थ context पर निर्भर करता है।

Project public न दिखा पाना valuable experience को खत्म नहीं करता।

लेकिन NDA, confidentiality duties, trade secrets, copyright और data-protection rules portfolio दिखाने की इच्छा से पहले आते हैं।

Specialist को project केवल उतना ही describe करना चाहिए जितना contracts, applicable law और अन्य लोगों व organizations के rights allow करते हैं। केवल client name हटाना हमेशा पर्याप्त नहीं है यदि बाकी details project, client, technology, results या confidential methods की पहचान करा सकती हैं।

जहाँ disclosure allowed हो, वहाँ संभव है:

• industry को sufficiently general रूप में बताना,
• confidential information के बिना problem बताना,
• अपनी role और responsibilities बताना,
• used skills बताना,
• केवल permitted सीमा तक scale बताना,
• protected data के बिना result type बताना,
• approach को general form में बताना।

यदि doubt हो कि information publish की जा सकती है या नहीं, contract check या rights holder की permission मिलने तक उसे disclose न करना सुरक्षित है।

Competency-evidence system को ऐसे design नहीं करना चाहिए जैसे हर profession software development हो।

Designer process, design decisions, prototype और result दिखा सकता है।

Developer product, code, architecture या technical responsibility दिखा सकता है।

Marketer campaign, approach, responsibility और result changes दिखा सकता है।

Sales professional confidential client data के बिना market segment, sales process, अपनी role और result बता सकता है।

Project Manager project scope, work organization, constraints और delivery impact दिखा सकता है।

Photographer artificial KPI बनाए बिना completed work दिखा सकता है।

Principles common रह सकते हैं, evidence type flexible होना चाहिए।

1. देखें skill वास्तव में कहाँ इस्तेमाल हुई।

2. Work artifact या concrete delivery example खोजें।

3. Specialist contribution को पूरे team के काम से अलग करें।

4. Result को देखें, यदि उसे meaningful तरीके से describe किया जा सके।

5. Experience की recency और आपके problem से similarity देखें।

6. जहाँ संभव और उचित हो independent confirmation खोजें।

इससे evaluation profile keywords से हटकर demonstrated competencies और concrete need के वास्तविक fit पर जाता है।

Model information organize करने और human judgment support करने के लिए है। इसे hiring, rejection या professional collaboration शुरू करने का automatic verdict नहीं मानना चाहिए।

हर competency के लिए level 6 evidence जरूरी नहीं है।

अपनी प्रमुख skills पर ये सवाल पूछना अधिक उपयोगी है:

• मैंने इसे कहाँ इस्तेमाल किया?
• कौन-सी problem solve कर रहा था?
• मैंने वास्तव में क्या किया?
• क्या मेरे पास work artifact है?
• result क्या था?
• क्या confidentiality तोड़े बिना describe कर सकता हूँ?
• क्या कोई person या source मेरे contribution की पुष्टि कर सकता है?

सिर्फ:

Figma - advanced

से:

मैंने B2B application का onboarding flow design किया और research, prototyping, usability testing तथा final design system के लिए जिम्मेदार था

तक जाना भी profile information की quality बढ़ा देता है।

Skills First तभी अर्थपूर्ण है जब "skill" सिर्फ एक tag से अधिक हो।

यदि competencies specialists खोजने और compare करने का मुख्य तरीका बनें, तो उन्हें best available context से जोड़ना चाहिए:

experience -> portfolio -> individual contribution -> outcome -> verifiability.

हर competency highest level तक नहीं पहुँचेगी और पहुँचना जरूरी भी नहीं है।

उद्देश्य profile के हर item के आसपास bureaucracy बनाना नहीं है।

उद्देश्य specialists को यह दिखाने देना है कि उनके skill claim पर भरोसा क्यों किया जाए, और expertise खोजने वालों को बेहतर informed decision लेने में मदद करना है।

1. Declaration की जगह specifics - दिखाएँ competency कहाँ और कैसे use हुई।

2. पूरे team की success की जगह individual contribution - अपना काम overall result से अलग करें।

3. Duties list की जगह outcome - जहाँ संभव हो दिखाएँ काम से क्या बदला।

4. अकेले number की जगह context - conditions के बिना metric गलत conclusion दे सकता है।

5. जहाँ संभव हो verification - independent confirmation credibility बढ़ाता है, लेकिन उसका न होना competency को invalid नहीं करता।

Professional profile को reader से यह guess नहीं करवाना चाहिए कि skills list के पीछे वास्तव में क्या है।

Declaration competency को discover होने देती है. Evidence उसे समझने देता है.

छह स्तरों को सरल क्रम में देखें:

1. मैं कहता हूँ कि मैं कर सकता हूँ।
2. दिखाता हूँ कहाँ इस्तेमाल किया।
3. दिखाता हूँ क्या बनाया।
4. समझाता हूँ मैंने वास्तव में क्या किया।
5. result दिखाता हूँ।
6. जहाँ संभव हो independent confirmation देता हूँ।

जितने अधिक सवालों का उत्तर मिले, उतना कम हमें सिर्फ claim पर निर्भर रहना पड़ता है।

यही वह जगह है जहाँ Skills First profile की information order बदलने से अधिक अर्थ रखने लगता है।

[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
स्रोत खोलें

Methodological note: स्रोत [1]-[3] Skills First, competency assessment और credentials का broader context देते हैं। योग्यता प्रमाण का 6-स्तरीय मॉडल इस सामग्री में वर्णित एक मूल conceptual model है और इन publications का परिणाम बताकर प्रस्तुत नहीं किया गया है।