बड़ी कंपनियों पर | मूल, AI द्वारा अनुवादित
विषय-सूची
- बड़ी कंपनियों के बारे में
- टैलेंट डेंसिटी टीम के आकार से ज़्यादा मायने रखती है
- प्रक्रियाएँ कर्मचारियों पर भरोसे की जगह ले लेती हैं
- जोखिम से बचने की प्रवृत्ति नवाचार को रोकती है
- स्टार्टअप्स एंटरप्राइज़ेज़ की तुलना में तेज़ी से तैनाती करते हैं
- नौकरशाही व्यक्तिगत जिम्मेदारी को छिपाती है
- बड़ी कंपनियों में इंजीनियरिंग
- नियम स्थिरता लाते हैं लेकिन रचनात्मकता को सीमित करते हैं
- ऑटोमैटेड चेक्स सूक्ष्म डिज़ाइन क्वालिटी को मिस करते हैं
- टेस्टिंग टूल्स स्ट्रैटेजिक मूल्यांकन की गहराई तक नहीं पहुँचते
- मोनोलिथिक सिस्टम्स तेज़ स्केलिंग का विरोध करते हैं
- रिडंडेंट वर्कफ़्लोज़ ज्ञान को बनाए रखने में मदद करते हैं
- सहयोग के बारे में
- टीम्स मॉड्यूलर कोड ऑर्गनाइज़ेशन को दर्शाती हैं
- टास्क ओनरशिप संचार के ओवरहेड को कम करती है
- पारदर्शिता रियल-टाइम अलाइनमेंट की जरूरत को कम करती है
- AI टूल्स व्यक्तिगत योगदान को बढ़ाते हैं
- मिसमैच्ड अपेक्षाएँ प्रोजेक्ट की सफलता को बाधित करतीं हैं
बड़ी कंपनियों के बारे में
बड़ी कंपनियाँ बिल्कुल बड़े प्रोग्राम्स की तरह होती हैं। 100,000 कर्मचारियों और 50,000 कॉन्ट्रेक्टर्स वाली एक बड़ी कंपनी, 150,000 मेथड्स वाले एक बड़े प्रोग्राम की तरह होती है।
डारियो अमोदेई ने कहा था कि टैलेंट डेंसिटी टैलेंट की संख्या से कहीं ज़्यादा महत्वपूर्ण होती है। 200 अत्यंत प्रतिभाशाली लोग, 800 सामान्य लोगों के साथ 1,000 प्रतिभाशाली लोगों को हरा सकते हैं।
डारियो अमोदेई ने यह भी कहा कि बड़ी कंपनियों में इतनी सारी प्रक्रियाएँ और प्रोसेस इसलिए होते हैं क्योंकि वे अपने कर्मचारियों या कॉन्ट्रेक्टर्स पर भरोसा नहीं करतीं। इसलिए उन्हें बहुत सारी चीजों की जाँच और नियंत्रण की जरूरत होती है।
बड़ी कंपनियों की एक विशेषता यह है कि वे गलतियाँ करने से डरती हैं। एक कारण यह है कि वे 300 अरब या 1 ट्रिलियन डॉलर की वैल्यू तक पहुँचने के लिए इतनी बड़ी हो चुकी होती हैं; उन्होंने निश्चित रूप से बहुत सारी गलतियाँ की होंगी और उनसे सीखकर आगे बढ़ी होंगी। लेकिन जब वे सफल हो जाती हैं, तो वे फिर से जोखिम लेने और गलतियाँ करने से बचती हैं।
यह एक बड़े प्रोग्राम की तरह है जो बग्स को पसंद नहीं करता और किसी भी बग, खासकर सुरक्षा संबंधी बग्स को खत्म करने की कोशिश करता है, खासकर बड़े बैंकों में।
स्टार्टअप्स तेज़ होते हैं, लेकिन उनके पास संसाधन कम होते हैं, और उनका ब्रांड स्थापित नहीं होता; उनके पास बड़ी कंपनियों जितना भरोसा नहीं होता।
चीन में, युवा प्रतिभाशाली लोग अभी भी ग्रेजुएशन के बाद बड़ी कंपनियों में जाना चाहते हैं और इसके लिए संघर्ष करते हैं। सिलिकॉन वैली में, कई स्टार्टअप्स हैं, जिनमें से कुछ शुरुआत में ही सिर्फ आइडियाज़ के साथ अच्छा कर रहे हैं।
कुछ कंपनियाँ 20 साल तक संघर्ष करती हैं और फिर भी स्टॉक मार्केट से हटा दी जाती हैं, जबकि कुछ कंपनियों की वैल्यू सिर्फ कुछ महीनों में ही 5 अरब या 10 अरब डॉलर तक पहुँच जाती है।
इसी तरह, मीरा मुराती की थिंकिंग मशीन्स लैब सीड राउंड में $12B की वैल्यूएशन प्राप्त करती है, और इल्या सुत्स्केवर की सेफ सुपरइंटेलिजेंस $2B फंडिंग पर $32B वैल्यूएशन प्राप्त करती है।
इसलिए, स्टार्टअप को स्थापित समय से मापना अच्छा संकेत नहीं है; बेहतर है कि उसे टीम की क्षमता, संस्थापकों की पहचान, और उनके कार्यक्षेत्र से मापा जाए।
मेरे सोलो स्टार्टअप में, मुझे अपने बैकएंड सर्वर को डिप्लॉय करने में सिर्फ 1 मिनट लगता है और एक मामूली बग को ठीक करने और डिप्लॉय करने में 5 मिनट। यह सीधा और तेज़ है। बड़ी कंपनियों में, डिप्लॉयमेंट रिक्वेस्ट तैयार करने, मैनेजर्स से अनुमति लेने, IT टीम के साथ डिप्लॉयमेंट करने और हेल्थ चेक करने में 1 हफ्ता लगता है।
हालांकि वास्तविक समय 8 घंटे हो सकता है, लेकिन अगर हम मापें, तो डिप्लॉयमेंट की तैयारी से लेकर अंतिम हेल्थ चेक तक 1 हफ्ता लगता है।
एक मामूली बग को ठीक करने और डिप्लॉय करने में दो हफ्ते लगते हैं। आपको टिकट मिलता है, जाँच होती है, एनालिसिस और टेस्टिंग होती है, फिर रिव्यू होता है, कोड मर्ज होता है, टेस्ट टीम को टेस्ट करने के लिए रिपोर्ट किया जाता है, और फिर डिप्लॉयमेंट होता है।
बड़ी कंपनियाँ अपनी पॉलिसीज़ को सभी टीम्स या प्रोजेक्ट्स पर लागू करना पसंद करती हैं। क्योंकि 200,000 लोगों वाली कंपनी के लिए, वे पॉलिसीज़ या इंटरनल प्रोसेस जो सिर्फ 10,000 लोगों पर लागू होती हैं, उनका कोई खास मतलब या परिणाम नहीं होता। कुछ इंटरनल प्रोसेस के लिए, बड़ी कंपनियों को उन्हें सपोर्ट करने के लिए टूल्स डेवलप करने में पैसा या लोग लगाने की जरूरत होती है। इसलिए अगर यह सिर्फ एक छोटे हिस्से को सर्व करता है, तो निवेश का परिणाम उचित नहीं होता।
बड़ी कंपनियों में एक और नकारात्मक पहलू यह है कि अक्सर बड़ी गलतियों के लिए किसी को सजा नहीं मिलती।
मेरे स्टार्टअप में, एक बार मुझे 9 लोगों को हायर करने के लिए आधा मिलियन डॉलर का निवेश मिला, और 2 महीने बाद मुझे उन्हें जाने देना पड़ा और वह पैसा खो दिया। मुझे उस निवेशक को पैसा वापस देने के लिए 50 छोटे सॉफ्टवेयर प्रोजेक्ट्स पार्ट-टाइम इंजीनियर्स के साथ करके वह पैसा वापस कमाना पड़ा।
यह एक बेहद तीव्र और दर्दनाक याद है। और इसने मुझे हमेशा उस सबक को याद रखने पर मजबूर किया।
एक बड़ी कंपनी के एक उल्लेखनीय मामले में, यह देखा गया कि शामिल लोगों के लिए कोई महत्वपूर्ण परिणाम नहीं हुआ। कुछ सीनियर मैनेजर्स और नए हायर किए गए कर्मचारियों को जाने दिया गया। यह स्पष्ट नहीं था कि यह तेज़ और बड़े पैमाने पर हायरिंग के कारण हुआ था या नहीं।
इसका एक कारण बड़ी कंपनियों में बहुत सारी जटिल प्रक्रियाएँ होती हैं। जो इंजीनियर्स 6 महीने से 1 साल से कंपनी में थे, वे कोई महत्वपूर्ण योगदान नहीं दे पाए। टाइमलाइन में आमतौर पर 2 महीने बेसिक्स समझने में, 3 महीने प्रोजेक्ट से परिचित होने में, 3 महीने थकाऊ प्रक्रियाओं या टेस्टिंग में, और अंत में 2 महीने प्रोडक्टिव काम में लगते थे जिससे उपयोगकर्ताओं पर प्रभाव पड़ता।
अगर हम 8 घंटे के वर्कडे को मानें, तो 2 महीने का वास्तविक प्रोडक्टिव काम किसी बड़े परिणाम की ओर नहीं ले जाता। डिपार्टमेंट का बजट खत्म हो गया, और उपयोगकर्ताओं का आधार जैसा अपेक्षित था वैसा नहीं बढ़ा, जिसके कारण और लेयऑफ्स हुए।
ऐसा लगा कि इस अनुभव से कोई सबक नहीं सीखा गया। शुरुआत में, मैनेजर्स का एक समूह तेज़ और बड़े पैमाने पर हायरिंग की रणनीति पर सहमत हुआ, जो उस समय अनावश्यक लग रहा था। पूरे मैनेजमेंट ग्रुप को दोष देना संभव नहीं था, न ही सिर्फ उन्हें हटाना जो कम समय से कंपनी में थे, खासकर जब अन्य मैनेजर्स और टेक्निकल लीड्स 6-8 साल से टीम का हिस्सा थे।
मैनेजिंग डायरेक्टर को इस स्थिति से ज्यादा अंतर्दृष्टि नहीं मिली, क्योंकि यह उनके अधीन तीन डिपार्टमेंट्स में से सिर्फ एक था, और उनका मुआवज़ा अपरिवर्तित रहा। टीम के भीतर भी, जो सीधे जिम्मेदार नहीं थे, वे इस अनुभव से कुछ नहीं सीख सके, जैसा कि स्टीव जॉब्स ने कंसल्टिंग पर टिप्पणी की थी। परिणामस्वरूप, कोई भी उस सबक को नहीं सीख पाया जो एक असाधारण टीम बनाने और उपयोगकर्ताओं के लिए बेहतरीन परिणाम देने के लिए जरूरी था।
स्टार्टअप्स के लिए, यह स्थिति ज्यादा बेहतर लगती है। क्योंकि यह वास्तव में गंभीर होता है। कुछ फाउंडर्स जो हार जाते हैं या असफल होते हैं, उन्हें वास्तव में मुश्किल समय होता है, खासकर ईमानदार लोगों को।
ईमानदारी वाले व्यक्तियों के लिए, लाखों से लेकर सैकड़ों मिलियन डॉलर तक का निवेश खो देने और फिर सिर्फ एक बुनियादी प्रोडक्ट या एक उपयोगकर्ता आधार के साथ समाप्त होना, जो शायद बहुत कम रेवेन्यू जनरेट करता है, बेहद निराशाजनक हो सकता है।
पॉल ग्राहम ने एक बार एक निबंध लिखा था, हायरिंग इज ओब्सोलीट।
लेकिन बड़ी कंपनियाँ क्या अच्छा करती हैं? एक तो यह कि वे दीर्घकालिकता को प्राथमिकता देती हैं। वे चीजों को लंबे समय के लिए करती हैं। कुछ अच्छी बड़ी कंपनियों के प्रोजेक्ट डिज़ाइन काफी अच्छे होते हैं; वे माइक्रोसर्विसेज़ का इस्तेमाल करते हैं ताकि एक दशक बाद एक बड़े मोनोलिथिक प्रोग्राम बनने की गलती से बचा जा सके। और उनके पास गवर्नेंस टीम्स होती हैं जो कुछ बुनियादी फ्रेमवर्क बनाती हैं और पूरी टीम के लिए डेवलपमेंट प्रैक्टिसेज़ को एकीकृत करती हैं।
प्रोसेस या प्रक्रियाएँ अपने आप में बुरी नहीं होतीं। लेकिन वे अक्सर चीजों को जटिल और धीमा बना देती हैं। हमें Java के यूनिफाइड कोड फॉर्मेट से कोई परेशानी नहीं होती क्योंकि Spotless या Checkstyle प्लगइन मदद करते हैं। ये प्लगइन्स अच्छे डिज़ाइन वाले हैं और इस्तेमाल में आसान हैं।
एक और बात यह है कि बड़ी कंपनियाँ अक्सर फ्रंट ऑफिसर्स के लिए आंतरिक उपयोग के कुछ टूल्स या प्रोजेक्ट्स बनाती हैं। लेकिन उनका यूजर बेस सिर्फ कुछ सौ या 10,000 होता है। यह बहुत सीमित होता है।
मेरा मानना है कि इस उद्देश्य के लिए हमें एक्सटर्नल टूल्स का उपयोग करना चाहिए। अगर कोई टूल एक बैंक के लिए वाकई अच्छा है, तो वह लगभग 200 बैंक्स के लिए अच्छा हो सकता है। और इससे कंपनी को यूनिकॉर्न बनने में मदद मिल सकती है।
पोनी.एआई के फाउंडर, लू तियानचेंग, कहते हैं कि कंपनियों को स्वतंत्र होने की जरूरत इसलिए है क्योंकि यह ज्यादा कुशल होता है। यह सही है।
और बड़ी कंपनियाँ अक्सर कर्मचारियों को इनाम देने के लिए अनुभव का उपयोग करती हैं। जबकि मार्केट स्टार्टअप टीम्स को रिजल्ट या एक्जीक्यूशन के आधार पर इनाम देता है। यह वास्तव में बहुत अलग होता है।
बड़ी कंपनियों में काम करना स्कूल में पढ़ने जैसा होता है। आप प्राइमरी स्कूल से मिडिल स्कूल, और फिर यूनिवर्सिटी तक प्रोग्रेस करते हैं। स्टार्टअप्स में, हालांकि, ज्यादा उतार-चढ़ाव होते हैं, और जैसे ही आप एक आइडिया या मार्केट से दूसरे में जाते हैं, लचीलापन ज्यादा होता है।
बड़ी कंपनियों के लिए जोखिम से बचने का लाभ यह है कि उनके प्रोडक्ट्स अपेक्षाकृत स्थिर होते हैं जिनमें कोई स्पष्ट बग या डाउनटाइम नहीं होता। यह अच्छा है।
लेकिन AI जैसे क्षेत्र में, वास्तव में कई उपयोगकर्ता शुरुआती दौर में अस्थिर प्रोडक्ट्स को लेकर ठीक होते हैं, जैसे deepseek। हम जानते हैं कि deepseek फरवरी-मार्च 2025 में काफी डाउन होता था जब इसने बहुत अधिक ध्यान आकर्षित किया। लेकिन कुछ समय बाद, यह बेहतर हो गया और उपयोगकर्ताओं को इससे ज्यादा समस्या नहीं हुई।
इसलिए यह निर्भर करता है। कभी-कभी, इनोवेटिव प्रोडक्ट्स के लिए, हमें उन्हें कुछ मुद्दों के साथ ही जल्दी मार्केट में लाना होता है। उपयोगकर्ता समझ सकते हैं।
अगर हम प्रक्रिया के बारे में सोचें, तो हम अधिक सावधान हो सकते हैं। हमें अपने डिप्लॉयमेंट टाइप्स को बेहतर ढंग से कैटेगराइज़ करना चाहिए। कुछ प्रकार के बदलावों को जल्दी डिप्लॉय करना ठीक है, जबकि अन्य को नहीं। टेस्टिंग के लिए, हमें कैटेगराइज़ करना चाहिए कि बदले गए कोड के लिए रिग्रेशन टेस्टिंग के किन हिस्सों की जरूरत है, और किन हिस्सों की नहीं। SonarQube चेकिंग के लिए भी यही लागू होता है।
बड़ी कंपनियों में, निश्चित रूप से कई चेक्स, टेस्ट्स या अनुमतियाँ अनावश्यक होती हैं। हम इंजीनियर्स को अपना काम करने दे सकते हैं, और क्योंकि सिस्टम में सभी रिकॉर्ड्स होते हैं, हम कुछ को रिव्यू के लिए चुन सकते हैं।
हमें सभी मैनेजर अनुमतियों को भी खत्म कर देना चाहिए। मैनेजर्स के पास ऐसा क्या ज्ञान है जो इंजीनियर्स के पास नहीं है? क्या इस ज्ञान को कोड में लिखकर रिक्वेस्ट्स को ऑटोमेटिकली स्वीकार या रिजेक्ट करने के लिए इस्तेमाल किया जा सकता है?
क्योंकि वहाँ सबकुछ धीमा है, कर्मचारियों के लिए चीजों को बदलना मुश्किल होता है। एक दशक से चल रहे बड़े मोनोलिथिक प्रोजेक्ट को माइक्रोसर्विसेज़ में बदलने में दो साल लग सकते हैं।
सॉफ्टवेयर में, कोड और लॉजिक आपस में बहुत जुड़े होते हैं, खासकर अच्छी तरह डिज़ाइन किए गए सिस्टम्स में। इसलिए इसमें शामिल डेवलपमेंट, टेस्टिंग या सहयोग बहुत अधिक हो सकता है।
इसीलिए अचानक टीम को स्केल करना अक्सर काम नहीं करता। यदि एक माइक्रोसर्विस आर्किटेक्चर है जो ढीले तरीके से जुड़ा हुआ है, तो टीम का आउटपुट टीम के सदस्यों की संख्या के समानुपाती हो सकता है। यदि एक मोनोलिथिक प्रोजेक्ट है जो सख्ती से जुड़ा हुआ है, तो टीम का आउटपुट सिर्फ 30% बढ़ सकता है भले ही हम उस पर काम करने वाली टीम को दोगुना कर दें।
इसकी धीमी गति के कारण, कभी-कभी यह जानना मुश्किल हो जाता है कि कोई कर्मचारी या कॉन्ट्रेक्टर अक्षम है या सिस्टम इतना जटिल और थकाऊ है कि नए लोगों के लिए समझ पाना मुश्किल है। एक मामले में, मैंने देखा कि कोई व्यक्ति 4 महीने से कंपनी में था और उसने बहुत कम किया था, सिर्फ कुछ लाइन्स को कोड बदलकर पुल रिक्वेस्ट सबमिट किया था। इससे भी बदतर, कोड की क्वालिटी खराब थी क्योंकि वह इसे ठीक से समझ नहीं पाया था। उसकी अंग्रेजी भी बहुत कमजोर थी, और वह सिर्फ स्क्रीनशॉट पेस्ट करके और बुनियादी अंग्रेजी में सवाल पूछकर ही कम्यूनिकेट कर पाता था।
स्थिरता के बारे में, मैं देखता हूँ कि बड़ी कंपनियाँ अक्सर टीम के कई सदस्यों को डुप्लीकेट टास्क्स पर काम करवाती हैं। उदाहरण के लिए, टास्क A और टास्क B के लिए, वे दो टीम इंजीनियर्स को अलग-अलग A और B पर काम करने के बजाय, दोनों को A और B के कुछ हिस्सों पर काम करने देती हैं ताकि ये इंजीनियर्स एक-दूसरे के काम से परिचित हों। इससे टीम अधिक स्थिर हो जाती है, क्योंकि यह उस स्थिति से बचती है जहाँ सिर्फ एक व्यक्ति कोड के बड़े हिस्से के बारे में बहुत कुछ जानता है और सालों से उस पर काम कर रहा होता है बिना किसी सहयोग के। फिर, अगर वह व्यक्ति कंपनी छोड़ देता है, तो कोई और उस पर काम नहीं कर पाता।
बड़ी कंपनियाँ कैश फ्लो और प्रॉफ़िट डिसिप्लिन को बनाए रखने में अच्छी होती हैं। कारण यह है कि जैसे-जैसे वे बड़ी होती जाती हैं, उन्हें अक्सर भारी वित्तीय संकटों का सामना करना पड़ता है। यह शायद सबसे महत्वपूर्ण चीज़ है जिसे वे प्राथमिकता देती हैं। उन्होंने इसे मुश्किल तरीके से सीखा है और इन प्रैक्टिसेज़ को अपने ऑपरेशन्स में शामिल कर लिया है। भले ही वे सालाना 10 अरब डॉलर या 30 अरब डॉलर का मुनाफा कमा रही हों, फिर भी वे अपने वर्कफोर्स को ऑप्टिमाइज़ करती रहती हैं और लेयऑफ्स करती रहती हैं।
मेरे एक सहकर्मी ने मुझे बताया कि बड़ी कंपनियाँ कुछ प्रोडक्ट्स पर एकाधिकार के साथ काम करती हैं जिन्हें बनाने में बहुत अधिक श्रम या समय लगता है। यह समझ में आता है। वे स्पीड पर नहीं, बल्कि अपने आकार, संसाधनों और ब्रांड पर भरोसा करती हैं।
बड़ी कंपनियों में कैसे जीवित रहें? एक तो यह कि ज्यादा करें, कम बोलें। यह मेरे एक आउटसोर्सिंग वेंडर में डिलीवरी मैनेजर ने मुझे बताया था।
दूसरी बात यह है कि दूसरों जैसा करें; यह सुरक्षित है। टीम में एक औसत इंजीनियर बनना सुरक्षित है, जैसे सड़क पर एक औसत व्यक्ति होना—ना बहुत उत्कृष्ट, ना बहुत उपेक्षित, बल्कि ठीक बीच में।
मुझे कहना पड़ेगा कि कई बड़ी कंपनियाँ हैं। कुछ में 200,000 से ज्यादा कर्मचारी हैं, जबकि कुछ में लगभग 20,000। अच्छी बड़ी कंपनियाँ भी हैं और खराब प्रदर्शन करने वाली भी। उनका रूप-रंग या मार्केट कैप कभी-कभी ज्यादा नहीं बताता। वे NVIDIA की तरह कुछ ही सालों में काफी बढ़ सकती हैं, या Credit Suisse की तरह अचानक गिर सकती हैं।
बड़ी कंपनियों में इंजीनियरिंग
बड़ी कंपनियाँ अपनी सख्त पॉलिसी कंट्रोल और मैनेजमेंट में अच्छी होती हैं। बड़ी कंपनियाँ सावधानीपूर्वक चेकिंग और थोरो सॉफ्टवेयर रिलीज़ मूल्यांकन में अच्छी होती हैं।
लेकिन बहुत सारी इंजीनियरिंग को सीधे नियमों में नहीं बाँधा जा सकता। हर मेथड या हर Java क्लास के डिज़ाइन की सरलता और ऑप्टिमाइज़ेशन को नियमों से चेक करना आसान नहीं होता।
SonarQube स्कैन एक अच्छी चीज़ है, और हाई टेस्टिंग कवरेज भी अच्छा है। लेकिन बहुत सारे सॉफ्टवेयर डिज़ाइन या इंजीनियरिंग को इतनी आसानी से मापा नहीं जा सकता।
APIs की गुणवत्ता और फंक्शनैलिटीज़ के उपयोग में आसानी को आसानी से मूल्यांकित नहीं किया जा सकता।
मेथड्स के पैरामीटर्स को आसानी से मूल्यांकित नहीं किया जा सकता। फंक्शन्स का डिज़ाइन, ब्रांच स्ट्रैटेजी, डेवलपमेंट स्ट्रैटेजी आसानी से मापने योग्य नहीं होते, और न ही नामकरण।
अलीबाबा का अपना Java गाइड है, और Google और Plantier का अपना Java फॉर्मेट है। यह अच्छा है। लेकिन Java प्रोजेक्ट की हर चीज़ को कोड से ऑटोमेटिकली चेक नहीं किया जा सकता।
टेस्टिंग के बारे में, यह सही है। बहुत सारे ऑटो टेस्टिंग टूल्स हैं। लेकिन सभी टेस्ट स्ट्रैटेजी, डिज़ाइन, फिलॉसफी या तकनीकों के लिए तय नियम नहीं होते।
प्रोडक्ट्स के बारे में, यह सही है। बहुत सारे A/B टेस्टिंग और डेटा-ड्रिवन प्रोडक्ट डेवलपमेंट होते हैं। लेकिन सभी प्रोडक्ट तकनीक, स्किल्स या इनसाइट्स को तय नियमों से नहीं मापा जा सकता।
मैं यह क्यों चर्चा करना चाहता हूँ? क्योंकि इसका मतलब है कि हमारा मूल्य इन क्षेत्रों में निहित है। बड़ी कंपनियाँ किन चीजों में अच्छी नहीं हैं? ताकि हम उन्हें वे काम करने में मदद कर सकें।
मैंने बड़ी कंपनियों में इंजीनियरिंग का ज़िक्र क्यों किया, न कि कंपनियों में इंजीनियरिंग का? दरअसल, यह सिर्फ बड़ी कंपनियों या छोटे स्टार्टअप्स के बारे में नहीं है। वे लोगों से बनी होती हैं; सिर्फ कर्मचारियों की संख्या में कुछ अंतर होता है।
बड़ी कंपनियों में इंजीनियरिंग, स्टार्टअप्स की तुलना में कम विविध होती है।
सहयोग के बारे में
सहयोग करना चुनौतीपूर्ण है। इसमें सामान्य लक्ष्यों को प्राप्त करने के लिए एक साथ काम करना शामिल है। आइए इसे कोडिंग के नज़रिए से देखते हैं।
मूल रूप से, हर व्यक्ति एक जटिल प्रोग्राम की तरह होता है, जो जीवन के अनुभवों, काम के इतिहास, विश्वदृष्टि, करीबी रिश्तों, पालन-पोषण और डिजिटल इंटरैक्शन से बना होता है।
चुनौती यह है कि एक टीम के रूप में एक लक्ष्य कैसे हासिल किया जाए। एक समूह को कैसे प्रभावी ढंग से सहयोग करना चाहिए? माइक्रोसर्विसेज़ कैसे सामंजस्यपूर्ण तरीके से एक साथ चल सकती हैं?
पर्सनल प्रोजेक्ट्स के लिए, एक व्यक्ति सब कुछ खुद ही संभालता है, सहयोग की जरूरत नहीं होती। आजकल, व्यक्ति अक्सर कई AI टूल्स का उपयोग करके अपने लक्ष्यों को पूरा करते हैं।
कुछ लोगों की छोटी टीम में, जिम्मेदारियाँ बाँट दी जाती हैं। उदाहरण के लिए, एक व्यक्ति डिज़ाइन संभाल सकता है जबकि दूसरा डेवलपमेंट पर ध्यान दे सकता है। वैकल्पिक रूप से, एक बैकएंड के लिए जिम्मेदार हो सकता है, और दूसरा फ्रंटएंड के लिए।
बड़ी कंपनियों में, अक्सर यह चिंता रहती है कि कर्मचारी कंपनी छोड़ देंगे, जिससे प्रोजेक्ट्स में नॉलेज गैप्स हो जाएँगे। जिम्मेदारियाँ संभालने वाले नए व्यक्ति को प्रोजेक्ट में पकड़ने में महीने या साल भी लग सकते हैं, जिससे प्रोजेक्ट धीमा हो जाता है या रुक जाता है।
हालाँकि, AI युग में, मेरा मानना है कि हमें अपने तरीके को ढालना चाहिए। “मैन-मंथ मिथ” की अवधारणा सही है।
मैं प्राकृतिक सहयोग का पुरजोर समर्थन करता हूँ। टीम के लाभ के लिए, जैसे-जैसे कोई प्रोजेक्ट आगे बढ़ता है, टीम के भीतर कुछ सहयोग आदतें प्राकृतिक रूप से विकसित हो जाती हैं।
यह कोड के प्राकृतिक मॉड्यूलराइज़ेशन जैसा है। कुछ विकास के बाद, हमारे पास 50 Java क्लास हो सकते हैं, जिन्हें हम फिर पैकेज में व्यवस्थित करते हैं। इसी तरह, 100 Python फाइल्स के साथ, हम उन्हें मॉड्यूल्स में व्यवस्थित करते हैं।
टास्क विभाजन हर व्यक्ति की ताकतों को ध्यान में रखना चाहिए। AI युग में, व्यक्ति कई क्षेत्रों में उत्कृष्टता प्राप्त कर सकते हैं। इसलिए, हमें बड़े टास्क को टीम मेंबर्स के बीच कैसे विभाजित किया जाए, इस पर पुनर्विचार करना चाहिए।
मेरा मानना है कि हर टीम मेंबर को एक समय में एक अपेक्षाकृत बड़े टास्क की जिम्मेदारी दी जानी चाहिए। इस तरह दूसरों के साथ बार-बार संचार या अलाइनमेंट की जरूरत कम होती है। बड़ा टास्क अपेक्षाकृत स्वतंत्र होना चाहिए, जिससे व्यक्ति जरूरत पड़ने पर सीनियर टीम मेंबर्स से मदद ले सकें जिनके पास अधिक विशेषज्ञता हो। इस तरह, अधिक लोग शामिल हो सकते हैं, लेकिन टास्क मूल रूप से निर्धारित व्यक्ति के स्वामित्व में रहता है।
अगर दो लोग हर लाइन कोड को संपादित करने या हर डिटेल पर साथ काम करने के लिए सहयोग करें, तो यह कष्टप्रद हो सकता है। उन्हें हर चरण पर अपने कार्यों को अलाइन करना होगा, जो चुनौतीपूर्ण है। कंप्यूटिंग में, किसी लक्ष्य को प्राप्त करने के कई तरीके हैं। जब तक परिणाम अच्छी गुणवत्ता का है और उद्देश्य को पूरा करता है, हमें अलग-अलग तरीकों या टूल्स को स्वीकार करना चाहिए, चाहे वह कोई विशिष्ट IDE हो, SQL क्लाइंट हो, Python स्क्रिप्ट्स हों या मैन्युअल प्रोसेसेज़।
सहयोग में एक और सुधार यह है कि काम के रिकॉर्ड्स को जितना संभव हो पारदर्शी बनाया जाए। मेरे हाल के काम में, मैंने अपने स्क्रिप्ट्स, लॉग्स और नोट्स को टीम मेंबर्स के साथ साझा किया। मैं वे क्वेरीज़ शेयर कर सकता हूँ जो मैंने Copilot से पूछी हैं, रास्ते में आई समस्याएँ और संबंधित लॉग। यह पारदर्शिता टीम मेंबर्स के साथ संवाद करना आसान बनाती है।
ऐसा करके, यह मेरे कंप्यूटर स्क्रीन को रिकॉर्ड करने जैसा है जब मैं कार्य कर रहा होता हूँ। हालाँकि हम यहाँ सूचना साझा करने के लिए टेक्स्ट का उपयोग कर रहे हैं, लेकिन बेहतर संचार का लक्ष्य पूरा होता है।
सहयोग क्यों विफल होता है? किस तरह के परिदृश्य सहयोग को काम नहीं करने देते? एक कारण टीम मेंबर्स के बीच मिसमैच्ड अपेक्षाएँ हो सकती हैं। संभावित परिणाम यह है कि प्रोजेक्ट डिले हो जाता है या काम क्वालिटी आवश्यकताओं को पूरा नहीं कर पाता।