सबसे अच्छा पीछा करते हुए

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

लेख कुछ लंबा है, क्योंकि मैंने न केवल इनपुट और आउटपुट की व्याख्या करने की कोशिश की, बल्कि सिस्टम को विकसित करने की प्रक्रिया, रास्ते में आने वाले प्रश्न और हमने उन्हें कैसे हल किया। शायद हमारा अनुभव आपके लिए उपयोगी होगा - यदि पूरी तरह से नहीं, तो इसके कुछ हिस्से।

तो, प्रवेश द्वार पर - एक फिक्स पर काम करने वाले तीन लोगों के 1 सी प्रोग्रामर की एक छोटी टीम। इसके अलावा, मैं, उनके नेता, मुख्य क्षमता से, 1 सी प्रोग्रामर भी हैं।

व्यवसाय प्रक्रिया सबसे आम है:

1. प्रोग्रामर को किसी भी विभाग से कार्य सौंपे जाते हैं;
2. कार्य यदि आवश्यक हो, तो अनुमोदन के अधीन हैं। समन्वयक की सूची विभिन्न कार्यों के लिए अलग है;
3. कार्यों की एक समय सीमा है, इसके हस्तांतरण की संभावना है (दो बार से अधिक नहीं)। शुरू करने से पहले, दोनों पक्षों द्वारा समय सीमा पर सहमति व्यक्त की जाती है;
4. एक कैस्केड के आधार पर स्वचालन परियोजनाएं की जाती हैं। परियोजना में कार्य शेष के समान जीवन जीते हैं - समय सीमाएं हैं, अनुमोदन हैं, आदि;
5. ड्यूटी के रूप में तकनीकी सहायता है - प्रोग्रामर 1 सप्ताह के लिए इस पर बैठते हैं।

प्रेरणा प्रणाली :
1. प्रोग्रामर का वेतन, योग्यता पर निर्भर करता है;
2. समय पर पूरा नहीं किए गए कार्यों के लिए एक डीमोटीशन है;
3. परियोजनाओं के कार्यान्वयन के लिए बोनस हैं।

इस सभी सामान का स्वचालन सबसे आम है। लक्ष्य निर्धारित करने के लिए, एक सामान्य उद्यम प्रणाली का उपयोग किया जाता है, जैसे 1C: दस्तावेज़ प्रबंधन। इसमें निर्देश और मेमो हैं, जिसमें कार्य रहते हैं। कैस्केडिंग परियोजना प्रबंधन का एक छोटा सा स्वचालन है। समय सीमा के उल्लंघन के मामले में डिमोनेटाइजेशन की एक स्वचालित गणना है।

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

लेकिन एक सवाल ने हमें परेशान किया - अधिक पैसा कैसे कमाया जाए?

वर्तमान प्रणाली में दो लीवर थे - वेतन या परियोजना पुरस्कारों में वृद्धि प्राप्त करने के लिए। कंपनियां आमतौर पर 1C प्रोग्रामर का वेतन बढ़ाना पसंद नहीं करती हैं, क्योंकि वे शायद ही समझते हैं कि इस आदमी को अधिक पैसे देने की आवश्यकता क्यों है ।

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

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

परियोजना पुरस्कार बढ़ाने के लिए कड़ी मेहनत करना भी असंभव है, क्योंकि विषय बल्कि फिसलन है। यह पसंद है या नहीं, एक परियोजना पुरस्कार काम के लिए एक अतिरिक्त भुगतान है जिसके लिए यह पहले ही भुगतान किया जा चुका है । बेशक, आप किसी भी तरह इसे फिर से लागू कर सकते हैं, उदाहरण के लिए, अनुसूची के आगे प्रदर्शन करने के लिए, या कार्यान्वयन में सक्रिय रूप से भाग लेने के लिए, या ग्राहकों की आवश्यकताओं के लिए जल्दी से स्वचालन लाने के लिए एक अतिरिक्त शुल्क।

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

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

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

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

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

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

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

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

यदि सबसे अच्छा प्रोग्रामर समस्या को 1 घंटे में हल करता है, तो इसकी लागत 1 घंटे है। एक अन्य प्रोग्रामर जो 4 घंटे में इस समस्या का हल करता है, उसे इसके लिए 1 भुगतान घंटे प्राप्त होगा।

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

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

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

क्लासिफायर में निहित, उदाहरण के लिए, निम्नलिखित आइटम:

• एक साधारण रिपोर्ट का विकास, जैसे "बिक्री", एक रजिस्टर, उपयोगकर्ता मोड में एसीएस पर। स्कोर - 15 मिनट;
• संचय के एक रजिस्टर का निर्माण, दस्तावेज़ के संदर्भ द्वारा पूरी तरह से निर्धारित आंदोलनों की एक सरल रिकॉर्डिंग के साथ। स्कोर - 15 मिनट;
• आरएलएस के बिना भूमिका विकास, अनुमत वस्तुओं की एक छोटी सूची (10 तक) के साथ। रेटिंग - 10 मिनट।

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

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

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

सरल गणना और गोलाई ने हमें प्रति घंटे सर्वश्रेष्ठ प्रोग्रामर की प्रति घंटा दर दी: 600 रूबल प्रति घंटा ।

यह आंकड़ा अच्छा लगेगा, क्योंकि यह स्थानीय फ्रैंचाइज़ी की प्रति घंटा की दर से कम है, और फ्रीलांसरों की लागत से कम है, जिन्होंने तब प्रति घंटे 700-900 रूबल की मांग की थी।

लेकिन मुख्य बात - केवल प्रत्यक्ष कार्य हमारे प्रति घंटा की दर का हिस्सा था। कोई प्रतिबिंब, मॉडलिंग, निर्णय विश्लेषण आदि नहीं था।

हालांकि, यह महसूस करते हुए कि नेतृत्व के साथ इस शर्त के बारे में बातचीत अभी भी होगी, हमने यह सुनिश्चित करने का निर्णय लिया कि हम सही थे। ऐसा करने के लिए, दोस्तों और अजनबियों फ्रेंचाइजी और फ्रीलांसरों के साथ बात की। हमने इन लोगों को मूल्यांकन करने के लिए कुछ कार्य दिए, और एक सरल प्रश्न पूछा - आप इस तरह के काम के लिए कितना पैसा लेंगे? परिणाम पूर्वानुमेय था - दोस्तों ने काम करने के लिए 2-3 गुना अधिक काम करने के लिए कहा (वेतन पर कर करों को ध्यान में रखते हुए)। यह शांत हो गया - गधा ढंका हुआ है।

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

दूसरी तरफ कंपनी है। बस एक न्यूनतम भुगतान लाभहीन है, क्योंकि इसका उपयोग सिस्टम को ट्रिक करने के लिए किया जा सकता है। उदाहरण के लिए, राज्य में "लगभग तैयार" होने से एक महीने पहले 20 कार्य करने के लिए, एक वेतन प्राप्त करें, और अगले महीने एक सफलता प्राप्त करें, 20 अधूरे कार्यों और 30 और नए कार्यों को बंद करें, और एक सौदा प्राप्त करें। वैसे, फ्रैंचाइज़ी में यह ऐसा ही था, और सभी ने इसका इस्तेमाल किया।

स्थिति से बाहर का रास्ता भी सरल है - "माइनस याद रखें । " उन्होंने 40 tr पर काम किया, 60 tr का वेतन प्राप्त किया - ठीक है, माइनस 20 tr को याद रखें अगले महीने आपको करना होगा। अगले महीने 80 tr पर काम करें - आपको 60 tr मिलते हैं, और आपको नहीं चाहिए।

उसी समय, बस के मामले में, हम पेआउट सीलिंग सेट करते हैं - 100 ट्र। हम इस बात से सहमत थे कि इस राशि से अधिक में किए गए काम को अगले महीने में एक प्लस माना जाएगा।

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

समाधान भी सरल है, और फिर से दूसरों द्वारा झाँका जाता है - परियोजना के अंत में टुकड़े टुकड़े के वेतन का हिस्सा जमा करने और देने के लिए । हमने तय किया कि हमारे साथ यह 20% होगा। जबकि परियोजना चल रही है, प्रोग्रामर को प्रति घंटे 480 रूबल मिलते हैं, और परियोजना के अंत में प्रत्येक घंटे से शेष 120 रूबल।

खैर, सब कुछ गणना और विचार के लिए लग रहा था, परीक्षण ऑपरेशन शुरू करना आवश्यक है।

पहला कदम प्रोग्रामर्स की व्यावसायिक प्रक्रिया को बदलना था:
1. कार्य अब व्यक्तिगत रूप से कलाकार के लिए नहीं, बल्कि मेरे लिए, नेता के लिए निर्धारित होना चाहिए;
2. मुझे अब प्रत्येक कार्य का मूल्यांकन घंटों में करना है;
3. स्वीकृति और मूल्यांकन के बाद, कार्य कार्यान्वयन के लिए उपलब्ध हो जाता है।

ठीक है, व्यवसाय प्रक्रिया बदल दी गई है, इसे स्वचालित करने के लिए आवश्यक है। रचनात्मकता की अधिक स्वतंत्रता के लिए, हमने असाइनमेंट और मेमो (सभी ने उनका उपयोग किया) का उपयोग करना बंद कर दिया, और हमने 1-2 दिनों में अपने लिए दो नई वस्तुएं बनाईं:
1. हमारे मूल्यांकन के लिए सभी आवश्यक क्षेत्रों के साथ आईटी विभाग के लिए एक आवेदन;

2. एक ही मूल्यांकन प्रणाली के साथ उन में परियोजनाओं और कार्यों के लिए लेखांकन की एक सरलीकृत प्रणाली।

और तुरंत उन्होंने एक रिपोर्ट बनाई जो घंटों में आउटपुट दिखाती थी और पैसा कमाती थी ताकि प्रोग्रामर हर दिन अपना परिणाम देख सकें।

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

मैंने उनकी बात सुनी, और सवाल की दार्शनिक गहराई पर प्रतिबिंबित करना शुरू किया: क्या कंपनी को अपने कर्मचारियों द्वारा ज्ञान के अधिग्रहण के लिए भुगतान करना चाहिए?

ऐसा लगता है कि उत्तर स्पष्ट है - यह होना चाहिए। लेकिन क्या यह सब इतना स्पष्ट है? क्या निकला।

यहां एक प्रोग्रामर के लिए एक कार्य है - पोस्टिंग में वेयरहाउस उप-खाते को 003 से भरने के लिए (किसी कारण से, यह एक मानक नरम स्टार्टर में नहीं भरा गया है)। लेकिन वह यह नहीं जानता कि इसे कैसे संसाधित किया जाए, न तो ठेकेदार की तरफ से, न ही प्रोसेसर की तरफ।

ऐसा लगता है - बैठो और यह पता करो कि ऐसा क्या था, हमेशा ऐसा किया। पारंपरिक वेतन प्रणाली में, नियोक्ता आपको उस समय का भुगतान करेगा जब आप वहाँ के आसपास प्रहार करेंगे।

लेकिन यह इतना आसान नहीं है। चार लोगों में से (तीन प्रोग्रामर + मैं, प्रमुख), दो प्रसंस्करण में पारंगत हैं, और यह कार्य किसी ऐसे व्यक्ति के पास चला गया जो इसे नहीं समझता है। हमने रीसाइक्लिंग को कब समझा? प्रोग्रामर आखिरी काम पर है, मैं वर्तमान स्थान पर हूं, क्योंकि पहले कोई टोलिंग / रीसाइक्लिंग अभ्यास नहीं था। यह पता चला है कि वर्तमान कंपनी पहले ही इस योग्यता के लिए भुगतान कर चुकी है । और ऐसा लगता है कि दूसरी बार, कम से कम एक ही राशि का भुगतान करना गलत है। अब क्या करने की जरूरत है? यह सही है, कार्य प्राप्त करने वाले के लिए योग्यता हस्तांतरण।

एक और सवाल उठता है - और क्या क्षमता के वाहक को इसकी आवश्यकता है? उसके पास एक टुकड़ा-दर वेतन भी है, और ज्ञान को स्थानांतरित करने के बजाय, वह बेहतर काम करेगा।

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

तो, समाधान हमारे लिए स्पष्ट हो गया:
1. ज्ञान के हस्तांतरण और मदद के लिए एक दूसरे को भुगतान करना होगा;
2. नई दक्षताओं के अधिग्रहण के लिए भुगतान किया जाना चाहिए।

दूसरा बिंदु ज्ञान के बारे में है जो टीम के पास नहीं है। उदाहरण के लिए, हमारे पास MS SQL में सीधे प्रश्नों का उपयोग करके बाहरी सिस्टम से डेटा को 1C में लगातार खींचने का कार्य था। कार्य कठिन नहीं है, लेकिन किसी ने भी पहले ऐसा नहीं किया है। मैंने ऐसा किया - मैंने अपनी ओर से एक आवेदन किया, जिसका सार एक विशिष्ट समस्या को हल करने के लिए पर्याप्त स्तर पर बाहरी डेटा स्रोतों के साथ काम करना है। कार्य का आकलन - 1 घंटा (और आप पूरे दिन कम से कम बैठ सकते हैं)।

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

हमने दक्षताओं के हस्तांतरण और पारस्परिक सहायता के लिए भुगतान करने का फैसला किया, और इसके लिए हम उपयुक्त शब्द - विश्लेषण और डिजाइन की लागतें लेकर आए। बड़ी नौकरशाही पर समय बर्बाद न करने के लिए, हमने डेटा वाले शब्द में एक तालिका आकर्षित की:
1. जिस मुद्दे पर चर्चा / डिजाइन / संदर्भित किया गया था;
2. चर्चा का आरंभ और अंत समय, मिनटों तक सटीक;
3. प्रतिभागियों।

लेखांकन प्रणाली में एक अलग दस्तावेज़ जोड़ा गया था, जिसमें ऐसी चर्चाओं के परिणाम सप्ताह में एक बार आते थे। आमतौर पर चर्चा 5 मिनट में , कभी-कभी 15 मिनट तक पहुंच जाती है। एक हफ्ते के लिए यह सभी 3-5 घंटों के लिए निकला ।

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

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

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

औपचारिक रूप से, उस समय तकनीकी सहायता एक समर्पित कर्तव्य अधिकारी होता है जिसे एक सप्ताह के भीतर लोगों की मदद करनी चाहिए। तकनीकी सहायता पर बैठने वाले प्रोग्रामर को कितना भुगतान करना है?

सबसे पहले, विचार बिल्कुल भुगतान करने का नहीं था, लेकिन भुगतान की गणना करते समय वेतन की गणना के लिए आधार को कम करने के लिए। उदाहरण के लिए, यदि किसी प्रोग्रामर का वेतन 60 tr है, तो तकनीकी सहायता पर महीने में 2 सप्ताह खर्च किए जाते हैं, तो गणना करते समय, 30 tr के आधे वेतन पर और बाकी समय के लिए, इस सौदे पर विचार करें।

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

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

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

यह स्पष्ट है कि केवल तकनीकी सहायता में संलग्न होना लाभहीन है - यह एक महीने में लगभग 25 हजार रूबल है।

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

दरअसल, इस पर चित्र का गठन किया गया था, और हमने सिस्टम का परीक्षण संचालन जारी रखा ।

प्रोग्रामर के बीच अभूतपूर्व उत्साह था । कार्य पर बंद, धुआँ निष्पादन में एक स्तंभ के रूप में खड़ा था।

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

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

एक अंतर्मुखी प्रोग्रामर ग्राहकों के साथ अधिक बार संवाद करना शुरू कर देता है, जो दो दिनों के लिए पहले से ही हल किए गए कार्य पर बैठ सकता है क्योंकि वह ग्राहक के साथ बात करने के लिए शर्मिंदा था।

उपयोगकर्ताओं से बहुत अधिक समझदार, उच्च-गुणवत्ता वाले कार्य दिखाई देने लगे, क्योंकि प्रोग्रामर उनके डिजाइन में मदद करने लगे।

नौसिखिए प्रोग्रामर, जो सहयोगियों से एक सवाल पूछने में शर्माते थे, क्योंकि यह "विचलित करने के लिए असुविधाजनक है, नाराज़ हो जाएगा" (मुझे कहना होगा, वे वास्तव में नाराज थे) एक समय पर और बेवकूफ थे।

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

मेरी भागीदारी पारदर्शी और समझ में आ गई है, ये व्यवसाय प्रक्रिया में केवल एक बिंदु हैं:
1. कार्यों की स्वीकृति और मूल्यांकन, मैंने दिन में एक बार ऐसा किया, लगभग 15 मिनट के लिए;
2. विश्लेषण और डिजाइन पर बैठकों में भागीदारी (यह 5 मिनट के लिए दिन में ~ 3 बार है)।

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

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

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

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

परीक्षण ऑपरेशन के बाद, मैं नई प्रणाली की रक्षा के कई पुनरावृत्तियों से गुजरा: कर्मियों के निदेशक, वित्तीय निदेशक, निदेशक, मालिक, बाहरी एचआर सलाहकार (मॉस्को, यह बहुत प्रसिद्ध लगता है)। सभी को सिस्टम पसंद आया।

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

इसके बाद, इस प्रणाली के सिद्धांत अन्य उद्यम प्रेरणा प्रणालियों के लिए बुनियादी बन गए।

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

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

हमने यह भी सीखा कि जो लोग हमेशा "हम में व्यस्त नहीं होते हैं" स्वचालन के लिए सभी पैसे का 40% उपभोग करते हैं।

यह उन परियोजनाओं के लिए महीने-दर-महीने बढ़ते बजट को देखने के लिए दिलचस्प था, जिनके पास एक मेजबान नहीं था (यह तब है जब निदेशक, उदाहरण के लिए, कहते हैं - इस सेवा को स्वचालित करें, और स्वचालन कहीं भी नहीं चलेगा, लेकिन उन्हें कार्य स्वयं लिखना होगा, इसलिए वे मंडलियों में घूमते हैं) ।

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

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

पुनश्च

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

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

आप हमेशा सोचना चाहते हैं, लेकिन समाप्त करने के लिए नहीं। Scrum, PMBOOK, CORE PM, Kanban, CBT या कुछ और, "लागू करें" या, अधिक फैशनेबल, "लागू करें"। और कुछ गधों, जैसे स्क्रम गाइड डेवलपर्स, "कुछ भी गलत तरीके से कर रहे हैं, अगर आप ऐसा कर रहे हैं, तो कुछ कहकर स्थिति को भड़का रहे हैं, तो आपको डरने की ज़रूरत नहीं है।" हालांकि किताब में उन्होंने खुद लिखा है कि आपको अपने सिर के साथ सोचने की जरूरत है।

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

आप इसे कैसे पसंद करते हैं? क्या यह मददगार है? या मधुमक्खी, श्रम नहीं, यह 1 सनिकोव के बारे में है।