टोलीमा द्वन्द्व व्यवस्थापन - सन्तुलन कार्य वा महत्त्वपूर्ण आवश्यकता?

Epigraph:
एक पटक, हेजहग र सानो भालु जंगलमा भेटे।
- नमस्ते, हेजहग!
- नमस्ते, सानो भालु!
त्यसोभए, शब्द द्वारा शब्द, मजाक द्वारा ठट्टा, हेजहग सानो भालुले अनुहारमा प्रहार गर्यो ...

तल हाम्रो टोली नेता, साथसाथै RAS उत्पादन विकास निर्देशक इगोर मारनाटबाट, कार्य द्वन्द्व र तिनीहरूलाई व्यवस्थापन गर्न सम्भावित विधिहरूको विवरणहरूको बारेमा छलफल गरिएको छ।

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

जीवन विविध छ, र माथि वर्णन गरिएको परिदृश्यमा भिन्नताहरू हुन्छन्। कहिलेकाँही सहभागीहरू बीचको सम्बन्ध सुरुमा धेरै राम्रो हुँदैन, कहिलेकाहीँ त्यहाँ कुनै समस्या पनि हुँदैन जसको लागि प्रत्यक्ष समाधान चाहिन्छ (जस्तै, एपिग्राफमा), कहिलेकाहीँ छलफल पछि सम्बन्ध सुरु हुनु अघि जस्तै रहन्छ, तर समस्या अन्ततः समाधान छैन।

कार्य द्वन्द्वको अवस्थाको रूपमा परिभाषित गर्न सकिने सबै परिस्थितिहरूमा के सामान्य छ?



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

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

तेस्रो, द्वन्द्वको निर्णायक कारक (हाम्रो छलफलको दृष्टिकोणबाट) प्रक्रियाका पक्षहरू स्वतन्त्र रूपमा सबै पक्षहरूलाई मिल्ने मुद्दाको समाधानमा आउन नसक्ने तथ्य हो। स्थितिमा तेस्रो पक्ष, बाह्य मध्यस्थको हस्तक्षेप आवश्यक छ। यो बिन्दु विवादास्पद लाग्न सक्छ, तर, संक्षेपमा, यदि बाह्य मध्यस्थको हस्तक्षेप बिना द्वन्द्वको स्थिति सफलतापूर्वक समाधान भयो भने, समस्या सफलतापूर्वक समाधान भयो र पक्षहरूको सम्बन्ध बिग्रन नदिने स्थिति हो, हामीले प्रयास गर्नुपर्छ। । हामीलाई सम्भवतः यस्तो द्वन्द्वको बारेमा थाहा हुँदैन, वा हामी यसलाई समाधान गरेपछि संयोगले थाहा पाउनेछौं। टोलीले जति धेरै समस्याहरू आफैं समाधान गर्न सक्छ, त्यति नै प्रभावकारी हुनेछ।

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

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

द्वन्द्व अवस्थाका केही उदाहरणहरू हेर्नु अघि, सबै द्वन्द्वहरूमा साझा हुने केही महत्त्वपूर्ण बुँदाहरू हेरौं।

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

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

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

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

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

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

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

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

धेरै सामान्य द्वन्द्व अवस्थाहरू विचार गरौं, साधारण देखि जटिल सम्म:

कामका मुद्दाहरूसँग सम्बन्धित नभएका विवादहरू

प्रायः त्यहाँ काममा विवादहरू छन् जुन कामका मुद्दाहरूसँग सम्बन्धित छैनन्। तिनीहरूको घटना र समाधानको सहजता सामान्यतया प्रत्यक्ष रूपमा सहभागीहरूको भावनात्मक बुद्धिको स्तर, तिनीहरूको परिपक्वताको स्तरसँग सम्बन्धित छ, र कार्य प्रक्रियाको पूर्णता वा अपूर्णतासँग सम्बन्धित छैन।

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

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

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

कार्य प्रक्रियालाई अनुकूलन गर्ने दृष्टिकोणबाट (मैले उल्लेख गरेको मध्यम-अवधि परिप्रेक्ष्य), यहाँ धेरै गर्न सकिँदैन; अनुकूलनको लागि एकमात्र बिन्दु भनेको टोली गठन गर्दा अनुकूलता कारकलाई ध्यानमा राख्नु हो र मानिसहरूलाई राख्नु हुँदैन। सँगै कसले द्वन्द्व गर्नेछ।

टोली संस्कृतिको परिप्रेक्ष्यमा, परिपक्व संस्कृति भएका टोलीहरूमा यस्ता परिस्थितिहरू धेरै कम हुन्छन्, जहाँ मानिसहरूले टोली र सहकर्मीहरूलाई सम्मान गर्छन् र स्वतन्त्र रूपमा समस्याहरू कसरी समाधान गर्ने भनेर जान्दछन्। थप रूपमा, त्यस्ता द्वन्द्वहरू धेरै सजिलैसँग समाधान गरिन्छ (प्रायः स्वचालित रूपमा) टोलीहरूमा जहाँ उच्च स्तरको विश्वास छ, मानिसहरूले लामो समयदेखि सँगै काम गरेका छन् र/वा कामभन्दा बाहिर बारम्बार सञ्चार गर्छन्।

कार्य सम्वन्धी विवादहरु:

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

म यहाँ दुई विशिष्ट केसहरू हाइलाइट गर्नेछु:

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

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

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

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

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

हाम्रो छलफल यस्तो देखियो (धेरै योजनाबद्ध रूपमा, पक्कै पनि, कुराकानी आधा घण्टा सम्म चल्यो):

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

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

अनिवार्य रूपमा समान द्वन्द्वको अर्को प्रकार भनेको प्राविधिक समाधानहरू/पुस्तकालयहरू/प्रोजेक्टमा विशेष गरी वितरित टोलीमा छनौट गर्ने हो। एउटा परियोजनामा, जुन C/C++ प्रयोग गरी राखिएको थियो, यो पत्ता लाग्यो कि परियोजनाको प्राविधिक व्यवस्थापन स्पष्ट रूपमा STL (Standard Template Library) को प्रयोगको विरुद्धमा थियो। यो एक मानक भाषा पुस्तकालय हो जसले विकासलाई सरल बनाउँछ, र हाम्रो टोली यसको लागि धेरै अभ्यस्त छ। यो पत्ता लाग्यो कि परियोजना C++ भन्दा C को धेरै नजिक छ, जसले टोलीलाई धेरै प्रेरित गरेन, किनभने व्यवस्थापनले सबै भन्दा राम्रो प्रयास गर्यो र साँच्चै राम्रो प्लस खेलाडीहरू भर्ती गर्यो। एकै समयमा, टोलीको अमेरिकी भाग, इन्जिनियरहरू र प्रबन्धकहरू दुवै, कम्पनीमा लामो समयको लागि काम गरेका थिए, हालको अवस्थाको लागि अभ्यस्त थिए, र सबै कुरामा खुसी थिए। टोलीको रूसी भाग केहि हप्ता भित्र (म सहित) सँगै ल्याइएको थियो। टोलीको रूसी भाग स्पष्ट रूपमा विकासको लागि सामान्य दृष्टिकोण त्याग्न चाहँदैन थियो।

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

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

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

सांस्कृतिक दृष्टिकोणबाट, स्पष्ट रूपमा, अधिक परिपक्व स्थितिको साथ, जहाँ पक्षहरूले आफ्ना सहकर्मीहरूको कार्यहरूको वास्तविक प्रेरणा सुन्न र बुझ्ने प्रयास गर्छन् र परियोजना र टोलीको प्राथमिकताहरूमा आधारित हुन्छन्, व्यक्तिगत अहंकार होइन। द्वन्द्व सहज र छिटो समाधान हुनेछ।

प्राविधिक समाधानको छनोटमा अर्को द्वन्द्वमा, यसले मलाई कुनै एक पक्षको प्रेरणा बुझ्नको लागि उल्लेखनीय समय लियो (यो धेरै असामान्य मामला थियो), तर प्रेरणा स्पष्ट भएपछि, समाधान स्पष्ट थियो।

अवस्था यस्तो छ: एक नयाँ विकासकर्ता लगभग 20 व्यक्तिहरूको टोलीमा देखा पर्दछ, उहाँलाई Stas भनिन्छ। त्यस समयमा, टोलीको रूपमा सञ्चारको लागि हाम्रो मानक उपकरण स्काइप थियो। यो पछि देखा पर्यो, Stas खुला मापदण्ड र खुला स्रोत सफ्टवेयरको ठूलो प्रशंसक थियो, र केवल उपकरण र अपरेटिङ सिस्टमहरू प्रयोग गर्थे जसको स्रोतहरू सार्वजनिक रूपमा उपलब्ध थिए र जसले सार्वजनिक रूपमा वर्णन गरिएको प्रोटोकलहरू प्रयोग गर्थे। स्काइप यी उपकरणहरू मध्ये एक होइन। हामीले यस दृष्टिकोणका फाइदाहरू र बेफाइदाहरूबारे छलफल गर्न धेरै समय बितायौं, विभिन्न अपरेटिङ सिस्टमहरूमा स्काइपको एनालगहरू सुरु गर्ने प्रयासहरू, टोलीलाई अन्य मापदण्डहरूमा स्विच गर्न मनाउन स्टासको प्रयासहरू, उहाँलाई व्यक्तिगत रूपमा मेलद्वारा लेख्नुहोस्, उहाँलाई व्यक्तिगत रूपमा कल गर्नुहोस्। फोन, उसलाई विशेष गरी स्काइप, इत्यादिको लागि दोस्रो कम्प्युटर किन्नुहोस्। अन्तमा, मैले महसुस गरें कि यो समस्या, संक्षेपमा, प्राविधिक वा संगठनात्मक होइन, यो बरु वैचारिक हो, यहाँसम्म कि, कसैले भन्न सक्छ, धार्मिक (स्टासका लागि)। यदि हामीले अन्ततः Stas र Skype लाई जोड्यौं (जसले धेरै महिना लियो), समस्या कुनै पनि अर्को उपकरणमा फेरि उत्पन्न हुनेछ। मसँग Stas को विश्वदृष्टिकोण परिवर्तन गर्न मेरो अधिकारमा कुनै वास्तविक माध्यम थिएन, र यस वातावरणमा पूर्ण रूपमा काम गर्ने टोलीको विश्व दृष्टिकोण परिवर्तन गर्ने प्रयास गर्ने कुनै कारण थिएन। व्यक्ति र कम्पनी तिनीहरूको विश्वव्यापी दृष्टिकोणमा केवल अर्थोगोनल थिए। यस्तो अवस्थामा, एक राम्रो समाधान संगठनात्मक छ। हामीले Stas लाई अर्को टोलीमा स्थानान्तरण गर्यौं, जहाँ उहाँ अधिक जैविक हुनुहुन्थ्यो।

यो द्वन्द्वको कारण, मेरो विचारमा, एक विशेष व्यक्तिको व्यक्तिगत संस्कृति (जससँग बलियो विचार छ जसले उसलाई सम्झौता गर्न अनुमति दिँदैन) र कम्पनीको संस्कृति बीचको भिन्नता हो। यस अवस्थामा, यो, निस्सन्देह, व्यवस्थापकको गल्ती हो। सुरुमा उनलाई यस्तो प्रोजेक्टमा लैजानु गलत थियो । Stas अन्ततः खुला स्रोत सफ्टवेयर विकास परियोजनामा ​​सारियो र त्यहाँ उत्कृष्ट भयो।

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

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

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

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

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

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

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

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

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

स्रोत: www.habr.com