छह हफ़्ते के रिलीज़ प्लान का तीसरा हफ़्ता चल रहा है और आपकी सॉफ़्टवेयर टीम फंसी हुई है। प्रोडक्ट मैनेजर को कस्टमर डेमो के लिए एक पक्की तारीख चाहिए, इंजीनियरिंग मैनेजर डिफेक्ट्स (खामियों) के अचानक बढ़ने की चेतावनी दे रहा है, और QA टीम पहले से ही रात में काम कर रही है। दो इंजीनियर्स को तीन-तीन प्रोजेक्ट्स सौंपे गए हैं, प्रोडक्शन सपोर्ट रोटेशन उन्हें बार-बार अपने काम से हटा देता है, और डिज़ाइनर दो अलग-अलग स्क्वाड (टीमों) के बीच बंटा हुआ है। जो फ़ैसला अटका हुआ है, वह कागज़ पर तो आसान लगता है। क्या आप तय तारीख पर काम पूरा करने के लिए स्कोप (काम का दायरा) कम करेंगे, स्कोप वही रखेंगे और तारीख आगे बढ़ाएंगे, या ऐसी कैपेसिटी (क्षमता) जोड़ेंगे जो असल में आपके पास है ही नहीं? आप जितना इंतज़ार करेंगे, दोबारा काम (rework) उतना ही बढ़ेगा और भरोसा उतना ही कम होगा। यह कोर्स आपको ऐसी आदतें और तरीके सिखाएगा जिनसे आप इस मुश्किल स्थिति से बाहर निकल सकें। आप छिपी हुई रिसोर्स की ज़रूरतों को समझने के लिए शेड्यूल पढ़ना सीखेंगे, एक ऐसा कैपेसिटी मॉडल बनाएंगे जो लोगों के असल काम करने के तरीके से मेल खाता हो, और AI का इस्तेमाल करके ऐसे विकल्प तैयार करेंगे जिन पर आप असली स्टेकहोल्डर्स के साथ बातचीत कर सकें।
इसका पहला संकेत गैंट चार्ट (Gantt chart) नहीं होता, बल्कि काम में बार-बार आने वाली रुकावटें होती हैं। एक इंजीनियर कोई फ़ीचर बनाना शुरू करता है, फिर उसे ‘Sev 2’ इंसिडेंट (गंभीर समस्या) में उलझना पड़ता है, फिर वह ‘मर्ज कॉन्फ़्लिक्ट’ (merge conflicts) ठीक करने लौटता है, और उसके बाद किसी दूसरे प्रोजेक्ट के लिए जल्दबाज़ी में कोड रिव्यू करता है क्योंकि उससे उसके टीममेट का काम रुका हुआ होता है। माइलस्टोन (काम का लक्ष्य) पीछे छूट जाता है, और फिर टीम टेस्ट न करके इसकी भरपाई करने की कोशिश करती है। एक हफ़्ते बाद डिफ़ेक्ट्स (कमियां) बढ़ जाते हैं, QA एक अड़चन (bottleneck) बन जाता है, और रिलीज़ कैंडिडेट में बार-बार बदलाव करने पड़ते हैं। ‘बर्नआउट’ (काम के बोझ से थकान) का पता लंबे साइकिल टाइम, कमज़ोर हैंडऑफ़ (काम सौंपने की प्रक्रिया) और असल काम करने के बजाय स्टेटस पूछने में ज़्यादा समय बिताने से चलता है।
PM (प्रोजेक्ट मैनेजर) अक्सर इसे ‘एक्ज़ीक्यूशन’ (काम को पूरा करने) की समस्या मानकर गलती करते हैं। यह सोच सही लगती है क्योंकि आप ज़्यादा स्टैंड-अप मीटिंग्स बुला सकते हैं, Jira पर सख्ती कर सकते हैं और फ़ोकस करने के लिए कह सकते हैं। नतीजा यह होता है कि आप उन्हीं लोगों पर कोऑर्डिनेशन का बोझ और बढ़ा देते हैं जिन पर पहले से ही ज़रूरत से ज़्यादा काम का बोझ है। असल समस्या यह है कि शेड्यूल में ऐसे हफ़्तों में ज़्यादा ‘पर्सन-आवर्स’ (काम के घंटे) की मांग की जा रही है, जिन्हें टीम क्वालिटी से समझौता किए बिना पूरा नहीं कर सकती।
जब आप लोगों को काम सौंपते हैं, तो आप असल में सीमाओं (constraints) से जुड़ी समस्या को हल कर रहे होते हैं, न कि बस खाली बॉक्स भर रहे होते हैं। स्कोप का मतलब है वह काम जिसका आपने वादा किया है। शेड्यूल का मतलब है कि वह काम कब तक पूरा होना चाहिए। क्षमता (Capacity) का मतलब है कि टीम हर हफ़्ते काम के कितने घंटे दे सकती है। स्किल (Skills) का मतलब है कि कौन से लोग बिना किसी बड़े जोखिम के कौन से काम कर सकते हैं। उपलब्धता से जुड़ी धारणाएं (Availability assumptions) वे छिपे हुए नियम हैं—जैसे ऑन-कॉल ड्यूटी, मीटिंग्स और शेयर्ड सर्विस की रिक्वेस्ट—जो काम करने की क्षमता को कम कर देते हैं।
कोई भी कदम उठाने से पहले, यह अंदाज़ा लगाएं कि आपकी स्थिति में असल में कौन सी सीमा (constraint) सबसे बड़ी रुकावट है: शेड्यूल, स्किल या उपलब्धता।
यह इसलिए ज़रूरी है क्योंकि एक ही समस्या के अलग-अलग कारण हो सकते हैं। सॉफ़्टवेयर डिलीवरी में, अक्सर स्किल्स (कौशल) की कमी मुख्य बाधा होती है। डिप्लॉयमेंट पाइपलाइन के बारे में सिर्फ़ एक व्यक्ति को पता होता है। मार्केटिंग कैंपेन में, बाहरी इवेंट्स से जुड़ी तारीखें मुख्य बाधा हो सकती हैं। हेल्थकेयर ऑपरेशन्स शुरू करते समय, ट्रेनिंग का समय और शिफ्ट कवरेज जैसी उपलब्धता की बातें काम में रुकावट डाल सकती हैं, भले ही लोगों की संख्या (हेडकाउंट) सही लग रही हो। आपका काम बाधा की पहचान करना है, और फिर ऐसा समाधान चुनना है जो उस बाधा को दूर करे, न कि सिर्फ़ दबाव बढ़ाए।
जब तक आपको यह पता न हो कि आपके पास असल में क्या संसाधन हैं, तब तक आप उन्हें सही ढंग से मैनेज नहीं कर सकते। कैपेसिटी मॉडल हर रोल के लिए साप्ताहिक इस्तेमाल होने वाले घंटों का आपका स्पष्ट अनुमान होता है; इसमें से वह समय घटा दिया जाता है जो प्रोजेक्ट को आगे नहीं बढ़ाता। सामान्य घंटों से शुरुआत करें। PTO (छुट्टियां) और सरकारी छुट्टियों को घटाएं। तय मीटिंग्स और सेरेमनीज़ के समय को घटाएं। फिर फ़ोकस फ़ैक्टर लागू करें—यानी बचे हुए समय का वह प्रतिशत जो रुकावटों और तालमेल बिठाने के बावजूद असल में प्रोजेक्ट के काम पर लगाया जा सकता है। आखिर में, शेयर्ड सर्विसेज़ (जैसे प्रोडक्शन सपोर्ट) या ऐसी अंदरूनी रिक्वेस्ट्स का समय घटाएं जिन्हें आप नज़रअंदाज़ नहीं कर सकते।
स्प्रिंट कैपेसिटी प्लान का ड्राफ़्ट बनाने के लिए बिल्डर का इस्तेमाल करें, जिसमें हर रोल के लिए PTO और मीटिंग्स का समय शामिल हो।