यह मैंने किया या टीम ने? पोर्टफोलियो में अपने योगदान को ईमानदारी से कैसे लिखें

अधिकांश मूल्यवान उत्पाद, अभियान, कार्यान्वयन और प्रक्रियाएँ टीम के रूप में बनती हैं।

इसलिए केवल अंतिम परिणाम दिखाना यह नहीं बताता कि किसी विशेष विशेषज्ञ ने वास्तव में कौन-सी भूमिका निभाई।

पोर्टफोलियो का मूल्यांकन करने वाले व्यक्ति के लिए अंतर बहुत बड़ा है:

"मैंने खरीद पूरी करने की प्रक्रिया के पुनःडिजाइन पर काम किया"

और

"मैंने शोध का नेतृत्व किया, खरीद पूरी करने की नई प्रक्रिया डिजाइन की, प्रोटोटाइप तैयार किया और उपयोगिता परीक्षण किए। कार्यान्वयन एक अलग क्लाइंट-साइड विकास टीम ने किया."

एक ही बात नहीं है।

दूसरा विवरण दूसरों के काम को कम किए बिना वास्तविक क्षमता का आकलन करने देता है.

यह समस्या केवल पेशेवर पोर्टफोलियो तक सीमित नहीं है।

वैज्ञानिक प्रकाशन में CRediT - Contributor Role Taxonomy एक उदाहरण है। यह मानक 14 प्रकार की भूमिकाएँ बताता है और यह स्पष्ट करने के लिए बनाया गया कि काम के अलग-अलग हिस्सों के लिए वास्तव में कौन जिम्मेदार था। CRediT एक व्यक्ति को कई भूमिकाएँ और एक भूमिका को कई व्यक्तियों से जोड़ने की अनुमति देता है। यह भी अनुशंसा करता है कि योगदानकर्ता अपने नाम से जोड़ी गई भूमिकाओं की समीक्षा और पुष्टि कर सकें। [1]

CRediT मुख्यतः शोध और वैज्ञानिक प्रकाशन के लिए है। यह पेशेवर पोर्टफोलियो का मानक नहीं है। फिर भी यह एक उपयोगी सिद्धांत दिखाता है: अस्पष्ट "मैं प्रोजेक्ट का हिस्सा था" के बजाय अपने वास्तविक योगदान की प्रकृति स्पष्ट बताना बेहतर है.

एक अच्छा टीम-प्रोजेक्ट विवरण छह जानकारियों के आसपास बनाया जा सकता है:

1. प्रोजेक्ट का संदर्भ
2. टीम की संरचना और दायरा
3. आपकी अपनी जिम्मेदारी
4. ठोस कार्य और निर्णय
5. काम के नमूने या प्रमाण
6. परिणाम और उसका श्रेय कैसे दिया जाए

लक्ष्य लंबी रिपोर्ट लिखना नहीं है। लक्ष्य सबसे महत्वपूर्ण अस्पष्टताओं को दूर करना है.

पहले बताएं कि टीम वास्तव में किस चीज पर काम कर रही थी।

संक्षेप में इतना बताना पर्याप्त है:

• समस्या या लक्ष्य,
• उत्पाद या सेवा का प्रकार,
• अनुमानित पैमाना,
• महत्वपूर्ण सीमाएँ,
• यदि प्रासंगिक हो तो कार्यान्वयन अवधि।

उदाहरण:

प्रोजेक्ट का लक्ष्य B2B एप्लिकेशन में खरीद प्रक्रिया को छोटा करना था। उत्पाद कई यूरोपीय बाजारों में काम करता था और व्यावसायिक ग्राहकों को सेवा देता था।

इससे पाठक व्यक्तिगत योगदान का आकलन करने से पहले संदर्भ समझ लेता है.

हर व्यक्ति का नाम लिखना जरूरी नहीं है।

कई मामलों में ऐसी संरचना पर्याप्त है:

टीम: उत्पाद प्रबंधक, उपयोगकर्ता अनुभव डिजाइनर, 2 क्लाइंट-साइड डेवलपर, 2 सर्वर-साइड डेवलपर और एक गुणवत्ता विशेषज्ञ।

यह एक जानकारी पूरे प्रोजेक्ट विवरण की व्याख्या बदल देती है।

पाठक देखता है कि परिणाम अकेले नहीं बना और विशेषज्ञ एक स्पष्ट जिम्मेदारी संरचना के भीतर काम कर रहा था.

यह सबसे महत्वपूर्ण हिस्सा है।

सामान्य वाक्य:

"मैंने क्लाइंट-साइड पर काम किया"

की जगह ठोस रूप से लिखें:

"मैं भुगतान मॉड्यूल की आर्किटेक्चर, खरीद-समापन प्रक्रिया के कार्यान्वयन, भुगतान API एकीकरण और इस क्षेत्र में बदलावों की कोड समीक्षा का जिम्मेदार था."

यदि अस्पष्टता हो सकती है तो यह भी बताना उपयोगी है कि आपने क्या नहीं किया:

"सर्वर-साइड परत और भुगतान प्रदाता का सर्वर-साइड एकीकरण अलग टीम ने किया."

इससे पोर्टफोलियो कमजोर नहीं होता। यह अधिक विश्वसनीय बनता है.

पदनाम अपने आप योगदान का विवरण नहीं होता।

एक वरिष्ठ उपयोगकर्ता अनुभव डिजाइनर किसी प्रोजेक्ट में पूरा शोध चला सकता है और दूसरे में केवल अंतिम स्क्रीन तैयार कर सकता है।

इसलिए ऐसी गतिविधियाँ दिखाएँ जिन्हें विशेष क्षमताओं से जोड़ा जा सके:

• मैंने समाधान की आर्किटेक्चर तैयार की,
• मैंने शोध किया,
• मैंने प्रक्रिया प्रवाह डिजाइन किया,
• मैंने डेटा का विश्लेषण किया,
• मैंने कार्यान्वयन का मुख्य हिस्सा लिखा,
• मैंने अभियान रणनीति तैयार की,
• मैंने वार्ता का नेतृत्व किया,
• मैंने टीमों के बीच निर्भरताएँ समन्वित कीं,
• मैंने लॉन्च से पहले समाधान सत्यापित किया।

सबसे उपयोगी उदाहरण वे हैं जिनमें आप यह भी समझा सकें कि किसी विशेष निर्णय को क्यों लिया गया.

यदि प्रोजेक्ट दिखाया जा सकता है, तो काम का नमूना दावे को वास्तविक काम से जोड़ता है।

उदाहरण के लिए:

• उत्पाद की स्क्रीन,
• इंटरफेस का हिस्सा,
• प्रोटोटाइप,
• कोड का अंश,
• सार्वजनिक रिपॉजिटरी,
• रिपोर्ट,
• आरेख,
• प्रकाशन,
• अभियान सामग्री,
• फोटो,
• दस्तावेज या उसका सुरक्षित अंश।

नमूने को सब कुछ साबित करने की जरूरत नहीं है। उसका उद्देश्य पाठक को यह समझाना है कि वास्तव में क्या बनाया गया और उसका वर्णित योगदान से क्या संबंध है.

अपने योगदान को बढ़ा-चढ़ाकर दिखाने का सबसे बड़ा जोखिम परिणामों के वर्णन में होता है।

यदि किसी प्रोजेक्ट के बाद कंपनी की रूपांतरण दर 25% बढ़ी, तो इसका मतलब यह नहीं कि एक व्यक्ति ने रूपांतरण 25% बढ़ाया।

उसी अवधि में बदल सकते थे:

• कीमतें,
• प्रस्ताव,
• मार्केटिंग,
• उपयोगकर्ता अनुभव,
• बुनियादी ढाँचा,
• मौसमी प्रभाव,
• ट्रैफिक स्रोत,
• अन्य टीम सदस्यों का काम।

परिणाम को केवल उसी स्तर की निश्चितता से लिखें जिसे आप वास्तव में उचित ठहरा सकें.

1. प्रत्यक्ष जिम्मेदारी
"मैंने जिन चरणों की जिम्मेदारी ली थी उन्हें स्वचालित करके इस प्रक्रिया का समय 12 मिनट से घटाकर 4 मिनट कर दिया."

इसे तब इस्तेमाल करें जब आपके कार्य और परिणाम के बीच संबंध प्रत्यक्ष और उचित रूप से साबित करने योग्य हो।

2. साझा परिणाम
"हमने टीम के साथ मिलकर उपयोगकर्ता प्रारंभिक प्रक्रिया को पुनःडिजाइन किया। लॉन्च के बाद पूर्णता दर 18% बढ़ी."

इसे तब इस्तेमाल करें जब परिणाम कई लोगों के काम से बना हो।

3. बड़े बदलाव में योगदान
"मैं व्यापक खरीद प्रक्रिया सुधार के हिस्से के रूप में खरीद-समापन प्रक्रिया के पुनःडिजाइन का जिम्मेदार था। पूरे कार्यक्रम के लॉन्च के बाद कंपनी ने रूपांतरण में वृद्धि दर्ज की."

इसे तब इस्तेमाल करें जब आपका क्षेत्र कई कारकों में से केवल एक हो।

4. परिणाम को प्रोजेक्ट संदर्भ की तरह दिखाना
"प्रोजेक्ट के बाद बिक्री 40% बढ़ी। मेरे दायरे में क्लाइंट-साइड आर्किटेक्चर और खरीद-समापन प्रक्रिया का कार्यान्वयन था."

इसे तब इस्तेमाल करें जब आपको पूरे प्रोजेक्ट का परिणाम पता हो, लेकिन यह तय करने का ठोस आधार न हो कि उसका कितना हिस्सा आपके काम से आया.

यदि प्रोजेक्ट में कई लोग शामिल हों, तो अच्छे विवरण को एक साथ दो सवालों का जवाब देना चाहिए:

टीम ने क्या दिया?

और

हर व्यक्ति किस चीज का जिम्मेदार था?

उदाहरण:

प्रोजेक्ट: लॉजिस्टिक्स एप्लिकेशन का पहला संस्करण
टीम: उपयोगकर्ता अनुभव डिजाइनर, क्लाइंट-साइड डेवलपर, सर्वर-साइड डेवलपर
साझा परिणाम: पायलट के लिए तैयार काम करने वाला पहला उत्पाद संस्करण
उपयोगकर्ता अनुभव डिजाइनर: शोध, उपयोगकर्ता यात्रा, प्रोटोटाइप, इंटरफेस डिजाइन
क्लाइंट-साइड डेवलपर: क्लाइंट आर्किटेक्चर, वेब एप्लिकेशन कार्यान्वयन
सर्वर-साइड डेवलपर: API, डेटा मॉडल, एकीकरण

ऐसा विवरण टीम और व्यक्तिगत विशेषज्ञ दोनों को मजबूत करता है.

कुछ प्रोजेक्ट में भागीदारी का स्तर बताने वाले सरल शब्द उपयोगी होते हैं:

मुख्य भूमिका - मैंने क्षेत्र का नेतृत्व किया और प्रमुख निर्णयों का जिम्मेदार था।
साझा जिम्मेदारी - मैंने एक या अधिक लोगों के साथ जिम्मेदारी साझा की।
सहायक भूमिका - मैंने क्षेत्र में सहायता की, लेकिन मुख्य जिम्मेदार नहीं था।

CRediT योगदानकर्ता भूमिकाओं में इसी तरह का अंतर करता है। [1]

मुख्य सिद्धांत सरल है: जिम्मेदारी का स्तर समझ में आना चाहिए.

महत्वपूर्ण साझा प्रोजेक्ट में यह देखना अच्छा है कि आपके योगदान का विवरण बाकी प्रतिभागियों की भूमिका समझ से स्पष्ट रूप से टकराता न हो।

CRediT अनुशंसा करता है कि योगदानकर्ता अपने नाम से जोड़ी गई भूमिकाओं की समीक्षा और पुष्टि कर सकें। [1]

पेशेवर पोर्टफोलियो में इसका अर्थ हर वाक्य की औपचारिक स्वीकृति नहीं है। व्यावहारिक नियम सरल है: उस काम की जिम्मेदारी अपने नाम न करें जिसका नेतृत्व वास्तव में किसी और ने किया था.

अपने योगदान का वर्णन कॉपीराइट निर्धारण के साथ नहीं मिलाना चाहिए।

पोलैंड के कॉपीराइट कानून के अनुसार अधिकार सामान्यतः लेखक के होते हैं और सह-लेखकों के मामले में संयुक्त रूप से होते हैं। रोजगार संबंध के तहत बनाए गए काम में नियोक्ता कानून और रोजगार संबंध द्वारा निर्धारित सीमा में आर्थिक अधिकार प्राप्त कर सकता है। [2]

व्यवहार में तीन सवाल अलग रखें:

क्या मैंने प्रोजेक्ट बनाने में भाग लिया?
क्या मैं किसी विशेष तत्व का लेखक या सह-लेखक हूँ?
क्या मुझे सामग्री अपने पोर्टफोलियो में प्रकाशित करने का अधिकार है?

पहले सवाल का "हाँ" बाकी दो के जवाब अपने आप तय नहीं करता.

हर प्रोजेक्ट दिखाया या विस्तार से बताया नहीं जा सकता।

पोलैंड का अनुचित प्रतिस्पर्धा कानून व्यापारिक रहस्य वाली जानकारी की रक्षा करता है, जिसमें कुछ तकनीकी, प्रौद्योगिकीय, संगठनात्मक और अन्य आर्थिक मूल्य वाली जानकारी शामिल है जिसे गोपनीय रखा जाता है। [3]

इसलिए गोपनीय प्रोजेक्ट में केवल ग्राहक का नाम हटाना पर्याप्त नहीं हो सकता। बाकी विवरण भी संरक्षित जानकारी उजागर कर सकते हैं।

सुरक्षित नियम है:

केवल वही बताएं जिसे आप लागू कानून, अनुबंध, प्राप्त सहमति और अपने अन्य अधिकारों के आधार पर वास्तव में उजागर कर सकते हैं।

प्रोजेक्ट विवरण में सामान्यतः पूरी टीम के निजी डेटा की जरूरत नहीं होती।

GDPR अन्य सिद्धांतों के साथ वैधता, उद्देश्य सीमा और डेटा न्यूनतमकरण की मांग करता है, यानी व्यक्तिगत डेटा संबंधित उद्देश्य के लिए आवश्यक सीमा तक ही होना चाहिए। [4]

यदि टीम को ऐसे बताना पर्याप्त है:

1 उपयोगकर्ता अनुभव डिजाइनर, 2 क्लाइंट-साइड डेवलपर, एक सर्वर-साइड डेवलपर और एक गुणवत्ता विशेषज्ञ

तो सहकर्मियों के नाम, फोटो, ईमेल पते या अन्य व्यक्तिगत डेटा प्रकाशित करने की स्वतः जरूरत नहीं है।

यदि आप किसी विशेष व्यक्ति की सिफारिश, बयान, तस्वीर या अन्य डेटा प्रकाशित करना चाहते हैं, तो उचित कानूनी आधार और सामग्री के अनुमत उपयोग का दायरा जांचें.

यदि सहयोग की शर्तें अनुभव का सामान्य वर्णन करने की अनुमति देती हैं, तो आप यह दिखाने पर विचार कर सकते हैं:

• ग्राहक की पहचान बताए बिना समस्या का प्रकार,
• अपनी भूमिका,
• इस्तेमाल की गई क्षमताओं की श्रेणियाँ,
• जिम्मेदारी का प्रकार,
• पर्याप्त रूप से सामान्य स्तर पर निर्णय प्रक्रिया,
• परिणाम केवल उस सीमा तक जहाँ उसे बताना अनुमत हो।

गोपनीय सामग्री की जगह काल्पनिक स्क्रीनशॉट, डेटा या परिणाम न बनाएं।

यदि आपको यकीन नहीं है कि कोई जानकारी बताई जा सकती है या नहीं, तो स्थिति स्पष्ट होने तक उसे प्रकाशित न करना अधिक सुरक्षित है.

शब्दों में छोटे अंतर जिम्मेदारी का स्तर बहुत स्पष्ट दिखा सकते हैं।

मैं इसके लिए जिम्मेदार था... - आपका अपना क्षेत्र स्पष्ट करता है।
मैंने नेतृत्व किया... - किसी क्षेत्र की दिशा या कार्यान्वयन की जिम्मेदारी दिखाता है।
मैंने सह-निर्माण किया... - दिखाता है कि परिणाम के एक से अधिक लेखक थे।
मैंने सहायता की... - सहायक योगदान को ईमानदारी से बताता है।
मैं उस टीम का हिस्सा था जिसने... - व्यक्तिगत भागीदारी को टीम के कुल परिणाम से अलग करता है।
प्रोजेक्ट लॉन्च होने के बाद कंपनी ने दर्ज किया... - पूरे प्रभाव को अपने नाम किए बिना परिणाम को संदर्भ की तरह दिखाता है।

यदि वास्तविक दायरा साझा था, तो स्वतः "मैंने किया" कहने से बचें.

1. आप कई लोगों द्वारा किए गए प्रोजेक्ट के लिए एकवचन भाषा इस्तेमाल करते हैं।

2. आप व्यावसायिक परिणाम दिखाते हैं लेकिन अपना काम का दायरा नहीं बताते।

3. आप पूरे उत्पाद की तकनीकों को अपनी क्षमता बताते हैं जबकि आपने उन सभी पर काम नहीं किया।

4. आप अंतिम दृश्य डिजाइन, कोड या रणनीति दिखाते हैं लेकिन यह नहीं बताते कि कौन-से हिस्से आपने वास्तव में बनाए।

5. आप उन प्रमुख सहयोगियों को छोड़ देते हैं जिनका योगदान प्रोजेक्ट समझने के लिए जरूरी है।

6. आप अपने काम और ऐसे परिणाम के बीच कारणात्मक संबंध सुझाते हैं जिसे आप उचित नहीं ठहरा सकते।

प्रोजेक्ट
क्या बनाया जा रहा था और कौन-सी समस्या हल करनी थी?

टीम
प्रोजेक्ट में कौन-कौन सी भूमिकाएँ थीं?

मेरी जिम्मेदारी
मैं व्यक्तिगत रूप से किस क्षेत्र का जिम्मेदार था?

मेरे कार्य और निर्णय
मैंने वास्तव में क्या किया या किसका नेतृत्व किया?

सहयोग
कौन-से तत्व दूसरों के साथ मिलकर बनाए गए?

काम के नमूने
मैं कानूनी रूप से क्या दिखा सकता हूँ?

परिणाम
प्रोजेक्ट ने क्या हासिल किया और मेरा योगदान उस परिणाम से कैसे जुड़ा था?

सीमाएँ
क्या ऐसे तत्व हैं जिन्हें मैं गोपनीयता या अन्य लोगों के अधिकारों के कारण उजागर नहीं कर सकता?

खुद से सात सवाल पूछें:

1. क्या पाठक जानता है कि टीम कितनी बड़ी थी?

2. क्या यह स्पष्ट है कि मैं वास्तव में किस चीज का जिम्मेदार था?

3. क्या मैंने दूसरों द्वारा किए गए काम को अपने नाम करने से बचा है?

4. क्या परिणाम उचित सावधानी के साथ लिखा गया है?

5. क्या मुझे इस्तेमाल की गई सामग्री प्रकाशित करने का कानूनी अधिकार है?

6. क्या मैं अनावश्यक व्यक्तिगत या गोपनीय जानकारी उजागर करने से बच रहा हूँ?

7. क्या बाहर का व्यक्ति इस विवरण से समझ सकता है कि मैंने वास्तव में कौन-सी क्षमताएँ इस्तेमाल कीं?

यदि जवाब स्पष्ट हैं, तो प्रोजेक्ट विवरण केवल आकर्षक कहानी नहीं बल्कि क्षमता का प्रमाण बनना शुरू करता है.

सबसे अच्छा प्रोजेक्ट विवरण इनके बीच चुनने के लिए मजबूर नहीं करता:

"यह मैंने किया"

और

"यह टीम ने किया."

यह दोनों सच एक साथ दिखा सकता है:

टीम ने एक निश्चित परिणाम दिया और मैं एक विशेष हिस्से, निर्णयों और कार्यान्वयन का जिम्मेदार था.

इस स्तर की सटीकता दूसरों का श्रेय छीने बिना विशेषज्ञ का आकलन करने देती है.

पोर्टफोलियो सबसे बड़ा दावा करने की प्रतियोगिता नहीं होना चाहिए।

उसकी कीमत तब बढ़ती है जब सामने वाला समझ सके:

क्या बनाया गया, किसने उस पर काम किया, आपकी जिम्मेदारी क्या थी, आपने व्यक्तिगत रूप से क्या किया और कौन-सा परिणाम उचित रूप से आपके योगदान से जोड़ा जा सकता है.

सटीक विवरण उपलब्धि को कमजोर नहीं करता।

इसके विपरीत, यह दिखाता है कि आप अपनी जिम्मेदारी समझते हैं, दूसरों के साथ काम कर सकते हैं और अपने काम के परिणामों को ईमानदारी से प्रस्तुत करते हैं.

[1] CRediT - Contributor Role Taxonomy, NISO
स्रोत खोलें

[2] पोलैंड का कॉपीराइट और संबंधित अधिकार अधिनियम - अनुच्छेद 8-12, ELI
स्रोत खोलें

[3] पोलैंड का अनुचित प्रतिस्पर्धा से मुकाबला अधिनियम - अनुच्छेद 11, 2026 में प्रकाशित समेकित पाठ
स्रोत खोलें

[4] विनियमन (EU) 2016/679 - GDPR, अनुच्छेद 5, EUR-Lex
स्रोत खोलें

पद्धतिगत टिप्पणी: CRediT शोध और वैज्ञानिक प्रकाशनों में योगदानकर्ता भूमिकाओं का मानक है। यह लेख इसे पारदर्शी योगदान-अनुदेशन के उदाहरण के रूप में उपयोग करता है, लेकिन इसे पेशेवर पोर्टफोलियो का मानक नहीं बताता। प्रोजेक्ट विवरण के छह तत्व और परिणामों से संबंध बताने के चार तरीके इस सामग्री में प्रस्तावित संपादकीय मॉडल हैं.