Bloodsuckers। प्रोग्रामर का वर्गीकरण

नेता कौन हैं, और उनकी आवश्यकता क्यों है? जीवन में उनका क्या उपयोग है? वे क्या करते हैं? उन्हें क्या करना चाहिए?

एक तरफ, नेता को पारंपरिक रूप से समझा जाता है कि वह जो प्रबंधन करता है - योजना बनाता है, निर्देश देता है, समय को नियंत्रित करता है, सबसे तेज चिल्लाता है, निर्णय लेता है और उनके लिए जिम्मेदार है।

दूसरी ओर, एक राय है कि परिचालन प्रबंधन में भाग न लेकर, सिर को केवल सौंपी गई इकाई के विकास से निपटना चाहिए।

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

तो वह कौन है, यह नेता, और उसकी आवश्यकता क्यों है? क्या एक प्रबंधक को कंपनी की आवश्यकता होती है या किसी कंपनी को आय के स्रोत के रूप में एक नेता की आवश्यकता होती है? शायद वह अपने अस्तित्व को सही ठहराता है, क्योंकि परिणाम इसके लायक है - प्रबंधकों की आय अक्सर आम कर्मचारियों की आय की तुलना में अतुलनीय रूप से अधिक होती है।

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

आदर्श

मॉडल अपमान करने के लिए सरल है, लेकिन आमतौर पर केवल प्रोग्रामर के लिए समझ में आता है। लेकिन आप प्रोग्रामर हैं, और सब कुछ आपके लिए स्पष्ट होगा।

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

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

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

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

मॉडल स्पष्ट है: प्रबंधक / विभाग का संबंध प्रोग्रामर / सूचना प्रणाली के समान है।

अब इस मॉडल के चश्मे के माध्यम से नेताओं को देखें।

ठग

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

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

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

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

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

यह इस तरह के एक प्रोग्रामर और इस तरह के एक नेता की भूमिका के बारे में बात करने के लिए कोई मतलब नहीं है, क्योंकि सिस्टम और इसके विकास में कोई भूमिका नहीं है और कोई विकास नहीं है। यह सबसे दयनीय मामला है।

एक रिश्तेदार

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

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

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

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

लेकिन सामान्य तौर पर, अधिकांश भाग के लिए, ऐसा प्रोग्रामर सिस्टम के जीवन में और विभाग के जीवन में प्रमुख की भूमिका नहीं निभाता है।

छोटे पेंच

ऐसा होता है कि एक प्रोग्रामर एक ऑपरेटर में बदल जाता है। अक्सर नहीं, लेकिन ऐसा होता है।

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

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

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

न तो एक और न ही अन्य नेताओं का उनके सिस्टम पर कोई प्रभाव है। प्रबंधन मत करो, विकास मत करो, प्रतिक्रिया मत करो। सिस्टम उन पर निर्भर नहीं करता है।

ऑक्टोपस

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

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

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

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

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

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

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

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

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

परिणामस्वरूप, प्रोग्रामर के लिए, प्रबंधक के लिए, परिणाम एक है: सिस्टम न तो मौजूद हो सकता है और न ही इसके बिना विकसित हो सकता है।

दस्ताने करनेवाला

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

किसी भी संकट की स्थिति में, जब सिस्टम से अच्छे से अधिक नुकसान होता है, तो वे बोलते हैं: किसी अन्य सिस्टम पर स्विच करने का समय है।

सौभाग्य से, अब इसके साथ कोई समस्या नहीं है, विशेष रूप से उत्पाद लाइन में niches का मिश्रण, वही 1C। आप यूटी 10.3 से सॉफ्ट स्टार्टर, फिर केए 1, फिर केपी 3.0, फिर केए 2, फिर ईआरपी, फिर सब कुछ पर थूक सकते हैं और यूएनएफ को लागू कर सकते हैं, फिर यूएसएचपी जैसे कुछ प्रकार के विकृत (यदि उद्योग अनुमति देता है), तब, आश्चर्यजनक रूप से, एससीपी पर लौटें। प्रत्येक संक्रमण न्यूनतम एक वर्ष है। अपने आप को गिनें कि आप इस तरह की रणनीति पर कितना पकड़ बना सकते हैं। क्या आप ऐसे प्रोग्रामर से मिले हैं? मुझे मिले हैं।

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

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

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

प्रणाली पर प्रभाव पैमाने पर भयानक है, लेकिन इसके परिणाम और प्रभावशीलता में अर्थहीन है। ये केवल परिवर्तन के लिए बदलाव हैं, केवल एक बड़े पैमाने पर।

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

बेशक, ऐसे प्रोग्रामर और मैनेजर से उद्यम के लिए किसी भी लाभ के बारे में बात करने की कोई जरूरत नहीं है।

Plyushkin

प्लायस्किन गोगोल की "डेड सोल्स" का किरदार है, एक लालची छोटी भाभी जो घसीटती है और उसे जो कुछ भी मिलता है, उसे बिट्स के ठीक नीचे रखती है।

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

वे स्वयं वास्तव में कुछ भी करना नहीं जानते हैं, इसलिए उनके लिए किसी और की छोटी चीज़ों का उपयोग करना ही पेशे में जीवित रहने का एकमात्र तरीका है। गंभीर परिवर्तनों के लिए, उनके पास ताकत, योग्यता और साहस की कमी है।

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

प्लायसुकिना के अधिकारी समान व्यवहार करते हैं। वे ब्लॉग, लेख, सामाजिक नेटवर्क में सभी प्रकार के समूहों को पढ़ते हैं कि कैसे थोड़े प्रयास से उपयोगी परिवर्तन किए जा सकते हैं। विधियों की पसंद में अव्यवस्थित प्रकृति के कारण, उनके विभाग की समस्याओं को समझने और खुद को लागू करने के कारण, वे आमतौर पर बकवास करते हैं।

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

इस तरह के प्रोग्रामर और मैनेजरों के पास एक मामूली, और ज्यादातर हानिकारक, सिस्टम पर प्रभाव होता है। इसे कूड़ेदान और शोर से भर दें।

अनुरक्षक प्रेमी

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

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

प्रणाली पर प्रभाव, ऐसा लगता है, लेकिन लगभग हमेशा कुटिल और हानिकारक है, क्योंकि सलाहकार मोज़ेक के केवल एक भाग के साथ काम करता है।

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

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

terpene

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

और ऐसे नेता - थोक में। ये वे सभी हैं जो बाहरी स्वचालन विशेषज्ञों, आईएसओ 9001 के कार्यान्वयनकर्ताओं, सभी पट्टियों के आंतरिक नौकरशाहों को रिपोर्ट करने, कागज के टुकड़े प्रदान करने, लाखों अनुमोदन के माध्यम से जाने, गाने सीखने और कॉर्पोरेट घटनाओं के लिए दृश्य तैयार करने आदि की आवश्यकता है। सामान्य तौर पर, जिसने अपने सिस्टम का एक हिस्सा बाहरी हमले के लिए खोल दिया, जैसे कि बेघर लोगों के लिए एक पोर्च और अब यह नहीं जानता कि उन्हें वहां से कैसे निकालना है, ताकि यह सब गंध न हो।

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

ऐसे लोग कीट हैं, क्योंकि "और आई चे की आड़ में, उन्होंने मुझे कहा" उनके सिस्टम को नष्ट करने के लिए।

साधारण

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

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

बहुत ही आपातकालीन मामलों को छोड़कर, न तो सिस्टम के अंदर एक और न ही दूसरा मिलता है।

उनमें से किसी ने भी सिस्टम को खुद से नहीं बांधा, और किसी भी क्षण वे छोड़ सकते हैं, और सिस्टम काम करना जारी रखेगा, हालांकि यह विकास को रोक देगा।

एकमात्र समस्या यह है कि न तो कोई मौजूद है और न ही दूसरा।

मुख्य मुद्दा

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

विकास हमेशा सुसंगत है, आप इसे उन परियोजनाओं से देख सकते हैं जो कभी-कभी कंपनियों में कल्पना की जाती हैं।

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

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

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

अंतहीन दौड़ प्राप्त की जाती है - सिस्टम का प्रत्येक हिस्सा आगे बढ़ता है, जो केवल पूरी आबादी की स्थिति को बढ़ाता है।

निर्णय

समाधान सरल है - विकास को एकीकृत करने के लिए। एक ही समय में सिस्टम के सभी हिस्सों को बदलें ताकि उनके बीच कोई असंतुलन न हो।

क्योंकि मुख्य समस्या असंतुलन है, सिस्टम के कुछ हिस्सों का एक दूसरे से बेमेल होना। हालांकि ऐसा लगता है कि समस्या एक विशिष्ट भाग में है।

उदाहरण के लिए, बहुत बार वे स्वचालन को कम करते हैं - यह सब कुछ के लिए दोषी है।

हम, प्रोग्रामर, आमतौर पर प्रक्रियाओं पर दोष लगाते हैं, वे कहते हैं कि गड़बड़ है, और हम इसे स्वचालित करने के लिए मजबूर हैं।

प्रेरणा प्रणालियों के कार्यान्वयन प्रक्रियाओं के बारे में और गैर-स्वचालित संकेतकों के बारे में और लक्ष्यों की कमी के बारे में शिकायत करते हैं। आदि

लेकिन असली समस्या विकास की दौड़ पैदा करने वाला असंतुलन है, और कंपनी को कभी भी व्यापार प्रणाली के हर हिस्से का लाभ नहीं मिलता है।

ईआरपी को लागू करता है, और 10% संभावनाओं का लाभ उठाता है, क्योंकि बाकी के लिए कोई प्रक्रिया नहीं है। यह एक ग्रेडिंग प्रणाली को लागू करता है और इसका उपयोग नहीं करता है, क्योंकि संकेतकों की गणना स्वचालित नहीं है। वह रणनीतिक लक्ष्यों को लिखता है, लेकिन वह उन्हें कभी हासिल नहीं करेगा, क्योंकि प्रक्रियाओं को तदनुसार नहीं बदला जाता है।

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

वापस अधिकारियों और प्रोग्रामर के पास

मैंने जो मॉडल आपको बताया है वह सिर्फ हंसने के लिए नहीं है। वह किसी विशेष उद्यम में किसी विशिष्ट नेता के साथ एक विशेष स्थान पर स्थिति को समझने के लिए है।

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

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

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

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

इसे कहां रखा जाए?

एक व्यक्ति को रखना आवश्यक नहीं है, लेकिन एक नेता का आम तौर पर स्वीकृत मॉडल - "एक बड़े वेतन के साथ एक बड़ा मालिक"। वास्तव में, जो नेता बनना चाहते हैं क्या वे वास्तव में इसके लिए प्रयास कर रहे हैं?

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

क्या आप ऑनलाइन लोगों के कार्यों का समन्वय कर सकते हैं? ठीक है, समन्वयक बनो।

क्या आप चीजों को आगे बढ़ाने के लिए प्रेरित कर सकते हैं, समर्थन कर सकते हैं? ठीक है, एक प्रेरक बनो।

क्या आप कुछ समय में परियोजनाओं को पूरा कर सकते हैं? ठीक है, एक फिनिशर बनो।

क्या आपके पास एक दृष्टि है, क्या आप जानते हैं कि कहां जाना है, क्या आप सही विचारों की पेशकश कर सकते हैं? ठीक है, एक जनरेटर हो।

क्या आप विश्लेषण कर सकते हैं, बहुत सारे सिस्टम मापदंडों को ध्यान में रखते हैं और इसकी कमजोरियों को समझ सकते हैं? ठीक है, एक विश्लेषक बनो।

ये सभी भूमिकाएँ नेतृत्व नहीं हैं। यह सिर्फ एक भूमिका है, ऐसी नौकरी।

यदि आप लोगों को बताते हैं कि क्या करना है, तो इसका मतलब यह नहीं है कि आप प्रभारी हैं। डिस्पैचर टैक्सी ड्राइवरों को यह भी बताता है कि कहां जाना है। वह नहीं बोला, उसने किया उनकी जगह सिस्टम ने ले ली।

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

यदि हम भूमिकाओं और दक्षताओं के समतल पर पारंपरिक "नेतृत्व" का विस्तार करते हैं, तो कुछ भी नहीं रहेगा। तो हमें ऐसे नेता की आवश्यकता क्यों है? इसके अलावा, लेआउट के साथ यह पता चलता है कि वह वास्तव में कोई भी भूमिका नहीं निभा सकता है।

और राजा नग्न है, जैसा कि कहानी में कहा गया है।