संघातील संघर्ष व्यवस्थापन – समतोल साधणारी कृती की अत्यावश्यक गरज?

एपिग्राफ:
एकदा, हेजहॉग आणि लहान अस्वल जंगलात भेटले.
- हॅलो, हेज हॉग!
- हॅलो, लहान अस्वल!
तर, शब्दाने शब्द, विनोदाने विनोद, हेजहॉग लहान अस्वलाने तोंडावर मारला...

खाली आमच्या टीम लीडर, तसेच RAS प्रोडक्ट डेव्हलपमेंट डायरेक्टर इगोर मारनाट यांच्याकडून कामातील संघर्षांची वैशिष्ट्ये आणि त्यांचे व्यवस्थापन करण्याच्या संभाव्य पद्धतींबद्दल चर्चा आहे.

कामाच्या ठिकाणी आपल्याला येणारे बहुतेक संघर्ष वरील एपिग्राफमध्ये वर्णन केलेल्या परिस्थितीनुसार विकसित होतात. असे बरेच सहभागी आहेत जे सुरुवातीला एकमेकांबद्दल अनुकूल आहेत; ते काही समस्या सोडवण्याचा प्रयत्न करीत आहेत, परंतु शेवटी समस्या निराकरण होत नाही आणि काही कारणास्तव चर्चेतील सहभागींमधील संबंध खराब होतात.

जीवन वैविध्यपूर्ण आहे, आणि वर वर्णन केलेल्या परिस्थितीत फरक आढळतात. काहीवेळा सहभागींमधील संबंध सुरुवातीला फार चांगले नसतात, काहीवेळा अशी समस्या देखील नसते ज्यासाठी थेट निराकरण आवश्यक असते (उदाहरणार्थ, एपिग्राफमध्ये), काहीवेळा चर्चेनंतर संबंध सुरू होण्याआधी सारखेच राहतात, परंतु शेवटी प्रश्न सुटलेला नाही.

सर्व परिस्थितींमध्ये काय सामान्य आहे ज्याची व्याख्या कामाच्या संघर्षाची परिस्थिती म्हणून केली जाऊ शकते?



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

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

तिसरे म्हणजे, संघर्षाचा निर्धारक घटक (आमच्या चर्चेच्या दृष्टिकोनातून) ही वस्तुस्थिती आहे की प्रक्रियेतील पक्ष स्वतंत्रपणे सर्व पक्षांना अनुकूल असलेल्या समस्येचे निराकरण करू शकत नाहीत. परिस्थितीमध्ये तृतीय पक्ष, बाह्य लवादाचा हस्तक्षेप आवश्यक आहे. हा मुद्दा विवादास्पद वाटू शकतो, परंतु, थोडक्यात, जर बाह्य लवादाच्या हस्तक्षेपाशिवाय संघर्षाची परिस्थिती यशस्वीरित्या सोडवली गेली, तर समस्या यशस्वीरित्या सोडवली गेली आणि पक्षांचे संबंध बिघडले नाहीत, ही परिस्थिती आहे ज्यासाठी आपण प्रयत्न केले पाहिजेत. . आम्हाला बहुधा अशा संघर्षाबद्दल माहितही नसेल किंवा ते सोडवल्यानंतर आम्हाला योगायोगाने कळेल. संघ जितके अधिक मुद्दे स्वतःहून सोडवू शकेल तितके ते अधिक प्रभावी होईल.

संघर्षाचे आणखी एक वैशिष्ट्यपूर्ण वैशिष्ट्य जे स्पर्श करण्यासारखे आहे ते म्हणजे निर्णयादरम्यान भावनिक तीव्रतेची डिग्री. संघर्ष हा उच्च भावनिक स्तराशी निगडीत असतोच असे नाही. थोडक्यात, संघर्षाची परिस्थिती होण्यासाठी सहभागींना ओरडण्याची आणि हात हलवण्याची गरज नाही. समस्येचे निराकरण झाले नाही, एक विशिष्ट भावनिक तणाव उपस्थित आहे (कदाचित ते स्पष्टपणे बाहेरून व्यक्त केले जात नाही), याचा अर्थ असा आहे की आपल्याला संघर्षाच्या परिस्थितीचा सामना करावा लागतो.

संघर्षाच्या परिस्थितीत हस्तक्षेप करणे अजिबात आवश्यक आहे का, किंवा त्यांचे निराकरण त्याच्या मार्गाने होऊ देणे आणि समस्या स्वतःच सुटण्याची प्रतीक्षा करणे चांगले आहे? गरज आहे. संघर्ष पूर्णपणे सोडवणे नेहमीच तुमच्या सामर्थ्यात किंवा सक्षमतेमध्ये नसते, परंतु कोणत्याही परिस्थितीत, कोणत्याही स्तराच्या संघर्षात, तुम्ही प्रौढ स्थिती घेऊ शकता, ज्यामुळे तुमच्या आजूबाजूला आणखी बरेच लोक आणू शकता, त्याचे नकारात्मक परिणाम कमी करू शकता. संघर्ष आणि त्याचे निराकरण करण्यासाठी योगदान.

संघर्षाच्या परिस्थितीची काही उदाहरणे पाहण्याआधी, सर्व संघर्षांमध्ये साम्य असलेल्या काही महत्त्वाच्या मुद्द्यांकडे पाहू.

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

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

तिसरा महत्त्वाचा मुद्दा म्हणजे संप्रेषणाचा सामान्य दृष्टीकोन. या सामान्य गोष्टी आहेत, काही वैश्विक नाही, परंतु त्या खूप महत्वाच्या आहेत. आम्ही वेळ वाचवण्याचा प्रयत्न करत नाही, आम्ही सर्व सहभागींशी बोलतो, आम्ही त्या व्यक्तीवर टीका करत नाही, परंतु आम्ही त्याच्या कृतींचे परिणाम विचारात घेतो ("तुम्ही असभ्य आहात" असे नाही, परंतु "कदाचित मुले नाराज होऊ शकतात. ही गोष्ट”), आम्ही चेहरा वाचवण्याची संधी देतो, आम्ही वैयक्तिकरित्या चर्चा करतो, रेषेसमोर नाही.

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

त्यानुसार, विवाद (तसेच इतर कोणत्याही समस्येचे) निराकरण करताना, व्यवस्थापकाने तीन दृष्टीकोन लक्षात ठेवले पाहिजेत: अल्पकालीन - समस्या/संघर्ष येथे आणि आता सोडवण्यासाठी, मध्यम-मुदतीचा - दुसरा संघर्ष उद्भवण्याची शक्यता कमी करण्यासाठी त्याच कारणास्तव, आणि दीर्घकालीन - टीम व्यक्तीमध्ये प्रौढ संस्कृती जोपासण्यासाठी.

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

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

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

साध्या ते जटिल अशा अनेक ठराविक संघर्ष परिस्थितींचा विचार करूया:

कामाच्या समस्यांशी संबंधित नसलेले मतभेद

बर्‍याचदा कामावर संघर्ष होतात जे कामाच्या समस्यांशी संबंधित नसतात. त्यांची घटना आणि रिझोल्यूशनची सुलभता सहसा सहभागींच्या भावनिक बुद्धिमत्तेच्या पातळीशी, त्यांच्या परिपक्वतेच्या पातळीशी थेट संबंधित असते आणि कार्य प्रक्रियेच्या परिपूर्णतेशी किंवा अपूर्णतेशी संबंधित नसते.

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

माझ्या कामाच्या दरम्यान मला अनेक वेळा समोर आलेले आणखी एक उदाहरण म्हणजे टीम सदस्यांची मानसिक विसंगती. काही कारणास्तव, लोक एकत्र काम करू शकत नाहीत; प्रत्येक संवाद एका घोटाळ्यात संपतो. काहीवेळा हे या वस्तुस्थितीमुळे होते की लोक काही महत्त्वाच्या मुद्द्यावर (सामान्यतः राजकीय) ध्रुवीय दृष्टिकोन ठेवतात आणि त्यांना कामाच्या बाहेर कसे सोडायचे हे माहित नसते. त्यांना एकमेकांना सहन करण्यास किंवा त्यांचे वर्तन बदलण्यास पटवून देणे हे एक व्यर्थ काम आहे. मला फक्त एकच अपवाद आढळला आहे तो म्हणजे खुल्या समज असलेले तरुण सहकारी; त्यांचे वर्तन अजूनही नियतकालिक संभाषणातून हळूहळू बदलले जाऊ शकते. सहसा समस्या वेगवेगळ्या संघांमध्ये विभक्त करून किंवा कमीत कमी क्वचितच कामावर आच्छादित होण्याची संधी देऊन यशस्वीरित्या सोडवली जाते.

वरील सर्व परिस्थितींमध्ये, सर्व सहभागींशी वैयक्तिकरित्या बोलणे, परिस्थितीवर चर्चा करणे, त्यांना या प्रकरणात काही समस्या दिसत आहेत का हे विचारणे, त्यांच्या मते, उपाय काय आहेत हे विचारणे आणि हे करण्यात त्यांचा सहभाग सुनिश्चित करणे योग्य आहे. निर्णय.

कामाच्या प्रक्रियेला अनुकूल करण्याच्या दृष्टिकोनातून (मी नमूद केलेला मध्यम-मुदतीचा दृष्टीकोन), येथे बरेच काही केले जाऊ शकत नाही; ऑप्टिमायझेशनचा एकमेव मुद्दा म्हणजे संघ तयार करताना अनुकूलता घटक विचारात घेणे आणि लोकांना न घालणे. एकत्र आगाऊ कोण संघर्ष होईल.

सांघिक संस्कृतीच्या दृष्टीकोनातून, प्रौढ संस्कृती असलेल्या संघांमध्ये अशा परिस्थिती फारच कमी वेळा उद्भवतात, जेथे लोक संघ आणि सहकाऱ्यांचा आदर करतात आणि समस्यांचे स्वतंत्रपणे निराकरण कसे करावे हे माहित असते. याव्यतिरिक्त, अशा संघर्षांचे निराकरण अधिक सहजपणे (बहुतेकदा आपोआप) अशा संघांमध्ये केले जाते जेथे उच्च पातळीचा विश्वास असतो, लोक बर्याच काळापासून एकत्र काम करतात आणि/किंवा कामाच्या बाहेर वारंवार संवाद साधतात.

कामाच्या समस्यांशी संबंधित मतभेद:

असे संघर्ष सहसा एकाच वेळी दोन्ही कारणांमुळे होतात, दोन्ही भावनिक (सहभागीपैकी एक प्रौढ व्यक्तीच्या स्थितीत नसल्याची वस्तुस्थिती) आणि कार्य प्रक्रियेची अपूर्णता. कोड पुनरावलोकने किंवा विकासकांमधील आर्किटेक्चर चर्चेदरम्यान कदाचित मला आलेला संघर्षांचा सर्वात सामान्य प्रकार.

मी येथे दोन सामान्य प्रकरणे हायलाइट करेन:

1) पहिल्या प्रकरणात, विकासक सहकाऱ्याकडून कोड पुनरावलोकन मिळवू शकत नाही. पॅच पुनरावलोकनासाठी पाठविला जातो आणि काहीही होत नाही. पहिल्या दृष्टीक्षेपात, दोन्ही बाजूंमध्ये कोणताही स्पष्ट संघर्ष दिसत नाही, परंतु जर आपण त्याबद्दल विचार केला तर, हा जोरदार संघर्ष आहे. कामाच्या समस्येचे निराकरण झाले नाही, पक्षांपैकी एक (पुनरावलोकनाची वाट पाहत आहे) स्पष्ट अस्वस्थता अनुभवतो. या प्रकरणाचा एक अत्यंत उपप्रकार म्हणजे समुदायामध्ये किंवा वेगवेगळ्या संघांमध्ये विकास, जेव्हा समीक्षकाला या विशिष्ट कोडमध्ये स्वारस्य नसू शकते, लोडिंग किंवा इतर परिस्थितींमुळे, पुनरावलोकन विनंतीकडे अजिबात लक्ष दिले जात नाही आणि बाह्य लवाद (दोन्ही बाजूंना सामाईक व्यवस्थापक) ) कदाचित अस्तित्वात नाही.

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

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

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

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

आमची चर्चा यासारखी दिसली (अत्यंत योजनाबद्धपणे, अर्थातच, संभाषण अर्धा तास चालले):

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

मुद्दा सुटला, वेळेवर सुटका झाली, पाशाला फारसा असंतोष वाटला नाही, कारण त्यांनी स्वतः एक उपाय सुचवला आणि तो अंमलात आणला. इगोर सामान्यतः खूश होते, कारण ... त्यांचे मत विचारात घेण्यात आले आणि त्यांनी सांगितल्याप्रमाणे केले.

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

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

हे सर्व बराच काळ चालले, जोपर्यंत मला शेवटी कळले नाही की आम्ही समस्येच्या तांत्रिक पैलूंवर चर्चा करत आहोत, परंतु समस्या प्रत्यक्षात तांत्रिक नव्हती. समस्या एसटीएलचे फायदे किंवा तोटे किंवा त्याशिवाय काम करण्याच्या अडचणी नाहीत. समस्या ऐवजी संघटनात्मक आहे. आम्ही ज्या कंपनीसाठी काम केले त्या कंपनीने कसे काम केले हे समजून घेणे आवश्यक आहे. अशा कंपनीत काम करण्याचा अनुभव आमच्यापैकी कोणालाच नव्हता. गोष्ट अशी होती की कोड विकसित झाल्यानंतर आणि उत्पादनात सोडल्यानंतर, समर्थन इतर संघातील, इतर देशांतील पूर्णपणे भिन्न लोकांद्वारे हाताळले गेले. हजारो अभियंत्यांचा हा मोठा अभियांत्रिकी संघ (एकूण) केवळ पूर्णपणे मूलभूत किमान तांत्रिक साधने घेऊ शकतो, म्हणून बोलायचे तर, किमान किमान. कंपनीमध्ये भौतिकरित्या स्थापित केलेल्या अभियांत्रिकी मानकांच्या पलीकडे गेलेली कोणतीही गोष्ट भविष्यात समर्थित होऊ शकत नाही. संघाची पातळी त्याच्या कमकुवत सदस्यांच्या पातळीनुसार निर्धारित केली जाते. आम्हाला समजल्यानंतर वास्तविक प्रेरणा कार्यसंघाच्या अमेरिकन भागाच्या कृतींमुळे, हा मुद्दा अजेंडातून काढून टाकला गेला आणि आम्ही एकत्रितपणे कंपनीने स्वीकारलेल्या मानकांचा वापर करून उत्पादन यशस्वीरित्या विकसित केले आणि सोडले. या प्रकरणात पत्रे आणि चॅट्स चांगले कार्य करत नाहीत; एका सामान्य भाजकापर्यंत येण्यासाठी अनेक ट्रिप आणि बरेच वैयक्तिक संप्रेषण करावे लागले.

वर्कफ्लोच्या दृष्टिकोनातून, या विशिष्ट प्रकरणात, वापरलेल्या साधनांचे वर्णन, त्यांच्यासाठी आवश्यकता, नवीन जोडण्यावरील निर्बंध आणि अशा निर्बंधांचे समर्थन करण्यात मदत होईल. असे दस्तऐवज अंदाजे परिच्छेदांमध्ये वर्णन केलेल्या “सॉफ्टवेअर डेव्हलपमेंटसाठी व्यवस्थापकाच्या हँडबुक” च्या स्ट्रॅटेजी आणि डेव्हलपमेंट एन्व्हायर्नमेंटमध्ये विकसित केलेल्या परिच्छेदांशी संबंधित आहेत. नासा. त्याचे वय असूनही, ते या प्रकारच्या सॉफ्टवेअर विकासाच्या सर्व मुख्य क्रियाकलाप आणि नियोजन चरणांचे उत्तम प्रकारे वर्णन करते. यासारखे दस्तऐवज असल्‍याने उत्‍पादनात कोणते घटक आणि पध्‍दती वापरता येतील आणि का वापरता येतील यावर चर्चा करणे खूप सोपे होते.

सांस्कृतिक दृष्टिकोनातून, स्पष्टपणे, अधिक परिपक्व स्थितीसह, ज्यामध्ये पक्ष त्यांच्या सहकाऱ्यांच्या कृतींची खरी प्रेरणा ऐकण्याचा आणि समजून घेण्याचा प्रयत्न करतात आणि प्रकल्प आणि कार्यसंघाच्या प्राधान्यांवर आधारित कृती करतात, वैयक्तिक अहंकार नाही. , संघर्ष सुलभ आणि जलद सोडवला जाईल.

तांत्रिक सोल्यूशनच्या निवडीवरील दुसर्‍या संघर्षात, पक्षांपैकी एकाची प्रेरणा समजून घेण्यासाठी मला लक्षणीय वेळ लागला (हे एक अतिशय असामान्य प्रकरण होते), परंतु प्रेरणा स्पष्ट झाल्यानंतर, समाधान स्पष्ट होते.

परिस्थिती अशी आहे: सुमारे 20 लोकांच्या टीममध्ये एक नवीन विकसक दिसतो, त्याला स्टॅस म्हणूया. त्या वेळी, एक संघ म्हणून संप्रेषणासाठी आमचे मानक साधन स्काईप होते. हे नंतर दिसून आले की, Stas मुक्त मानके आणि मुक्त स्त्रोत सॉफ्टवेअरचा एक मोठा चाहता होता, आणि ज्यांचे स्त्रोत सार्वजनिकरित्या उपलब्ध होते आणि ज्यांनी सार्वजनिकरित्या वर्णन केलेले प्रोटोकॉल वापरलेले फक्त साधने आणि ऑपरेटिंग सिस्टम वापरली. स्काईप हे यापैकी एक साधन नाही. आम्ही या दृष्टिकोनाचे फायदे आणि तोटे यावर चर्चा करण्यात बराच वेळ घालवला, वेगवेगळ्या ऑपरेटिंग सिस्टमवर स्काईपचे अॅनालॉग्स लाँच करण्याचा प्रयत्न केला, टीमला इतर मानकांवर स्विच करण्यासाठी स्टॅसचे प्रयत्न, त्याला वैयक्तिकरित्या मेलद्वारे लिहा, त्याला वैयक्तिकरित्या कॉल करा. फोन, त्याला विशेषत: स्काईपसाठी दुसरा संगणक विकत घ्या, इ. शेवटी, मला समजले की ही समस्या, तत्वतः, तांत्रिक किंवा संस्थात्मक नाही, ती त्याऐवजी वैचारिक आहे, अगदी, कोणी म्हणेल, धार्मिक (स्टॅससाठी). जरी आम्ही अखेरीस Stas आणि Skype (ज्याला अनेक महिने लागले) कनेक्ट केले तरीही, त्यानंतरच्या कोणत्याही इन्स्ट्रुमेंटवर समस्या पुन्हा उद्भवेल. स्टॅसचा जागतिक दृष्टिकोन बदलण्यासाठी माझ्याकडे कोणतेही वास्तविक साधन नव्हते आणि या वातावरणात उत्तम प्रकारे कार्य करणाऱ्या संघाचे जागतिक दृष्टिकोन बदलण्याचा प्रयत्न करण्याचे कोणतेही कारण नव्हते. व्यक्ती आणि कंपनी त्यांच्या जागतिक दृश्यात फक्त ऑर्थोगोनल होते. अशा परिस्थितीत, एक चांगला उपाय संघटनात्मक आहे. आम्ही स्टासला दुसर्या संघात स्थानांतरित केले, जिथे तो अधिक सेंद्रिय होता.

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

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

परिस्थितीचे निराकरण करण्यासाठी, मी त्याला मला दाखवायला सांगितले की सर्वकाही खरोखर कार्य करते (ते कार्य करत नाही, आणि त्याला ते दुरुस्त करावे लागले), आम्ही संघाशी आणि पूर्ण केलेल्या QA व्याख्येसह बोललो (त्यांनी ते केले नाही लेखन, कारण आम्हाला प्रक्रिया खूप नोकरशाही बनवायची नव्हती ), बरं, आम्ही लवकरच या तज्ञाशी (सामान्य आरामासाठी) मार्ग काढला.

वर्कफ्लोच्या दृष्टीकोनातून, या प्रकरणात संभाव्य सुधारणा म्हणजे पूर्ण केलेल्या व्याख्येची उपस्थिती, प्रत्येक युनिट वैशिष्ट्याच्या समर्थनासाठी आवश्यकता आणि एकत्रीकरण चाचण्या आणि विकासकाद्वारे केलेल्या चाचणीचे वर्णन. एका प्रकल्पामध्ये, आम्ही CI दरम्यान चाचण्यांद्वारे कोड कव्हरेजची पातळी मोजली आणि पॅच जोडल्यानंतर कव्हरेज पातळी कमी झाल्यास, चाचण्या अयशस्वी म्हणून चिन्हांकित केल्या गेल्या, म्हणजे. कोणताही नवीन कोड केवळ नवीन चाचण्या असल्यासच जोडला जाऊ शकतो.

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

या परिस्थितीत, संघर्षाचे निराकरण स्वतःच अगदी स्पष्ट आणि रेषीय आहे (उत्पादनाचे निराकरण करा, दस्तऐवजीकरण आणि चाचण्या अद्यतनित करा, ग्राहकाला संतुष्ट करा, हॉटफिक्स सोडा इ.). कामाच्या प्रक्रियेचे विश्लेषण करणे आणि दोन संघांमधील परस्परसंवाद आयोजित करण्यासाठी कोण जबाबदार आहे हे समजून घेणे आणि ही परिस्थिती प्रथमतः का शक्य झाली हे समजून घेणे महत्वाचे आहे. प्रक्रियेत काय निश्चित केले जाणे आवश्यक आहे हे स्पष्ट आहे - कोणीतरी ग्राहकांच्या स्मरणपत्रांशिवाय संपूर्ण चित्राचे सक्रियपणे निरीक्षण केले पाहिजे. विकसकांच्या इतर तिकिटांमध्ये ग्राहकाची तिकिटे वेगळी असली पाहिजेत. डेव्हलपमेंट टीम सध्या त्याच्या तिकिटांवर काम करत आहे की नाही हे सपोर्टने पाहिले पाहिजे आणि नसल्यास, ते केव्हा काम सुरू करू शकते आणि केव्हा अपेक्षित परिणाम मिळू शकतात. समर्थन आणि विकास यांनी वेळोवेळी संवाद साधला पाहिजे आणि तिकिटांच्या स्थितीबद्दल चर्चा केली पाहिजे, डीबगिंगसाठी आवश्यक माहितीचे संकलन शक्य तितके स्वयंचलित केले पाहिजे इ.

ज्याप्रमाणे युद्धात शत्रू दोन तुकड्यांमधील जंक्शनवर आदळण्याचा प्रयत्न करतो, त्याचप्रमाणे कामात सर्वात नाजूक आणि असुरक्षित मुद्दा म्हणजे संघांमधील परस्परसंवाद. जर सपोर्ट आणि डेव्हलपमेंट मॅनेजर पुरेसे जुने असतील, तर ते प्रक्रिया स्वतःच दुरुस्त करू शकतील, जर नसेल तर, जोपर्यंत मॅनेजर हस्तक्षेप करत नाही तोपर्यंत ही प्रक्रिया संघर्ष आणि समस्या निर्माण करत राहील.

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

वर्कफ्लोच्या दृष्टीकोनातून, समस्येचे निराकरण करण्यासाठी विशिष्ट पायऱ्या संघांची रचना, चाचण्यांचा प्रकार आणि उत्पादन इत्यादींवर अवलंबून असतात. एका प्रकल्पात, आम्ही नियतकालिक कर्तव्य सादर केले, ज्यामध्ये संघांनी आठवड्यातून एका वेळी चाचणीचे परीक्षण केले. दुसऱ्यामध्ये, प्रारंभिक विश्लेषण नेहमी चाचणी विकसकांद्वारे केले जात असे, परंतु विश्लेषण अतिशय मूलभूत होते आणि उत्पादन बरेच स्थिर होते, त्यामुळे ते चांगले कार्य करते. मुख्य म्हणजे प्रक्रिया पारदर्शक आहे, सर्व पक्षांच्या अपेक्षा स्पष्ट आहेत आणि प्रत्येकाला परिस्थिती न्याय्य वाटते याची खात्री करणे आहे.

संघर्ष ही एखाद्या संस्थेमध्ये देखील समस्या आहे का? तुमच्या संघात अनेकदा (किंवा फक्त वेळोवेळी) संघर्ष होणे हे वाईट लक्षण आहे का? सर्वसाधारणपणे, नाही, कारण जर वाढ, विकास असेल, काही प्रकारची गतिशीलता असेल, तर असे मुद्दे उद्भवतात जे यापूर्वी कधीही सोडवले गेले नाहीत आणि त्यांचे निराकरण करताना संघर्ष उद्भवू शकतात. हे एक सूचक आहे की काही क्षेत्रांवर लक्ष देणे आवश्यक आहे, सुधारण्यासाठी काही क्षेत्रे आहेत. संघर्ष खूप वेळा उद्भवला तर ते वाईट आहे, निराकरण करणे कठीण आहे किंवा बराच वेळ लागतो. हे बहुधा अपर्याप्तपणे सुव्यवस्थित कार्य प्रक्रिया आणि संघाच्या अपुरी परिपक्वतेचे लक्षण आहे.

स्त्रोत: www.habr.com