प्रोग्रामर और प्रबंधन

जब मैं प्रोग्रामिंग मंचों पर जाता हूं, तो मैं लगातार इस तथ्य पर आता हूं कि लोग उन कंपनियों के मामलों पर चर्चा करते हैं जहां वे काम करते हैं। और अक्सर बहुत नाराज स्वर में।

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

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

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

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

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

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

अब कल्पना करें कि हर कोई आपके कोड में पाई गई त्रुटियों के बारे में चुप है, वे आपको कुछ भी नहीं बताते हैं। लेकिन दूसरी ओर, वे अधिक से अधिक त्रुटियों से नाराज हैं, इस प्रकार तर्क कर रहे हैं:
“अच्छा, यह क्या है? यह आदमी ज्यादा से ज्यादा गलतियां कर रहा है! मैं इन बग्स के साथ हमें सॉफ्टवेयर कैसे दे सकता हूं? बस गलतियों की एक धारा! हाँ, वह हमारा बिल्कुल सम्मान नहीं करता है! उसके साथ काम करने से हमारी प्रेरणा और कम होती जाती है ... "।
अंत में, निर्णय किया जाता है: “यह अब बर्दाश्त नहीं किया जा सकता है! हम अब उसके साथ काम नहीं करना चाहते हैं! ”
क्या आपको लगता है कि प्रोग्रामर के साथ ऐसा करना सही है? क्या त्रुटियों पर प्रतिक्रिया और किसी भी सुधार की आवश्यकता के बिना उसे अच्छा कोड मिलेगा? क्या इस दृष्टिकोण के साथ एक अच्छा परिणाम प्राप्त करने की कोई संभावना है? मुझे लगता है कि उत्तर स्पष्ट है।

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

क्या क्लाइंट के लिए सामान्य रूप से हमारे सॉफ़्टवेयर में गलतियों को लंबे समय तक उनके बारे में कुछ भी बताए बिना गलती करना होगा, और फिर, अंत में, बस हमें भेजें, क्योंकि ऐसी त्रुटियां अब और बर्दाश्त करना असंभव है!

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

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

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

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

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

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

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

क्लाइंट से, हमें अपने उत्पाद की संतुष्टि के बदले अपनी सेवाओं के लिए भुगतान करना होगा।

डेवलपर से, हमें अपनी कंपनी में उसके काम से संतुष्टि के बदले प्रभावी कार्य की आवश्यकता है।

क्लाइंट, आदर्श रूप से, हमें एक महीने में 20,000 रूबल के लिए काम करना पसंद करेगा और तुरंत वह दे देगा जो उसे चाहिए, अधिमानतः एक वर्ष में नहीं, बल्कि कुछ हफ़्ते में, और ताकि सब कुछ तुरंत और बिना त्रुटियों के पूरी तरह से काम करे, और बिना बेवकूफ़ सवालों के, वह कैसे बेहतर है - एक तरीका या दूसरा ("क्या आप वास्तव में नहीं जानते कि मुझे क्या चाहिए? आप खुद को विशेषज्ञ कहते हैं?")।

हम समझते हैं कि यह असंभव है। हम एक महीने में 20,000 रूबल के लिए काम नहीं करेंगे। यहां तक ​​कि एक जीनियस कुछ हफ़्ते में कई काम नहीं करेगा, क्योंकि तीन लोगों की एक टीम को इस काम को करने के लिए छह महीने की ज़रूरत होती है, अगर वे भाग्यशाली हैं और अज्ञात कठिनाइयां सामने नहीं आती हैं। हालांकि, कार्यक्रम, कई पुनरावृत्तियों के बाद ही आवश्यक होते हैं, कई त्रुटियों को ठीक करते हैं और क्लाइंट द्वारा प्रस्तावित कई अतिरिक्त सुधारों को शुरू करते हैं। लेकिन यह महसूस करते हुए कि हम एक अच्छे अंतिम परिणाम के लिए जिम्मेदार हैं, दोनों ठेकेदार और ग्राहक, कि यह परिणाम केवल संयुक्त प्रयासों और समझौता के परिणामस्वरूप संभव है, सही क्लाइंट प्राप्त करता है, अंत में, उसे क्या चाहिए, उसे क्या प्रदान करता है प्रतिद्वंद्वियों पर प्रतिस्पर्धात्मक लाभ।

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

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

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

इस स्थिति में, प्रबंधक कोई निर्णय नहीं ले सकता है। दर्जनों पीड़ितों द्वारा न्याय की मांग की जाती है, जो कंपनी द्वारा पूरी तरह से नाराज होंगे, अगर उनकी परेशानियों के असली अपराधी कम से कम वास्तविक, अर्थात् उनके साथ वित्तीय जिम्मेदारी नहीं साझा करते हैं।

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

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

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

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

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

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

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

70 . 250 . , . , , , , , – , . , — , – … . , , . , , . .

, , - , , , , , . , , , - . , , , .

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

: , , – , . , , – , .