उस समस्या को हल करने का श्रेय, जिसे कोई याद नहीं रखता और जो कभी हुई ही नहीं (2001) [PDF]
(web.mit.edu)- कंपनियाँ Toyota-शैली की manufacturing capability, six-sigma quality, और Dell-शैली supply chain जैसी operational capabilities को अपनाने के लिए भारी खर्च करती हैं, लेकिन सुधार कार्यक्रमों का टिकाऊ प्रदर्शन में बदलना दुर्लभ है
- TQM एक ऐसा उदाहरण है जो कभी व्यापक रूप से अपनाया गया, फिर तेज़ी से पीछे छूट गया; Fortune 1000 में अच्छी तरह विकसित TQM program वाली कंपनियाँ 10% से भी कम थीं
- असफलता का कारण किसी खास tool के चयन से अधिक इस बात में होता है कि नया program भौतिक, आर्थिक, सामाजिक और मनोवैज्ञानिक संरचनाओं के साथ कैसे जुड़ता है; इसलिए सुधार अंततः system problem बन जाता है
- जब performance gap बड़ा हो जाता है, तो संगठन अधिक देर तक काम करने वाले Work Harder और capability बढ़ाने वाले Work Smarter के बीच चुनते हैं, लेकिन देरी और विफलता के जोखिम के कारण दूसरा विकल्प अक्सर पीछे रह जाता है
- सुधार के समय को घटाने वाले Shortcuts अल्पकाल में output बढ़ाकर आकर्षक लगते हैं, लेकिन देर से दिखने वाली capability में गिरावट जमा होती जाए तो संगठन Capability Trap में फँस सकता है
सुधार कार्यक्रमों के विफल होने का विरोधाभास
- कंपनियाँ manufacturing, quality, customer understanding, और supply chain management जैसी operational capabilities विकसित करने के लिए process improvement में सक्रिय निवेश करती हैं
- 1997 में अमेरिकी कंपनियों का management consultants और training पर कुल खर्च 100 billion dollars से अधिक था, और इसका बड़ा हिस्सा उत्कृष्ट कंपनियों की operational capabilities की बराबरी करने में लगा
- कुछ नाटकीय सफलताओं के बावजूद, कई improvement programs सार्थक परिणाम नहीं दे पाए
- TQM इस विरोधाभास को अच्छी तरह दिखाता है
- 1980 के दशक में जापानी कंपनियों की सफलता से प्रेरित होकर यह अमेरिकी कंपनियों में बहुत लोकप्रिय हुआ
- 1990 के दशक के मध्य तक academia और business media की रुचि कम हो गई, और यह re-engineering जैसे नए innovations के आगे पीछे छूट गया
- जिन कंपनियों ने TQM के अनुशासन और तरीकों के प्रति गंभीर प्रतिबद्धता दिखाई, उनका प्रदर्शन प्रतिस्पर्धियों से बेहतर रहा
- एक अध्ययन में Fortune 1000 में अच्छी तरह विकसित TQM program वाली कंपनियाँ 10% से कम थीं
- एक अन्य अध्ययन में TQM 1993 में तीसरा सबसे अधिक इस्तेमाल होने वाला business tool था, लेकिन 1999 तक 14वें स्थान पर आ गया
- पुराने सुधार तरीक़े नाम बदलकर फिर से सामने आते हैं
- statistical process control और variation reduction के मुख्य अनुशासन six-sigma में आगे बढ़े
- quality circle को फिर high-performance work team कहा जाने लगा
टूल से भी कठिन है implementation structure
- performance improvement के tools और techniques तेज़ी से बढ़े, और information technology तथा consultants की वृद्धि से यह जानना भी आसान हुआ कि कौन-सी technique कौन इस्तेमाल कर रहा है
- अधिकांश managers के लिए बड़ी बाधा नया तरीका जानना नहीं, बल्कि उसे रोज़मर्रा के काम में सफलतापूर्वक लागू करना है
- six-sigma quality program जैसी capabilities कोई turnkey product नहीं हैं जिन्हें खरीदा जा सके; इन्हें संगठन के भीतर विकसित करना पड़ता है
- लगभग एक दशक में telecom, semiconductor, chemical, petroleum, automobile, और leisure products industries में 12 से अधिक गहन case studies की गईं
- इनमें observation, participant interviews, archival records, और quantitative metrics का उपयोग हुआ
- implementation और improvement की dynamics को पकड़ने के लिए models भी साथ-साथ विकसित किए गए
- अधिकांश संगठन improvement innovation का पूरा लाभ नहीं उठा पाते, इसका कारण किसी विशेष improvement tool का चुनाव लगभग नहीं होता
- नया improvement program उन जगहों पर काम करता है जहाँ tools, equipment, workers, managers, और भौतिक, आर्थिक, सामाजिक, मनोवैज्ञानिक संरचनाएँ एक-दूसरे से जुड़ी होती हैं; इसलिए यह systemic problem बन जाता है
सुधार का मूल physics: समय और capability
- किसी process का वास्तविक performance Time Spent Working और वह काम करने की process capability से तय होता है
- manufacturing में प्रतिदिन के labor hours और productivity, यानी labor hour प्रति usable output, के गुणनफल से net usable output तय होता है
- performance को अधिक काम करके या improvement में अधिक निवेश करके बढ़ाया जा सकता है, लेकिन दोनों तरीकों के नतीजे अलग होते हैं
- यदि साप्ताहिक काम के घंटे 20% बढ़ा दिए जाएँ, तो overtime जारी रहने तक output 20% बढ़ सकता है
- process capability में सुधार बाद में लगाए जाने वाले सभी work time के output को बढ़ाता है
- defective products के rework के लिए overtime तभी output बढ़ाता है जब overtime चलता रहे, लेकिन defects के root cause को हटाना rework की ज़रूरत को लगातार घटाता है
- capability को समय के साथ जमा होने वाली asset(stock) के रूप में देखा जाता है
- improvement पर खर्च किया गया समय capability investment बढ़ाता है
- root cause ढूँढ़ने, solutions खोजने, परखने और लागू करने में समय लगता है, इसलिए improvement activity और capability change के बीच delay होता है
- machine wear, process drift, design aging, और procedures के outdated हो जाने के कारण, नियमित रखरखाव न होने पर capability घटती जाती है
- improvement delay process की तकनीकी और organizational complexity के अनुसार बदलता है
- job shop में machine yield जैसे अपेक्षाकृत सरल process improvement delays कुछ महीनों के होते हैं
- product development जैसे जटिल process improvement delays कई साल या उससे अधिक हो सकते हैं
- जिन संगठनों में products और workforce का turnover ऊँचा होता है, वहाँ improved capability की उम्र भी कम होती है
Work Harder और Work Smarter के बीच तनाव
- management customer demand, insurance claims processing volume, या quarterly new product launches जैसी targets को Desired Performance के रूप में तय करता है
- वास्तविक performance और target के बीच का अंतर Performance Gap बन जाता है, और अध्ययन किए गए संगठनों में अपेक्षा से बेहतर चलते process दुर्लभ थे
- जो संगठन capacity expansion या अतिरिक्त hiring से बचते हैं, उनके पास performance gap बंद करने के दो मूल विकल्प होते हैं
-
Work Harder loop
- managers performance gap होने पर काम की रफ्तार बढ़ाने, overtime, अधिक आक्रामक targets, या target miss करने पर penalties जैसे तरीकों से work pressure बढ़ाते हैं
- performance reviews की frequency, review detail का स्तर, और reviewers की seniority जैसे सूक्ष्म तरीके भी work pressure का हिस्सा होते हैं
- एक कंपनी में एक senior vice president ने factory floor पर individual machines के performance की समीक्षा की, और यह संदेश गया कि किसी भी कीमत पर machines चलती रहनी चाहिए
- एक project manager का subsystem schedule पीछे रह गया, तो उससे prototype specification पूरी होने तक हर घंटे status report call माँगी गई
-
Work Smarter loop
- managers improvement programs शुरू करके, नए ideas के experiment को प्रोत्साहित करके, और training में निवेश करके process capability बढ़ाने की कोशिश कर सकते हैं
- सफलता मिलने पर समय के साथ capability सुधरती है, throughput बढ़ता है, और performance gap घटता है
- improvement investment लंबे समय में अधिक प्रभाव दे सकता है, लेकिन असर दिखने में काफी delay होता है और root cause खोजने या नए tools लागू करने में failure risk भी रहता है
- तात्कालिक समस्याओं में अक्सर Work Harder चुना जाता है
- यदि किसी महत्वपूर्ण customer की manufacturing line रुक जाए, तो manager reliability improvement training की बजाय line फिर चालू कराने और shipment पूरा होने तक overtime बढ़ाने की ओर झुक सकता है
- यदि अस्थायी प्रतिक्रिया खत्म होने के बाद भी संगठन improvement activities पर वापस नहीं लौटता, तो अधिक मेहनत से काम करना standard operating mode बन जाता है
reinvestment loop और capability trap
- संगठनों में spare resources लगभग नहीं होते, इसलिए work pressure बढ़ने पर लोग rest जैसी non-work activities घटाते हैं और overtime बढ़ाते हैं
- knowledge workers का overtime अक्सर unpaid होता है और रातों तथा weekends तक फैल जाता है, जिससे परिवार और community activities का समय छिन जाता है
- जब समय और नहीं बढ़ाया जा सकता, तो बढ़ते हुए performance gap को पूरा करने के लिए improvement time घटाना पड़ता है
-
Reinvestment loop
- यदि improvement investment सफल हो, तो performance बढ़ता है और performance gap घटता है, जिससे improvement पर अधिक समय लगाया जा सकता है और virtuous cycle बनती है
- इसके विपरीत, throughput gap का जवाब work pressure से देने पर improvement time घटता है, capability गिरती है, और performance gap और बढ़ता है; इससे अधिक work pressure और कम improvement वाला vicious cycle बनता है
- सफल improvement cases में productivity gains से मिले resources को फिर स्पष्ट रूप से improvement activities में लगाया गया ताकि reinvestment process मज़बूत हो
- कई संगठनों में cost और schedule pressure downsizing या ऊँचे performance targets में बदल जाते हैं, जिससे improvement resources छिन जाते हैं और capability स्थिर हो जाती है या गिरती है
-
Shortcuts loop
- improvement meetings छोड़ना, scheduled preventive maintenance टालना, या documentation requirements को नज़रअंदाज़ करना जैसे shortcuts तुरंत working time बढ़ाते हैं
- capability degradation तुरंत नहीं दिखती, इसलिए shortcuts अल्पकाल में प्रभावी और आकर्षक लगते हैं
- जो manager preventive maintenance टालता है, उसे scheduled downtime और maintenance cost से अस्थायी राहत मिलती है, लेकिन बाद में equipment aging और wear के कारण yield और uptime गिरते हैं
- documentation छोड़ने वाला software engineer project समय पर पूरा कर सकता है, लेकिन कुछ हफ्तों या महीनों बाद testing में मिले bugs को ठीक करते समय उसकी कीमत चुकाता है
-
Capability Trap
- Work Harder शुरुआत में total throughput तुरंत बढ़ाता है और improvement time घटने की लागत देर से दिखती है, इसलिए यह better-before-worse स्थिति बनाता है
- Work Smarter अल्पकाल में output घटाता है, लेकिन समय के साथ capability growth work effort में कमी की भरपाई करके performance बढ़ाती है; यह worse-before-better dynamics रखता है
- Shortcuts और Reinvestment की परस्पर क्रिया संगठन को capability decline के vicious cycle में फँसा देने वाला Capability Trap बना सकती है
2 टिप्पणियां
Hacker News की राय
याद थोड़ी धुंधली है, लेकिन एक अच्छा उदाहरण है
एक संगठन में महत्वपूर्ण order processing था, लेकिन भरोसा नहीं किया जा सकता था कि सारी ज़रूरी जानकारी पूरी आएगी या सही आएगी। इसलिए input values को साफ़ करने और processing का तरीका बदलने वाली validation logic बनाई गई, और हर order में कौन-सा validation trigger हुआ, इसे metrics के रूप में रखा गया। नया validation जोड़ते तो तारीख भी जोड़ते थे
इन metrics को सार्वजनिक करके कभी-कभी शेयर करने से, जब कोई पूछता “XYZ हो तो क्या होगा?”, तो जवाब दिया जा सकता था, “इसे पहले ही संभाल लिया है, और XYZ की वजह से #### orders रुकने से बचाए गए”
इससे दिखा कि टीम सावधानी से काम कर रही थी, system को लगातार ठीक से चलाते रहने के लिए ऐसा काम ज़रूरी है, और इसे data से support किया जा सकता है। इसके कारण संगठन के भीतर बातचीत “यह सोचा क्यों नहीं?” से बदलकर “अब क्या करना चाहिए?” हो गई, और preventive quality को ऊपर तक पहचान मिलने लगी
ज़्यादातर teams शायद सिर्फ order success rate जैसे metrics देख कर रुक जातीं, लेकिन खराब data को संभालने की संख्या को metric बनाने से अच्छी चीज़ों के नज़र न आने वाले trap से बचा जा सकता है
हाल ही में अपने workplace पर बिल्कुल यही अनुभव हुआ
संगठन के tech lead/architect के तौर पर मैंने हाल में release हुए projects की review की, और गंभीर reliability/performance issues के कारण वे हिस्से ढूंढे जिन्हें ज़रूर सुधारना था। एक team की कई releases सूची में सबसे ऊपर थीं, लेकिन उस team के PM और engineering manager, और ऊपर के लोगों ने feature updates को प्राथमिकता देने की बात कहकर सारी चिंताओं को नज़रअंदाज़ कर दिया
कुछ महीनों बाद मेरी छुट्टी के दौरान मामला फट पड़ा, sev 1 escalation हुआ, कई customers नाराज़ हुए और CEO/CTO तक शामिल हो गए। वही team जिसने खराब code लिखा था और warnings को ignore किया था, दिन-रात काम करके service restore करने लगी, और अब वे hero बन गए। खासकर उस manager की company में प्रतिष्ठा बढ़ गई, क्योंकि outage के दौरान उसने सक्रिय communication किया और leadership दिखाई
दूसरों के बनाए problems ठीक करना ज़्यादा impressive है। अपनी ही गलती ठीक करने वाले पर तारीफों की बारिश करने का मन नहीं होता, और मैं भी अपनी गलती ठीक करने पर तारीफ की उम्मीद नहीं करता। सबसे पहले तो जो बिगाड़ा है उसके लिए सब से माफी मांगूंगा
शीर्षक वाला मुद्दा मुझे अपनी value के संदर्भ में लगातार सोचने पर मजबूर करता है
अगर कोई 3 महीनों से अटके काम में 40 मिनट में मदद कर दे, तो मेरी value सबको साफ़ दिखती है। लेकिन अगर मैं शुरू से साथ काम करूं और कोई भी 3 महीनों तक न अटके, तो मेरी value अस्पष्ट हो जाती है। समझ नहीं आता इस paradox से कैसे निपटें
ज़्यादा मेहनत और समय लगाने पर अक्सर reward पीछे रह जाता है और आपसे और अधिक मेहनत व समय की उम्मीद की जाने लगती है। value और opportunity मेहनत व समय के संदर्भ में किसी chaotic process जैसी चीज़ हैं
आखिरकार कोशिश यह होनी चाहिए कि workload इतना रहे कि दिमाग साफ़ रहे और मौका आने पर उसे पकड़ा जा सके। ईमानदार और balanced colleagues मदद करते हैं, लेकिन अंततः यह खुद ही करना पड़ता है
boss समझाने की कोशिश करे फिर भी, अगली layoff में कटने वाला सिर मेरा हो सकता है
उन्होंने दूसरी companies को बताया कि मैं ऐसे काम में अच्छा हूं, लेकिन उससे कुछ आगे नहीं हुआ। छोटी companies के लिए contracting का वह मेरा पहला और आखिरी दिन था
इसलिए team members का morale नहीं टूटता। team member को psychologically अपनी individual contribution की पहचान मिलनी ज़रूरी होती है
ऐसे bosses अक्सर सक्षम individual contributors रहे होते हैं और फिर team lead बने होते हैं; क्योंकि वे खुद उस skill के master होते हैं, इसलिए वे अपने manage किए जा रहे individual contributors को judge करने की सबसे अच्छी position में होते हैं
जिस disaster से बचाया गया, उसका vivid वर्णन करें ताकि लोगों के दिमाग में एक साफ़ तस्वीर बने
एक और variant यह है कि जिस समस्या ने सच में एक बार सिर उठाया हो, उसे रोकने के लिए संसाधन जरूरत से ज्यादा लगा दिए जाते हैं, और जो समस्याएं ज्यादा गंभीर हैं लेकिन अभी तक हुई नहीं हैं, उन पर कम ध्यान दिया जाता है
यह management problem है। क्योंकि भले ही कोई और ज्यादा जरूरी काम करना तर्कसंगत रहा हो, वही हादसा दोबारा होने पर कोई भी जिम्मेदारी नहीं लेना चाहता
जैसे एक छोटा घाव किसी कठोर और कम लचीले संगठन से बदल दिया जाता है। सिर्फ इसलिए कि कोई चीज़ एक बार हुई है, यह जरूरी नहीं कि उसे दोबारा कभी न होने देने के लिए बदलाव अनिवार्य हो; और ऐसी overreaction भविष्य में बड़ा बोझ बन सकती है
नुकसान स्वीकार करना और यह मानना कि यह फिर हो सकता है, कभी-कभी उसे पक्का रोकने के नाम पर जरूरत से ज्यादा prevention करने से बेहतर हो सकता है
जब तक कोई चीज़ सच में न हो जाए, prevention resources allocate न करने की policy कुछ हद तक तर्कसंगत है
मैंने एक बदहाल साल यह समझाने में गुजारा कि outage पर overreact किया जा रहा है और जो असल समस्या हुई थी उसका बहुत simple solution है। लेकिन अगर senior manager को recurrence से अपनी position खतरे में दिखती है, तो वह पूरे department को similar problem वाले code review और fix करने का आदेश देता है। और अजीब तरह से, वे सबसे ऊंची आवाज़ों को सुनते हैं जो बेहद over-engineered solutions लेकर आती हैं
एक और बार password expiry की वजह से trading stack में outage आ गया। इसे “फिर कभी न होने देने” के लिए हास्यास्पद रूप से जटिल custom solution में जो मेहनत लगी, वह अविश्वसनीय थी। आखिरकार 1 साल से ज्यादा काम के बाद सब फेंक दिया गया, और उसकी जगह वही कहीं ज्यादा सरल centralized solution आया जो शुरू से करना चाहिए था
मुझे अपनी पुरानी workplace याद आ गई। जब भी feedback मांगा जाता, वे बार-बार कहते थे कि “यहां PIR(post-incident response) के बिना कुछ भी priority नहीं बनता”
आखिर के दिनों में जब PIR से जुड़ा ticket आता, तो मैं उसे उस असली ticket का duplicate mark कर देता जो उस incident को रोक सकता था लेकिन backlog में मर रहा था। हमारे area में predictable problems रोकने पर हमारा कोई influence नहीं है—इससे team morale को बड़ा नुकसान हुआ
team के ज्यादातर लोगों ने improvement suggestions देना ही बंद कर दिया। क्योंकि management हमें खुद tickets खींचकर लेने की अनुमति नहीं देता था
यह बहुत अच्छी तरह दिखाता है कि corporate Scrum किस तरह के नरक में बदल रहा है
Agile का मतलब सचमुच तेजी से काम करना और अपनी capabilities को तेज cycles में improve करना था। लेकिन Scrum उस planning process का और भी खराब version बन गया जिसे वह replace करना चाहता था
Scrum जिस तरह काम को केवल तुरंत सामने दिख रही problems में तोड़ता है, वह इस cycle को और बिगाड़ता है। लंबे समय में यह ऐसा ticket system बन जाता है जहां आग ऊपर धकेली जाती है और technical debt नीचे
ऊपर से यह ऐसे efficiency numbers भी उगलता है जिन्हें track करना आसान है लेकिन अर्थहीन हैं, और जिनसे consultants और executives optimization का खेल आसानी से खेल सकते हैं
मैं यह कह सकता हूं। मेरे close friends में भी Scrum Masters हैं
क्यों, यह समझ आता है। किए जा सकने वाले अनगिनत कामों में से क्या करना है, इसका फैसला किसी को करना ही होता है। क्या यह feature पैसा कमाएगा? feature नहीं, लेकिन resource cost कम करने वाला काम कैसा रहेगा? उस technical debt का क्या जो feature delivery की speed धीमी करता है?
मैं senior manager नहीं हूं, लेकिन आखिर ऊपर कोई तो है जिस पर company को जिंदा रखने, पैसा कमाने और हमें salary देने की जिम्मेदारी है। वे भी हमारी तरह कम उपलब्ध जानकारी के आधार पर फैसले लेते हैं। इसलिए उन्हें “इसकी cost कितनी है और value कितनी है” बनाम “उसकी cost कितनी है और value कितनी है” compare करने का तरीका चाहिए
इसका estimate लगाने का तरीका चाहिए था, और tech industry ने Agile को उसी साधन के रूप में promote किया, तो वे उसी से चिपक गए। गलती किसकी है?
फिर उसके साथ frequent estimates, schedule tracking और ceremonies आ गईं। कुछ लोग मानते हैं कि यह स्वाभाविक रूप से follow होना जरूरी नहीं था, और मैं सहमत हूं। लेकिन जो भी हो, वे ceremonies cult का हिस्सा बन गईं
हमने Scrum छोड़ दिया, refinement meetings, story estimates और story points भी छोड़ दिए। अब हम महीने में एक बार PM से formally मिलते हैं और team level पर current status को सिर्फ T-shirt size estimation से देखते हैं। बाकी समय PM के मांगने पर या हमें जरूरत महसूस होने पर updates देते हैं। इससे authority हमारे पास है, लेकिन उतनी ही responsibility भी है कि अगर स्थिति अस्थिर दिखे तो समय पर inform करें। अब भी “estimate” करना पड़ता है, क्योंकि आखिर senior managers को decisions लेने होते हैं। लेकिन overall यह काफी lightweight है, और सचमुच मुक्त करने जैसा है
सभी लोग process के प्रति committed थे, और Scrum team ने effort का 20% debt handling priority के लिए रखा था। प्रत्येक व्यक्ति की velocity भी काफी accurate थी, इसलिए personal interest work के लिए अतिरिक्त 20% reflect किया जा सकता था, और stakeholder priorities बचे हुए 60% में आती थीं
कुछ sprints में अगर epic या team goal खत्म करने के लिए push करना पड़ता, या emergency/bug के कारण priorities बदलनी पड़तीं, तो हम दिशा बदल लेते थे
सिर्फ process जोड़ने की इच्छा से ढेर सारा process जोड़ना value create नहीं करता
दफ्तर में चिपकाई हुई यह comic याद आ गई: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
इसलिए कई corporate cultures में, अगर कोई problem आपके immediate ownership area की नहीं है, तो उसे proactively रोकने के बजाय—भले ही आपको ठीक करने का तरीका पता हो—reward के लिहाज से बेहतर है कि आप न रोकें। problem को सामने आने दें, उसे किसी की emergency बनने दें, फिर fix कर दें
बेशक long term में ऐसा organization अच्छा नहीं करेगा, इसलिए वहां से निकलने की planning भी करनी चाहिए
“किसी को उस समस्या को ठीक करने का श्रेय नहीं मिलता जो कभी हुई ही नहीं” (2001) [pdf] याद आता है
जब भी YouTuber या सोशल मीडिया क्लिकबेट दावा करते हैं कि Y2K bug कोई बड़ी बात नहीं था, यही बात दिमाग में रहती है
वह बड़ी बात इसलिए नहीं बना क्योंकि मेरे जैसे अनगिनत veteran लोगों ने कई महीने पहले से रातें जागकर इसे काम करने लायक बनाया था
मुझे अब भी UTC midnight countdown के समय का तनाव याद है। फिर Eastern Time countdown पर फिर तनाव हुआ, और local time पर एक बार और। Pacific Time के 2000 में पहुँचने के बाद ही आखिरकार राहत मिली
2038 में पता चल जाएगा
उसी दौर की बात करें तो Y2K भी बहुत अच्छा उदाहरण है। दिखने में लगभग कुछ नहीं हुआ, लेकिन अगर लोगों ने इसे बस अनदेखा कर दिया होता तो बहुत कुछ हो सकता था
यह इसलिए नहीं कि मेरी तनख्वाह इस पर निर्भर थी। करने के लिए दूसरे काम तो बेशक बहुत थे। यह सच में ऐसा मुद्दा था जो energy industry को पंगु कर सकता था, और बड़ी कंपनियों तथा उन पर निर्भर अनगिनत संगठनों को प्रभावित करता। इस अनुभव से मुझे लगता है कि finance या resource development जैसी कई industries पर भी सीधे या परोक्ष रूप से वैसा ही असर पड़ता
इसलिए यह अच्छा उदाहरण है। आज भी ऐसे लोग मिलते हैं जिन्हें Y2K बस बेकार का हंगामा याद है। ऐसा नहीं था। यह आपके लिए समस्या नहीं बना क्योंकि बहुत से लोगों ने मेहनत करके उसे रोका
वे समस्याएँ बहुत जटिल नहीं थीं, लेकिन व्यापक, महत्वपूर्ण थीं और भारी workload मांगती थीं। यह मानवता की उपलब्धि के रूप में दिखाने लायक moon landing स्तर की engineering problem कम थी, और विस्फोट से पहले ढेरों मूर्खतापूर्ण Challenger O-ring समस्याएँ ठीक करने जैसी ज्यादा थी
इसलिए उस दिन तक बस थोड़े बहुत छोटे residual bugs बचे थे। अखबारों में कुछ मजाक जरूर थे, लेकिन आम जनता ने कुल मिलाकर इसे यूँ ही जाने दिया
मैं climate क्षेत्र में काम करता हूँ और चाहता था, या चाहता हूँ, कि वही चीज हो। लेकिन अब लगता है कि जल्द ही यह सबका ध्यान खींचने पर मजबूर कर देगा
अगर आप तैयार हैं, तो कुछ भी दिलचस्प नहीं होता, जिंदगी चलती रहती है, और लोग इसे बस laptop खोलकर कुछ buttons दबाने भर के रूप में याद रखते हैं
अगर आप तैयार नहीं हैं, तो Texas power grid जम जाती है, लोग मरते हैं, savings खो देते हैं, और बात बनती है “किसी ने कल्पना नहीं की थी कि यह इतना बुरा होगा”
कबूल करूँ तो मैं भी उस काम में शामिल था। मजेदार बात यह है कि मुझे एक पुराने client के पास वापस बुलाया गया, जहाँ मैंने उस समस्या को ठीक किया जो सचमुच मेरे ही पुराने काम ने पैदा की थी। समस्या देखते ही 20 मिनट में ठीक कर दी। फिर “जब आ ही गए हो तो इसे भी देख लोगे…” शुरू हुआ, और वह करीब 2 साल तक चला, जब तक वह department बंद होकर New York नहीं चला गया
कम से कम billable hours के रूप में तो श्रेय मिल गया
चूँकि यह लेख ठीक उसके बाद लिखा गया था, मुझे लगा था कि यह Y2K की बात होगी
90 के दशक के आखिरी कुछ वर्षों में मैंने Y2K projects पर काम किया और UK की core infrastructure को midnight पर रुकने से बचाने में मदद की। उदाहरण के लिए, हमारी कोशिशों के बिना Wales में पानी या gas नहीं होता
लेकिन बाद में मैंने बातें सुनीं जैसे “कुछ हुआ ही नहीं, तो साफ था कि यह समस्या नहीं थी, फिर Y2K पर इतना पैसा क्यों खर्च किया?” या “Y2K IT industry द्वारा बनाया गया scam था”
हम जीत गए थे। हमने Y2K bug को सफलतापूर्वक रोका, यह कठिन काम था, और midnight तक सब कुछ पकड़ लिया था या नहीं, यह भी पक्का नहीं था। लेकिन celebration मिलने के बजाय कुछ लोगों ने इसे इस बात का सबूत माना कि हमने लोगों से ज्यादा पैसे वसूले। लोग अजीब हैं
चिढ़ाने वाली बात यह है कि climate change में भी best-case scenario यही है। अगर हम सच में apocalypse से बचने में सफल हो गए, तो सारे “climate deniers” को लगेगा कि वे सही थे
Hacker News की राय
शीर्षक देखकर एक दिलचस्प प्राचीन चीनी कथा याद आ गई। Toyota का हाल की स्कैंडल में फँसना भी थोड़ा विडंबनापूर्ण है: https://www.bbc.com/news/articles/c1wwj1p2wdyo
Wei राज्य के राजा Wen ने Bian Que से पूछा, “अगर तीनों भाई डॉक्टर हैं, तो सबसे श्रेष्ठ कौन है?” इस पर Bian Que ने जवाब दिया, “सबसे बड़े भाई सबसे श्रेष्ठ हैं, दूसरे भाई उनसे कम, और मैं सबसे कमज़ोर हूँ।”
सबसे बड़े भाई बीमारी को उसके आकार लेने से पहले पहचानकर चुपचाप समाप्त कर देते थे, इसलिए उनका नाम केवल परिवार के भीतर जाना जाता था; दूसरे भाई बीमारी के उभरने की शुरुआत में इलाज कर देते थे, इसलिए उनका नाम गाँव की गलियों से बाहर नहीं जाता था; और Bian Que स्वयं नसें चुभोते, तेज़ दवाइयाँ देते और शरीर चीड़ते थे, इसलिए उनके दिखने वाले उपचारों के कारण उनका नाम राजाओं-रईसों में फैल गया — कहानी कुछ ऐसी है
मैंने ऐसी company देखी है जहाँ “मुसीबत झेलने वाला department” अपनी ही बनाई समस्या को वीरतापूर्वक संभाल लेने पर अगली तिमाही में तारीफ़ और बढ़ा हुआ budget पा गया
जबकि मेरा department, जो चुपचाप सब ठीक चला रहा था, बस लाइटें जलाए रखना तक मुश्किल से कर पा रहा था
गैर-तकनीकी management, जिसे मुश्किल से double-click समझ आता है, और उस engineering के बीच का disconnect जो वास्तव में company को संभालती है, इस industry में एक गंभीर समस्या है। इसका हल management का engineering background से आना छोड़कर और कुछ सूझता नहीं
कुछ समस्याओं में leadership को सीखने का मौका मिले, इसके लिए मरम्मत से पहले दर्द का संकेत ऊपर भेजना चाहिए
हालाँकि incentive design कठिन है, और top management ऐसा ढाँचा न बना दे जिसमें अधीनस्थ और departments दर्द व समस्याएँ दिखा ही न सकें। अच्छे इरादे से संकेत दबा देने वाले लोग भी आम हैं, इसलिए बड़े संगठनों में कभी-कभी कुछ समस्याओं को unfold होने देना और उन पर बहुत reactive न होना ज़्यादा प्रभावी हो सकता है — इसके लिए coaching की ज़रूरत होती है
जब सब लोग normal conditions और perfect operations मानकर design करते हैं, तब ऐसा व्यक्ति ज़रूरी है जो यह ढूँढ़े कि design, service, infra और app को कैसे तोड़ा जा सकता है
IT department के एक सहकर्मी को commercial certificates की जगह Let’s Encrypt अपनाकर और EV requirement हटाकर 2,000 euro से थोड़ा ज़्यादा मिल सकता था, लेकिन अंत में उसे कुछ नहीं मिला। वजह यह थी कि वह तो “उसकी सामान्य job” थी
जिन teams ने वास्तव में काम करने वाली services बनाईं, उनका budget freeze कर दिया गया और headcount तक कम कर दिया गया
जब दूसरी teams में कोई समस्या फूटे, तब हमारी team यह completed work list दिखाकर बता सकती है कि हमारे यहाँ वही समस्या क्यों नहीं हुई। काम पहले ही कर लिया गया था, बस ऐसे बेहतर समय पर जब downtime से बचा जा सकता था
ऐसा बहुत होता है। मुझे खास तौर पर यह बात पसंद है कि elegant solutions बाद में देखने पर अक्सर साधारण लगते हैं
आप लंबे समय तक सोचते हैं, फिर कोई चतुर समाधान निकालकर समझाते हैं, और सामने वाला कहता है, “हाँ, यह तो obvious है”
वहीं बगल में बैठा वह व्यक्ति जिसने समस्या को बेवजह बहुत जटिल बना दिया, उलटे इस बात के लिए सराहा जाता है कि उसने कितनी कठिन चीज़ बनाई
बड़ी companies शायद अब भी complexity से प्रभावित होने वाली दिशा में पीछे अटकी हों, लेकिन जो लोग सीधे या परोक्ष रूप से AI output प्राप्त कर रहे हैं, उनके लिए complexity अब पहले जितनी प्रभावशाली नहीं रही
जितना चमत्कारिक recovery हो, उतना ही वे “मेरे भांजे ने तो छोटी-मोटी समस्या तुरंत ठीक कर दी” जैसी बातें करते हैं, मानो यह दिखा रहे हों कि मैं वैसा नहीं कर पाया
उसके supervisor ने जटिल तरीका अपनाने की सलाह दी, क्योंकि तभी वह publish होगा। बात यह नहीं थी कि वह ज़्यादा बुद्धिमान लगे, बल्कि यह कि समाधान जटिल सुनाई देना चाहिए ताकि उसे मान्यता मिले
यह ठीक उसी वास्तविकता से मेल खाता है जहाँ सुंदर समाधान से ज़्यादा जटिल प्रक्रिया की तारीफ़ होती है, और शायद bureaucracy भी कुछ ऐसी ही पैदा हुई होगी
वह code release के 15 मिनट बाद भुला दिया गया और किसी ने उसे फिर कभी नहीं पढ़ा, लेकिन वह सालों तक इस्तेमाल होता रहा। इसी वजह से मुझे लगता है कि AI बहुतों की सोच से कहीं तेज़ jobs ले सकती है
clean code, separation of concerns, maintainability जैसी चीज़ें — जिन पर हम सबसे ज़्यादा समय लगाते हैं — असल में कभी properly reward ही नहीं हुईं। “काफ़ी ठीक-ठाक” स्तर management को संतुष्ट कर देता है, और जब समस्या आती है तो AI उस spaghetti mess पर भी patch लगा सकती है
मेरी पिछली नौकरी में भी ऐसी ही समस्या थी। मीटिंग्स शेड्यूल करना, और यह सुनिश्चित करना कि लोग मीटिंग से पहले ज़रूरी जानकारी के साथ आएँ, जैसी पर्दे के पीछे चलने वाली administrative work में मेरा लगभग सारा समय जाता था
लेकिन performance review के समय मुझे यही सुनने को मिला कि मैं चीज़ों को टूटने से बचाए रखने में इतना व्यस्त था कि ज़्यादा story points पूरे नहीं कर पाया
इसलिए मैंने सारा administrative work बंद कर दिया और सिर्फ story points पूरा करने पर ध्यान दिया, तो 1–2 हफ्ते बाद manager ने टीम से पूछा, “सारी मीटिंग्स बिखर क्यों रही हैं? मीटिंग में जाते ही किसी को पता नहीं होता कि क्या चल रहा है”
Y2K की तैयारी के लिए करीब 2 साल तक मैंने network, hardware, और IT का बहुत भारी काम किया, फिर marketing में जाना शुरू किया। आखिरकार लगभग हर company ने यह माना कि क्योंकि “कुछ हुआ ही नहीं,” इसलिए वह समय और पैसा बर्बाद गया
एक company ने तो पूरा refund माँग लिया, और जब मैंने कहा कि अगर मैं अपना किया हुआ काम वापस undo कर दूँ तो refund दे दूँगा, तो वे मान गए। अगले ही दिन उस company का पूरा system ध्वस्त हो गया
मेरे पिता की company के लिए network support संभालना भी मुश्किल था, क्योंकि वे मेरी fee कभी देना ही नहीं चाहते थे। जब दो और लोग समस्या हल नहीं कर पाए और मैंने उसे 15 मिनट में ठीक कर दिया, तो अब वे इस वजह से और भी कम पैसे देना चाहते थे कि इसमें सिर्फ 15 मिनट लगे
चीज़ों को टूटने से बचाए रखने की क्षमता की कोई कद्र नहीं थी; कद्र सिर्फ टूट जाने के बाद उसे ठीक करने की थी। Marketing में pay बेहतर था, और मैं हर दिन वास्तविक numbers के साथ अपनी salary justify कर सकता था। मुझे वह कहीं कम पसंद है, लेकिन मेरे किए किसी भी IT काम से ज़्यादा उसका सम्मान हुआ
मान्यता मिलती है printer ठीक करने, computer problem A/B/C ठीक करने, या दोस्तों के लिए बनाए गए बिना ads वाले Android Sudoku जैसी सरल चीज़ों के लिए
पैसे लेकर किए जाने वाले मुख्य काम की कद्र नहीं होती। लगता है कि कई industries में जैसे ही पैसे शामिल होते हैं, contract के तहत अपनी भूमिका निभाना स्वाभाविक मान लिया जाता है, इसलिए आभार कम हो जाता है
जिन्हें technology की समझ नहीं है, वे सोचते हैं कि developers घर से काम करते हुए दिन में सिर्फ 30 मिनट काम करते हैं, और AI ने उस छवि को और खराब कर दिया है
Ian Rush ने इसे अच्छी तरह कहा था: “Striker सबसे अच्छा होता है। वह पाँच मौके चूक जाए, फिर भी अगर winning goal कर दे तो hero बन जाता है। Goalkeeper शानदार बचाव करता रहे, लेकिन एक गोल खा ले तो villain बन जाता है”
मैंने जहाँ भी काम किया, वहाँ firefighter को उन लोगों से ज़्यादा reward मिला जो आग लगने ही नहीं देते थे। और इससे भी बुरा यह है कि incentive तय करने वाले लोगों को छोड़कर बाकी सबको यह हिसाब साफ़-साफ़ समझ में आता है
दूसरी तरफ़ भी एक समस्या है। कुछ लोग अपना सारा समय उन चीज़ों की चिंता में लगा देते हैं जो कभी होने वाली ही नहीं होतीं, इसलिए सिर्फ रक्षात्मक रवैये को reward कर देना भी समाधान नहीं है
नौकरी में promotion अक्सर ऐसे ही होता है। पहले कुछ तोड़ो, फिर मामला escalate होकर visible बनता है, फिर किसी executive को email जाता है। उसके बाद जब आप उसे “ठीक” कर देते हैं, तो सब आपकी तारीफ़ करते हैं
इसका एक और version यह है कि जो काम पहले से करना चाहिए था उसे देर तक टालो ताकि visibility बढ़े। Executive उन लोगों का काम देख ही नहीं पाते जो समस्या बनने से पहले ज़िम्मेदारी लेकर चीज़ें पूरी कर देते हैं
इसके बजाय, उन्हें उस व्यक्ति का नाम याद रहता है जिसने कुछ बिगाड़ा और फिर दिन “बचा” लिया
साथ ही executive की खुशामद करता है और कहता है, “इसे doublerabbit को न देना बेहतर है,” “यह team player नहीं लगता।” जबकि वह पूरा infrastructure मेरा था
यही वजह है कि लोग पूछते हैं कि मुझे इंसानों से इतनी नफ़रत क्यों है
यह बात मैंने पहली कक्षा में ही सीख ली थी। जो बच्चे क्लास में शांति से बैठे रहते हैं और homework कर लेते हैं, वे teacher का ज़्यादा समय और मेहनत नहीं लेते
ध्यान उन problem children को मिलता है जो नियम नहीं मानते, और पढ़ाई में ज़रा-सी कोशिश करने पर भी लगातार प्रशंसा चाहते हैं
IT में बिताया समय इन दो चरम सीमाओं के बीच झूलता रहा
“सब कुछ ठीक चल रहा है। हम IT पर पैसा क्यों खर्च कर रहे हैं?”
“सब कुछ टूट गया है। हम IT पर पैसा क्यों खर्च कर रहे हैं?”
निजी तौर पर मैं दूसरे की बजाय पहले वाले को लक्ष्य मानता हूँ। मैं कहा करता था, “अगर मैं अपना काम सही करूँ, तो तुम्हें पता भी नहीं चलेगा कि मैं यहाँ हूँ।” लेकिन इसी वजह से मुझे निकाल दिया गया
कर्म के स्तर पर, मैं अपनी पुरानी company के लोगों से अब भी संपर्क में हूँ, और अब वहाँ पूरा हाल बेहाल है। यही थोड़ी तसल्ली देता है
competency trap के बारे में पता चल जाए तो वह हर जगह दिखने लगता है
Sterman, Repenning और दूसरे collaborators ने इस paper के बाद भी कई और papers लिखे, और वे सभी दिलचस्प हैं, लेकिन लगभग सभी उदास करने वाले हैं
खासकर यह कि MIT Sloan, जहाँ system dynamics पहली बार एक discipline के रूप में स्थापित हुआ, ठीक Harvard Business School के पास है, जहाँ system dynamics को सबसे पहले नज़रअंदाज़ किया गया था