1 सी, कोई दर्द नहीं

अपने जीवन में मैंने दो प्रकार के व्यवसाय देखे जो किसी और से भी बदतर विकसित हो रहे हैं - 1C फ्रेंचाइजी और क्रिसमस ट्री विक्रेता। यह विकास की चौड़ाई के बारे में नहीं है, जब सिर्फ प्रोग्रामर की संख्या बढ़ रही है, लेकिन आंतरिक विकास के बारे में। प्रभावशीलता पर, संक्षेप में।

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

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

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

लेकिन किसी कारण से, यह मुझे लगता है कि सब कुछ खो नहीं गया है। आप बेहतर कर सकते हैं।

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

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

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

यदि आपको नहीं पता है कि 1 सी क्या है: फ्रैंचाइज़ी है, तो पढ़ें जैसे कि हम एक निश्चित कंपनी के बारे में बात कर रहे हैं जो सॉफ्टवेयर के विकास, रखरखाव और शोधन के लिए सेवाएं प्रदान करता है।

मामले का लक्ष्य सरल है - प्रोग्रामर के उत्पादन में वृद्धि करना और, यदि संभव हो तो, राजस्व। या निकास, उसके पास अलग-अलग विकल्प हैं। चलो चलते हैं। मैं आपको चेतावनी देता हूं - लोंग्रिड।

प्रारंभिक स्थिति

पूरे मताधिकार को न लें, लेकिन इसका एक हिस्सा, जिसे हम विकास विभाग कहेंगे। ये लोग हैं, 1 सी प्रोग्रामर जो कार्यालय में बैठे हैं, सिस्टम के माध्यम से या सलाहकारों से कार्य प्राप्त करते हैं, यह तय करते हैं कि वे परिणाम को सलाहकार या क्लाइंट को पास करते हैं, दूरस्थ रूप से।

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

मान लीजिए कि हमारे विकास विभाग में पांच लोग शामिल हैं। कुल औसत मासिक उत्पादन 500 घंटे है। इनमें से, 200 को एक निश्चित चैंपियन द्वारा बंद किया गया है - सबसे अनुभवी और बुद्धिमान कोडर। 100 घंटे दूसरे, 80 - तीसरे और चौथे, 40 - शुरुआती को बंद कर देते हैं।

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

उदाहरण के लिए, विकास अपेक्षाकृत स्थिर है, ज्यादा उछलता नहीं है। जब तक, चैंपियन छुट्टी पर नहीं जाता है, तब तक हमारे पास 40 प्रतिशत की विफलता है। कभी-कभी ऐसा होता है और 700 घंटे - जब एक अच्छी परियोजना हुई, और प्रोग्रामर सप्ताहांत पर काम करते हैं।

मामला लक्ष्य

तुरंत मैं आपको मामले का उपयोग करने का उद्देश्य बताऊंगा ताकि रहस्य पैदा न हो। हम चाहते हैं कि हमारा विकास विभाग 500 नहीं, बल्कि प्रति माह 1000 घंटे दे, अर्थात्। जितना दुगना। समान प्रति घंटा की दर के लिए, एक ही निश्चित लागत के साथ, समान कार्य घंटों के साथ। हम इस परियोजना के लिए छोटे समय के खर्च की अनुमति दे सकते हैं - उदाहरण के लिए, 30-50 tr के भीतर।

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

मान लीजिए कि हमारे 500 घंटे एक महीने के विशेषज्ञों के लिए 500 वास्तविक घंटे काम करते हैं। इन 500 घंटों के लिए, वे कहते हैं, 200 समस्याओं को हल करते हैं, 2.5 घंटे के औसत मूल्य टैग के साथ। यह पता चलता है कि प्रत्येक कार्य में औसतन 5000 रूबल की लागत आती है। ग्राहक उस तरह के पैसे देने के लिए काफी तैयार है, वह बाजार को जानता है, बाकी सभी फ्रैंचाइजी की कीमत एक समान है।

और इसलिए हमने 2.5 घंटे में नहीं, बल्कि 1.25 घंटे में समस्या को हल करना सीखा। अहम सवाल यह है कि किसी ग्राहक को कितना बेचा जा सकता है?

यदि हम समय बेचते हैं, तो 1.25 घंटे के लिए बेचना तर्कसंगत है। ग्राहक खुश होगा - सस्ता और तेज दोनों। लेकिन हमारे लिए, एक व्यवसाय के रूप में, इस तरह की योजना से लगभग कोई लाभ नहीं है - केवल एक संतुष्ट ग्राहक और विशेषज्ञों के खाली समय के लिए जिन्हें कुछ लेने की आवश्यकता है। मान लीजिए कि हमें अधिक ग्राहक मिले, और हम उन्हें 1.25 घंटे के लिए एक कार्य भी बेचते हैं। नतीजतन, एक महीने में, हमें क्या मिलेगा? 2000 रूबल के लिए समान 500 घंटे। कोई मतलब नहीं है।

एक विकल्प प्रति घंटा की दर को बढ़ाने के लिए है। लेकिन हम प्रतियोगियों की तुलना में समस्याओं को तेजी से हल करते हैं? छोटी नौकरियों पर, कोई भी विशेष रूप से इस पर ध्यान नहीं देगा, लेकिन 40 घंटों में कार्यों पर अंतर पहले से ही ध्यान देने योग्य होगा।

लेकिन एक घंटे की कीमत बाहरी दुनिया के लिए ध्यान देने योग्य परिवर्तन है जो हमारे से नए ग्राहकों को हतोत्साहित कर सकती है। वे नहीं जानते कि हम दो बार उपवास के रूप में क्या कर रहे हैं? साइट पर लिखे गए नारे विशेष रूप से आश्वस्त नहीं हैं।

2.5 घंटे के लिए कार्य को जारी रखना अधिक सही लगता है। क्लाइंट कुछ भी नोटिस नहीं करता है, और हम एक सामान्य, लक्ष्य परिणाम प्राप्त करते हैं - दो बार कई कार्यों को करते हुए, हमें दो बार उतना पैसा मिलता है।

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

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

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

खैर, यह सब, लक्ष्य स्पष्ट है, अब हम आवश्यक परिवर्तनों का विश्लेषण करेंगे।

मुख्य मुद्दा

वे कहते हैं कि हमेशा बल के आवेदन का एक बिंदु होता है जिस पर आपको लीवर डालने और अधिकतम प्रभाव प्राप्त करने की आवश्यकता होती है। मैं इस बात से सहमत नहीं हूं - इस अर्थ में कि ऐसा बिंदु हमेशा होता है। लेकिन इस मामले में यह है - प्रेरणा की एक प्रणाली।

हमारी प्रेरणा प्रणाली प्रदर्शन के लिए एक व्यक्तिगत, प्रति घंटा की दर है।

इसमें प्रोग्रामर के लिए कई फायदे हैं, व्यापार के लिए कुछ हैं, लेकिन बहुत सारे minuses हैं।

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

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

यह व्यवसाय के लिए क्या है? यदि विशेषज्ञ दक्षताओं को साझा नहीं करते हैं, तो प्रशिक्षण की देखभाल कंपनी के कंधों पर आती है। पाठ्यक्रमों को व्यवस्थित करना, या तृतीय-पक्ष संगठनों (जैसे 1 सी) को भुगतान करना आवश्यक है। दूसरा प्रमुख विशेषज्ञों के रूप में अड़चन है। यदि 5 लोगों में से केवल एक ही ईआरपी जानता है (यह भी उस तरह का एक कार्यक्रम है), तो आप शारीरिक रूप से अधिक ईआरपी नौकरी नहीं ले सकते हैं, क्योंकि यह कर्मचारी पचाने में सक्षम है। यदि यह एक चैंपियन है, तो भी प्रति माह 200 घंटे से अधिक नहीं होगा। ठीक है, या तो जोखिम उठाएं - बाद में, यह पता लगाने के लिए काम करें।

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

एक व्यक्तिगत प्रति घंटा की दर एक व्यवसाय के अंदर एक व्यवसाय की तरह है, और यह "आंतरिक व्यवसाय" हमेशा एक आईपी होता है, एलएलसी नहीं।

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

व्यक्तिगत कृति काम समाधान और सर्वोत्तम प्रथाओं को साझा करने की क्षमता को मारती है, क्योंकि, फिर से, इसका कोई मतलब नहीं है। ठीक है, आपने उस व्यक्ति को अपना प्रसंस्करण या सबसिस्टम दिया, उसने एक दिन में ग्राहक के साथ सहमत हुए 40 घंटे बंद कर दिए, 20 tr बढ़ा दिए। उस के साथ क्या हो रहा है? आप निश्चित रूप से, एक समझौते पर आ सकते हैं और विभाग के अंदर एक काला बाजार बना सकते हैं, लेकिन इसका कोई मतलब नहीं है। यह कहना आसान है, "मुझे काम दो, मैं इसे हल कर दूंगा।" एक निराशाजनक स्थिति में, निश्चित रूप से, वह देगा, लेकिन इसके बजाय, वह खुद को छोड़ देगा, सिद्धांत से बाहर।

आप दक्षताओं को अलग तरह से देख सकते हैं: उनका मालिक कौन है? मान लीजिए कि आपका चैंपियन 2010 से कंपनी के साथ है। उन्होंने ईआरपी पर बहुत काम किया, दक्षता हासिल की। वे किससे संबंधित हैं?

कंपनी कहेगी - वे हमारे हैं। हमारे ग्राहक, हमारी परियोजनाएँ, हमारे कार्य। सक्षमता दें। उन्हें कैसे उठाएं? क्या टिक नहीं खींचते हैं? यह कोई भौतिक संपत्ति नहीं है। वह बाहर निकलता है, और दक्ष रोते हैं।

और क्या योग्यताएं हैं? उत्पाद। या नहीं, उत्पाद की बिक्री से होने वाली आय। ईआरपी द्वारा 200 घंटे भेज दिया गया, दो लाभ प्राप्त हुए - 400 ट्र और दक्षताओं। पैसा - बेशक, यहां यह चालू खाते पर है। आप ट्रांसफर कर सकते हैं, खर्च कर सकते हैं, निवेश कर सकते हैं। दक्षियां कहां हैं? उस गंजे सिर पर। उनके साथ क्या किया जा सकता है? वास्तव में - कुछ भी नहीं।

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

इस स्थिति का कारण ट्राइट है - गलत प्रेरणा प्रणाली। ऐसा नहीं है कि यह प्रोत्साहित नहीं करता है - यह सीधे किसी व्यक्ति को सक्षमताओं को साझा करने से रोकता है।

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

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

मामला

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

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

तो आपको क्या करना है :

• रेटिंग सिस्टम में प्रारंभिक शेष राशि का चयन करें, स्वचालित करें और जोड़ें;
• स्वचालित करें और क्षमता प्रणाली में प्रारंभिक संतुलन जोड़ें;
• प्रेरणा प्रणाली पर निर्णय लें, स्वचालित करें;
• योग्यता रणनीति के मापदंडों को चुनें;
• एक कर्तव्य अधिकारी नियुक्त करें;
• प्रोग्रामर से बात करें।

करने के लिए:

• आने वाले कार्यों की सामान्य चर्चा;
• रणनीति के अनुसार योग्यता द्वारा एक निष्पादक का चयन;
• पारस्परिक सहायता प्रबंधन और लेखांकन;
• कार्य की स्थिति प्रबंधित करें।

अब मैं संक्षेप में प्रत्येक आइटम की रूपरेखा तैयार करूंगा। लेकिन पहले, स्वचालन का स्पष्टीकरण।

स्वचालन

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

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

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

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

एक दूसरे के बगल में बैठे आंतरिक टीमों के काम को स्वचालित करने के लिए, सबसे अच्छा मंच, अफसोस, 1 सी है।

ग्रेडिंग प्रणाली

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

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

मैं Scrum - पोकर योजना से प्रणाली की सिफारिश करता हूं। प्रत्येक कार्य का मूल्यांकन फिबोनाची श्रृंखला से लिए गए अंकों में किया जाता है - 1, 2, 3, 5, 8, 13, 21, 34, आदि। मूल्यांकन इस कार्य की आपकी व्यापक दृष्टि को दर्शाता है - निष्पादन की जटिलता, और श्रम लागत, और अनिश्चितता, और काम की डिलीवरी में ग्राहक की समस्याग्रस्त प्रकृति।

"एंकर" से शुरू करने का सबसे आसान तरीका यह निर्धारित करना है कि 1 बिंदु का कार्य है। यह सबसे सरल, परमाणु कार्य है जिसे आप हल करते हैं। तदनुसार, 2 अंकों का एक कार्य मुश्किल से दोगुना है।

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

यदि आप सिस्टम को "ऊपर से" शुरू करते हैं, तो यह संभव है कि वोट की व्यवस्था न की जाए, बल्कि रेटिंग्स को खुद रखा जाए। हमारे पास स्क्रम नहीं है, हम खुद नियम लिखते हैं।

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

मूल्यांकन प्रणाली में दर्ज किया जाना चाहिए, और एक सहारा कार्य के रूप में संग्रहीत किया जाना चाहिए।

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

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

उदाहरण के लिए, यह पता चला है कि आप 2000 रूबल के लिए महीने में 500 घंटे बेचते हैं, और यह 500 अंक है। फिर इस समय आपका स्कोर 2000 रूबल है। परिवर्तनों को प्रस्तुत करने के बाद, आपको 1000 अंक उत्पन्न करने होंगे, उन्हें 2000 रूबल के लिए बेचना होगा और आय (कंपनी और कर्मचारियों दोनों) से दोगुनी आय प्राप्त होगी।

प्रारंभिक बचे हुए टुकड़े बेहद महत्वपूर्ण हैं, क्योंकि उनके बिना आप प्रारंभिक प्रश्न का उत्तर नहीं देंगे - यह काम किया या नहीं? आलसी मत बनो, कृपया।

यह पुराने कार्यों का मूल्यांकन करने के लिए नहीं, बल्कि नए लोगों के साथ शुरुआत करने के लिए लुभाएगा। , , , . – .

«», – .

, . , , ( ).

– . . , . , , .

– . – « » « », , .

– . – . , , , . – , . , , , , .. , .

, – . , . – , . , 10 . , , 100 %.

. . . . , , , .

« », . , - . – , , , , .

– , . , – .

– . , , , , , ( ). , – .

, – . «», «», .

. – . , , ( ). , , .. .

, , , , .

– «» , , . , , , , . , ( , – ).

, , , , « -». , , 10 , 2.

-. «», . «» – , , , . ? – . , 40 % — «». , 15 , , 2 , 500 . 2 . 60% = 600 , .. 266 (600 2.25 ). , 100 ( 10 , 1000 ).

«» 1600 ( 15 , 400 ). , . , .. , 500 , – 1600 . , – . , . , . , , -, .

, . , – . , 2 , 5 - . , , , .

, – , . , .

: – , «» . – , . , – , . .

, , . – , , , .

, . , .

, – - . , , , . , , , .

, . : . – , , , , .

: 70 % – , 30 % – . , . , . , , .

, – , , , ? , . -, . -, . , , . « » – « — ».

, , – , , . , – . . -, , . , , .

– , , . , – , .

«», , , . – , , , . – , , - . .

– , . , – – .

, , . , - «, , , . , . , , . , . „ “? ? , , , , 9-00 . , . – , ».

– , ( ). .

. , . , , , , . , , , . , , , , , .

- , . 5 15 . , – .

– , , . - , . . , . , , « ».

, , . 1 – , . , , . , , – , , , – - «», , . 1 , - .

, , - , , . : .

– . , , . , – , , . .

, – , . , , . , « », - .

, , , - . , , , , .

. , , – , – . , , .

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

समस्या, वास्तव में, सामान्य है - ध्यान का गलत वेक्टर। या, अधिक सरलता से, आप वहां नहीं देख रहे हैं। हम विषय को प्रोग्रामर तक सीमित करते हैं, हालांकि सिद्धांत सार्वभौमिक है।

आपकी राय में, 1C प्रोग्रामर द्वारा क्लाइंट समस्या को हल करने के लिए आदर्श गति क्या है? यह विकास या अंतिम रूप देने के कार्य के बारे में है। पढ़ते समय सोचें, जवाब थोड़ा कम होगा।

आइए 1C प्रोग्रामर के काम पर एक नज़र डालें। आपको क्या लगता है, यह वास्तव में कितने प्रतिशत समय (सभी पहलुओं - कोड लिखना, मेटाडेटा, लेआउट बनाना, आदि) सहित कार्यक्रम करता है? 100%? 50%? 20%?

अभ्यास से पता चलता है कि ऐसा होता है और 3% होता है। यदि आप इसे नहीं मानते हैं, तो अपने लिए जांचें - इस तरह के माप के लिए विशेष कार्यक्रम हैं। लेकिन एक सरल तरीका है - एक दिन में प्रोग्रामर द्वारा लिखित कोड की मात्रा को देखें, और इसकी प्रिंट गति से विभाजित करें। परिणामी आंकड़ा आपको आश्चर्यचकित कर सकता है।

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

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

अब सवाल यह है: किस समय में यह उसी समस्या को किसी अन्य ग्राहक से हल करेगा? यदि वह सिर्फ एक तैयार समाधान लेता है, तो लगभग 5 मिनट, सही? खैर, जबकि विन्यासकर्ता वहां खुलता है, जबकि दूसरा, कॉपी करते समय आदि। और अगर आप कलम से फिर से लिखते हैं? आधा घंटा? रास्ते में, वह मशीन पर एक समीक्षा भी करेगा, और कोड में सुधार होगा। 16 गुना तेज।

ठीक है, कोड की नकल के साथ, इसके साथ नरक करने के लिए। एक और उदाहरण। आपने प्रोग्रामर को एक कार्य देने के बजाय, 10-20 दिया - आपने कहा: यहाँ ट्रैकर है, कोई भी चुनें और इसे करें। आगे क्या होगा?

प्रोग्रामर चुनेंगे। प्रोग्राम कोड में, चयन ऑपरेटर एक मिलीसेकंड के एक अंश के लिए काम करता है (यदि बहुत कठिन स्थिति नहीं है), लेकिन एक व्यक्ति एक मशीन नहीं है। उसके लिए चुनाव एक ऐसी प्रक्रिया है जो कभी-कभी धीमी गति से चलती है।

कभी-कभी यह प्रक्रिया युद्ध में टोह लेने की याद दिलाती है: प्रोग्रामर न केवल कार्य शीर्षक और विस्तृत विवरण पढ़ता है, बल्कि टिप्पणियां भी करता है, और फिर वह संदर्भ समझने के लिए विन्यासकर्ता में क्रॉल करता है। देखो, ठोकर - फू, कहते हैं, यह चौग़ा के बारे में एक काम है, वहाँ शैतान इस नरम स्टार्टर में अपने पैर को तोड़ देगा। नहीं, कोल्यान को करने दो। 15 मिनट का समय गंवा दिया। 10-20 से गुणा करें, यह कितना निकलेगा? 5 घंटे तक?

यह ठीक है अगर प्रोग्रामर बुद्धिमान है और निर्णय लेने के लिए पर्याप्त संदर्भ है। लेकिन वह कहते हैं, इंटरनेट का एक बड़ा प्रशंसक, और एक तैयार समाधान के लिए देखने के लिए चला गया - एक ही Infostart, या एक संबद्ध सम्मेलन, या कहीं और। पसंद का समय खतरनाक दर से बढ़ने लगता है।

आधा दिन चुनेगा, आधा दिन काम करेगा। हानियाँ - 50%, अर्थात यह किसी के लिए सही ढंग से काम करने के लिए पर्याप्त है ताकि आउटपुट दोगुना हो सके।

ठीक है, हमें पसंद के रूप में ऐसी कोई समस्या नहीं है। प्रबंधक, या मुख्य प्रोग्रामर, चुनता है और कहता है - यहाँ, ऐसा करें। नहीं, मैं नहीं चाहता, मैं नहीं कर सकता, चलो कल्याण को बेहतर करते हैं, प्रोग्रामर जवाब देता है। करो, मैंने कहा! - मुखिया का जोर

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

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

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

अधिकांश समय खो जाता है जहां प्रोग्रामर बेवकूफ है, और न कि जहां वह कोड लिखता है। मैंने कई विकल्प बताए।

यदि आप प्रोग्रामर के प्रमुख हैं, तो कोडिंग को देखना बंद करें, डाउनटाइम को देखें। यदि आप एक प्रोग्रामर हैं, तो अपने आप को, अपने डाउनटाइम पर देखें। यह विकास की गति को बढ़ाने की कुंजी है।

हम इस सवाल पर लौटते हैं - 1C प्रोग्रामर द्वारा क्लाइंट समस्या के समाधान के लिए आदर्श समय क्या है? उत्तर स्पष्ट है - शून्य। खैर, बिल्कुल शून्य मौजूद नहीं है, इसे 5 मिनट होने दें। यह समय कैसे प्राप्त किया जाता है? आप पहले से ही समझते हैं: टर्नकी समाधान जारी करके। ग्राहक आया, उसके कार्य को कहा, और आपने उसे तुरंत बता दिया - जो समाधान आपके पास पहले से है। मुझे नहीं पता कि किसी विशेषज्ञ के काम के 5 मिनट में कितना पैसा लेना है, ठीक है, यह सुनिश्चित करने के लिए है। आप इस कथन के साथ बहस कर सकते हैं, लेकिन आप सोच सकते हैं। आपने कितनी बार समान समस्याओं को हल किया है? उन कार्यों का प्रतिशत क्या है जो आप पहली बार हल करते हैं, और ऐसी बात कभी नहीं सुनी है? मेरे पास एक छोटा अभ्यास है - केवल 13 वर्ष की उम्र, लेकिन यहां तक ​​कि इस तरह के एक मामूली आंकड़े के साथ, मैं समझता हूं और देखता हूं कि मैंने पहले ही आधी समस्याओं को हल कर दिया है।

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

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

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

आने वाले कार्यों की सामान्य चर्चा

सरल और कॉर्नी। परिचर, जिसे हमने पिछले लेख में चर्चा की थी, हर सुबह सभी प्रोग्रामर को ढेर में इकट्ठा करता है, और वे एक साथ नए कार्यों को देखते हैं।

पहली बात यह पता लगाना है कि क्या किसी ने इसी तरह की समस्या को हल किया है। यदि आप निर्णय लेते हैं, तो उसे एक सलाहकार, या क्यूरेटर नियुक्त करें - इससे कोई फर्क नहीं पड़ता कि क्या कॉल करना है। यह महत्वपूर्ण है कि ठेकेदार को पता है कि किसे संपर्क करना है।

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

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

शुरुआती लोगों के लिए एक सलाहकार होना विशेष रूप से महत्वपूर्ण है। यहां तक ​​कि अगर, आपकी सक्षमता विकास रणनीति के अनुसार, आप एक शुरुआत को एक क्यूरेटर से पूछने के लिए मना करते हैं, तो उसकी उपस्थिति का एकमात्र तथ्य एक शुरुआती को भारी नैतिक समर्थन प्रदान करेगा।

ठीक है, अंक में - पोकर की योजना बनाकर, कार्य का मूल्यांकन करना न भूलें।

रणनीति के अनुसार योग्यता द्वारा एक निष्पादक का चयन

यहां सब कुछ सरल है। आपने एक विकल्प बनाया - दक्षताओं के विकास और वृद्धि के बीच स्लाइडर को समायोजित किया। इसलिए अपनी रणनीति के अनुसार एक कलाकार चुनें।

उदाहरण के लिए, आप तय करते हैं कि शुरुआती अपरिचित समस्याओं को 30% समय में हल करना चाहिए। सिस्टम में, आपके पास पहले से ही एक रिपोर्ट है जो प्रतिशत को दिखाती है - कितने दोस्त, कितनी अपरिचित समस्याएं उन्होंने हल कीं। संख्याओं को देखें और तय करें कि किस बिंदु पर एक नया, अपरिचित कार्य जारी करना है।

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

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

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

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

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

पारस्परिक सहायता प्रबंधन और लेखांकन

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

बेशक, यह सुनिश्चित करना आवश्यक है कि सलाहकार अभेद्य नहीं बनता है, और जब नवागंतुक को कार्य सौंपा जाता है तो वह कंबल को अपने ऊपर नहीं खींचता है। यह मत भूलो कि हमारा लक्ष्य तत्काल लाभ नहीं है, लेकिन दीर्घकालिक सफलता है।

ठीक है, आपको शुरुआत का पालन करना चाहिए। यदि आप तय करते हैं कि इस कार्य में वह केवल शेड्यूलर के साथ काम जानता है, तो उसे बाकी के काम के संदर्भ में न लेने दें - सलाहकार को उसे बताने दें।

दरअसल, जोड़ने के लिए और कुछ नहीं है।

कार्य की स्थिति प्रबंधित करें

इस विषय पर एक अलग लेख था, मैं सब कुछ नहीं दोहराऊंगा। संयोग से, लेख को विशेष रूप से 1Snikov में कोई दिलचस्पी नहीं थी, लेकिन डेवलपर्स के अन्य नस्लों के प्रतिनिधियों ने इसे पसंद किया - हम अब उनके साथ सक्रिय रूप से काम कर रहे हैं। यह कहना है कि प्रोग्रामिंग 1C की दुनिया में, अब तक, दक्षता बढ़ाने के तरीकों के साथ सब कुछ अच्छा नहीं है।

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

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

दूसरी विंडो में - कार्य में स्वीकृत कार्य, लेकिन निष्पादक नहीं। एक सामान्य चर्चा के बाद, उसी तरह से खाली कर दिया। चर्चा के बाद, दोनों सूची खाली हो जानी चाहिए। कार्य के लिए स्वीकृत समय "कार्य के लिए स्वीकृत नहीं" और "एक निष्पादक नहीं" - एक कार्य दिवस से अधिक नहीं है।

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

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

प्रोग्रामर के साथ चर्चा के दौरान, हम "इन वर्क" विंडो को देखते हैं। हमने इसे स्थान दिया है: हर कोई समझता है कि कौन किस कार्य में लगा हुआ है। तदनुसार, कार्य के लिए "काम" स्थिति में होने का समय है, ठेकेदार से बंधा हुआ है, और इस समय की निगरानी की जानी चाहिए।

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

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

अन्त

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

यहां ग्राहकों में से एक के लिए हमारा कार्यक्रम है (फिलहाल एक कुंजी):



जैसा कि आप देख सकते हैं, मामले को लागू करने से पहले (यानी, अप्रैल तक), बिंदु का मूल्य उसी स्तर पर खतरे में पड़ गया। इसका मतलब यह है कि, समान संख्या में घंटे बिताने पर, हमने परिणाम की समान मात्रा का उत्पादन किया - 0.9 घंटों में औसतन 1 अंक।

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

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

ठीक है, तो यह आंकड़ा मूल के आधे - अनुमानित औसत के आसपास लटकना शुरू हुआ।

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

यहाँ, उदाहरण के लिए, अर्जित अंकों की कुल संख्या का एक ग्राफ है:



जैसा कि आप देख सकते हैं, मामले से पहले हमने औसतन एक महीने में 400-500 अंक दिए थे, और फिर यह आंकड़ा बढ़कर 1400 हो गया - 3 गुना की वृद्धि।

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

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

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

पहली हमारी व्यवसाय प्रोग्रामिंग परियोजना की साइट है (मुझे लिंक नहीं दिया गया है, अन्यथा मुझे "nmivan, let’s go ..." विषय के साथ एक ईमेल प्राप्त होगा)। मुख्य शब्द साइट है, क्योंकि इससे पहले कि हम केवल व्यावसायिक अनुप्रयोग बनाते थे जो इंटरनेट के माध्यम से काम करते हैं। साइट मेटाडेटा.जेएस प्लेटफॉर्म पर बनाई गई है, लेकिन महत्वपूर्ण सफलता साइट ही नहीं है, न ही सामग्री, बल्कि मंच और उसके घटकों का शोधन। अब आप metadata.js पर साइट भी बना सकते हैं। इसके अलावा, साइट में CMS की कार्यक्षमता और microservices शामिल हैं।

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

तीसरी परियोजना के बारे में बात की - फ्लोकोन.लाइफ । हमारे लिए, यह बेहद महत्वपूर्ण है, क्योंकि मंच के विकास के लिए उपयोगी कार्यों का एक गुच्छा दिया। यह लोगों के लिए पहली परियोजना है, व्यापार के लिए नहीं।

चौथा आप के लिए शायद ही दिलचस्प है - यह फ्लोकोन है, 1 सी + कार्य / टीम / व्यवसाय प्रबंधन सेवा के लिए एक कॉन्फ़िगरेशन।

खैर, कुछ और - या तो छोटे और अधिक उबाऊ, या बड़े और अधिक गुप्त। कुल, कहें, छह टुकड़े।

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

सब कुछ सापेक्ष है। 9 महीने में छह परियोजनाएं - बहुत कुछ या थोड़ा? , 6 ( ), – 0.15 0.66 .

, , — , . , , , . , – .

, , . , , .

, , , – . , , , – .

, . , . , , — , ? .

, , . , . , , , , . .

« »

. , , - .

, - – , , . . , – , .

, , . – , – . , – . , .

1 , , , 1 , ? , , - , – .

, , . – . 1.5 – . – . , , «, - , ».

1? कोई बात नहीं। , – , .

. , – . . , .

?

« , »

– . «» — . , , .

– , – , . , . , . .

, . – , . , , , – «, ?».

? , .. – , , . , , , – : , . , , – .

« , »

– , . . , .

« , -, »

, . , ? ? .

, « », – , .

, . , . ?

, .

« – »
. – , .

« / ///»

– . , , .

« , »

, – . , . , – .

. , . – , .

, – 1, , , . .

« ? ?»

, . – , , . , .

, – 1: , – . – , – .

« , …»

, . , – .

« ?»

. – , – . – .

. - , , .. – , , .. , .

, , . «» — , .

« ?»

, . .

, , – . . – . , , , , – .

, . , . – .. . - , . , .

, . , , . , .

, . , . , , , , .

, , .. , – – . , , , .

«?»

– , , , . – - .

1: , , , «», - . , , . , – , .

, . – , . , , .

(, -, ), 1: , . – , – . «» .

– . – . , «» .