हमने स्टूडियो में एक प्रशिक्षण और प्रेरणा प्रणाली कैसे बनाई

मेरे स्टूडियो में 15 लोग हैं, जिनमें से आधे प्रोग्रामर हैं। स्टूडियो ऑनलाइन स्टोर विकसित करने में माहिर है, इसलिए प्रोग्रामर हमारे मुख्य संसाधन हैं।

प्रोग्रामर के लिए तीन चीजें हमेशा जरूरी होती हैं

• परियोजनाओं को सौंपने के लिए तेज़।
• श्रम लागत के अपने स्वयं के मूल्यांकन में रहें।
• विकास और विकास

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

हम तेजी से परियोजनाओं को कैसे प्रस्तुत करना शुरू करते हैं

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

कैसे प्रेरित हुआ?

पहला चरण

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

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

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

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

दूसरा चरण

दूसरा निर्णय परियोजना के वितरण पर बोनस का भुगतान करना था, न कि परियोजना के पूरा होने पर।

अब, प्रोग्रामर और भी बदतर हो गए हैं: न केवल संबंधित कार्यों ने उनके प्राप्त बोनस को प्रभावित किया, बल्कि उदाहरण के लिए, भुगतान और वितरण के साथ एकीकृत करने के लिए ग्राहक पहुंच प्रदान करने की गति (और कभी-कभी यह कई महीने है), और 1C विशेषज्ञों की गति (1C के लिए एकीकरण) )।

इसके अलावा, प्रोग्रामिंग चरण में, पिछले चरणों की सभी त्रुटियां सामने आती हैं: योजना, डिजाइन, डिजाइन। और प्रोग्रामर को उन्हें वस्तुतः एक नंगे वेतन के लिए सही करना पड़ता है (और वह इस प्रणाली के ढांचे में बहुत छोटा था)।

यह पता चला है कि प्रोग्रामर बोनस के बिना रहता है (और वे महत्वपूर्ण हैं) अपनी गलती के बिना।

यह संरेखण अस्वीकार्य था और परियोजनाओं के लिए बोनस के साथ प्रयोग को रोकना पड़ा।

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

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

तो क्या इस मामले में भौतिक प्रेरणा आवश्यक है?

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

वेतन और बोनस का अनुपात एक ही समय में 80/20% के स्तर पर।

हम श्रम लागत के आपके आकलन में फिट होने के लिए प्रेरित करते हैं

यदि डेवलपर्स की सामग्री प्रेरणा के कारण परियोजनाओं को तेजी से वितरित करना असंभव है, तो शायद यह प्रोग्रामर को कार्यों के लिए समय सीमा के अपने अनुमान में फिट करने के लिए प्रेरित करने योग्य है?

हम किस बारे में बात कर रहे हैं: कार्यों की जटिलता के अनुमान के आधार पर, यह प्रोग्रामर के काम करने के लिए योजनाबद्ध है - कार्य अल्पकालिक (सप्ताह) और दीर्घकालिक (1-2 महीने) के परिप्रेक्ष्य के लिए निर्धारित हैं। तदनुसार, यदि प्रोग्रामर समय सीमा को पूरा नहीं करता है, तो काम का पूरा शेड्यूल गिर जाएगा, समय सीमाएं उस पर निर्भर परियोजनाओं, और इसी तरह आगे बढ़ेंगी।

प्रोग्रामर को नियोजित समय सीमा के भीतर रखने में मदद कैसे करें?

यदि आप निशान से मिले हैं तो इनाम देना संभव है। आप वंचित हो सकते हैं, अगर नहीं मिले।

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

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

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

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

इसलिए, क्योंकि आप कार्य के लिए समय सीमा को पूरा नहीं कर सकते हैं

कार्य का प्रारंभ में गलत मूल्यांकन किया गया था।

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

रास्ते में विवरण के साथ कार्य अधिक हो गया है।

यदि ग्राहक से विवरण आया और शुरू में वे स्पष्ट नहीं थे, तो प्रोग्रामर मूल्यांकन को सही करता है, और प्रबंधक लापता घंटों को बेचता है और समय सीमा को स्थानांतरित करता है।

यदि विवरण स्पष्ट था, लेकिन प्रबंधक ने उन्हें याद किया

वह पहले से ही प्रबंधक के ज्ञान के अंतराल के बारे में बोलता है। हम समझते हैं कि प्रबंधक को अध्ययन करना चाहिए ताकि समान समस्याएं अब उत्पन्न न हों।

लेकिन क्या आपको यहां वित्तीय प्रेरणा की आवश्यकता है

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

प्रोग्रामर का प्रशिक्षण और विकास के लिए प्रेरणा

पूर्वव्यापी चरण में, हम प्रोग्रामर के ज्ञान में अंतराल पाते हैं। लेकिन इन अंतरालों का अध्ययन और उन्हें कैसे प्राप्त करें?

हम क्रास्नोडार में स्थित हैं, और यहां सामान्य रूप से एक ईकॉमर्स स्टूडियो है (वास्तव में, हम)। इसका मतलब है कि तैयार कर्मियों को लेने के लिए कहीं नहीं है। और सभी को या तो खरोंच से बढ़ने की ज़रूरत है, या उस स्तर से "बढ़ने" की, जो उनके पास अन्य स्टूडियो में था।

एक प्रोग्रामर को क्या पता होना चाहिए

• दृश्यपटल
• बैकएंड
• स्लाइडर
• एकीकरण (1C और इतने पर)
• लिनक्स, Nginx, Apache

इस प्रकार, हमारे पास क्षमता के 5 क्षेत्र हैं। उनमें से प्रत्येक के पास कौशल का एक निश्चित समूह है जिसमें से एक प्रोग्रामर का सक्षमता मानचित्र बनता है। यह डेवलपर्स के स्तर (प्रशिक्षु, जूनियर, मध्य, वरिष्ठ) में विभाजन को निर्धारित करता है।

जैसे-जैसे स्तर बढ़ता है, वेतन बढ़ता है।

हमने डेवलपर्स को कैसे उठाया

परिकल्पना 1

पहला विचार डेवलपर्स को दक्षताओं और कार्यप्रणाली का एक नक्शा देने और खुद को विकसित करने की पेशकश करने का था।

Bitrix24 में, हमने स्वचालित कार्य शुरू किए, जिसमें सभी को प्रशिक्षण में प्रगति पर रिपोर्ट करना था।

और फिर मैं पहली समस्या में भाग गया। किसी कारण से, प्रोग्रामर अध्ययन नहीं करना चाहते थे और सक्षमता के नक्शे पर बढ़ना नहीं चाहते थे।

कुछ महीनों के निरर्थक प्रयासों के बाद, मैंने उनसे पूछने का अनुमान लगाया: क्या गलत है?

यह पता चला कि विभिन्न स्तरों के बीच दक्षताओं में बहुत अधिक अंतर है। और वह पढ़ाई के लिए प्रेरित नहीं करती है।

परिकल्पना २

फिर मैंने स्तरों को कई स्तरों में तोड़ने का फैसला किया (अध्ययन क्षमता मानचित्र के प्रतिशत के रूप में)। और प्रत्येक स्तर के लिए वेतन में एक छोटी सी वृद्धि देने के लिए।

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

परिकल्पना ३

खाली समय दें। कार्यों के बीच, प्रोग्रामर प्रशिक्षण के लिए सप्ताह में कई घंटे छोड़ने लगे।

और इसलिए इसने काम किया। प्रोग्रामर आत्म-विकास में संलग्न होने लगे, परीक्षण करने लगे और वेतन में वृद्धि हुई।

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

निष्कर्ष

हमारे अनुभव में, प्रोग्रामर के पास पर्याप्त आंतरिक प्रेरणा होती है, और यदि वे परेशान नहीं होते हैं, तो वे यथासंभव संभव काम करते हैं।

यह पुरस्कार एक अतिरिक्त प्रेरक के रूप में काम की गुणवत्ता के लिए इतना नहीं है जितना कि संबंधित विशेषज्ञों के काम में विसर्जन के लिए (डिजाइन में समस्या वाले क्षेत्रों की खोज और TK पहले यह सहमति देता है)।

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