1.2 टीम टोपोलॉजी और संगठनात्मक डिज़ाइन

अवलोकन और प्रेरणा

आप लोगों को टीमों में किस तरह बाँटते हैं, यह तय करता है कि आप कौन-सा सॉफ़्टवेयर बना सकते हैं और कितनी तेज़ी से बना सकते हैं। यह कोई रूपक नहीं है। यह लगभग यांत्रिक परिणाम है, जिसे कॉनवे का नियम कहा जाता है: संगठन ऐसी प्रणालियाँ डिज़ाइन करते हैं जो उनकी अपनी संचार-संरचनाओं की छवि होती हैं। यदि तीन टीमें मिलकर एक कंपाइलर बनाती हैं, तो आपको तीन-चरण वाला कंपाइलर मिलेगा। यदि आपका भुगतान-लॉजिक एक फ़्रंटएंड टीम, एक बैकएंड टीम, और एक डेटाबेस टीम में बँटा हो, तो भुगतान में हर बदलाव के लिए तीन-तरफ़ा समन्वय चाहिए होगा। छोटे संगठन के लिए यह संभाला जा सकता है। बड़े संगठन के लिए, ऑर्ग-चार्ट का आकार आपकी इंजीनियरिंग, आपकी आर्किटेक्चर, आपकी डिलीवरी की गति, और आपकी गुणवत्ता पर हावी होने वाली मुख्य बाधा बन जाता है। इसलिए टीम-संरचना का डिज़ाइन करना एक प्रथम-श्रेणी इंजीनियरिंग गतिविधि है, न कि किसी एचआर का बाद का सोचा हुआ काम।

टीम टोपोलॉजी आपको इस डिज़ाइन के लिए एक सुविचारित शब्दावली देती है। पुनर्गठनों और हेडकाउंट के ज़रिए संरचना को संयोग से बनने देने के बजाय, परिपक्व संगठन जानबूझकर टीम-प्रकार और अंतःक्रिया-तरीके चुनते हैं, और जैसे-जैसे प्रणाली और व्यवसाय विकसित होते हैं, वे इन चुनावों की समीक्षा करते रहते हैं। लक्ष्य है हर टीम का संज्ञानात्मक भार कम रखना, यानी वह कुल मात्रा जो किसी टीम को प्रभावी बने रहने के लिए अपने दिमाग़ में रखनी पड़ती है, ताकि टीमें अपने डोमेन को छोर से छोर तक अपने अधिकार में रख सकें और लगातार दूसरों की प्रतीक्षा किए बिना मूल्य का स्थिर प्रवाह दे सकें।

उद्यमों (एंटरप्राइज़) और सरकार के लिए यह अनुशासन निर्णायक है। बड़े संगठन स्वाभाविक रूप से गहरे पदानुक्रमों, लंबी कतारों वाली साझा सेवाओं, और हैंड-ऑफ़ शृंखलाओं में फैल जाते हैं, जो दो दिन के बदलाव को दो महीने की परियोजना में बदल देती हैं। सरकार इसमें ख़रीद-सीमाएँ, ठेकेदार टीमें, और अनिवार्य कर्तव्यों का पृथक्करण जोड़ देती है, जो स्वामित्व को और खंडित करता है। स्पष्ट टोपोलॉजी डिज़ाइन ही वह तरीक़ा है जिससे ये संगठन प्रवाह वापस पाते हैं: टीमों को मूल्य की धाराओं के साथ संरेखित करें, ऐसे प्लेटफ़ॉर्म बनाएँ जो संज्ञानात्मक भार घटाएँ, और ऐसे अंतःक्रिया-पैटर्न चुनें जो निर्भरताओं को छुपे और स्थायी होने के बजाय दृश्य और जान-बूझकर बनाए रखें।

मुख्य सिद्धांत

• कॉनवे का नियम अपरिहार्य है; टीमों को उस सॉफ़्टवेयर इंजीनियरिंग के अनुरूप डिज़ाइन करें जो आप चाहते हैं (“उलटा पैंतरा”)।
• व्यक्तियों के अधिकतम उपयोग के बजाय टीम के संज्ञानात्मक भार के लिए अनुकूलन करें।
• ऐसी स्ट्रीम-संरेखित टीमों को प्राथमिकता दें जो मूल्य के किसी हिस्से को छोर से छोर तक अपने अधिकार में रखती हों।
• प्लेटफ़ॉर्म का उद्देश्य स्ट्रीम-संरेखित टीमों का संज्ञानात्मक भार घटाना है, न कि द्वारपाल बनना।
• टीम की अंतःक्रियाओं को स्पष्ट और सीमित रखें: सहयोग, X-को-सेवा-के-रूप में, या सुगमीकरण।
• निर्भरताएँ न्यूनतम रखें; हर क्रॉस-टीम हैंड-ऑफ़ एक कतार और एक जोख़िम है।
• टीम-संरचना एक जीवंत डिज़ाइन है जिसे प्रणाली और व्यवसाय बदलने के साथ विकसित होना चाहिए।

सिफ़ारिशें

चार मूलभूत टीम-प्रकार अपनाएँ

टीम टोपोलॉजी चार टीम-प्रकार परिभाषित करती है जो अधिकांश ज़रूरतों को पूरा करते हैं। स्ट्रीम-संरेखित टीमें डिफ़ॉल्ट हैं: हर एक किसी विशिष्ट उत्पाद, सेवा, या उपयोगकर्ता-यात्रा के लिए काम के निरंतर प्रवाह को छोर से छोर तक अपने अधिकार में रखती है। प्लेटफ़ॉर्म टीमें आंतरिक उत्पाद (कंप्यूट, डिप्लॉयमेंट, डेटा पाइपलाइन, पहचान) उपलब्ध कराती हैं जिन्हें स्ट्रीम-संरेखित टीमें स्व-सेवा के तौर पर उपभोग करती हैं, जिससे उनका संज्ञानात्मक भार घटता है। सक्षमकारी (एनेबलिंग) टीमें विशेषज्ञ होती हैं (परीक्षण, सुरक्षा, ऑब्ज़र्वेबिलिटी) जो स्ट्रीम-संरेखित टीमों को कोई क्षमता बनाने के लिए प्रशिक्षित करती हैं, फिर पीछे हट जाती हैं। जटिल-उपप्रणाली (कॉम्प्लिकेटेड-सबसिस्टम) टीमें उन घटकों की मालिक होती हैं जिन्हें गहन विशेषज्ञ ज्ञान चाहिए (एक मूल्य-निर्धारण इंजन, एक वीडियो कोडेक, एक क्रिप्टोग्राफ़िक मॉड्यूल), जहाँ हर टीम का वह ज्ञान रखना व्यावहारिक नहीं है। आपकी अधिकांश टीमें स्ट्रीम-संरेखित होनी चाहिए; बाक़ी तीन प्रकार उन्हें सहारा देने के लिए हैं।

उलटा कॉनवे पैंतरा अपनाएँ

चूँकि सॉफ़्टवेयर आपके संगठन की संरचना की छवि बनाता है, इसलिए अपनी टीमों को उस आकार में ढालें जो आप चाहते सॉफ़्टवेयर बना सके। ढीले-ढाले जुड़े हुए (लूज़ली कपल्ड) सेवाएँ चाहिए, स्पष्ट सीमाओं के साथ? स्पष्ट स्वामित्व-सीमाओं वाली ढीली-ढाली जुड़ी टीमें बनाएँ। एक भुगतान-क्षमता चाहिए जो अपनी ख़ुद की समय-सारणी पर लॉन्च हो? ऐसी भुगतान टीम बनाएँ जो उसे आगे से पीछे तक अपने अधिकार में रखे। कॉनवे के नियम से वीरतापूर्ण समन्वय के ज़रिए मत लड़िए। टीम-सीमाओं को फिर से खींचिए ताकि जो आर्किटेक्चर आप चाहते हैं वह सबसे कम प्रतिरोध का रास्ता बन जाए।

संज्ञानात्मक भार को स्पष्ट रूप से प्रबंधित करें

कोई भी टीम एक सीमा तक ही महारत हासिल कर सकती है। संज्ञानात्मक भार में डोमेन की जटिलता, तकनीकें, परिचालन-बोझ, और हितधारकों की व्यापकता शामिल है। जब कोई टीम बहुत सारी असंबंधित सेवाओं की मालिक बन जाती है, तो गुणवत्ता और गति दोनों ढह जाती हैं। इसलिए हर टीम की ज़िम्मेदारियों को उस डोमेन तक सीमित रखें जिस पर वह वाक़ई महारत हासिल कर सके, और अविभेदित जटिलता को उसकी थाली से हटाने के लिए प्लेटफ़ॉर्म और सक्षमकारी टीमों का इस्तेमाल करें। टीमों को लगभग पाँच से नौ लोगों तक सीमित रखें: इतनी छोटी कि आसानी से संवाद कर सकें और, कहा जाए तो, दो पिज़्ज़ा से खिलाई जा सकें।

जान-बूझकर अंतःक्रिया-तरीके चुनें

टीम की अंतःक्रियाओं को तीन तरीकों तक सीमित रखें। सहयोग (कोलैबोरेशन) किसी तय अवधि के लिए दो टीमों के बीच नज़दीकी, उच्च-बैंडविड्थ काम है; यह खोज के लिए शक्तिशाली है, पर महँगा है, इसलिए इसे अस्थायी रखें। X-को-सेवा-के-रूप में एक स्वच्छ प्रदाता/उपभोक्ता संबंध है जिसका इंटरफ़ेस स्पष्ट रूप से परिभाषित होता है, जो बड़े पैमाने पर प्लेटफ़ॉर्म-उपभोग के लिए आदर्श है। सुगमीकरण (फ़ैसिलिटेटिंग) तब होता है जब एक टीम दूसरी को सीखने में मदद करती है, जो सक्षमकारी टीमें करती हैं। हर महत्वपूर्ण क्रॉस-टीम संबंध के लिए उसके तरीक़े का नाम रखें, और एक ही दो टीमों के बीच लंबे समय तक चलने वाले सहयोग को इस संकेत के रूप में पढ़ें कि उनकी सीमा ग़लत जगह पर है।

क्रॉस-कटिंग कार्यों के लिए एक परिचालन-मॉडल चुनें

सुरक्षा, डेटा, डिज़ाइन, और ऐसे ही अन्य अनुशासनों को तीन तरीक़ों से संगठित किया जा सकता है: केंद्रीकृत (एक टीम सबके लिए इसकी मालिक होती है), संघीकृत (विशेषज्ञ अंशकालिक रूप से जड़े होते हैं, एक गिल्ड के ज़रिए समन्वय करते हुए), या अंतर्निहित (हर स्ट्रीम-संरेखित टीम के भीतर एक समर्पित विशेषज्ञ)। केंद्रीकृत मॉडल आपको स्थिरता और गहराई देता है, पर यह एक बाधा (बॉटलनेक) बन जाता है। अंतर्निहित मॉडल आपको गति और संदर्भ देता है, पर इसमें असंगति और दोहराव का जोख़िम है। संघीकृत (अक्सर हब-एंड-स्पोक या अभ्यास-समुदाय मॉडल) दोनों के बीच बैठता है। हर कार्य और हर पैमाने के अनुसार चुनें। अधिकांश बड़े संगठन इन अनुशासनों के लिए संघीकृत मॉडल पर पहुँचते हैं, साथ में एक छोटा केंद्रीय कोर जो मानक तय करता है।

इनर-सोर्स में निवेश करें

इनर-सोर्स संगठन के भीतर ओपन-सोर्स जैसे सहयोग-पैटर्न लाता है: साझा आंतरिक रिपॉज़िटरी, प्रकाशित योगदान-दिशानिर्देश, टीम-सीमाओं के आर-पार कोड समीक्षा, और स्पष्ट मेंटेनर। जब किसी टीम को किसी दूसरी टीम के घटक में बदलाव चाहिए हो, तो वह टिकट दाख़िल करके कतार में इंतज़ार करने के बजाय सीधे वह बदलाव योगदान कर सकती है। इससे स्वामित्व को भंग किए बिना क्रॉस-टीम निर्भरताएँ कम होती हैं, और यह बड़ी इंजीनियरिंग आबादी में स्वाभाविक रूप से ज्ञान और मानक फैलाता है।

ट्रेड-ऑफ़: फ़ायदे और नुक़सान

क्रॉस-कटिंग कार्यों के लिए मॉडल	फ़ायदे	नुक़सान
केंद्रीकृत (सबके लिए एक टीम)	स्थिरता, गहरी विशेषज्ञता, स्पष्ट मानक	बाधा, कतारें, उत्पाद-संदर्भ की हानि
संघीकृत (हब-एंड-स्पोक, गिल्ड)	स्थिरता और गति में संतुलन; ज्ञान साझा करता है	समन्वय-अनुशासन चाहिए; जवाबदेही धुँधली हो सकती है
अंतर्निहित (हर टीम में विशेषज्ञ)	तेज़, संदर्भ-समृद्ध, उच्च स्वामित्व	दोहराव, असंगति, बड़े पैमाने पर स्टाफ़ करना कठिन

टीम-प्रकार	किसके लिए सर्वश्रेष्ठ	अति-उपयोग होने पर जोख़िम
स्ट्रीम-संरेखित	अधिकांश उत्पाद और सेवा डिलीवरी	कोई नहीं; इसका प्रभुत्व होना चाहिए
प्लेटफ़ॉर्म	साझा संज्ञानात्मक भार घटाना	हाथी-दाँत के मीनार जैसा द्वारपाल बन जाता है
सक्षमकारी	किसी क्षमता को अस्थायी रूप से फैलाना	स्थायी निर्भरता में बदल जाता है
जटिल-उपप्रणाली	वाक़ई गहरे विशेषज्ञ डोमेन	सामान्य काम को जमा करने के बहाने के रूप में उपयोग

बार-बार आने वाला ट्रेड-ऑफ़ है स्वायत्तता बनाम संगति। पूरी तरह स्वायत्त टीमें तेज़ चलती हैं, पर मानकों, टूलिंग, और सुरक्षा-मुद्रा में एक-दूसरे से दूर होती जाती हैं। पूरी तरह केंद्रीकृत नियंत्रण चीज़ों को संगत रखता है, पर प्रवाह को घोंट देता है। अच्छा टोपोलॉजी डिज़ाइन वह सिलाई खोजता है: डिलीवरी के लिए स्ट्रीम-संरेखित स्वायत्तता, साथ ही उन चीज़ों के लिए पतले केंद्रीय मानक और पक्की-सड़क प्लेटफ़ॉर्म (अच्छी तरह समर्थित डिफ़ॉल्ट टूलिंग जो अनुपालक चुनाव को आसान बनाती है) जो वाक़ई संगत होनी ही चाहिए।

अपनी टीम के साथ चर्चा के लिए प्रश्न

1. गुणवत्ता ढहने से पहले कौन-से ठोस संकेत आपको बताएँगे कि किसी टीम का संज्ञानात्मक भार बहुत ज़्यादा है? “हर टीम को उस डोमेन तक सीमित रखें जिस पर वह महारत हासिल कर सके” कहना आसान है और बिना प्रमाण के उस पर अमल करना कठिन, क्योंकि संज्ञानात्मक भार तब तक अदृश्य रहता है जब तक डिलीवरी और विश्वसनीयता बिगड़ना शुरू न हो जाए। मापने-योग्य लक्षणों पर नज़र रखें: किसी टीम की मालिकी वाली असंबंधित सेवाओं या रिपॉज़िटरी की संख्या, ऑनबोर्डिंग में कितना समय लगता है, एक इंजीनियर को हफ़्ते भर में कितने डोमेन के बीच संदर्भ-स्विच करना पड़ता है, और टीम के दायरे के कोनों में बढ़ती घटना-दर। बड़े संगठन के लिए यह मायने रखता है क्योंकि अतिभारित टीमें चुपचाप बाधाएँ बन जाती हैं जिनकी भविष्यवाणी कोई पुनर्गठन-आरेख नहीं करता। इन संख्याओं को चर्चा में लाएँ, साथ ही टीम की अपनी समझ कि वे अपने दिमाग़ में क्या रख सकते हैं और क्या नहीं। यदि संकेत अतिभार दिखाते हैं, तो क़दम है अविभेदित काम को किसी प्लेटफ़ॉर्म या सक्षमकारी टीम पर डालना, न कि और वीरता माँगना।

2. क्या यहाँ पुनर्गठन वाक़ई व्यवधान के लायक़ है, या आप पुनर्गठन की लत पाल रहे हैं? उलटा कॉनवे पैंतरा लागू करने के लिए सीमाएँ फिर से खींचना शक्तिशाली है, और हर पुनर्गठन उस स्थिरता को भी नष्ट करता है जो टीमों को जमने के लिए चाहिए और कड़ी मेहनत से अर्जित डोमेन-ज्ञान को रीसेट कर देता है। प्रतिस्पर्धी विचार हैं वर्तमान संरचना का चालू समन्वय-कर बनाम उसे बदलने की एक-बारगी लागत और मनोबल पर आघात। उद्यम और सरकारी परिवेश में, ख़रीद-सीमाएँ, ठेकेदार टीमें, और अनिवार्य कर्तव्य-पृथक्करण पुनर्गठनों को धीमा और महँगा बनाते हैं, इसलिए बार ऊँचा रखा जाना चाहिए। निर्भरता-प्रेरित देरी के प्रमाण लाएँ: कितनी पहलें किसी दूसरी टीम की प्रतीक्षा में अटकी हैं, और कितने समय से। पुनर्गठन करें जब वह प्रतीक्षा संरचनात्मक और बड़ी हो, और अस्थायी पीड़ा या इनर-सोर्स योगदान और स्पष्ट इंटरफ़ेस से सस्ते में हल होने वाली पीड़ा पर फेरबदल का प्रतिरोध करें।

3. सुरक्षा, डेटा, और डिज़ाइन के लिए, कौन-सी घटना आपको अंतर्निहित, संघीकृत, और केंद्रीकृत के बीच बदलने के लिए प्रेरित करेगी? इस अध्याय की सिफ़ारिश है कि हर कार्य और हर पैमाने के अनुसार चुनें, और कठिन अनुशासन है पहले से तय करना कि कौन-सी वृद्धि या जोख़िम आपको वह चुनाव दोबारा देखने पर मजबूर करेगा। जो मॉडल पचास इंजीनियरों के लिए फ़िट बैठता है वह पाँच सौ पर बाधा या संगति की आपदा बन सकता है, और ख़ासकर उद्यमों और सरकारी निकायों को यह नाम देना होगा कि छोटा केंद्रीय कोर हमेशा किन मानकों को थामे रखेगा। हर कार्य के लिए वर्तमान कतार-समय और संगति-अंतराल लाएँ: बहु-सप्ताह समीक्षा-कतार वाली केंद्रीय सुरक्षा टीम संघीकरण का संकेत है, जबकि असंगत डेटा-मॉडल बनाते अंतर्निहित विशेषज्ञ केंद्रीय मानक-कोर जोड़ने का संकेत हैं। अभी वह ट्रिगर तय करें, जैसे कोई कतार-लंबाई सीमा या कोई ऑडिट-निष्कर्ष, ताकि यह बदलाव संकट-प्रतिक्रिया के बजाय एक नियोजित विकास बने। इसका उत्तर तय करता है कि आप पक्की-सड़कों और चैंपियनों बनाम केंद्रीय हब में कहाँ निवेश करते हैं।

4. आपको कैसे पता चलेगा कि आपकी प्लेटफ़ॉर्म टीम वाक़ई संज्ञानात्मक भार घटा रही है या चुपचाप द्वारपाल बन रही है? प्लेटफ़ॉर्म का अस्तित्व स्व-सेवा के ज़रिए अनुपालक, भरोसेमंद चुनाव को आसान बनाने के लिए है, और वही टीम टूल थोपने, हर अनुरोध की हाथ से समीक्षा करने, और उसी घर्षण को जोड़ने की तरफ़ बह सकती है जिसे हटाना उसका मक़सद था। बड़े संगठन के लिए यह अंतर तय करता है कि प्लेटफ़ॉर्म निवेश फल देता है या हर स्ट्रीम-संरेखित टीम की कतार वाली केंद्रीय बाधा बन जाता है। प्रतिस्पर्धी विचार हैं एक तरफ़ संगति और नियंत्रण, दूसरी तरफ़ उपभोक्ता-स्वायत्तता और प्रवाह। ऐसे प्रमाण लाएँ जिन्हें कोई उपभोक्ता पहचान सके: किसी स्ट्रीम-संरेखित टीम को टिकट दाख़िल किए बिना नया वातावरण या पाइपलाइन स्व-सेवा से पाने में कितना समय लगता है, स्व-सेवा क्रियाओं और मानव-मध्यस्थ क्रियाओं का अनुपात, और यह मापी गई प्लेटफ़ॉर्म-अपनाई कि कितनी टीमें इसे चुनती हैं बनाम कितनी पर यह थोपी गई। उद्यम और सरकारी परिवेश में, इस बात पर ज़ोर दें कि प्लेटफ़ॉर्म ऑडिट और अनुपालन-प्रमाण मैनुअल गेट्स के बजाय स्वचालित रूप से उत्पन्न करे, क्योंकि जो प्लेटफ़ॉर्म कर्तव्य-पृथक्करण नियमों को मानव समीक्षक डालकर पूरा करता है, उसने वही बाधा फिर बना दी है जिसे मिटाने के लिए उसे वित्त पोषित किया गया था।

5. आपके किन क्रॉस-टीम संबंधों ने स्थायी सहयोग का रूप ले लिया है, और हर एक को स्वच्छ सेवा-इंटरफ़ेस या फिर से खींची सीमा में क्या बदलेगा? सहयोग-तरीका तीव्र और अस्थायी होने के लिए है, और जो जोड़ी कभी ख़त्म नहीं होती वह आम तौर पर इस बात का संकेत है कि स्वामित्व ग़लत जगह बैठा है या दो टीमों के बीच इंटरफ़ेस कभी स्पष्ट नहीं किया गया। यह बड़े पैमाने पर इसलिए मायने रखता है क्योंकि बिना नाम वाला, स्थायी सहयोग वह जगह है जहाँ समन्वय-लागत छिपती है: यह किसी ऑर्ग-चार्ट पर नहीं दिखती, फिर भी यह उन दोनों टीमों के हर बदलाव पर कर लगाती है। प्रतिस्पर्धी विचार हैं नज़दीक बने रहने का खोज-मूल्य बनाम उस संबंध को परिभाषित इंटरफ़ेस वाले X-को-सेवा-अनुबंध में बदलने, या ज़िम्मेदारी को एक ही टीम में मिलाने से मिलने वाला प्रवाह। एक तिमाही से ज़्यादा लगातार सहयोग करती टीम-जोड़ियों की सूची, बीते कुछ महीनों में दोनों टीमों को चाहिए वाले बदलाव, और क्या उनके बीच स्थिर इंटरफ़ेस लिखा जा सकता है, यह लाएँ। उद्यम और सरकारी संदर्भों के लिए, जहाँ ठेकेदार-सीमाएँ और ख़रीद-लॉट किसी हैंड-ऑफ़ को वर्षों तक जमा सकते हैं, नाम दें कि किन संबंधों को आप इंटरफ़ेस और इनर-सोर्स योगदान से बदल सकते हैं और कौन-से अनुबंधानुसार तय हैं और स्पष्ट निर्भरता के रूप में प्रबंधित होने चाहिए।

6. जब कोई सक्षमकारी टीम किसी दूसरी टीम को क्षमता बनाने में मदद करती है, तो आपको कैसे पता चलेगा कि वह सफल हुई और पीछे हट सकती है, न कि स्थायी निर्भरता बन जाए? सक्षमकारी टीमों का मक़सद किसी स्ट्रीम-संरेखित टीम को परीक्षण, सुरक्षा, या ऑब्ज़र्वेबिलिटी में प्रशिक्षित करना और फिर आगे बढ़ जाना है, और स्पष्ट निकास-शर्त के बिना यह प्रशिक्षण-संबंध एक स्थायी सेवा में जम जाता है जिसे स्ट्रीम-संरेखित टीम कभी वाक़ई आत्मसात नहीं करती। बड़े संगठन के लिए यही अंतर है किसी क्षमता को दर्जनों टीमों में फैलाने और एक नई साझा बाधा बनाने के बीच जो हर साल बदतर पैमाने पर बढ़ती है। प्रतिस्पर्धी विचार हैं एक विशेषज्ञ टीम की गहराई और संगति बनाम वह स्वायत्तता और छोर-से-छोर स्वामित्व जो आप स्ट्रीम-संरेखित टीमों में बनाना चाहते हैं। क्षमता-हस्तांतरण के प्रमाण लाएँ: क्या प्राप्त करने वाली टीम अब सक्षमकारी टीम की मौजूदगी के बिना काम संभालती है, एक स्थिर सक्षमकारी समूह एक साथ कितनी टीमों के लिए प्रतिबद्ध है, और हर जुड़ाव अपनी इच्छित हैंडओवर-तिथि से कितना आगे निकल चुका है। उद्यम और सरकारी परिवेश में, जहाँ कोई दुर्लभ विशेषज्ञ कौशल एक ही केंद्रीय टीम या एक ही अनुबंध के पीछे बैठा हो सकता है, पहले से तय करें कि आप क्षमता-हस्तांतरण और चैंपियनों को कैसे वित्त पोषित करेंगे ताकि विशेषज्ञता डिलीवरी टीमों में फैले, न कि किसी कतार के पीछे बंद रहे जिसकी हर ऑडिट और रिलीज़ प्रतीक्षा करे।

क्षेत्र-लेंस

स्टार्टअप। मुट्ठी भर इंजीनियरों और थोड़े से रनवे के साथ, सही टोपोलॉजी एक अकेली स्ट्रीम-संरेखित टीम है जो पूरे उत्पाद की मालिक हो, और अनुशासन है ज़रूरत से पहले साइलो बनाने से इनकार करना। अकेले “डेवऑप्स” या “क्यूए” व्यक्ति को भर्ती करने का प्रतिरोध करें जो द्वार बन जाए; उन कौशलों को एक ही टीम में अंतर्निहित क्षमता के रूप में समेट लें। ऑर्ग को सपाट रखकर कॉनवे के नियम को अपने पक्ष में काम करते रहने दें, ताकि आर्किटेक्चर टीम जितना ही सरल और परिवर्तनशील बना रहे।

छोटा व्यवसाय। आप समर्पित प्लेटफ़ॉर्म या सक्षमकारी टीम को स्टाफ़ नहीं करेंगे, इसलिए प्लेटफ़ॉर्म ख़रीदें: प्रबंधित क्लाउड सेवाओं, होस्टेड पाइपलाइनों, और तैयार सुरक्षा-टूलिंग का उपयोग करके अपनी एक या दो टीमों से अविभेदित संज्ञानात्मक भार हटाएँ। सुरक्षा और डेटा जैसी क्रॉस-कटिंग चिंताओं को उस चीज़ के रूप में देखें जिसे आप कॉन्फ़िगर और उपभोग करते हैं, न कि किसी ऐसे कार्य के रूप में जिसे आप बनाते हैं। किसी भी कस्टम स्वामित्व को उस एक जटिल उपप्रणाली के लिए आरक्षित रखें जो वाक़ई आपको अलग बनाती है, और बाक़ी विक्रेताओं पर छोड़ दें।

उद्यम। बड़े पैमाने पर समस्या कई टीमों के बीच समन्वय-लागत है, इसलिए टोपोलॉजी को स्पष्ट, शासित डिज़ाइन बनाएँ: चार टीम-प्रकारों की साझा वर्गीकरण-प्रणाली, नामित अंतःक्रिया-तरीके, पक्की-सड़क प्लेटफ़ॉर्म, और क्रॉस-टीम कतारों को राहत देने के लिए इनर-सोर्स। निर्भरता-प्रेरित देरी और टीम के संज्ञानात्मक भार को पोर्टफ़ोलियो-मेट्रिक्स के रूप में ट्रैक करें, और पुनर्गठनों को वार्षिक प्रतिवर्त के बजाय ऊँचे बार वाले सुविचारित विकास के रूप में चलाएँ। एक पतला केंद्रीय कोर उन मानकों को थामे रहे जो संगत होने ही चाहिए, जबकि स्ट्रीम-संरेखित टीमें डिलीवरी पर स्वायत्तता बनाए रखें।

सरकार। ख़रीद-नियम, ठेकेदार-सीमाएँ, और अनिवार्य कर्तव्य-पृथक्करण स्वामित्व को खंडित करते हैं, इसलिए टोपोलॉजी को मानवीय हैंड-ऑफ़ के बजाय टूलिंग और स्पष्ट इंटरफ़ेस के ज़रिए इन बाधाओं को पूरा करने के लिए डिज़ाइन करें। एक छोटे मानक-कोर और ऐसे प्लेटफ़ॉर्म वाले संघीकृत मॉडलों को प्राथमिकता दें जो ऑडिट और अनुपालन-प्रमाण स्वचालित रूप से उत्पन्न करे, ताकि कर्तव्य-पृथक्करण समीक्षा-कतारों के बजाय पाइपलाइनों से लागू हो। टीम-सीमाओं, अंतःक्रिया-तरीकों, और परिचालन-मॉडल को खुले तौर पर दस्तावेज़ित करें, ताकि संरचना ऑडिटरों, निगरानी-निकायों, और इसे वित्त पोषित करने वाली जनता के लिए पारदर्शी हो।

उदाहरण

स्टार्टअप। एक दस-सदस्यीय स्टार्टअप में एक अकेली स्ट्रीम-संरेखित टीम है जो पूरे उत्पाद की मालिक छोर से छोर तक है, जो उसके पैमाने पर बिल्कुल सही है: कोई हैंड-ऑफ़ नहीं, कोई समन्वय-कर नहीं, सब एक ही संदर्भ साझा करते हैं। मुसीबत तब शुरू होती है जब वे एक समर्पित “डेवऑप्स व्यक्ति” और एक अलग “क्यूए व्यक्ति” भर्ती करते हैं और अनजाने में कार्यात्मक साइलो फिर बना लेते हैं, इसलिए अब हर रिलीज़ दो व्यक्तियों की प्रतीक्षा करती है। वे उन नियुक्तियों को उस एक टीम के भीतर अंतर्निहित प्लेटफ़ॉर्म-और-परीक्षण क्षमता के रूप में मानकर सुधार करते हैं, न कि उन द्वारों के रूप में जिनसे काम को गुज़रना पड़े। इस आकार पर, सबसे सस्ती टोपोलॉजी वही है जो सबको एक ही प्रवाह में रखे।

उद्यम। एक बड़े रिटेलर का चेकआउट बदलने में धीमा था क्योंकि फ़्रंटएंड, बैकएंड, और पूर्ति-लॉजिक तीन कार्यात्मक रूप से संगठित टीमों में बँटे थे, जिससे हर बदलाव को तीन बैकलॉग से गुज़रना पड़ता था। उलटा कॉनवे पैंतरा लागू करके, उन्होंने ग्राहक-यात्राओं (“ब्राउज़”, “कार्ट और चेकआउट”, “ख़रीद-के-बाद”) के इर्द-गिर्द स्ट्रीम-संरेखित टीमों में पुनर्गठन किया, हर एक अपने हिस्से को आगे से पीछे तक अपने अधिकार में रखती है, और उसे एक प्लेटफ़ॉर्म टीम का समर्थन मिलता है जो डिप्लॉयमेंट और ऑब्ज़र्वेबिलिटी को सेवा के रूप में देती है। चेकआउट के बदलाव जो पहले एक तिमाही लेते थे, अब दिनों में शिप होने लगे, क्योंकि वह समन्वय जो पहले टीमों के आर-पार फैला था अब एक टीम के भीतर होने लगा।

सरकार। एक सरकारी कर एजेंसी में एक केंद्रीय सुरक्षा टीम हर रिलीज़ की समीक्षा करती थी, जिससे बहु-सप्ताह वाली कतार बनती थी जो नाज़ुक फ़िक्स को टाल देती थी। वे संघीकृत मॉडल में बदल गए: एक छोटा केंद्रीय सुरक्षा-कार्य मानक तय करता और पूर्व-स्वीकृत, स्वतः-स्कैन होने वाली पाइपलाइनों की “पक्की सड़क” देता, जबकि हर डिलीवरी टीम में अंशकालिक रूप से जड़े सुरक्षा-चैंपियन रोज़मर्रा के फ़ैसले संभालते। प्लेटफ़ॉर्म अनुपालन-प्रमाण स्वचालित रूप से उत्पन्न करता। अनिवार्य कर्तव्य-पृथक्करण की आवश्यकताएँ फिर भी पूरी होतीं, पर मानव-बाधा के बजाय टूलिंग और स्पष्ट इंटरफ़ेस से, जिससे रिलीज़ लीड-टाइम में भारी कटौती हुई और साथ ही ऑडिट-तैयारी बेहतर हुई।

व्यवसाय-मामला: प्रेरणाएँ, आरओआई, और टीसीओ

आप ख़राब टीम-डिज़ाइन की क़ीमत समन्वय-ओवरहेड में चुकाते हैं, और यह ओवरहेड सामान्य बदलाव के लिए समन्वयित होने वाली टीमों की संख्या से रैखिक रूप से भी तेज़ बढ़ता है। हर हैंड-ऑफ़ एक कतार है जिसमें प्रतीक्षा-समय है, एक संदर्भ-हस्तांतरण है जो जानकारी खो देता है, और ग़लतफ़हमी का एक ताज़ा मौक़ा है। जब किसी सामान्य बदलाव के लिए तीन टीमों को अपने रोडमैप संरेखित करने पड़ें, तो असली लागत उनके काम का योग नहीं है; यह शेड्यूलिंग, प्रतीक्षा, और फिर से काम की कहीं ज़्यादा बड़ी लागत है। सीमाओं को इस तरह फिर से खींचिए कि अधिकांश बदलाव एक ही टीम के स्वामित्व में समा जाएँ, और वह ओवरहेड बस ग़ायब हो जाता है।

अपनाने की लागत वास्तविक है। पुनर्गठन विघटनकारी होते हैं, और प्लेटफ़ॉर्म व अगर इनर-सोर्स प्रथाएँ बनाने में लाभ मिलने से पहले अग्रिम निवेश लगता है। पर न अपनाने की लागत चक्रवृद्धि होती है। जो संगठन संरचना को संयोग से जमा होने देते हैं वे हैंड-ऑफ़ शृंखलाएँ, तिमाही-भर की कतार वाली साझा-बाधा टीमें, और ऑर्ग-चार्ट में जड़ जमा चुकी आर्किटेक्चर ढेर कर लेते हैं। नेतृत्व के सामने मामला बनाने के लिए, निर्भरता-प्रेरित देरी मापें: कितनी सक्रिय पहलें किसी दूसरी टीम की प्रतीक्षा में अटकी हैं, और कितने समय से। प्लेटफ़ॉर्म और टोपोलॉजी निवेश आमतौर पर उस प्रतीक्षा को प्रवाह में बदलकर लाभ लौटाते हैं, जो हेडकाउंट जोड़े बिना छोटे लीड-टाइम और ऊँचे थ्रूपुट के रूप में दिखता है।

एंटी-पैटर्न और नुक़सान

• कॉनवे के नियम को अनदेखा करना: ऐसी आर्किटेक्चर डिज़ाइन करना जिसे ऑर्ग-संरचना डिलीवर नहीं कर सकती।
• कार्यात्मक साइलो: अलग-अलग फ़्रंटएंड, बैकएंड, क्यूए, और ऑप्स टीमें जिन्हें किसी भी बदलाव के लिए समन्वय करना पड़े।
• साझा-सेवा बाधा: एक केंद्रीय टीम जिसके पीछे हर परियोजना को कतार में लगना पड़े।
• द्वारपाल के रूप में प्लेटफ़ॉर्म: एक प्लेटफ़ॉर्म टीम जो सेवा करने के बजाय थोपती है, और हटाने की जगह घर्षण जोड़ती है।
• संज्ञानात्मक अतिभार: टीमें फैली हुई, असंबंधित प्रणालियों की मालिक हैं जिन पर वे महारत हासिल नहीं कर सकतीं।
• स्थायी “सहयोग”: दो टीमें हमेशा के लिए उलझी हुई, जो ग़लत जगह बैठी सीमा का संकेत है।
• पुनर्गठन की लत: लगातार फेरबदल, उस स्थिरता को नष्ट करना जो टीमों को जमने के लिए चाहिए।

परिपक्वता मॉडल

• स्तर 1, आरंभ। टीमें संयोग से, हेडकाउंट से, या विरासती पदानुक्रम से बनती हैं; कोई टीम-प्रकार या अंतःक्रिया-तरीके नहीं नामे जाते; कार्यात्मक साइलो और साझा-सेवा बाधाएँ हर जगह हैं और निर्भरताएँ तब तक छुपी रहती हैं जब तक वे किसी रिलीज़ को रोक न दें।
• स्तर 2, विकास। कुछ स्ट्रीम-संरेखित टीमें मौजूद हैं और पहला प्लेटफ़ॉर्म या इनर-सोर्स प्रयास दिखता है, पर पैटर्न असमान रूप से लागू है: कुछ टीमें अपने हिस्से को छोर से छोर तक अपने अधिकार में रखती हैं जबकि अन्य अब भी केंद्रीय कार्यों के पीछे कतार में हैं, और संज्ञानात्मक भार की चर्चा किस्सों में होती है, प्रबंधन में नहीं।
• स्तर 3, मानकीकरण। चार टीम-प्रकार और तीन अंतःक्रिया-तरीके पूरे संगठन में दस्तावेज़ित और जान-बूझकर उपयोग किए जाते हैं; प्लेटफ़ॉर्म और इनर-सोर्स क्रॉस-टीम निर्भरताएँ कम करते हैं; सुरक्षा, डेटा, और डिज़ाइन के लिए परिचालन-मॉडल चुना और लिखा जाता है, और नई टीमें तात्कालिक सुधार के बजाय इन मानकों के अनुरूप बनाई जाती हैं।
• स्तर 4, प्रबंधन। टोपोलॉजी को आधार-रेखाओं के मुक़ाबले मापा और नियंत्रित किया जाता है: टीमें संज्ञानात्मक भार, निर्भरता-प्रेरित देरी (कितनी पहलें किसी दूसरी टीम की प्रतीक्षा में अटकी हैं, और कितने समय से), प्लेटफ़ॉर्म स्व-सेवा अनुपात और अपनाई, अंतःक्रिया-तरीके की अवधि, और लीड-टाइम व परिवर्तन-आवृत्ति जैसे डिलीवरी-प्रवाह मेट्रिक्स ट्रैक करती हैं। सीमाएँ कार्रवाई को ट्रिगर करती हैं, उदाहरण के लिए कोई कतार-लंबाई जो किसी कार्य को संघीकृत होने पर मजबूर करे या कोई स्थायी सहयोग जो ग़लत जगह बैठी सीमा का झंडा उठाए, ताकि निर्णय राय के बजाय प्रमाण पर टिके हों।
• स्तर 5, संयोजन। टीम-डिज़ाइन को लगातार सुधारा जाता है और आर्किटेक्चर, उत्पाद, और जोख़िम-योजना के साथ एकीकृत किया जाता है; संगठन प्रणाली और व्यवसाय के विकसित होने के साथ सीमाएँ फिर से आकार देता है, क्षमता हस्तांतरित होने के बाद सक्षमकारी जुड़ावों को सेवानिवृत्त करता है, और संज्ञानात्मक भार बदलने के साथ प्लेटफ़ॉर्म-निवेश को फिर से संतुलित करता है, तेज़ प्रवाह को एक-बारगी पुनर्गठन के बजाय एक अनुकूली, स्थायी गुण के रूप में बनाए रखते हुए।

चर्चा के लिए विचार

• किसी सामान्य बदलाव के लिए कितनी टीमों को समन्वय करना पड़ता है, और क्यों?
• हमारी कौन-सी टीमें बहुत ज़्यादा संज्ञानात्मक भार उठा रही हैं, और कोई प्लेटफ़ॉर्म क्या हटा सकता है?
• हम कहाँ कॉनवे के नियम से लड़ रहे हैं, सीमाएँ फिर से खींचने के बजाय?
• क्या हमारी प्लेटफ़ॉर्म टीमें स्ट्रीम-संरेखित टीमों की सेवा कर रही हैं या उन्हें द्वारपालित कर रही हैं?
• अभी हमारे लिए सुरक्षा, डेटा, और डिज़ाइन को केंद्रीकृत, संघीकृत, या अंतर्निहित होना चाहिए?
• कौन-से “अस्थायी” सहयोग चुपचाप स्थायी निर्भरता बन गए हैं?

मुख्य निष्कर्ष

• ऑर्ग-संरचना आर्किटेक्चर और डिलीवरी की गति तय करती है; इसे जान-बूझकर डिज़ाइन करें।
• चार टीम-प्रकार उपयोग करें, स्ट्रीम-संरेखित को डिफ़ॉल्ट और बाक़ी को सहायक के रूप में।
• वांछित आर्किटेक्चर को आसान रास्ता बनाने के लिए उलटा कॉनवे पैंतरा अपनाएँ।
• संज्ञानात्मक भार प्रबंधित करें; हर टीम को उस डोमेन तक सीमित रखें जिस पर वह महारत हासिल कर सके।
• क्रॉस-टीम अंतःक्रिया-तरीकों को सीमित और नामित रखें; लंबे समय तक टिकी निर्भरताओं को सीमा-दोष मानें।
• क्रॉस-कटिंग कार्यों के लिए पैमाने के अनुसार केंद्रीकृत, संघीकृत, या अंतर्निहित मॉडल चुनें, और कतारों से राहत के लिए इनर-सोर्स का उपयोग करें।

संदर्भ और आगे पढ़ने के लिए

• मैथ्यू स्केल्टन और मैनुएल पाइस, “टीम टोपोलॉजीज़: ऑर्गनाइज़िंग बिज़नेस एंड टेक्नोलॉजी टीम्स फ़ॉर फ़ास्ट फ़्लो”
• मेल्विन कॉनवे, “हाउ डू कमिटीज़ इन्वेंट?” (कॉनवे के नियम की उत्पत्ति)
• निकोल फ़ोर्सग्रेन, जेज़ हम्बल, जीन किम, “एक्सेलेरेट”
• विल लार्सन, “एन एलिगेंट पज़ल: सिस्टम्स ऑफ़ इंजीनियरिंग मैनेजमेंट”
• सैम न्यूमैन, “बिल्डिंग माइक्रोसर्विसेज़” (सेवाओं को टीमों के साथ संरेखित करने पर)
• डेनीज़ कूपर और क्लास-यान स्टॉल, “एडॉप्टिंग इनरसोर्स,” और इनरसोर्स कॉमन्स पैटर्न
• फ़्रेडरिक ब्रूक्स, “द मिथिकल मैन-मंथ” (संचार-ओवरहेड)