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

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

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

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

तृतीय - अपनेपन और प्यार की जरूरत

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

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

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

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

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

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

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

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

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

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

चतुर्थ. पहचान की जरूरत

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

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

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

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

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

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

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

V. अनुभूति और आत्म-साक्षात्कार की आवश्यकता।

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

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

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

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

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

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

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

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

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

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

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

दूसरा बिंदु है सरलीकरण और प्रतिस्पर्धा।

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

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

और अंत में, तीसरी बात - कोई बकवास नहीं।

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

स्रोत: www.habr.com