अब मैं क्या करूँ? डिज़ाइन परिवर्तनों की योजना बनाना

अक्सर मुझे लोगों से उनके system design, योजनाओं और architecture के बारे में बात करनी पड़ती है। और कई बार यह चर्चा बहुत देर से होती है जब design या तो पूरी तरह लागू हो चुकी होती है या आंशिक रूप से। यह बहुत निराशाजनक हो सकता है यदि कार्यान्वित हो रही design को उस स्थिति के लिए आदर्श नहीं माना गया हो।

मैं इस तरह की स्थिति से आने वाली निराशा की भावना को समझता हूँ, लेकिन यह कुछ ऐसा है जिसका IT में हमें नियमित रूप से सामना करना पड़ता है और इस प्रतिक्रिया को रचनात्मक रूप से प्रबंधित करना एक महत्वपूर्ण IT कौशल है। हमें इस स्थिति के तकनीकी और भावनात्मक दोनों पहलुओं के विशेषज्ञ बनना होगा। हमें इससे पंगु नहीं होना चाहिए; यह एक स्वाभाविक स्थिति है जिसे हर IT professional नियमित रूप से अनुभव करता है। यह निरुत्साहजनक या पंगु बनाने वाला नहीं होना चाहिए, लेकिन यह बिल्कुल समझ में आता है कि ऐसा महसूस हो सकता है।

हम इसे इतनी बार इसलिए अनुभव करते हैं क्योंकि IT एक विशाल क्षेत्र है जिसमें हर स्थिति में बड़ी संख्या में चर होते हैं। यह एक अत्यधिक रचनात्मक क्षेत्र भी है जहाँ किसी भी समस्या के कई व्यावहारिक दृष्टिकोण हो सकते हैं। शायद ही कभी एक एकल “सर्वोत्तम” विकल्प होता है। आमतौर पर कई प्रतिस्पर्धी विकल्प होते हैं। कभी-कभी ये बहुत निकट से संबंधित होते हैं, कभी-कभी ये विकल्प नाटकीय रूप से भिन्न होते हैं जिससे उनकी सार्थक तुलना करना बहुत मुश्किल हो जाता है।

एक और प्रमुख कारण यह है कि कारक बदलते हैं। यह हो सकता है कि नई तकनीकें या जानकारी सामने आती हैं, नए उत्पाद जारी होते हैं, उत्पादों को अपडेट किया जाता है, कीमतें बदलती हैं या निर्णय लेने और design प्रक्रियाओं के दौरान या उनके करीब व्यावसायिक जरूरतें बदल जाती हैं। परिवर्तन की यह दर कुछ ऐसी नहीं है जिसे हम, IT professionals के रूप में, नियंत्रित करने की उम्मीद कर सकते हैं। यह कुछ ऐसा है जिसे हमें जितना हो सके स्वीकार करना और उससे निपटना होगा।

एक और चीज़ जो मैं अक्सर चूकी हुई देखता हूँ वह यह है कि जो समाधान बनाते समय आदर्श था, वह आज उसी निर्णय पर किया जाता तो आदर्श नहीं होता। यह किसी भी तरह से मूल design में कमी नहीं है, फिर भी मैंने बहुत से लोगों को इस पर ऐसे प्रतिक्रिया देते देखा है जैसे यह हो। सबसे सामान्य परिदृश्य जिसमें मैं लोगों को यह व्यवहार करते देखता हूँ वह आधुनिक storage design में RAID 5 के उपयोग से बचने में है, RAID 6 और RAID 10 अच्छे कारणों से लोकप्रिय विकल्प हैं। लेकिन यह RAID 5 से बचाव, जो लगभग 2009 से सामान्य है, हमेशा से नहीं था और 1990 के दशक के मध्य से लगभग 2000 के दशक के अंत तक RAID 5 न केवल व्यावहारिक था, बल्कि यह अक्सर दी गई व्यावसायिक और तकनीकी आवश्यकताओं के लिए सबसे अच्छा समाधान था। हालांकि कई लोग आज RAID 5 को एक गरीब विकल्प के रूप में देखते हैं, लेकिन वे इस नई अरुचि को बहुत पहले design और कार्यान्वित प्रणालियों पर लागू करते हैं। 2002 में एक परिदृश्य के लिए RAID 5 का सबसे अच्छा विकल्प होना किसी भी तरह से यह नहीं दर्शाता कि यह 2015 में भी सबसे अच्छा विकल्प होगा।

मुझसे कई बार पूछा गया है कि जब कम-से-आदर्श design निर्णय ले लिए जाएं तो क्या करें। “अब मैं क्या करूँ?”

यह सीखना कि जब पूर्णता अब एक विकल्प नहीं है तो क्या करें (जैसे कि यह कभी वास्तव में था, सभी IT समझौतों के बारे में है) एक बहुत महत्वपूर्ण कौशल है। सबसे पहले हमें भावनात्मक समस्याओं से निपटना होगा क्योंकि ये बाकी सब कुछ कमजोर कर देंगी। हमें पीछे हटने, स्थिति को स्वीकार करने और तर्कसंगत रूप से कार्य करने की पूरी कोशिश करनी चाहिए। आखिरी चीज़ जो हम करना चाहते हैं वह है एक गैर-आदर्श स्थिति लेना और बुरे निर्णयों को उलटे तरीके से उचित ठहराने या घबराने से चीजों को बदतर बनाना।

यह स्वीकार करना कि कोई design परिपूर्ण नहीं है, कि हमेशा चीजों को पूरी तरह से सही करने का कोई तरीका नहीं है और इससे निपटना IT में काम करने का हिस्सा है, पहला कदम है। पीछे हटें, गहरी सांस लें। यह उतना बुरा नहीं है। यह एक अनूठी स्थिति नहीं है। हर IT pro जो design करता है वह इससे हर समय गुजरता है। आपको सबसे अच्छे निर्णय लेने की पूरी कोशिश करनी चाहिए, लेकिन आपको यह भी स्वीकार करना होगा कि यह शायद ही कभी किया जा सकता है — किसी के पास वास्तव में ऐसा करने के लिए पर्याप्त संसाधनों तक पहुंच नहीं है। हम जो है उसके साथ काम करते हैं। तो हम यहाँ हैं। आगे क्या?

अगला कदम स्थिति का आकलन करना है। हम अभी कहाँ हैं? कई मामलों में कार्यान्वयन हो चुका है और कुछ और करने की आवश्यकता नहीं है। स्थिति आदर्श नहीं है, लेकिन क्या यह बुरी है? बहुत अक्सर सबसे बड़ी गलती जो मैं पहले से लागू design का सामना करने वाले लोगों में देखता हूँ वह यह है कि यह बहुत महंगी है — आमतौर पर “बेहतर” समाधान इसलिए बेहतर नहीं होते क्योंकि वे तेज़ या अधिक विश्वसनीय हैं, बल्कि इसलिए बेहतर हैं क्योंकि वे सस्ते, आसान या लागू करने में तेज़ हैं। यह एक दुर्भाग्यपूर्ण स्थिति है लेकिन मुश्किल से पंगु बनाने वाली। जो भी समय या पैसा खर्च किया गया वह उस समय स्वीकार्य रही होगी और अनुमोदित की गई होगी। सबसे अच्छी बात जो हम अभी कर सकते हैं वह यह है कि निर्णय प्रक्रिया से सीखें और भविष्य में अत्यधिक खर्च से बचने की कोशिश करें।

ऐसी स्थितियाँ हैं जहाँ लागू की गई design पर्याप्त रूप से व्यावसायिक आवश्यकताओं को पूरा नहीं करती। यह सौभाग्य से कम आम है, मेरे अनुभव में, क्योंकि यह एक बहुत कठिन स्थिति है। इस मामले में हमें अपनी व्यावसायिक जरूरतों को पूरा करने के लिए कुछ संशोधन करने होंगे। यह महंगा या जटिल हो सकता है। लेकिन चीजें उतनी बुरी नहीं हो सकतीं जितनी लगती हैं। इस पर प्रतिक्रियाएं अक्सर भ्रामक होती हैं और स्थिति को अक्सर बचाया जा सकता है।

पहला कदम एक बार जब हम ऐसी स्थिति में हों जहाँ हमने एक ऐसा समाधान लागू किया है जो व्यावसायिक जरूरतों को पूरा करने में विफल रहता है, तो व्यावसायिक जरूरतों का पुनर्मूल्यांकन करना है। इसका यह मतलब नहीं है कि हमें जरूरतों को इस तरह से बदलना चाहिए कि वे जो कुछ भी हमारा system पूरा कर सकता है उसमें फिट हो जाएं। लेकिन यह देखने के लिए वापस जाने का एक अच्छा समय है कि क्या मूल रूप से बताई गई जरूरतें वास्तव में वैध हैं या वे पर्याप्त रूप से सत्यापित नहीं की गई थीं, या और भी अधिक संभावना है, यह देखने के लिए जाएं कि क्या कार्यान्वयन के दौरान व्यावसायिक जरूरतें बदल गई हैं।

दूसरा कदम एक नई technology baseline बनाना है। यह IT को sunk cost fallacy के जाल में गिरने से रोकने में मदद करने के लिए एक बहुत महत्वपूर्ण कदम है। यह किसी के लिए भी बेहद सामान्य है — यह किसी भी तरह से IT के लिए अद्वितीय नहीं है — कि किसी परियोजना पर खर्च किए गए समय और पैसे को देखें और यह मान लें कि मूल रास्ते पर चलते रहना, चाहे वह कितना भी मूर्खतापूर्ण हो, सही तरीका है क्योंकि उस रास्ते पर पहले से ही इतने संसाधन खर्च किए जा चुके हैं। लेकिन यह बेशक कोई मायने नहीं रखता कि आप अपनी वर्तमान स्थिति तक कैसे पहुंचे। जो प्रासंगिक है वह है विभाग और कंपनी की वर्तमान जरूरतों का आकलन करना और वर्तमान में उपलब्ध समाधानों, technologies और संसाधनों का लेखा-जोखा करना।

sunk cost fallacy का एक अच्छा उदाहरण शतरंज के खेल में है। प्रत्येक चाल के साथ सभी उपलब्ध चालों, जोखिमों और रणनीतियों का फिर से आकलन करना महत्वपूर्ण है क्योंकि वर्तमान स्थिति तक पहुंचने के लिए कौन सी चालें उपयोग की गई थीं, इसका आगे की चालों पर कोई असर नहीं होता। यदि दुनिया का सबसे महान शतरंज खिलाड़ी या एक놀라uni computer शतरंज algorithm खेल के बीच में लाया जाए, तो उन्हें यह जानने की आवश्यकता नहीं होगी कि वर्तमान स्थिति कैसे आई — वे बस वर्तमान स्थिति का आकलन करेंगे और उसके आधार पर एक रणनीति बनाएंगे।

IT में हमें भी इसी तरह व्यवहार करना चाहिए। हमारी वर्तमान स्थिति हमारी वर्तमान स्थिति है। रणनीतिक योजना के लिए यह मायने नहीं रखता कि हम उस स्थिति में कैसे पहुंचे। हम केवल उन निर्णयों और लागतों की परवाह तब करते हैं जब हम एक post mortem प्रक्रिया कर रहे होते हैं ताकि यह निर्धारित किया जा सके कि निर्णय लेने में कहाँ विफलता हुई होगी ताकि उससे सीखा जा सके।

दुर्भाग्यपूर्ण बात यह है कि हमें अपनी योजना प्रक्रियाओं को फिर से शुरू करना होगा लेकिन इस बार, हम मानते हैं, काम करने के लिए अधिक। लेकिन इसे टाला नहीं जा सकता। सबसे बुरे मामलों में, बजट अब उपलब्ध नहीं होता और flawed design को ठीक करने और आवश्यक व्यावसायिक लक्ष्यों को प्राप्त करने के लिए कोई संसाधन नहीं होते। समझौते कभी-कभी आवश्यक होते हैं। जो हमारे पास है उससे काम चलाना कभी-कभी सबसे अच्छा होता है। लेकिन, अधिकांश मामलों में, अतिरिक्त बजट या मौजूदा उत्पादों के रचनात्मक पुनर्उपयोग का कुछ संयोजन स्थिति को सुधारने के लिए पर्याप्त हो सकता है।

एक बार जब हम ऐसी स्थिति में पहुंच जाते हैं जिसमें हमने अपनी कमियों को दूर कर लिया है, चाहे केवल यह स्वीकार करके कि हमने अधिक खर्च किया है, कम दिया है, या जरूरतों को पूरा करने के लिए समायोजित किया है, तो हमारे पास वापस जाने और अपनी निर्णय लेने की प्रक्रियाओं की जांच करने का अवसर है। यह इसी से है कि हम व्यक्तियों के रूप में बढ़ने और, यदि संभव हो, संगठनात्मक स्तर पर अपनी गलतियों से सीखने की उम्मीद करते हैं। हर कंपनी और हर व्यक्ति गलतियां करता है। जो हमें अलग करता है वह है उनसे सीखने और भविष्य में उन्हीं गलतियों से बचने की क्षमता।

अंतिम कदम जो हम कर सकते हैं वह है मौजूदा कार्यान्वयन के प्रतिस्थापन को design करने के लिए निर्णय प्रक्रिया जल्द से जल्द शुरू करना, एक बार निर्णय प्रक्रिया की समीक्षा पूरी होने के बाद। इसका अनिवार्य रूप से यह मतलब नहीं है कि हमें निकट भविष्य में पैसा खर्च करने या अपने designs को बदलने का इरादा रखना चाहिए। बिल्कुल नहीं। लेकिन design लेने में अत्यंत सक्रिय होकर हम योजना के लिए अतिरिक्त समय, आवश्यकताओं को एकत्र करने और प्रलेखित करने के लिए अधिक समय, समय के साथ आवश्यकताओं में परिवर्तन की बेहतर अंतर्दृष्टि और निर्णय में management और peer की बेहतर भागीदारी पाने की कोशिश कर सकते हैं।

अच्छी, तर्कसंगत प्रक्रियाओं और कम-से-आदर्श systems design या कार्यान्वयन के मामले में उठाए जाने वाले कदमों की अच्छी समझ के साथ हम गलतियों से उबर सकते हैं और न केवल, अधिकांश मामलों में, अल्पकालिक रूप से उनसे उबर सकते हैं, बल्कि भविष्य में उसी गलतियों से संगठन को बचा सकते हैं।