समय सीमा सिर पर हो और बहुत सारा काम पिछड़ा हुआ हो, तो हर किसी के मन में लगभग एक ही विचार आता है। क्या और लोगों को लगाने से काम जल्दी पूरा नहीं हो जाएगा? आखिर घर बदलते समय सामान ढोने या खेत जोतने जैसे कामों में अधिक हाथ होने से काम जल्दी पूरा होने के उदाहरण साफ दिखाई देते हैं।
लेकिन सॉफ्टवेयर विकास में अक्सर इसका उलटा होता है। पहले से देर से चल रही परियोजना में और लोगों को लगाने से समय सीमा और आगे खिसक जाती है। अनुभव पर आधारित इस नियम को सबसे पहले व्यवस्थित रूप से प्रस्तुत करने वाले व्यक्ति के नाम पर ‘ब्रूक्स का नियम (Brooks's Law)’ कहा जाता है।
इस सामग्री में हम क्रम से समझेंगे कि ब्रूक्स का नियम किस पृष्ठभूमि में सामने आया, मैन-मंथ की इकाई में कौन-सा भ्रम छिपा है, अधिक लोगों को जोड़ने पर भी काम तेज क्यों नहीं होता, संचार के रास्ते किस हिसाब से बढ़ते हैं, और इस नियम के प्रभाव से बचने के उपाय तथा इसकी सीमाएँ क्या हैं।
ब्रूक्स के नियम का सिद्धांत और उपयोग
नियम की उत्पत्ति और मैन-मंथ का भ्रम
फ्रेडरिक ब्रूक्स (Frederick P. Brooks Jr.) एक कंप्यूटर वैज्ञानिक थे, जिन्होंने 1960 के दशक में अमेरिका की IBM कंपनी में बड़े कंप्यूटर System/360 और उसके ऑपरेटिंग सिस्टम OS/360 के विकास का नेतृत्व किया था। OS/360 उस समय की सबसे बड़ी सॉफ्टवेयर परियोजनाओं में गिना जाता था। इसमें बहुत बड़ी संख्या में डेवलपर लगाए गए, फिर भी समय-सारणी लगातार पिछड़ती रही।
इसी अनुभव के आधार पर ब्रूक्स ने 1975 में ‘मैन-मंथ का मिथक (The Mythical Man-Month)’ पुस्तक प्रकाशित की। इस पुस्तक में उन्होंने लिखा, “देर से चल रही सॉफ्टवेयर परियोजना में और लोगों को लगाने से उसमें और देरी होती है (Adding manpower to a late software project makes it later)।” यही कथन ब्रूक्स के नियम के नाम से जाना जाने लगा।
मैन-मंथ (Man-Month) उस काम की मात्रा की इकाई है, जिसे एक व्यक्ति एक महीने में करता है। इस हिसाब से 10 मैन-मंथ का काम एक व्यक्ति दस महीने में या दस व्यक्ति एक महीने में पूरा कर सकते हैं। ब्रूक्स ने बताया कि यह गणना तभी सही होती है, जब काम को आपसी बातचीत की जरूरत के बिना बराबर हिस्सों में बाँटा जा सके। लोगों और महीनों को एक-दूसरे की जगह इस्तेमाल करने का विचार ही एक भ्रम है।
आधी सदी बीत जाने के बाद भी यह पुस्तक सॉफ्टवेयर इंजीनियरिंग की एक कालजयी कृति मानी जाती है। 1995 में प्रकाशित इसके 20वीं वर्षगाँठ संस्करण में ‘कोई जादुई उपाय नहीं (No Silver Bullet)’ नामक लेख भी शामिल किया गया था। इस लेख का आशय है कि उत्पादकता को एक ही झटके में बहुत अधिक बढ़ाने वाला कोई जादुई तरीका नहीं है। कंप्यूटर आर्किटेक्चर और सॉफ्टवेयर इंजीनियरिंग में योगदान के लिए ब्रूक्स को 1999 में ट्यूरिंग पुरस्कार (Turing Award) मिला।
अधिक लोगों को जोड़ने पर भी काम तेज क्यों नहीं होता
देर से चल रही परियोजना में नए लोगों को लगाने पर तुरंत ऐसा लगता है कि काम करने वाले हाथ बढ़ गए हैं। लेकिन वास्तव में निम्नलिखित कारणों से समय-सारणी के और पिछड़ने की आशंका रहती है।
(1) काम सीखने में समय लगता है
नए व्यक्ति को अपना योगदान देने लायक बनने के लिए परियोजना की संरचना, अब तक लिए गए निर्णय और काम करने के तरीके सीखने पड़ते हैं। इस दौरान पुराने सदस्यों को अपना काम रोककर नए व्यक्ति को सिखाना पड़ता है, इसलिए शुरुआती कुछ हफ्तों में पूरी टीम की गति उलटे घट जाती है।
(2) कुछ काम बाँटे नहीं जा सकते
कुछ काम ऐसे होते हैं, जिन्हें लोगों की संख्या कितनी भी बढ़ा दी जाए, एक निश्चित क्रम में ही करना पड़ता है। ब्रूक्स ने इसे इन शब्दों में समझाया था: “बच्चे को जन्म देने में नौ महीने लगते हैं। इस काम के लिए कितनी भी महिलाओं को लगाया जाए, समय उतना ही लगेगा।”
(3) तालमेल बैठाने का काम बढ़ता है
काम को जितने छोटे हिस्सों में बाँटा जाता है, उन हिस्सों को दोबारा जोड़ने, यह जाँचने कि वे एक-दूसरे के साथ सही बैठते हैं, और विचारों में तालमेल बनाने का काम उतना ही बढ़ता है। लोगों की संख्या बढ़ने के साथ इस समन्वय में लगने वाला समय तेजी से बढ़ता है।
जब ये तीनों बातें एक साथ होती हैं, तो नए व्यक्ति के अपना योगदान देना शुरू करने से पहले ही मौजूदा समय-सारणी बिगड़ जाती है। इसलिए काम में हुई देरी की भरपाई लोगों की संख्या बढ़ाकर करने की कोशिश अक्सर अंततः और अधिक देरी पैदा करती है।
संचार के रास्ते बढ़ने का हिसाब
ब्रूक्स के नियम को सबसे अच्छी तरह संचार के रास्तों की संख्या से समझा जा सकता है। यदि टीम के सभी सदस्यों को एक-दूसरे से बातचीत करनी हो और लोगों की संख्या n हो, तो संचार के रास्तों की संख्या n(n-1)/2 होगी। लोगों की संख्या एक-एक करके बढ़ती है, लेकिन रास्तों की संख्या उससे कहीं अधिक तेजी से बढ़ती है।
- 3 लोगों की टीम (Team of 3): संचार के 3 रास्ते होते हैं।
- 5 लोगों की टीम (Team of 5): संचार के रास्तों की संख्या बढ़कर 10 हो जाती है।
- 10 लोगों की टीम (Team of 10): संचार के रास्तों की संख्या 45 हो जाती है।
- 20 लोगों की टीम (Team of 20): संचार के रास्तों की संख्या 190 तक पहुँच जाती है।
इसका अर्थ है कि लोगों की संख्या दोगुनी होने पर रास्तों की संख्या लगभग चौगुनी हो जाती है। बैठकें, संदेश और जाँच का काम उसी अनुपात में बढ़ते हैं, जबकि असल में प्रोग्राम बनाने के लिए उपलब्ध समय घटता जाता है। एक बिंदु के बाद ऐसी स्थिति आ जाती है, जहाँ और लोगों को जोड़ने से कुल उत्पादकता उलटे घटने लगती है।
नियम के प्रभाव से बचने के उपाय और सीमाएँ
ब्रूक्स के नियम का आशय लोगों की संख्या बढ़ाने से मना करना नहीं, बल्कि यह सोच-समझकर तय करना है कि संख्या कब और कैसे बढ़ाई जाए। वास्तविक विकास कार्य में इस जाल से बचने के लिए निम्नलिखित तरीके अपनाए जाते हैं।
- छोटी टीम (Small Team): एक टीम में लोगों की संख्या कम रखकर संचार के रास्ते घटाए जाते हैं। अमेज़न का ‘दो पिज़्ज़ा टीम’ सिद्धांत इसका एक प्रसिद्ध उदाहरण है।
- मॉड्यूलरता (Modularity): काम को एक-दूसरे से स्वतंत्र हिस्सों में बाँटा जाता है और उन हिस्सों के बीच के नियम स्पष्ट रूप से तय किए जाते हैं, ताकि टीमों को आपस में कम बातचीत करनी पड़े।
- शुरुआत में ही लोग जोड़ना (Early Staffing): यदि लोगों की जरूरत हो, तो उन्हें समय-सारणी पिछड़ने के बाद जोड़ने के बजाय परियोजना की शुरुआत में ही जोड़ा जाता है, ताकि उन्हें काम सीखने का समय मिल सके।
- कार्य-क्षेत्र में कटौती (Scope Cut): यदि पहले ही देरी हो चुकी हो, तो अक्सर और लोगों को जोड़ने की तुलना में सुविधाएँ कम करना या समय-सारणी दोबारा तय करना बेहतर होता है।
हालाँकि इस नियम की भी सीमाएँ हैं। बाद में स्वयं ब्रूक्स ने भी स्वीकार किया कि यह नियम अत्यधिक सरलीकृत कथन है। परीक्षण या दस्तावेज़ लिखने जैसे काम, जिन्हें छोटे हिस्सों में बाँटना आसान हो, अथवा ऐसे व्यक्ति के जुड़ने पर जो परियोजना को पहले से अच्छी तरह जानता हो, अधिक लोगों को जोड़ने से वास्तव में काम तेज भी हो सकता है। आज सहयोग के उपकरणों और स्वचालन के विकास से संचार में लगने वाला प्रयास पहले की तुलना में कम हुआ है, इसलिए यह नियम कितना प्रभावी होगा, यह टीम और काम की प्रकृति पर निर्भर करता है।
अंततः ब्रूक्स का नियम हमें याद दिलाता है कि काम की गति केवल लोगों की संख्या से तय नहीं होती। और हाथ जोड़ने से पहले यह देखना कि काम कैसे बँटता है और लोग किस तरह एक-दूसरे से जुड़े हैं—समय-सारणी के अनुसार विकास पूरा करने की दिशा में यही पहला कदम है।
