सबसे दिलचस्प संगठनात्मक अभ्यास है जिसके बारे में मैंने कुछ समय में सीखा है। आज मैं साझा करता हूं कि फास्ट एजाइल क्या है, और पता लगाता हूं कि क्या यह प्रयोग करने लायक है। टीएल;डीआर? काफी सम्मोहक, लेकिन फिर भी प्रयोगात्मक। फास्ट एजाइल फास्ट एजाइल क्या है? एक एजाइल सॉफ्टवेयर संस्करण है। FAST बहुत बड़ी टीमों के भीतर स्व-संगठन पर ध्यान केंद्रित करता है। इन बड़ी टीमों को कलेक्टिव कहा जाता है। वे कुछ लोग से लेकर 150 लोग तक हो सकते हैं [1]। फास्ट एजाइल सप्ताह में दो बार सामूहिक बैठक होती है। बैठक में हु: । टीम के सदस्य दिखाते हैं और बताते हैं कि उन्होंने क्या प्रगति की है । वे शीर्ष परियोजनाओं पर संदर्भ देते हैं। जैसे-जैसे काम पूरा होता है, या प्राथमिकताएँ बदलती हैं, वे नई प्राथमिकताएँ पेश करते हैं। और आम तौर पर वे प्राथमिकताओं को दृश्य तरीके से, दीवार पर या आभासी समकक्ष पर दिखाते हैं। उत्पाद नेता दृष्टिकोण को दोहराता है और दिशा निर्धारित करता है और स्वयं-चयन करते हैं। सामूहिक के भीतर के लोग सर्वोच्च प्राथमिकता वाले कार्य को पूरा करने के लिए छोटी टीमों में स्वयं-संगठित फास्ट एजाइल का सबसे दिलचस्प हिस्सा ये स्व-संगठित टीमें हैं, तो आइए इनका थोड़ा और विस्तार से वर्णन करें। प्रत्येक बैठक में, लोग स्वेच्छा से टीमों का नेतृत्व करते हैं, और लोग स्वेच्छा से उन टीमों में भाग लेते हैं। जब कोई स्वेच्छा से किसी टीम का नेतृत्व करता है, तो वे आगे बढ़ते हैं और कहते हैं, "मैं [शीर्ष परियोजनाओं में से एक] पर काम करने जा रहा हूं"। फिर लोग बनाई गई टीमों में शामिल हो जाते हैं और उस क्षेत्र में काम करते हैं। न्यूनतम टीम का आकार दो है, इसलिए टीम बनाने के लिए आपको लोगों को "अपने पैरों से वोट देने" की आवश्यकता है। गठित टीमें करती हैं उत्पाद द्वारा निर्धारित प्राथमिकताओं के आसपास रहना होगा। उदाहरण के लिए, तैनाती पाइपलाइन में सुधार, या कुछ कमजोर सेवाओं के लिए निगरानी में सुधार के लिए एक टीम बनाई जा सकती है। नहीं बैठकों में सप्ताह में एक घंटे के अलावा, लोग अपना अधिकांश समय अपनी स्व-चयनित, स्व-संगठित टीमों में बिताते हैं। सैद्धांतिक रूप से, आप सप्ताह में दो बार टीम बदल सकते हैं। लेकिन व्यवहार में, लोगों को यह पता चल जाता है कि उन्हें किसके साथ काम करना पसंद है, और टीमें पहले महीने या उसके बाद व्यवस्थित हो जाती हैं। वे इतने तरल रहते हैं कि लोग व्यवसाय की ज़रूरतों में बदलाव के अनुसार स्थानांतरित हो सकते हैं, या विभिन्न क्षेत्रों में विशेषज्ञता वाले लोगों की आवश्यकता होती है। टीमों को स्थानांतरित करना एक अपेक्षित, कम प्रयास वाला बदलाव है। तो इसका मतलब यह है कि सामूहिक बैठकों के दौरान, लोगों द्वारा अपनी टीमों को फिर से बनाने का एक पैटर्न होता है, लेकिन संरचना उतनी नहीं बदलती जितनी आप कल्पना कर सकते हैं। कई अन्य विवरण हैं जैसे कि बग और ऑन-कॉल को कैसे प्रबंधित किया जाता है। मैं इनमें से कुछ विषयों को बाद में कवर करूंगा। लेकिन फास्ट एजाइल का मूल आधार ये स्वयं-चयन करने वाली टीमें हैं, जो परियोजनाओं पर एक बड़े सामूहिक के भीतर काम कर रही हैं। सामूहिक बैठकें संरचित होती हैं और व्यवसाय की आवश्यकताओं पर संदर्भ देने और उन प्राथमिकताओं के विरुद्ध प्रगति का संचार करने पर केंद्रित होती हैं। मतभेदों का सारांश FAST आज अधिकांश चुस्त सॉफ्टवेयर संगठनों के चलने के तरीके से बहुत अलग है। जैसा कि मैं उन्हें देखता हूं ये अंतर हैं: (एससीआरयूएम, कानबन, या "लाइटवेट एजाइल") सामान्य अभ्यास तेज़ फुर्तीला बैठक घनत्व मध्यम से उच्च कंपनी-दर-कंपनी अलग-अलग होती है, लेकिन आम तौर पर दैनिक स्टैंडअप, डेमो, ग्रूमिंग, अनुमान, रेट्रो आदि)। कम सप्ताह में दो, आधे घंटे की बैठकें। अन्य इच्छानुसार। स्केल करने की क्षमता स्केलिंग की इकाई टीम है. टीमों को बढ़ाना और विभाजित करना और बनाना (और उनकी जिम्मेदारी के क्षेत्र) प्रबंधन का एक प्रमुख फोकस है। जैसे-जैसे व्यावसायिक प्राथमिकताएँ बदलती हैं, प्राथमिकताओं में परिवर्तन को प्रतिबिंबित करने के लिए पुनर्गठन की आवश्यकता होती है। स्केलिंग की इकाई सामूहिक है। व्यावहारिक रूप से, कार्य के ट्रैक की संख्या सामान्य अभ्यास के समान होगी। हालाँकि, लोगों को जोड़ना और काम के प्रवाह को बदलना अधिक तरल और स्व-संगठित है। "बहुत छोटी" या "बहुत बड़ी" टीमों के साथ कम चुनौतियाँ। टीमों की व्यवहार्यता के बारे में कम चिंताएँ, और जिम्मेदारी के क्षेत्रों में टीमों का मिलान। बहुत बड़ी कंपनियों में परीक्षण नहीं किया गया, लेकिन सैद्धांतिक रूप से सही लगता है। कोड स्वामित्व और विशेषज्ञता संरेखण सख्त कोड स्वामित्व, जो दुनिया को उन चीज़ों में विभाजित करने में मदद करता है जिनमें व्यक्ति महारत हासिल कर सकते हैं। प्रोत्साहनों का अच्छा संरेखण क्योंकि लोग अपने क्षेत्र में काम करते हैं। चुनौतियाँ यह सुनिश्चित करना है कि प्रत्येक टीम अपना कोडबेस बनाए रख सके और संचालित कर सके। ज़िम्मेदारियाँ उठाना कष्टकारी होता है। व्यावसायिक प्राथमिकताएँ बदलने से अक्सर पुनर्गठन होता है। प्रथाओं को विकेंद्रीकृत और खंडित किया जा सकता है, हालाँकि इससे चुनौतियाँ पैदा हो सकती हैं। उदाहरण के लिए, आप टीमों को अपनी स्वयं की प्रोग्रामिंग भाषाएँ चुनने, काम करने के विभिन्न तरीके और विभिन्न कोडिंग शैलियाँ चुनने दे सकते हैं। साझा कोड स्वामित्व. अच्छे मानकों, कुशल टीम या अच्छी समीक्षा प्रथाओं की आवश्यकता है। प्राथमिकताएँ बदलना कम कठिन है। जब तक आप सामूहिक सीमाएँ नहीं बदल रहे हैं, रीऑर्ग लगभग अस्तित्वहीन हैं। (सोचिए कि पुनर्गठन में प्रबंधन का कितना समय व्यतीत होता है!) प्रथाओं को अधिक मानकीकृत करने की आवश्यकता है, अन्यथा आपको समस्याएँ होंगी। प्रथाओं का मानकीकरण एक अच्छी बात है, इसलिए प्रोत्साहन सही जगह पर हैं, लेकिन विफलता मोड शायद बदतर है। स्थापत्य पैटर्न आदर्श आर्किटेक्चर माइक्रोसर्विसेज है। बड़े मोनोलिथ को अच्छी तरह से व्यवस्थित करने की आवश्यकता है। आम तौर पर माइक्रोसर्विस वातावरण के बाहर गन्दा होता है। मैं उम्मीद करूंगा कि FAST वास्तुकला के बारे में अधिक अज्ञेयवादी हो। मोनोलिथिक कोडबेस या माइक्रोसर्विस वातावरण के साथ काम करना चाहिए। और मिश्रण के साथ. माइक्रोसर्विस परिवेश में स्थानांतरण को और अधिक क्रमिक बनाना चाहिए। रोलआउट पैटर्न सख्त कोड स्वामित्व के लिए संगठन-व्यापी डिज़ाइन की आवश्यकता होती है कि किस टीम के पास क्या है। इन परिवर्तनों का कार्यान्वयन हमेशा बड़े पैमाने पर होता है। विघटनकारी, बड़े पुनर्गठन की आवश्यकता है। क्रमिक रूप से किया जा सकता है. आप एक या दो टीमों के साथ शुरुआत कर सकते हैं और यदि यह काम करता है तो धीरे-धीरे इसमें अतिरिक्त टीमें जोड़ सकते हैं। Reorgs दुर्लभ होना चाहिए. यह अभी भी सामूहिक स्तर पर होगा, लेकिन यह कम बार होना चाहिए। संरेखण तंत्र आमतौर पर लोगों को एकजुट करने के लिए ओकेआर, ऑल-हैंड मीटिंग और लिखित संचार का उपयोग करें। सामूहिक बैठकें सप्ताह में दो बार एक अंतर्निहित ऑल हैंड्स मीटिंग होती हैं, जहां आप लक्ष्यों को सुदृढ़ करते हैं और टीम के लिए संदर्भ निर्धारित करते हैं। यदि नेतृत्व उस बैठक को गंभीरता से लेता है, तो बहुत अधिक लाभ मिलता है। कर्मचारी प्रतिधारण अभ्यास ग्राइंड और टॉप-डाउन, उच्च-नियंत्रण वातावरण से लेकर उच्च प्रदर्शन टीमों तक हो सकते हैं जो , और लगातार अपने व्यवसाय के लिए मूल्य प्रदान करते हैं। इस प्रकार, कंपनी द्वारा प्रतिधारण काफी भिन्न होगा। फीचर-फ़ैक्टरी अपने व्यावसायिक संदर्भ और ग्राहकों को समझते हैं मैं उम्मीद करता हूं कि सामान्य चुस्त प्रथाओं के समान प्रथाएं भिन्न हो सकती हैं। हालाँकि, FAST खुद को कर्मचारी प्रतिधारण के लिए उधार देता है क्योंकि यह के साथ जुड़ा हुआ है। कर्मचारी यह चुन सकते हैं कि वे किसके साथ काम करें, किस विषय पर काम करें, और यह सुदृढीकरण प्राप्त करें कि उनका काम मायने रखता है। मुझे उम्मीद है कि इससे समग्र संतुष्टि बेहतर होगी। एक चुनौती राजनीति हो सकती है। स्व-शासित समूह कभी-कभी संघर्ष से खराब तरीके से निपटते हैं, इसलिए इसका उल्टा असर हो सकता है। आंतरिक प्रेरणा जैसा कि आप देख सकते हैं, FAST आज अधिकांश कंपनियां जो कर रही हैं उससे बहुत अलग दृष्टिकोण है। तो ट्रेडऑफ़ क्या हैं? जैसा कि मैंने देखा, ये फास्ट एजाइल के ट्रेडऑफ़ हैं: FAST बेहतर संगठनात्मक मापनीयता प्रदान कर सकता है FAST को क्रमिक रूप से प्रयोग किया जा सकता है तेजी से परिणाम कम होने चाहिए FAST बदलती प्राथमिकताओं पर प्रतिक्रिया देना आसान बनाता है आंतरिक प्रेरणा और प्रतिधारण के लिए FAST बेहतर हो सकता है लेकिन… कई वातावरण FAST के साथ असंगत हैं आपको स्व-प्रबंधन का प्रबंधन करना पड़ सकता है FAST के लिए बहुत अधिक कार्य की आवश्यकता होती है फास्ट सामग्रियां शब्दजाल से भरी हैं हम इनमें से प्रत्येक पर बारी-बारी से चर्चा करेंगे। FAST बेहतर संगठनात्मक मापनीयता प्रदान कर सकता है जब आप संगठनों को मापते हैं, तो आप आम तौर पर उन्हें "क्षैतिज रूप से" स्केल करके ऐसा करते हैं। आप एक समय में संगठन को एक टीम के रूप में विकसित करते हैं। इनमें से प्रत्येक टीम के पास उत्पाद का एक टुकड़ा होता है, और आपके पास अक्सर एक प्लेटफ़ॉर्म संगठन होता है जो उत्पाद टीमों को अधिक प्रभावी बनाता है। जैसे-जैसे लोगों की संख्या बढ़ती है संगठन की जटिलता बढ़ती जाती है। यदि आपके पास इंजीनियरिंग में दस लोग हैं, तो वे सभी एक दूसरे के साथ संवाद कर सकते हैं। इंजीनियरिंग में सौ लोग एक दूसरे से बात नहीं कर सकते। और कोडबेस किसी भी व्यक्ति के दिमाग में फिट नहीं बैठेगा। तो आप इस जटिलता को टीमों में विभाजित करते हैं, और प्रत्येक टीम के पास एक क्षेत्र होता है जिस पर वे ध्यान केंद्रित कर सकते हैं। FAST दिलचस्प है क्योंकि यह संगठनों को "लंबवत" पैमाने पर मापने का एक प्रयास है। अधिक टीमें जोड़ने के बजाय, FAST बनाने का प्रयास करता है, जिन्हें कलेक्टिव कहा जाता है। कलेक्टिव्स के पास अभी भी कोड है, लेकिन उस कलेक्टिव के भीतर स्व-संगठित टीमों के पास नहीं है। और आपको अभी भी संचार को खंडित करना होगा। लेकिन टीमें अधिक गतिशील हैं और लगातार विकसित होती रहती हैं। पुनर्गठन के माध्यम से टीमों को नया आकार देने के बजाय, यह आपके संचालन के तरीके का एक निरंतर, अपेक्षित हिस्सा है। बड़ी टीमें इंजीनियरिंग के कई प्रमुखों के लिए टीम का आकार एक परिचित विषय है। टीमें कितनी बड़ी होनी चाहिए? आइए इस विषय पर थोड़ा गहराई से विचार करें, क्योंकि इससे हमें यह समझने में मदद मिलती है कि फास्ट कैसे बेहतर पैमाने का दावा करता है। टीमें कितनी बड़ी होनी चाहिए? जब आप इंजीनियरिंग के वीपी लोगों के साथ समय बिताते हैं, तो कभी-कभी इंजीनियरिंग टीम के आकार का विषय सामने आएगा। आप छोटी टीमों के लिए तर्क और बड़ी टीमों के लिए तर्क सुनेंगे। दोनों पक्षों में खूबियां हैं. छोटी टीमों के फायदे टीम के भीतर कम समन्वय और संचार। परिणामस्वरूप तेजी से आगे बढ़ सकते हैं। काम की धाराएँ कम होने से ध्यान केंद्रित करना और परिणाम देना आसान हो जाता है। प्रबंधन करना आसान. बड़ी टीमों के लाभ चापलूस संगठन. 150 इंजीनियरों वाले एक इंजीनियरिंग संगठन में दस व्यक्तियों की टीमों के साथ 3-4 निदेशक होंगे। इसमें पांच व्यक्तियों की टीमों के साथ 6-8 निदेशक और 1-2 उपाध्यक्ष होंगे। किसी संगठन में भ्रम कहाँ से आता है? संभवतः नेतृत्व, इसलिए बड़ी टीमें भ्रम को कम कर सकती हैं। अधिक लचीलापन. कोई छुट्टी ले सकता है और टीम ठीक से काम जारी रख सकती है। इसलिए छोटी टीमें अपनी टीम के भीतर महान हैं, लेकिन कम आदर्श हैं क्योंकि उनमें से बहुत सारे हैं जिससे संगठनात्मक जटिलता बढ़ जाती है। समग्र संगठनात्मक जटिलता के लिए बड़ी टीमें बेहतर हैं, लेकिन प्रत्येक टीम के भीतर प्रदर्शन के लिए कम आदर्श हैं। कई नेता जो दृष्टिकोण अपनाते हैं वह बड़ी टीमें बनाना है जो काम की कम धाराओं पर ध्यान केंद्रित करती हैं। इससे आंतरिक टीम जटिलता कम हो जाती है, और संगठनात्मक जटिलता भी कम हो जाती है। आप FAST को एक ऐसे दृष्टिकोण के रूप में देख सकते हैं जो हास्यास्पद रूप से बड़ी टीमों के माध्यम से और भी अधिक संगठनात्मक सरलता प्राप्त करने का प्रयास करता है। और इसने छोटी स्व-संयोजन टीमों का लाभ भी प्राप्त करने का प्रयास किया। संगठनों का विस्तार करना चुनौतीपूर्ण कार्य है मेरा अधिकांश परामर्श व्यवसाय संगठनों को पैमाने से निपटने में मदद कर रहा है। संगठनों को चुनौतियों का सामना करने के कई चरणों का सामना करना पड़ता है। पहला बैरियर आम तौर पर 15-25 इंजीनियर मार्क पर होता है। यह वह समय है जब आपका अमीबा बहुत बड़ा हो गया है, और उसे विभाजित होने की आवश्यकता है। आप इस प्रकार की समस्याएँ देखते हैं: संचार माध्यम अप्रभावी हो जाते हैं। इंजीनियरिंग में डिलीवरी और/या गुणवत्ता संबंधी समस्याएं होने लगती हैं। प्रबंधक या नेता अभिभूत महसूस करते हैं। अधिक लोगों को जोड़ने से यह और खराब हो जाएगा, बेहतर नहीं। और दूसरा अवरोध लगभग साठ इंजीनियरों पर है। इस बिंदु पर, आपको बहुत अधिक समस्याएं दिखाई देने लगती हैं: समन्वय क्रॉस-टीम प्रोजेक्ट शायद ही कभी सफल होते हैं। उत्पाद कार्य प्लेटफ़ॉर्म टीमों को दलदल में डाल देता है, या इसके विपरीत। बड़ी पहलों को पूरा करने में असमर्थता. मैंने प्रतिभाशाली लोगों को संगठनात्मक जटिलता में इन चरण-क्रम परिवर्तनों को नेविगेट करने में बार-बार विफल होते देखा है। मेरा अनुमान यह है कि जब आप प्रबंधन की एक अतिरिक्त परत जोड़ते हैं तो ये चरण क्रम जटिलता में बढ़ जाता है। इंजीनियरिंग संगठनों को बढ़ाना एक वास्तविक कौशल है। इसके लिए संगठन और लोग कैसे काम करते हैं इसकी गहरी समझ की आवश्यकता है। आप इन चीज़ों के बारे में सीखते हैं: लोगों के समूहों को एक साथ काम करने के लिए । समन्वय मॉडल बनाम कार्यात्मक रूप से डिज़ाइन की गई टीमें। स्ट्रीम-संरेखित टीमें पुनर्गठन कैसे करें, जहां आप व्यवसाय की प्राथमिकताएं बदलने पर लोगों को स्थानांतरित करते हैं और कोड बनाते हैं। उत्पादों को उत्पाद निवेश के साथ ओवरलैप होने वाली तकनीकी जिम्मेदारियों के क्षेत्रों में कैसे विभाजित किया जाए। टीमों के आसपास संचार चैनल स्थापित करना। आपके उत्पाद को प्रभावी ढंग से समर्थन देने के लिए ऑन कॉल और विश्वसनीयता कार्यक्रम स्थापित करना। जटिलता से निपटने के लिए प्लेटफ़ॉर्म संगठनों और डेवलपर अनुभव पहलों की स्थापना करना। वगैरह। भले ही आपके पास इस विशेषज्ञता वाले लोग हों, स्केलिंग से निपटने के लिए आपकी प्रबंधन टीम को बहुत प्रयास की आवश्यकता होती है। इसलिए यदि FAST बेहतर पैमाने पर काम कर सकता है, तो आप किसी और चीज़ पर ध्यान केंद्रित करने के लिए अपनी प्रबंधन टीम की काफी संभावनाएं खोल देंगे। और, क्योंकि आपके चरण-क्रम में परिवर्तन बहुत कम बार होते हैं, आप संभावित रूप से अपने संगठन को प्रबंधित करना बहुत आसान बना सकते हैं। फास्ट एजाइल के आसपास एक विचार प्रयोग तो, कल्पना कीजिए कि आप टीम के आकार को माप । पाँच या दस लोगों की टीमों के बजाय, यदि आपके पास प्रभावी बीस व्यक्तियों की टीमें हों तो क्या होगा? या साठ व्यक्तियों की टीमें? सकते हैं प्रथमदृष्टया, यह एक हास्यास्पद प्रस्ताव है। इतनी बड़ी टीमें प्रभावी नहीं होतीं. यहाँ तक कि बारह व्यक्तियों की टीमें भी बहुत बड़ी हैं। मैं कभी-कभी ऐसे लोगों के बायोडाटा देखता हूं जिनके पास बीस या तीस लोग रिपोर्ट करते हैं। मेरी तत्काल प्रतिक्रिया यह सोचना है कि उन्होंने एक भयानक कंपनी में काम किया। इतनी सारी प्रत्यक्ष रिपोर्टें होना एक "संगठनात्मक गंध" है। फास्ट एजाइल का केंद्रीय आधार यह है कि यदि आप इस बड़े कलेक्टिव के भीतर स्व-संगठन और स्व-चयन करने वाली टीमों को जोड़ते हैं, तो आप अपनी टीमों को अधिक माप सकते हैं। प्रत्येक टीम (फास्ट उन्हें कलेक्टिव्स कहता है) बहुत बड़ी हो सकती है। और फिर जिन टीमों के साथ लोग दिन-प्रतिदिन काम करते हैं, वे उन सामूहिकताओं के भीतर स्व-इकट्ठी हो जाती हैं। क्षैतिज रूप से यदि बड़े सामूहिक प्रभावी होते, तो वे संगठनात्मक जटिलता को काफी कम कर देते। विशिष्ट सॉफ़्टवेयर स्टार्टअप को ज़िम्मेदारी के क्षेत्रों में विभाजित होने में वर्षों लग सकते हैं। कोडबेस को प्रत्येक टीम के स्वामित्व वाले क्षेत्रों में सख्ती से विभाजित करने की आवश्यकता नहीं होगी। इससे महत्वपूर्ण प्रबंधन समय खाली हो जाएगा जिसका उपयोग प्रबंधक उत्पाद और टीमों पर ध्यान केंद्रित करने के लिए कर सकते हैं। तो यह वह केंद्रीय चीज़ है जिसका हमें परीक्षण करने की आवश्यकता है: क्या स्व-संयोजन, और स्व-संगठन संचालित करने का एक तरीका प्रदान करता है जो छोटी, डिज़ाइन की गई टीमों जितना प्रभावी है? यदि ऐसा होता है, तो यह संगठनों को स्केल करने का एक तरीका प्रदान करेगा जो संभावित रूप से स्केलिंग संगठनों में बेहतर परिमाण का क्रम है। इतना क्यों? आइए छह लोगों की टीमों के साथ विकसित होने वाले संगठन की तुलना साठ लोगों की "टीमों/सामूहिक" वाले संगठन से करें। इस तर्क में बहुत सारी धारणाएँ अंतर्निहित हैं, और आप इसमें कुछ खामियाँ निकालने में सक्षम हो सकते हैं। लेकिन अगर आप ऐसा करते भी हैं, तो FAST अनिवार्य रूप से एक बड़ी संगठनात्मक इकाई को उत्पाद और कोडबेस के एक क्षेत्र का मालिक बनने की अनुमति देता है। FAST नया है, इसलिए अभी इस बारे में कोई सबूत नहीं है कि FAST टीमें पारंपरिक चुस्त टीमों की तरह प्रभावी ढंग से काम करती हैं या नहीं। लेकिन मुझे संदेह है कि उस प्रश्न का उत्तर हाँ है। मेरे पास उस पर विश्वास करने के कुछ कारण हैं। सबसे पहले, जिम शोर का इसके साथ प्रारंभिक अनुभव काफी सकारात्मक था, और वह ऐसे व्यक्ति हैं जिन पर मुझे भरोसा है। फास्ट को लेकर मेरे आशावादी होने का दूसरा कारण यह है कि मुझे स्व-संगठन करने वाले लोगों के बड़े समूहों के साथ कुछ अनुभव हुआ है। और मुझे आश्चर्य हुआ कि इसने कितनी अच्छी तरह काम किया। बेशक, छोटी कंपनियों में आप बहुत सारा स्व-संगठन देखते हैं। लेकिन जैसे-जैसे कंपनियां बढ़ती हैं, आप चीजों का मानकीकरण करते हैं और टीमों के अलावा स्व-संगठन को हटा देते हैं। हालाँकि, सबसे दिलचस्प प्रयोगों में से एक जिसका मैं हिस्सा रहा हूँ वह न्यू रेलिक में एक बड़े पैमाने पर स्व-संगठन कार्यक्रम था। हमने अपनी सभी टीमों को फिर से डिज़ाइन किया, और पचास सॉफ़्टवेयर टीमों में से प्रत्येक को यह चुनने के लिए कहा कि वे किस टीम का हिस्सा बनना चाहते हैं। हमारे पास प्रत्येक टीम के लिए आवश्यक कौशल पर बाधाएं थीं, और हमने परिभाषित किया था कि हर किसी के पास क्या होना चाहिए। यह किसी की भी अपेक्षा से कहीं अधिक सफल रहा, यहाँ तक कि हमारे आयोजकों की भी। इसलिए यद्यपि जूरी इस पर सहमत नहीं है, मेरा अनुमान है कि इस अभ्यास में सही संदर्भों में बहुत अधिक संभावनाएं हैं। FAST को क्रमिक रूप से प्रयोग किया जा सकता है फास्ट सामग्री में इसका उल्लेख नहीं है, लेकिन फास्ट के बारे में दिलचस्प बात यह है कि आप इसके साथ क्रमिक रूप से प्रयोग कर सकते हैं। आप एक प्रयोग के रूप में एक टीम पर फास्ट एजाइल को लागू कर सकते हैं, और फिर ब्लॉब दृष्टिकोण का उपयोग कर सकते हैं जहां आप समय के साथ अतिरिक्त टीमों को निगल सकते हैं। यदि यह ठीक रहा, तो अतिरिक्त टीमों को निगलना जारी रखें। यदि ऐसा नहीं होता, तो प्रयोग रोक दें. तेजी से परिणाम कम होने चाहिए परिवर्तन संगठनों में होता रहता है. प्राथमिकताएँ बदल जाती हैं, लोग चले जाते हैं, उत्पाद के क्षेत्रों में अप्रत्याशित वृद्धि होती है। पिछले तकनीकी निर्णय आपको परेशान करते हैं और आपको अतिरिक्त काम करना पड़ता है। नए अवसर पैदा होते हैं जिनमें निवेश की आवश्यकता होती है। इन सभी चीज़ों का आपके संगठन की संरचना पर प्रभाव पड़ता है। आपके पास टीमों का एक समूह है, जिनमें से प्रत्येक के स्वामित्व के अपने-अपने क्षेत्र हैं। जैसे ही यह परिवर्तन होता है, आप अपने संगठन को सर्वोत्तम प्रदर्शन करने के लिए समय के साथ पुनः तैयार करते हैं। ये रिफैक्टरिंग "रीऑर्ग" हैं, और बढ़ते संगठनों में, ये अक्सर हो सकते हैं! FAST के साथ रीऑर्ग बहुत कम होने चाहिए। पुनर्गठन की इकाई इतनी बड़ी है कि आपको इसे बार-बार नहीं करना पड़ेगा। इसका एक संभावित नकारात्मक पक्ष यह है कि आपके पास जिम्मेदारी के परिभाषित क्षेत्रों वाली टीमें नहीं हैं। तो आपके पास ज़िम्मेदारी का प्रसार हो सकता है और खराब बनाए रखा गया कोड कॉमन्स हो सकता है। (हम इस बारे में थोड़ी देर बाद बात करेंगे) FAST बदलती प्राथमिकताओं पर प्रतिक्रिया देना आसान बनाता है जब परंपरागत रूप से संरचित टीमों में प्राथमिकताएं बदलती हैं, तो आपके पास काम करने के लिए टीमें गठित होती हैं। यदि वह टीम संरचना नई प्राथमिकताओं का समर्थन नहीं करती है, तो आपको अपने संगठन को दोबारा तैयार करना होगा। FAST के लिए, प्राथमिकता में परिवर्तन अधिक तरल और निरंतर होते हैं। जब तक जिम्मेदारियाँ सामूहिक के भीतर रहती हैं, तब तक टीमें काम के अनुसार खुद को व्यवस्थित कर लेती हैं, और यह एक और दिन की तरह है। सामूहिक बैठक संरचना बदलती प्राथमिकताओं को भी कम नाटकीय बनाती है। आपके पास अनिवार्य रूप से सप्ताह में दो बार बिल्ट-इन ऑल हैंड्स होता है। सामूहिक बैठकों में, आप लगातार संदर्भ संप्रेषित कर सकते हैं और अपनी टीम को अपने ग्राहकों और बाज़ार के बारे में शिक्षित कर सकते हैं। इससे आपकी टीम को बेहतर ढंग से संगठित रखने में मदद मिलेगी। जब मैं उस दृष्टिकोण की तुलना त्रैमासिक ओकेआर जैसी किसी चीज से करता हूं, तो यह अधिक तरल लगता है और ऐसा लगता है कि यह लोगों को संरेखित करने का बेहतर काम करेगा। संदर्भ और प्राथमिकताओं को लगातार साझा करने के लिए उत्पाद नेता से प्रतिबद्ध प्रयास की आवश्यकता होती है। लेकिन मैं जिन सर्वश्रेष्ठ टीमों का हिस्सा रहा हूं उनमें से कुछ में उत्पाद लीडर इस तरह से काम कर रहे थे, इसलिए मुझे संदेह है कि यह समय अच्छा व्यतीत हुआ है। आंतरिक प्रेरणा और प्रतिधारण के लिए FAST बेहतर हो सकता है कई टीमें ऐसा महसूस कर सकती हैं कि उनकी प्रक्रिया लोगों को नियंत्रित करने के उपकरण के रूप में डिज़ाइन की गई है। और यह किसी असेंबली लाइन पर काम करने जैसा महसूस हो सकता है। FAST अपने डिज़ाइन के मूलभूत घटक के रूप में स्व-संगठन को अपनाता है। यह इतना मौलिक है कि यह स्व-संगठन के बिना काम नहीं करेगा। इसके प्रबंधन के लिए एक पूरी तरह से अलग टूलकिट की आवश्यकता होती है, और यह ज्यादातर (हालांकि पूरी तरह से नहीं) ऊपर से नीचे, पदानुक्रमित दृष्टिकोण के साथ असंगत है। डैनियल पिंक ने प्रसिद्ध रूप से रेखांकित किया: आंतरिक प्रेरणा के तीन पहलुओं को - स्व-निर्देशित होने की इच्छा, जो अनुपालन से अधिक जुड़ाव बढ़ाती है। स्वायत्तता - बेहतर कुशल बनने की ललक। निपुणता - कुछ ऐसा करने की इच्छा जिसका अर्थ हो और जो महत्वपूर्ण हो। जो व्यवसाय उद्देश्य को महत्व दिए बिना केवल मुनाफे पर ध्यान केंद्रित करते हैं, उनका अंत खराब ग्राहक सेवा और नाखुश कर्मचारियों के साथ होगा। उद्देश्य FAST के साथ, आप अपने काम को स्व-निर्देशित करने में सक्षम हैं, जिससे आपको स्वायत्तता महसूस करने में मदद मिलती है। आप उस काम पर ध्यान केंद्रित करने में सक्षम हैं जो आपके कौशल को बेहतर बनाता है, निपुणता की भावना प्राप्त करता है। और आपको लगातार याद दिलाया जाता है कि आपका काम व्यवसाय के लिए महत्वपूर्ण चीज़ों से कैसे जुड़ा है, जिससे आपको उद्देश्य की भावना महसूस करने में मदद मिलती है। इसलिए हालांकि इसकी गारंटी नहीं है, मैं फास्ट को लागू करने वाले संगठनों के लिए उच्च अवधारण दर देखने की संभावना देखता हूं। स्व-संगठन कुछ उपयोगी संकेत भी प्रदान करता है जो लोगों के समुदाय को एक साथ बेहतर ढंग से काम करने में मदद कर सकता है। "जर्क मैनेजर" प्रकार के व्यक्ति को संकेत मिलता है कि उनका व्यवहार स्वागत योग्य नहीं है। कैसे? वे एक टीम का नेतृत्व करने के लिए आगे बढ़ते हैं और कहते हैं कि वे जो काम करना चाहते हैं। यदि कोई भी उनकी टीम में शामिल नहीं होता है, तो काम नहीं होता है, और टीम नहीं बनती है (टीम में कम से कम दो या तीन लोग होते हैं, या ऐसा नहीं होता है)। स्व-संगठन लोगों को काम के दर्दनाक पहलुओं से निपटने की भी अनुमति देता है जिन पर अन्य कंपनियों में ध्यान नहीं दिया जा सकता है। उदाहरण के लिए, यदि परीक्षण सूट ख़राब है, तो कोई व्यक्ति उस समस्या को हल करने वाली टीम का नेतृत्व करने के लिए आगे बढ़ सकता है। वह काम करना बिल्कुल उचित है जो स्पष्ट रूप से व्यावसायिक प्राथमिकता नहीं है। लेकिन यह खुले में है, और इसे घटित करने के लिए दूसरों को भी इसमें शामिल होना होगा। इससे आपको यह महसूस होने से बचने में मदद मिल सकती है कि आप किसी में हैं। फ़ीचर फ़ैक्टरी अंततः, आप उन लोगों को चुनने में सक्षम हैं जिनके साथ आप प्रतिदिन काम करते हैं। जब मैंने अतीत में स्व-संगठित टीमों को देखा, तो यह एक अप्रत्याशित लाभ था: लोगों ने उन लोगों के साथ काम करना चुना जिनके साथ वे काम करना चाहते थे। और वे टीमें मेरी अपेक्षा से कहीं अधिक मजबूत थीं। जिस चीज़ के विरुद्ध यह सब संतुलित किया जाएगा वह कोई नया दर्द है जो लोगों को FAST के साथ अनुभव होगा। एक चुनौती अनौपचारिक शक्ति गतिशीलता, या संभावित राजनीति के साथ हो सकती है। कई वातावरण FAST के साथ असंगत हैं क्योंकि FAST इतना नया है, इसे लागू करना जोखिम भरा है। हर स्थिति में FAST का कोई मतलब नहीं होगा। और भी अज्ञात हैं. इसे एक प्रयोगात्मक दृष्टिकोण के रूप में सोचना सबसे अच्छा है। तेजी से प्रयास करने के लिए कौन सा वातावरण सबसे अनुकूल है? और आपको कहां फास्ट से बचना चाहिए? आपकी कंपनी में इस सूची से जितने अधिक गुण होंगे, FAST के लिए वह उतना ही बेहतर होगा: प्रबंधन नवाचार और प्रयोग में रुचि। उच्च विश्वास, कम भय वाला वातावरण। या कम से कम नेतृत्व में आदेश और नियंत्रण से बचने की इच्छा। प्रक्रिया का एक अच्छा मार्गदर्शक या सुविधाकर्ता। कोई व्यक्ति जो एक प्रभावी सामूहिक बैठक चला सकता है, प्रक्रिया स्थापित कर सकता है, उसका मूल्यांकन कर सकता है और सक्रिय रूप से उसका प्रबंधन कर सकता है। कोई व्यक्ति जो संगठनात्मक गतिशीलता को समझता है और समूहों में मनुष्य एक साथ कैसे काम करते हैं। (आप इसके लिए मुझे काम पर रख सकते हैं)। प्राथमिकताओं में परिवर्तन की मध्यम से उच्च दर। यदि प्राथमिकताएँ नहीं बदल रही हैं तो FAST कम उपयोगी है। एक टीम जो सहयोगात्मक, स्व-निर्देशित, उच्च प्रदर्शन करने वाली और लगातार सीखने वाली है। एक नेतृत्व टीम जो अपनी प्राथमिकताओं का पता लगा सकती है। आपके पास एक उत्पाद नेता है जो प्रत्येक सामूहिक बैठक में प्राथमिकताओं और व्यावसायिक संदर्भ के बारे में बात कर सकता है। और वे प्रभावी ढंग से संवाद कर सकते हैं। ये लक्षण जितने कम सत्य होंगे, आपको FAST के साथ उतनी ही अधिक विपरीत परिस्थितियों का सामना करना पड़ेगा। मुझे नहीं लगता कि आपको इसके लिए एक आदर्श वातावरण में रहने की आवश्यकता है। कुछ मायनों में, मुझे लगता है कि इन चीज़ों के होने की चाहत वास्तव में इन चीज़ों के होने से अधिक महत्वपूर्ण है। तो शायद सबसे महत्वपूर्ण सफलता कारक यह है कि नेतृत्व इसके लिए जगह बना रहा है। आपको स्व-प्रबंधन का प्रबंधन करना पड़ सकता है स्व-संगठित प्रणालियाँ प्रभावी ढंग से काम कर सकती हैं। लेकिन वे स्वतंत्र नहीं हैं. वे एक समुदाय का प्रबंधन करना अधिक पसंद करते हैं। आपको सही व्यवहार को उकसाने के लिए बाधाएँ और साधन बनाने की आवश्यकता होगी। और आपको यह सुनिश्चित करने के लिए सावधानीपूर्वक निगरानी और प्रबंधन करने की आवश्यकता होगी कि चीजें पटरी से न उतर जाएं। किसी भी संगठन में बुरे अभिनेता या ऐसे लोग हो सकते हैं जो उस समुदाय के हितों से मेल नहीं खाते। मुझे याद है कि एक बार मैं एक इंजीनियर से बात कर रहा था जिसने मुझसे कहा था (मैं मजाक नहीं कर रहा हूं) कि उन्हें नहीं लगता कि अपने नियोक्ता के लिए मूल्य पैदा करना उनका दायित्व है। कुछ इंजीनियर शायद उन चीज़ों पर ध्यान केंद्रित करना चाहते हैं जो उनके कौशल को विकसित करती हैं या उन्हें अधिक मूल्यवान कर्मचारी बनाती हैं, न कि उन चीज़ों पर जो उन्हें काम पर रखने वाली कंपनी के लिए अच्छी हैं। FAST के साथ, आप लोगों के के प्रबंधन के लिए साइन अप कर रहे हैं। समुदाय पारंपरिक स्थितियों में, पदानुक्रम स्पष्ट करता है कि इसके लिए कौन जिम्मेदार है। फास्ट में, मुझे संदेह है कि संघर्ष से बचने की कोशिश करना आसान होगा और "सदस्यों को इसका पता लगाने दें"। इसके परिणामस्वरूप अनौपचारिक बिजली नेटवर्क एक प्रकार की पर हावी हो सकते हैं। यदि आप FAST का उपयोग करते हैं, तो यह एक ऐसी चीज़ है जिससे मैं सावधान रहूँगा। संरचनाहीनता के अत्याचार दूसरा चरम यह होगा कि समूह को समस्याओं का पता न चलने दिया जाए और प्रबंधन को इसे पूरी तरह से संभालने दिया जाए। ये हानिकारक हो सकता है. भी इसलिए FAST को अच्छी सुविधा, सावधानीपूर्वक अवलोकन और कभी-कभार हस्तक्षेप की आवश्यकता होगी। FAST के लिए बहुत अधिक कार्य की आवश्यकता होती है सबसे बड़ा कारण जो आप FAST के साथ प्रयोग नहीं करना चाहेंगे वह यह है कि FAST के साथ बहुत सारा छिपा हुआ काम है। इसके संचालन के अपरिचित तरीके में, आपके संगठन में बहुत सारे बदलाव की आवश्यकता है। आप FAST की तुलना किसी नई कंप्यूटर प्रोग्रामिंग भाषा में काम करने से कर सकते हैं। नई भाषा आशाजनक लगती है क्योंकि इसमें इतनी सारी नई एर्गोनोमिक विशेषताएं हैं कि यह आपके द्वारा पहले देखी गई किसी भी चीज़ से कहीं बेहतर लगती है। लेकिन, आपके पास इस नई भाषा में लिखी गई रूपरेखाएँ और लाइब्रेरीज़ नहीं हैं। इसलिए आपको इसका बहुत सारा हिस्सा स्वयं ही बनाना होगा। तो FAST का सबसे बड़ा नुकसान यह है कि यह एक अच्छी तरह से स्थापित प्रथा नहीं है। FAST कैसे संचालित होता है और पारंपरिक प्रथाओं के बीच असंगतताओं से निपटने के लिए आपको बहुत सी चीजें बनाने की आवश्यकता होगी। यहां कुछ उदाहरण दिए गए हैं: प्रदर्शन प्रबंधन कैसे काम करता है? पारंपरिक टीमों में, आपके पास एक प्रबंधक होता है जो काम की देखरेख करता है, और व्यक्तियों को प्रशिक्षित करता है। आपके पास प्रदर्शन समीक्षाएँ हैं, और यदि कोई व्यक्ति उपयुक्त नहीं है, तो प्रबंधक हस्तक्षेप कर सकता है। हालाँकि प्रदर्शन समीक्षाओं में समस्याएँ हैं, अधिकांश लोग समझते हैं कि वे कैसे काम करते हैं, और वे संगठन में एक उद्देश्य की पूर्ति करते हैं। FAST टीमों पर, प्रदर्शन समीक्षा करने का वास्तव में कोई स्पष्ट तरीका नहीं है। क्या उस व्यक्ति के प्रबंधक को यह भी पता है कि वे क्या कर रहे हैं या कैसे काम कर रहे हैं? आप "टीमों" का मूल्यांकन भी नहीं कर सकते, क्योंकि वे क्षणभंगुर हैं। इसलिए प्रदर्शन प्रबंधन की संपूर्ण अवधारणा को फिर से आविष्कार करने की आवश्यकता है। हालाँकि यह वैसे भी एक अच्छा विचार हो सकता है, यह कुछ ऐसा है जिसके लिए विचार और आविष्कार की आवश्यकता होगी। FAST में इंजीनियरिंग प्रबंधकों की क्या भूमिका है? इंजीनियरिंग प्रबंधक की भूमिका को संरचित करने के कई तरीके हैं। मैं आम तौर पर बनाने की सलाह देता हूं क्योंकि इससे उन्हें अपनी टीम के साथ कंधे से कंधा मिलाकर काम करने का मौका मिलता है, बिना उन्हें ऐसे क्षेत्र में रखे जहां बिजली अंतर समस्याएं पैदा करता है। इंजीनियरिंग प्रबंधक की भूमिका को परिभाषित करने के कई वैध तरीके हैं, लेकिन मैं उसी पर ध्यान आकर्षित करता हूँ। परियोजना प्रबंधन के लिए इंजीनियरिंग प्रबंधक को जिम्मेदार FAST में, इंजीनियरिंग प्रबंधक की भूमिका कम स्पष्ट है। आपके पास लंबे समय तक रहने वाली टीमें नहीं हैं, इसलिए इंजीनियरिंग प्रबंधक के लिए उनकी प्रत्यक्ष रिपोर्ट के साथ कंधे से कंधा मिलाकर काम करना कठिन है। आप इंजीनियरिंग प्रबंधकों को स्व-इकट्ठी टीमों का नेतृत्व करने के लिए कह सकते हैं। या फिर आप उन्हें शुद्ध जन प्रबंधक बना सकते हैं। या आप उन्हें खिलाड़ी-कोच बना सकते हैं। इन सभी में सामंजस्य है, और कुछ बहुत बड़े नकारात्मक पहलू भी हैं। ऐसा प्रतीत होता है कि FAST से अधिक इंजीनियरिंग प्रबंधन की आवश्यकता कम हो गई है। आपको अभी भी लोगों को काम पर रखने, प्रदर्शन प्रबंधन करने और प्रक्रिया की निगरानी करने की आवश्यकता है। लेकिन शायद उतना नहीं जितना एक पारंपरिक संगठन में होता है? मैंने कई संगठनों को पीड़ित होते देखा है क्योंकि वे प्रबंधन को एक अनुशासन के रूप में महत्व नहीं देते हैं। लेकिन मेरा अनुमान है कि FAST संगठनों को कम प्रबंधन की आवश्यकता होती है। मैं वास्तव में यह देखने के लिए उत्सुक हूं कि क्या ऐसा होता है, और उन संगठनों से सुनना चाहता हूं जो FAST के साथ प्रयोग करते हैं। आप प्रबंधन के साथ क्या करते हैं? स्वामित्व के क्षेत्रों के बिना आप कोड गुणवत्ता कैसे सुनिश्चित करेंगे? कोड स्वामित्व कोड गुणवत्ता को उच्च बनाए रखने के लिए प्राकृतिक प्रोत्साहन प्रदान करता है। यह आपके स्वार्थ में है, क्योंकि आपके भविष्य को आपके वर्तमान कोड में काम करना होगा। साझा कोड स्वामित्व स्थिति में, आपको कोड गुणवत्ता सुनिश्चित करने के लिए अधिक प्रयास करना होगा। मेरी सिफ़ारिश एक आवश्यक अभ्यास के रूप में जोड़ी बनाना या जुटाना होगी। आपको कोड पैटर्न के लिए मजबूत मानकों की भी आवश्यकता होगी। आपको कोड लाइनिंग की आवश्यकता होगी. और आपको किसी प्रकार के वास्तु संबंधी निर्णय लेने की आवश्यकता होगी। आपका फ्रंटएंड कोड स्थिति को कैसे संभालता है, इसके लिए आप बीस पैटर्न नहीं रखना चाहेंगे। अधिकांश सॉफ़्टवेयर संगठनों में ये समस्याएं होंगी, लेकिन FAST का उपयोग करने वाले संगठन में ये और भी अधिक गंभीर होंगी। एक चीज़ जिस पर बहुत सारे संगठन कम निवेश करते हैं, वह है प्रभावी सॉफ़्टवेयर डिज़ाइन पैटर्न के बारे में प्रशिक्षण और संचार। और बातचीत यह सुनिश्चित करने के लिए कि हर कोई इस बात पर सहमत है कि किस दृष्टिकोण का उपयोग करना है और कब करना है। ये संभवतः FAST संगठन में और भी अधिक महत्वपूर्ण हैं। साझा कोड स्वामित्व एक ऐसी प्रथा है जिसकी कुछ मिसालें हैं। यदि आप तेजी से आगे बढ़ते हैं तो इसमें सफल होने के तरीके पर विचार करने में समय व्यतीत करना उचित होगा। एकाधिक सामूहिकता और सामूहिक सीमाओं को पार करने से क्या होता है? सामूहिक सीमाओं को पार करने वाला कार्य अनिवार्य रूप से FAST में अपरिभाषित है। और उच्च स्तर के समन्वय की आवश्यकता वाली बड़ी पहलों को भी FAST द्वारा कम निर्दिष्ट किया गया है। इसलिए आपको इन स्थितियों का समाधान खोजना होगा। कोई भी संगठन जो FAST का उपयोग करने के लिए कई कलेक्टिव रखने के लिए पर्याप्त बड़ा है, क्रॉस-कलेक्टिव परियोजनाओं में चलेगा। इन चीजों को संबोधित करने के पैटर्न आपके द्वारा छोटे पैमाने पर इसे हल करने के तरीके के समान या अनुरूप होंगे। लेकिन जहां तक मेरी जानकारी है, यह काफी हद तक अज्ञात क्षेत्र है। इसलिए आपको इन समस्याओं के उत्पन्न होने पर उन्हें हल करने के लिए कुछ उपयोग करने की आवश्यकता होगी। यह एक आविष्कार का कार्य होगा. समन्वय मॉडल का FAST ऑन-कॉल से कैसे निपटता है? में ऑन-कॉल का विशेष रूप से उल्लेख नहीं किया गया है। इसलिए आपको इससे निपटने के लिए एक योजना का आविष्कार करना होगा। फास्ट गाइड पारंपरिक टीमों में, ऑन-कॉल के लिए मानक सलाह यह है कि प्रत्येक टीम अपने स्वयं के संचालन के लिए जिम्मेदार हो। और टीम के सभी लोगों को कॉल पर रखना। इसका तात्पर्य यह है कि आपके पास कम से कम चार लोगों की टीम होनी चाहिए ताकि बोझ बहुत अधिक न हो। सोच यह है कि अपने कार्य उत्पाद के लिए टीमों को कॉल पर रखने से उन्हें विश्वसनीयता हासिल करने के लिए प्रोत्साहन मिलता है। इससे उन्हें यह सुनिश्चित करने में मदद मिलती है कि उनके पास एक अच्छा ऑन-कॉल शेड्यूल है। FAST के साथ, आप एक ऑन-कॉल रोटेशन बना सकते हैं जिसमें स्तर हैं (इस रनबुक का पालन करें और यदि यह इसे ठीक नहीं करता है तो आगे बढ़ें)। और आपको स्पष्ट रूप से एक नक्शा रखना होगा कि कौन किसका समर्थन करने में सक्षम है। यह आपकी टीमों पर मैप नहीं होगा. ऐसा करना बहुत कठिन नहीं है, लेकिन पारंपरिक ऑन-कॉल प्रथाओं की तुलना में यह कम आम है, और इसके लिए प्रबंधन को ध्यान देने की आवश्यकता होगी। बग्स को ठीक करने और समर्थन वृद्धि के बारे में क्या? FAST की एक वैकल्पिक भूमिका होती है जिसे "फ़ीचर स्टीवर्ड" कहा जाता है। वे एक विशेष सुविधा के लिए एक तरह के विशेषज्ञ हैं, और हितधारकों के लिए उस सुविधा के आसपास संपर्क का बिंदु हैं। उन्हें उस सुविधा पर लगातार काम करने की आवश्यकता नहीं है, बल्कि इसकी निरंतर समझ होनी आवश्यक है। ऑन-कॉल की तरह, आपको उन सुविधाओं पर विशेषज्ञता वाले लोगों के लिए सुविधाओं की मैपिंग की आवश्यकता होगी। यह बग और समर्थन वृद्धि दोनों के लिए महत्वपूर्ण होगा। और आप इसे ऑन-कॉल के साथ भी जोड़ सकते हैं। आपको मुद्दों को सही लोगों तक पहुंचाने के लिए किसी तरीके की आवश्यकता होगी। आपको यह भी सुनिश्चित करना होगा कि जब विशेषज्ञता एक या दो लोगों तक सीमित हो तो आपके पास ज्ञान की कमी को पूरा करने के लिए एक तंत्र हो। एक चीज़ जो आपको तय करनी होगी वह है बग ठीक करने की आपकी नीति। क्या आप चाहते हैं कि वे हमेशा ठीक रहें, जिससे अन्य फीचर का काम धीमा हो जाए? क्या बग्स को उस व्यक्ति द्वारा ठीक कर दिया गया है जिसने उन्हें पेश किया था, या आप कोई अन्य योजना चाहते हैं? और आप यह कैसे निर्धारित करेंगे कि बगों को दूर करने के लिए कौन जिम्मेदार है? संभवतः किसी प्रकार का ? घुमाव समर्थन वृद्धि के लिए भी कुछ प्रयास की आवश्यकता होगी। संपर्क का बिंदु किसी क्षेत्र के लिए फ़ीचर प्रबंधक है। लेकिन क्या होगा यदि फ़ीचर स्टीवर्ड छुट्टी पर है? आप संभवतः प्रत्येक क्षेत्र के बारे में एक से अधिक जानकार व्यक्ति चाहते हैं। और क्या होगा यदि समर्थन प्रश्न के लिए काम की आवश्यकता पड़े? क्या आप सिर्फ काम करते हैं, या इसे केंद्रीय प्राथमिकताओं में शामिल करते हैं? इनमें से किसी को भी हल करना कठिन समस्या नहीं है, लेकिन ये प्रबंधन का काम है। और आप जो कुछ भी करेंगे उसमें फोकस बनाम जवाबदेही का संतुलन होगा। विश्वसनीयता घटनाओं और घटना पूर्वव्यापी के बारे में क्या? FAST यह परिभाषित नहीं करता कि घटनाओं से कैसे निपटा जाता है। आपके ऑन-कॉल पैटर्न काफी हद तक यह निर्धारित करेंगे कि घटनाओं को कैसे संभाला जाता है, और संभवतः इसमें वह व्यक्ति भी शामिल होगा जो जानता है कि स्थिति को ठीक करने के लिए इसे कैसे ठीक किया जाए। FAST यह वर्णन नहीं करता कि घटना के पूर्वव्यापी प्रभाव को कैसे संभालना है। मैं निम्नलिखित जैसा कुछ करने की अनुशंसा करूंगा: अगली सामूहिक बैठक से पहले होने वाली किसी घटना को पूर्वव्यापी रूप से शेड्यूल करें। पूर्वव्यापी का एक उद्देश्य ऐसे कुछ कार्यों की पहचान करना होगा जो किए जा सकते हैं जो घटना के कारण की संभावना या गंभीरता को कम कर देंगे। दूसरा यह होगा कि आप इस घटना से सब कुछ सीखें। घटना के तुरंत बाद सामूहिक बैठक में, हमने जो सीखा उसे साझा करूंगा, और पूर्वव्यापी में पहचाने गए कुछ कार्यों को अगले चक्र के लिए स्वचालित प्राथमिकता भी दूंगा। न्यू रेलिक में, हमने FAST का उपयोग नहीं किया, लेकिन हमारी नीति समान थी। हमने इसे "दुर्घटनाएँ न दोहराएँ" (DRI) कहा। यह विश्वसनीयता के लिए हमारे द्वारा किए गए अब तक के सर्वोत्तम कार्यों में से एक था। नियम यह था कि डीआरआई का काम स्वचालित रूप से अन्य प्राथमिकताओं से अधिक महत्वपूर्ण था। इस प्रकार, किसी घटना के परिणामस्वरूप हमेशा या तो गुंजाइश कम हो जाती है, या समय सीमा पीछे खिसक जाती है। FAST में डिज़ाइनर कैसे काम करते हैं? कई डिजाइनरों के सामने एक चुनौती इंजीनियरिंग टीम के साथ काम करने या इंजीनियरिंग टीम से आगे काम करने पर ध्यान केंद्रित करना है। या उन्हें दोनों तरीकों से संचालित करें। आप काम करने के दोनों तरीकों के लिए मजबूत तर्क सुनेंगे। FAST यह निर्दिष्ट नहीं करता है कि इसे कैसे काम करना चाहिए, इसलिए आपको स्वयं निर्णय लेना होगा। क्या डिज़ाइनर काम करने के लिए टीमों के लिए साइन अप करते हैं? या क्या वे एक सेवा संगठन हैं, जो चीजों पर आगे बढ़कर काम करते हैं, और जब लोगों को उनसे कुछ चाहिए होता है तो रूप में कार्य करते हैं? आपको निर्णय लेना होगा. मैं संभवतः डिज़ाइनरों से साइन अप करवाऊंगा और टीमों का हिस्सा बनूंगा, लेकिन फिर से यह उस प्रकार के निर्णयों का एक उदाहरण है जो आपको FAST को अपनाते समय लेने की आवश्यकता होगी। सलाहकार के FAST में उत्पाद प्रबंधक कैसे कार्य करते हैं? FAST में उत्पाद की भूमिका अधिकतर प्राथमिकताओं को प्राथमिकता देना और संप्रेषित करना है। इसके बाहर के काम के बारे में बहुत कुछ ऐसा है जिसका वास्तव में FAST मैनुअल में वर्णन नहीं किया गया है। फास्ट मैनुअल में धारणा यह प्रतीत होती है कि उत्पाद प्रबंधक प्रेरित करते हैं और संवाद करते हैं, और फिर इंजीनियर सुविधाओं पर काम करते हैं। जिस हद तक आप कर सकते हैं, मैं इंजीनियरों को ग्राहकों से बात करवाऊंगा, और उन्हें उस उत्पाद क्षेत्र में विशेषज्ञता हासिल करवाऊंगा जिसमें वे काम कर रहे हैं। आदर्श रूप से, वे काम करेंगे, ग्राहकों को इसका डेमो देंगे और उनसे इस पर प्रतिक्रिया प्राप्त करेंगे। . उत्पाद प्रबंधकों द्वारा इसे सुविधाजनक बनाना, और इसे प्रभावी ढंग से करने के लिए इंजीनियरों की क्षमता को बढ़ाना, उनके काम का एक मूल्यवान हिस्सा हो सकता है। इस मॉडल में काफी लचीलापन है. आप विशिष्ट उत्पाद-से-इंजीनियरिंग हैंडऑफ़ कर सकते हैं, या आप उन्हें ग्राहकों के साथ मिलकर स्थान की खोज और समस्या-समाधान करवा सकते हैं। तो जैसा कि आप देख सकते हैं, FAST में कई कमियाँ हैं। आपको बाकी समस्याओं का समाधान करना होगा। फास्ट सामग्रियां शब्दजाल से भरी हैं आपको FAST वेबसाइट और मैनुअल भ्रामक लग सकते हैं। फास्ट एजाइल का स्वर्ण पाने के लिए आपको बहुत सारे शब्दजाल और कष्टप्रद शब्दावली से गुजरना होगा। उदाहरण के तौर पर, यहां फास्ट एजाइल की भयानक परिभाषा दी गई है जो में अभ्यास को परिभाषित करने का प्रयास करती है: फास्ट गाइड के संस्करण 2.12 “द्रव स्केलिंग प्रौद्योगिकी क्या है? फ्लुइड स्केलिंग टेक्नोलॉजी ओपन स्पेस टेक्नोलॉजी और ओपन एलोकेशन को मिलाकर लोगों को काम के आसपास व्यवस्थित करने के लिए एक हल्का, समझने में आसान और मास्टर करने में आसान तरीका बनाती है - जो कि स्केल है। FAST फ्लूइड स्केलिंग टेक्नोलॉजी का संक्षिप्त रूप है। एजाइल के लिए फ्लूइड स्केलिंग टेक्नोलॉजी फास्ट एजाइल है। इसलिए। खराब। और यह बहुत प्रतिनिधि है. आपको कलेक्टिव्स, वैल्यू साइकल, ओपन टेक्नोलॉजी, टील ट्रांसफॉर्मेशन, थ्योरी वाई आदि के बहुत सारे संदर्भ दिखाई देंगे। यह सब बिना किसी स्पष्टीकरण के प्रस्तुत किया गया है, और वास्तव में अगर इसे समझाया भी गया तो यह मददगार नहीं होगा। वे चुस्त सिद्धांतकारों के विशिष्ट दर्शकों से बात कर रहे हैं, और उपयोगिता के बजाय श्रेय पर ध्यान केंद्रित कर रहे हैं। निष्कर्ष तो वह हमें कहां छोड़ता है? क्या FAST एजाइल प्रयोग करने लायक है? मेरा मानना है कि इसका उत्तर हां है, लेकिन सावधानी के साथ और सही संदर्भों में। आप अलग-अलग टीमों में इसके साथ खेल सकते हैं। और यदि आपके पास नेतृत्व का समर्थन है, तो बड़े संगठनों में धीरे-धीरे इसका प्रयोग करें। यदि आप इसके साथ प्रयोग करते हैं तो कृपया मेरे साथ साझा करें। और यदि आप इसे अपने संगठन में लागू करने में सहायता चाहते हैं, तो मुझसे संपर्क करें। मैं या तो सीधे आपकी मदद करूंगा, या आपको अन्य लोगों से जोड़ूंगा जो मदद कर सकते हैं। धन्यवाद इस पोस्ट के शुरुआती संस्करण... सचमुच ख़राब थे। मैं और उनकी आलोचना के लिए धन्यवाद देना चाहता हूं। उन दोनों ने पोस्ट में कुछ प्रमुख समस्याओं की ओर इशारा किया जिसने मुझे वापस लौटने और अपने दृष्टिकोण पर पुनर्विचार करने के लिए मजबूर किया। और उन्होंने कुछ उत्कृष्ट बिंदु बनाए जिन्हें मैंने पोस्ट के अपने अनुभागों में शामिल किया। आख़िरकार, मैंने अधिकांश पोस्ट दोबारा लिखी, और परिणाम से मैं बहुत खुश था। धन्यवाद! सेठ के पास है, और डेवी (मेरी तरह) देता है। सेठ फाल्कन डेवी स्टीवेन्सन को इंजीनियरिंग नेतृत्व पर जांचने लायक एक समाचार पत्र स्टार्टअप को सलाह और कोचिंग मुझे फास्ट एजाइल से परिचित कराया। उन्होंने इसके साथ अपने अनुभवों पर कुछ है। और हमने कई बार मुलाकात की है और FAST के निहितार्थों और कार्यान्वयन पर चर्चा की है। जिम के लेखक हैं। जिम शोर ने उत्कृष्ट बातचीत की द आर्ट ऑफ एजाइल डेवलपमेंट से द्वारा छवि पिक्साबे कनेनोरी फुटनोट मेरा मानना है कि एक सामूहिकता के लिए 150 लोग संभवतः बोझिल हैं। मुझे संदेह है कि साठ लोग एक बेहतर अधिकतम आकार है। भी प्रकाशित किया गया है. यहाँ
