- Legacy software modernization में काम शुरू होने से पहले दिखने वाली जानकारी के आधार पर पूरे scope को तय करना मुश्किल होता है, इसलिए शुरुआती estimate को deadline नहीं बल्कि adjust किए जा सकने वाले baseline की तरह देखना चाहिए
- कार repair की तरह शुरुआत में $18,000·30 दिन जैसा estimate संभव है, लेकिन disassembly और inspection के बाद छिपा नुकसान सामने आए तो supplemental estimate और re-approval की जरूरत होती है
- Modernization projects में भी integration failure या unexpected behavior जैसी छिपी complexity सामने आती है, और ऐसे में original estimate में जबरन फिट करने की कोशिश reality से टकराती है
- स्वस्थ leadership “यह क्यों नहीं दिखा” पूछने के बजाय complexity, solution, trade-offs, workaround पूछती है और तय करती है कि आगे बढ़ना है या रोकना है
- Complex context में fixed rulebook के बजाय try, experiment और discovery के iterations की जरूरत होती है, और leader को excessive control के बजाय ऐसा environment बनाना चाहिए जहाँ patterns उभर सकें
Estimate deadline नहीं, progress baseline है
- Complex software modernization में estimate को fixed deadline की तरह treat करने पर असली काम के दौरान सामने आने वाली reality से टकराव होता है
- Initial estimate बाहर से दिखने वाली जानकारी और experience के आधार पर बनता है, लेकिन काम शुरू होने के बाद नई complexity सामने आ सकती है
- “Estimate” actual value का approximation है, और complex modernization में शुरू होने से पहले सभी outcomes को perfect तरीके से predict करना मुश्किल है
कार repair analogy: न दिखने वाला नुकसान और supplemental estimate
- कार repair में insurance adjuster पहले damage estimate repair shop को submit करता है, और repair shop भी अपना estimate insurance company को भेजती है
- उदाहरण के लिए insurance adjuster $15,000 का damage estimate करता है
- repair shop $18,000 damage और 30 दिन repair duration का estimate करती है
- Insurance adjuster और repair shop expert मिलकर damage evaluate करते हैं, और insurance company नया estimate approve करती है तो repair शुरू होता है
- Repair के दौरान ऐसा damage मिल सकता है जो शुरुआत में नहीं दिखा था
- Parts खोलते समय additional damage सामने आ सकता है
- Frame machine से unibody frame damage inspect किया जा सकता है
- यह भी check करना होता है कि impact point के अलावा effect frame के पीछे की तरफ तक गया है या नहीं
- Additional damage के कारण $20,000 और cost चाहिए तो repair shop supplemental repair request insurance company को भेजती है, और insurance company तय करती है कि repair जारी रखना है या total loss process करना है
- सिर्फ इसलिए कि original estimate $18,000 था, additional $20,000 को reject कर देना realistic repair process से मेल नहीं खाता
Legacy modernization में भी hidden complexity सामने आती है
- Legacy software modernization complex software domain में आता है
- बाहर से साफ दिखने वाली problems के आधार पर initial estimate बनाया जा सकता है, लेकिन actual work के दौरान और अधिक complexity सामने आती है
- जैसे कार repair में hidden damage या frame damage मिलता है, वैसे ही modernization में भी initial estimate में शामिल न रही problems पैदा हो सकती हैं
- ऐसी स्थिति में original estimate से बंधे रहने के बजाय additional approval और re-evaluation के जरिए next steps तय करने चाहिए
अच्छे leader के सवाल
- Healthy software development environment में problem सामने आने पर blame करने के बजाय decision के लिए जरूरी questions पूछे जाते हैं
- यह problem कितनी complex है
- इसके solution options क्या हैं
- हर option के trade-offs क्या हैं
- क्या workaround या alternative solution है
- इसके उलट, अगर बात “यह complexity क्यों नहीं दिखी”, “इतना समय क्यों लग रहा है”, “original estimated date क्यों नहीं रख पा रहे” की तरफ जाती है, तो team original estimated date से बंध जाती है
- Modernization projects में आगे बढ़ने और रोकने—दोनों तरह के cases होते हैं
- Supplemental cost approve हो जाए तो next step पर जाते हैं, और यह process repeat करते हुए completion के करीब पहुंचते हैं
- अगर cost value से ज्यादा हो जाए तो project stop हो सकता है
- आगे बढ़ने और रोकने का decision आसान नहीं होता, और direction तय करने के लिए frameworks और decision-making workshops इस्तेमाल किए जा सकते हैं
Complicated context और complex context का फर्क
- A Leader’s Framework for Decision Making के Cynefin framework में कार repair या motorcycle maintenance complicated context के करीब हो सकते हैं
- कार repair में expert accident scenario सुनता है, और hidden damage या frame damage जैसे कई factors को analyze और test करके best action तय करता है
- Complex context में try करने के बाद ही सही-गलत का judgement किया जा सकता है
- जिस integration के work करने की उम्मीद थी, वह fail हो सकता है
- कोई नया unknown behavior discover हो सकता है और उसे incorporate करना पड़ सकता है
- Complex legacy system modernization के लिए कोई fixed path या पालन करने वाली rulebook नहीं होती
- Modernization try करने, experiment करने, discover करने, solve करने और अगले piece पर जाने की process को repeat करता है
Curveballs exception नहीं, reality हैं
- अगर application modernization complex और complicated के बीच है, तो progress और success को judge करने के लिए उचित dashboard चाहिए
- Complex context पर simple estimation process apply करना वैसा है जैसे हर screw और lug nut को hammer से solve करने की कोशिश करना
- Modernization project में unexpected curveballs reality हैं
- सभी outcomes पहले से predict नहीं किए जा सकते
- चाहे कितनी भी upfront analysis कर लें, perfect data model तक नहीं पहुंचा जा सकता
- लगभग हर step पर नई learning होती है
- Discover हुई complexity के अनुसार data model बदलना पड़ता है
- जब estimate बदलता है, तो गुस्सा करने, blame करने या schedule को जबरन fit करने वाली analysis में फंसने के बजाय आगे बढ़ने का तरीका ढूंढना चाहिए
Organization culture curveballs को कैसे handle करती है
- Ron Westrum का organization culture model यह अलग करता है कि organization curveball बताने वाले व्यक्ति और failure को कैसे handle करती है
- Power-Oriented organization curveball बताने वाले messenger को shoot करती है, और failure scapegoating में बदल जाता है
- Rule-Oriented organization curveball बताने वाले messenger को ignore करती है, और failure को defined implementation की problem मानती है
- Performance-Oriented organization curveball बताने वाले messenger को train करती है, और failure को exploration की तरफ ले जाती है
- अगर जिस problem को solve करना है वह अब भी relevant है और business needs को meet करती है, तो एक-एक step करके आगे बढ़ना चाहिए
- Modernize किए जा रहे software का final target users हैं
Complex domain में experimental management चाहिए
- जो leader complex domain को recognize नहीं करता, वह targeted results जल्दी न मिलने पर impatient हो सकता है
- Complex domain में failure को tolerate करने की क्षमता अहम है, और failure experimental understanding का essential element है
- Organization को जरूरत से ज्यादा control करने से useful patterns उभरने का मौका रुकता है
- Complex context पर जबरन order impose करने की कोशिश करने वाला leader fail होता है
- Stage set करने, एक कदम पीछे हटने, patterns को उभरने देने और desirable patterns का judgement करने वाला leader सफल हो सकता है
1 टिप्पणियां
Hacker News की रायें
मैंने वह दौर देखा है जब मैनेजमेंट अनुमानों को डेडलाइन की तरह ट्रीट करता था, स्पेसिफिकेशन लगातार बदलता रहता था, फिर भी यह सुनने को बिल्कुल तैयार नहीं होता था कि वे क्यों बदल सकते हैं
ऐसे समय में मैंने हर गैर-तुच्छ काम पर “हेडलाइट्स के सामने खड़े हिरण” जैसी प्रतिक्रिया अपनाई। अगर मैं कहता, “यह काफ़ी बड़ा काम हो सकता है। लगता है टीम में किसी को करीब एक घंटा लगाकर देखना होगा कि असल में क्या चाहिए,” तो मैनेजर हमेशा की तरह “मोटा-मोटी ही सही” पूछता। फिर मैं इतना बड़ा नंबर देता कि वह कुर्सी से उछल पड़े, और वही नंबर उसके दिमाग में रह जाता। इसके बाद एक घंटे की असल जाँच करने के बाद भी, जितना हो सके उस मोटे अनुमान से अलग कोई और नंबर नहीं देता, और आखिर में “शेड्यूल से पहले” पूरा करके अच्छा दिखता
अच्छे मैनेजरों के साथ ऐसी रणनीति की बिल्कुल ज़रूरत नहीं पड़ती थी और यह सचमुच अच्छा था, लेकिन जो लोग अपना काम सीखने की इच्छा नहीं रखते, उनसे इसी तरह निपटना पड़ता था। मीटिंग्स भी कहीं ज़्यादा मज़ेदार हो गईं
डिजाइन टीम, फ्रंटएंड टीम, बैकएंड टीम और QA टीम—सब अपने-अपने अनुमान इसी तरह फुलाते थे, फिर प्रोजेक्ट मैनेजर उस कुल को फिर से 150~200% बढ़ा देता था, और अकाउंट मैनेजर व सेल्स टीम भी लागत का अनुमान लगाने से पहले फिर 150~200% जोड़ देते थे
नतीजा यह हुआ कि एक ऐसी वेबसाइट को बनाए रखने पर महीने के करीब 10 लाख डॉलर खर्च हो रहे थे, जिसे decent वेब/फुल-स्टैक डेवलपर्स की 8~10 लोगों की डेडिकेटेड टीम आराम से संभाल सकती थी। 24-घंटे सपोर्ट को छोड़ दें, तो कुछ अच्छे Rails या Django डेवलपर, या शायद एक डेवलपर और पार्ट-टाइम ग्राफिक डिजाइनर से भी काम चल सकता था
कुछ साल बाद ग्राहक को स्थिति समझ आ गई, और कंपनी के मैनेजमेंट ने काम पूरी तरह बिगाड़ दिया, जिससे करीब 100 लोगों ने नौकरी और बकाया हक खो दिए। उस दिन मैंने खुद भी लगभग 26,000 डॉलर गंवाए
कुल क्षमता मान लें 40 पॉइंट है, और टीम में कोई जाता या जुड़ता है तो यह थोड़ा बदलती है। Velocity को व्यक्ति-दिनों के हिसाब से पॉइंट्स में औसत throughput के रूप में देखा जाता है
Volatility यह है कि स्प्रिंट कितना बदलता है। 5-पॉइंट का एक टिकट हटाकर 3-पॉइंट और 2-पॉइंट के टिकट डालना ठीक हो सकता है, लेकिन 2-हफ्ते के स्प्रिंट में ऐसा 12 बार करें तो कुल मात्रा 40 पॉइंट से कम होने पर भी स्प्रिंट पूरा नहीं होगा
हम रोज़ स्प्रिंट का स्नैपशॉट लेते थे और टिकट जोड़ने/हटाने की मात्रा देखते थे। इससे मैनेजरों को दिखा सके कि volatility कम हो तो काम लगभग हमेशा पूरा होता है, लेकिन ज़्यादा हो तो Velocity पार हुई या नहीं, इससे अलग, स्प्रिंट फेल हो जाता है। वजह यह है कि ठीक से प्लान करने और requirements साफ़ करने का समय नहीं मिलता। प्रोडक्ट टीम को 2 हफ्तों से आगे देखने पर मजबूर करने से कुछ हद तक असर हुआ
साधारण कामों के लिए बहुत फुलाए हुए अनुमान देने वाले इंजीनियर के low performer होने की संभावना भी ज़्यादा थी। यह उन लोगों या मैनेजरों के सामने चल सकता है जो धीमी delivery का आकलन नहीं करते या स्थिति नहीं जानते, लेकिन जो मैनेजर स्थिति समझते हैं वे जल्दी पकड़ लेते हैं
एकल fixed value के बजाय “3 महीने, ±4 हफ्ते” जैसा error range साथ देना चाहिए। ज़्यादातर इंजीनियर जानते हैं कि उनके अनुमान में error range है, लेकिन पता नहीं क्यों उन्हें इसे बताना भूल जाने के लिए प्रशिक्षित कर दिया गया है
मैनेजमेंट के नज़रिए से भी error range का आकार अनुमान पर भरोसे को तुरंत दिखाता है और risk पर चर्चा शुरू कराता है। “अभी दोनों तरफ 30% error है; इसकी सबसे बड़ी वजह क्या है, और क्या कुछ दिन जाँच करके इनमें से एक-दो चीज़ें घटाई जा सकती हैं?” जैसी बातचीत संभव हो जाती है
हम engineering पेशे में हैं और फिर भी risk, probability, confidence interval पर ठीक से बात नहीं कर पाते—यह समझ से बाहर है। यह सिर्फ मैनेजरों की जिम्मेदारी भी नहीं है
अनुभवहीन मैनेजरों या किसी की जगह अस्थायी रूप से काम संभाल रहे लोगों के लिए अनिश्चितता से असहज होना समझ में आता है, लेकिन बाकी स्थितियों में इसका कोई बहाना नहीं है
यह लेख modernization projects के बारे में है, और ऐसे projects में मौजूदा software replacement के development के दौरान भी चलता रहता है, इसलिए इनकी ढीली deadlines होती हैं
बजट का दबाव, commitments और नए features को लेकर user expectations हो सकती हैं, लेकिन replacement एक दिन देर हो जाए तो कोई बड़ी आफत नहीं आती
इसके उलट, अगर आप space probe लॉन्च कर रहे हैं और ग्रहों की स्थिति gravity assist के लिए सही नहीं रह गई, तो spacecraft अपनी मंज़िल तक नहीं पहुँचेगा। 10 करोड़ डॉलर सालाना revenue वाली कोई छोटी tool-making कंपनी Ford से 2026 F150 production line के लिए मार्च तक molds देने का contract ले, और देरी पर प्रति मिनट 20,000 डॉलर penalty हो, तो फरवरी में यह नहीं कह सकती कि “कुछ अप्रत्याशित हो गया, नहीं हो पाएगा।” तभी sign करना चाहिए जब पक्का कर सकें
Ford या NASA को यह सुनकर हैरानी नहीं होती कि estimate निकालने में दसियों हजार डॉलर लगेंगे। वे ECO देते हैं, और अगर ऐसा part जिसे हाथ से 30 मिनट में बनाया जा सकता लगता है, उसके लिए 3 हफ्ते और 8,000 डॉलर चाहिए कहें, तो वे जानते हैं कि उसमें deadline risk, acceptance phases, inspection phases, contingency plans वगैरह शामिल हैं
लेकिन OP के modernization group में अगर कहा जाए कि “जानकारी अधूरी है, इसलिए button text बदलने का 30-मिनट का काम अधिकतम 3 हफ्ते और 8,000 डॉलर ले सकता है,” तो आपको दरवाज़े से ही लौटा दिया जाएगा। आशावादी अनुमान को reward मिलता है, निराशावादी अनुमान को दबाया जाता है, और सही अनुमान मायने नहीं रखते। नतीजतन schedule हमेशा पीछे रहता है और फिर भी किसी को खास हैरानी नहीं होती
इसमें hardware changes, operating system upgrades, नए feature support जैसी maintenance शामिल हो सकती है। मैंने ऐसे projects देखे हैं जो 10 साल से ज़्यादा समय तक parallel चलते रहे
1505 में Michelangelo ने अनुमान लगाया था कि Pope Julius II की कब्र पूरी करने में 5 साल लगेंगे
Sistine Chapel की ceiling painting जैसे छोटे side job की वजह से असल में करीब 40 साल लग गए
अनुमान पर आधारित deadline पूरी न कर पाने के दौरान project का scope काफी घटा दिया गया। वजहें थीं: Pope Julius II का completion से पहले निधन, customer Julius और उनके heirs की change requests, supply chain issues, contract renegotiations, labour disputes, skilled workers की कमी, और लंबी अवधि के कारण funding खत्म हो जाना
तो कम-से-कम 1505 से ही ऐसी चीज़ें होती आ रही हैं। मज़ेदार बात यह है कि पोप उस कब्र में दफन भी नहीं हैं
करियर की शुरुआत में एक अहम बात सीखी। पहली बार बताया गया नंबर लोगों को याद रह जाता है
दुर्भाग्य से असल में अक्सर ऐसा ही होता है, और लोग बार-बार कहते रहते हैं, “क्या आपने शुरू में X नहीं कहा था?” “हाँ, लेकिन हमें नई जानकारी मिली है” हमेशा काम नहीं करता
यह जानने वाले लोग नंबर बताने से बचने लगते हैं, इसका साइड इफेक्ट भी होता है
Scotty: “बिल्कुल, Captain. इसी से तो चमत्कार करने वाले आदमी की प्रतिष्ठा बनी रहती है”
उदाहरण के लिए दिन→हफ्ता, हफ्ता→महीना, महीना→quarter कर देता हूँ। अगर कोई काम एक दिन का लगता है, तो मैं 3 हफ्ते कहता हूँ। ज्यादा लगता है, लेकिन आखिर में bureaucracy, process और technical debt की वजह से आम तौर पर लगभग उतना ही लग जाता है
एक जगह लिखा है, “क्या आप सोच सकते हैं कि कोई insurance company repair shop से बहस करे कि original estimate 18,000 डॉलर था, इसलिए वे extra 20,000 डॉलर नहीं देंगे? बेतुका है न? मैं भी यही मानता हूँ। शुक्र है कि reality ऐसे काम नहीं करती”, लेकिन insurance में ऐसा हमेशा होता है
सिर्फ car और home insurance ही नहीं, health insurance में भी यही है। कई बार बात reasonable point पर negotiate हो जाती है, लेकिन हमेशा नहीं; इसलिए “reality ऐसे काम नहीं करती” वाला आत्मविश्वासी लहजा चौंकाता है
Total loss करना ज्यादा महंगा हो सकता है, लेकिन upper limit साफ होती है और claim बंद किया जा सकता है। Insurance companies open claims पसंद नहीं करतीं
बाद वाला, जिसे car insurance में “preferred rate” भी कहा जाता है, एक umbrella contract होता है जिसमें किसी खास type के काम को fixed negotiated rate पर bill किया जाता है
यह binding estimate से बहुत अलग है। Binding estimate आम तौर पर किसी specific काम के लिए one-off estimate होता है, जिसमें estimator risk लेता है और यह वादा करता है कि काम उम्मीद से कहीं ज्यादा complex निकला तब भी उसी rate पर पूरा करेगा
एक तरीका यह है कि जहाँ संभव हो हमेशा सिर्फ fixed scope के लिए estimate करें, और unknown unknowns को बाहर रखें
“feature X implement करना” estimate न करें; “feature X engine” estimate करें। अगर extra काम मिलता है, तो उसे “existing code refactoring”, “feature X+Y integration” जैसे खोजे गए milestones के रूप में जोड़ना चाहिए
लेकिन यह naming और understanding ऊपर तक पहुँचे तभी असर करता है। अगर कोई “feature X engine” milestone को उसी estimate के साथ “feature X complete” में बदल दे, तो मामला खराब हो जाता है
इससे जुड़ी समस्या भी देखी है। Leadership deadlines को “motivation” समझती है। यह उन लोगों जैसा है जो घर को 72F तक गर्म करना चाहते हैं, लेकिन “जल्दी हो” इसलिए thermostat 80F पर set कर देते हैं
एक बार leadership meeting में वे भूल गए कि मेरे जैसा junior engineer भी invite किया गया था। किसी ने माना कि deadline X पूरी करना बहुत मुश्किल है और पूछा कि क्या इसे अधिक realistic date पर बदलना चाहिए; तब एक senior PM ने जवाब दिया, “हम deadlines कभी नहीं खिसकाते! Engineering दिए गए सारे समय का इस्तेमाल कर लेती है!”
उस मामले में engineering ने तब समय वापस कर दिया जब मैं उस team से निकल गया
यह भी सच है कि कई engineering teams दिए गए समय का पूरा इस्तेमाल कर लेती हैं
लेकिन managers को estimates और plans को engineers के सामने hard deadlines बनाने के बजाय organization को overrun के लिए तैयार करना चाहिए। जब expected completion time करीब आए और developer समझा सके कि कौन-सा हिस्सा क्यों ज्यादा समय ले गया, तो उसे reasonable तरीके से समझना चाहिए
Managers को यह भी सुनिश्चित करना चाहिए कि customers, sales और senior managers planned completion time को deadline की तरह treat न करें। अगर commitment देना ही हो, तो customer-facing deadline expected completion time से काफी बाद की होनी चाहिए
Electric radiator में भी असल में असर हो सकता है। क्योंकि radiator के पास की हवा थोड़ी गर्म होते ही वह तुरंत बंद नहीं होगा
बहुत सारे “rough guess estimates” को hard deadlines में बदलते देखने के बाद से मैं stakeholders के सामने No Estimates approach push कर रहा हूँ
शुरुआत में स्वाभाविक रूप से resistance होता है। चिंताएँ दूर करने के लिए यह समझाना मदद करता है कि planning के लिए सही मायने में इस्तेमाल लायक काफी accurate estimates असल में सिर्फ दो cases में possible हैं
A) जब बचा हुआ काम past work की copy जैसा हो। उदाहरण के लिए उसी system का दूसरा datacenter provision करना
B) जब team मानती हो कि बचा हुआ नया feature work आखिरी quartile में आ चुका है, और success रोक सकने वाले remaining risks सहित अच्छी तरह defined है
Micro estimates micro-management को enable करते हैं। Healthy teams project success risks के आधार पर highest-priority काम ढूँढती हैं और उन्हें priority order में करती हैं
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
पहले HN पर देखा एक मजेदार formula ध्यान में आया। यह fancy और अच्छा दिखता है, लेकिन दूसरी estimation methods की तरह इसकी कोई formal validity नहीं है; यह personal experience पर आधारित बस एक arbitrary formula है
https://news.ycombinator.com/item?id=37965582
मेरा estimation math: R = t × [1.1^ln(n+p) + 1.3^X]
R actual लगने वाला समय है, t वह shortest possible time है जब communication की जरूरत न हो, n process में शामिल लोगों की संख्या है जिसमें customer और development organization शामिल हैं, p project के भीतर सबसे लंबी communication distance है, और X process में इस्तेमाल होने वाले नए tools, libraries, techniques की संख्या है
उदाहरण के लिए अगर एक developer code लिखने वाला project 2 हफ्ते लेता है(t=2), कुल 5 लोग involved हैं(n=5), 1 नया tool है(X=1), और longest communication distance 4 है, तो 2×(1.1^ln(5+4) + 1.3^1) = 4.5 हफ्ते होता है
known unknowns के अलावा unknown unknowns के लिए भी X quantity जोड़नी चाहिए
दुख की बात है कि estimates असल में negotiation होते हैं। जो व्यक्ति पहले नंबर देता है, वह अक्सर “भौंहें सिकोड़ने” की वजह से हार जाता है
“Estimate क्या है?” “मुझे ठीक से नहीं पता।” “लगभग ही सही।”
“तो आप इसे कब तक चाहते हैं?”
यही वह trap है जिसमें नए managers हर बार फँस जाते हैं। अगर आप जवाब दे देते हैं, तो bingo। उसी समय वे “भौंहें सिकोड़ना” दिखाते हैं। दाँतों के बीच से साँस खींचते हैं, चेहरा सिकोड़ते हैं और कहते हैं, “अरे, यह तो पूरी तरह अवास्तविक है। आखिर यह नंबर आया कहाँ से?” फिर वे कई गुना बड़ा नंबर देते हैं या scope घटाने का सुझाव देते हैं। जैसे, “अरे, इतने समय में तो अगर किस्मत अच्छी रही और दूसरे project की Y feature काटनी पड़ी, तभी सिर्फ X feature हो पाएगी”
जो भी करें, जरूरी है कि पहले नंबर आप न दें। Poker या car खरीदने जैसा है; इसकी feel आने में थोड़ा समय लगता है। बड़े enterprise में भी समय पैसा है, और उसे उसी तरह treat करना चाहिए। zero-sum game
जहाँ मैं काम करता हूँ, वहाँ efficiency के नाम पर estimates लगातार कम किए जा रहे हैं, और carry-over work भी allow नहीं है
recovery time के बिना एक साल से ज्यादा समय तक लगभग crunch जैसी हालत में रहा हूँ। लगातार उम्मीद करता रहा कि चीजें बेहतर होंगी, लेकिन लगता है उल्टा और खराब हो रही हैं। ऊपर से सभी लोगों को product के अलग-अलग areas में लगातार rotate किया जा रहा है, और कोई option भी नहीं है। अभी भी भाग तो रहा हूँ, लेकिन mentally पूरी तरह burnt out महसूस करता हूँ