एक टीम के भीतर प्रतिस्पर्धा टीम भावना को मार देती है

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

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

जीवन उदाहरण

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

यह स्पष्ट है कि इन विभागों के कर्मचारी एक दूसरे से भयंकर घृणा करते हैं (नेतृत्व द्वारा कुशलता से ईंधन) और एक दूसरे को दुश्मन मानते हैं।

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

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

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

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

वैसे, कुछ इस दृष्टिकोण को वर्णित कंपनी की विफलता के मुख्य कारणों में से एक मानते हैं ।

टीम के भीतर इस तरह की प्रतियोगिता को लागू करना कर्मचारियों को जीत-हार शैली में काम करने के लिए मजबूर करता है - एक मॉडल जिसमें एक तरफ जीत जरूरी दूसरी (और इसके विपरीत) को खोने के लिए मजबूर करती है। अगर मैं जीत गया, तो तुम हार गए। अगर तुम जीते, तो मैं हार गया। वह इतना बुरा क्यों है?

जीत-हार

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

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

अन्य टीमों के लोगों के साथ संवाद करते समय यह दृष्टिकोण और भी स्पष्ट होता है, जिस पर आपकी परियोजना की सफलता निर्भर करती है।

मुझे लगता है कि हम में से प्रत्येक ने कम से कम एक बार ऐसा कुछ सुना है:

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

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

कार्य बहुत लंबे समय तक हल किए जाते हैं या बिल्कुल हल नहीं होते हैं

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

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

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

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

खरोंच से समस्याएं दिखाई देती हैं

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

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

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

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

छिपी हुई तोड़फोड़

अव्यक्त तोड़फोड़ संभवतः आंतरिक प्रतिस्पर्धा का सबसे विनाशकारी प्रकटीकरण है। यह टीम के अन्य सदस्यों के काम की जानबूझकर जटिलता का प्रतिनिधित्व करता है। इस तरह की तोड़फोड़ का एक ज्वलंत उदाहरण C ++ कोड की जानी-मानी लाइन है: " #define TRUE FALSE // हैप्पी डीबगिंग, s * ki ... "

यह स्पष्ट है कि केवल असामाजिक अद्वितीय ही खुले तौर पर ऐसा करेंगे, लेकिन अपनी श्रेष्ठता दिखाने के लिए सहकर्मियों की छिपी हुई उत्तेजना, दुर्भाग्य से, टीम उत्पादकता को कम कर सकती है।

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

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

उदासीनता और सामान्य लक्ष्यों की कमी

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

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

यदि ऊपर वर्णित अन्य समस्याएं अभी भी किसी भी तरह से लड़ी जा सकती हैं (उदाहरण के लिए, प्रशासनिक तरीकों से), तो एक प्रणाली में सामान्य लक्ष्यों की कमी की समस्या जहां टीम के भीतर प्रतियोगिता का प्रचार किया जाता है वह व्यावहारिक रूप से ठीक नहीं होती है। अगर टीम के एक सदस्य की सफलता का मतलब दूसरे की विफलता है तो लोगों के पास सामान्य लक्ष्य नहीं हो सकते। जल्दी या बाद में, टीम समाप्त हो जाएगी।

लोगों को एक सामान्य काम करने के लिए कैसे प्रेरित करें?

जीत मिली

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

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

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

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

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

और, सबसे महत्वपूर्ण बात, यह स्पष्ट रूप से और स्पष्ट रूप से हर किसी के लिए सोचा के लिए आवश्यक है: "हम सभी का एक लक्ष्य है, हम सभी एक सामान्य बात करते हैं" और अपने स्वयं के शब्दों या कर्मों में इस दृष्टिकोण का उल्लंघन नहीं करते हैं।

लोगों को समझना चाहिए: वे केवल एक साथ कुछ कर सकते हैं, केवल बलों में शामिल होकर। प्रत्येक टीम का सदस्य कैरियर की वृद्धि में बाधा नहीं है, लेकिन एक दोस्त जो आपको इस सीढ़ी पर अगले कदम पर चढ़ने पर आपको एक हाथ देगा (या आपको धक्का देगा)।

केवल इस मामले में, टीम के पास कुछ महत्वपूर्ण और महत्वपूर्ण काम करने का मौका होगा, और न केवल कंप्यूटर के कीबोर्ड को मिटा देगा, समय-समय पर बेकार काम के क्लोन जारी करेगा।

आपके विकास में शुभकामनाएँ, और अपनी टीम में सहयोग का शासन करने दें (जैसे कि हमारा :)!

वैसे, कई परिस्थितियां हैं जिनमें टीमों के बीच प्रतिस्पर्धा उपयोगी है। लेकिन यह पूरी तरह से अलग कहानी है ...