- अगर development team के बाहर से बिना किसी नए तथ्य के estimate कम करने का दबाव आता है, तो estimation बातचीत में बदली जा सकने वाली चीज़ जैसा हो जाता है, जिससे भरोसा और agile planning की गुणवत्ता दोनों खराब होते हैं
- वास्तविक काम की मात्रा को development team आम तौर पर अपनी मर्ज़ी से कम नहीं कर सकती; team team velocity, पूरी हो चुकी stories के data और मौजूदा throughput के आधार पर expected effort का अनुमान लगाती है
- कम estimate को पूरा करने के लिए process छोड़ना या quality घटाना फिलहाल schedule को छोटा दिखा सकता है, लेकिन बाद में यह बड़े cost के रूप में लौटने की संभावना रखता है
- ज़्यादा productive बातचीत “estimate कम रखो” नहीं, बल्कि budget, समय लेने वाले हिस्से, बड़े unknowns, alternatives, story splitting और early validation को साथ में देखना है
- fixed feature scope में सिर्फ numbers घटाने से customer को delivery timing को लेकर गलत expectations मिलती हैं; इसलिए high-effort, low-value features हटाने पर चर्चा ज़रूरी है
बिना नए तथ्यों के estimate पर दबाव से पैदा होने वाली विकृति
- development team के बाहर के stakeholders, जिनके पास technical knowledge या codebase की समझ सीमित होती है, अक्सर “नहीं, इसके लिए उससे कम मेहनत चाहिए” कहते हुए estimate कम करवाने की कोशिश करते हैं
- ऊपर से यह “बेहतर estimate” मांगने जैसा दिखता है, लेकिन असल में अक्सर वे कम estimate चाहते हैं
- estimate को negotiate किए जा सकने वाले number की तरह लेने पर stakeholders और development team दोनों एक ऐसे समझौते पर पहुंचते हैं जिससे कोई संतुष्ट नहीं होता, और business को customers तक software कब deliver हो पाएगा, इस बारे में खराब expectations बनती हैं
- संबंधित quote source के रूप में Is tasking developers with creating detailed estimates a waste of money? लिंक किया गया है
Estimation control नहीं, prediction के ज्यादा करीब है
- estimate पर सवाल उठाए जा सकने की स्थितियां होती हैं
- जब development team के भीतर story पर चर्चा हो रही हो
- जब वास्तविक काम की मात्रा को प्रभावित करने वाला नया तथ्य हो
- implementation details न समझने वाला या नई जानकारी न देने वाला बाहरी stakeholder अगर कम estimate मांगता है, तो यह meteorologist से यह कहने जैसा है कि “कल का forecast गलत है और मौसम बेहतर होगा”
- meteorologist मौसम को control नहीं करता; वह knowledge और observation data के आधार पर forecast करता है
- development team भी वास्तविक काम की मात्रा को लगभग control नहीं कर पाती, और knowledge व data के आधार पर expected effort का अनुमान लगाती है
Development team क्या control कर सकती है और क्या नहीं
- development team स्थापित team velocity, पूरी हो चुकी stories के review data, और हर sprint में बेहतर होते process का इस्तेमाल करके estimate लगाती है
- काम की मात्रा घटाने के लिए कुछ process छोड़कर low-quality software deliver किया जा सकता है
- यह recommended तरीका नहीं है
- बाद में अक्सर इसकी बड़ी cost चुकानी पड़ती है
- team के पास speed improve करने की गुंजाइश हो सकती है, लेकिन estimation के समय expected future throughput नहीं, बल्कि current throughput को आधार बनाना चाहिए
- अगर company में “बस ज्यादा देर काम कर लो” जैसी बातचीत होती है, तो ऐसा environment लगभग disaster का recipe है
- संबंधित experience examples के रूप में Reddit के 3 comments लिंक किए गए हैं:
Numbers काटने के बजाय किस बातचीत की ज़रूरत है
- software development जटिल है, और अक्सर लोगों की सोच से ज्यादा समय लेता है
- अगर stakeholder को लगता है कि वे केवल एक तय रकम तक ही खर्च कर सकते हैं, तो estimate कम करने के बजाय इन बातों पर चर्चा करनी चाहिए
- इस story पर कितना खर्च किया जा सकता है
- story का कौन-सा हिस्सा सबसे ज्यादा समय लेता है
- सबसे बड़े unknowns कहां हैं
- ज्यादा समय लेने वाले हिस्सों और unknowns से निपटने के alternatives क्या हैं
- validation और delivery के तरीके बदलने के विकल्प भी साथ में देखने चाहिए
- story को काटकर कई हिस्सों में deliver करना
- हर हिस्से को जितना जल्दी हो सके validate करना
- संभव हो तो prototype से validate करना
- खास तौर पर जिन features में बहुत effort चाहिए लेकिन value सबसे कम है, उन्हें story से बाहर करने का तरीका खोजना चाहिए
Schedule वाले सवाल को ज्यादा उपयोगी बनाना
- estimate कम करने वाले सवालों से ज्यादा productive वे सवाल हैं जो features और schedule·scope के बीच संबंध को स्पष्ट करते हैं
- अलग article में जिन सवालों पर चर्चा की जाएगी, वे ये हैं
- Feature A कब deliver किया जा सकता है
- अगली quarter के अंत से पहले क्या deliver किया जा सकता है
- क्या Feature A को अगली quarter के अंत से पहले deliver किया जा सकता है
- लिंक किया गया article: converting story points to hours
2 टिप्पणियां
लेख के मूल शीर्षक को deepl से अनुवाद करें तो यह ऐसा आता है:
क्या कोई ऐसा है जो कहता है, 'नहीं, उससे कम मेहनत लगती है!'?
Hacker News की राय
“सेल्सपर्सन पर sales/quota बढ़ाने का दबाव डालना किसी मौसम वैज्ञानिक से धूप की मांग करने जैसा है” वाली उपमा इस संदर्भ में इतनी अनुचित नहीं लगती।
असल में यह एक ही काम को ज़्यादा जल्दी खत्म करने के लिए ज़्यादा प्रभावी ढंग से काम करो कहने के करीब है।
अगर सेल्सपर्सन से कहा जाए कि quota वे खुद तय करें, तो deal close होने में बहुत जटिलता और अनिश्चितता होने के कारण वे ऐसा नंबर चुनेंगे जिसे हासिल करना सुरक्षित लगे, ताकि वे असफल न दिखें।
लेकिन वह नंबर बिज़नेस की ज़रूरत से कम हो सकता है, इसलिए उनसे थोड़ा ज़ोर लगाकर भी पूरा करवाने के लिए उससे ऊँचा quota दिया जाता है।
खासकर जब इनाम उस नंबर को हासिल करने से सीधे जुड़ा हो, तब यह और भी महत्वपूर्ण हो जाता है।
फिर भी सेल्सपर्सन लगातार यह नहीं लिखते रहते कि “खुद तय किया गया quota पवित्र है, उसे सिर्फ सेल्सपर्सन ही तय करें, और उससे ऊँची performance माँगने वाला management अज्ञानी है।”
अगर सेल्स टीम किसी खास deal के बारे में कहे, “close होने की संभावना 70% है, annual recurring revenue लगभग 5 million dollars है,” और management जवाब दे, “क्या इसे 80% और 7 million dollars बनाया जा सकता है?” तो वह ज़्यादा नज़दीकी उपमा होगी।
close होने की संभावना बढ़ाते हुए price भी बढ़ाना संभव हो सकता है, लेकिन जैसे किसी feature को आधे समय में पूरा करना हो, वैसे ही कहीं न कहीं बड़ा बदलाव या समझौता चाहिए होगा।
बस estimate को wishful target में बदलने के बजाय, estimate से पहले खत्म करना कहीं बेहतर है।
सबसे अच्छा तरीका है priority और dependencies को ध्यान में रखकर काम को लाइन में लगाना, development के लिए तैयार stories का पर्याप्त भंडार रखना, और ज़रूरत पड़ने पर लंबे समय में टीम की क्षमता असंतुलित होने की कीमत स्वीकार करके tickets को रणनीतिक रूप से assign करना।
अगर समय का दबाव हो, तो हर feature से “अच्छा होगा अगर हो” वाली चीज़ें हटानी चाहिए या backlog के नीचे भेजनी चाहिए, और दूसरी टीमों या external expert consultation पर सख्त time limit लगानी चाहिए।
बेकार की meetings और interruptions हटानी चाहिए, developers को meetings मना करने या calendar block करने की छूट होनी चाहिए, और refactoring का मानदंड इतना ऊँचा रखना चाहिए कि deadline से पहले उसका cost-benefit साफ़ हो; यानी भविष्य से उधार लेने जैसी सोच से काम करना चाहिए।
लेकिन बहुत सावधानी रखनी चाहिए कि यह तरीका standard working style न बन जाए।
अगर आप leads में से 10% convert कर सकते हैं, तो 4 deals की जगह 5 deals convert करने के लिए लगभग 10 और लोगों को call करना होगा।
software के साथ बेहतर तुलना यह होगी कि आप एक नई तरह की building बना रहे हों, जैसे geodesic dome house, जबकि न आपके पास अनुभव हो और न ही आपको ठीक से पता हो कि किन समस्याओं का सामना करना पड़ेगा।
फिर आपसे सटीक estimate माँगा जाए, और उसके बाद उसे और कम करने का दबाव डाला जाए।
सबसे महत्वपूर्ण बात है customer को mislead करना, और यह सिर्फ “कंपनी के लिए अच्छा सामान्य exaggeration” बोलने की बात नहीं है।
इसमें ऐसे वादे करना शामिल है जिन्हें कंपनी निभा नहीं सकती, या future features बेच देना, या quality और sustainability की कीमत पर death march जैसी मांग करना।
भले ही C-level को यह दिखाई न दे, नतीजे फिर भी सामने आते हैं।
इसका मतलब यह नहीं कि developers के estimates पर बिना शर्त भरोसा किया जाए, लेकिन वह इससे भी बड़ा rabbit hole है, और अभी उसमें उतरने की ऊर्जा नहीं है।
इससे बस schedule की समझ और ज़्यादा अवास्तविक हो जाती है।
उसी समस्या के दूसरे creative solutions ढूँढना, या यह समझना कि target पूरा करने के लिए scope कहाँ घटाया जा सकता है, पूरी तरह संभव है।
लेकिन यह “ठीक वही काम बस और जल्दी करो” कहने से पूरी तरह अलग बात है।
जब estimation की बात आती है, तो developers अक्सर business के नज़रिए से सोचने की कोशिश ही नहीं करते, न यह समझने की कि estimation की ज़रूरत क्यों है और छोटा estimate लंबा estimate से हमेशा बेहतर क्यों माना जाता है
इसके बजाय वे software development के पवित्र क्षेत्र की रक्षा करने लगते हैं और engineers और “बाकी लोगों” के बीच का फ़ासला और बढ़ा देते हैं
इसी दौरान निंदकपन और व्यंग्य झलकने लगता है, और अंत में अवास्तविक estimates बनते हैं
मैं developer, PO, manager, director, और CTO तक रह चुका हूँ, फिर भी यह बात अब तक हैरान करती है कि ज़्यादातर developers value delivery और time factor जैसी वास्तविकताओं से कितने कटे हुए हैं
developer के रूप में आपसे यह पूछा जाना कि कितना समय लगेगा, और आपको समझाने, बहस करने, तथा अपने estimate का बचाव करने का मौका मिलना, उल्टा एक तरह की किस्मत ही है
दुखद सच्चाई यह है कि developers अक्सर business-level बातचीत में शामिल होने, PMs और managers को काम की complexity दिखाने, और एक स्वस्थ cost/benefit discussion के लिए अपने विचार, आइडिया, चिंताएँ और सुझाव रखने में कमजोर होते हैं
देखना चाहिए कि lead developer business meetings में शामिल होता है या नहीं, क्या development team numbers और budgets देखती है, roadmap में साथ भाग लेती है, और user research व feature brainstorming business/UX लोगों के साथ मिलकर करती है या नहीं
अगर ऐसा नहीं है, तो developers से business को समझने की उम्मीद करना मुश्किल है
development/business का अलगाव हर पक्ष को अपने-अपने silo में बंद कर देता है, जहाँ हर कोई उम्मीद करता है कि दूसरा विशेषज्ञ उसकी समस्या अच्छी तरह समझेगा, और यही software development को पवित्र क्षेत्र बना देता है
बहुत-सी companies बस अत्यधिक siloed roles के बावजूद किसी तरह चल रही हैं, और क्योंकि पैसा आता रहता है, उन्हें भ्रम हो जाता है कि यह तरीका ठीक है
आम तौर पर बस कोई व्यक्ति organizational politics वाली PowerPoint में कोई संख्या डालना चाहता है
कभी-कभी बात A करना है या B, यह तय करने की होती है, और उस स्थिति में असली estimation नहीं बल्कि केवल relative estimation की वैध ज़रूरत होती है
कभी सचमुच कोई deadline होती है, लेकिन तब भी ज़रूरत estimation की नहीं, बल्कि इस सवाल की होती है: “क्या हम यह तारीख़ पकड़ सकते हैं?” या उससे भी अधिक उपयोगी: “उस तारीख़ तक पहुँचने के लिए हमें क्या करना होगा?”
business के जितना संभव हो उतना करीब काम करना अच्छी बात है, और software का इस्तेमाल भी आम तौर पर किसी business need को हल करने के लिए ही किया जाता है
लेकिन estimation के मामले में सच में कई बार वे ग़लत होते हैं और हम सही
अगर छोटा हमेशा बेहतर है, तो फिर अब से हर estimate 1 दिन कह देना चाहिए; क्या वह बेहतर होगा?
अगर कोई developer code लिख सकता है, estimation कर सकता है, और business schedule के हिसाब से delivery भी कर सकता है, तो वह कर्मचारी नहीं बल्कि founder है
उन्हें ऐसे भोले लोग चाहिए जो founder की तरह deliver करें लेकिन profit share न लें
आप या मैं चाहे जितनी भी मेहनत कर लें, बच्चा उससे जल्दी पैदा नहीं होगा
इसमें कोई अस्पष्टता नहीं है
असली शिकायत उस तरह के सवाल से है जिसमें developers से ऐसे पूछा जाता है मानो वे completion time जान सकते हों
किसी व्यक्ति की तेजी से value deliver करने की क्षमता और समय का estimate लगाने की क्षमता दो अलग चीज़ें हैं
कोई estimate पूरी तरह ग़लत होने पर भी बहुत बड़ी value deliver की जा सकती है
अगर software work time estimate करने का सचमुच कोई तरीका होता, तो companies product teams की तरह professional estimators भी रखतीं
developers से यह काम कराने की कोई वजह नहीं होती
बेशक दूसरे लोग भी यह नहीं कर पाते, और developers कम से कम lower bound तो बता देते हैं, इसलिए उन्हें परेशान करना जारी रहता है, लेकिन पूरी प्रक्रिया साफ़ तौर पर मूर्खतापूर्ण है
यह जानने के लिए कि किसी काम में कितना समय लगेगा, उस काम के हर step को सूचीबद्ध करना पड़ता है, लेकिन software development में यह असंभव है
developers दिए गए requirements पर एक lower bound दे सकते हैं, और अगर कोई unexpected चीज़ बिल्कुल न हो तो शायद सटीक estimate भी दे सकते हैं, लेकिन 95~98% projects में estimate असलियत से छोटा निकलता है
आख़िरकार “developer estimate” इस बात का माप बन जाता है कि इस project में developer कितना buffer जोड़ना चाहता है
estimate माँगना बातचीत का frame ही पूरी तरह ग़लत तय कर देता है
असली सवाल यह होना चाहिए कि business के सामने अभी कौन-सी समस्या है, 6 महीने बाद कौन-सी समस्या उभर सकती है, और उस समस्या को हल करने का cost versus effect क्या होगा—इन सब पर developer का input क्या है
उसके बाद risk कम करने की दिशा में qualitative decisions लेनी चाहिए
software estimation का सबसे अच्छा नतीजा यह है कि सब लोग उसे नज़रअंदाज़ करके भूल जाएँ, और बाकी लगभग हर नतीजा business value को नष्ट करता है
बात समझ में आती है, और गैर-जिम्मेदार लोगों वाली संस्था में वास्तविक जोखिम भी बड़ा होता है
लेकिन मौसम विज्ञानी वाली उपमा खास अच्छी नहीं है
मौसम विज्ञानी का मुख्य काम मौसम का पूर्वानुमान लगाना होता है, लेकिन सामान्य developer उस मौसम के भीतर काम करने वाला व्यक्ति होता है और सटीक पूर्वानुमान लगाने का अनुभव उसके पास अपेक्षाकृत कम होता है
stakeholder के रूप में सबसे निराशाजनक बात वे बेहूदा estimates हैं जो न तो काम में लगने वाले समय से शुरू होते हैं और न ही किसी यथार्थवादी समयसीमा पर खत्म होते हैं
खासकर micro-task स्तर पर यह और भी ज़्यादा सच है, और कभी-कभी ऐसा होता है कि अगर access हो तो मैं खुद सीधे इससे तेज़ कर सकूँ ऐसे अधिकतम 30 मिनट के काम के लिए कई हफ्तों का estimate वापस आता है
यहाँ तक कि जब उससे operations पर गंभीर लागत पड़ रही हो और मामला “सब कुछ रोककर इसे संभालना होगा” वाली श्रेणी में आता हो, तब भी ऐसा होता है
बेशक 30 मिनट का काम testing और documentation की वजह से सचमुच सिर्फ 30 मिनट में पूरा नहीं होगा, लेकिन जितना estimate हक़ीक़त से कटा हुआ होगा, भरोसे का रिश्ता उतना ही ज़्यादा टूटेगा
क्या आप किसी खास काम के लिए लगने वाला वास्तविक कार्य समय पूछ रहे हैं, या अभी से deploy होने के क्षण तक का कुल बीता समय पूछ रहे हैं—यह अलग बात है
लगभग हर team में, दोनों ही मामलों में काम पर किसी न किसी चीज़ का इंतज़ार हावी रहता है, लेकिन दूसरे मामले में यह खास तौर पर ज़्यादा होता है
वास्तव में keyboard पर टाइप करने में लगने वाला समय आम तौर पर coordination और scheduling के मुकाबले rounding error जैसा होता है
अगर team ने सहज बुद्धि के विरुद्ध काम करने के तरीकों को लेकर खास मेहनत नहीं की है, तो औसत ticket वास्तविक काम से कहीं ज़्यादा समय इंतज़ार में बिताता है
ऊपर से team को यह असंतुलन दिखता भी नहीं, और यह भी समझ नहीं आता कि यह महत्वपूर्ण है
मन करता है जल्दी से ठीक करके आगे बढ़ा दिया जाए
समस्या यह है कि पूरी तरह automated continuous deployment न हो, तो 30 मिनट वास्तव में 30 मिनट नहीं होते
उस 30 मिनट के काम की समीक्षा करनी पड़ती है कि उसका असर दूसरे विभागों पर तो नहीं पड़ेगा, scheduling, announcement और deployment करना पड़ता है, और 2~3 लोग और भी इसमें जुड़ सकते हैं
अगर वह scheduled काम है, तो कई लोगों में बंटकर यह लगभग 2 घंटे तक जा सकता है, और अगर hotfix या support ticket है, तो automated tests से आगे QA process होने पर productivity loss 4~6 घंटे का हो जाता है
इसके ऊपर अगर 6 और लोग ऐसे “30 मिनट के काम” माँगते रहें जिनका कंपनी के दूसरे लोगों पर क्या असर होगा यह स्पष्ट न हो, तो फिर कुछ भी पूरा नहीं हो पाता
हमारी team में hotfix flow है, लेकिन वह सचमुच ऐसी emergency के लिए होना चाहिए जहाँ कंपनी का संचालन ठप हो रहा हो
बिल्कुल साफ़ मामलों को छोड़कर, ऐसी request विभाग प्रमुख या उससे ऊपर के स्तर से आनी चाहिए
हर urgent ticket को तुरंत न संभाल पाने से जो नुकसान होता है, उससे कहीं बड़ा नुकसान तब होता है जब एक व्यक्ति के लिए किया गया fix कई लोगों के लिए समस्या बन जाए या रणनीतिक रूप से महत्वपूर्ण बड़े project पूरे न हो पाएं
संस्था में ज़रूरी access देने का कोई तरीका होना चाहिए
अगर जवाब कुछ ऐसा है कि “यह मेरा काम नहीं है”, तो वह संस्था सख़्त ज़िम्मेदारियों वाले आपस में जुड़े हिस्सों को महत्व देने वाली संरचना है
ऐसी संस्था में communication cost का output performance पर पूरी तरह हावी होना स्वाभाविक है
अगर अच्छा coordination हो, तो quality अच्छी हो सकती है, और roles साफ़ हों, तो throughput भी ऊँचा हो सकता है, लेकिन low latency कभी नहीं मिलेगी
क्योंकि response time को दूसरी चीज़ों के लिए sacrifice किया जाता है
ऐसे ढाँचे में छोटे-मोटे काम के लिए 1 हफ्ते का estimate आना भी अनुमानित बात है
schedule पहले से भरा हो, तो नया काम शायद कई हफ्तों बाद ही assign हो, और अगर बँटी हुई ज़िम्मेदारियों की वजह से दो या उससे ज़्यादा लोग चाहिए हों, तो waiting time लगातार जुड़ता जाता है
अगर यह आपके काम के अनुकूल नहीं है, तो संस्था ही उस काम के अनुकूल नहीं है
यह जुड़े हुए सभी लोगों के लिए inefficent है
हमारी team काफ़ी autonomous है, हम समय नहीं गिनते और न ही बाहर से productivity को इस तरह देखते हैं, लेकिन जब ज़रूरत पड़ती है तो code को सँवारने का समय नहीं होता
जब कोई “30 मिनट” का काम दिखता है, तो हम उसे सुबह की review में रखते हैं और पूछते हैं कि जब इस विषय को छेड़ेंगे तो क्या आसपास की चीज़ें भी साथ में करनी चाहिए
अगर कुछ न भी हो, तो हम एक दिन रखते हैं, और अगर project बहुत अच्छी तरह जाना-पहचाना हो, तो आधा दिन
आधा दिन code को खंगालने में जाता है, और बाकी आधा दिन छोटे comments, version upgrades, code improvements, variable name changes जैसी updates में
मेरा मानना है कि individual contributor को भी ऐसा करने के लिए प्रोत्साहित करना समय की दृष्टि से अधिक efficient है
नए individual contributors उस समय का इस्तेमाल पुराने code को सीखने में कर सकते हैं, और अंततः बड़े बदलाव किए बिना भी legacy issues कम होते हैं
software development में एकमात्र जादुई छड़ी requirements simplification है
requirements हमेशा गलत होती हैं
वे या तो बहुत व्यापक होती हैं, या बहुत अस्पष्ट, या गलत धारणाओं पर आधारित
सचमुच असाधारण क्षमता यह है कि कुछ धारणाओं को छोड़कर एक सरल समाधान प्रस्तावित किया जाए
schedule घटाने का यही सबसे अच्छा और एकमात्र तरीका है
requirements सरल हों तो उनका अधिक complete और accurate होना आसान होता है, लेकिन हो सकता है कि वास्तविक requirements को सरल बनाया ही न जा सके
उस स्थिति में ज़रूरत बेहतर specification की होती है
shuttle software group पर लिखी “They write the right stuff” मूलतः ऐसी ही चीज़ करने की कहानी है: https://www.fastcompany.com/28121/they-write-right-stuff
ज़्यादातर software bugs असल में requirements bugs होते हैं, और जब requirements अच्छी हों तो software बनाना अविश्वसनीय रूप से तेज़ हो जाता है
मैंने ऐसे project देखे हैं जो बिल्कुल खाली repository से शुरू होकर पूरी तरह स्पष्ट और न बदलने वाली requirements के साथ 2 महीने में production deploy तक पहुँच गए
दूसरी ओर, अस्पष्ट और लगातार बदलती requirements की वजह से लगभग 30 lines वाले feature implementation को महीनों तक लटकते भी देखा है
अभी items केवल कुछ दर्जन हैं, लेकिन कहा जाता है कि कुछ साल बाद वे हज़ारों हो जाएँगे
designer 20-page product requirements document के आधार पर सारे search flows design करता है, और सारी planning तथा तैयारी पूरी होने के बाद ही engineering को बुलाया जाता है ताकि story लिखी जाए और काम का estimate किया जाए
आम तौर पर उनके पास पर्याप्त domain knowledge होती है, और वे जानते हैं कि इस context में कुछ बनाने के लिए क्या-क्या चाहिए
हितधारकों के हिसाब से सही cost/revenue balance के लिए scope को कैसे बदला जाए, इस पर चर्चा करना उपयोगी हो सकता है
मैंने ऐसे मामले भी देखे हैं जहाँ developer मान लेते हैं कि बहुत ज़्यादा काम लगेगा, और ऐसे भी जहाँ non-developer उन मुख्य हिस्सों को नज़रअंदाज़ कर देते हैं जो समय बढ़ा देते हैं
कभी-कभी लोग एक generalized solution बनाना चाहते हैं, जबकि वास्तव में ज़रूरत सिर्फ इतनी हो सकती है कि कोई एक व्यक्ति एक दिन spreadsheet पर बैठकर काम निपटा दे
अक्सर estimates के बहुत ज़्यादा होने पर सवाल उठते हैं, लेकिन बहुत कम होने पर लगभग कभी नहीं; planning poker इसी समस्या को address करने की कोशिश करता है
विचार यह है कि सब लोग एक-दूसरे से प्रभावित हुए बिना काम की कठिनाई बताएं, और अगर उम्मीदें मेल न खाएँ तो फिर चर्चा करें
काफ़ी संभावना है कि कोई न कोई कुछ मिस कर रहा हो
मैं किसी चीज़ को simple क्यों मान रहा हूँ, इसका कारण यह भी हो सकता है कि मैं समस्या के जटिल हिस्से को मिस कर रहा हूँ, या मुझे कोई अधिक साफ़-सुथरा solution दिख रहा है
इसका अच्छा उदाहरण है जब ग्राहक ऐसी माँग करते हैं जो गणितीय या भौतिक रूप से असंभव हो
ऐसी इच्छा पर आप दिन भर planning poker खेल लें, फिर भी नतीजा एक असंभव समझौता ही हो सकता है
जब मैं freelancer था, तो मैं पहले समस्या का बहुत विस्तार से वर्णन सुनना पसंद करता था, ज़रूरत पड़े तो जो व्यक्ति अभी यह समस्या संभाल रहा है उसे काम करते हुए देखता था, फिर कुछ दिनों के लिए ग़ायब होकर वह design लेकर लौटता था जो मुझे सबसे elegant और reliable लगता था
अगर किसी के पास जटिल समस्याओं का बहुत अनुभव न हो, तो ज़्यादातर लोग अपनी समस्या समझाने तक तो ठीक रहते हैं, लेकिन solution सुझाने में नहीं
क्योंकि solution हमेशा उन्हीं सीमित चीज़ों को model बनाकर सोचा जाता है जिन्हें वे पहले से जानते हैं
मैंने बहुत बार ऐसे अजीब requirements देखे हैं जो वास्तव में किसी ने माँगे ही नहीं थे, बल्कि कई लोगों की assumptions जुड़ते-जुड़ते बन गए थे
उदाहरण के लिए, सिर्फ बारह internal users को data Excel spreadsheet में export करने देना है, लेकिन उसके लिए infinitely scalable microservice architecture और पूरी single-page app बना दी जाती है
इसके लिए यह मान लेना पड़ता है कि team पूरे feature set से काफ़ी परिचित है, और यह भी समझती है कि A किसी चीज़ को X में करेगा और B उसी चीज़ को X*3 में—इस अपरिहार्य अंतर से निपटने वाली system को कैसे इस्तेमाल करना है
Scrum के ख़राब तरीके से चलाए जाने पर होने वाली चर्चाएँ ही दिखा देती हैं कि ये मान्यताएँ बिल्कुल भी guaranteed नहीं हैं
यह बात भी नज़रअंदाज़ होती है कि job change और नई features की वजह से team कभी भी इन मान्यताओं से बाहर हो सकती है
बहुत बार बस लोग भौंहें चढ़ाकर एक-दूसरे को देखते हैं, फिर कह दिया जाता है कि “X करेगा, तो X का estimate ही मान लो”, या average/minimum चुन लिया जाता है और जिसने ज़्यादा estimate दिया वही नुकसान में रहता है
अगर ऐसा ही होना है, तो फिर poker शुरू ही क्यों किया जाए, समझ नहीं आता
यह उससे भी ज़्यादा Machiavellian है
बीच का व्यक्ति ऐसा सौदा चाहता है जिसमें heads आए तो मैं जीतूँ और tails आए तो तुम हारो
वह अपनी तरफ़ के लोगों को मनाने के लिए कम number दिखाकर फ़ायदा लेना चाहता है
इसलिए वह developer से मनचाहा number कहलवाने के लिए हर तरह की तकनीक अपनाता है, लेकिन ऐसा नहीं दिखाना चाहता कि वह आदेश दे रहा है या दबाव बना रहा है
क्योंकि अगर वैसा लगा, तो वह number उसी का number बन जाएगा और पूरा खेल बिगड़ जाएगा
लेकिन जब काम अनिवार्य रूप से बहुत ज़्यादा समय लेता है, तो वह developer के दिए हुए number की ओर इशारा करके कह सकता है कि उसने तो सिर्फ वही बताया जो उसे कहा गया था, इसलिए ज़िम्मेदारी उसकी नहीं
ऐसे लोगों की समझ में आने वाली एकमात्र भाषा यह है कि estimate “review” माँगे जाने का नतीजा हमेशा number बढ़ना चाहिए—तभी संदेश जाएगा
पहली बात, estimate का उपयोग business को adapt करने में मदद करने के लिए होना चाहिए, लेकिन व्यवहार में कोई adaptation होती ही नहीं
PM पर उसके boss का दबाव होता है कि एक मोटा-मोटी deadline तक काम पूरा हो
अगर वैसे भी मेरे estimate की परवाह नहीं होनी, तो फिर estimate क्यों किया जाए?
दूसरी बात, team के पास realistically estimate करने की कोई incentive नहीं होती
क्या सही estimate देने पर कोई medal मिलता है? असल में तो सारे incentives estimate के ज़रिए काम का बोझ बढ़ाकर दिखाने की तरफ़ जाते हैं
तीसरी बात, estimation का यह पूरा dance और ritual बस इसीलिए अपनाया जाता है ताकि manager असलियत से ज़्यादा प्रभावी और असरदार दिख सकें
जब मैं engineer होता हूँ, तो मैं साफ़ कहता हूँ: “इसे इससे तेज़ करने का कोई तरीका नहीं है, इसलिए मनचाहा number पाने के लिए दबाव मत डालो”
जब होगा तब होगा, और मैं इसे मज़बूत और अच्छे ढंग से बनाऊँगा, इसलिए बीच में दखल मत दो
लेकिन manager के रूप में जब मैंने छोटे estimate के लिए दबाव डाला, तो उसकी वजह business reality थी कि तय समय के भीतर कुछ न कुछ ship करना बेहद ज़रूरी था
चाहे ताश के पत्तों का घर ही क्यों न खड़ा करना पड़े और कोनों को काटना पड़े, कम-से-कम इतना तो ज़िंदा रहना था कि बाद में उस समस्या से निपटा जा सके
तब engineering की तरफ़ से वही विरोध आया जो शायद मैं खुद उस स्थिति में होता तो करता
कि यह एक भयानक विचार है, यह भविष्य में विफलता लाएगा, और बाद का दर्द टालना है तो अभी मेहनत करनी होगी
अब मैं फिर से engineer हूँ, लेकिन manager के रूप में मिले अनुभव की वजह से ऐसे gap को संभालने में काफ़ी मदद मिलती है
ये वही लोग हैं जो “11 तक जाते हैं”
Spinal Tap के amp की तरह, अगर आप सामान्य maximum output को 9 पर सेट रखें, तो जब उन्हें चाहिए होगा तब एक notch और ऊपर जाने की गुंजाइश रहेगी
हाँ, इसका मतलब यह भी है कि आप पहले से धीमे काम करेंगे
लेकिन अगर आपको “11 तक जाने वाला” developer चाहिए, तो साफ़ है कि उसके काम करने का यही एक तरीका है
मेरा manager और उसके ऊपर वाला manager भी ठीक ऐसे ही हैं: वे ग्राहक के इंतज़ार की वजह से नहीं, बल्कि अपने boss के सामने अच्छे दिखने के लिए मनमानी deadlines ठेलते हैं
जब estimate अनिवार्य रूप से विफल हो जाते हैं, तो सब हाथ खड़े कर देते हैं और अपनी ही ख़राब planning का बहाना बनाकर लोगों को performance improvement plan में डालना शुरू कर देते हैं
engineer के रूप में इस लगातार तनाव में जीकर, परिवार और दोस्तों के साथ बिताने वाला समय खोकर, आख़िर मिलता क्या है?
सिर्फ़ इतना कि किसी और के manager की अयोग्य estimation अच्छी दिखे
पुरानी चालों में से एक है vision बनाना, commitment कर देना, और फिर कहना, “मैंने अपना काम कर दिया, अब engineering अपना काम करे”
release को wrap up करते समय मुझे अक्सर वह manager याद आता है जो कभी-कभी बस कुछ घंटे पहले बिना बताए features जोड़ देता था
वह पहले से लगभग ख़त्म हो चुकी release में भी features ठूँस देता था
शायद उसके दिमाग़ में feature को release से जोड़ना ही उसे तुरंत पूरा कर देने जैसा लगता था
सबसे बड़ी मुश्किल यह है कि जब प्रोजेक्ट की सिर्फ़ एक पैराग्राफ़ की व्याख्या होती है, तब लोग तुरंत estimate माँगते हैं
ऊपर से हमेशा यह एहसास होता है कि “कोड देख लेने के बाद technical debt कितना है, उसी पर निर्भर करेगा”
अब तक मैंने जो एकमात्र वाजिब जवाब दिया है, वह यह था: “requirements को मज़बूती से तय करने के लिए आपको push करना होगा, और शुरू करने से पहले codebase को रोककर audit करने और risks ढूँढने के लिए 1~2 दिन चाहिए होंगे”
क्या यहाँ मैं इससे बेहतर कुछ कर सकता हूँ?
लक्ष्य perfect card बनाना नहीं है, बल्कि प्रोजेक्ट में जो भी काम करना पड़ सकता है, उनमें से हर एक के लिए कम-से-कम एक ticket बना देना है
फिर “bulk create API endpoint बनाना”, “existing table से new table में data migration” जैसी एक-पंक्ति वाली कई cards बन जाती हैं
अगर cards 5 से ज़्यादा हों, तो
((cards की संख्या / developers की संख्या) * प्रति card अनुमानित working days) + अनुमानित छुट्टियाँसे estimate करता हूँयह सटीक नहीं होगा, लेकिन PM और उसके बॉस को लगता है कि उस समय estimate सोच-समझकर और वाजिब तरीके से किया गया था
बाद में delay की ज़रूरत पड़े तो यह समझाना आसान होता है कि “हमने मान लिया था कि सभी cards में लगभग बराबर दिन लगेंगे, लेकिन ये दो cards उम्मीद से बड़े outlier निकले”
यह आमतौर पर sprint process जैसा ही है, लेकिन sprint velocity को मोटे अनुमान से track करने की ज़रूरत नहीं होती
कंपनी की leadership बहुत कम जानकारी की हालत में estimate माँगती है, और जब आप कहते हैं कि और जानकारी चाहिए और codebase देखना पड़ेगा, तो वे कहते हैं कि “बस” यह तय करने के लिए estimate चाहिए कि इस काम को approve करना है या नहीं और प्रोजेक्ट करना है या नहीं
इस तरह चक्कर काटते-काटते मैं बड़ा estimate दे देता हूँ, और वह बड़ा number इसलिए बनता है क्योंकि उसमें वे सारे unknowns शामिल होते हैं जिनका scope तक पता नहीं होता
फिर leadership को वह बहुत बड़ा और बहुत महँगा लगता है
Agile terminology में यह 3-point spike ticket है, और इसका deliverable होगा detailed requirements, deliverables, और estimates, साथ में सोचे-समझे trade-offs
यह बिल्कुल सामान्य तरीका है
spike से पहले आप estimate दे सकते हैं, लेकिन जितनी हो सके उतनी शर्तें जोड़नी चाहिए
उदाहरण के लिए, आप कह सकते हैं, “60% confidence पर 3 हफ्तों से कम, 80% confidence पर 5 हफ्ते, 90% confidence पर 6 हफ्ते”
आम तौर पर मैं 1~2 हफ्तों से आगे की deadline estimates देने से मना करता हूँ, और जितना संभव हो chunked estimates को तरजीह देता हूँ
जैसे, “यह प्रोजेक्ट 7 deliverables से बना है, जिनमें से हर एक में 1~2 दिन का engineering work लगेगा”
क्योंकि कोई काम engineering के 10 दिनों का हो सकता है, लेकिन priorities बदलने वगैरह की वजह से deadline calculation practically बेमानी हो जाती है
अगर “managers” यह नहीं समझते, तो अफ़सोस की बात है कि शांति से रहना मुश्किल होगा
code debt और quality की परवाह मत कीजिए, बस किसी तरह चलने लायक चीज़ को जल्दी से बाहर निकाल दीजिए
तब वे खुश हो जाएँगे
एक typical action movie hacking scene कुछ ऐसा होता है
लीडर: “mainframe hack करने में कितना समय लगेगा?”
टेक्नीशियन: “सामने वाला hacker बहुत ही कमाल का है, कम-से-कम 2 घंटे लगेंगे”
लीडर: “1 घंटा देता हूँ. करके दिखाओ”
उसके बाद 3D filesystem में उड़ान भरते रहते हैं
हर बार ऐसा scene देखते हुए मैं टेक्नीशियन के लिए मन ही मन narration जोड़ देता हूँ
“असल estimate 20 मिनट था. शायद 50 मिनट में ख़त्म कर लूँगा, और leader को कोई अजीब idea न आए इसलिए 10 मिनट और 3D filesystem में व्यस्त उड़ता रहूँगा”
यह पूरी तरह सही बात नहीं है
कई features बहुत bare-bones तरीके से लेकर पूरी तरह सोने का पानी चढ़ी हुई हालत तक कई स्तरों में बनाए जा सकते हैं
कभी-कभी कोई साथी developer जिस feature को मैं ज़्यादा से ज़्यादा एक दिन का मानता हूँ, उसे 2 हफ्ते estimate करता है, क्योंकि या तो वह कई ऐसे extra features मानकर चल रहा होता है जो वास्तव में माँगे ही नहीं गए, या उसे कुछ ऐसी ज़रूरतें पता होती हैं जिनके बारे में मुझे मालूम नहीं होता
अगर आपसे estimate बदलने को कहा जाए, तो इसे requirements और proposed implementation पर थोड़ा और चर्चा करने के निमंत्रण की तरह देखना चाहिए
हो सकता है 90% तक पहुँचने वाला कोई बहुत सरल समाधान उपलब्ध हो और स्वीकार्य भी हो
मौसम वैज्ञानिकों के पास ऐसा विकल्प नहीं होता
एक basic combo box/select box डाल देने और स्थिति के लिए कहीं बेहतर custom UI element बनाने के बीच का फ़र्क IT के बाहर के लोगों तक ठीक से नहीं पहुँचता
आप तस्वीरों से समझा सकते हैं, लेकिन stakeholders उसे देखकर या छूकर नहीं समझते, इसलिए उन्हें फिर भी पता नहीं चलता कि क्या होने वाला है
इसलिए आम तौर पर आपको उसे सच में बनाकर दिखाना पड़ता है
कुछ clients “जितना हो सके उतना simple बनाइए” कहते हैं, और फिर prototype GUI, finished design GUI, और उसके बाद prototype दिखाने पर पहले दो को देखे बिना ही approve कर देते हैं
दबाव डालने पर prototype चलाकर देखने के बाद भी “ठीक है, आगे बढ़ो” कह देते हैं, लेकिन test server पर सच में काम करती हुई चीज़ को छूने के बाद कहते हैं, “यह वह नहीं है जो हम कहना चाहते थे”
मैंने 2 लोगों की पति-पत्नी वाली दुकान से लेकर Fortune 500 कंपनियों तक, जहाँ regional director और global CTO दोनों राय देते हैं, सब देखा है
यह front-end की बात है, और backend व DevOps में तो बिल्कुल अलग समस्याएँ हैं, लेकिन वहाँ भी bare-bones बनाने और gold-plating करने के बीच का अंतर बहुत बड़ा है
अब मैं इस खेल को समझ चुका हूँ, इसलिए आजकल इस टूटी हुई process से काफ़ी पैसा कमा रहा हूँ
1975 में Fred Brooks ने लिखा था
“एक बच्चा पैदा करने में 9 महीने लगते हैं, चाहे आप कितनी भी महिलाएँ लगा दें”
इससे बेहतर अभिव्यक्ति नहीं है
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
हर बार जब आप एक और इंसान जोड़ते हैं, तो ज़्यादा समय लगता है
सबसे तेज़ delivery वही है जब एक solo developer को परेशान न किया जाए और बस उसे काम करने दिया जाए