जब प्रबंधन ने IT की चेतावनी को नज़रअंदाज़ किया, तो टेक टीम ने कड़ा कदम उठाया

IT टीम की एक सीख देने वाली प्रतिक्रिया

• ऑस्ट्रेलिया के एक बैंक की इंटरनेट इन्फ्रास्ट्रक्चर टीम में काम करने वाले "Bruce" की कहानी.
• इंटरनेट बैंकिंग के शुरुआती दौर में टीम तेज़ी से बढ़ी और काम का बोझ भी बढ़ता गया.
• ISDN link का उपयोग आधा होने से पहले ही टीम ने अतिरिक्त link खरीदने की ज़रूरत पहचानी और CIO को प्रस्ताव भेजा.

प्रबंधन की अस्वीकृति और IT टीम की प्रतिक्रिया

• CIO ने प्रबंधन को अतिरिक्त ISDN link खरीदने का अनुरोध भेजा, लेकिन यह कहकर मना कर दिया गया कि मौजूदा link का उपयोग अभी आधे तक भी नहीं पहुँचा है.
• IT टीम ने link उपयोग 50% से ऊपर जाते ही फिर अनुरोध किया, लेकिन उन्हें 100% के करीब पहुँचने तक इंतज़ार करने को कहा गया.

IT टीम का रणनीतिक कदम

• IT टीम ने तय किया कि प्रबंधन को समस्या का एहसास कराने के लिए उनके network connection को नियंत्रित किया जाए.
• पहले हफ्ते में 10% कम किया गया, और उसके बाद हर हफ्ते 10% और कम किया गया.
• एक महीने बाद अतिरिक्त ISDN link की स्थापना को मंज़ूरी मिल गई, और प्रबंधन ने 'इंटरनेट समस्या' हल होने पर खुद को बधाई दी.

GN⁺ की राय

इस लेख की सबसे महत्वपूर्ण बात यह है कि IT टीम ने प्रबंधन के फैसले को चुनौती दी और वास्तविक user experience के ज़रिये ज़रूरी इन्फ्रास्ट्रक्चर निवेश के लिए मनाने वाली रणनीतिक प्रतिक्रिया दिखाई. यह तकनीकी समस्या और business decision के बीच की दूरी कम करने के लिए एक रचनात्मक और प्रभावी approach को दिखाता है. यह कहानी सिर्फ IT professionals के लिए ही दिलचस्प नहीं है, बल्कि गैर-तकनीकी निर्णय लेने वालों को भी तकनीकी इन्फ्रास्ट्रक्चर की अहमियत समझने में मदद करने वाला सबक देती है.

[GN⁺]

Hacker News राय

• एक सॉफ्टवेयर इंजीनियर ने एक ऐसे third-party software के इस्तेमाल का अनुभव साझा किया जिसने क्लाइंट के लिए समस्याएँ पैदा कीं। यह इंजीनियर एक internal solution विकसित कर रहा था, लेकिन कुछ लोग contract renew करना चाहते थे। इस इंजीनियर ने पूरे दिन समस्याग्रस्त system को ठीक करने में बिताया और क्लाइंट के tickets उन लोगों को भेजने की रणनीति अपनाई जो contract renew करना चाहते थे। अंततः internal system पर migration हुआ, और उसके बाद से लगभग कोई समस्या नहीं हुई।
• IT professionals के लिए तकनीकी समस्याओं के business impact और risk को स्पष्ट रूप से बताने की क्षमता महत्वपूर्ण है। संभव है कि किसी बैंक का management इसे समझ नहीं पाया हो, लेकिन यह भी संभव है कि technical team इसे ठीक से समझा नहीं पाई हो।
• एक IT manager ने CFO से उचित backup system का अनुरोध किया, लेकिन उसे बार-बार मना कर दिया गया। फिर एक बड़ा disk crash हुआ, कंपनी कई हफ्तों तक ठप रही, और उसके बाद ही उचित backup device खरीदा गया।
• यह राय है कि किसी बड़े संगठन में कुछ हासिल करने के लिए management को आपका दर्द महसूस होना चाहिए। दावा किया जाता है कि दुनिया ऐसे ही चलती है।
• एक engineer ने लागत बचाने के लिए Cisco 1604 ISDN router configure किया, लेकिन उसने पाया कि IBM AIX हर घंटे IBM को telemetry data भेज रहा था, और इसे रोकने के लिए firewall rules जोड़ने पड़े।
• यह राय है कि IT department को business unit से स्वतंत्र होकर सही निर्णय लेने की autonomy चाहिए। किसी संगठन में trust यह तय करता है कि कितनी oversight की आवश्यकता होगी। IT team को business के 'customer' के रूप में model करना एक अधिक सरल approach हो सकता है।
• कुछ comments का तर्क है कि hierarchical decisions का सम्मान किया जाना चाहिए, लेकिन यह फिर भी याद दिलाता है कि कंपनियाँ अब भी military mindset रखती हैं।
• leadership से निराश एक व्यक्ति ने कहा कि वह नई नौकरी ढूँढता और जहाज़ डुबोने का विकल्प चुनता।
• "50% utilization" अभिव्यक्ति पर सवाल उठाने वाली राय है। यदि एक single pipe हो और load irregular हो, तो performance degradation बीच-बीच में हो सकता है।
• "Regomise" शब्द को लेकर भ्रम दूर करने के लिए यह स्पष्टीकरण दिया गया कि यह username generator के रूप में इस्तेमाल होता है।