एक व्यक्ति या टीम? कौशल, निर्भरताओं और जोखिम के आधार पर परियोजना का न्यूनतम दल कैसे तय करें

शोध "छोटी टीम हमेशा बेहतर होती है" या "बड़ी टीम हमेशा अधिक काम करती है" जैसे सरल नियम का समर्थन नहीं करता.

2023 के एक मेटा-विश्लेषण में 208 स्वतंत्र प्रभाव और 21,435 टीमें शामिल थीं. कुल मिलाकर टीम के आकार और कार्य प्रदर्शन के बीच संबंध लगभग शून्य पाया गया, लेकिन संदर्भ के अनुसार बहुत बड़ा अंतर भी मिला. लेखकों ने दिखाया कि कार्य की जटिलता और समन्वय की जरूरत जैसे तत्व टीम आकार के प्रभाव को बदलते हैं. [4]

जटिल संकट-मानचित्रण कार्य पर एक प्रयोग ने बड़ी टीमों के लाभ और लागत दोनों दिखाए: टीम बढ़ने के साथ सहयोग बढ़ा, लेकिन व्यक्तिगत प्रयास के ढंग भी बदले. उसी विशिष्ट प्रयोग में सबसे बड़ी टीमों ने उतने ही स्वतंत्र व्यक्तियों से बेहतर प्रदर्शन किया. यह हर तरह के काम के लिए सार्वभौमिक नियम नहीं है. [5]

व्यावहारिक निष्कर्ष सरल है: लोगों की संख्या काम की प्रकृति से तय होनी चाहिए, किसी जादुई संख्या से नहीं.

2020 Scrum Guide Scrum Team को छोटी, विभिन्न आवश्यक कौशलों वाली और स्वयं अपना काम प्रबंधित करने वाली टीम बताता है. वह यह भी कहता है कि ऐसी टीम आम तौर पर 10 या उससे कम लोगों की होती है. [3]

यह Scrum के संदर्भ में उपयोगी मार्गदर्शन है, लेकिन हर परियोजना, सेवा, उद्योग या कार्य मॉडल का सार्वभौमिक नियम नहीं.

निर्माण परियोजना, विपणन अभियान, सुरक्षा मूल्यांकन, वित्तीय प्रणाली और छोटी जानकारी वेबसाइट की जरूरतें बहुत अलग होती हैं. एक ही संख्या को इन सभी स्थितियों पर लागू नहीं करना चाहिए.

ब्रिटेन का Service Standard डिजिटल सेवाओं की टीमों को बहु-विषयी और आवश्यक कौशलों तक पहुँच रखने वाला होने को कहता है. वह यह भी बताता है कि टीम की संरचना इस बात पर निर्भर होनी चाहिए कि उस चरण में क्या हासिल करना है. [1]

GOV.UK की दूसरी मार्गदर्शिका बताती है कि सेवा बनाते समय अलग-अलग चरणों में टीम का आकार और जरूरी भूमिकाएँ बदलती हैं. [2]

इससे एक व्यावहारिक नियम निकलता है:

पहले काम और जिम्मेदारी को सूचीबद्ध करें, फिर कौशल तय करें और अंत में उन्हें व्यक्तियों को सौंपें.

अस्पष्ट दायरे के लिए सही टीम तय नहीं की जा सकती.

कम से कम यह लिखें:

• कौन-सा परिणाम बनाना है,
• क्या दायरे में है,
• क्या दायरे से बाहर है,
• सबसे महत्वपूर्ण गुणवत्ता अपेक्षाएँ क्या हैं,
• समय और बजट की सीमाएँ क्या हैं,
• परिणाम कौन स्वीकार करेगा,
• टीम केवल समाधान देगी या उसे चलाना भी उसकी जिम्मेदारी है.

"एक एप्लिकेशन बनाना" और "एक एप्लिकेशन डिजाइन करना, बनाना, सुरक्षित करना, तैनात करना और एक साल चलाना" पूरी तरह अलग कार्य कवरेज मांगते हैं.

तुरंत पदनाम लिखने के बजाय उन प्रकार के काम की सूची बनाएं जो वास्तव में होने चाहिए.

डिजिटल सेवा में उदाहरण हो सकते हैं:

• उपयोगकर्ता जरूरतों को समझना,
• समाधान डिजाइन करना,
• उपयोगकर्ता को दिखने वाला हिस्सा बनाना,
• सर्वर पक्ष का तर्क और एकीकरण बनाना,
• परीक्षण,
• सुरक्षा,
• सुगम्यता,
• तैनाती और संचालन,
• दायरे और निर्णयों का समन्वय.

दूसरे प्रकार की परियोजना में सूची अलग होगी.

GOV.UK बताता है कि डिजिटल सेवा बनाने और चलाने वाली टीम को उपयोगकर्ता जरूरत, डिजाइन, निर्माण, परीक्षण, सुरक्षा, तैनाती और संचालन सहित व्यापक कौशल चाहिए. [2]

हर आवश्यक कौशल के लिए टीम में पूर्णकालिक व्यक्ति जरूरी नहीं.

हर क्षेत्र को वर्गीकृत करें:

स्थायी - नियमित रूप से जरूरी और रोज के निर्णयों पर सीधा प्रभाव.
समय-समय पर - खास चरण या समीक्षा बिंदु पर जरूरी.
बाहरी रूप से उपलब्ध - किसी दूसरे व्यक्ति या टीम से मिल सकता है, यदि प्रतिक्रिया समय और जिम्मेदारी पर्याप्त रूप से स्पष्ट हों.

GOV.UK स्पष्ट रूप से मानता है कि विशेषज्ञ ज्ञान टीम को उपलब्ध हो सकता है, भले विशेषज्ञ स्थायी सदस्य न हो. [1]

इससे महत्वपूर्ण विशेषज्ञता खोए बिना टीम को अनावश्यक रूप से बड़ा करने से बचा जा सकता है.

दो लोगों के पास मिलकर सभी जरूरी कौशल हो सकते हैं, फिर भी व्यवस्था खराब हो सकती है यदि पूरा काम एक संकरी निर्भरता श्रृंखला में फँसा हो.

जाँचें:

• कौन-से काम समानांतर चल सकते हैं,
• कौन-से काम दूसरों की प्रतीक्षा करेंगे,
• कौन-से निर्णय आगे का काम रोकते हैं और उन्हें कौन लेता है,
• परियोजना किन बाहरी टीमों या आपूर्तिकर्ताओं पर निर्भर है,
• कहाँ एक व्यक्ति की अनुपस्थिति कई क्षेत्रों को रोक देगी.

GOV.UK अन्य टीमों पर निर्भरताओं के प्रबंधन को डिजिटल सेवा बनाने की आवश्यक क्षमताओं में गिनता है. [2]

जब एक से अधिक टीम सेवा पर काम करती हैं, तो योजनाओं और प्रगति का अतिरिक्त समन्वय जरूरी होता है. [8]

कुछ जरूरी विशेषज्ञता उत्पाद की सुविधाओं की सूची में दिखाई नहीं देती, लेकिन उसकी कमी महँगी पड़ सकती है.

परियोजना के अनुसार इसमें शामिल हो सकता है:

• सुरक्षा,
• डेटा संरक्षण,
• सुगम्यता,
• कानूनी या उद्योग संबंधी आवश्यकताएँ,
• विश्वसनीयता,
• डेटा स्थानांतरण,
• महत्वपूर्ण प्रणालियों के साथ एकीकरण,
• ऐसी तकनीक जिसे टीम ने पहले इस्तेमाल नहीं किया.

GOV.UK जरूरत होने पर विशेषज्ञ ज्ञान तक पहुँच की सलाह देता है और कहता है कि टीम की संरचना उस चरण की सबसे जोखिमपूर्ण धारणाओं को भी दर्शानी चाहिए. [1]

इसका मतलब हर जोखिम के लिए अलग पूर्णकालिक पद नहीं है. इसका मतलब है कि किसी सक्षम व्यक्ति के पास स्पष्ट जिम्मेदारी और निर्णयों पर वास्तविक प्रभाव होना चाहिए.

एक व्यक्ति डिजाइन, विकास, परीक्षण और तैनाती जान सकता है. इसका मतलब यह नहीं कि वह ये सभी काम एक साथ किसी भी समयसीमा में कर सकता है.

PMI की संसाधन योजना सामग्री कौशल, उपलब्धता, लागत और अनुभव को परियोजना की जरूरतों से मिलाने के महत्व पर जोर देती है. [7]

हर व्यक्ति के लिए देखें:

• वह वास्तव में कितना समय दे सकता है,
• कौन-से काम उसके ध्यान के लिए प्रतिस्पर्धा करते हैं,
• क्या जरूरी काम समानांतर चलना चाहिए,
• क्या समयसीमा कई प्रकार के काम के बीच अव्यावहारिक बदलाव मानती है,
• क्या लॉन्च के बाद समाधान चलाने के लिए भी किसी की जरूरत है.

कौशल उपलब्ध होना लेकिन समय उपलब्ध न होना, परियोजना की पूरी जरूरत को पूरा नहीं करता.

न्यूनतम दल में निरंतरता भी देखनी चाहिए.

पूछें:

• मुख्य व्यक्ति उपलब्ध न हो तो क्या होगा,
• क्या केवल एक व्यक्ति समाधान का महत्वपूर्ण हिस्सा समझता है,
• क्या निर्णय और ज्ञान दर्ज किए जाते हैं,
• क्या कोई और प्रमुख काम संभाल सकता है,
• क्या अनुपस्थिति में परियोजना सुरक्षित रूप से रुक सकती है.

हर छोटी परियोजना में पूरा बैकअप जरूरी नहीं. छोटी, कम जोखिम वाली परियोजना में इस जोखिम को जानबूझकर स्वीकार करना उचित हो सकता है.

महत्वपूर्ण परियोजना में यही निर्भरता अस्वीकार्य हो सकती है.

परियोजना को हर भूमिका नाम के लिए अलग व्यक्ति जरूरी नहीं.

यदि एक व्यक्ति में सचमुच आवश्यक कौशल हैं, पर्याप्त समय है और वह अस्वीकार्य जोखिम पैदा नहीं करता, तो वह कई क्षेत्रों को जिम्मेदारी से संभाल सकता है.

छोटी परियोजना में एक व्यक्ति इंटरफ़ेस डिजाइन और उसे लागू करने का काम कर सकता है. दूसरी परियोजना में वही व्यक्ति व्यावसायिक विश्लेषण और दायरे का समन्वय जोड़ सकता है.

जिम्मेदारियाँ केवल इसलिए न जोड़ें कि "किसी को तो करना है". संयोजन तभी उचित है जब व्यक्ति दोनों जिम्मेदारियाँ अपेक्षित स्तर पर निभा सके और उसके पास पर्याप्त समय हो.

एक व्यक्ति उचित दल हो सकता है यदि एक साथ ये स्थितियाँ हों:

• दायरा छोटा और स्पष्ट हो,
• जरूरी कौशल वास्तव में उसकी क्षमता में हों,
• बहुत अधिक समानांतर काम न हो,
• बाहरी निर्भरताएँ सीमित हों,
• जोखिम स्वीकार्य हो,
• समयसीमा वास्तविक क्षमता से मेल खाती हो,
• बैकअप न होने का जोखिम जानबूझकर स्वीकार हो.

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

फिर भी निर्णय वास्तविक दायरे पर निर्भर है. केवल "छोटी परियोजना" कह देना पर्याप्त नहीं.

इनमें से कई स्थितियाँ होने पर टीम अधिक उचित होती है:

• जरूरी कौशल एक व्यक्ति के लिए बहुत व्यापक हों,
• कई काम समानांतर चलने हों,
• समयसीमा वास्तविक क्रमिक कार्य से कम हो,
• बहुत सारी निर्भरताएँ और संपर्क बिंदु हों,
• जोखिम स्वतंत्र विशेषज्ञता माँगता हो,
• समाधान को एक साथ बनाना और चलाना हो,
• एक व्यक्ति पूरी परियोजना का महत्वपूर्ण एकल बिंदु बन जाए,
• जिम्मेदारी कई अलग क्षेत्रों में फैली हो.

ऐसी स्थिति में केवल लोगों की संख्या बढ़ाने से अधिक महत्वपूर्ण है कि गायब क्षमताएँ जोड़ी जाएँ.

लोग जोड़ने से उपलब्ध ज्ञान और संभावित क्षमता बढ़ती है, लेकिन निर्भरताएँ, काम का हस्तांतरण और निर्णय समन्वय भी बढ़ सकते हैं.

Journal of Systems and Software में प्रकाशित सॉफ्टवेयर परियोजनाओं के अध्ययन ने दिखाया कि टीम आकार, उत्पादकता, प्रयास और समय के संबंध जटिल हैं और हमेशा हमारी सहज अपेक्षाओं से मेल नहीं खाते. [6]

टीम आकार पर मेटा-विश्लेषण भी दिखाता है कि परिणाम कार्य के संदर्भ और टीम प्रक्रियाओं की लागत पर निर्भर करते हैं. [4]

इसलिए सवाल "कितने लोग जोड़ सकते हैं?" नहीं, बल्कि "क्या अगला व्यक्ति परियोजना की वास्तविक बाधा को समन्वय लागत से अधिक कम करता है?" होना चाहिए.

हर महत्वपूर्ण कौशल रोज मौजूद होना जरूरी नहीं.

स्थायी उपस्थिति तब अधिक उचित है जब व्यक्ति नियमित निर्णय लेता हो, उसके काम की अन्य क्षेत्रों से बहुत निर्भरताएँ हों या तेज प्रतिक्रिया जरूरी हो.

समय-समय पर सहायता तब पर्याप्त हो सकती है जब विशेषज्ञता खास बिंदुओं पर चाहिए, जैसे समीक्षा, परामर्श, जोखिम मूल्यांकन या विशेषज्ञ स्वीकृति.

एक शर्त है: उपलब्धता वास्तविक हो. यह स्पष्ट होना चाहिए:

• जिम्मेदार कौन है,
• कब उपलब्ध है,
• अपेक्षित प्रतिक्रिया समय क्या है,
• कौन-से निर्णय ले सकता है,
• समस्या मिलने पर क्या होगा.

बिना स्पष्ट जिम्मेदारी के विशेषज्ञ तक नाममात्र पहुँच संगठन चार्ट में अच्छी दिख सकती है, लेकिन वास्तविक परियोजना में विफल हो सकती है.

मान लें लक्ष्य एक ऑनलाइन बुकिंग प्रणाली शुरू करना है.

विकल्प A: विचार जाँचने के लिए सरल प्रोटोटाइप
दायरा सीमित है, भुगतान या विशेष रूप से संवेदनशील डेटा नहीं है और लक्ष्य छोटे उपयोगकर्ता समूह के साथ प्रक्रिया जाँचना है. एक बहु-कुशल व्यक्ति डिजाइन और निर्माण संभाल सकता है, जरूरत पर विशेषज्ञ सलाह ली जा सकती है.

विकल्प B: खातों, भुगतान और एकीकरण वाली सार्वजनिक सेवा
अधिक विशेषज्ञता, परीक्षण, जोखिम, निर्भरताएँ और समानांतर काम आते हैं. कई लोगों की टीम अधिक उचित हो जाती है.

विकल्प C: लगातार चलने वाली सेवा जिसमें समस्याओं पर तेज प्रतिक्रिया चाहिए
निर्माण के साथ संचालन, निगरानी, घटना प्रतिक्रिया और ज्ञान निरंतरता जुड़ती है. लॉन्च के लिए पर्याप्त दल स्थायी संचालन के लिए पर्याप्त न हो सकता.

सामान्य उत्पाद प्रकार समान है, लेकिन दायरा, जोखिम और संचालन मॉडल बदलते ही टीम की जरूरत भी बदलती है.

1. आप काम से नहीं, तैयार पदनाम सूची से शुरू करते हैं.

2. आप मानते हैं कि हर भूमिका के लिए अलग व्यक्ति चाहिए.

3. आप केवल कौशल देखते हैं और उपलब्ध समय भूल जाते हैं.

4. निर्भरताएँ और बाधाएँ हटाए बिना लोगों को जोड़ते हैं.

5. जोखिम से निकलने वाले कौशल अनदेखे करते हैं क्योंकि वे कोई दिखाई देने वाली सुविधा नहीं बनाते.

6. कई महत्वपूर्ण क्षेत्रों को एक व्यक्ति पर निर्भर करते हैं, बिना जोखिम को जानबूझकर स्वीकार किए.

7. परियोजना के शुरुआती दल को अंत तक स्थायी मान लेते हैं.

GOV.UK स्पष्ट रूप से कहता है कि सेवा विकास के अलग चरणों में टीम का आकार और भूमिकाएँ बदलती हैं. [2]

यह सार्वजनिक सेवाओं से बाहर भी उचित सिद्धांत है:

• शुरुआत में अधिक शोध और समस्या स्पष्ट करना जरूरी हो सकता है,
• निर्माण के दौरान कार्यान्वयन और परीक्षण कौशल का महत्व बढ़ता है,
• लॉन्च से पहले सुरक्षा, गुणवत्ता और संचालन तैयारी पर अधिक ध्यान चाहिए,
• लॉन्च के बाद विकास और संचालन का संतुलन बदलता है.

न्यूनतम दल चरण और दायरे का गुण है, परियोजना के लिए हमेशा का स्थिर अंक नहीं.

हर महत्वपूर्ण क्षेत्र के लिए पाँच बातें लिखें:

कार्य क्षेत्र - क्या करना है?
कौशल - कौन-सा ज्ञान और क्षमता चाहिए?
जिम्मेदारी - निर्णय कौन लेता है और परिणाम का मालिक कौन है?
उपलब्धता - कौशल स्थायी, समय-समय पर या बाहरी है?
अनुपस्थिति का जोखिम - कौशल या व्यक्ति न हो तो क्या होगा?

उसके बाद ही लोगों को नियुक्त करें.

यदि एक व्यक्ति कई पंक्तियाँ संभालता है तो समय और निर्भरताएँ जाँचें. यदि एक पंक्ति के लिए कई लोग चाहिए तो तय करें कि कारण क्षमता, स्वतंत्र जाँच या समानांतर काम है.

1. क्या हर जरूरी कार्य क्षेत्र का जिम्मेदार है?
2. क्या हर महत्वपूर्ण जिम्मेदारी सही कौशल वाले व्यक्ति के पास है?
3. क्या कोई कई भूमिकाएँ निभा रहा है और उसके पास वास्तव में पर्याप्त समय है?
4. क्या परियोजना ऐसा समानांतर काम चाहती है जिसे वर्तमान दल संभाल नहीं सकता?
5. क्या अन्य लोगों, टीमों और आपूर्तिकर्ताओं पर प्रमुख निर्भरताएँ ज्ञात हैं?
6. क्या महत्वपूर्ण जोखिमों को सही विशेषज्ञता उपलब्ध है?
7. क्या एक व्यक्ति की अनुपस्थिति पूरी परियोजना रोक सकती है?
8. यदि दायरे में है तो क्या दल निर्माण के साथ लॉन्च और संचालन के लिए भी पर्याप्त है?
9. क्या पता है कि कौन-से कौशल स्थायी के बजाय समय-समय पर उपलब्ध हो सकते हैं?
10. क्या दायरा या चरण बदलने पर दल की दोबारा समीक्षा के बिंदु तय हैं?

टीम तय करने की शुरुआत इस सवाल से नहीं होनी चाहिए:

"ऐसी परियोजनाओं में आम तौर पर कितने लोग लगते हैं?"

बेहतर क्रम है:

परिणाम -> काम -> कौशल -> निर्भरताएँ -> जोखिम -> क्षमता -> लोग.

यदि इस प्रक्रिया के बाद एक व्यक्ति सच में सब कुछ पूरा करता है, तो एक व्यक्ति सही विकल्प हो सकता है.

यदि कौशल, समय, स्वतंत्र जाँच, निरंतरता या समानांतर कार्य क्षमता कम है, तो अतिरिक्त लोगों या विशेषज्ञों तक भरोसेमंद पहुँच की जरूरत है.

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

[1] GOV.UK Service Standard - Have a multidisciplinary team
स्रोत खोलें

[2] GOV.UK Service Manual - Set up a service team at each phase
स्रोत खोलें

[3] The Scrum Guide, 2020 - Scrum Team
स्रोत खोलें

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
स्रोत खोलें

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
स्रोत खोलें

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
स्रोत खोलें

[7] Project Management Institute - Solving The Resource Puzzle
स्रोत खोलें

[8] GOV.UK Service Manual - Running more than one service team
स्रोत खोलें

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