लिखित DevOps प्रशिक्षण
DevOps से परिकल्पनाएँ कैसे सुधारें और प्रयोग व सीख पर चलने वाला संगठन कैसे बनाएँ?
सामान्य IT संगठन अक्सर उत्पादों और फ़ीचर की कई रिलीज़ बनाते हैं, बिना जाँचे कि अपेक्षित व्यावसायिक नतीजे मिले या कोई असल व्यक्ति उन्हें इस्तेमाल भी करता है। बिज़नेस मॉडल या उत्पाद और फ़ीचर का विचार जाँचने का सबसे अकुशल तरीका है पहले पूरा उत्पाद और सेवा बनाना और फिर देखना कि अनुमानित माँग है या नहीं और आपका विचार उसे पूरा कर सकता है या नहीं।
पूरा उत्पाद और सेवा बनाने से पहले पूछें: «मुझे यह क्यों बनाना चाहिए?”, “क्या यह वाकई मेरे समय और संसाधनों के लायक है?» ऐसे प्रयोग बनाएँ और चलाएँ जो जल्द से जल्द और कम खर्च में जाँचें कि आपके विचार, उत्पाद और फ़ीचर अपेक्षित व्यावसायिक नतीजे देते हैं या नहीं।
कई एंटरप्राइज़ उत्पादों पर लंबे समय के सांख्यिकीय प्रयोगों से पता चला कि सिर्फ़ 1/3 बदलाव आय, कन्वर्ज़न, ऑर्डर, सदस्यता या नए ग्राहकों जैसे अहम मेट्रिक्स में बड़ा सुधार करते हैं। बाकी 2/3 से सुधार नहीं होता, बहुत कम होता है या नतीजे बिगड़ते हैं। ऐसे फ़ीचर बनाने से बेहतर पूरे दल को छुट्टी देना होगा।
इस चुनौती का जवाब है A/B टेस्ट से उपयोगकर्ता शोध। फ़ीचर बनाने से पहले उसके परिणाम जाँचें। शोध का फ़ीडबैक सॉफ़्टवेयर इंजीनियरिंग में शामिल करें, ताकि DevOps तरीके से सही ढंग से काम करने के साथ सही चीज़ भी बनाएँ। जितना तेज़ प्रयोग करेंगे, सीखेंगे और ग्राहक फ़ीडबैक जीवनचक्र में जोड़ेंगे, उतनी अच्छी तरह अपने बाज़ार में प्रतिस्पर्धियों से आगे रहेंगे।
A/B टेस्ट पहले डाक से सीधे प्रतिक्रिया माँगने वाले मार्केटिंग अभियानों में लोकप्रिय हुआ। शब्द, रंग, लेआउट, शीर्षक और पाठ बदलकर पर्चों और पोस्टकार्ड के कई रूप जाँचे गए, ताकि सबसे अच्छा प्रदर्शन और बिक्री देने वाला रूप पता चले। ब्रिटिश सरकार ने बकाया कर वसूलने के सबसे असरदार पत्र के लिए A/B टेस्ट किए। आज यह मार्केटिंग और संवाद के साथ विचार, उत्पाद और फ़ीचर जाँचने का आम तरीका है।
टीम को A/B टेस्ट अपनाने के लिए फ़ीचर के कई वर्शन जल्दी और आसानी से डिप्लॉय करके अलग उपयोगकर्ता समूहों को दिखाने चाहिए। टेलीमेट्री और बिज़नेस मेट्रिक्स से जानें कि फ़ीचर बेहतर परिणाम देता है या नहीं और कौन-सा वर्शन सबसे अच्छा है।
उदाहरण: संगठन ई-कॉमर्स पोर्टल का नया चेकआउट रिलीज़ करना चाहता है। इसे टीम का बड़ा काम बनाने से पहले यह बेहतर परिणामों की एक परिकल्पना है। इसकी जाँच और पुष्टि के बाद ही इसे ऐसी परियोजना बनाएँ जिसमें टीम का काफ़ी समय, संसाधन और मेहनत लगे। पहला काम है:
परिकल्पना की पुष्टि करें: हमारा मानना है कि चेकआउट का नया वर्शन दे सकता है बेहतर कन्वर्ज़न दर। हमें पूरा भरोसा होगा कि इसे पूरी तरह बनाना और डिलीवर करना सही है, जब 1% आगंतुकों को दिखाए गए किसी प्रायोगिक चेकआउट वर्शन से अगले 7 दिनों में बिक्री कम से कम 5% बढ़े।
निष्कर्ष
सिर्फ़ अपनी सहज समझ और सीखी हुई सर्वोत्तम प्रथाओं पर निर्भर न रहें। असल दुनिया के लोगों को असल परिस्थितियों में अपने प्रयोगों में भाग लेने दें।
DevOps प्रोडक्ट ओनर अपने उत्पाद और फ़ीचर के विचारों को सत्यापित की जाने वाली परिकल्पना मानें। तर्क और सबूत से अच्छे साबित होने के बाद ही उनका पूरा डिज़ाइन, निर्माण और टेस्ट करें।
