उत्पाद प्रबंधकों और इंजीनियरों के बीच मनमुटाव सॉफ्टवेयर टीमों में सबसे अनुमानित समस्याओं में से एक है, और सबसे लगातार गलत तरीके से संभाली जाने वाली समस्याओं में से एक है।
प्रधानमंत्री को ऐसा लगता है कि इंजीनियर बिना कोई विकल्प दिए हर काम को टाल देते हैं। इंजीनियरों को ऐसा लगता है कि प्रधानमंत्री तकनीकी जटिलता को समझे बिना समय सीमा और दायरे के प्रति प्रतिबद्ध हैं। दोनों पक्ष आम तौर पर दूसरे पक्ष की खामियों के बारे में सही होते हैं, और दोनों ही आम तौर पर दूसरे पक्ष के इरादों के बारे में गलत होते हैं।
मानक स्प्रिंट ⟦RETROS⟧ शायद ही कभी इसे ठीक करते हैं क्योंकि वे टीम की सीमाओं के भीतर रहते हैं। इंजीनियरों के साथ रेट्रो इंजीनियर। प्रधानमंत्रियों ने प्रधानमंत्रियों से चर्चा की। क्रॉस-फ़ंक्शनल तनाव तब तक जमा होता रहता है जब तक कि यह किसी योजना बैठक या छूटी हुई समय सीमा में भड़क न जाए।
एक समर्पित उत्पाद-इंजीनियरिंग ⟦RETRO⟧ दोनों दृष्टिकोणों को एक ऐसी संरचना के साथ एक ही कमरे में रखता है जो बातचीत को जुझारू के बजाय उत्पादक बनाता है।
चार आवर्ती घर्षण बिंदु
रेट्रो⟧ को डिज़ाइन करने से पहले, यह तनावों को ईमानदारी से नाम देने में मदद करता है। अधिकांश टीमों में, वे चार श्रेणियों में विभाजित होते हैं।
1. आवश्यकताएँ जो स्पष्ट लगती हैं लेकिन हैं नहीं
एक प्रधानमंत्री एक विशेष विवरण लिखता है जिस पर वे पूरी तरह विचार करते हैं। एक इंजीनियर इसे पढ़ता है और उसके पास पंद्रह प्रश्न होते हैं। पीएम को लगता है जैसे इंजीनियर गड़बड़ी कर रहा है. इंजीनियर को लगता है कि पीएम ने किनारे के मामलों के बारे में नहीं सोचा है।
मूल मुद्दा शायद ही कभी दोनों तरफ का आलस्य हो। प्रधानमंत्री और इंजीनियर उत्पादों के बारे में अलग तरह से सोचते हैं। प्रधानमंत्री उपयोगकर्ता यात्राओं और व्यावसायिक परिणामों के बारे में सोचते हैं। इंजीनियर डेटा प्रवाह, राज्य प्रबंधन और विफलता मोड में सोचते हैं। एक दृष्टिकोण जो एक दृष्टिकोण से पूर्ण है, दूसरे दृष्टिकोण से अंतराल से भरा है।
2. गति बनाम गुणवत्ता
पीएम समय पर शिपिंग के लिए जवाबदेह हैं। उत्पादन में गड़बड़ी होने पर इंजीनियर जवाबदेह होते हैं। ये प्रोत्साहन विपरीत दिशाओं में खींचते हैं, और कोई भी गलत नहीं है।
संघर्ष दायरे में कटौती, परीक्षण कवरेज, कोड समीक्षा की संपूर्णता और तकनीकी शॉर्टकट अपनाने पर बहस के रूप में दिखाई देता है। इन ट्रेडऑफ़ के बारे में स्पष्ट बातचीत के बिना, प्रत्येक पक्ष यह मान लेता है कि दूसरे को इस बात की परवाह नहीं है कि क्या मायने रखता है।
3. तकनीकी ऋण
इंजीनियरों को कर्ज बढ़ता हुआ दिख रहा है और वे इसका समाधान करने के लिए समय चाहते हैं। प्रधान मंत्री उपयोगकर्ता-सामना वाली सुविधाओं का एक बैकलॉग देखते हैं और उन कार्यों को उचित ठहराने के लिए संघर्ष करते हैं जो ग्राहकों के लिए अदृश्य हैं। परिणाम: कर्ज़ तब तक के लिए स्थगित कर दिया जाता है जब तक कि वह घटनाओं का कारण न बनने लगे, जिस बिंदु पर हर कोई सहमत होता है कि इसे पहले ही संभाल लिया जाना चाहिए था।
4. अनुमान और पूर्वानुमान
प्रधानमंत्री को हितधारकों को समयसीमा बताने की जरूरत है। इंजीनियर अनुमान देने से बचते हैं क्योंकि वे जानते हैं कि कितनी अनिश्चितता मौजूद है। प्रधानमंत्री सुनते हैं "मैं प्रतिबद्धता नहीं करना चाहता" और इंजीनियर सुनते हैं "बस मुझे बताओ कि मैं क्या सुनना चाहता हूँ।" कोई भी व्याख्या सटीक नहीं है।
⟦RETROC⟧ की स्थापना
इसे त्रैमासिक या प्रमुख रिलीज़ के बाद चलाएँ। मासिक बहुत बार होता है - पैटर्न को विकसित होने के लिए समय की आवश्यकता होती है।
कौन भाग लेता है: उत्पाद प्रबंधक, तकनीकी प्रमुख और वरिष्ठ इंजीनियर। समूह को 6-10 लोगों तक रखें। यदि समूह बड़ा है, तो बातचीत प्रदर्शनात्मक हो जाती है।
अवधि: 90 मिनट. क्रॉस-फ़ंक्शनल ⟦RETROS⟧ को समान-टीम वाले की तुलना में अधिक समय लगता है क्योंकि आपको केवल सतही मुद्दों के लिए नहीं, बल्कि साझा समझ बनाने के लिए समय की आवश्यकता होती है।
सुविधा: एक तटस्थ सुविधाकर्ता का उपयोग करें, आदर्श रूप से कोई ऐसा व्यक्ति जो टीम में प्रधान मंत्री या इंजीनियर न हो। एक इंजीनियरिंग प्रबंधक, एक स्क्रम मास्टर, या किसी अन्य टीम का कोई व्यक्ति अच्छा काम करता है। सूत्रधार का काम बातचीत को बहस बनने से रोकना और यह सुनिश्चित करना है कि दोनों पक्षों को सुना जाए।
एक संरचना जो काम करती है
भाग 1: दोहरे परिप्रेक्ष्य संग्रह (20 मिनट)
क्या प्रधान मंत्री और इंजीनियर स्वतंत्र रूप से समान तीन संकेतों का उत्तर देते हुए कार्ड लिखते हैं:
- इस तिमाही में हमारे सहयोग में क्या अच्छा रहा?
- घर्षण ने हमें कहाँ धीमा कर दिया?
- आप क्या चाहते हैं कि दूसरा पक्ष बेहतर ढंग से समझे?
तीसरा संकेत महत्वपूर्ण है। यह उन धारणाओं और कुंठाओं को सामने लाता है जो आम तौर पर अनकही रह जाती हैं।
सभी कार्ड गुमनाम रूप से एकत्र करें। यह मायने रखता है - लोग अधिक ईमानदारी से लिखते हैं जब उनका नाम संलग्न नहीं होता है, खासकर क्रॉस-फ़ंक्शनल तनाव के बारे में।
भाग 2: थीम चर्चा (40 मिनट)
कार्डों को थीम में समूहित करें। सामान्य लोगों में शामिल हैं: आवश्यकताओं की स्पष्टता, अनुमान प्रक्रिया, प्राथमिकता निर्णय, संचार अंतराल, और तकनीकी ऋण प्रबंधन।
प्रत्येक विषय के लिए, इस बहस के प्रलोभन से बचें कि कौन सही है। इसके बजाय, पूछें:
- प्रत्येक पक्ष किस लिए अनुकूलन कर रहा है? (आमतौर पर दोनों पक्षों के पास वैध लक्ष्य होते हैं जो तनाव में होते हैं।)
- हैंडऑफ कहां टूट रहा है? (अधिकांश घर्षण भूमिकाओं के बीच की सीमाओं पर होता है, उनके भीतर नहीं।)
- प्रत्येक पक्ष के पास किस जानकारी का अभाव है? (कई संघर्ष वास्तव में छिपी हुई सूचना विषमताएं हैं।)
भाग 3: विशिष्ट समझौते (30 मिनट)
अस्पष्ट इरादों के साथ न निकलें। उन विशिष्ट कामकाजी समझौतों के साथ निकलें जिनके लिए दोनों पक्ष प्रतिबद्ध हैं।
अच्छे कामकाजी समझौते हैं:
- अवलोकन योग्य -- आप बता सकते हैं कि वे घटित हो रहे हैं या नहीं।
- द्विपक्षीय -- दोनों पक्ष कुछ बदलते हैं, न कि केवल एक पक्ष दूसरे से मांग करता है।
- टाइम-बॉक्स्ड -- उन्हें एक तिमाही के लिए आज़माएं और मूल्यांकन करें।
यहां उन समझौतों के उदाहरण दिए गए हैं जो काम करते हैं:
आवश्यकताओं की स्पष्टता के लिए: "विशेष रूप से किनारे के मामलों और तकनीकी बाधाओं की पहचान करने के लिए किसी भी फीचर विशिष्टता को व्यापक टीम के साथ साझा करने से पहले प्रधान मंत्री और तकनीकी प्रमुख एक साथ 30 मिनट बिताएंगे।"
अनुमान के लिए: "इंजीनियर एकल-बिंदु अनुमान के बजाय रेंज अनुमान (सर्वोत्तम मामला / संभावित / सबसे खराब मामला) प्रदान करेंगे, और पीएम केवल सर्वोत्तम मामले के बजाय हितधारकों को रेंज के बारे में बताएंगे।"
तकनीकी ऋण के लिए: "प्रत्येक स्प्रिंट की क्षमता का 20% इंजीनियरिंग-प्राथमिकता वाले कार्य के लिए आरक्षित है। पीएम इस क्षमता को आवंटित नहीं करते हैं और इंजीनियरों को व्यक्तिगत वस्तुओं को उचित ठहराने की आवश्यकता नहीं है, लेकिन इंजीनियर किस पर समय खर्च किया गया इसका त्रैमासिक सारांश साझा करते हैं।"
स्कोप चर्चा के लिए: "जब दायरे में कटौती की आवश्यकता होती है, तो पीएम प्रस्तावित करते हैं कि क्या कटौती की जाए और इंजीनियर प्रस्तावित करता है कि इसे कैसे सरल बनाया जाए। निर्णय लेने से पहले दोनों विकल्पों पर चर्चा की जाती है।"
कठिन बातचीत को संभालना
कुछ विषय लगातार क्रॉस-फंक्शनल ⟦RETROS⟧ को पटरी से उतार देते हैं। यहां बताया गया है कि उन्हें कैसे संभालना है।
"तकनीकी ऋण के लिए हमारे पास कभी समय नहीं होता।" तकनीकी ऋण मायने रखता है या नहीं, इस पर बहस न करें। इसके बजाय, पूछें: वर्तमान ऋण की लागत क्या है? यदि इंजीनियर विशिष्ट घटनाओं, मंदी, या डेवलपर को ऋण के कारण होने वाली समस्याओं की ओर इशारा कर सकते हैं, तो बातचीत अमूर्त से ठोस में बदल जाती है। पीएम प्रभावशाली डेटा पर प्रतिक्रिया देते हैं, कोड गुणवत्ता के लिए अमूर्त अपील पर नहीं।
"आवश्यकताएं बदलती रहती हैं।" आवश्यकताएं बदलती रहती हैं क्योंकि बाजार बदलता है, उपयोगकर्ता प्रतिक्रिया आती है, और हितधारक प्राथमिकताएं बदलते हैं। सवाल यह नहीं है कि क्या आवश्यकताएं बदलेंगी, बल्कि सवाल यह है कि परिवर्तन कैसे संप्रेषित किए जाते हैं और वे प्रक्रिया में कितनी देर से आते हैं। प्रक्रिया पर ध्यान दें: विकास के किस बिंदु पर गुंजाइश को समाप्त माना जाना चाहिए? उस बिंदु के बाद परिवर्तनों के लिए आगे बढ़ने का मार्ग क्या है?
"इंजीनियरिंग हमेशा कम आंकलन करती है।" इसे पलटें: क्या टीम समय के साथ सटीकता का अनुमान लगाती है? यदि नहीं, तो शुरू करें. डेटा के कुछ हिस्सों के बाद, बातचीत आरोप-प्रत्यारोप से पैटर्न की ओर बढ़ती है। हो सकता है कि टीम लगातार एक विशिष्ट प्रकार के काम (एकीकरण, माइग्रेशन) को कम आंकती हो और दूसरों पर सटीक हो। यह कार्रवाई योग्य है.
"प्रधानमंत्री यह नहीं समझते कि यह कितना जटिल है।" यह अक्सर सच है, और जटिलता को दृश्यमान बनाना भी इंजीनियर का काम है। यदि कोई इंजीनियर कहता है "यह कठिन है" और प्रधान मंत्री सुन लेते हैं "यह कठिन है," तो कुछ भी नहीं बदलता है। यदि इंजीनियर कहता है, "इसके लिए तीन सेवाओं में बदलाव, एक डेटाबेस माइग्रेशन की आवश्यकता है, और माइग्रेशन विफल होने पर डाउनटाइम का जोखिम है," तो पीएम वास्तव में ट्रेडऑफ़ के बारे में तर्क दे सकते हैं।
समय के साथ कैसा अच्छा दिखता है
इनमें से तीन या चार रेट्रोस्पेक्टिव के बाद, आपको ठोस बदलाव देखने चाहिए:
- स्प्रिंट योजना में कम आश्चर्य क्योंकि पीएम और तकनीकी नेतृत्व पहले संरेखित हो रहे हैं
- निष्क्रिय-आक्रामक गतिरोध के बजाय ट्रेडऑफ़ के बारे में अधिक ईमानदार बातचीत
- पुनर्कार्य कम हो गया क्योंकि विकास शुरू होने से पहले दोनों दृष्टिकोणों से आवश्यकताओं का पता लगाया जाता है
- तकनीकी ऋण को संकट उत्पन्न होने तक स्थगित करने के बजाय धीरे-धीरे संबोधित किया जा रहा है
- अनुमान अधिक सटीक हो रहे हैं क्योंकि टीम पिछले प्रदर्शन के आधार पर आकलन कर रही है
लक्ष्य उत्पाद और इंजीनियरिंग के बीच तनाव को खत्म करना नहीं है। कुछ तनाव स्वस्थ है - इसका मतलब है कि दोनों पक्ष उन चीज़ों की वकालत कर रहे हैं जो मायने रखती हैं। लक्ष्य उस तनाव को संक्षारक के बजाय उत्पादक बनाना है।
<घंटा/>NextRetro निःशुल्क आज़माएं -- अनाम कार्ड संग्रह और संरचित चर्चा वर्कफ़्लो के साथ क्रॉस-फ़ंक्शनल रेट्रोस्पेक्टिव की सुविधा प्रदान करें।
<घंटा/>अंतिम अद्यतन: फरवरी 2026
पढ़ने का समय: 7 मिनट
