संकेत और संदर्भ (Prompt and context)
मुझे उस समय के बारे में बताएं जब आपका और एक निर्भर टीम का API अनुबंध को लेकर मतभेद हुआ था। उनका मानना था कि आपके प्रस्ताव से रखरखाव की लागत बढ़ेगी, जबकि आपको डर था कि अनुबंध को अपरिवर्तित छोड़ने से विश्वसनीयता प्रभावित होगी। आपने तथ्यों को कैसे स्पष्ट किया, निर्णय लिया और डिलीवर किया?
यह प्रश्न क्रॉस-टीम सहयोग, तकनीकी ट्रेड-ऑफ और प्रभाव क्षमता (influence) का परीक्षण करता है। Atlassian की इंजीनियरिंग साक्षात्कार मार्गदर्शिका स्पष्ट रूप से समस्या-समाधान, सीखने की चपलता (learning agility), सहयोग और संचार की तलाश करती है। एक मजबूत उत्तर दूसरी टीम को बाधा के रूप में वर्णित करने के बजाय वास्तविक बाधाओं, सत्यापन योग्य साक्ष्यों, एक साझा निर्णय और परिणाम को दर्शाता है।
साक्षात्कारकर्ता क्या परख रहा है
साक्षात्कारकर्ता यह जानना चाहता है कि क्या आप असहमति को एक साझा लक्ष्य में बदल सकते हैं, प्राथमिकताओं से तथ्यों को अलग कर सकते हैं, संगतता (compatibility), विश्वसनीयता, लागत और शेड्यूल ट्रेड-ऑफ की व्याख्या कर सकते हैं, निर्णयों और स्वामित्व (ownership) को रिकॉर्ड कर सकते हैं, और साक्ष्य बदलने पर दिशा बदल सकते हैं। वे यह भी देखते हैं कि क्या आप निर्भर टीम की डिलीवरी गति की रक्षा करते हैं।
स्पष्टीकरण हेतु प्रश्न (Clarifying questions)
API उपभोक्ताओं (consumers), संस्करण (version), SLO, डेटा संवेदनशीलता, रिलीज़ विंडो और अस्वीकार्य विफलताओं की पुष्टि करें। पहचानें कि असहमति फ़ील्ड सिमेंटिक्स, त्रुटि अनुबंधों (error contracts), संगतता अवधि या परिचालन स्वामित्व से संबंधित है या नहीं। ऐसे लॉग, ट्रैफ़िक, विफलता के नमूने, माइग्रेशन प्रयास और रोलबैक स्थितियां तैयार करें जिन्हें दोनों टीमें सत्यापित कर सकें।
30-सेकंड का उत्तर
"मैंने पहले असहमति को एक साझा लक्ष्य के रूप में पुनः परिभाषित किया: रिलीज़ विंडो के भीतर विश्वसनीयता और रखरखाव की बाधाओं को पूरा करना। मैंने ज्ञात तथ्यों, मान्यताओं और अज्ञात तत्वों को अलग किया और निर्भर टीम को उन्हें मान्य करने के लिए आमंत्रित किया। हमने संगतता, ऑब्जर्वेबिलिटी (observability), माइग्रेशन और रोलबैक लागतों की तुलना की, फिर अनिश्चितता को कम करने के लिए एक छोटे प्रतिवर्ती (reversible) परीक्षण का उपयोग किया। अंत में हमने निर्णय, स्वामी (owner), समय सीमा और रोलबैक संकेतों को दर्ज किया। डिलीवरी के बाद, हमने परिणाम की जांच की और सबक को एक पुन: प्रयोज्य टेम्पलेट में बदल दिया।"
गहन-विश्लेषण उत्तर (Deep-dive answer)
चरण 1: उपयोगकर्ता और सेवा लक्ष्यों पर संरेखित हों
इस बात से शुरुआत न करें कि कौन सा फ़ील्ड डिज़ाइन सही है। उपयोगकर्ता प्रभाव, विश्वसनीयता लक्ष्य, रिलीज़ का समय और रखरखाव सीमाओं को लिखें ताकि दोनों टीमें एक ही परिणाम के लिए अनुकूलन करें। यदि लक्ष्य परस्पर विरोधी हैं, तो पहचानें कि उत्पाद या आर्किटेक्चर ट्रेड-ऑफ का स्वामित्व किसके पास है।
चरण 2: तथ्यों, मान्यताओं और प्राथमिकताओं को अलग करें
वास्तविक कॉल वॉल्यूम, विफलता दर, संगत क्लाइंट्स, माइग्रेशन प्रयास और समर्थन विंडो को सूचीबद्ध करें। बिना डेटा वाले दावों को मान्यताओं के रूप में चिह्नित करें और एक प्रतिवर्ती जांच निर्धारित करें। वरिष्ठता, टीम के आकार या बोलने की मात्रा को साक्ष्य के रूप में उपयोग न करें।
चरण 3: अनुबंध विकल्पों की तुलना करें
वर्तमान अनुबंध, सबसे छोटे संगत परिवर्तन और दीर्घकालिक डिज़ाइन की तुलना करें। प्रत्येक के लिए, फ़ील्ड सिमेंटिक्स, त्रुटि कोड, संस्करण, ऑब्जर्वेबिलिटी, प्रदर्शन, रखरखाव और रोलबैक रिकॉर्ड करें। निर्भर टीम से उसकी लागतें भरवाएं ताकि चर्चा "आप मुझे बदलने के लिए कह रहे हैं" वाली न बने।
चरण 4: एक प्रतिवर्ती प्रयोग डिज़ाइन करें
वैकल्पिक फ़ील्ड्स, दोहरे लेखन (dual writes), शैडो ट्रैफ़िक (shadow traffic), या उपभोक्ता अनुबंध परीक्षणों के साथ शुरुआत करें और वास्तविक परिणामों का निरीक्षण करें। प्रयोग को एक समय सीमा (time box), सफलता के उपाय और रोकने की शर्तें दें; संगतता परत (compatibility layer) को हमेशा के लिए न रहने दें।
चरण 5: निर्णय लें और रिकॉर्ड करें
ADR या प्रोजेक्ट रिकॉर्ड में संदर्भ, विकल्प, औचित्य, जोखिम, स्वामी, समय सीमा और रोलबैक ट्रिगर लिखें। लोग असहमति बरकरार रख सकते हैं, लेकिन उन्हें पता होना चाहिए कि निर्णय पर दोबारा कब विचार किया जाएगा।
चरण 6: निर्भर टीम की डिलीवरी को सुरक्षित रखें
माइग्रेशन उदाहरण, परीक्षण फिक्स्चर, एक संगतता विंडो और संयुक्त एकीकरण (integration) समय प्रदान करें। यदि आपका परिवर्तन काम बढ़ाता है, तो बताएं कि आप किस समर्थन के मालिक हैं; उपभोक्ताओं पर अधूरी माइग्रेशन की ज़िम्मेदारी चुपचाप न डालें।
चरण 7: मेट्रिक्स के साथ रोलआउट जोखिम प्रबंधित करें
रिलीज़ से पहले त्रुटि दर, विलंबता (latency), अज्ञात-फ़ील्ड दर, रोलबैक समय और उपभोक्ता सफलता को परिभाषित करें। ट्रैफ़िक को चरणों में विस्तारित करें और दोष मढ़ने की प्रतीक्षा करने के बजाय सीमाएं पार होने पर रोकें या रोलबैक करें।
चरण 8: सीखें और सिस्टम में बदलाव करें
जांचें कि क्या परिणाम मान्यताओं से मेल खाते हैं और रिकॉर्ड करें कि किस साक्ष्य ने निर्णय को बदल दिया। प्रक्रिया में अनुबंध टेम्पलेट, समीक्षा चेकलिस्ट, संगतता परीक्षण, या एक जिम्मेदारी मैट्रिक्स जोड़ें ताकि अगली असहमति पहले ही सामने आ जाए।
मॉडल उत्तर
ऑर्डर-स्थिति API माइग्रेशन के दौरान, उपभोक्ता टीम को डर था कि एक नया त्रुटि पदानुक्रम (error hierarchy) क्लाइंट रखरखाव को बढ़ाएगा, जबकि मुझे डर था कि अस्पष्ट त्रुटियां विफलता के दौरान पुन: प्रयासों (retries) को बढ़ा देंगी। हम पुनः प्रयास योग्य (retryable) और गैर-पुनः प्रयास योग्य स्थितियों के बीच अंतर करते हुए रिलीज़ विंडो को बनाए रखने पर सहमत हुए। हमने त्रुटि नमूनों, क्लाइंट संस्करणों और पुन: प्रयास की मात्रा के 30 दिनों की समीक्षा की और पाया कि दो स्थितियों के कारण अधिकांश जोखिम था। हमने पहले बैकवर्ड-संगत फ़ील्ड जोड़े और अनुबंध परीक्षणों तथा शैडो ट्रैफ़िक का उपयोग किया। मेरे पास उदाहरण SDK, माइग्रेशन गाइड और डैशबोर्ड का स्वामित्व था; दूसरी टीम के पास दो उच्च-वॉल्यूम क्लाइंट्स का स्वामित्व था। ADR ने स्वामियों, दो ठहराव संकेतों और रोलबैक को रिकॉर्ड किया। हमने धीरे-धीरे ट्रैफ़िक बढ़ाया, डुप्लिकेट अनुरोधों में कमी देखी, और पुराने क्लाइंट पार्सिंग में कोई विफलता नहीं पाई। पूर्वव्यापी समीक्षा (retrospective) ने समीक्षा में त्रुटि-अनुबंध टेम्पलेट को जोड़ा। यह निर्णय मेरी पसंद को थोपने से नहीं, बल्कि साझा मेट्रिक्स और प्रतिवर्ती कदमों से आया था।
सामान्य गलतियाँ
दूसरी टीम को तकनीकी रूप से कमजोर कहना
निर्भर टीम आमतौर पर उपभोक्ता की बाधाओं को जानती है। इसे खारिज करना माइग्रेशन लागत को छुपाता है और विश्वास-निर्माण का प्रदर्शन नहीं करता है।
केवल अंतिम डिज़ाइन का वर्णन करना
साक्षात्कारकर्ता को यह देखना होगा कि आपने ट्रेड-ऑफ़ की तुलना कैसे की। कम से कम दो विकल्पों, साक्ष्यों और एक को क्यों खारिज किया गया, इसकी व्याख्या करें।
कोई मापने योग्य परिणाम या स्वामित्व न देना
"हर कोई सहमत हो गया" कोई परिणाम नहीं है। मेट्रिक्स, समय सीमा, अपना कार्य और शेष जोखिम बताएं।
अनुवर्ती प्रश्न और उत्तर
क्या होगा यदि दूसरी टीम अभी भी असहमत है?
जांचें कि क्या नए तथ्यों ने विवाद को बदल दिया है, फिर निर्णय प्रक्रिया द्वारा नामित आर्किटेक्चर या उत्पाद स्वामी से चयन करने के लिए कहें। सबसे छोटे प्रतिवर्ती कदम को डिलीवर करते हुए असहमति, जोखिम और समीक्षा तिथि रिकॉर्ड करें।
यदि रिलीज़ से पहले केवल दो दिन बचे हों तो क्या होगा?
दायरा कम करें, अपरिवर्तनीय जोखिम और महत्वपूर्ण उपभोक्ताओं की रक्षा करें, और संगत फ़ील्ड, एक फ़्लैग या शैडो सत्यापन का उपयोग करें। बताएं कि क्या स्थगित किया गया है; मौखिक वादे को रोलबैक का विकल्प न बनाएं।
आप कैसे दिखाते हैं कि डिज़ाइन ओवर-इंजीनियर्ड नहीं था?
उन क्षमताओं के नाम बताएं जिन्हें आपने हटा दिया, वास्तविक ट्रैफ़िक और विफलता लागत की तुलना करें, संगतता परत को समयबद्ध करें, और इसे हटाने की योजना बनाएं। साक्ष्यों को जटिलता तय करने दें।
क्या होगा यदि डेटा आपके निर्णय को गलत साबित कर दे?
स्वीकार करें कि धारणा गलत थी, ADR और सीमाओं को अपडेट करें, सुरक्षित रास्ता चुनें, और दिखाएं कि आपने प्रभावित टीमों के साथ नए साक्ष्य कैसे साझा किए।
आप उसी असहमति को दोबारा होने से कैसे रोकते हैं?
अनुबंध, संस्करण, त्रुटि, संगतता-विंडो और स्वामित्व निर्णयों को एक टेम्पलेट में बदलें। उपभोक्ता अनुबंध परीक्षण और एक संक्षिप्त प्री-कोड समीक्षा के साथ एक रिलीज़ चेकलिस्ट जोड़ें।
यह नियंत्रण के बजाय प्रभाव को कैसे प्रदर्शित करता है?
इस बात पर जोर दें कि आपने सहायक कार्य का स्वामित्व लेते हुए एक साझा लक्ष्य, साक्ष्य और प्रतिवर्ती निर्णय बनाया। टीम ने परिणाम चुना; आपने दूसरी टीम पर दबाव नहीं बनाया।