जब एक प्रबंधन उपकरण वास्तव में मायने रखना शुरू करता है
एक प्रबंधन एप्लिकेशन का मूल्यांकन पहले दिन आसानी से किया जा सकता है: स्क्रीन्स मौजूद हैं, प्रदर्शन डेटा टेबल्स को भर देता है, सब कुछ सही लगता है। लेकिन वास्तविक मूल्यांकन बाद में आता है, उस दिन, जब आपका व्यवसाय आगे बढ़ चुका होता है। एक नई सेवा का बिल बनाना, एक ऐसी स्थिति को अलग से पहचानना जिसकी पहले आवश्यकता नहीं थी, या एक ऐसी जानकारी जिसे आप पहले किसी नोटबुक के कोने में हाथ से लिखा करते थे और अब उसे अपना अलग कॉलम मिलना चाहिए।
यही वह समय है जब अधिकांश उपकरण अपनी वास्तविक प्रकृति दिखाते हैं। कुछ विनम्रतापूर्ण ढंग से अस्वीकार कर देते हैं: ‘यह फ़ील्ड मौजूद नहीं है, आपको बिना इसके ही काम चलाना होगा।’ कुछ सब कुछ स्वीकार कर लेते हैं और आपको बाद में पता चलता है कि कोई डेटा चुपचाप ओवरराइट हो गया है। इन दोनों के बीच एक तीसरी स्थिति है: स्पष्ट रूप से बताना कि क्या बिना जोखिम के बदला जा सकता है, और शेष सभी को सीधे अस्वीकार करना।
परिवर्तन के तीन प्रकार, और केवल एक ही बिना किसी परिणाम के है
सभी परिवर्तन समान नहीं होते, और यहाँ अंतर बनाने वाली बात है, पहले से दर्ज किया गया डेटा। Blueprint Maker प्रत्येक अनुरोधित परिवर्तन को कुछ भी निर्णय लेने से पहले तीन श्रेणियों में वर्गीकृत करता है:
- बिना किसी प्रभाव के: डैशबोर्ड पर एक संकेतक जोड़ना, किसी लेबल को बदलना, एक वैकल्पिक फ़ील्ड जोड़ना, किसी प्रतिबंध को ढीला करना। इनमें से कोई भी कार्य पहले से दर्ज किए गए डेटा को प्रभावित नहीं करता।
- माइग्रेशन की आवश्यकता: किसी कॉलम का नाम बदलना, एक अनिवार्य फ़ील्ड जोड़ना, किसी डेटा के प्रकार को बदलना। संरचना में बदलाव होता है, लेकिन मौजूदा जानकारी को सुरक्षित रखा जा सकता है।
- विनाशकारी: किसी फ़ील्ड या एंटिटी को हटाना, अभी भी उपयोग में आ रहे किसी स्थिति के मान को हटाना, या एक अस्पष्ट नामांतरण। यहाँ डेटा गायब हो सकता है।
आज क्या बदला जा सकता है, बिना आपके डेटा को छुए बिना
पहली श्रेणी के परिवर्तन स्वीकार किए जाते हैं। डैशबोर्ड पर एक अतिरिक्त संकेतक, एक अधिक सटीक लेबल, एक पुनर्व्यवस्थित दृश्य, या एक वैकल्पिक फ़ील्ड जोड़ना, इन सभी के लिए एप्लिकेशन को पुनर्उत्पन्न किया जा सकता है, और आपके द्वारा दर्ज किया गया डेटा अपरिवर्तित रहता है। यह पहले कुछ महीनों में छोटे संगठनों द्वारा अनुरोधित अधिकांश समायोजनों को कवर कर लेता है, क्योंकि अधिकांश समायोजन डेटा के रूप (form) के बजाय उसके प्रदर्शन और पठन पर केंद्रित होते हैं।
आप एप्लिकेशन के अस्तित्व से पहले भी काफी काम कर सकते हैं, और यह सबसे कुशल विकल्प है: आपके विवरण से उत्पन्न योजना निर्माण से पहले संशोधित की जा सकती है। उस समय किसी एंटिटी को सुधारना, किसी स्थिति के मान को स्पष्ट करना, या कोई फ़ील्ड जोड़ना कुछ भी नहीं कीमती है, क्योंकि तब तक कोई डेटा सुरक्षित करने की आवश्यकता नहीं होती।
क्या अस्वीकार किया जाता है, और यह अच्छी खबर क्यों है
जैसे ही कोई भी अनुरोधित परिवर्तन माइग्रेशन या विनाशकारी श्रेणी में आता है, पुनर्निर्माण अस्वीकार कर दिया जाता है। यह अस्वीकार आपके द्वारा इसे लागू करने के समय सर्वर-साइड पर दोनों संस्करणों के वास्तविक अंतर के आधार पर गणना के द्वारा किया जाता है, यह कोई इंटरफ़ेस चेतावनी नहीं है जिसे आप अनदेखा कर सकते हैं, बल्कि यह एक वास्तविक अवरोध है।
अस्वीकार का अर्थ यह नहीं है कि आपका डेटा अवश्य ही खो जाएगा। ‘माइग्रेशन की आवश्यकता’ के मामले में तो उसे अक्सर सुरक्षित रखा जा सकता है। इसका अर्थ कुछ अधिक स्पष्ट और ईमानदार है: ऐसा कोई उपकरण अभी तक मौजूद नहीं है जो डेटा को साफ़ तरीके से स्थानांतरित कर सके, जिसमें एक कॉपी पर ड्राई रन करना और बाद में सत्यापन करना शामिल हो। जब तक ऐसा कोई उपकरण मौजूद नहीं है, एकमात्र उचित स्थिति यही है कि झूठ न बोला जाए।
यह सिद्धांत पूरे उत्पाद में अन्य सभी स्थानों पर भी लागू होता है: कोई भी प्रदर्शित मान झूठ नहीं बोल सकता। एक ऐसा उपकरण जो सब कुछ स्वीकार कर लेता है और चुपचाप संभाल लेता है, आपको उस समय समस्या का पता चलने देता है जब आप कोई जानकारी ढूँढ़ते हैं जो अब वहाँ नहीं है। दूसरी ओर, एक स्पष्ट अस्वीकार को तुरंत संबोधित किया जा सकता है।
जब पुनर्निर्माण अवरुद्ध हो जाता है, तो आपके पास क्या विकल्प हैं
पहला, सबसे सरल विकल्प: अपने अद्यतन विवरण से शुरू करके एक नई एप्लिकेशन उत्पन्न करना। आप शून्य से शुरू नहीं कर रहे हैं, बल्कि पहली एप्लिकेशन के उपयोग से प्राप्त अपने अनुभवों से शुरू कर रहे हैं। जब संरचना वास्तव में बदलती है, तो यह अक्सर सही उत्तर होता है, क्योंकि तब जो बदल रहा होता है वह कोई छोटा विवरण नहीं होता, बल्कि यह आपके व्यवसाय को देखने का तरीका होता है।
दूसरा विकल्प, जो अन्य दोनों को संभव बनाता है: कोड आपका है। आर्काइव के रूप में निर्यात करें, अपने रिपॉजिटरी पर भेजें, और जहाँ चाहें होस्ट करें। इसलिए कोई डेवलपर एप्लिकेशन को वैसे ही ले सकता है, एक कॉलम जोड़ सकता है, उचित डेटाबेस माइग्रेशन लिख सकता है, और इसे फिर से ऑनलाइन कर सकता है। आप किसी की अनुमति का इंतज़ार नहीं कर रहे हैं, और अपने स्वयं के उपकरण को संशोधित करने के अधिकार के लिए कोई सेवा शुल्क भी नहीं दे रहे हैं।
तीसरा विकल्प सबसे कम ध्यान आकर्षित करने वाला लेकिन सबसे आम है: इसके साथ रहना। कई आवश्यकताएँ जो पहली नज़र में संरचनात्मक लगती हैं, वास्तव में एक वैकल्पिक फ़ील्ड या एक अतिरिक्त दृश्य से हल की जा सकती हैं, और ये दोनों परिवर्तन बिना किसी कठिनाई के स्वीकार कर लिए जाते हैं।
प्रबंधन उपकरण चुनने से पहले पूछने योग्य प्रश्न
यह प्रश्न यह नहीं है कि ‘क्या मैं इसे अनुकूलित कर सकता हूँ?’ सभी कहते हैं कि हाँ। बल्कि प्रश्न है: ‘जब मैं एक ऐसा परिवर्तन अनुरोध करूँगा जो उपकरण कर नहीं सकता, तो ठीक-ठीक क्या होगा?’
तीन संभावित उत्तर हैं, और वे समान नहीं हैं। आपको ‘नहीं’ कहा जाता है, और विषय समाप्त हो जाता है। यह स्वीकार कर लिया जाता है, और आप बाद में क्षति का पता लगाते हैं। या फिर आपको स्पष्ट रूप से बताया जाता है कि क्या अवरोध है, आपका डेटा अपरिवर्तित रहता है, और यदि आवश्यकता उचित हो तो आप खुद इसे करने के लिए कोड रखते हैं। तीसरा ही एकमात्र विकल्प है जो दो साल बाद भी आपके आपूर्तिकर्ता की अच्छी इच्छा पर निर्भर नहीं करता।