प्रोग्रामरहरूको टोली प्रबन्ध गर्दै: कसरी र कसरी तिनीहरूलाई राम्रोसँग उत्प्रेरित गर्ने? भाग दुई

Epigraph:
श्रीमान्, उदास बच्चाहरूलाई हेर्दै आफ्नी पत्नीलाई भन्छन्: राम्रो, हामीले यी धुने कि नयाँ जन्माउने?

कट तल हाम्रो टोली नेता, साथै RAS उत्पादन विकास निर्देशक इगोर मारनाट द्वारा लेखको दोस्रो भाग हो, प्रोग्रामरहरूलाई उत्प्रेरित गर्ने विशेषताहरूको बारेमा। लेखको पहिलो भाग यहाँ फेला पार्न सकिन्छ - habr.com/ru/company/parallels/blog/452598

लेखको पहिलो भागमा, मैले मास्लोको पिरामिडको दुई तल्लो तहलाई छोएँ: शारीरिक आवश्यकताहरू, सुरक्षाका लागि आवश्यकताहरू, आराम र स्थिरता र अर्को, तेस्रो स्तरमा जानुहोस्, अर्थात्:

III - सम्बन्ध र प्रेमको आवश्यकता

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

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

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

यो महत्त्वपूर्ण छ कि महत्त्वपूर्ण घटनाहरूको आफ्नै दृश्यात्मक अवतार छ जससँग तिनीहरू सम्बन्धित हुन सक्छन्। आजकल, कम्पनीको आफ्नै व्यापारिक सामान, ज्याकेट, टी-शर्ट, इत्यादि हुनु सामान्य छ। तर कम्पनी भित्रको टोलीलाई हाइलाइट गर्न पनि महत्त्वपूर्ण छ। हामी प्राय: रिलीजको नतिजाको आधारमा टी-शर्टहरू जारी गर्छौं, जुन रिलीजमा संलग्न सबैलाई दिइन्छ। केही घटनाहरू, संयुक्त उत्सवहरू वा सम्पूर्ण टोलीसँग गतिविधिहरू प्रेरणाको अर्को महत्त्वपूर्ण कारक हुन्।

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

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

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

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

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

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

IV। मान्यताको खाँचो छ

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

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

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

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

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

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

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

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

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

दुवै प्रक्रियाहरूलाई ठूलो बौद्धिक प्रयास चाहिन्छ, तर तिनीहरूको व्यावहारिक उत्पादन फरक छ। यो विश्वास गरिन्छ कि प्रोग्रामरहरू अवस्थित समाधानहरूलाई समर्थन गर्न अनिच्छुक छन्; तिनीहरू बरु नयाँ विकास गर्न उत्प्रेरित छन्। यसमा बुद्धिको दाना छ। अर्कोतर्फ, मैले अहिलेसम्म काम गरेको सबैभन्दा उत्प्रेरित र एकताबद्ध टोली अवस्थित उत्पादनलाई समर्थन गर्न, समर्थन टोलीले उनीहरूलाई सम्पर्क गरेपछि बगहरू फेला पार्न र समाधान गर्न समर्पित थियो। केटाहरू शाब्दिक रूपमा यो कामको लागि बाँचे र शनिबार र आइतबार बाहिर जान तयार थिए। हामीले एक पटक उत्सुकताका साथ अर्को अत्यावश्यक र जटिल समस्याको सामना गर्यौं, या त डिसेम्बर 31 को साँझ वा जनवरी 1 को दिउँसो।

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

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

सामान्यतया, हामीले पहिले नै धेरै पटक उल्लेख गरिसकेका छौं, तपाईले तपाइँका प्रोग्रामरहरूको अपेक्षाहरू थाहा पाउनु पर्छ, तिनीहरू मध्ये कसले उनीहरूको गतिविधिको क्षेत्र विस्तार गर्न वा परिवर्तन गर्न चाहन्छ भनेर बुझ्नुहोस्, र यी अपेक्षाहरूलाई ध्यानमा राख्नुहोस्।

मास्लोको पिरामिडभन्दा पर: परिणामहरूको दृश्यता, गेमिफिकेशन र प्रतिस्पर्धा, कुनै बकवास छैन

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

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

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

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

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

दोस्रो बिन्दु खेल र प्रतिस्पर्धा हो।

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

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

र अन्तमा, तेस्रो बिन्दु - कुनै बकवास।

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

स्रोत: www.habr.com