SCRUM इतना लोकप्रिय हो गया है कि अब वे इसे लगभग हर जगह लागू करने की कोशिश कर रहे हैं। बड़ी कंपनियों में, कभी-कभी यह पता चलता है कि SCRUM रिपोर्टिंग के लिए, या "प्रगतिशील" और "फैशनेबल" होने के लिए लागू किया गया है। नतीजतन, स्थिति, जो एक जिम्मेदार प्रबंधक की तरह प्रतीत होती है, अगले चेक मार्क को सेट करते हैं, वे कहते हैं, कार्यप्रणाली को लागू करना आवश्यक था - कार्यान्वित, अच्छी तरह से किया गया, लेकिन कुछ गुणात्मक सुधारों के बजाय, आउटपुट पर तथाकथित "ज़ोंबी एससीआरयूएम" दिखाई देता है। यह तब होता है जब रूपरेखा औपचारिक रूप से लागू की जाती है, लेकिन कोई भी सामान्य रूप से इस पर काम नहीं करता है। इसलिए नाम।
मेरा नाम ओलेग एगोरकिन है, मैं रोस्टेलकॉम में एक चुस्त कोच हूं, और इस पोस्ट में मैं बताऊंगा कि "जॉम्बी स्क्रैम" सामान्य रूप से क्यों उत्पन्न होता है, इससे कैसे बचा जाए और यह कैसे सुनिश्चित किया जाए कि कंपनी के लिए एक स्क्रम टीम लॉन्च करने के लिए सब कुछ तैयार है।
मौजूदा कमांडिंग रनिंग कमांड्स के लिए
कभी-कभी वे आईटी में एक स्क्रैम टीम लॉन्च करने की कोशिश करते हैं, यानी नीचे से ऊपर तक। यह तब है जब डेवलपर्स स्वयं और विभागों के प्रमुख समझते हैं कि यह समय है, इस उत्पाद के लिए हमें एक निशान की आवश्यकता है। प्लस यह है कि पहल विषय में लोगों से आती है। माइनस - इस दृष्टिकोण के साथ, व्यवसाय शामिल नहीं है। और यदि व्यवसाय शामिल नहीं है, तो इस दृष्टिकोण के साथ संगठनात्मक संरचना या तो बहुत कम बदलती है, या (अधिक बार) बिल्कुल भी नहीं बदलती है। नतीजतन, इस तरह के एक घोटाले "ज़ोंबी स्क्रैम" बनने की संभावना बहुत अधिक है। बेशक, यह ऐसा नहीं होगा कि पहले दिन सब कुछ गलत हो जाएगा जैसा कि एक व्यक्ति चाहेगा। लेकिन लगभग छह महीनों के बाद, लोगों को एहसास होगा कि स्टार्टअप पर आने वाले सभी मंत्रालय कहीं नहीं गए थे। इसलिए हताशा जो हमेशा उत्पाद को प्रभावित करती है।
एक उलटी कहानी है- ऊपर से नीचे तक। इसके लिए प्रयास करने की चीज भी नहीं। एक उदाहरण के रूप में, याद रखें, कई साल पहले, एजाइल की भोर में, उच्च अधिकारियों के निर्देश पर "गर्मियों में", और वर्ष के अंत तक 50 नई टीमों को एक ग्रीन बैंक में लॉन्च किया गया था। 5000 - यह बहुत ही घबराहट के लिए घोटाले के लिए दृष्टिकोण है। इस मामले में क्या होता है? लोग दौड़ने के लिए दौड़ते हैं। स्क्रीन के नीचे, जो कुछ भी खराब नहीं है वह पंक्ति में शुरू होता है। इस कहानी में स्क्रैम कभी भी एक विकास सुधार और नई पद्धति नहीं है, यह प्रबंधक के KPI में एक टिक है। परिणाम एक "ज़ोंबी घोटाले" है।
और एक तीसरा दृष्टिकोण है - पहल ऊपर और नीचे कोडबद्ध रूप से। हम भाग्यशाली थे, और रोस्टेलकॉम में अभी। किस चीज में। शीर्ष प्रबंधन स्तर पर, टीमों में सभी परिवर्तनकारी दृष्टिकोणों के लिए निरंतर सहायता है। इसी समय, कोई भी "महत्वाकांक्षी" योजना नहीं बनाता है।
बड़ी और बहुत बड़ी कंपनियों के लिए, यह पूरी तरह से परिचित नहीं है। यह कुछ इस तरह काम करता है: महीने में एक बार मैं एजाइल पर एक दिवसीय बुनियादी प्रशिक्षण देता हूं। आईटी कर्मचारी और व्यवसाय के लोग दोनों प्रशिक्षण के लिए आते हैं, समूह में 25 लोग। मैं इसके बारे में यथासंभव और व्यापक रूप से बात करने की कोशिश करता हूं। कुछ समय बाद (इसमें एक सप्ताह से लेकर कई महीनों तक का समय लग सकता है), सहकर्मियों ने प्राप्त ज्ञान को पचाते हुए, एक अच्छी टीम बनाने के लिए समझने योग्य अनुरोध के साथ वापस आते हैं।
चेकलिस्ट के बारे में
मेरे लिए दो प्रकार के अनुरोध हैं - या तो एक मौजूदा उत्पाद के परिवर्तन के हिस्से के रूप में एक टीम लॉन्च करने के लिए, या एक नए उत्पाद के लिए एक टीम के लिए। इन अनुरोधों को संसाधित करने के लिए, मैंने एक विशेष चेकलिस्ट लिखी, जिसकी मदद से मैं चलाने के लिए आवश्यक सभी शर्तों की जांच करता हूं। यदि आवेदन किसी एक बिंदु से नहीं जाता है और प्रारंभिक आवश्यकताओं को पूरा नहीं करता है, तो हम टीम नहीं चलाते हैं। यह एक मान्यता प्राप्त आवश्यकता है - यदि आप कम से कम एक अंक स्कोर करते हैं और इसके बिना टीम चलाते हैं, तो भी यह परिणाम नहीं लाएगा। इस तथ्य के अलावा कि कमजोर सभी प्रतिभागियों को नहीं गिराता है।
यदि आईटी का कोई व्यक्ति मेरे पास कोई एप्लिकेशन लेकर आता है, तो मैं उसे व्यवसाय से बात करने और एक साथ वापस आने के लिए कहता हूं। चूँकि Agile में व्यवसाय एक प्रमुख घटक है। यहाँ से हमारे पास पहला चेकलिस्ट आइटम है:
1. फुर्तीली टीम को एक व्यवसाय बनाना चाहिए
यहाँ, जैसा कि पिशाचों के साथ होता है - वे सिर्फ घर में प्रवेश नहीं कर सकते, उन्हें आमंत्रित किया जाना चाहिए। एजाइल कोचों के साथ, एक ही बात, इस अर्थ में कि परिवर्तन का अनुरोध किया जाना चाहिए।
व्यवसाय से और आईटी से लोग यह नोटिस करते हैं कि कुछ उत्पाद मुश्किल बाजार की स्थितियों में काम करते हैं, वे खुद मुझसे संपर्क करते हैं और कहते हैं - दृष्टिकोण को बदलना होगा। और यहां, यदि आप बहुत भाग्यशाली हैं, तो अनुरोध बिल्कुल शुरुआत में आता है, जब अभी तक कोई टीम नहीं है, लेकिन एक विचार है जिसके तहत लोग इकट्ठा करना शुरू कर सकते हैं। इसी समय, हर कोई समझता है कि उत्पाद के लिए एक स्पष्ट विनिर्देश नहीं बनाया जा सकता है, यह व्यवसाय मॉडल के आधार पर बदल जाएगा, और यह स्पष्ट नहीं है कि कौन सा मॉडल काम करेगा और कौन सा नहीं।
सामान्य तौर पर, यह बहुत महत्वपूर्ण है कि व्यवसाय शामिल हो।
यह भी महत्वपूर्ण है कि इस भागीदारी का चालक कुछ ठोस होना चाहिए, न कि केवल प्रचार। इसलिए, मैं जाँच करता हूँ कि व्यवसाय के उद्देश्य मोटे तौर पर निम्नलिखित में आते हैं:
- यदि यह संकेतक बहुत बड़ा है तो बाजार में समय कम करें;
- टीम की कार्य क्षमता में वृद्धि;
- बदलती प्राथमिकताओं के सामने प्रबंधन क्षमता बढ़ाना।
यदि इन तीन बिंदुओं में से कोई भी है, तो सब कुछ ठीक है, यह एक निश्चित संकेत है कि टीम पर्याप्त उम्मीदों के साथ शुरू होती है।
2. लॉन्च के लिए एक उत्पाद होना चाहिए
सबसे पहले, यह तर्कसंगत है। जब आपके पास उत्पाद नहीं है, तो उत्पाद के लिए उत्पाद टीम चलाना मूर्खतापूर्ण है। और इससे कोई फर्क नहीं पड़ता कि हम सभी इसके आसपास क्या करना शुरू करते हैं - किसी उत्पाद या सेवा के आसपास।
3. उत्पाद के मालिक के पास विकास के लिए एक विजन और रोडमैप होना चाहिए
इसके अलावा, अग्रिम में एक साल के लिए रोडमैप एक न्यूनतम है, जो कि आम तौर पर किए जाने की उच्चतम स्तर की समझ के रूप में होता है। यहां तक कि अगर किसी व्यक्ति के पास 3-5 परिकल्पनाएं हैं कि वह किस व्यावसायिक मॉडल को लागू करेगा, तो वह क्या पता लगाना चाहता है। अगर मैं देखूं कि कोई रोडमैप है, तो जारी रखें।
4. व्यापार में पैसा होना चाहिए
अर्थात्, एक क्रॉस-फ़ंक्शनल टीम के लिए बजट। क्योंकि उत्पाद को पूर्णकालिक टीम के लिए काम पर रखा जाना चाहिए, और व्यवसाय को लगभग एक साल पहले क्षितिज में इसके लिए भुगतान करने के लिए तैयार होना चाहिए। मैं यह सुनिश्चित करता हूं कि यह सब किया जाता है, मैं देखता हूं कि कौन सा वित्तीय जिम्मेदारी केंद्र इसमें शामिल है, ताकि यह काम न करे कि एक विचार है, एक टीम लॉन्च करने की इच्छा है, लेकिन कोई पैसा नहीं है।
5. व्यवसाय में उत्पाद का मालिक होना चाहिए
मालिक। मालिक नहीं। एक मालिक।
एक व्यक्ति जो इस विशेष उत्पाद के लिए 100% समर्पित है। एक मामला था जब दो प्रबंधकों ने आकर कहा - हम एक प्रेरक और शैक्षिक उत्पाद बनाना चाहते हैं (कर्मचारियों के लिए ऐसी आंतरिक बात)। मैं उन्हें बताता हूं - महान, लेकिन क्या आपके पास उत्पाद का मालिक है? वे जवाब देते हैं - हां, ज़ाहिर है, उत्पाद का एक मालिक प्रशिक्षण के लिए है, और दूसरा - प्रेरणा के लिए। उत्पाद प्रेरक और शैक्षिक है।
उस समय मैंने सोचने और सहमत होने के लिए कहा कि पूरे उत्पाद के लिए कौन जिम्मेदार होगा। यह एक बहुत कठिन मामला था और टीम केवल छह महीने बाद लॉन्च होने में कामयाब रही।
एक उत्पाद - एक उत्पाद का मालिक। यह महत्वपूर्ण है।
6. विकास टीम में सभी प्रतिभागियों को उत्पाद के लिए 100% आवंटित किया जाना चाहिए।
यदि विकास दल का कोई व्यक्ति 50%, 30%, 10% पर काम करता है - तो यह अभी ठीक नहीं है। एक उत्पाद में पूरी तरह से होना चाहिए। लेकिन एक ही समय में, मुझे सह-स्थित टीमों की उपस्थिति की आवश्यकता नहीं है। हमारी स्थितियों में, यह एक ऐसी दुर्लभता है, रोस्टेलकॉम बहुत बड़ी है, हमारे पास कई सहायक और सहयोगी (सहायक सहयोगी) हैं, जहां डेवलपर्स टीमों में काम करते हैं। और उन्हें मॉस्को, पीटर, क्रास्नोडार और हमारी विशाल मातृभूमि के अन्य शहरों में फैलाया जा सकता है। मॉस्को में एक टीम को जल्दी से इकट्ठा करने में कभी-कभी मुश्किल और समय लगता है, लेकिन अक्सर यह बिल्कुल काम नहीं करता है।
इसलिए, मैं आगे बढ़ता हूं, लेकिन एक काउंटर आवश्यकता है - कि टीम पहले 2 दिनों के लिए एक साथ हो जब प्रशिक्षण प्रगति पर है, और फिर व्यक्तिगत संपर्कों को बनाए रखने और वर्तमान मुद्दों पर चर्चा करने के लिए हर छह महीने में।
7. उत्पाद भुगतान विधि
यह भी एक महत्वपूर्ण बात है, साथ ही बहुत कुछ जो पैसे से जुड़ा है। जब उत्पाद के मालिक के पास बजट होता है, तो यह अनुरोध पर खर्च किया जाता है। अर्थात्, टीके ऑर्डर पर लिखा गया है, इसके कार्यान्वयन के लिए एक मूल्यांकन किया जाता है, और फिर इस मामले के लिए बजट में धन आवंटित किया जाता है। यह आसान लगता है। लेकिन बारीकियां हैं।
जब आप कस्टम काम पर स्विच करते हैं, तो आदेशों के निष्पादन के अंत में उत्पाद को संचालन के लिए स्वीकार करने और स्थानांतरित करने की प्रक्रियाएं होनी चाहिए। और चूंकि टीके को पहले ही मंजूरी दी जा चुकी है, इसलिए इसमें बदलाव करना बेहद मुश्किल है। किसी भी संपादन को पुनः स्वीकृत, अनुमोदित किया जाना चाहिए। यह एक बहुत ही जटिल और धीमी प्रक्रिया है, जो परिवर्तनों की त्वरित प्रतिक्रिया के साथ असंगत है।
हमने ऐसा क्या किया है कि इसमें खुद को दफन नहीं करना है और पागल नहीं होना है।
जब अनुबंध समाप्त हो जाता है और पूरी टीम के समय का भुगतान किया जाता है तो आप समय और सामग्री पर काम कर सकते हैं। यही है, एक टीम है जो उत्पाद के मालिक के लिए काम करती है। उसकी सेवाओं का मासिक या त्रैमासिक भुगतान किया जाता है। लेकिन हमारे देश में यह अपने शुद्ध रूप में नहीं किया जा सकता है, क्योंकि नौकरशाही प्रतिबंध हैं।
इसलिए, हमने रोडमैप (टीके नहीं) को ठीक करने के साथ तिमाही आदेशों के स्तर पर कस्टम विकास के हिस्से के रूप में काम करना शुरू किया, जबकि आदेश में यह विस्तार नहीं है कि रोडमैप कैसे लागू किया जाएगा। उत्पाद के मालिक के पास बैकलॉग पीढ़ी का लचीलापन है। और जब तिमाही समाप्त होती है, हम आहार से किए गए कार्यों की एक सूची को अनलोड करते हैं और इसके आधार पर हम ऐसे कार्य करते हैं जो हस्ताक्षरित और भुगतान किए जाते हैं। यह वही Time & Material निकलता है।
और यहां टीके का स्पष्ट रूप से पालन करना आवश्यक नहीं है, क्योंकि टीके नहीं है। आवश्यकताएँ जो अब परिकल्पना के परीक्षण के बाद समझ में नहीं आती हैं, बस नहीं बनाई जा सकतीं।
8. उत्पाद से जुड़े लोगों को छोड़कर टीम के पास कोई केपीआई नहीं होना चाहिए
यह महत्वपूर्ण रूप से ठीक है क्योंकि डेवलपर्स को सहायक कंपनियों द्वारा काम पर रखा जाता है, जहां केपीआई को रीसाइक्लिंग के लिए स्थापित करने के लिए उपयोग किया जाता है (यह तब होता है जब डेवलपर को लगातार कुछ के साथ व्यस्त होना चाहिए)। वास्तव में, लगभग सभी इंटीग्रेटर इस तरह से काम करते हैं - एक ही डेवलपर की एक परियोजना (या प्रतिस्पर्धी परियोजनाओं) की कमी की स्थितियों में, वे कई परियोजनाओं पर पेंट करते हैं। और फिर, कंपनी के काले रंग में होने के लिए, उन्होंने डेवलपर को KPI में रखा कि वह हमेशा कम से कम 85% व्यस्त होना चाहिए। यही है, उसके पास वास्तव में एक निश्चित KPI है, जो उसे आवश्यक संख्याओं के लिए अपने निपटान को दर्जी करने के लिए अधिकतम परियोजनाओं में फिट होने के लिए प्रेरित करता है।
सौभाग्य से, स्कोर टीम को ऐसी कोई आवश्यकता नहीं है (वास्तव में यह 100% है)। मैं यह सुनिश्चित करता हूं कि टीमों में किराने के अलावा अन्य केपीआई नहीं हैं।
कुल मिलाकर
यह मेरी चेकलिस्ट है। इसके अनुसार, मैं शुरू करने से पहले सभी टीमों की जांच करता हूं, और चूंकि हमारे पास एक सह-दिशात्मक दृष्टिकोण है, मैं शर्तों में बदलाव की मांग कर सकता हूं अगर टीम इनमें से कम से कम एक अंक से नहीं गुजरती है। इसलिए, आउटपुट केवल उन टीमों को है जो चुस्त दृष्टिकोण के मूल्यों को लागू करने के लिए तैयार हैं।
यदि टीम के लिए आवेदन इन सभी बिंदुओं से गुजरता है, तो अगला चरण शुरू होता है - टीम को प्रशिक्षण और लॉन्च करना।
जिसके बारे में मैं अगले पोस्ट में बात करूंगा =)