सॉफ़्टवेयर काम का अनुमान कैसे लगाया जाता है
(seangoedecke.com)- सॉफ़्टवेयर प्रोजेक्ट की सटीक अवधि का अनुमान लगाना असंभव है, और ज़्यादातर काम अप्रत्याशित ‘अज्ञात काम’ से संचालित होते हैं
- अनुमान इंजीनियरों के लिए नहीं, बल्कि मैनेजमेंट के राजनीतिक टूल के रूप में इस्तेमाल होते हैं, जो प्रोजेक्ट की प्राथमिकता और फंड के आवंटन का फ़ैसला करते हैं
- व्यवहार में अनुमान ही काम को परिभाषित करता है, और टीमें दिए गए समय के भीतर संभव तकनीकी approach खोजने के तरीके से काम करती हैं
- प्रभावी अनुमान के लिए इंजीनियरों को राजनीतिक संदर्भ समझने, अज्ञात जोखिम का आकलन करने और कई execution scenarios पेश करने पर ध्यान देना चाहिए
- यह approach सटीकता से अधिक भरोसे और यथार्थवादी सहयोग को महत्व देता है, और संगठन के भीतर decision-making structure को समझने वाली engineering क्षमता पर ज़ोर देता है
सॉफ़्टवेयर अनुमान की मिथ्या धारणा
- इंडस्ट्री में यह ‘शिष्ट मिथक’ मौजूद है कि कुशल टीमें पर्याप्त मेहनत से सटीक टाइमलाइन का अनुमान लगा सकती हैं
- वास्तव में ज़्यादातर इंजीनियर यह मानते हैं कि सटीक अनुमान संभव नहीं है
- कुछ टीमें T-shirt sizing method से अनुमान लगाती हैं, लेकिन अंततः इसे समय की इकाइयों में बदलकर मैनेजमेंट तक भेजा जाता है
- “शुरुआती अनुमान को दोगुना करो और 20% जोड़ दो” जैसी अवास्तविक heuristics भी इस्तेमाल होती हैं
अनुमान लगाना असंभव क्यों है
- छोटे और स्पष्ट काम अनुमानित हो सकते हैं, लेकिन ज़्यादातर प्रोजेक्ट अनिश्चित और जटिल सिस्टम में किए जाते हैं
- उदाहरण: किसी साधारण लिंक टेक्स्ट को बदलना 45 मिनट में होने का अनुमान लगाया जा सकता है, लेकिन बड़े सिस्टम में बदलाव का नहीं
- ज़्यादातर प्रोग्रामिंग exploratory research activity की तरह होती है, जहाँ केवल पहले से की गई योजना से यह पता नहीं चल सकता कि कौन-कौन सा काम लगेगा
- अतीत का centralized architecture design approach असफल रहा, और फ़ैसले वही डेवलपर लें जो वास्तविक कोड से काम कर रहे हैं
- नतीजतन ज्ञात काम कुल का सिर्फ 10% होता है, बाकी 90% अज्ञात क्षेत्र होने के कारण अनुमानित नहीं किया जा सकता
अनुमान इंजीनियरों का नहीं, मैनेजमेंट का टूल है
- अनुमान का टीम की उत्पादकता बढ़ाने से कोई संबंध नहीं है, और कई प्रभावी टीमें बिना अनुमान के भी काम करती हैं
- मैनेजमेंट अक्सर मनचाहे नतीजों के अनुसार अनुमान को समायोजित करना चाहता है; लंबी टाइमलाइन पर उसे छोटा करने का दबाव आता है, छोटी टाइमलाइन पर buffer जोड़ने का
- सिर्फ तकनीकी रूप से असंभव प्रोजेक्ट ही अपवाद के तौर पर यथार्थवादी निर्णय ला सकते हैं
- संगठन के कम-रुचि वाले क्षेत्रों में औपचारिक प्रक्रियाएँ जैसे-की-तैसी बनी रह सकती हैं
- इसलिए अनुमान ग़ैर-इंजीनियरों द्वारा प्रोजेक्ट चुनने या रद्द करने के राजनीतिक साधन की तरह काम करता है
अनुमान ही काम को परिभाषित करता है
- आम धारणा के विपरीत, काम नहीं बल्कि अनुमान पहले तय होता है, और उसके अनुरूप तकनीकी approach चुना जाता है
- उदाहरण: “PDF से बातचीत” फ़ीचर को 6 महीने में बनाना और 1 दिन में बनाना — दोनों के approach पूरी तरह अलग होंगे
- समय की सीमा कोड डिज़ाइन की गहराई और गुणवत्ता तय करती है, और इंजीनियर दिए गए समय में संभव समाधान चुनते हैं
वास्तविक अनुमान प्रक्रिया
- पहले राजनीतिक संदर्भ को समझें, ताकि प्रोजेक्ट की अहमियत और अपेक्षित शेड्यूल का अंदाज़ा हो
- फिर पहले से तय समय-सीमा के आधार पर संभावित approaches तलाशें
- अज्ञात क्षेत्र (unknowns) जितने ज़्यादा होंगे, अनुमान उतना बड़ा होगा और approach का दायरा उतना सीमित करना पड़ेगा
- अंत में सटीक अवधि के बजाय जोखिम आकलन और कई execution scenarios पेश करें
- उदाहरण: सभी हिस्से खुद हल करना, कुछ को bypass करना, या दूसरी टीम से सहायता माँगना
- इंजीनियर की भूमिका “इसमें कितना समय लगेगा” नहीं, बल्कि “दिए गए समय में क्या संभव है” ढूँढना है
आपत्तियाँ और जवाब
- कुछ इंजीनियर अनिश्चित परिस्थितियों में अनुमान देने से बचते हैं, लेकिन इससे कोई ग़ैर-तकनीकी व्यक्ति उनकी जगह अनुमान लगाने लगता है
- मैनेजमेंट से सहयोग किए बिना हमेशा टकराव की मुद्रा रखना अलाभकारी है और भरोसा कम करता है
- जिन टीमों पर दबाव महसूस नहीं होता, वे संभवतः सिर्फ संगठन के कम-ध्यान वाले क्षेत्र में होती हैं
निष्कर्ष
- व्यवहार में मैनेजर पहले से ही एक टाइमलाइन मन में रखकर टीम के पास आते हैं, और टीम उसके भीतर संभव तकनीकी समाधान खोजती है
- अनुमान मैनेजमेंट के बीच negotiation tool है, और केवल असंभव प्रोजेक्ट ही अपवादस्वरूप वास्तविकता बताने का माध्यम बनते हैं
- सही अनुमान में सटीक संख्या नहीं, बल्कि जोखिम और विकल्पों की प्रस्तुति शामिल होनी चाहिए
- सॉफ़्टवेयर काम का सटीक अनुमान असंभव है, और सफल अनुमान इस बात पर निर्भर करता है कि अज्ञात जोखिमों को पहचाना और प्रबंधित किया जाए
2 टिप्पणियां
ओहो
Hacker News की राय
मैंने अपना थोड़ा मज़ाकिया project estimation rubric साझा किया
आंतरिक प्रोजेक्ट्स (जैसे vendor migration आदि, जिनका users पर असर नहीं होता) के लिए उतना समय तय किया जाता है जितना manager को समझाया जा सके
users पर असर डालने वाले प्रोजेक्ट्स (जैसे नई feature जोड़ना) को जब तक ROI positive रहे तब तक चलाया जाता है
बाहरी partners के साथ collaboration वाले प्रोजेक्ट्स में sales team deadline तय करती है, और engineering team उस schedule के हिसाब से MVP definition को थोड़ा adjust करती है
मुझे हैरानी थी कि कोई भी planning poker या story point की बात क्यों नहीं कर रहा
यह perfect नहीं है, लेकिन काफ़ी अच्छा तरीका है। हर काम sprint के भीतर पूरा होना चाहिए, और बड़ा हो तो उसे तोड़ना चाहिए
पूरी team को points पर सहमत होना चाहिए, और उसी प्रक्रिया में असल discussion की value पैदा होती है
कुछ महीनों बाद team की velocity stable हो जाती है, और लगभग ±10% accuracy के साथ prediction संभव हो जाता है
यह कोई जादू नहीं है, लेकिन लगातार value deliver करने और हर sprint में cost-benefit को फिर से देखने में मदद करता है
अभी-अभी शामिल हुआ व्यक्ति उसी ticket पर 2 गुना से भी ज़्यादा समय ले सकता है
ऊपर से organization ऐसे नियम बना देता है जैसे PR review 24 घंटे में खत्म होना चाहिए, जिससे ज़मीनी हक़ीक़त से दूरी पैदा होती है
developers और QA मिलकर complexity compare करते हुए estimate करते हैं, और QA test difficulty या automation की संभावना का आकलन करता है
इसकी वजह से development velocity metrics stable रहते हैं और version-by-version estimates भी काफ़ी accurate होते हैं
इसका मतलब तभी है जब पूरी team को minimum unit की common understanding हो और उसे time में convert किया जा सके
आखिर उस स्थिति में सीधे time का इस्तेमाल किया जा सकता है, इसलिए points खुद ही अनावश्यक हो जाते हैं
मैं “2 घंटे, 2 दिन, 2 हफ़्ते, 2 महीने, 2 साल” जैसी units में सवाल पूछकर confidence interval based estimation करता हूँ
अगर range बहुत चौड़ी हो तो उसे और तोड़ा जाता है, और अगर वह संभव न हो तो यह तय किया जाता है कि जानकारी जुटाने में समय लगाना worthwhile है या नहीं
नहीं तो प्रोजेक्ट छोड़ दिया जाता है
अगर result को साफ़ तौर पर define किया जाए और idea को detailed steps में बाँटा जाए, तो realistic estimate संभव हो जाता है
अगर उसे दिन या हफ़्ते के स्तर तक नहीं तोड़ा जा सकता, तो इसका मतलब है कि planning अभी अधूरी है
ऐसे मामलों में लगातार अलग-अलग approaches आज़माकर सीखना ही प्रक्रिया होती है, इसलिए मुझे लगता है estimation मुश्किल है
यह केवल duration का अंदाज़ा लगाने की बजाय action-oriented सोच को बढ़ावा देता है
पहले मैंने सिर्फ़ password को plaintext से hash में migrate करने वाले काम को एक sprint माना था, लेकिन असल में उसे 6 महीने लगे
यह तब पता चला जब एक customer ने वीडियो में दिखाया कि वे password case-sensitive मानकर नहीं, बल्कि बिना case distinction के इस्तेमाल कर रहे थे
ऊपर से PHP image delete हो गई, जिससे build failure भी हो गया
estimation हमेशा एक मज़ेदार adventure रहता है
यह असली project data के आधार पर budget overrun statistics दिखाती है
IT projects औसतन 73% overrun करते हैं, और nuclear waste storage, Olympics, और hydropower के बाद सबसे खराब श्रेणी में आते हैं
18% IT projects 50% से ज़्यादा overrun करते हैं, और उनका average overrun 447% होता है
अंत में यह दिखाता है कि ज़्यादातर industries में estimation संरचनात्मक रूप से optimistic होना लगभग तय है
यह दिलचस्प है कि इतने सारे engineers और managers पिछले projects के metrics के आधार पर estimate नहीं करते
team throughput data देखने पर मोटा-मोटी duration और confidence intervals (जैसे 90%, 70%, 50%) निकाले जा सकते हैं
इससे बाहरी stakeholders को भी probabilistic context दिया जा सकता है
लेकिन बहुत से engineers इसे administrative burden मानते हैं
अच्छी practice यह है कि range estimation का उपयोग किया जाए, जैसे PERT method में best, expected, और worst तीनों को model किया जाता है
सबसे अच्छे technologists में अपने time estimate को लेकर overconfidence की प्रवृत्ति होती है
हर व्यक्ति का estimate लेकर उसमें 20% correction जोड़ने का तरीका काफ़ी ठीक काम करता था
अगर management deadline थोप दे, तो उस समय-सीमा में क्या संभव है यह समझाना चाहिए, या clear scope के बाद re-estimation का सुझाव देना चाहिए
संदर्भ: PMI PMP, PMBOK का Lessons Learned Repository
prediction errors से सीखता है, लेकिन prescription उल्टा productivity pressure में बदल जाता है
मैं estimation को negotiation process के रूप में देखता हूँ
car trim की तरह Economy, Mid-tier, Luxury तीन options देता हूँ
business हमेशा तीसरे विकल्प वाली functionality और पहले विकल्प वाला budget चाहता है, इसलिए अंत में मुझे ही स्थिति के मुताबिक adjust करना पड़ता है
अगर #1 plan तैयार रखा जाए, तो crisis में जल्दी switch किया जा सकता है, और negotiation के दौरान shortcuts की कीमत को visualise किया जा सकता है
इसकी वजह से घबराए हुए PMs या executives के irrational decisions कई बार टाले जा सके
मैं FAANG स्तर के large-scale distributed systems पर काम करता हूँ, और यहाँ accurate estimation लगभग असंभव है
unknown-unknowns बहुत ज़्यादा होते हैं, और prototype भर के लिए भी भारी मात्रा में data और time चाहिए होता है
इसलिए estimation से ज़्यादा uncertainty management पर ध्यान दिया जाता है
सबसे भरोसेमंद तरीका similar projects के साथ comparison करना है
जैसे, “यह project X से 20% ज़्यादा complex है, इसलिए 20% ज़्यादा समय लगेगा”
लेकिन इसके लिए पुराने projects के actual effort data को लगातार record करना ज़रूरी है
शुरू में मैं “estimation असंभव है” वाले दावे से असहमत होना चाहता था, लेकिन बाद में समझ आया कि असल में organization के भीतर की role dynamics ज़्यादा महत्वपूर्ण हैं
भले ही team estimate के मुकाबले capacity देखकर कह दे कि यह संभव नहीं है, deadline नहीं बदलती
आखिरकार बात scope reduction या quality trade-off पर आ जाती है
इसलिए शायद “estimation बेकार है” कहना ज़्यादा सही हो
मुझे लगता है estimation का मूल ambiguity है
UI fine-tuning जैसे काम छोटे दिखते हैं, लेकिन असल में उनमें काम करते-करते सीखना शामिल होता है
दूसरी तरफ़, बड़ा बदलाव भी अगर साफ़ तौर पर defined हो तो जल्दी पूरा हो सकता है
LLM के दौर में बदलाव के आकार से ज़्यादा uncertainty की मात्रा ही समय तय करने वाला मुख्य factor बन सकती है