प्रोग्रामर की एक टीम का प्रबंधन: उन्हें सही तरीके से कैसे और कैसे प्रेरित करना है? भाग दो

आदर्श वाक्य:
कर्कश बच्चों को देख पति अपनी पत्नी से कहता है: अच्छा, क्या, हम इन या नए लोगों को धोते हैं?

कटौती के तहत, हमारी टीम के नेता के लेख का दूसरा भाग, साथ ही आरएएस उत्पाद विकास के निदेशक - इगोर मारनाट ने प्रोग्रामर प्रेरणा की विशेषताओं के बारे में बताया। लेख का पहला भाग यहां पाया जा सकता है - habr.com/en/company/parallels/blog/452598




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

III - संबद्धता और प्रेम की आवश्यकता



मुझे पता था कि इतालवी माफिया को "कोसा नोस्ट्रा" कहा जाता है, लेकिन मैं बहुत प्रभावित हुआ जब मैंने "कोसा नोस्ट्रा" का अनुवाद करना सीखा। इतालवी से अनुवाद में "कोसा नोस्ट्रा" - "हमारा व्यवसाय"। प्रेरणा के लिए नाम का विकल्प बहुत सफल है (आइए हम एक तरफ व्यवसाय छोड़ दें, इस मामले में हम केवल प्रेरणा में रुचि रखते हैं)। एक व्यक्ति आमतौर पर कुछ बड़े, सामान्य, हमारे व्यवसाय करने के लिए एक टीम का हिस्सा बनना चाहता है।

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

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

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

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

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

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

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

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

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

चतुर्थ। मान्यता चाहिए

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

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

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

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

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

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

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

V. ज्ञान और आत्म-बोध की आवश्यकता।

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

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

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

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

सामान्य तौर पर, जैसा कि हमने बार-बार उल्लेख किया है, आपको अपने प्रोग्रामर की अपेक्षाओं को जानना चाहिए, समझें कि उनमें से कौन सी गतिविधियों के दायरे का विस्तार करना या बदलना और इन अपेक्षाओं को ध्यान में रखना चाहिए।

मैस्लो पिरामिड के बाहर: दृश्यता, Gamification और प्रतियोगिता, कोई बकवास नहीं

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

पहला परिणाम की दृश्यता और निकटता है।

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

यह प्रेरणा कुछ हद तक कंप्यूटर गेम खेलने वाले खिलाड़ियों द्वारा अनुभव के समान है: वे समय-समय पर प्रत्येक स्तर से गुजरते समय पदक, अंक, बोनस प्राप्त करते हैं, इसे "डोपामाइन प्रेरणा" कहा जा सकता है।

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

दूसरा बिंदु Gamification और प्रतियोगिता है।

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

एक महत्वपूर्ण बिंदु जो क्वांटिटेटिव मेट्रिक्स की किसी भी प्रणाली को पेश करते समय उत्पन्न होता है, वह यह है कि जैसे ही आपने उन्हें लागू किया है, सिस्टम स्वचालित रूप से इन मात्रात्मक मेट्रिक्स की उपलब्धि को प्राथमिकता देना चाहता है, गुणात्मक लोगों के नुकसान के लिए। , . , -, , , , , , +1 . , , +1 CI . , “go, go, jenkins”. , , , . : , . , , , , scale performance , , core reviewer, core projects , — .

, — No bullshit.

— , . 8-10 , . -, , , , , . , , , . — . , , , , disagree and commit ( , ). - , . , , , . - : « , , . , , ». , . , , .