आपको इसकी जरूरत नहीं पड़ेगी

मैं भाग्यशाली हूँ कि मैं IT में काम करता हूँ लेकिन software engineering background से आता हूँ, यह मुझे IT की दुनिया पर थोड़ा अलग दृष्टिकोण देता है, release cycles और features के पीछे क्या हो रहा है इसे समझने में और उस industry से प्राप्त ज्ञान को इस पर लागू करने में।

software engineering समुदाय में हाल के वर्षों में “You Aren’t Gonna Need It” या YAGNI की अवधारणा लोकप्रिय हो गई है। YAGNI Agile developers के Extreme Programming (XP) समूह से उभरा और इस नियम के रूप में कहा गया है: “हमेशा चीजें तब implement करें जब आपको वास्तव में उनकी जरूरत हो, कभी नहीं जब आप केवल अनुमान लगाते हैं कि आपको उनकी जरूरत होगी।”

मुझे YAGNI को development में “किसी चीज में तब तक invest न करें जब तक आप न जानें कि आपको इसकी जरूरत है” के रूप में reframe करना पसंद है। लेकिन अवधारणा वही है - यदि आप उन pieces को बनाने में समय और पैसा खर्च करते हैं जिनकी आपको कभी जरूरत होगी या नहीं यह आप निश्चित नहीं हैं तो आप ऐसे risks लेते हैं जैसे जितनी जल्दी हो सके value न मिलना (उन चीजों पर ध्यान केंद्रित करके जो अभी मायने नहीं रखतीं जबकि उन चीजों की उपेक्षा करना जो मायने रखती हैं) और ऐसी technology में invest करना जो कभी उपयोग नहीं होगी (क्योंकि requirements बदल जाती हैं, project cancel हो जाता है, आदि)।

यह अवधारणा IT पर बहुत अच्छी तरह लागू होती है। Design और purchasing दोनों YAGNI से भारी प्रभावित हैं, या होने चाहिए। Storage एक बेहतरीन उदाहरण है। आज ऐसे storage में invest न करें जो आप सोचते हैं कि आप कल उपयोग करेंगे। हम बहुत सारे कारण सूचीबद्ध कर सकते हैं कि early storage investment क्यों बुरी है: business के पास अपनी स्वयं की वृद्धि का सटीक अनुमान लगाने की बहुत कम या कोई क्षमता नहीं है, IT business growth के आधार पर storage growth का अनुमान लगाने में कमजोर है, पैसे का time-value और आज storage खरीदना कल वही storage खरीदने से अधिक महंगा है। जब भी हम predictions के आधार पर खरीदते हैं तो हम risk लेते हैं। Predictions शायद ही कभी सच होती हैं।

यदि हम आज storage अधिक खरीदते हैं तो हम उस storage के लिए premium चुका रहे हैं क्योंकि storage की लागत समय के साथ नाटकीय रूप से घटती है। यदि हम 100% headroom के साथ खरीदते हैं और उस headroom का उपयोग करने में तीन साल या उससे अधिक समय लगता है तो हम storage के लिए बहुत अधिक भुगतान कर रहे हैं और बाद में खरीदना हमें बेहतर insight देता कि हमें वास्तव में उस समय क्या चाहिए (केवल capacity नहीं बल्कि speed, reliability, features, आदि), कम लागत और अधिक विकल्प।

Overbuying एक risk है, underbuying दूसरा। Underbuying स्पष्ट रूप से कम risk है लेकिन फिर भी एक concern है। यदि आप आज तीन साल की जरूरतों के लिए खरीदते हैं और दो साल में अचानक जरूरत में burst होती है तो आपने ऐसे platform या technology में अधिक invest किया हो सकता है जो आपकी जरूरतों को पूरा नहीं कर सकती।

Storage एक उदाहरण है लेकिन यह software licenses से लेकर CPU capacity, memory, high availability technologies यहाँ तक कि desktops कहीं भी लागू हो सकता है। कुछ shops तीन साल में predicted headcount वृद्धि के लिए तैयार होने के लिए desktops को सौ प्रतिशत अधिक नहीं खरीदेंगे, लेकिन अजीब बात है कि वे इसे अन्यत्र करने में संकोच नहीं करते।

तत्काल जरूरत के लिए जो आवश्यक है उसे खरीदकर और purchasing decisions को बाद तक hold करके लागत बचत और technology improvements के लिए महत्वपूर्ण अवसर है। कुछ मामलों में यह हो सकता है कि भविष्य की जरूरत कभी उत्पन्न न हो चाहे बुरी predictions, बाजार या strategy में बदलाव या internally या externally technology दिशा में बदलाव के कारण।

खरीद के अलावा, YAGNI network design पर लागू हो सकता है। यह असामान्य नहीं है कि बड़े, complex designs प्रस्तावित और कार्यान्वित किए जाएं जो अक्सर वर्षों दूर anticipated growth पर आधारित हों और, ईमानदारी से कहें तो, यथार्थवादी दुनिया में शायद ही कभी बहुत संभावित हों। उदाहरण के लिए, एक complex high availability environment बनाना जिसमें expensive licensing, complex networking, भविष्य में expected company growth के लिए बहुत storage हो जब आज केवल दो servers और एक अच्छा backup plan ही cost justified है, यह खतरनाक है। न केवल IT spend को justify करने के लिए आवश्यक growth होनी चाहिए बल्कि यह इतनी जल्दी होनी चाहिए कि पैसे का time-value justified हो और technology की लागत इतनी न गिरे कि दो systems को implement करना अधिक cost effective हो गया हो। यह आश्चर्यजनक रूप से आसानी से हो सकता है कि एक छोटा, stop-gap system रखना और फिर जरूरत होने पर एक बड़े scale system को implement करना कहीं अधिक सस्ता हो सकता है क्योंकि बड़े, अधिक complex system के निर्माण की लागत पहले system के place होने के बाद से इतनी कम हो गई है और यह बुरी predictions के risk को consider करने से पहले है।

जल्दी खर्च करने का एक अतिरिक्त risk है - यह unused architecture में corporate finances को बांध देता है। उस पैसे को business को grow करने के लिए business के अन्य भागों में invest किया जा सकता था। extreme cases में, infrastructure में overinvestment एक company के पूरी तरह fail होने में योगदानकर्ता हो सकता है - एक self-fulfilling स्थिति जहाँ YAGNI का उपयोग न करने से ही वह स्थिति उत्पन्न हुई जहाँ YAGNI सबसे अधिक लागू होता था। Architected solution की कभी जरूरत नहीं थी क्योंकि company fail हो गई।

YAGNI एक risk mitigation process है। उन जरूरतों के साथ काम करना जो आप जानते हैं बनाम उन जरूरतों के बजाय जिनका आप अनुमान लगाते हैं।

शायद IT shops आज इसलिए अधिक खरीदते हैं क्योंकि उन्हें specific budgets दिए जाते हैं। यह समझ में आता है कि IT एक technology grab में समाप्त होती है जब business की मर्जी उन पर मुस्कुराती है तो जो कुछ भी वे कर सकते हैं implement करने का प्रयास करते हैं। हालाँकि, यह एक अत्यंत खराब business practice है। Businesses को यह महसूस करना होगा कि IT पर बड़ी रकम बर्बाद हो रही है क्योंकि IT को real world में किसी आधार के बिना business से arbitrary budgets के आधार पर clairvoyance की assumption के साथ systems implement करने के लिए मजबूर किया जाता है। IT अक्सर बहुत अस्पष्ट कारकों के आधार पर business को “sell” कर सकने वाली चीजें खरीदने के लिए फंसी है और business अक्सर IT को काफी capriciously fund करती है। यह एक बहुत अस्वस्थ business और IT संबंध बनाता है जहाँ IT पैसा बर्बाद कर रही है क्योंकि उसके पास बहुत कम विकल्प है और business IT को बर्बाद के रूप में देखती है क्योंकि उन्हें efficiently operate करने की अनुमति नहीं है।

इस स्थिति को ठीक करने के लिए business और IT को मिलकर काम करना होगा। IT को business-savvy unit की तरह अधिक act करने की जरूरत है और business को guidance के लिए IT पर निर्भर रहने की जरूरत है और prediction-based budgeting का उपयोग नहीं करना चाहिए या उन choices के technical ramifications की technical understanding के बिना technological approaches चुनने में उलझना नहीं चाहिए। IT को business पर भरोसा करने में सक्षम होना चाहिए कि वह logical business financial decisions लेगी और business को IT पर भरोसा करने में सक्षम होना चाहिए कि वह business के लिए logical technological decisions लेगी। Business IT को drive करती है, IT business को enable करती है। यह एक symbiotic relationship है। यदि business IT को predict करने और fixed budgets पर operate करने पर जोर देती है, तो IT को जब भी संभव हो overspend और overarchitect करने के लिए मजबूर होना जारी रहेगा इस उम्मीद में तैयार रहे कि कल के लिए जब budget approved नहीं हो सकता। यदि IT को जो जरूरत है उसका अनुरोध करने पर भरोसा किया जाए और business को appropriate time पर technology needs को fund करने पर भरोसा किया जाए तो दोनों common good के लिए अधिक प्रभावी ढंग से operate कर सकते हैं।

Takeaway: जल्दी invest न करें, आप नहीं जानते कि technology या business कल क्या करेगी।