हमारे उद्योग में कार्यों को मापने का पारंपरिक तरीका घड़ी है। आइए गणना करें कि हम उपयोग की जाने वाली घड़ी में कितने मीट्रिक हैं।
पहला, सबसे महत्वपूर्ण घंटे वे हैं जो हम क्लाइंट पर डालते हैं। स्थिति के आधार पर, हम या तो घड़ी पर पहले से सहमत हैं, या इस तथ्य को निर्धारित करते हैं - प्रोग्रामर ने कितना खर्च किया।
दूसरे घंटे वे होते हैं जो प्रोग्रामर को बुलाए जाते हैं, जो इस सवाल का जवाब देते हैं कि "आपको समस्या को हल करने के लिए कितना समय चाहिए?"। यदि हम ग्राहक के साथ पहले से सहमत हैं, तो इन घड़ियों को बिक्री के लिए रखा गया है। यदि तथ्य के बाद भुगतान किया जाता है, तो हम प्रोग्रामर को नियोजन उद्देश्यों के लिए मूल्यांकन के लिए कहते हैं।
तीसरे घंटे - वास्तव में समस्या को हल करने पर प्रोग्रामर ने कितना खर्च किया। यह घड़ी नियोजित संख्या के साथ अत्यंत दुर्लभ रूप से मेल खाती है, जिसे उन्होंने खुद कहा था, और यह सामान्य है - कोई भी नहीं जानता कि अपना समय कैसे ठीक से नियोजित किया जाए, क्योंकि प्रोग्रामर के काम पर पर्यावरण की बहुत सारी ताकतें काम करती हैं - वह विचलित होता है, उसका सामना नहीं होता है। अप्रत्याशित कठिनाइयों आदि के साथ।
चौथे घंटे भी हैं - जब हम ग्राहक को पहले से सहमत एक से अलग राशि निर्धारित करते हैं। बेशक, अगर हमारे सहयोग की शर्तें हमें ऐसा करने की अनुमति देती हैं।
और अब ध्यान, सवाल यह है: आप दक्षता पर कहां काम कर सकते हैं? या दूसरे तरीके से: क्या हम बढ़ेंगे की प्रभावशीलता?
एक अस्पष्ट जवाब दे सकते हैं: प्रोग्रामर की दक्षता। खैर, कैसे, और हम क्या मापेंगे? हमारी उपस्थिति में, मैं आपको तीन या चार प्रकार की घड़ियों को याद दिलाता हूं।
प्रोग्रामर को बताने का प्रयास करें: हम चाहते हैं कि आप अधिक घंटे का उत्पादन करें। वह क्या जवाब देगा? प्रोग्रामर एक बुद्धिमान लड़का है, उसने संस्थान में अध्ययन किया, और वह तुरंत पांचवें मीट्रिक को याद करता है - एक दिन में घंटों की संख्या। और साहसपूर्वक आपको इसके बारे में बताता हूं - मैं दिन में 24 घंटे से अधिक काम नहीं कर सकता, भगवान से डरता हूं।
वह सापेक्षता के सिद्धांत को भी याद रखेगा। यहां तक कि अगर यह विवरण में नहीं है, तो यह निश्चित रूप से संपीड़ित समय की असंभवता का उल्लेख कर रहा है - क्या हम प्रकाश के करीब गति पर नहीं बढ़ रहे हैं?
यदि घड़ी सिकुड़ती नहीं है, तो दक्षता कैसे बढ़ाई जाए? आप इसके बारे में कैसे बात कर सकते हैं? आप इसे कैसे गिन सकते हैं? प्रोग्रामर ने प्रति घंटे कितने घंटे खर्च किए? काम के एक घंटे पर आधे घंटे खर्च करें? कैसे एक सूत्र बनाने के लिए? सूत्र के बिना, आपने कोई गणना नहीं की है, और आपने एक लक्ष्य निर्धारित नहीं किया है।
दूसरी तरफ चलते हैं। एक प्रोग्रामर नहीं, बल्कि एक कारखानेदार की कल्पना करें। यहाँ वह गरीब साथी है, मशीन में एक पूरी शिफ्ट और भागों का उत्पादन करता है। उसका काम कैसे नियोजित है? मान लीजिए कि प्रति शिफ्ट में सौ भाग हैं। परिवर्तन आठ घंटे तक रहता है, यह एक भाग के लिए 4.8 मिनट निकलता है।
अब कल्पना करें: हम, काम को मापने के हमारे दृष्टिकोण के साथ, इस कार्यकर्ता का नेतृत्व करने के लिए आए हैं। अब हम उसे "100 भाग करते हैं" नहीं बताते हैं, हम घंटों में मापना पसंद करते हैं, इसलिए नई कार्य योजना "शिफ्ट के 8 घंटे" की तरह लगेगी।
वह, निश्चित रूप से, पहले हमें बेवकूफों पर विचार करेगा। वह पूछता है - लेकिन कितने विवरण होने चाहिए? इससे कोई फर्क नहीं पड़ता, हम जवाब देंगे मुख्य चीज घड़ी है। हम समझते हैं कि विविधताएं हैं, आप धुएं के लिए वहां जाते हैं, दोस्तों के साथ चैट करते हैं, लेकिन हम औसत बिल की कल्पना करते हैं - प्रति मिनट 4.8 मिनट। इसलिए, अपने काम के 4.8 मिनट के लिए हमें 100 बार करें।
सबसे पहले, निश्चित रूप से, वह पुरानी योजना का पालन करने की कोशिश करेगा, लेकिन जब वह अपनी गणना देखता है, तो उसके जीवन मूल्यों में बदलाव आएगा - यह कहेगा "8 घंटे की 20 पारियों में गणना की गई है।" सामान्य रूप से विवरण देने के लिए अब उसके पास क्या बिंदु है, अगर मशीन पर केवल समय का भुगतान किया जाता है?
यदि उस समय तक उन्होंने हमें कारखाने से बाहर नहीं निकाला था, तो हम बिक्री प्रणाली को बदल देंगे। हम ग्राहकों को भागों को नहीं बेचेंगे - चालान हमारे श्रमिकों द्वारा खर्च किए गए घंटे दिखाएगा। ग्राहक 100 भागों के लिए पूछता है, हम सोचना छोड़ देते हैं, फिर हम एक चालान भेजते हैं - 8 घंटे का विशेषज्ञ काम। ग्राहक आश्चर्यचकित है, लेकिन इससे सहमत है, और बिल का भुगतान करता है। और कुछ दिनों के बाद उसे एक और "वृद्धि" मिलती है - कुछ घंटे। खैर, क्या हुआ। कार्यकर्ता 8 घंटे के भीतर नहीं रख सका।
ग्राहक नाराज होना शुरू कर रहे हैं - आखिर क्या, किस तरह की घड़ी? हमें विवरण चाहिए! टुकड़ों, बक्से, पैलेट, वैगनों में - इससे कोई फर्क नहीं पड़ता। यह हमें कोई फर्क नहीं पड़ता कि उन्हें उत्पादन करने के लिए कितने घंटे की आवश्यकता है!
यहाँ, मुझे लगता है, वे निश्चित रूप से हमें मारेंगे। ग्राहकों के लिए आंतरिक और बाहरी दोनों ही टुकड़ों में हिसाब-किताब लौटाएँ। और दक्षता में लगेगी।
यहां दक्षता कहां है, इसका सूत्र क्या है? उत्तर स्पष्ट है: श्रमिक, या कार्यशाला, या पूरे संयंत्र का उत्पादन प्रति यूनिट अधिक भागों, बेहतर है। बेशक, प्रौद्योगिकी, सभ्य गुणवत्ता और कोई स्टॉकिंग के अधीन।
लेकिन दक्षता का सूत्र स्पष्ट है - प्रति घंटे टुकड़े। और दक्षता में सुधार के लिए प्रबंधन प्रयासों के आवेदन के लिए दिशा-निर्देश स्पष्ट हैं।
हम, अपने प्रोग्रामर के पास वापस चले गए। और हम प्रभावशीलता की गणना के लिए एक सरल और समझने योग्य सूत्र भी चाहते हैं। हमारे पास वहाँ क्या है? घड़ियाँ, घड़ियाँ, घड़ियाँ - घड़ियाँ।
अब आप पहले ही समझ गए हैं कि घड़ी में क्या गड़बड़ है। एक घड़ी उपाय समय - आपके नियंत्रण से परे एक भौतिक घटना है जो हुआ है, हो रहा है और हमेशा होगा। इससे कोई फर्क नहीं पड़ता कि आप काम करते हैं या नहीं, आपकी कंपनी मौजूद है या बंद हो गई है, आपके पास ग्राहक हैं या नहीं - समय जाएगा, और इसे घंटों में मापा जाएगा।
लेबर कोड द्वारा आपको आवंटित घंटों के दौरान आप अपनी गतिविधियों का प्रबंधन कर सकते हैं, अर्थात्। कुछ का उत्पादन करें, और किसी भी तरह से जो आप का उत्पादन करते हैं।
पौधे के मामले में, सब कुछ स्पष्ट है - भौतिक इकाइयों में एक माप है। टुकड़े, लीटर, रैखिक, वर्ग या घन मीटर। और हमारे साथ, प्रोग्रामर, क्या करना है? घंटों को छोड़कर, हमारे कार्यों को क्या मापें?
पहली बात जो दिमाग में आती है वह है टुकड़े। लेकिन ऐसा विचार व्यवहार्य नहीं है - कार्यों के बीच भिन्नता बहुत अधिक है।
वास्तव में, उत्तर लंबे समय से तथाकथित में पाया गया है। लचीले विकास के तरीके, जैसे कि घोटाला। विधि को "पोकर योजना" कहा जाता है।
पोकर नियोजन कार्यों को किन इकाइयों में मापा जाता है? उत्तर असामान्य है - किसी भी में। आप जो चाहते हैं, उन्हें बुलाओ। कुत्ते, तोते, मल, अंक, चश्मा - यह कोई फर्क नहीं पड़ता। सबसे आम नाम कहानी अंक (कहानी अंक, कहानी अंक) है। व्यक्तिगत रूप से, मुझे सरल और अधिक संक्षिप्त - अंक पसंद हैं। मैं इसे आगे के प्रदर्शन के दौरान उपयोग करूंगा। आप निश्चित रूप से, किसी अन्य को चुन सकते हैं।
अंकों की एक प्रमुख विशेषता उनकी सापेक्षता है। यह कुछ क्लासिफायर से माप की इकाई नहीं है, बल्कि प्रत्येक कंपनी या टीम के लिए एक अनूठा पैमाना है। एक ही कार्य, दो अलग-अलग टीमों में, अलग-अलग मूल्यांकन किया जा सकता है। कहीं - कहीं पाँच अंक, कहीं - तेरह, आदि।
अंकों की संख्या - यह कार्य का वास्तविक आकार है। बहुत मूल्यांकन जो हमारे पास अभाव था।
पोकर नियोजन तकनीक फाइबोनैचि श्रृंखला के अनुमानों का उपयोग करने की सिफारिश करती है: 1, 2, 3, 5, 8, 13, 21, 34, आदि। अंक, जहां प्रत्येक बाद का तत्व पिछले दो के योग के बराबर है। कारण सरल है: रेटिंग के बीच एक महत्वपूर्ण अंतर होना चाहिए। उदाहरण के लिए, 5 और 6 अंक के बीच की रेटिंग चुनना मुश्किल है। बहुत आसान है - 5 और 8, या 8 और 13 के बीच।
कार्यप्रणाली टीम का मूल्यांकन करने की सिफारिश करती है। सभी टीम के सदस्यों को उनके (फिबोनाची श्रृंखला से) लिखे गए अंकों के साथ कार्ड निपटाए जाने चाहिए। आप पोकर प्लानिंग के लिए विशेष कार्ड खरीद सकते हैं, यदि आप कुछ सुंदरता चाहते हैं, लेकिन सादगी के लिए कागज के साधारण छोटे टुकड़े लेने के लिए पर्याप्त है, जैसे स्टिकर, केवल एक चिपकने वाली पट्टी के बिना।
इसलिए, टीम इकट्ठा हुई, प्रत्येक ने एक कार्ड पकड़ा। एक कार्य की घोषणा की गई है, इसकी विशेषताओं और विवरणों को सूचीबद्ध किया गया है ताकि हर कोई यह समझ सके कि क्या किया जाना चाहिए। उसके बाद, प्रत्येक प्रतिभागी अपना स्वयं का मूल्यांकन करता है - कार्ड में से एक का चयन करता है - और इसे नीचे टेबल पर रखता है (ताकि मूल्यांकन दिखाई न दे)।
जब सभी ने मूल्यांकन किया है, कार्ड खत्म हो गए हैं, और एक महत्वपूर्ण जांच की गई है - ऐसे अनुमान नहीं होने चाहिए जो एक दूसरे से अलग-अलग होते हैं जो कि फिबोनाची श्रृंखला के एक से अधिक तत्वों द्वारा अलग हो जाते हैं।
उदाहरण के लिए, ग्रेड 5 और 8 सामान्य हैं, और ग्रेड 3 और 8 अच्छे नहीं हैं। अनुमानों में बहुत अधिक ओवरशूट बताता है कि किसी को कुछ समझ नहीं आया। जो लोग कम रेटिंग देते हैं वे या तो बहुत अधिक जानते हैं (उदाहरण के लिए, पहले से ही इस तरह की समस्या को हल कर चुके हैं), या कुछ भी समझ में नहीं आया है और बहुत आशावादी हैं।
इसी तरह, एक उच्च स्कोर कार्य की गलतफहमी का संकेत दे सकता है। उदाहरण के लिए, एक प्रोग्रामर ने कभी भी इस तरह की समस्याओं को हल नहीं किया है, या वे उसके लिए अज्ञात प्लेटफॉर्म तंत्र से जुड़े हुए हैं, और वह, केवल मामले में, रिजर्व में, एक उच्च अंक देता है।
किसी भी मामले में, यदि अनुमानों में बहुत बदलाव आया है, तो एक दूसरी चर्चा की आवश्यकता है - विवरणों को स्पष्ट करने के लिए, सूक्ष्मताओं पर चर्चा करें, और अधिकतम जानकारी दें। जब चर्चा होती है, तो मूल्यांकन दोहराया जाता है। यदि आवश्यक हो, तो बार-बार, जब तक कि अनुमान श्रृंखला के एक तत्व से अधिक नहीं एक दूसरे से अलग हो जाते हैं।
कभी-कभी टीम के सदस्यों में से किसी एक को किसी विशिष्ट कार्य के मूल्यांकन से बाहर करना उपयोगी होता है। उदाहरण के लिए, यदि टीम में कोई इंटर्न है, तो कम से कम उसे समझाएं, कम से कम उसे समझाएं नहीं - वह यह नहीं समझेगा कि कठिनाई क्या है या, इसके विपरीत, कार्य की सादगी। अंत में, वह बस सहमत होता है और वांछित रेटिंग डालता है ताकि टीम को देरी न हो।
इस तरह के परिणाम का कोई मूल्य नहीं होता है, क्योंकि यह पोकर नियोजन को एक औपचारिकता में बदल देता है। इसलिए, मैं एक सरल नियम की सिफारिश करता हूं: केवल वे लोग जो कार्य में कुछ समझते हैं, वे कार्य के मूल्यांकन में भाग लेते हैं। आप समझते नहीं हैं - बस बैठो और सुनो।
बेशक, कभी-कभी ऐसा होता है कि केवल एक ही व्यक्ति कार्य को समझता है। उदाहरण के लिए, यदि यह कुछ बहुत विशिष्ट है, तो शायद ही कभी ज्ञान का उपयोग किया जाता है। यह ठीक है, एक मूल्यांकन होने दो।
एक चरम मामला है - कोई नहीं समझता कि समस्या को कैसे हल किया जाए। यह भी ठीक है - हमने यह निर्धारित किया कि क्या हुआ, फिर हम इसका पता लगाएंगे।
जब ग्रेड निर्धारित होते हैं, तो अंकगणितीय औसत माना जाता है - यह कार्य का अंतिम ग्रेड होगा। लचीली कार्यप्रणाली में, वे इसे एक स्टिकर पर लिखते हैं और इसे एक व्हाइटबोर्ड पर लटका देते हैं, लेकिन मैं इसे आपके सूचना तंत्र में जोड़ने की सलाह देता हूं, जहां आप कार्य लिखते हैं। बेशक, आपको पहले उपयुक्त फ़ील्ड जोड़ना होगा।
एक अन्य मूल्यांकन एल्गोरिथ्म एक कमांड का उपयोग किए बिना है। उदाहरण के लिए, अंक एक नेता, या एक नेता, या सबसे बुद्धिमान प्रोग्रामर द्वारा दिए जा सकते हैं। आमतौर पर, वे कई हफ्तों या महीनों के लिए पोकर टीम खेलने के बाद इस एल्गोरिदम पर जाते हैं।
कारण सरल है: यह आवश्यक है कि सभी टीम के सदस्य मूल्यांकन प्रणाली के आदी हों। वे इसे भेदते थे, सीखते थे कि कार्यों का त्वरित मूल्यांकन कैसे किया जाता है, और एक नए द्वार पर एक राम की तरह, बिंदुओं को नहीं देखा। जब एक आदत विकसित हो गई है, तो एक व्यक्ति का मूल्यांकन किया जा सकता है। बेशक, टीम को अपनी राय व्यक्त करने का अधिकार छोड़ दें - कोई भी सही नहीं है, और नेता अनुमानों में गलत हो सकता है।
कभी-कभी टीमों को अंकों के साथ काम की शुरुआत में कठिनाइयाँ होती हैं - किसी को नहीं पता कि संदर्भ बिंदु के लिए क्या चुनना है। मैं कई एंकर चुनने की सलाह देता हूं - विशिष्ट कार्य जिन्हें आप समय-समय पर हल करते हैं।
पहला एंकर सबसे आसान काम है। एक नियम के रूप में, जहां तक मुझे पता है, प्रोग्रामर द्वारा बिताया गया समय 15 मिनट से अधिक का शुल्क लिया जाता है। आप आम तौर पर 15 मिनट में कौन से कार्य हल करते हैं? एक साधारण रिपोर्ट? डेटाबेस में एक उपयोगकर्ता जोड़ना? एड्रेस क्लासिफायर भरना?
इस कार्य को 1 अंक का स्कोर दिया जाना चाहिए। भविष्य में, आप इसके द्वारा निर्देशित होंगे।
आप अपनी बारीकियों के आधार पर कुछ और एंकर जोड़ सकते हैं। उदाहरण के लिए, एक अवशिष्ट रजिस्टर पर एक साधारण बाहरी रिपोर्ट, बिना घंटी और सीटी के, फॉर्म और मॉड्यूल में कोड के बिना - इसे 3 अंक होने दें। दस्तावेज़ में आवश्यक दस्तावेज जोड़ें और फॉर्म पर प्रदर्शन करें, इनपुट और जांच के बिना - इसे 2 अंक दें। आदि
यह महत्वपूर्ण है कि टीम खुद इन एंकरों का चयन करे, उनसे सहमत हो और भविष्य में उनका उपयोग करे। अनुमान सापेक्ष हैं, और एंकर प्रारंभिक बिंदुओं की भूमिका निभाएंगे।
अब हमारे सभी कार्यों को भौतिक इकाइयों - बिंदुओं में मापा जाता है। हम जानते हैं कि एक सप्ताह, महीने, वर्ष आदि में कितने बिंदु पूरे हुए। हम जानते हैं कि प्रत्येक प्रोग्रामर कितने पॉइंट्स का उत्पादन करता है। हम स्पष्ट रूप से देखते हैं कि कितने अंक "वजन" अनसुलझे कार्य करते हैं।
लेकिन सबसे महत्वपूर्ण बात, हम प्रभावशीलता को घंटों के अंकों के अनुपात के रूप में जानते हैं। बेशक, प्रति दिन अंक गिनना आसान है।
एक प्रोग्रामर एक दिन में 4 अंक बनाता है, दूसरा - 8, तीसरा - 2. पिछले सप्ताह हमने 50 अंक बनाए, इस सप्ताह - 80, जिसका अर्थ है कि हमारी दक्षता में वृद्धि हुई है।
दक्षता बढ़ाने का लक्ष्य भी स्पष्ट हो जाता है: हमें प्रति यूनिट अधिक समय का उत्पादन करना सीखना चाहिए। समय, जैसा कि हम जानते हैं, हमारे प्रभाव के अधीन नहीं है, लेकिन हल किए गए अंकों की संख्या अभी भी कैसे है। वास्तव में, यह वही है जो हम अध्ययन करना जारी रखेंगे।
अंक एक महत्वपूर्ण समन्वय प्रणाली है जिसका उपयोग आगे की प्रस्तुति में किया जाएगा। यह एक ऐसा सेक्शन है, जिसे छोड़ा नहीं जा सकता। अंकों की गणना होने तक कुछ अन्य तरीकों को लागू करना थोड़ा समझ में आता है। क्या आप समझते हैं क्यों?
क्योंकि आप लागू विधियों की प्रभावशीलता का मूल्यांकन नहीं कर सकते हैं। कैसे समझें, संख्याओं का नहीं होना बेहतर या बुरा है? कोई रास्ता नहीं, बस एक कल्पना बनी हुई है। कल्पनाओं और भ्रमों पर आधारित प्रबंधन, निश्चित रूप से, बहुत व्यापक है, लेकिन यह दक्षता बढ़ाने के लिए उपयुक्त नहीं है।
मैं आपको थोड़ा गुप्त बताऊंगा: अंकों में कार्यों के आकलन के लिए एक प्रणाली लागू करके, आप पहले से ही प्रोग्रामर की टीम की कार्यक्षमता बढ़ा सकते हैं। कभी-कभी दो बार भी, मैंने कई बार इस परिकल्पना का परीक्षण किया।
कारण सरल है - वास्तविक पारदर्शिता है। भ्रम मिट जाते हैं, नंगे नंबर रह जाते हैं। क्लाइंट द्वारा भुगतान किए गए घंटों के साथ, आपको ट्रैकिंग प्रदर्शन के लिए एक काफी शक्तिशाली प्रणाली मिलती है। लोग, उनकी संख्या को देखकर, खुद बेहतर काम करना शुरू कर देंगे, क्योंकि वे अब घड़ी के पीछे छिप नहीं पाएंगे।
इसलिए, देरी के बिना, अंक में अपने सिस्टम में कार्यों का रिकॉर्ड बनाएं। यह बिल्कुल मुश्किल नहीं है, खासकर यदि आप 1 सी प्लेटफॉर्म पर एक सिस्टम का उपयोग करते हैं - बस मेटाडेटा ऑब्जेक्ट में एक संख्या फ़ील्ड जोड़ें जो आपके कार्यों को संग्रहीत करता है। खैर, एक बिंदु प्रणाली पर कुछ रिपोर्टें लिखें - कितनी समस्याओं का समाधान किया गया है, किसके द्वारा, कब, कितने काम में स्वीकार नहीं किए गए हैं, कितने ग्राहक द्वारा स्वीकृति की प्रतीक्षा कर रहे हैं, आदि।
सारांश
- केवल घंटों में कार्य मापना आपको दक्षता बढ़ाने के अवसर से वंचित करता है;
- भौतिक इकाइयों में कार्यों को मापना बेहतर है - अंक;
- टीम पोकर योजना के साथ अंक लागू करना बेहतर है;
- जब रेटिंग प्रणाली टीम के लिए स्पष्ट हो जाती है, तो आप एक व्यक्ति को एक आकलन दे सकते हैं;
- स्कोरिंग प्रभावशीलता की समझ प्रदान करता है;
- अंक स्वचालित होना चाहिए।