क्या एक टीम में 150 लोग हो सकते हैं? फास्ट एजाइल हाँ कहता है

फास्ट एजाइल सबसे दिलचस्प संगठनात्मक अभ्यास है जिसके बारे में मैंने कुछ समय में सीखा है। आज मैं साझा करता हूं कि फास्ट एजाइल क्या है, और पता लगाता हूं कि क्या यह प्रयोग करने लायक है। टीएल;डीआर? काफी सम्मोहक, लेकिन फिर भी प्रयोगात्मक।

फास्ट एजाइल क्या है?

1. फास्ट एजाइल एक एजाइल सॉफ्टवेयर संस्करण है। FAST बहुत बड़ी टीमों के भीतर स्व-संगठन पर ध्यान केंद्रित करता है। इन बड़ी टीमों को कलेक्टिव कहा जाता है। वे कुछ लोग से लेकर 150 लोग तक हो सकते हैं [1]।

सप्ताह में दो बार सामूहिक बैठक होती है। बैठक में हु:

• टीम के सदस्य दिखाते हैं और बताते हैं कि उन्होंने क्या प्रगति की है ।
• उत्पाद नेता दृष्टिकोण को दोहराता है और दिशा निर्धारित करता है । वे शीर्ष परियोजनाओं पर संदर्भ देते हैं। जैसे-जैसे काम पूरा होता है, या प्राथमिकताएँ बदलती हैं, वे नई प्राथमिकताएँ पेश करते हैं। और आम तौर पर वे प्राथमिकताओं को दृश्य तरीके से, दीवार पर या आभासी समकक्ष पर दिखाते हैं।
• सामूहिक के भीतर के लोग सर्वोच्च प्राथमिकता वाले कार्य को पूरा करने के लिए छोटी टीमों में स्वयं-संगठित और स्वयं-चयन करते हैं।

फास्ट एजाइल का सबसे दिलचस्प हिस्सा ये स्व-संगठित टीमें हैं, तो आइए इनका थोड़ा और विस्तार से वर्णन करें।

प्रत्येक बैठक में, लोग स्वेच्छा से टीमों का नेतृत्व करते हैं, और लोग स्वेच्छा से उन टीमों में भाग लेते हैं। जब कोई स्वेच्छा से किसी टीम का नेतृत्व करता है, तो वे आगे बढ़ते हैं और कहते हैं, "मैं [शीर्ष परियोजनाओं में से एक] पर काम करने जा रहा हूं"। फिर लोग बनाई गई टीमों में शामिल हो जाते हैं और उस क्षेत्र में काम करते हैं। न्यूनतम टीम का आकार दो है, इसलिए टीम बनाने के लिए आपको लोगों को "अपने पैरों से वोट देने" की आवश्यकता है।

गठित टीमें करती हैं नहीं उत्पाद द्वारा निर्धारित प्राथमिकताओं के आसपास रहना होगा। उदाहरण के लिए, तैनाती पाइपलाइन में सुधार, या कुछ कमजोर सेवाओं के लिए निगरानी में सुधार के लिए एक टीम बनाई जा सकती है।

बैठकों में सप्ताह में एक घंटे के अलावा, लोग अपना अधिकांश समय अपनी स्व-चयनित, स्व-संगठित टीमों में बिताते हैं। सैद्धांतिक रूप से, आप सप्ताह में दो बार टीम बदल सकते हैं। लेकिन व्यवहार में, लोगों को यह पता चल जाता है कि उन्हें किसके साथ काम करना पसंद है, और टीमें पहले महीने या उसके बाद व्यवस्थित हो जाती हैं।

वे इतने तरल रहते हैं कि लोग व्यवसाय की ज़रूरतों में बदलाव के अनुसार स्थानांतरित हो सकते हैं, या विभिन्न क्षेत्रों में विशेषज्ञता वाले लोगों की आवश्यकता होती है। टीमों को स्थानांतरित करना एक अपेक्षित, कम प्रयास वाला बदलाव है। तो इसका मतलब यह है कि सामूहिक बैठकों के दौरान, लोगों द्वारा अपनी टीमों को फिर से बनाने का एक पैटर्न होता है, लेकिन संरचना उतनी नहीं बदलती जितनी आप कल्पना कर सकते हैं।

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

मतभेदों का सारांश

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 के निहितार्थों और कार्यान्वयन पर चर्चा की है। जिम द आर्ट ऑफ एजाइल डेवलपमेंट के लेखक हैं।

पिक्साबे से कनेनोरी द्वारा छवि

फुटनोट

1. मेरा मानना है कि एक सामूहिकता के लिए 150 लोग संभवतः बोझिल हैं। मुझे संदेह है कि साठ लोग एक बेहतर अधिकतम आकार है।