Software productivity को घटाने के सरल तरीके (2023)

तकनीक

• मुख्य सिस्टम को 6-18 महीनों तक फिर से लिखने की मांग करें। पिछले CTO को दोष दें।
• प्रोत्साहित करें कि हर व्यक्ति अलग भाषा और framework इस्तेमाल करे।
• सिस्टम को मनमानी सीमाओं पर विभाजित करें ताकि एक feature में कई सिस्टम शामिल हों।
• जटिल development environment बनाएं। कम से कम 12 services वाला service mesh चलाने को कहें।
• production environment और developer environment को जितना हो सके उतना अलग बनाएं।
• deployment जितना संभव हो उतना कम करें। deployment के बारे में अत्यधिक सावधान रहने की सलाह दें।
• code changes और सामान्य workflow में बहुत जटिल process लागू करें। बहाना दें कि यह "security" या "compliance" के कारण है।
• हर काम को task tracker में दर्ज कराएं और कम से कम 5 लोगों के समूह से review, prioritization और approval कराएं।
• मूल कार्य-क्षेत्र के बाहर की हर चीज़ पर रोक लगाएं। उदाहरण के लिए code cleanup या अन्य improvement work पर प्रतिबंध लगाएं।
• जो लगभग कुछ भी core competency नहीं है, उसे भी in-house बनाएं। इसे "vendor lock-in से बचने" के नाम पर सही ठहराएं।
• हर चीज़ में abstraction layer जोड़ने पर अड़े रहें। abstracted vendors इस्तेमाल करें और एक अतिरिक्त abstraction layer भी जोड़ें।
• अवास्तविक रूप से आशावादी scale के आधार पर technical decisions लेने को बढ़ावा दें। मौजूदा load से कम से कम 3 गुना अधिक के लिए योजना बनाएं।
• सिस्टम की shared ownership को बढ़ावा दें। ताकि किसी को maintenance की जिम्मेदारी महसूस न हो।
• लगभग हर चीज़ को "platform" के रूप में केंद्रीकृत करने पर जोर दें। platform team को understaffed रखें और दूसरी teams को वह चीज़ें बनाने से रोकें जो platform own कर सकता है।
• platform team से API को बार-बार बदलवाएं और दूसरी teams को latest version पर code refactor करने के लिए मजबूर करें।
• "architects" को hire करें और छोटे बदलावों के लिए भी "architecture review" अनिवार्य करें।
• छोटे बदलावों के लिए भी "security review" अनिवार्य करें।

उत्पाद

• उपयोगी metrics को अकादमिक कारणों से अनदेखा करें। उदाहरण के लिए उन्हें "bias" या "lagging metrics" कहें।
• ऐसी vanity metrics चुनें जिनका business value से कोई संबंध न हो। noisy metrics चुनें।
• हर चीज़ को "big bet" मानें और जोर दें कि जब तक सब कुछ पूरी तरह तैयार न हो, तब तक release न किया जाए।
• हर feature को "must-have" मानें और उसे "version zero" का महत्वपूर्ण हिस्सा घोषित करें। कभी समझौता न करें।
• बहुत विस्तृत "strategic" plans बनाएं।
• दिशा बार-बार बदलें।
• स्पष्ट improvements को "local optimization" कहकर खारिज करें।
• नवीनतम trends का इस्तेमाल करके resources को बांध दें। ऊपर-ऊपर से विश्वसनीय लगने वाली "AI strategy" शुरू करें। इसके लिए vendors और consultants पर बहुत पैसा खर्च करें।
• product managers को प्रोत्साहित करें कि वे अपना अधिकांश समय "strategy" और "planning" पर बिताएं।
• engineers और product managers के लिए internally product का इस्तेमाल करना कठिन या असंभव बना दें।
• internally users को "idiots" समझकर नज़रअंदाज़ करें।

नेतृत्व

• rewards को titles और team size से जोड़ दें ताकि अनावश्यक विस्तार को बढ़ावा मिले।
• strategy, features या technical complexity के बारे में ऊंची-ऊंची बातें करें।
• नए product area में प्रवेश करने के लिए महंगे acquisitions करें। "synergy" का उल्लेख करें। acquired product को बंद कर दें।
• reporting structure में बहुत सारी dotted lines रखें।
• जितना संभव हो उतने लोग किसी दूसरी team, location या function के manager को report करें। सुनिश्चित करें कि managers अपनी reports को effectively supervise न कर सकें।
• low performers को बार-बार दूसरी teams में स्थानांतरित करें।
• high performers को ऐसे बहुत speculative R&D projects में लगाएं जिनके deliverables अनिश्चित हों।
• छोटे फैसलों के लिए भी हमेशा meetings अनिवार्य करें।
• जोर दें कि हर "stakeholder" को meetings में शामिल होना चाहिए।

भर्ती

• ऐसा hiring process बनाएं जो ऊपर से objective दिखे लेकिन वास्तव में subjective हो।
• "culture fit की कमी" या अन्य अस्पष्ट मानदंडों के आधार पर सर्वश्रेष्ठ प्रतिभा को reject करें।
• "potential" या "attitude" या अन्य अस्पष्ट मानदंडों के आधार पर सबसे कमजोर candidates को hire करें।
• बहुत महंगे senior leaders को hire करें जिनके साथ बड़े headcount commitments हों।
• अवसरवादियों को आकर्षित करने के लिए inflated titles और गढ़ी हुई भूमिकाओं का इस्तेमाल करें।
• अत्यधिक specialized "experts" को hire करें, फिर उन्हें कंपनी में बनाए रखने के लिए कृत्रिम projects बनाएं।
• specialization का इस्तेमाल दूसरे complementary लोगों को hire करने के औचित्य के रूप में करें।

परियोजना प्रबंधन

• हर project के लिए बहुत विस्तृत estimates की मांग करें।
• ऐसे projects को बढ़ावा दें जो जितनी संभव हो उतनी teams में फैले हों, आदर्श रूप से अलग-अलग locations में।
• नई requirements जोड़ें जो दूसरी teams द्वारा किए गए काम पर निर्भर हों।
• महंगी agencies का बार-बार इस्तेमाल करें। scope को अस्पष्ट रखें और अधूरे prototypes internal team को पूरा करने के लिए सौंप दें।
• दूसरी teams के stakeholders के लिए जटिल "self-service" systems बनाएं।

परिणाम

• productivity को गिराना आसान काम नहीं है। लेकिन अगर आप दुश्मन के पीछे parachute से उतरकर CTO बन जाएं, तो यह संभव है।
• जो लोग विनाशकारी नहीं हैं, उनके लिए: यह दरअसल टीम की productivity को अधिकतम करने के तरीकों की कहानी है। productivity कई छोटी चीज़ों के जोड़ से बनती है।
• अगर 100 छोटी चीज़ें प्रत्येक 5% productivity tax लगाएं, तो सब कुछ 131 गुना धीमा हो जाता है। engineers को खुश रखना है तो उन 100 छोटी लेकिन ऊपर से उचित लगने वाली चीज़ों को ठुकराना होगा।

GN⁺ की राय

• यह लेख software development में productivity को नुकसान पहुंचाने के कई तरीकों को हास्यपूर्ण ढंग से समझाता है। इससे यह स्पष्ट होता है कि व्यवहार में किन चीज़ों से बचना चाहिए।
• technical debt को कम रखना और कुशल development culture बनाए रखना महत्वपूर्ण है। अनावश्यक complexity और bureaucracy से बचना ही मुख्य बात है।
• ऐसा environment बनाना महत्वपूर्ण है जो टीम का morale बढ़ाए और collaboration को प्रोत्साहित करे। इसका productivity improvement पर सीधा प्रभाव पड़ता है।
• यह लेख software engineering और management की जटिलताओं को समझने में मदद करता है। खासकर junior engineers के लिए यह उपयोगी insights देता है।
• इसी तरह की थीम वाले अन्य projects में "The Phoenix Project" जैसी किताबें शामिल हैं। वे IT और DevOps की efficiency बढ़ाने के तरीकों पर चर्चा करती हैं।

[rockmkd]

क्या ऐसी कोई कंपनी है जो ऐसा नहीं करती? T_T
छोटी और सफल कंपनी भी जब बड़ी होती है, तो लगता है कि सब ऐसी ही हो जाती हैं...

[vvvvvv]

इसमें ज़्यादातर वही चीज़ें शामिल हैं जो मुझे पिछली कंपनी में करने के लिए कहा गया था—ऐसे platform का ज़बरदस्ती इस्तेमाल जिसे काम में भी नहीं लाया जा सकता, standard performance metrics को नज़रअंदाज़ करना, पहले किए हुए task फिर से करवाना, वगैरह।

[dkswjdrka]

उह..?

[whitetor]

यह तो बिल्कुल 'मेंटेन करना मुश्किल कोड लिखने का तरीका: आप भी डेवलपर बनकर ज़िंदगी भर आराम से खा सकते हैं'...

[bus710]

मैं नाश्ता छोड़ दूँगा.

[eyelove]

आह.. आह!.. आह!!.. अरे!... आह......

दुर्भाग्य से हमारी organization के अंदर भी इनमें से कुछ चीज़ें दिखती हैं. sniff sniff

[wedding]

मुझे दिग्गज किताब "कोड को maintain करना मुश्किल कैसे बनाएं" याद आ रही है।

[laeyoung]

मुझे भी यह किताब!

[gcback]

इतना ज़्यादा? ऐसा सोचा जा सकता है, लेकिन ऐसा भी लगता है कि ऊपर की बातों को कोई एक व्यक्ति या एक संगठन हासिल कर सकता है.^^

[GN⁺]

Hacker News राय

• इस बात पर भरोसा कम है कि CIA के सुझाव वास्तव में असरदार थे: मैंने कभी कोई ठोस वजह नहीं देखी कि CIA के मूल सुझाव सच में काम करते थे, और संगठन स्वाभाविक रूप से ऐसे लोगों को नज़रअंदाज़ करने की प्रवृत्ति रखते हैं.

• कंपनी को बर्बाद करने का तरीका: खराब लोगों को मैनेजमेंट पदों पर प्रमोट करना और गैर-लाभकारी चीज़ों को optimize करने देना कंपनी को बड़ा नुकसान पहुँचा सकता है.

• विनाशकारी CTO बनने का तरीका: लगभग कुछ भी न करना, सक्षम लोगों को हटाना, और ज़िम्मेदारी नीचे धकेलने वाली संस्कृति बनाना आसान है.

• औपचारिक चैनलों से काम और लिखित आदेश की मांग: कुछ लोगों के लिए औपचारिक चैनलों के जरिए काम करना और लिखित आदेश माँगना ज़्यादा उत्पादक हो सकता है.

• OSS और CIA के बीच अंतर: OSS (Office of Strategic Services) ने द्वितीय विश्व युद्ध के दौरान एक बेहतरीन किताब बनाई थी, और CIA की स्थापना 1947 में हुई थी.

• विजन का महत्व: ऐसे लोगों को हटाना जिनके पास उत्पाद के समग्र काम करने के तरीके या बेहतर भविष्य को लेकर एक सुसंगत vision हो, सबसे अहम कदम है.

• हायरिंग सेक्शन को अपडेट करने की ज़रूरत: Leetcode के कठिन सवाल 30 मिनट के भीतर हल करने की मांग करना, और अनिश्चितता व संदेह को बर्दाश्त न करना ज़रूरी है.

• प्रोडक्शन environment और डेवलपर environment का अंतर: आधुनिक architecture में इतने external services होते हैं कि production environment और developer environment का अलग होना तय है, और इसका मतलब है कि developers को हमेशा इंटरनेट से जुड़े रहना होगा.

• खुद को बचाने के लिए फैसले: "sabotage" के लिए लिए जाने वाले कई फैसले इस बात से जुड़े होते हैं कि लोग अपनी गलतियों को छिपाने की कोशिश को सही ठहराना चाहते हैं.

• कंपनी में "best practices": लेख की शुरुआत में दिए गए आठ नियमों का कंपनी में "best practices" के रूप में सख्ती से पालन किया जा रहा है.

• consultants का व्यवहार: बहुत से consultants इनमें से ज़्यादातर, अगर सभी नहीं, ऐसे व्यवहार करते हैं.

• टेक उद्योग की समस्या: टेक उद्योग में ऐसे व्यवहार करने वाले लोग बहुत हैं, और वे सचमुच मानते हैं कि वे मदद कर रहे हैं.

• बड़ी कंपनी में अनुभव: बड़ी कंपनी में मेरा सीमित अनुभव इस लेख की बातों से बहुत मेल खाता है.