CTO से झूठ बोलकर संकट टालने की घटना

 (GrumpyOldDev.com)
2 पॉइंट द्वारा GN⁺ 2024-05-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें

एक डेवलपर ने CTO से झूठ क्यों बोला

  • यह कुछ साल पहले की बात है, जब लेखक एक Fortune 500 कंपनी में काम करता था
  • उस समय CTO ने अपने निजी नेटवर्क वाले एक महत्वपूर्ण ग्राहक के लिए एक बड़ा प्रोजेक्ट लिया और उसके मुख्य हिस्से को एक बड़ी तकनीकी सेवा कंपनी को आउटसोर्स करने का फैसला किया
  • लेकिन vendor का "product" वास्तव में ऐसा था कि requirements के मुताबिक बनाने के लिए उसमें बड़े पैमाने पर customization की ज़रूरत थी, और यह सबसे खराब विकल्प साबित हुआ
  • CTO के साथ status check मीटिंगों में किसी को भी यह idea अच्छा नहीं लग रहा था, लेकिन सब सिर्फ इतना ही कहते थे, "अच्छा आइडिया है, बॉस"
  • आखिरकार जब vendor ने "product" डिलीवर किया, तब तक सितंबर आ चुका था, और अक्टूबर रिलीज़ के लिए dead march शुरू हो गया
  • testing के दौरान performance issues और MongoDB की 16MB document limit से टकराने जैसी गंभीर bugs सामने आए
  • ग्राहक से कहा गया कि रिलीज़ एक महीने की देरी से होगी, और उसी समय vendor integration को बदलने के लिए एक गुप्त प्रोजेक्ट शुरू करने का फैसला किया गया
  • मैं तब एक युवा और उत्साही डेवलपर था, और मुझे 3 टीम सदस्यों के साथ replacement system बनाने की ज़िम्मेदारी दी गई
  • दिसंबर के मध्य तक, पिछले एक महीने में replacement software लगभग पूरा हो चुका था, लेकिन सब लोग burnout की हालत में थे
  • तभी CTO आया और उसने कहा कि छुट्टियाँ रद्द की जा रही हैं, और मैंने जवाब दिया, "ठीक है"
  • लेकिन पिता की सलाह याद करते हुए मैंने टीम को छुट्टी पर जाने को कहा, फिर अकेले CTO के साथ dead march status check मीटिंग में शामिल होकर झूठ बोला
    • "टीम बहुत मेहनत कर रही है। आज हम 73वें milestone integration point तक पहुँच गए हैं"
    • "टीम ने कल अच्छा progress किया। हमने एक और web service पूरा कर लिया"
  • एक हफ्ते बाद आराम कर चुके टीम सदस्य लौटे, और जनवरी में deadline पर सफलतापूर्वक लॉन्च किया जा सका

GN⁺ की राय

  • यह खराब माहौल और अव्यावहारिक मांगों के बीच भी प्रोजेक्ट को सफलतापूर्वक आगे बढ़ाने वाली leadership का उल्लेखनीय उदाहरण है। खासकर टीम सदस्यों की स्थिति और थकान का ध्यान रखना प्रभावशाली है
  • हालांकि, CTO से झूठ बोलना उचित नहीं था। लंबे समय में इससे संगठन के भीतर भरोसा टूट सकता है और बड़े मुद्दे पैदा हो सकते हैं
  • vendor selection और outsourcing management में विफलता के लिए CTO की ज़िम्मेदारी बड़ी थी, लेकिन इसे सुधारने की प्रक्रिया में अधिक पारदर्शी और सक्रिय communication की ज़रूरत थी
  • डेवलपर्स के burnout को रोकने के लिए शुरू से ही अधिक यथार्थवादी schedule बनाना और पर्याप्त staffing देनी चाहिए थी। crunch mode ऐसी प्रथा है जिससे बचना चाहिए
  • ऐसी मिलती-जुलती समस्या स्थितियों में एक उपयोगी विकल्प agile methodology हो सकती है। छोटे cycles में development और feedback को दोहराकर risk को कम किया जा सकता है और टीम की workload intensity को संतुलित रखा जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-10
Hacker News राय
  • अत्यधिक काम और छुट्टी रद्द करना:
    • अवास्तविक समय-सीमा पूरी करने के लिए हद से ज़्यादा काम करना और छुट्टियाँ रद्द करना समझदारी नहीं है, और बाद में इसका पछतावा होता है
    • जो कंपनियाँ प्रोडक्ट डिलीवर करने के लिए कर्मचारियों की छुट्टियों के बलिदान पर निर्भर करती हैं, वे समस्याग्रस्त कार्यस्थल संस्कृति को बढ़ावा देती हैं
  • स्वस्थ कंपनी बनाम अस्वस्थ कंपनी:
    • एक स्वस्थ कंपनी में अनुभवी लोग outsourcing approach की समस्याओं का पहले से अंदाज़ा लगा लेते और शुरू में ही चिंता जताते
    • खुला संचार, समाधान खोजने के लिए साथ काम करना, और टीम की भलाई के लिए मैनेजर का पक्ष लेना एक स्वस्थ माहौल के संकेत हैं
    • यह कहानी एक ऐसी अस्वस्थ स्थिति दिखाती है जहाँ मैनेजर बार-बार अपने वरिष्ठों से झूठ बोलता है
  • बेतुकी vendor practices:
    • हर transaction को एक विशाल JSON document में स्टोर करना और हर update पर पूरा document पढ़ना vendor का बेहद बेतुका approach है
    • एक और उदाहरण वह startup है जो user ticket data को user table में अतिरिक्त columns के रूप में स्टोर करता है, जिससे सैकड़ों columns बन जाते हैं
  • दुष्क्रियाशील स्थिति और leadership:
    • टीम लीडर का छुट्टी के बारे में झूठ बोलना स्वीकार्य नहीं है और यह ऐसी उल्लंघनकारी हरकत है जिस पर नौकरी जा सकती है
    • बेहतर तरीका यह है कि अव्यावहारिक overtime की मांगों का विरोध किया जाए और project scope तथा vendor की ज़िम्मेदारी पर ठोस रुख रखा जाए
    • टीम लीडर की ज़िम्मेदारी है कि वह अपनी नौकरी जोखिम में पड़ने पर भी टीम को पागलपन भरी मांगों से बचाए
  • किसी को भी लाभ नहीं मिला:
    • vendor ने खराब गुणवत्ता दी, CTO अनजान रहा, developers ने हद से ज़्यादा काम किया, और कहानी का मुख्य व्यक्ति झूठ पर निर्भर रहा
    • यह ऐसी पागल स्थिति है जिसे किसी को भी स्वीकार नहीं करना चाहिए। बेहतर कार्यस्थल के लिए निकल जाना ही उचित है
  • ईमानदारी और पारदर्शिता:
    • तकनीकी समस्याओं, performance issues, scope changes आदि के बारे में management से ईमानदारी से बात करना कुछ लोगों के लिए अच्छा काम करता है
    • disconnected leadership द्वारा तय की गई मनमानी deadlines पूरी करने के लिए झूठ बोलना अच्छा तरीका नहीं है
  • developer-management के बीच भरोसे की खाई:
    • developers और गैर-तकनीकी management के बीच अक्सर information asymmetry और trust की कमी होती है
    • managers के लिए प्रगति का आसानी से आकलन करना मुश्किल होता है और वे project success को लेकर अनिश्चित महसूस करते हैं
    • क्योंकि जोखिम business side पर होता है, developers पर यह दबाव आता है कि वे इस trust gap को पाटें और deliver करें
  • कम वादा करो, ज़्यादा पूरा करो:
    • कहानी के मुख्य व्यक्ति का पहले से पूरा हो चुका काम पूरा हुआ बताना कुछ हद तक "underpromise and overdeliver" के रूप में देखा जा सकता है
    • अधूरे काम के बारे में झूठ बोलना अधिक जोखिम भरा है और टीम के लोगों का वापस आकर काम करने का मनोबल गिरा सकता है
  • असहाय संगठन और low-code tools:
    • vendor की खराब practices और मामूली project scope यह दिखाते हैं कि कुछ बड़ी कंपनियाँ software projects को लेकर खुद को कितना असहाय महसूस करती हैं
    • इससे यह समझ आ सकता है कि भले इंजीनियरों में नहीं, लेकिन तकनीकी leadership के बीच Retool जैसे low-code tools इतने लोकप्रिय क्यों हैं
  • ईमानदारी और मना करने का साहस:
    • असली "rockstar" वही है जिसमें ईमानदारी हो और बेवकूफी तथा अव्यावहारिक मांगों को ठुकराने का साहस हो
    • असाधारण अक्षमता की भरपाई करना या पूरी टीम का बोझ अपने ऊपर लेना किसी एक व्यक्ति की ज़िम्मेदारी नहीं है