यह नोट लिखने के लिए खर्च किया गया था:
- यात्रा के लिए 68,338 किलोमीटर।
- मेल पत्राचार के लिए 72 मानव-घंटे।
- 30 लोगों की एक टीम के साथ प्रयोगों के लिए 423 मानव-घंटे।
- सम्मेलनों में रिपोर्ट तैयार करने और बोलने के लिए 88 घंटे।
- बाद में समझदार लोगों के साथ बातचीत के लिए 17 कप कॉफी।
- इस पाठ को टाइप करने और उसमें कीड़े संपादित करने के लिए लगभग 25 घंटे :)।
- मृत्यु के लिए, एक अत्याचारी कॉपीराइटर जो मेरे ड्राफ्ट, ऑडियो रिकॉर्डिंग और सामान्य रूप से उसके लिए धन्यवाद करने के लिए मजबूर किया गया था।
बहुत सारा पैसा और समय। शायद सबसे महंगा (नसों, समय और धन के संदर्भ में) मेरी अपनी टीम पर एक प्रयोग था, जिसे याद करने के लिए मैं अविश्वसनीय रूप से अजीब हूं। लेकिन इसके बारे में अधिक नीचे।
जल्दी या बाद में, शायद, हर निर्देशक को निष्पक्षता का भुगतान करने की इच्छा होती है। किए गए काम के लिए। और अब कई केपीआई (प्रमुख प्रदर्शन संकेतक) को लागू करने की कोशिश कर रहे हैं। यह इस तरह काम करता है: आप एक व्यवसाय के स्वामी के रूप में, कर्मचारियों के लिए विशिष्ट लक्ष्य निर्धारित करते हैं। वे प्रक्रिया में अपने लक्ष्यों को प्राप्त करते हैं या नहीं प्राप्त करते हैं। जिन लोगों ने हासिल किया है उन्हें एक बन्स (नकद बोनस) प्राप्त होता है।
इस दृष्टिकोण का अर्थ: निष्पक्षता में भुगतान करना। कितना काम किया है - बहुत कुछ मिला है। यह ईमानदार है, यह तार्किक है, यह अद्भुत है!
खैर, यह तार्किक है:
- बिक्री के लोगों को टर्नओवर का प्रतिशत आवंटित करने की आवश्यकता है। भेड़ियों को भूखा रहना चाहिए। (हां, एक वैकल्पिक राय है कि इस दृष्टिकोण को लागू करने का अर्थ है "अपने आप पर एक अतिरिक्त कर लगाना।" लेकिन मेरे लिए, यहां सब कुछ उचित है :-))।
- कार्यालय प्लवक - वेतन। उनके लिए स्थिरता अस्तित्व के लिए एक बहुत महत्वपूर्ण शर्त है।
लेकिन रचनात्मक इकाइयों (डिजाइनर, प्रोग्रामर) के साथ - सब कुछ बहुत अधिक जटिल है।हमने हाल ही में इस विषय पर देश की अग्रणी डिजिटल एजेंसियों और वेब स्टूडियो के नेताओं का एक सर्वेक्षण किया "आप रचनात्मक इकाइयों के काम के संबंध में KPI का उपयोग कैसे करते हैं", परिणामस्वरूप हमें यह चित्र मिला:
कुछ कंपनियां (15%) प्रोग्रामर्स और डिजाइनरों के काम की प्रभावशीलता का मूल्यांकन करने के लिए KPI का उपयोग करती हैं।
लगभग 25% कंपनियां फिलहाल KPI को लागू कर रही हैं / कंपनी के भीतर प्रतिरोध को पूरा करती हैं या एक सरलीकृत योजना पर काम करती हैं।
लगभग 30% कंपनियां प्रबंधकों के व्यक्तिपरक आकलन के आधार पर मजदूरी का भुगतान करती हैं। बल्कि, 30% यह स्वीकार करते हैं ;-)
शेष 30% मान्यता प्राप्त नहीं हैं।सबसे दिलचस्प बात यह है कि कई ने केपीआई को लागू करने की कोशिश की है या अब कोशिश कर रहे हैं। और बहुत सफलतापूर्वक नहीं। इसका मतलब यह नहीं है कि "KPI खराब है।" खराब पका हुआ भोजन असंभव है। शायद हम इस KPI को खाना बनाना नहीं जानते हैं?
लेकिन आंकड़े बताते हैं कि विशाल बहुमत के कार्यान्वयन में कठिनाइयाँ हैं। और एक संदेह है कि हर किसी को एक आम समस्या है। आइए इसे जानने की कोशिश करें।
KPI को लागू करते समय आपको सबसे पहले जिस चीज का सामना करना पड़ता है वह है टीम प्रतिरोध
सवाल उठता है:
KPI लागू करते समय डेवलपर्स के लिए सबसे अधिक मंडराना क्या है?सहकर्मियों के बीच कई प्रयोग और सर्वेक्षण करने के बाद, हमने 6 मुख्य कारणों की पहचान की:
- नवीनता का डर। हर कोई नवाचारों से पूरी तरह से डरता है, यह सोचकर कि यह खराब हो जाएगा (कम पैसा, अधिक काम, आदि)।
- अपारदर्शी लेआउट। कई मापदंडों के साथ सामग्री क्षतिपूर्ति योजना का उपयोग करते हुए, हम उस जोखिम को बढ़ाते हैं जो कर्मचारी इसे नहीं समझेंगे। यह लोगों को तब प्रभावित करता है, जब वे समझ नहीं पाते हैं कि वे सबसे अच्छे परिणाम कैसे प्राप्त कर सकते हैं या क्यों उन्हें अचानक कम पैसे मिले।
- "वहाँ इतना क्या है?" हां, ऐसा भी होता है। यदि योजना इस तरह से बनाई गई है कि इस महीने का परिणाम केवल दो या तीन के बाद दिखाई देगा। “इस महीने मैंने और भी बुरा काम किया, लेकिन और भी बहुत कुछ किया। इसलिए, पिछली बार मैं ऊब गया था। नेतृत्व - बेवकूफ, वे मेरे काम में कुछ भी नहीं समझते हैं! "
- ChSV कर्मचारी। किसी व्यक्ति की स्वयं की भावना में आना और उसे "उचित" बोनस देना लगभग असंभव है।
- कर्मचारी पर कसौटी की उपलब्धि की अधूरी निर्भरता । उदाहरण के लिए, यह पूरी तरह से डिज़ाइनर पर निर्भर नहीं करता है कि उसने जो डिज़ाइन तैयार किया है, वह बेचा जाएगा या नहीं तो उसे 50 संपादन करने होंगे।
- रिपोर्ट। मैं किसी को भी नहीं जानता, जो रिपोर्ट लिखना पसंद करता है, समय व्यतीत करता है, "सटीक तिथियां" का वादा करता है।
यदि आप इस सूची को ध्यान से देखें, तो आप पाएंगे कि अधिकांश दावे चयन, विचार, पारदर्शिता और मानदंडों की पर्याप्तता से संबंधित हैं।
ठीक है। तो आपको बस अच्छे क्राइटेरिया के साथ आने की जरूरत है!
खैर, जो लोग सब कुछ समझते हैं, जो किसी को भी नहीं भिगोएंगे, जिन्हें बस एक साक्षात्कार में समझाया जाएगा। और इसलिए कि सब कुछ ईमानदार था, और मैं बार-बार काम करना चाहता था।
सामान्य तौर पर, चलो अच्छा मानदंड खोजने की कोशिश करते हैं। (वैसे, "अच्छा" - किसके लिए?) हमारे पास तीन प्रमुख प्रभावित हितधारक हैं: स्टूडियो मालिक, ग्राहक और डेवलपर्स।
ग्राहक के दृष्टिकोण से एक अच्छा मानदंड क्या हो सकता है? आमतौर पर यह पैसे के लिए नीचे आता है (अच्छी तरह से, या कुछ वास्तविक परिणाम):
- आरओआई - मोटे तौर पर, यह "वित्तीय इंजेक्शन पर वापसी" है। अर्थशास्त्रियों द्वारा काटा गया संकेतक पूरी तरह से डेवलपर्स के लिए लागू नहीं होता है: आखिरकार, वे अपने काम पर वापसी को नियंत्रित नहीं कर सकते हैं और इसे पैसे पर माप सकते हैं। यही है, वे सीधे संकेतक को प्रभावित नहीं कर सकते हैं।
- कम लागत वाली सुविधाएँ। ग्राहक के लिए कम लागत की सुविधा होना फायदेमंद है। और डेवलपर के लिए, यह टेम्पलेट में एक विराम है ("यह कैसे होता है: क्या मुझे सस्ते काम करने के लिए अधिक पैसा मिलता है?")।
- संतुष्टि की डिग्री। मुझे नहीं पता कि इसे कैसे गिना जाए, लेकिन अगर आप इस बात को ध्यान में रखते हैं कि लोग खुशी चाहते हैं या कम स्टीम (© दिमित्री सैटिन), तो आप भी इस सूत्र का सुझाव दे सकते हैं:
हालांकि, अब वास्तविकताएं ऐसी हैं, जो आने और पेश करने के लिए, उदाहरण के लिए, एक डिजाइनर के लिए, अल्पकालिक "ग्राहक संतुष्टि" पर उसके आरएफपी की निर्भरता एक डिजाइनर के बिना रहने के लिए एक गारंटीकृत तरीका है। इस विषय पर काम करने के लिए बहुत गंभीर संकट की आवश्यकता है। या बहुत अच्छे सुपरफ़्लूड डिज़ाइनर हैं।
- रिलीज की तारीख। सब कुछ तर्कसंगत लगता है: हम समय पर परियोजना सौंपते हैं - हमें बहुत पैसा मिलता है, हम इसे अनुसूची से आगे देते हैं - हमें अधिक पैसा मिलता है। संकेतक उपयुक्त है, लेकिन पहले से ही पहचानी गई समस्या है: सब कुछ डेवलपर पर निर्भर नहीं करता है। समय अंतराल सबसे अधिक बार ग्राहक-प्रबंधक की ओर से उत्पन्न होता है। (इसलिए उचित: "मुझे अपना वेतन क्यों खोना चाहिए, हालांकि इस प्रबंधक ने ग्राहक से सामग्री नहीं ली?")।
ठीक है। ग्राहक के लिए ये क्राइटेरिया गुड जाहिर तौर पर डेवलपर के लिए अच्छा नहीं होगा।
(मुझे कोई भ्रम नहीं है, अब आप आसानी से विभिन्न मानदंडों के 200 टुकड़ों के साथ आ सकते हैं जो व्यवसाय के लिए महत्वपूर्ण हैं। लिखें, हम टिप्पणियों में चर्चा करेंगे :))लेकिन आप उत्पादकता को माप सकते हैं! यह इतना आसान है!या नहीं? इसे कैसे मापें? अगर मैंने बाड़ को चित्रित किया - तो सब कुछ स्पष्ट है। लेकिन एक पकड़ है। हमारे उद्योग में, कोई भी बहुत सोच, रचनात्मक, प्रतिभाशाली लोगों और बाड़ नहीं सोचता है। आइए प्रोग्रामर्स के उदाहरण को देखें। तो, क्या अच्छा प्रदर्शन मानदंड दिमाग में आया?
- KSLOC। क्या आप जानते हैं कि यह क्या है? और हिंदू कोड क्या है - आप जानते हैं? लागू - आप पता लगा लेंगे। KSLOC कोड की हजारों लाइनों की संख्या है। यदि आप इस सूचक को वेतन पर बाँधते हैं, तो कॉपी-पेस्ट की एक हजार पंक्तियों की प्रतीक्षा करें। मेरे एक दोस्त को बैंगलोर में एक पूरा ऑर्डर मिला - एक php स्क्रिप्ट, केवल दस डॉलर में, लेकिन 20 एमबी तक। और उसने काम किया!
- प्रति घंटे कुछ गंदगी की मात्रा (डब्ल्यूटीएफ / एच)। प्रति दिन तैयार किए गए पृष्ठों की संख्या, प्रति घंटे बेची जाने वाली सुविधाओं की संख्या आदि। यह एक सामान्य मीट्रिक लगता है - कुछ को वास्तव में गणना की जा सकती है और बन्स वितरित करने के लिए उपयोग किया जाता है। हालांकि, पिछले पैराग्राफ के समान एक समस्या उत्पन्न होती है: मात्रा की गिरावट की गुणवत्ता में गिरावट, तकनीकी ऋण में वृद्धि। प्रेरणा, रुचि, संतुष्टि - सब कुछ तेजी से नीचे गिर रहा है। नतीजतन, टर्नओवर और कम योग्यता।
- बग की संख्या। कम कीड़े - जितना हम भुगतान करते हैं। सब कुछ तार्किक है, है ना? वास्तव में नहीं। क्या आपके स्टूडियो में बग ट्रैकर लागू किया गया है? यदि हां, तो इसे भूल जाइए। आपके परीक्षक बहुत जल्द आपके प्रोग्रामर के साथ सहमत होंगे कि कितने बग लिखने हैं, और कितने - नहीं, ताकि यह दोनों पक्षों के विरोध में न हो।
- प्रोसेस हो रहा है। "यदि आप काम में देरी करते हैं, तो आप खराब काम करते हैं।" क्या वह भी तार्किक है? हम प्रसंस्करण से जूझ रहे हैं, उदाहरण के लिए, हम 18:00 के बाद बिजली बंद कर देते हैं। हालांकि, यहां हमें याद रखना चाहिए कि डेवलपर का मनोविज्ञान कार्यालय प्लैंकटन के मनोविज्ञान से मौलिक रूप से अलग है: यदि वह शाम तक बैठता है, तो वह दिलचस्पी रखता है (और इसे प्रोत्साहित किया जाना चाहिए)।
हमारे क्षेत्र में, लोग मुख्य रूप से काम करते हैं क्योंकि वे रुचि रखते हैं।बेवकूफ कॉर्पोरेट नियमों के साथ उन्हें परेशान मत करो।
- फोकस फैक्टर। यह मीट्रिक मेरे पसंदीदा घोटाले से हमारे पास आया था। दिखाता है कि कार्य को आदर्श रूप से कितना लेना चाहिए, और अंत में कितना सामने आया। परियोजना पर टीम की "एकाग्रता"। क्या मैं इस कसौटी के आधार पर पैसा दे सकता हूं? काफी, लेकिन, यदि आपके प्रबंधक "तकनीकी" नहीं हैं, तो प्रोग्रामर जानबूझकर अपने समय के अनुमानों को कम कर देंगे, अपने स्वयं के जोखिमों को कम से कम करेंगे। इस दृष्टिकोण का परिणाम यह है कि समय बढ़ाया जाता है, ग्राहक अशिष्ट होता है (या आपसे नहीं खरीदता है)। हां, और प्रत्येक बैठक 10 मिनट में स्क्वैबल्स और विवादों में बदल जाएगी।
- वेग। घोटाले से भी। कुख्यात "प्रदर्शन"। यहाँ यह बहुत स्पष्ट है, मानविकी एक अनुच्छेद को छोड़ सकते हैं।
आपको यह अनुमान लगाने की अनुमति देता है कि टीम अगले चरण में कितने कार्य टाइप कर पाएगी, यह इस बात पर निर्भर करता है कि उसने पिछले एक में कितना काम पूरा किया है। फ़ोकस फ़ैक्टर के रूप में समस्याएं समान हैं, प्लस एक और जोड़ा जाता है। अक्सर प्रबंधक (विशेष रूप से अनुभवहीन), यह महसूस करते हुए कि टीम का प्रदर्शन "मापा" जा सकता है, इस उपकरण का उपयोग दूसरे तरीके से करना शुरू कर देता है। लेकिन वेग एक सटीक मानदंड नहीं हो सकता है, जैसा कि यह दर्शाता है कि एक ही कार्य को एक ही टीम द्वारा एक ही परिस्थितियों में कितना समय लिया जा सकता है। हालांकि, कार्य पूरा करने के बाद, टीम पहले ही बदल चुकी है: उसने इस विशेष समस्या को हल करने के तरीके पर अनुभव प्राप्त किया है। और मीट्रिक फिर से काम नहीं करेगा।
- साइकिल का समय। किसी परियोजना पर एक सुविधा को लागू करने के विचार से उत्पन्न होने वाले क्षण से कितनी जल्दी समय बीत जाता है।
मैं व्यक्तिगत रूप से इस मीट्रिक को वास्तव में पसंद करता हूं। कुंजी में से एक जो मापने और अनुकूलन के लायक है। लेकिन डेवलपर्स इस कारक को सीधे प्रभावित नहीं करते हैं। यह बहुत उच्च स्तरीय मीट्रिक है। यदि आप किसी टीम को साइकिल के समय के आधार पर वेतन देना शुरू करते हैं, तो इसका मतलब है कि आप, एक नेता के रूप में, टीम की समस्याओं को हल करने और प्रक्रियाओं को समझने की कोशिश नहीं कर रहे हैं, लेकिन बस टीम को सब कुछ स्थानांतरित करें।
उच्च-स्तरीय मीट्रिक पर एक डेवलपर के वेतन को निर्भर बनाने का प्रयास प्रबंधकीय नपुंसकता का प्रमाण हैतो, क्या किसी टीम की प्रभावशीलता को मापना संभव है? हां, यह संभव है, खासकर जब से हमने इसके लिए दस संकेतकों के बारे में लिखा है। और एक या दो दर्जन आप टिप्पणियों में सोच सकते हैं। एक और सवाल - क्या यह डेवलपर के वेतन को संकेतकों पर निर्भर करने के लायक है? लेकिन यह पहले से ही जोखिम भरा है।
मैं काम करना शुरू कर रहा हूं, और मेरा काम करना अच्छा है, क्योंकि मैं एक पेशेवर हूं और मुझे दिलचस्पी है। लेकिन अगर वे मुझे बेवकूफ मीट्रिक के साथ बदनाम करना शुरू करते हैं, तो मैं इन बेवकूफ मीट्रिक को अनुकूलित करूंगा। मैं 1000 लाइनें लिखूंगा या प्रति दिन 10 गंदगी डिजाइन तैयार करूंगा। और काम में मेरी दिलचस्पी बहुत, बहुत जल्दी बाहर निकल जाएगी, मैं बेवकूफी से आटा चाहता हूं। इसे आंतरिक प्रेरणा का एक विकल्प कहा जाता है - बाहरी।
एक पागलपन की कहानी
एक बार "मेरे अच्छे दोस्त", स्टूडियो के प्रमुख, को एक बहुत ही उचित पारिश्रमिक शुरू करने का विचार मिला, जो मापदंडों के एक समूह को ध्यान में रखेगा। स्वाभाविक रूप से, उन्होंने इस मामले को भव्य पैमाने पर अपनाया। इस तरह से मापदंड का एक गुच्छा लिखा:
- काम के लिए मासिक योजना-घंटे और वास्तव में काम समय;
- त्रैमासिक बिक्री योजना;
- वार्ड की संख्या और उनके वेतन;
- ग्राहकों (संतुष्टि) से सकारात्मक संचार की मात्रा;
- नई परियोजनाओं के साथ दोहराया ग्राहक अनुरोधों की संख्या;
- विशेष प्रतियोगिताओं में पुरस्कार;
- ग्राहक के साथ नकारात्मक संचार;
- क्यूए द्वारा पाए जाने वाले कीड़े की संख्या;
- प्राप्य में वृद्धि;
- परियोजना की शुरुआत के बाद ग्राहक द्वारा पाए जाने वाले कीड़े की संख्या;
- किताबें पढ़ना, लेख लिखना।
और 20 और। (उपयोगी सूची, इसे दूर ले ;-))।
यह सब एक प्रणाली में एक साथ लाया गया था। स्वाभाविक रूप से, व्यवस्था को संतुलित करना पड़ा। इसलिए, पहले कुछ महीनों में, इसे आभासी "कैंडी रैपर" पर कैलिब्रेट करने का निर्णय लिया गया था। एक बड़े बोर्ड का आविष्कार किया गया था जिस पर कर्मचारियों की एक सूची तैयार की गई थी। विभिन्न "कैंडी रैपर" बोर्ड पर लटका दिए गए थे - तुरंत, जैसे ही भुगतान आया, परियोजना समाप्त हो गई या कुछ अच्छी (या बुरी) घटना हुई, जो भविष्य में वेतन को प्रभावित करेगी।
सचमुच 1 घंटे के भीतर, कर्मचारियों के चेहरे बहुत, बहुत उदास हो गए। कुछ दिनों बाद सवाल शुरू हुआ: "मैं कैंडी रैपर्स कम क्यों हूं?" या "उन्होंने मुझे कैंडी के रैपर क्यों नहीं दिए - क्या मैंने वासा की मदद की?"
मूड भयावह होता जा रहा था। एक सप्ताह के बाद, परियोजनाओं के मूल्यांकन में पहले की तुलना में 4 गुना अधिक समय लगने लगा और प्रत्येक मूल्यांकन डेवलपर और परियोजना प्रबंधक के बीच एक अंतहीन बहस में बदल गया। महीने के अंत तक, कुछ दोस्त की मदद करना चाहते थे - उन्होंने समझाया कि "उनका काम काफी है।" कई तरह की परिस्थितियां सामने आईं, जिन्हें औपचारिक रूप नहीं दिया जा सका। कई कैंडी रैपर व्यक्तिपरक भावनाओं के अनुसार जारी किए गए थे।
कुछ लोग कैंडी रैपर्स के बिना काम करना चाहते थे, तनाव बढ़ गया। उत्पादकता और प्रेरणा गिर गई। एक महीने बाद, कार्यक्रम को बंद कर दिया गया था। कुछ महीनों के बाद, चिंता गायब हो गई।
निष्कर्ष के रूप में:
विभिन्न मैट्रिक्स मापने और सोचने-समझने-सोचने के लायक हैं, उन्हें कैसे प्रभावित किया जाए। लेकिन डेवलपर्स और डिजाइनरों के लिए सीधे उच्च-स्तरीय मीट्रिक को स्थानांतरित न करें। और अधिक।
“डेवलपर में चार घटक होते हैं: शरीर, हृदय, मन और आत्मा।
1. शरीर को धन और सुरक्षा की आवश्यकता होती है।
2. दिल के लिए - प्यार और मान्यता।
3. कारण - विकास और आत्म-सुधार।
4. आत्मा - आत्मबोध। ”
एस। आर्किपेनकोव
अन्य लोगों का सम्मान करें और उन्हें वह करने का अवसर दें जो उन्हें पसंद है))।
और बहुत आखिरी। एक संदेह है कि प्रत्येक नेता को खुद के लिए समझना चाहिए कि क्या उसका संगठन KPI के लिए संक्रमण के लिए तैयार है। मुझे उम्मीद है कि हमारे द्वारा एकत्र किए गए लेखों के इस छोटे से चयन से सही निर्णय लेने में मदद मिलेगी।
- बोनस (जोएल स्पोलस्की) के खतरों पर ।
- मुझे काम करने के लिए परेशान मत करो (Stas Davydov)।
- सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट्स (अस्कैट उरगैब) में मौद्रिक प्रेरणा ।
- एजाइल में मेट्रिक्स (बैठक एजिलेरूसिया । 2009-08-18)।
- पूंजीवादी श्रम (लरिसा खारखिनोवा) के टक्कर के मूल संकेतक ।
- डेवलपर्स को कितना भुगतान करना होगा (हैब्राह्ब, अनुवाद)।
- बिज़नेस इंटेलिजेंस (हैब्राह्ब, वी.पी. सवचुक)।
- आईटी-विशेषज्ञों का अभिप्रेरण (हाबराहाब)।
- एक कंपनी / डिवीजन (हाबराहाब) के प्रबंधन के लिए एक उपकरण के रूप में संतुलित स्कोरकार्ड ।
- अगर शेड्यूल और बजट बहुत महत्वपूर्ण नहीं हैं, तो केपीआई को क्या मापा जा सकता है ।
- आईटी कर्मचारियों के लिए प्रदर्शन संकेतक (KPI) (हैब्राह्ब)।
- प्रेरणा के मिथक। ब्रेकिंग द डेडलॉक (रेनहार्ड स्प्रेंजर)।
- कर्मचारी प्रेरणा के तरीके (जूलिया लाव्रिक)।
- लाभ: जिंजरब्रेड वाले कर्मचारी को कैसे मारें? या प्रेरणा के तरीके (वैलेंटाइन पॉलाकोव)।
- प्रोग्रामर को उनकी उत्पादकता के अनुपात में भुगतान क्यों नहीं किया जाता है (हैब्रह्ब, अनुवाद)।