एक टीम में संघर्ष प्रबंधन - एक संतुलन कार्य या एक महत्वपूर्ण आवश्यकता?

आदर्श वाक्य:
एक बार की बात है, हेजहोग और छोटा भालू जंगल में मिले।
- नमस्ते, हेजहोग!
- नमस्ते, छोटा भालू!
तो, शब्द दर शब्द, मज़ाक दर मज़ाक, हेजहोग के चेहरे पर छोटे भालू ने प्रहार किया...

नीचे हमारे टीम लीडर के साथ-साथ आरएएस उत्पाद विकास निदेशक इगोर मार्नाट की कार्य संघर्षों की विशिष्टताओं और उन्हें प्रबंधित करने के संभावित तरीकों के बारे में चर्चा है।

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

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

सभी स्थितियों में क्या समानता है जिसे कार्य संघर्ष की स्थिति के रूप में परिभाषित किया जा सकता है?



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

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

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

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

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

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

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

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

तीसरा महत्वपूर्ण बिंदु संचार का सामान्य दृष्टिकोण है। ये सामान्य चीज़ें हैं, कोई लौकिक चीज़ नहीं, लेकिन ये बहुत महत्वपूर्ण हैं। हम समय बचाने की कोशिश नहीं करते हैं, हम सभी प्रतिभागियों से बात करते हैं, हम व्यक्ति की आलोचना नहीं करते हैं, लेकिन हम उसके कार्यों के परिणामों पर विचार करते हैं ("आप असभ्य हैं" नहीं, लेकिन "शायद लोग इससे नाराज हो सकते हैं यह चीज़"), हम चेहरा बचाने का अवसर देते हैं, हम व्यक्तिगत रूप से चर्चा करते हैं, लाइन के सामने नहीं।

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

तदनुसार, एक संघर्ष (साथ ही किसी भी अन्य मुद्दे) को हल करने में, एक प्रबंधक को तीन दृष्टिकोणों को ध्यान में रखना चाहिए: अल्पकालिक - मुद्दे/संघर्ष को यहीं और अभी हल करने के लिए, मध्यम अवधि - एक और संघर्ष उत्पन्न होने की संभावना को कम करने के लिए इसी कारण से, और दीर्घकालिक - टीम के व्यक्ति में एक वयस्क संस्कृति विकसित करना।

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

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

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

आइए सरल से जटिल तक, कई विशिष्ट संघर्ष स्थितियों पर विचार करें:

संघर्ष काम के मुद्दों से संबंधित नहीं हैं

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

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

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

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

कार्य प्रक्रिया को अनुकूलित करने के दृष्टिकोण से (मध्यम अवधि परिप्रेक्ष्य जिसका मैंने उल्लेख किया है), यहां बहुत कुछ नहीं किया जा सकता है; अनुकूलन का एकमात्र बिंदु टीम बनाते समय संगतता कारक को ध्यान में रखना है न कि लोगों को रखना एक साथ पहले से कौन संघर्ष करेगा.

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

कार्य संबंधी मुद्दों से संबंधित संघर्ष:

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

मैं यहां दो विशिष्ट मामलों पर प्रकाश डालूंगा:

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

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

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

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

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

हमारी चर्चा कुछ इस तरह दिखी (बेशक, योजनाबद्ध तरीके से, बातचीत आधे घंटे तक चली):

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

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

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

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

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

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

सांस्कृतिक दृष्टिकोण से, जाहिर है, अधिक परिपक्व स्थिति के साथ, जिसमें पार्टियां अपने सहयोगियों के कार्यों की वास्तविक प्रेरणा को सुनने और समझने की कोशिश करती हैं और परियोजना और टीम की प्राथमिकताओं के आधार पर कार्य करती हैं, न कि व्यक्तिगत अहंकार के आधार पर। , संघर्ष को आसानी से और तेजी से हल किया जाएगा।

तकनीकी समाधान के चुनाव पर एक अन्य संघर्ष में, मुझे एक पक्ष की प्रेरणा को समझने में काफी समय लगा (यह एक बहुत ही असामान्य मामला था), लेकिन प्रेरणा स्पष्ट होने के बाद, समाधान स्पष्ट था।

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

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

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

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

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

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

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

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

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

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

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

स्रोत: www.habr.com