प्रभावशीलता को कैसे मापें और डेवलपर्स की समस्याओं को हल करें, यदि आपके पास एक सौ है

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



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

एक छोटी सी टीम में, मैट्रिक्स उतना महत्वपूर्ण नहीं है

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

इसकी प्रभावशीलता का मूल्यांकन करने के संदर्भ में कॉम्पैक्ट टीमों का प्रबंधन करना बहुत सरल है: क्योंकि वर्कफ़्लो में बहुत अधिक प्रतिभागी नहीं हैं, कोई भी अप्रभावी समाधान या विधियां तुरंत दिखाई देती हैं। और डेवलपर्स आसानी से अपने वरिष्ठ के साथ संपर्क बनाते हैं, क्योंकि वे उसके साथ दैनिक संवाद करते हैं।

सौ डेवलपर्स के साथ, सब कुछ बहुत अधिक जटिल है

जैसे ही टीम का आकार कई गुना बढ़ जाता है और 5-10 नहीं, बल्कि 50-100 लोग होते हैं, स्थिति नाटकीय रूप से बदल जाती है। अब नेता व्यक्तिगत रूप से सभी के साथ संवाद नहीं कर सकता है, और हमें स्पष्ट और प्रभावी मैट्रिक्स की आवश्यकता है।

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

उदाहरण के लिए, जब डॉकडॉक में मेट्रिक्स का गठन किया गया था, तो वे शुरू में सात संकेतकों के रूप में बंद हो गए थे, लेकिन अंत में केवल दो विकल्प थे:

1. काम से सुविधा / आनंद ;
2. वादा और कार्य पर खर्च किए गए समय का अनुपात;
3. कार्य जीवन चक्र का समय।

पहली मीट्रिक व्यक्तिपरक है और टीम में स्थिति और संपूर्ण रूप में माइक्रोकलाइमेट का संकेत देती है। दूसरे और तीसरे - सीधे विकास से संबंधित थे और उस समय महत्वपूर्ण मापदंडों को प्रतिबिंबित करते थे: कई टीमों को समय सीमा मिलने के साथ समस्या थी।

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

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

ग्राहक के साथ संचार

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

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

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

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

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

नीचे पंक्ति: लोगों से बात किए बिना मैट्रिक्स बेकार हैं

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

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

मेट्रिक्स केवल एक समस्या का तथ्य दिखा सकता है।

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



ps द मिटप में, उन्होंने अपने विचार साझा किए:

* सर्गेई लिस्टसेव (Plesk);
* ईगोर टॉल्स्टॉय (एविटो);
* अलेक्जेंडर एंड्रोनोव (डोडो पिज्जा);
* एंड्री शिलोखिन (टिंकोव);
* एलेक्सी परशुकोव (स्काईेंग, एक्स-डॉकडोक);
* एंड्री राइज़किन (अगिमा);
* एलेक्सी चेक्कनोव (त्सियान);
* दानिला श्टान (यांडेक्स। धार्मिक, पूर्व-टोका)

बहुत बहुत धन्यवाद!

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