खेल की मदद से टीम लीड की किन समस्याओं को हल किया जा सकता है

सभी को नमस्कार! मेरा नाम येवगेनी Rtischev है, Sbertekh में मैं यूनिफाइड फ्रंटल सिस्टम की परियोजनाओं पर IT सिस्टम डेवलपमेंट के प्रमुख के रूप में काम करता हूं। 24 सितंबर को, मैंने सेंट पीटर्सबर्ग में सेंट टीमलेड कॉन्फ 2018 सम्मेलन में बात की। मेरी रिपोर्ट टीम में आयोजित खेल के बारे में थी, जिसने एक नेता के रूप में मेरे सिरदर्द को कम किया, प्रेरणा और अनुशासन के साथ मदद की। दर्शकों ने बहुत गर्मजोशी से विषय को स्वीकार किया और बहुत सारे रोचक और मूल्यवान प्रश्न पूछे।

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

परिचय

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

समस्याएं और दर्द

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

मैंने नियमित प्रबंधन के तत्वों की शुरूआत में एक रास्ता देखा। यानी पुरस्कार और दंड के लिए पारदर्शी नियमों के साथ एक प्रणाली की आवश्यकता है। उसी समय, मैं वास्तव में सब कुछ कम नहीं करना चाहता था
सामान्य तरीके, जिस पर प्रतिक्रिया हमेशा विपरीत होती है।



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

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

और तब मुझे महसूस हुआ कि मुझे प्रयोग करने की जरूरत है

हम समस्या क्षेत्रों का निर्माण करते हैं

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

टीम के सदस्य रैंकिंग

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

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

उत्पाद विकास सहायता

जब मैं आया, तो कंपनी ने झरना मॉडल के अनुसार काम किया - वास्तव में, बैंक ग्राहक था, और Sberbank-Technologies की टीम आंतरिक ठेकेदार थी। एक साल बाद, कंपनी ने बड़े एजाइल पर स्विच किया - टीमें विकेंद्रीकृत हो गईं, अपने स्वयं के उत्पादों के विकास पर ध्यान केंद्रित किया (जो एक बड़े के सबमॉड्यूल्स हो सकते हैं
प्रणाली)। ऐसी टीम के उत्पाद स्वामी के कंधों पर, रैखिक प्रबंधन और सेवा वास्तुकार (तकनीकी उत्पाद के मामले में) के अलावा, एक नया कार्य भी था - उत्पाद प्रबंधन, अर्थात्। उनकी दृष्टि का गठन, विकास का एक रणनीतिक मानचित्र, कार्यों का विवरण और प्राथमिकता, साथ ही कार्यान्वयन के समय के लिए जिम्मेदारी भी।

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

योजना सटीकता और समय हत्यारा निर्धारण

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

कुछ नया और नया

एक उत्पाद पर और एक ही टीम पर दो साल काम करने के बाद, लोग थकने लगते हैं, उनकी आँखें अपनी चमक और उत्पादकता को कम कर देती हैं।
जिस उपाय का आविष्कार करना था, वह फिर से प्रकाश और थोड़ा प्रकाश करना था
टीम को खुश करें।

टीम के बारे में थोड़ा सा

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



कुछ सामाजिक डेटा: हमारी दो लड़कियां थीं, और प्रतिभागियों की उम्र थी
22 से 33 तक की सीमा। रुचि के क्षेत्र अलग थे, लेकिन हमने व्यवस्था करने की कोशिश की
सामान्य टीम गतिविधियां: नियमित बोर्ड गेम, मिनी-कॉर्पोरेट इवेंट,
सम्मेलनों, आदि के लिए संयुक्त यात्राएं

अब हर कोई MotC का खनन कर रहा है

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

जैसा कि आप समझते हैं, एक बार फिर मैं एक खेल की दुनिया बनाना और विसर्जित करना चाहता था
वास्तविक समय चुनौती में टीम के सदस्यों



खेल, अपने आप में, एक बहुत ही उपयोगी आधार होते हैं, अर्थात्: प्रतियोगिता, अंक और रेटिंग, नियम और उल्लंघन, एकल और टीम उपलब्धियां। खेल उत्साह के साथ संक्रमित करते हैं (जो हमारे मामले में भागीदारी के समान है), और हार की कड़वाहट और जीत की खुशी भी सिखाते हैं।

केवल एक चीज बची है एक सेटिंग चुनना, यांत्रिकी और नियमों के साथ आना, शेष राशि को संतुलित करना, और सशर्त कौमार्य पर भी काम करना।


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

कैसे प्राप्त करें MotC?

संक्षेप में, कुछ कार्य करने के लिए आपको आभासी सिक्के मिल सकते हैं:
1. स्प्रिंट कार्यों को बंद करना। यह महत्वपूर्ण है और इसे प्रोत्साहित करने की आवश्यकता है, क्योंकि यही वह है जो व्यावसायिक मूल्य लाता है। 1 स्टोरी प्वाइंट 1.2 मोटोक लेकर आया। समान मूल्य क्यों नहीं है? हां, यह सरल है: सबसे पहले, जादुई संख्या पहले से ही कहती है कि किसी प्रकार का गुणांक है, और इसकी उपस्थिति का संकेत देते हुए, आप इसे हमेशा सावधानीपूर्वक (शेष को समायोजित करने के लिए) बदल सकते हैं। प्लस मोटोक - पूर्णांक, अर्थात बड़ी संख्या में कहानी बिंदुओं को बंद करने के लिए यह एक अतिरिक्त प्रोत्साहन भी है। 3 के लिए आपको 3 मोटक मिलता है, और 5 के लिए पहले से ही 6।

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

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

4. रेटिंग और रैंक। पहले से ही 4 श्रेणियों का आविष्कार किया गया था: एसपी चैंपियन, योगदान मैक्सिमाइज़र (मोटोक की अधिकतम संख्या), स्प्रिंट हीरो और टीम पुरस्कार। पहले दो का सिद्धांत, मुझे लगता है, नाम से स्पष्ट होना चाहिए, बाकी के साथ - अधिक दिलचस्प। स्प्रिंट के नायक को रेट्रो पर टीम वोटिंग द्वारा चुना गया था, और यह मोटाउ की संख्या और प्रतिष्ठा और महत्व के संदर्भ में टीम में सबसे सम्मानित पुरस्कारों में से एक था। एक टीम पुरस्कार की उपस्थिति महत्वपूर्ण है क्योंकि यह दर्शाता है कि न केवल व्यक्तिगत परिणाम महत्वपूर्ण है, बल्कि पूरी टीम का समग्र परिणाम भी है। तीन ग्रेडेशन का आविष्कार किया गया था: नियमित स्प्रिंट, शीर्ष स्प्रिंट और असफल स्प्रिंट। स्प्रिंट को सामान्य माना जाता था, अगर स्प्रिंट बैकलॉग का 78% से अधिक बंद था, अगर यह 100% था, तो यह शीर्ष स्प्रिंट है। शीर्ष स्प्रिंट के मामले में, पूरी टीम ने एक उदार वृद्धि प्राप्त की। लेकिन सिक्के का एक फ्लिप पक्ष था - यह एक विफल स्प्रिंट है।

खनन नकारात्मक मोट

MotCs मामला। इसलिए, नकारात्मक मूल्य वाले सिक्के प्राप्त करना संभव था। किस विरोधी गुण के कारण यह हुआ:

1. स्प्रिंट विफल। स्प्रिंट बैकलॉग के 78% से कम प्रदर्शन के मामले में, पूरी टीम ने नकारात्मक खनन प्राप्त किया।
2. दोष को खोलना। यदि जलसेक कार्य में एक असमानता दोष था, तो नकारात्मक MotC को डेवलपर द्वारा अर्जित किया गया था जिसने पुल अनुरोध, साथ ही साथ इसके समीक्षकों को भी इंजेक्शन दिया था।
3. 3. एक अतिरिक्त वित्त पोषित प्रणाली का आविष्कार एक सहकर्मियों के लिए देर से खड़े होने या असावधान होने के लिए भी किया गया था। उसने "3 में एक पंक्ति के सिद्धांत पर काम किया।" 3 समान चिह्न एक नए में ढह गए, जिसमें एक नकारात्मक खनन था। एक एमनेस्टी नियम था: जब स्प्रिंट में 25 से अधिक MotC प्राप्त होता है, तो पतन नकारात्मक खनन का कारण नहीं था, लेकिन बैज रीसेट नहीं हुआ।

कैसे खर्च करें मोटापा?

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

दुकान में क्या था?

1. काम जल्दी छोड़ने या बाद में वापस आने की क्षमता। सबसे महत्वपूर्ण hodovichok।
2. दूरस्थ कार्य का दिन।
3. योजना पर प्राथमिकता कार्य चयन की संभावना।
4. लिंक्डइन सिफारिश।
5. स्विफ्ट पर विकास के लिए एक मॉड्यूल चुनना। सभी कोड ऑब्जेक्टिव-सी में थे, और लोग वास्तव में स्विफ्ट में विकसित करना चाहेंगे।
6. सम्मेलन टिकट (यदि उपलब्ध हो)।

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

खेल के दौरान सुधार

प्रयोग के दौरान, कुछ बिंदुओं पर, प्राथमिक संतुलन की समस्याएं ध्यान देने योग्य हो गईं।
कौन-कौन से?

1. रोल मॉडल खिलाड़ी। डेवलपर्स के अलावा, टीम में एक विश्लेषक था, और MotC प्राप्त करने की उसकी क्षमता बहुत सीमित थी, क्योंकि विकास के लिए कहानीकारों के लिए शेरों के कार्यों का हिस्सा तेज किया गया। इसके अलावा, विश्लेषक के कार्यों में प्रशासनिक कार्यों का हिस्सा शामिल था, जो लगातार निगरानी करना महंगा था। इसका समाधान "विशेषाधिकार प्राप्त खनन" की अवधारणा को पेश करना था, अर्थात दैनिक कर्तव्यों को पूरा करने के लिए स्वचालित रूप से मोटोकॉर्स की एक निश्चित संख्या को श्रेय दिया जाता है। यह दिलचस्प है कि भविष्य में एक और असंतुलन पाया गया: एक विश्लेषक (उदाहरण के लिए, छुट्टी) की अनुपस्थिति में, किसी ने अपने कार्यों को संभाला और इस प्रकार, विशेषाधिकार प्राप्त खनन के लिए उत्पादन का हिस्सा लिया।

2. कार्यों का मूल्यह्रास। समय के साथ, कुछ दोहराए जाने वाले कार्यों को पूरा करना आसान हो जाता है। उदाहरण के लिए, हमारे पास फ्रेमवर्क (हमारे उत्पाद) के नए संस्करण को जारी करने की एक प्रक्रिया थी - जिसमें लगभग 1.5-2 घंटे का शुद्ध समय लगता था। DevOps के विकास के साथ, इसके व्यतीत होने का समय 30 मिनट तक कम हो गया था। इसके विपरीत, MotC में पारिश्रमिक भी गिर गया है। या समय-समय पर रिपोर्ट या स्थिति के नए रूपों को तैयार करने के लिए कार्य होते थे। पहली बार ऐसा करना मुश्किल है, लेकिन इसे दोहराना आसान है - इसलिए, सिक्कों में अनुमान घट गया। टीम ने इस तरह के समायोजन को उचित माना।

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



नतीजतन, औपचारिक रूप से, नियमों के अनुसार, खिलाड़ी जल्दी से 2-3 कार्य पूरा कर सकता था और 2-3x सिक्के प्राप्त कर सकता था। मुझे ऐसे कार्यों के लिए सुधार पेश करना था, क्योंकि उनकी जटिलता कम हो गई (लेकिन निश्चित रूप से व्यक्तिगत शाखाओं में बदलाव के कारण संभावित संघर्षों के कारण शून्य नहीं हुई)।

4. उपयोगकर्ताओं के साथ काम करने के लिए पुरस्कृत करने का विचार। मैं वास्तव में अपने उपभोक्ताओं की मदद करने के लिए लोगों को "मजबूर" करना चाहता था (और यह लगभग 100 एप्लिकेशन डेवलपर्स, बेवकूफ और दोहराव वाले सवालों से भरा हुआ है)। हमने अलग-अलग तरीकों की कोशिश की: परिचारकों को नियुक्त करें, एक विस्तृत ज्ञान आधार बनाए रखें, विशेषज्ञ उपयोगकर्ताओं के एक समुदाय को विकसित करें और उन्हें प्रोत्साहित करें। लेकिन एक सरल समाधान दिखाई दिया: प्रति दिन 1 बार मैंने जल्दी से स्लैक में समर्थन चैट के माध्यम से देखा और टीम से सबसे सक्रिय सलाहकारों को मोटक के रूप में एक छोटा लेकिन सुखद इनाम दिया। दोस्तों ने रेट किया

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

परिणाम और अवलोकन

पूरा प्रयोग 9 स्प्रिंट (4 महीने) तक चला। कुल 968 MotCs खर्च किए गए थे, और 262 खर्च किए गए थे। 3 शीर्ष स्प्रिंट थे, एक ही व्यक्ति 4 बार स्प्रिंट का नायक बन गया, टीम पर MotC का वितरण इस तरह दिखाई दिया:

	MotC	MotC +
खिलाड़ी १	104	86
खिलाड़ी २	203	203
खिलाड़ी ३	148	128
खिलाड़ी ४	65	47
खिलाड़ी ५	172	92
खिलाड़ी ६	58	40
खिलाड़ी 7	68	68
खिलाड़ी 8	95	77
खिलाड़ी ९	55	55

यहाँ यह है - एकमात्र संकेतक जिसे मैं बनाना चाहता था।

वैसे, पूरे डेटाबेस को नंबरों (मैकल्स के लिए xls) में संग्रहीत किया गया था और प्रतिभागियों को सप्ताह में एक बार (रेट्रो के लिए MotC जारी करने के समय) भेजा गया था। क्रॉस-कटिंग फ़ार्मुलों के साथ 5 पृष्ठ थे: खनन इतिहास, खरीद इतिहास, ऑफ़र स्टोर, खनन विवरण और सारांश तालिका।

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

MotC	खनिज
1	समस्या एक्स के लिए प्रस्ताव
1	डेमो के लिए लाइब्रेरी आइकन को अपडेट करने के साथ मकोव की मदद करें
2	आईपी ​​के लिए बॉयलरप्लेट के साथ भंडार तैयार करना (डेमो के लिए) मैनुअल)
2	एक आईपी के उदाहरण के लिए एक एक्सएसडी योजना तैयार करना, साथ ही साथ बॉयलरप्लेट परामर्श
3	दोष बंद करना
16	14 एसपी बदलें
4	मैक्सिमाइज़र एसपी

जब प्रयोग समाप्त हो गया, तो मैंने लोगों से पूछा - सभी लोग नवाचारों से खुश थे और पुष्टि की कि यह ताजा और रोमांचक था।


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

मैं यह साबित करने की कोशिश नहीं कर रहा हूं कि यह सही प्रबंधन विकल्प या एक आदर्श उपकरण है - यह सिर्फ एक उदाहरण है कि कैसे मैं अपनी प्रबंधन शैली में विविधता लाऊं और एक टीम को "खुश करूं"। , , , . Performance Review .

!

PS Facebook LinkedIn , - 2 .