अद्यतन रिपोर्ट: बेसकैंप की 'शेप अप' पद्धति का परीक्षण

पिछले साल, मैंने अपनी उत्पाद टीम को क्लासिक SCRUM दृष्टिकोण से बेसकैंप की शेप अप पद्धति में स्थानांतरित करने का प्रयास किया। वह एक अविश्वसनीय अनुभव था; मैंने इससे बहुत कुछ सीखा है और सोचा कि मैं अपने कुछ निष्कर्ष आपके साथ साझा करूँ।

यदि आपने स्वयं इसका प्रयोग किया है, तो मुझे यह सुनना अच्छा लगेगा कि यह कैसा रहा। यदि आपने नहीं किया है, तो मुझे यह सुनना अच्छा लगेगा कि आप दूर क्यों रहे।

भाग 1: आकार क्यों बढ़ाएं?

मेरी टीम हमेशा से SCRUM पर चल रही थी। हमारे स्टार्टअप दिनों के दौरान, हम क्लासिक तकनीकी चक्रों को जी रहे थे: तेजी से काम करना, जहाज चलाना, और प्रक्रियाओं के बारे में बहुत अधिक नहीं सोचना। फिर, हम अधिग्रहित हो गए।

एक बार जब मेरे पास हमारे उत्पाद पद्धति विकल्पों पर विचार करने के लिए थोड़ा और समय हो गया, तो मैंने शेप अप को आज़माने का फैसला किया। इसके कुछ कारण थे:

1. तब तक, हम 2-सप्ताह की दौड़ का प्रयास कर रहे थे और उन्हें पूरा करने में लगातार असफल हो रहे थे। हर सप्ताह ऐसा महसूस होता था जैसे टिकटों का एक कन्वेयर बेल्ट जिसे हम कभी ख़त्म नहीं करेंगे।

   
   

2. टीम को कोड बंदरों की तरह महसूस हुआ। टिकट उठाओ. कार्य टिकट. टिकट वितरित करें.

   
   

3. क्योंकि हमने कभी भी स्प्रिंट पूरा नहीं किया, कार्य हमेशा अगले तक फैल जाते थे। आख़िरकार बांध टूट जाता है.

   
   

4. हम सभी में फोकस की कमी थी। प्रत्येक स्प्रिंट पूरे कोड बेस पर काम करने के लिए चीजों का चयन और मिश्रण था।

   
   

5. बहुत कम टीम वर्क. प्रत्येक डेवलपर पाई के अपने छोटे से हिस्से पर काम करेगा, जिससे एक-दूसरे से सीखने के लिए बहुत कम जगह बचेगी और, स्पष्ट रूप से, समुदाय की भावना पैदा होगी।

   
   

6. ग्राहक को लगभग कोई समझ नहीं है। देव सौंपे गए टिकट उठाएंगे, उन्हें पूरा करेंगे, और उन्हें कोई सुराग नहीं होगा कि क्यों/कौन/क्या।

दोबारा पढ़ने के बाद बेसकैंप का आकार ऊपर , मैंने सोचा कि मैं इसे आज़माऊंगा क्योंकि इसमें से अधिकांश मुद्दों को हल करने का दावा किया गया है।

भाग 2: आंतरिक रूप से पिचिंग

शेप अप की ओर बढ़ने में सबसे कठिन भागों में से एक विचार को आंतरिक रूप से प्रस्तुत करना था।

यह सुनिश्चित करने के लिए कि मैं किसी भी प्रश्न के लिए तैयार हूं, मैंने शेप अप की अधिकांश अवधारणाओं को आत्मसात करने में अतिरिक्त समय बिताया। आश्चर्य की बात नहीं, डेवलपर्स को इस नए दृष्टिकोण का विचार पसंद आया (अधिक समय, अधिक फोकस, अधिक सहयोग; वे ऐसा क्यों नहीं करेंगे!)।

इसमें कोई आश्चर्य की बात नहीं है कि पदानुक्रम अधिक मितभाषी था। आख़िरकार, मैं उन्हें निम्न तरीकों से समझाने में कामयाब रहा:

1. यह सुनिश्चित करना कि यह सिर्फ एक परीक्षण था। अगर चीजें काम नहीं करतीं, तो हम 'सामान्य' स्थिति में वापस आ जाएंगे।

   
   

2. यह सुनिश्चित करते हुए कि मैं उनकी मदद के लिए हमेशा की तरह उपलब्ध रहूँगा। देव केंद्रित और निर्बाध होंगे, लेकिन मैं नहीं था।

   
   

3. शेप अप को हाइलाइट करने से हम बड़ी समस्याओं को हल कर सकते हैं जिसका अर्थ है बड़े अवसर।

   
   

4. दर्द उत्पाद पर जोर देना वर्तमान में अनुभव कर रहा है और यह प्रत्येक टीम को कैसे प्रभावित करता है।

मैंने एक बहुत ही स्पष्ट स्लाइड डेक तैयार किया और प्रत्येक विभाग प्रमुख (ग्राहक सेवा, बिक्री और सी-सूट) को इसके माध्यम से चलाया।

भाग 3: भय और चिंताएँ

एक संस्थापक, विपणक और उत्पाद प्रबंधक के रूप में मेरे अनुभव ने मुझे सिखाया है कि किसी प्रयोग को शुरू करने से पहले चिंताओं को लिखना हमेशा उचित होता है। मेरे पास शेप अप के साथ कुछ थे:

• हम विकर्षणों से कैसे निपटते हैं? मैं जानता हूं कि मुझे 'नहीं कहना' चाहिए। 'व्यस्त थे।' 'अगले चक्र में, हम उस पर गौर कर सकते हैं।' यही सिद्धांत है, और यह तब काम करता है जब पूरी कंपनी को इस पद्धति में शामिल कर लिया जाए। अपने पहले चक्र परीक्षण के दौरान, मुझे चिंता थी कि कोई आपातकालीन स्थिति सामने आ जाएगी।

• बकाया? शेप अप कोई बैकलॉग न रखने की अनुशंसा करता है (अध्याय 7)। चूँकि हम अभी इसका परीक्षण कर रहे थे, मैं स्पष्ट रूप से नहीं गया और cmd+a+हमारे बैकलॉग को हटा नहीं सका, लेकिन फिर भी। यदि हम इस पद्धति को अपनाते हैं, तो मुझे बैकलॉग के बिना कुछ हद तक खोया हुआ महसूस होगा।

• 'लगभग समाप्त।' इसने मुझे सचमुच डरा दिया। यदि हम 6-सप्ताह के चक्र के अंत तक पहुँचते हैं और हम अस्थायी रूप से वहाँ हैं, लेकिन पूरी तरह से नहीं, तो क्या होगा? बेसकैंप कहता है 'फिर से शुरू करें' (जब तक कि आप बहुत करीब न हों)। मुझे चिंता थी कि हम कष्टप्रद 20-30% सीमा से चूक जायेंगे।

अंततः, इनमें से कोई भी डर/चिंता मुझे मुकदमा जारी रखने से नहीं रोक सकी। हालाँकि, उन्हें ध्यान में रखना उचित था।

भाग 4: चक्र

और हम चले गए!

छह सप्ताह के गहन फोकस और टीम वर्क को देखते हुए, मैंने सोमवार की सुबह पहला चक्र शुरू किया। प्रत्येक सप्ताह क्या हुआ इसका सारांश यहां दिया गया है:

• सप्ताह 1 : आरंभ और... मौन। टीम को छोड़ना, उन्हें शोध करने देना, और अपने समय पर कोड में गोता लगाना, ये सभी इस पद्धति का एक प्रमुख हिस्सा हैं। मेरे लिए उस पहले सप्ताह के दौरान जाने देना और अपडेट न माँगना अविश्वसनीय रूप से कठिन था। मैं मजबूत रहा!

• सप्ताह 2 : टीम अंततः अपने खोल से बाहर आ गई। संचार बढ़ा. काम का डिज़ाइन दिखने लगा, कुछ फीडबैक देने और साथ मिलकर काम करने का मौका मिला।

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

• सप्ताह 4 : फिर से शांत। सप्ताह 3 से आगे-पीछे सभी ने एक केंद्रित सप्ताह 4 का निर्माण किया, क्योंकि सभी ने अपना काम लागू किया। हमने शुक्रवार को 'दिखाओ और बताओ' शुरू किया।

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

• सप्ताह 6 : बचे हुए दायरे अच्छे से ख़त्म हो रहे थे। सप्ताह 6 में तीव्रता काफी बढ़ गई क्योंकि मैं हर जगह क्यूए कर रहा था, और डेवलपर मेरी प्रतिक्रिया पर अविश्वसनीय रूप से तेजी से ध्यान दे रहे थे; हम सभी लक्ष्य तक पहुंचने के लिए एक साथ प्रयास कर रहे थे।

  
  

अंत में, हमने लक्ष्य हासिल कर लिया। हमने इसे बनाया! यह अत्यधिक तीव्र था, और मैं तबाह हो गया था कि हमें एक स्कोप को काटना पड़ा, लेकिन हमने इसे बनाया।

अगले सोमवार सुबह 10 बजे हमने उत्पादन में भेज दिया।

भाग 5: कुछ पाठ

बिना किसी विशेष क्रम के, यहां कुछ सबक और सिफारिशें दी गई हैं:

1. आकार देना कठिन है . मुझे लगा कि मैंने चक्र के अधिकांश डरावने हिस्सों को आकार देने में अच्छा काम किया है। पता चला कि मुझसे कुछ स्पष्ट रूप से चूक हो गई जिससे पूरा चक्र लगभग पटरी से उतर गया।

   
   

2. आकार देने के दौरान अपनी टीम को शामिल करें । मैंने इसे अधिकतर अपने दम पर और कभी-कभी अपनी विकास टीम के नेतृत्व के साथ आकार दिया। अन्य डेवलपर्स को शामिल करना मेरे लिए मूल्यवान होता।

   
   

3. यदि आप स्वयं को चक्र के मध्य में चर्चा करते या आकार देते हुए पाते हैं, तो कुछ गलत हो गया है। सब कुछ बंद करो. आपकी प्राथमिकता उस चीज़ का पता लगाना है, इससे पहले कि वह बाकी सब चीज़ों को पूरी तरह से पटरी से उतार दे।

   
   

4. तीव्रता समान रूप से वितरित नहीं है . चाहे वह टीम के सदस्यों के बीच हो या पूरे चक्र में, कार्य की तीव्रता बहुत भिन्न होगी। प्रधान मंत्री के रूप में, यह आपकी भूमिका है कि आप तीव्रता के इन हिस्सों को पहचानें और उनसे गुज़रने वाले व्यक्तियों पर विशेष ध्यान दें।

   
   

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

   
   

6. पहले सप्ताह से दिखाएं और बताएं बैठकें लागू करें । हमने ऐसा करने के लिए बहुत लंबा इंतजार किया. सप्ताह 1 के अंत से दिखाने या चर्चा करने के लिए पर्याप्त होना चाहिए। यह मिलने, चर्चा करने, सीखने आदि का भी एक अवसर है।

   
   

7. कूलडाउन अवधि चक्र की तुलना में कहीं अधिक कठिन साबित हुई । 6 सप्ताह तक सारे 'अन्य काम' ढेर हो गए थे; ऐसा लगा जैसे मैं सीधे SCRUM पर वापस जा रहा हूँ। यह कुछ ऐसा है जिस पर मैं अभी भी सुधार करने पर काम कर रहा हूं।

जैसा कि आप शायद बता सकते हैं, मुझे इस परीक्षण द्वारा बेच दिया गया था।

शेप अप को लागू करना और इसकी विचित्रताओं को अपनाना निश्चित रूप से कोई रातोरात की बात नहीं है। मुझे संदेह है कि यह सीखने की एक लंबी प्रक्रिया होगी। मैंने विशेष रूप से उस मानसिकता बदलाव की सराहना की है जिससे इस परीक्षण ने हमें अनुमति दी है। मुझे आशा है कि हमने (और अन्य टीमों ने) काम को उसी रूप में देखना सीख लिया है: एक रोमांचक चुनौती जिसे हम साथ मिलकर पार करेंगे।

यदि आपने इसका परीक्षण किया है (या नहीं), तो मुझे कुछ कहानियाँ या प्रतिक्रियाएँ पढ़ना अच्छा लगेगा!

यदि आपको यह पोस्ट अच्छी लगी हो, तो आप मेरे न्यूज़लेटर का भी आनंद ले सकते हैं। मैं उत्पाद प्रबंधन के बारे में लिखता हूं, कार्रवाई योग्य अंतर्दृष्टि साझा करता हूं, और मनोरंजन के लिए वास्तविक जीवन की उत्पाद चुनौतियों का सामना करता हूं (मुझे पता है, है ना?)।