आप एक प्रोजेक्ट पर काम कर रहे हैं और कस्टमर का लीड कहता है, “हमें यह वर्कफ़्लो अपने तीन अलग-अलग क्षेत्रों (regions) के लिए चाहिए, जिनमें हर एक के लिए अलग-अलग अप्रूवल नियम हैं, और इसे प्लेटफ़ॉर्म के ज़रिए लागू किया जाना चाहिए।” हो सकता है कि आप डिप्लॉयमेंट के दौरान कोई जुगाड़ करके इसे बना लें, लेकिन आप यह भी जानते हैं कि अगला कस्टमर भी ऐसी ही चीज़ की मांग करेगा।
यह लेसन उस पल को पहचानने के बारे में है जब कस्टमर की कोई रिक्वेस्ट सिर्फ़ एक बार की डिलीवरी का काम न रहकर मुख्य प्रोडक्ट का काम बन जाती है, और फिर यह साफ़ करना कि एक Forward Deployed Engineer (FDE) के तौर पर आपकी क्या ज़िम्मेदारी बनी रहती है। FDE वह इंजीनियर होता है जो कस्टमर के एनवायरनमेंट में काम करता है और साथ ही कस्टमर की ज़रूरतों को प्रोडक्ट और इंजीनियरिंग के काम में बदलता है।
क्या बनाना है, यह तय करने से पहले आप यह तय करें कि असल में रिक्वेस्ट क्या है। क्या यह “इस अकाउंट के लिए शुक्रवार तक इसे चालू करना” है, या यह “हमारे पास दोबारा इस्तेमाल होने वाली क्षमता (reusable capability) की कमी है और यह कस्टमर उसका पहला मज़बूत संकेत है” वाला मामला है?
एक बार किए जाने वाले क्लाइंट बदलाव और दोबारा इस्तेमाल होने वाली क्षमता के बीच के अंतर को समझें।
कोई रिक्वेस्ट तब प्रोडक्ट स्ट्रेटेजी बन जाती है जब वह सिर्फ़ उस कस्टमर के कॉन्फ़िगरेशन के बारे में नहीं रह जाती, बल्कि प्रोडक्ट की किसी कमी या ज़रूरी फ़ीचर की ओर इशारा करने लगती है। आपको यह तब महसूस होता है जब कस्टमर कोई आउटपुट नहीं, बल्कि एक ऐसा नियम मांग रहा होता है जिसे प्लेटफ़ॉर्म को ही अपनाना चाहिए।
इस स्थिति पर विचार करें। कस्टमर चाहता है कि क्षेत्र-विशिष्ट (region-specific) मंज़ूरी की प्रक्रिया प्लेटफ़ॉर्म के अंदर ही लागू हो - न कि स्प्रेडशीट में, न ही मैन्युअल स्टेप के तौर पर, और न ही किसी ऐसे कस्टम स्क्रिप्ट के तौर पर जिसे सिर्फ़ आपकी टीम समझती हो। यह इस बात का संकेत है कि वे कुछ ऐसा मांग रहे हैं जिसके लिए प्रोडक्ट डिज़ाइन, लंबे समय तक सपोर्ट और उसके काम करने के तरीके के बारे में स्पष्ट नियम की ज़रूरत है।
इन दोनों के बीच फ़र्क करने का एक आसान तरीका यह पूछना है कि आपके जाने के बाद क्या होगा। अगर समाधान के लिए आपको कस्टम ब्रांच, प्राइवेट पैच या किसी ऐसे खास व्यवहार (special-case behavior) को बनाए रखना पड़ता है जिसे आपके नोट्स के बिना कोई समझा नहीं सकता, तो यह प्रोडक्ट के दायरे में आ रहा है क्योंकि इसके लिए एक आधिकारिक इंटरफ़ेस और एक स्थिर सपोर्ट सिस्टम की ज़रूरत है।
अगर इसे सपोर्ट करना है, तो इसे डिज़ाइन भी करना होगा जिस पल कोई कस्टमर यह उम्मीद करता है कि कोई फ़ीचर अपग्रेड और नए यूज़र्स के आने के बाद भी काम करता रहे, तो उसे एक बार की डिलीवरी ट्रिक के बजाय प्रोडक्ट का हिस्सा मानें।
भले ही कोई चीज़ कोर प्रोडक्ट का काम बन जाए, फिर भी एंगेजमेंट को आगे बढ़ाने की ज़िम्मेदारी आपकी ही होती है। आपका काम कस्टमर की रुकावटों को दूर करना है, बिना इसके कि आप फ़ील्ड में चुपके से प्रोडक्ट को ही दोबारा लिख दें।
उस ज़िम्मेदारी के दो हिस्से हैं।
पहला, आप डिलीवरी को आगे बढ़ाते रहते हैं। आप रिक्वेस्ट को एक स्पष्ट ज़रूरत में बदलते हैं, यह पहचानते हैं कि मौजूदा डिप्लॉयमेंट में क्या संभव है, और एक ऐसा अस्थायी रास्ता सुझाते हैं जो सीमाओं के बारे में ईमानदार हो।
दूसरा, आप प्रोडक्ट की अखंडता (integrity) की रक्षा करते हैं। प्रोडक्ट की अखंडता का मतलब है कि प्रोडक्ट एक ही प्रोडक्ट के तौर पर सुसंगत बना रहे, न कि अकाउंट-विशिष्ट व्यवहारों का ऐसा ढेर बन जाए जो समय के साथ एक-दूसरे को खराब कर दें। असल में, इसका मतलब है कि आप ‘फ़ोर्क’ (कोड की अलग शाखाएं) से बचते हैं, ऐसे छिपे हुए फ़्लैग से बचते हैं जिनका इस्तेमाल सिर्फ़ एक कस्टमर करता है, और ऐसे वादे करने से बचते हैं जो बाद में इंजीनियरिंग टीम को मुश्किल में डाल दें।
हमारे मंज़ूरी वाले उदाहरण में, आप एक अस्थायी प्रक्रिया लागू कर सकते हैं जो ऑडिट की ज़रूरत को पूरा करे, जबकि आप कोर फ़ीचर के लिए सबूत इकट्ठा कर रहे हों। आप रिक्वेस्ट को मना नहीं कर रहे हैं, बल्कि उसे सही क्रम में लगा रहे हैं।
मुश्किल बात यह है कि हर तरह की विफलता (failure mode) उस पल में “रिस्पॉन्सिव होने” (तुरंत जवाब देने) जैसी लग सकती है। इसकी कीमत बाद में चुकानी पड़ती है, आमतौर पर तब जब आप किसी दूसरे कस्टमर के साथ काम कर रहे होते हैं।
आइए कुछ छोटे उदाहरण देखें कि कैसे ये विफलताएं बाद में लागत या समस्याएँ पैदा करती हैं।