उद्देश्य डेटा के आधार पर डेवलपर का मूल्यांकन करें

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

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


वक्ताओं के बारे में: अलेक्जेंडर Kiselev और सेर्गेई सेमेनोव, हम 8 से अधिक वर्षों के लिए आईटी में रहे हैं। दोनों डेवलपर से टीम लीड और आगे उत्पाद प्रबंधक के पास गए। अब वे विश्लेषणात्मक सेवा GitLean पर काम कर रहे हैं, जो स्वचालित रूप से टीम लीड और सीटीओ के लिए विकास टीमों से विश्लेषण एकत्र करता है। इस सेवा का उद्देश्य यह है कि तकनीकी प्रबंधक अपने निर्णय ऑब्जेक्टिव डेटा के आधार पर कर सकते हैं।

समस्या कथन

हम दोनों ने टीम लीडर के रूप में काम किया और अक्सर अपने काम में अनिश्चितता और अस्पष्टता की समस्या का सामना किया।


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

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


यह दो मुख्य मामलों में आवश्यक है।

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

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

दूसरा पहलू टीम की मौजूदा स्थिति पर नजर रख रहा है । मैं उन समस्याओं को जल्दी से समझना चाहता हूं, और जल्दी से उन्हें जवाब देना चाहता हूं।

निर्णय के विकल्प

इसके कई समाधान हो सकते हैं।


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


यह अगली बात है। चूंकि व्यक्तिपरक आकलन अक्सर पर्याप्त नहीं होता है, आप भ्रमित हो सकते हैं और तथ्यों को हाथ से एकत्र कर सकते हैं ।

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

जब सीटीओ को पता चला, तो यह पता चला कि समस्या इतनी पुरानी थी कि कुछ भी करना असंभव था, और अंत में प्रोग्रामर को निकाल दिया जाना था।


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

एक सरल उदाहरण - पिछले स्प्रिंट में डेवलपर ने 5 कार्य किए, यह एक - 10. क्या यह कहना संभव है कि उसने बेहतर काम करना शुरू किया? यह असंभव है, क्योंकि कार्य पूरी तरह से अलग हैं।


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

चयनित समाधान

इसलिए, चुना हुआ उपाय है कि आप अपनी स्क्रिप्ट को एनालिटिक्स इकट्ठा करने के लिए तैयार करें। मुख्य प्रश्न यह हैं कि डेटा कहाँ प्राप्त करें और क्या मापें।

डेटा स्रोत

मुख्य डेटा स्रोत जिसमें डेवलपर के काम के बारे में जानकारी संचित है:

1. Git - मुख्य इकाइयाँ: कमिट, शाखाएँ और उनके अंदर कोड।
2. कोड समीक्षा टूल - git होस्टिंग सेवाएँ जो होस्ट कोड समीक्षा पुल-रिक्वेस्ट के बारे में जानकारी रखती हैं, जिनका उपयोग किया जा सकता है।
3. टास्क ट्रैकर्स - कार्यों और उनके जीवन चक्र के बारे में जानकारी।

सहायक डेटा स्रोत:

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

चूँकि मैंने ऊपर जिन सभी स्रोतों के बारे में बात की है, वे अधिक या कम मानक हैं, और अंतिम इतना मानक नहीं है, मैं इसके बारे में कुछ और बात करूँगा।


एक अन्य सीटीओ ने इस विधि को हमारे साथ साझा किया। प्रत्येक पुनरावृत्ति के अंत में, उन्होंने टीम को स्वचालित रूप से एक पोल भेजा, जिसमें केवल 2 प्रश्न थे:

1. आपकी राय में, हमने इस पुनरावृत्ति में क्या महत्वपूर्ण था?
2. क्या आपको लगता है कि हम जो कर रहे हैं वह दिलचस्प था?

यह एक टीम में मूड को मापने के लिए एक काफी सस्ता तरीका है और, शायद, प्रेरणा के साथ कुछ समस्याओं को पकड़ता है।

क्या और कैसे मापना है

सबसे पहले, हम माप पद्धति पर चर्चा करेंगे। एक अच्छे मीट्रिक को 3 प्रश्नों का उत्तर देना चाहिए:

1. क्या यह महत्वपूर्ण है? केवल यह मापना आवश्यक है कि कंपनी के लिए किसी महत्वपूर्ण चीज के बारे में क्या संकेत हैं।
2. क्या यह बदतर / बेहतर / समान हो गया है? मीट्रिक द्वारा, यह स्पष्ट होना चाहिए कि क्या यह बेहतर या बदतर हो गया है।
3. क्या करें? मीट्रिक से, यह स्पष्ट होना चाहिए कि स्थिति को सुधारने के लिए क्या करना चाहिए।

सामान्य तौर पर, यह सिद्धांत का पालन करने लायक है:

आप जो चाहते हैं उसे माप सकते हैं और बदल सकते हैं।

यह अभी ध्यान देने योग्य है कि कोई सार्वभौमिक मीट्रिक नहीं है, और हम निम्नलिखित कारणों से आज एक सार्वभौमिक मीट्रिक के बारे में बात नहीं करेंगे:

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

नया तरीका

इसलिए, हमने एक दृष्टिकोण तैयार किया है जिसमें हम समस्याओं से जाते हैं: हम विशिष्ट समस्याओं की पहचान करने की कोशिश करते हैं और उनके लिए मैट्रिक्स का एक सेट का चयन करते हैं जो उनका पता लगाएगा। एक अच्छे डेवलपर को कम से कम समस्याओं के साथ डेवलपर कहा जाएगा।


समस्याओं के आधार पर हमारी पसंद क्या है? यह सरल है: हमने 37 सीटीओ और टीम के नेताओं के साथ एक साक्षात्कार आयोजित किया, जिन्होंने अपनी टीमों में होने वाली समस्याओं के बारे में बात की, और वे इन समस्याओं को कैसे हल करते हैं।

परिणामस्वरूप बड़ी सूची, हमने इन समस्याओं के लिए जीवन हैक और मैट्रिक्स को प्राथमिकता दी और एकत्र किया। हमने सभी समस्याओं को 2 समूहों में विभाजित किया है:

1. एक व्यक्तिगत डेवलपर की समस्याएं (इन समस्याओं के लिए डेवलपर जिम्मेदार है)।
   
   
2. टीम की समस्याएं इन समस्याओं के लिए टीम जिम्मेदार है; तदनुसार, उन्हें हल करने के लिए, आपको टीम के साथ समग्र रूप से काम करने और प्रक्रिया समाधान बदलने की आवश्यकता है।
   
   

आइए प्रत्येक समस्या पर विस्तार से विचार करें, जो कि मैट्रिक्स से कुंजी को चुना जा सकता है। आइए सरलतम समस्याओं के साथ शुरू करें और धीरे-धीरे जटिलता को मापने के लिए सबसे कठिन जटिलता के साथ आगे बढ़ें।

डेवलपर समस्याएँ

डेवलपर थोड़ा प्रदर्शन

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

इसे कैसे मापा जा सकता है?

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

जाहिर है, सिर्फ सक्रिय दिनों की संख्या पर्याप्त नहीं है। एक डेवलपर सिर्फ कोड लिख सकता है और इसे प्रतिबद्ध नहीं कर सकता है - लिखा, लिखा और फिर एक दिन कोड का एक गुच्छा बनाया।

इसलिए, अगली सीमा जो हम लगाते हैं, वह यह है कि डेवलपर के पास थोड़ा कोड भी होना चाहिए। दहलीज "छोटे कोड" का निर्धारण कैसे करें? हम अनुशंसा करते हैं कि आप इसे छोटा रखें ताकि कोई भी, जितना कि एक प्रदर्शन करने वाला डेवलपर, आसानी से इसे पार कर सके। उदाहरण के लिए, जेएस के लिए हमारी सेवा में यह कोड की लगभग 150 लाइनें हैं, और क्लोजर के लिए - कोड की 100 लाइनें।

इतनी छोटी दहलीज क्यों? विचार यह है कि हम नहीं चाहते कि कूलिंग डेवलपर्स को औसत कामकाजी लोगों से अलग किया जाए, लेकिन जो लोग लगभग कुछ भी नहीं करते हैं, जो कम से कम कुछ काम की राशि करते हैं।

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

देखने लायक अगली चीज कोड समीक्षा की मात्रा है जो उसने किया था, क्योंकि एक व्यक्ति कार्य नहीं कर सकता था और कोड नहीं लिख सकता था, लेकिन कोड समीक्षा में पूरी तरह से डूब जाता है। ऐसा होता है।

इसलिए, अगर इन सभी मैट्रिक्स के लिए - और केवल इतना ही! - डेवलपर किसी भी सीमा तक नहीं पहुंचता है, आप उस पर अच्छा प्रदर्शन नहीं करने का संदेह कर सकते हैं।

इसके बारे में क्या करना है?

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

यह सबसे सरल और सबसे उत्तेजक समस्या थी। चलो भारी लोगों पर चलते हैं।

डेवलपर रीसायकल करता है

यह भी एक आम कहानी है। यदि कोई व्यक्ति इसे संसाधित करता है, तो यह बाहर जलता है, अंततः डिमोटिविट्स और, परिणामस्वरूप, कंपनी को छोड़ सकता है। तकनीकी प्रबंधकों में से एक जिनके साथ हमने बात की, उन्होंने ऐसी कहानी बताई। उन्होंने एक अमेरिकी कंपनी के लिए काम किया जिसमें रैलियों की संस्कृति बेतहाशा विकसित हुई थी। नतीजतन, सभी डेवलपर्स, जब वे काम पर आए, तो बस वही किया, जो उन्होंने रैली की थी, और उन्होंने घंटों और सप्ताहांत के बाद कोड लिखा था। नतीजतन, कंपनी में डेवलपर्स का वार्षिक कारोबार 30% तक पहुंच गया, हालांकि उद्योग का मानक 6% है।

नतीजतन, इस कार्यालय से 30 लोगों से मिलकर सभी तकनीकी प्रबंधन को खारिज कर दिया गया था। इसे आगे नहीं लाने के लिए, मैं समय रहते इस समस्या का पता लगाना चाहता हूं।

इसे कैसे मापा जा सकता है?

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

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

अंतिम स्पष्ट ट्रिगर समानांतर कार्यों की एक बड़ी संख्या है । डेवलपर के लिए 3-4 कार्यों की कुछ उचित सीमा है। आप उन्हें अपनी इच्छानुसार जीआरए या जीरा द्वारा ट्रैक कर सकते हैं। यह बहुत अच्छी तरह से काम करता है।

इसके बारे में क्या करना है?

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

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

डेवलपर का कार्य जारी करने पर कोई ध्यान नहीं है

मैं यह समझना चाहता हूं कि आपकी टीम में कितने डेवलपर्स हैं और समय में इसकी कितनी लागत है।


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

इसे कैसे मापा जा सकता है?

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

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

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

इसके बारे में क्या करना है?

यदि आपको ऐसा कोई डेवलपर मिलता है, तो स्पष्ट रूप से उसके ऊपर जाना और कहने योग्य है : "देखो, यह आपके समय का 30-40% डाउनटाइम पर खर्च होता है!" यह आमतौर पर बहुत अच्छा काम करता है। मेरे मामले में, उदाहरण के लिए, इसका ऐसा प्रभाव पड़ा। यह समस्या लगभग पूरी तरह से दूर हो गई है, यदि नहीं, तो आपको समय-समय पर निगरानी जारी रखने की आवश्यकता है, लेकिन यहां मुख्य बात यह है कि यह सूक्ष्मजीव में नहीं पड़ना चाहिए, क्योंकि यह और भी खराब होगा।

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

डेवलपर पर्याप्त कार्यों के माध्यम से नहीं सोचता है

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


इसे कैसे मापा जा सकता है?

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

इसे कैसे मापा जा सकता है?

ऐसा करने के लिए, हमें 2 मेट्रिक्स शुरू करने की आवश्यकता है, जिनमें से पहला मंथन कोड है।


मंथन एक माप है कि एक डेवलपर कितना कोड को व्यर्थ में लिखता है।

स्थिति की कल्पना करो। सोमवार को, डेवलपर ने एक नया कार्य करना शुरू किया, और कोड की 100 लाइनें लिखीं। फिर मंगलवार आया, उन्होंने इस कार्य में कोड की 100 नई लाइनें लिखीं। लेकिन, दुर्भाग्य से, ऐसा हुआ कि कोड की 50 लाइनें जो सोमवार को लिखी गई थीं, वह कार्य को हटा देता है और जारी करता है। नतीजतन, कार्य में 200 लाइनों का कोड बनाया गया था, लेकिन रिलीज होने तक केवल 150 बच गए, और 50 व्यर्थ में लिखे गए थे। इन 50 को हम मंथन कहते हैं। और इसलिए इस उदाहरण में, डेवलपर मंथन 25% था।

हमारी राय में, मंथन का एक उच्च स्तर एक शांत ट्रिगर है जो डेवलपर ने कार्य को नहीं सोचा था।

एक अमेरिकी कंपनी का एक अध्ययन है जिसमें उन्होंने 20,000 डेवलपर्स के चर्न स्तर को मापा और इस नतीजे पर पहुंचे कि एक अच्छा मंथन कोड 10-20% की सीमा में होना चाहिए।

लेकिन 2 महत्वपूर्ण शर्तें हैं:

1. उच्च मंथन ठीक है अगर, उदाहरण के लिए, आप एक प्रोटोटाइप या कुछ नई परियोजना बना रहे हैं। फिर यह कई महीनों तक 50-60% के बराबर हो सकता है। चिंता की कोई बात नहीं है। , Churn — , .
2. Churn — . . - . delivery .

, , , , Fixed Tasks, . , .

, bug fixes , bug fixes . bug fixes 3 , , . , , , .

— . , , , - .

?

, , , . , , , estimation ..

CTO, , workflow, , . , , , - , .

Churn Fixed Tasks

, , :

• commit message, . commit message, , git .
• git-squash commit' , Churn .
• git. merge master, merge , . — , , Churn Fixed Tasks.

, — , . , , , . , - .

, , - 3-4 . , .

?

— - , , .


, 3 , , ( ), .

, , . — , .

— , — — , , .

?

. , , . - , .

— , , . . , , . .

30-50 50-60 %. , .

, , . , , , . .


, — . product- , . , , .

?

product- , ?

, product- , :

• Churn, ;
• , , estimation;
• in progress product-.

?

product- : «, Churn - — ».

« » , 1-2 . , product-, .


. , , .

, , , . , , - , , . , . .

?

, , :

• ;
• ;
• ;
• -, - , ;
• .

?

-, , , , .

-, , , , , , .

— - , . best practise, , , , . 3 , 3 .


, — . , . - , , -. , , CTO, , 100%. , - .

?

, legacy refactoring . , . . , , , .


, legacy refactoring , , complexity , , .

?

, , . , CTO. , .

CTO , , Jira «» . , - estimation . , — , ..

CTO . , , , «Hack». - -, : « Hack — », . grep' «Hack» , .

. .

:

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

निष्कर्ष

हम आपको निम्नलिखित बताना चाहते हैं:

• डेवलपर्स और टीम को मापा जा सकता है । यह मुश्किल हो सकता है, लेकिन यह किया जा सकता है।
  
• KPI का कोई सार्वभौमिक छोटा सेट नहीं है । प्रत्येक समस्या के लिए, आपको मीट्रिक के अपने अति विशिष्ट सेट का चयन करना होगा। यह याद रखना चाहिए कि आपको सरलतम मैट्रिक्स की भी उपेक्षा नहीं करनी चाहिए। दोनों मिलकर अच्छा काम कर सकते हैं।
  
• Git विकास और डेवलपर्स के बारे में बहुत सारी दिलचस्प बातें बता सकता है, लेकिन आपको कुछ प्रथाओं का पालन करने की आवश्यकता है ताकि डेटा को आसानी से एक्सेस किया जा सके, जिसमें शामिल हैं:
  
  • कमिट्स में कार्यों की संख्या;
  • कोई स्क्वैश नहीं;
  • आप रिलीज़ समय निर्धारित कर सकते हैं: मास्टर, टैग में मर्ज करें।

उपयोगी लिंक और संपर्क:

• प्रस्तुति प्रस्तुति में उनके लिए कई बोनस समस्याएं और मैट्रिक्स हैं।
  
• लेखक ब्लॉग विकास प्रबंधकों के लिए उपयोगी लेख के साथ
  
• टेलीग्राम संपर्क: @avkiselev (अलेक्जेंडर Kiselev) और sss0791 (सर्गेई सेमेनोव)।

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

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