आप लक्षण जानते हैं। इंजीनियरिंग वही बनाती है जो वे विशिष्टता से समझते हैं। उत्पाद परिणाम को देखता है और कहता है कि यह वह नहीं है जो उनका मतलब था। डिज़ाइन बताता है कि इंटरैक्शन को अलग तरीके से काम करना चाहिए था। मार्केटिंग पूछती है कि जिस सुविधा की उन्होंने पिछले सप्ताह घोषणा की थी वह रिलीज़ में क्यों नहीं है। और हर कोई बिना कुछ बदले "संचार" पर एक समस्या के रूप में चर्चा करके रेट्रोस्पेक्टिव को छोड़ देता है।
मानक ⟦रेट्रो⟧ प्रारूप क्रॉस-फ़ंक्शनल तनाव के लिए डिज़ाइन नहीं किए गए थे। "क्या अच्छा हुआ / क्या नहीं" टीम को एक एकल इकाई के रूप में मानता है, जो कार्यों के बीच अंतराल पर ध्यान केंद्रित करती है। दिलचस्प समस्याएं - गलत संरेखित प्राथमिकताएं, टूटी हुई हैंडऑफ़, गायब संदर्भ - पीएम, इंजीनियरिंग, डिज़ाइन और गो-टू-मार्केट के बीच के स्थानों में रहते हैं। आपको एक ⟦रेट्रो⟧ प्रारूप की आवश्यकता है जो उन्हें ढूंढ सके।
क्रॉस-फ़ंक्शनल रेट्रोज़ को एक अलग दृष्टिकोण की आवश्यकता क्यों है
एकल-फ़ंक्शन टीम में, हर कोई लगभग समान संदर्भ साझा करता है। एक इंजीनियरिंग टीम रेट्रोस्पेक्टिव कोडबेस, टूलींग और तकनीकी ट्रेडऑफ़ की साझा समझ ग्रहण कर सकती है।
क्रॉस-फ़ंक्शनल टीमों के पास यह विलासिता नहीं है। प्रत्येक फ़ंक्शन अलग-अलग चीज़ों के लिए अनुकूलित होता है:
- उत्पाद ग्राहक परिणामों और व्यावसायिक प्रभाव पर केंद्रित है
- इंजीनियरिंग तकनीकी गुणवत्ता, रखरखाव और वितरण गति पर केंद्रित है
- डिज़ाइन उपयोगकर्ता अनुभव सुसंगतता और प्रयोज्यता पर केंद्रित है
- GTM (विपणन, बिक्री, समर्थन) स्थिति, लॉन्च की तैयारी और ग्राहक संचार पर केंद्रित है
ये परस्पर विरोधी लक्ष्य नहीं हैं। वे पूरक हैं. लेकिन वे प्राकृतिक तनाव बिंदु बनाते हैं जो तभी दिखाई देते हैं जब आप एक ही काम को कई कोणों से देखते हैं। एक सुविधा तकनीकी रूप से अच्छी तरह से निर्मित हो सकती है, खराब डिज़ाइन की जा सकती है, सही ढंग से स्थित हो सकती है, और फिर भी ग्राहक की आवश्यकता से चूक सकती है। प्रत्येक फ़ंक्शन का एक अलग मूल्यांकन होगा कि स्प्रिंट कैसा रहा।
प्रारूप: फ़ंक्शन परिप्रेक्ष्य + संरेखण कॉलम
पांच कॉलम सेट करें:
उत्पाद परिप्रेक्ष्य - उत्पाद के दृष्टिकोण से यह चक्र कैसा दिखता था? क्या सही समस्याओं को प्राथमिकता दी गई? क्या ग्राहक अंतर्दृष्टि ने इसे काम में लाया? क्या समझौता सोच-समझकर किया गया?
इंजीनियरिंग परिप्रेक्ष्य - इंजीनियरिंग से यह साइकिल कैसी दिखती थी? क्या आवश्यकताएँ इतनी स्पष्ट थीं कि उनके विरुद्ध निर्माण किया जा सके? क्या ऐसी कोई तकनीकी बाधाएँ थीं जिन्हें नियोजन में शामिल नहीं किया गया था? पुनर्कार्य कहाँ हुआ?
डिज़ाइन परिप्रेक्ष्य — डिज़ाइन से यह साइकिल कैसी दिखती थी? क्या अंतिम कार्यान्वयन इच्छित अनुभव से मेल खाता है? क्या तकनीकी बाधाओं के बारे में पर्याप्त संदर्भ के साथ डिज़ाइन निर्णय लिए गए थे? डिज़ाइन और जो भेजा गया उसमें कहां अंतर था?
GTM परिप्रेक्ष्य - बाज़ार जाने के दृष्टिकोण से यह साइकिल कैसी दिखती थी? क्या टीम को इस बात की जानकारी दी गई कि शिपिंग क्या थी और कब थी? क्या ऐसे आश्चर्य थे जिनसे मैसेजिंग, दस्तावेज़ीकरण, या समर्थन तैयारी प्रभावित हुई?
संरेखण — यह सबसे महत्वपूर्ण स्तंभ है। फ़ंक्शन कॉलम भरने के बाद, टीम उन थीमों की पहचान करती है जो फ़ंक्शंस से संबंधित हैं। ये आपके वास्तविक सुधार के अवसर हैं।
इसे कैसे सुविधाजनक बनाएं
सिंगल-टीम रेट्रो की तुलना में क्रॉस-फंक्शनल रेट्रो को सुविधाजनक बनाना कठिन है क्योंकि पावर डायनेमिक्स अलग हैं। यहां बताया गया है कि क्या काम करता है:
फ़ंक्शन में फैसिलिटेटर को घुमाएं। इसे हमेशा पीएम या स्क्रम मास्टर से न चलाएं। जब कोई इंजीनियर सुविधा प्रदान करता है, तो वे स्वाभाविक रूप से अलग-अलग प्रश्न पूछते हैं। जब कोई डिज़ाइनर सुविधा देता है, तो वे विभिन्न पैटर्न देखते हैं। रोटेशन भी सहानुभूति बनाता है: एक समूह के लिए रेट्रो की सुविधा जिसमें आपका कार्य शामिल है, आपको अपने से अलग दृष्टिकोण के लिए जगह रखने के लिए मजबूर करता है।
फ़ंक्शन कॉलम के लिए अनाम इनपुट का उपयोग करें। जब उनका नाम संलग्न नहीं होता है तो लोग क्रॉस-फ़ंक्शनल घर्षण के बारे में अधिक ईमानदार होते हैं। "आवश्यकताएँ अस्पष्ट थीं और तीन बार बदली गईं" उन आवश्यकताओं को लिखने वाले प्रधान मंत्री के सामने ज़ोर से कहने की तुलना में किसी गुमनाम कार्ड पर लिखना आसान है।
प्रत्येक फ़ंक्शन के कॉलम को समान रूप से टाइमबॉक्स करें। संरचना के बिना, सबसे तेज़ फ़ंक्शन हावी होता है। प्रत्येक कॉलम को पाँच से सात मिनट की चर्चा का समय दें। यह सुनिश्चित करता है कि इंजीनियरिंग डिज़ाइन को स्टीमरोल नहीं करती है, और GTM को छोड़ नहीं दिया जाता है क्योंकि टीम के पास समय समाप्त हो गया है।
हर चीज़ को प्रक्रिया के मुद्दों के रूप में फ़्रेम करें, न कि लोगों के मुद्दों के रूप में। "डिज़ाइन से लेकर इंजीनियरिंग तक के हैंडऑफ़ में इंटरैक्शन विनिर्देश शामिल नहीं थे" कार्रवाई योग्य है। "डिज़ाइनर ने स्पष्ट रूप से संवाद नहीं किया" एक दोषपूर्ण बयान है जो बातचीत को बंद कर देता है।
हैंडऑफ़ समस्या
यदि कोई एक मुद्दा है जो क्रॉस-फ़ंक्शनल रेट्रो किसी भी अन्य की तुलना में अधिक सतह पर है, तो वह टूटा हुआ हैंडऑफ़ है। ऐसे क्षण जब कार्य एक कार्य से दूसरे कार्य में जाता है, तब जानकारी लुप्त हो जाती है।
सामान्य हैंडऑफ़ विफलता बिंदु:
प्रधानमंत्री से डिजाइन: उत्पाद आवश्यकताओं में ग्राहक की समस्या के बारे में पर्याप्त संदर्भ का अभाव होता है, जिससे डिजाइनर धारणाएं बनाते हैं। या ऐसी आवश्यकताएं जो बहुत अधिक निर्देशात्मक हैं, जो डिजाइनरों को समाधान स्थान तलाशने से रोकती हैं।
डिज़ाइन टू इंजीनियरिंग: ऐसे डिलिवरेबल्स डिज़ाइन करें जो तकनीकी बाधाओं, किनारे के मामलों या प्रतिक्रियाशील व्यवहार को ध्यान में न रखें। या डिज़ाइन इतनी देर से सौंपे गए कि इंजीनियरिंग को अंतिम रूप देने से पहले निर्माण शुरू करना पड़ा।
इंजीनियरिंग से GTM: मार्केटिंग के लिए पोजिशनिंग, दस्तावेज़ीकरण, या समर्थन सामग्री तैयार करने के लिए पर्याप्त लीड समय के बिना पूरी की गई सुविधाएँ। या दायरे में परिवर्तन जिसके बारे में सूचित नहीं किया जाता है, जिससे गलत घोषणाएं होती हैं।
GTM से उत्पाद: बिक्री, समर्थन और विपणन से ग्राहक प्रतिक्रिया और बाजार संकेत जो उत्पाद प्राथमिकता में वापस नहीं आते हैं।
आपके ⟦रेट्रो⟧ को हैंडऑफ़ के बारे में स्पष्ट रूप से पूछना चाहिए: कौन सा हैंडऑफ़ सुचारू रूप से चला, कौन सा समस्याएँ उत्पन्न करता है, और कौन सा हैंडऑफ़ बेहतर होगा। समय के साथ, यह एक फीडबैक लूप बनाता है जो कार्यों के बीच सीम को मजबूत करता है।
कार्रवाई आइटम जिनमें वास्तव में सहयोग की आवश्यकता होती है
क्रॉस-फ़ंक्शनल रेट्रोज़ में सबसे बड़ी गलती व्यक्तिगत कार्यों के लिए एक्शन आइटम निर्दिष्ट करना है। "इंजीनियरिंग बेहतर दस्तावेज़ लिखेगी" या "डिज़ाइन पहले वितरित करेगा" एकल-फ़ंक्शन प्रतिबद्धताएं हैं जो क्रॉस-फ़ंक्शनल मूल कारण को संबोधित नहीं करती हैं।
बेहतर एक्शन आइटम इस तरह दिखते हैं:
- स्प्रिंट शुरू होने से पहले स्वीकृति मानदंड पर प्रधानमंत्री और तकनीकी नेतृत्व की जोड़ी, सहयोगात्मक कार्य सत्र के साथ हैंडऑफ़ की जगह
- एसिंक्रोनस टिप्पणियों के बजाय वास्तविक समय में सवालों के जवाब देने के लिए जटिल सुविधाओं के लिए डिजाइनर कार्यान्वयन के पहले दिन से जुड़ते हैं
- इंजीनियरिंग GTM को आत्मविश्वास के स्तर के साथ मध्य-स्प्रिंट पर "शिपिंग पूर्वानुमान" देती है, इसलिए मार्केटिंग बाइनरी पूर्ण/नहीं किए गए सिग्नल पर भरोसा किए बिना योजना बना सकती है
- मासिक क्रॉस-फ़ंक्शनल संरेखण जांच जहां प्रत्येक फ़ंक्शन अपनी वर्तमान प्राथमिकताओं को साझा करता है और टीम समस्या बनने से पहले संघर्षों की पहचान करती है
पैटर्न: एक्शन आइटम जो एक फ़ंक्शन को अलग-थलग सुधारने के लिए कहने के बजाय फ़ंक्शंस के बीच टचप्वाइंट बनाते हैं।
असुविधाजनक गतिशीलता से निपटना
आइए हम इस बारे में ईमानदार रहें कि कौन सी चीज़ क्रॉस-फ़ंक्शनल रेट्रो को कठिन बनाती है। इसमें वास्तविक शक्ति की गतिशीलता काम कर रही है।
प्राथमिकताओं पर अक्सर अंतिम फैसला प्रधानमंत्री का होता है। इससे इंजीनियरों और डिजाइनरों को ऐसा महसूस हो सकता है कि रेट्रो प्रदर्शनात्मक है - वे मुद्दे उठा सकते हैं, लेकिन प्रधानमंत्री तय करेंगे कि क्या किया जाए। यह सुनिश्चित करके इसका मुकाबला करें कि इंजीनियरिंग और डिज़ाइन के पास इस बात का वास्तविक स्वामित्व है कि उनका कार्य कैसे संचालित होता है, भले ही उत्पाद का स्वामित्व उस पर हो।
विभिन्न कार्यों में वरिष्ठता का अंतर। यदि इंजीनियरिंग का वीपी किसी जूनियर डिजाइनर के साथ रेट्रो में है, तो सक्रिय सुविधा के बिना बातचीत संतुलित नहीं होगी। इस बात पर विचार करें कि क्या कमरे में सही लोग हैं, या क्या सहकर्मी स्तर पर कुछ रेट्रो होना चाहिए।
ऐतिहासिक शिकायतें। क्रॉस-फ़ंक्शनल टीमें अक्सर पिछले चक्रों से अनसुलझे निराशाएं लेकर आती हैं। पहले कुछ रेट्रोज़ में वेंटिंग का बोलबाला हो सकता है। यह होने दिया। निराशा के बैकलॉग को दूर करें ताकि आप रचनात्मक क्षेत्र में आगे बढ़ सकें। लेकिन यह अपेक्षा जरूर रखें कि शुरुआती सत्रों के बाद ध्यान भविष्योन्मुखी सुधारों पर केंद्रित हो जाए।
दूरस्थ बनाम सह-स्थित असंतुलन। यदि कुछ कार्य कार्यालय में हैं और अन्य दूरस्थ हैं, तो दूरस्थ प्रतिभागियों को संरचनात्मक नुकसान होता है। पूरी तरह से डिजिटल रेट्रो प्रारूप का उपयोग करें जहां स्थान की परवाह किए बिना हर कोई एक ही इंटरफ़ेस के माध्यम से योगदान देता है।
समय के साथ कैसा अच्छा दिखता है
आपको पता चल जाएगा कि क्रॉस-फ़ंक्शनल रेट्रो तब काम कर रहे हैं जब:
- हैंडऑफ़ शिकायतों में कमी आई है क्योंकि टीम सक्रिय रूप से संक्रमण बिंदुओं में सुधार कर रही है
- फ़ंक्शन पूछे जाने की प्रतीक्षा करने के बजाय एक-दूसरे के लिए स्वेच्छा से संदर्भ देना शुरू करते हैं
- कार्रवाई आइटम में स्वाभाविक रूप से कई कार्यों का सहयोग शामिल होता है
- "संरेखण" कॉलम कम आइटम उत्पन्न करना शुरू कर देता है क्योंकि संरेखण डिफ़ॉल्ट बन रहा है
- विभिन्न कार्यों के लोग रेट्रो के बाहर बातचीत की योजना बनाते समय एक-दूसरे के दृष्टिकोण का संदर्भ देते हैं
ऐसा एक सत्र में नहीं होता है. टीम को वास्तव में उत्पादक क्रॉस-फ़ंक्शनल बातचीत करने के लिए पर्याप्त विश्वास और साझा भाषा बनाने में तीन से पांच चक्र लगते हैं। इसके साथ बने रहें.
व्यावहारिक युक्तियाँ
एक पायलट के साथ शुरुआत करें। यदि आपकी टीम ने कभी क्रॉस-फंक्शनल रेट्रो नहीं चलाया है, तो सबसे हालिया लॉन्च या मील के पत्थर पर केंद्रित एकल सत्र से शुरुआत करें। यह प्रारूप को एक ठोस विषय देता है और "आम तौर पर सहयोग कैसा चल रहा है" की अस्पष्टता से बचता है।
इसे अधिकतम 75 मिनट तक रखें। क्रॉस-फ़ंक्शनल रेट्रो मानक रेट्रो की तुलना में भारी होते हैं क्योंकि सुनने के लिए अधिक परिप्रेक्ष्य होते हैं। लेकिन 75 मिनट से अधिक समय तक चलने से थकान और गुणवत्ता में गिरावट आती है। टाइमबॉक्सिंग के बारे में अनुशासित रहें।
सभी कार्यों का सारांश साझा करें। रेट्रो के बाद, सभी हितधारकों को मुख्य विषयों और कार्रवाई वस्तुओं का एक संक्षिप्त सारांश भेजें, जिनमें वे लोग भी शामिल हैं जो कमरे में नहीं थे। इससे पारदर्शिता और जवाबदेही बनती है।
उन्हें हर स्प्रिंट पर न दौड़ाएं। हर दो से चार सप्ताह आमतौर पर क्रॉस-फ़ंक्शनल रेट्रोज़ के लिए सही होते हैं। बीच में, व्यक्तिगत फ़ंक्शन फ़ंक्शन-विशिष्ट सुधारों पर केंद्रित अपना स्वयं का रेट्रोस्पेक्टिव चला सकते हैं।
<घंटा/>NextRetro निःशुल्क आज़माएं - अनाम कार्ड, प्रत्येक फ़ंक्शन के लिए अनुकूलन योग्य कॉलम और संरेखण मुद्दों को प्राथमिकता देने के लिए वोटिंग के साथ क्रॉस-फ़ंक्शनल रेट्रोस्पेक्टिव चलाएं।
<घंटा/>अंतिम अद्यतन: फरवरी 2026
पढ़ने का समय: 7 मिनट
