👨🏿‍🎨 🚴🏼 👨🏼‍✈️ क्या आउटसोर्सिंग में स्क्रैम का उपयोग किया जा सकता है? 👩🏿‍🤝‍👨🏽 📿 ♑️

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

मुसीबत

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

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

समस्या का समाधान

चरण 1. अपनी सेवाओं को बेचने के लिए कुछ झरने से शुरू करें।

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

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

(!) इस कदम का मतलब सीधे बिक्री नहीं है, यह केवल "धन से" और "शब्दों में" से "सशर्त" निर्धारित करने के बारे में है।

चरण 2. हुर्रे! हमने प्रोजेक्ट लिया, हम स्क्रैम पर काम शुरू करते हैं (इसकी छवि और समानता में)

प्रोजेक्ट लिया है। ऐसा लगता है कि सभी समय सीमाएं हैं। कार्य स्पष्ट है, ठीक है, करने के लिए चला गया। चेतावनी! इतनी जल्दी मत करो। जब आप पहली बार परियोजना का मूल्यांकन करते हैं, तब से सबसे अधिक संभावना है कि कई चीजें बदल गई हैं। उदाहरण के लिए, ग्राहक से नई विशलिस्ट को डिज़ाइन या उड़ान भर सकते हैं।

मेरे पास एक सुझाव है। घोटाले की कोशिश करो। उत्पाद के बैकलॉग से, स्प्रिंट बैकलॉग, दूल्हे का चयन करें। अपने स्प्रिंट की सावधानीपूर्वक योजना बनाएं और देखें कि टीम इसे कैसे संभालती है। "डेवलपर ने कल क्या किया / वह आज क्या करता है" प्रारूप में दैनिक जांच करें। और स्प्रिंट के अंत में रेट्रो, प्रत्येक की सफलता और समग्र रूप से टीम की सफलताओं को संक्षेप में प्रस्तुत करना। आप जल्दी से नोटिस करेंगे कि प्रत्येक डेवलपर का KPI स्प्रिंट से स्प्रिंट तक कैसे बढ़ता है, क्यूए से रिटर्न की संख्या कैसे घटती है और उत्पाद का बैकलॉग कैसे घटता है।

पुनश्च नए ग्राहक की इच्छा से इंकार करने के लिए जल्दी मत करो। हो सकता है कि उन्हें समझ में आए और उन्हें कुछ अन्य कार्यक्षमता के बजाय उत्पाद बैकलॉग में सुरक्षित रूप से दर्ज किया जा सके, जो अब आपके ग्राहक के व्यवसाय (और, तदनुसार, स्वयं ग्राहक) की आवश्यकता नहीं है।

चरण 2.1 उत्पाद के मालिक को प्रोजेक्ट से परिचित कराएं

अधिक बार नहीं, आउटसोर्सिंग कंपनियों में केवल एक परियोजना प्रबंधक होता है। स्क्रैम मास्टर्स और उत्पाद मालिकों में विभाजित किए बिना, लेकिन यह इतनी बड़ी समस्या नहीं है क्योंकि यह पहली नज़र में लगता है।

उदाहरण के लिए, मेरे पास परियोजना पर एक शांत परीक्षक है, जिसके लिए मैंने उत्पाद स्वामी की जिम्मेदारियों का 90% (शेष 10% वही है जो ग्राहक से आता है, और मैं इसे पहले ही अपने सहयोगी को दे देता हूं)। इस तथ्य के अलावा कि वह परीक्षण में लगा हुआ है (और वह इसे पूरी तरह से करता है), वह बैकलॉग को बनाए रखता है और उसकी भरपाई भी करता है, एक डॉक लिखता है, प्रवाह और इकाई तालिका बनाता है: वह एक महान काम करता है (अपने कोर के प्रतिवाद नहीं), जिसके लिए मेरे पास बस समय नहीं है। अन्य परियोजनाओं पर रोजगार के कारण।

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

पीएस नाउ मैं ऐसे मॉडल पर काम करता हूं जो मेरी सभी परियोजनाओं पर नहीं है। कहीं, एक घोटाले की जरूरत नहीं है, क्योंकि यह जटिल है। ये मुख्य रूप से एक महीने या उससे कम की अवधि के लिए छोटी परियोजनाएं हैं।

चरण २.२ घड़ी की रेटिंग को कहानी के बिंदुओं में बदलें

सबसे महत्वपूर्ण कदम नहीं, आप इसके बिना काम कर सकते हैं, लेकिन अधिक कठिन। तथ्य यह है कि जब आप घंटों में कार्य का मूल्यांकन करते हैं, तो घड़ी सभी के लिए अलग-अलग होती है, किसी को डोमेन इकाई (सशर्त कार्य) बनाने के लिए 6 घंटे लगते हैं, किसी के पास 7 हैं, किसी के पास 8. कहानी बिंदुओं में हर किसी के पास एक ही होगा। 8.

कहानी बिंदुओं के अनुसार, प्रत्येक डेवलपर के KPI की गणना करना, एक प्रदर्शन समीक्षा संकलित करना और परियोजना की सफलता को सामान्य रूप से ट्रैक करना अधिक सुविधाजनक होगा।

प्रति दिन 8 (एमबी 5 के लिए डेवलपर्स) कहानी बिंदुओं के साथ डेवलपर्स की व्यवस्था करें, इसके आधार पर योजना बनाएं और देखें कि कैसे कार्य बंद हैं और परियोजना को लागू किया जा रहा है।

यदि कोई डेवलपर अचानक 8 स्टोरी पॉइंट्स को 4 घंटे में बंद कर देता है (फिबोनाची संख्याओं के अनुसार 5 स्टोरी पॉइंट्स), तो उसे नए हैंडल के साथ लोड न करें। अपने समझौते की सराहना करें, उसके काम का सम्मान करें। उसके शेष "मुक्त" समय का हिस्सा अभी भी अगली सुविधा का अध्ययन करने, और कल की तैयारी, और स्वयं के विकास या आंशिक रूप से अवकाश पर खर्च किया जाएगा। अच्छा आराम भी अच्छा काम करने के लिए प्रेरित करता है।

चरण 3. काम कूल

सब कुछ जैसा कि लिखित गाइड या किसी अन्य pm-standardizers में नहीं करें। लचीले ढंग से निर्णय लें, और स्थिति पर निर्माण करें। विभिन्न फ्रेमवर्क द्वारा दिए गए टूल का ध्यानपूर्वक चयन करें और एक नया प्रयास करने में संकोच न करें।

परियोजनाओं को सफलतापूर्वक प्रबंधित करने के लिए जलप्रपात या घोटाले पर काम करने की आवश्यकता नहीं है। शांत होकर काम करने की जरूरत है। बस इतना ही।

निष्कर्ष

स्क्रम का उपयोग किया जा सकता है, और यह बहुत उपयोगी होगा: एक उत्कृष्ट ढांचा जो लगातार अप टू डेट होने के लिए कूल टूल्स का एक गुच्छा प्रदान करता है, अपने आप को विकसित करने और टीम के विकास के लिए आधार प्रदान करने, परियोजना की प्रगति की निगरानी करने और अपनी टीम के KPI सदस्यों पर विचार करने के लिए।

फिर भी, घबराहट एक रामबाण नहीं है, और उदाहरण के लिए, ग्राहक को यह कहना कि हम शुरू में यह नहीं जानते हैं कि परियोजना आपको कितना प्राप्त करेगी और आउटसोर्स विकास के संदर्भ में कितना समय लगेगा, असफल होने की सबसे अधिक संभावना है। यह सभी झरने के तत्वों के बिना समान है।

फ्रेमवर्क को संयोजित करने और उन उपकरणों का उपयोग करने के लिए स्वतंत्र महसूस करें, जिन्हें आप और आपकी टीम पसंद करती है, भले ही वे घोटाले करने वाले न हों। इसे आसानी से काम करें, क्योंकि यह प्रत्येक रूपरेखा का मुख्य लक्ष्य है। और उसे कैसे बुलाना है यह आप पर निर्भर है।

पुनश्च मैं यह एचएमएस है - आनुवंशिक रूप से संशोधित घोटाले।

क्या आउटसोर्सिंग में स्क्रैम का उपयोग किया जा सकता है?