Menaxhimi i konflikteve në ekip – ekvilibristikë apo një nevojë e jetës?

Epigrafi:
Një herë u takuan në pyll Dashi dhe Femija i Berberit.
— Përshëndetje, Dashi!
— Përshëndetje, Femija i Berberit!
Ashtu, fjala për fjalë, shaka për shaka, dhe Dashi mori nga Femija i Berberit një grusht ...

Nën këtë shkrim janë refleksionet e liderit tonë të ekipit, si dhe të drejtorit të zhvillimit të produktit RAS – Igor Maranat mbi specifikën e konflikteve në punë dhe metodat e mundshme të menaxhimit të tyre.

Shumica e konflikteve me të cilat përballimi në punë zhvillohen sipas një skenari të ngjashëm me atë të përshkruar më lart në epigraf. Ka disa pjesëmarrës, të cilët në fillim janë të disponueshëm ndaj njëri-tjetrit mjaft pozitivisht, ata përpiqen të zgjidhin një çështje, por në fund problemi mbetet i pazgjidhur, dhe marrëdhëniet ndërmjet pjesëmarrësve ndihen të prishura për një arsye të panjohur.

Jeta është e shumëllojshme, në skenarin e përshkruar më lart ndodhin variacione. Ndonjëherë marrëdhëniet ndërmjet pjesëmarrësve nuk janë fillimisht të mira, ndonjëherë nuk ka asnjë çështje që kërkon zgjidhje të menjëhershme (si, për shembull, në epigraf), ndonjëherë pas diskutimit marrëdhëniet mbeten ashtu siç ishin para fillimit të tij, por çështja në fund nuk është zgjidhur.

Çfarë kanë të përbashkët të gjitha situatat që mund të përcaktohen si një situatë konflikti në punë?



Së pari, kjo është prania e dy ose më shumë palëve. Këto palë mund të kenë pozita të ndryshme në organizatë, të jenë në marrëdhënie barazie (kolektivë në ekip), ose në nivele të ndryshme hierarkike (shef – nëndrejtor), të jenë individuale (punonjës) ose grupore (në rastet e konfliktit midis një punonjësi dhe ekipit ose dy ekipeve), e kështu me radhë. Nivelin e besimit ndërmjet pjesëmarrësve ka një ndikim të madh në probabilitetin e konfliktit dhe lehtësinë e zgjidhjes së tij. Sa më mirë të njohin njëri-tjetrin palët, aq më i lartë është niveli i besimit, aq më i lartë është shansi që ata të arrijnë një marrëveshje. Për shembull, punonjësit e një ekipi të shpërndarë, të cilët kurrë nuk kanë komunikuar në mënyrë personale, ka më shumë gjasa të hyjnë në një situatë konflikti kur zgjidhin një çështje të thjeshtë pune, se sa njerëzit që të paktën kanë komunikuar disa herë personalisht. Prandaj, duke punuar në ekipe të shpërndara, është shumë e rëndësishme të sigurohen takime personale periodike të gjithë anëtarëve të ekipit me njëri-tjetrin.

Në radhë të dytë, në situatën e një konflikti në punë, palët ndodhen në një situatë zgjidhjeje të një çështjeje, e cila është e rëndësishme për njërën nga palët, për të dyja ose për organizatën në tërësi. Në këtë rast, për shkak të karakteristikave të situatës, palët zakonisht kanë mjaft kohë dhe mënyra të ndryshme për ta zgjidhur atë (formale, informale, takime, letra, vendime nga drejtuesit, praninë e objektivave dhe planeve të ekipit, si dhe faktin e egzistencës së hierarkisë, etj.). Kjo është ndryshe nga situata e zgjidhjes së një çështjeje pune (ose jo pune) në organizatë, për shembull, zgjidhja e një pyetjeje të rëndësishme: "He, shoku, nga cila lagje je?!" në rrugë, ose konflikti nga epigrafi. Në rastin e zgjidhjes së një çështjeje pune, ka rëndësi cilësia e procesit të punës dhe kultura e zgjidhjes së problemeve në ekip.

Në radhë të tretë, një faktor përcaktues i konfliktit (nga këndvështrimi i diskutimit tonë) është fakti se palët e procesit nuk mund të arrijnë vetë një zgjidhje që përmbush të gjitha palët. Situata kërkon ndërhyrjen e një pale të tretë, një arbitri të jashtëm. Ky pikë mund të duket diskutueshme, por, në thelb, nëse situata konflitku është zgjidhur me sukses pa ndërhyrjen e një arbitri të jashtëm, çështja është zgjidhur me sukses dhe marrëdhëniet midis palëve nuk janë përkeqësuar, kjo është ajo situatë të cilës duhet t'i synojmë. Ne për një konflikt të tillë ndoshta as nuk do të mësojmë, ose do të mësojmë rastësisht pas zgjidhjes së tij. Sa më shumë çështje ekipi mund të zgjidhë vetë, aq më efektiv do të punojë.

Një tjetër karakteristikë e konfliktit që meriton përmendje është intensiteti emocional gjatë zgjidhjes. Konflikti nuk është domosdoshmërisht i lidhur me një gradë të lartë emocionale. Pjesëmarrësit nuk është e nevojshme të bërtasin dhe të përplasin duar për të qenë një situatë gjithsesi konfliktuale. Nëse një çështje nuk zgjidhet, dhe ka një tension emocional të caktuar, ndonëse ndoshta nuk është shprehur qartë jashtë, atëherë kjo paraqet një situatë konflikti.

A është e nevojshme të ndërhyni në situata konflikti, apo është më mirë të lejoni që zgjidhja e tyre të ndodhë vetë dhe të prisni që problemi të zgjidhet vetë? Po, është e nevojshme. Nuk është gjithmonë në fuqinë ose kompetencën tuaj të zgjidhni plotësisht një konflikt, por në çdo situatë, në një konflikt të çdo përmasash, ju mund të merrni një pozita të rritur, kështu duke përfshirë edhe disa njerëz të tjerë rreth jush, duke lehtësuar pasojat negative të konfliktit dhe duke kontribuar në zgjidhjen e tij.

Para se të diskutojmë disa shembuj të situatave konfliktuale, le të ndalemi në disa pika të rëndësishme, të përbashkëta për të gjitha Konfliktet.

Kur zgjidhni një konflikt, është e rëndësishme të jeni mbi betejë, e jo brenda saj (kjo quhet gjithashtu ‘të merrni një metapozitë’), domethënë, të mos jeni në procesin e zgjidhjes si një nga palët. Në të kundërt, si një arbitër i jashtëm që ndihmon në zgjidhje, ju vetëm do të forconi pozitat e njërit prej palëve në dëm të palës tjetër. Kur merrni një vendim, është e rëndësishme që ai të pranohet moralish nga të gjitha palët, siç thonë, ‘të jetë blerë’. Që, edhe nëse palët nuk ishin të kënaqura me vendimin e marrë, ato të paktën të pranojnë me sinqeritet ta zbatojnë atë. Këtë e quajmë të jesh në gjendje të mos jesh dakord dhe të angazhohesh. Përndryshe, konflikti do të ndryshojë thjesht pamjen, zjarri që skuqet do të mbetet në torf dhe në një moment patjetër do të shpërthejë përsëri.

Mënyra e dytë, e cila është disi e lidhur me të parën - nëse po merrni pjesë në zgjidhjen e një konflikti, merreni këtë shumë seriozisht në aspektin e komunikimit dhe studimit të kontekstit. Flisni personalisht me secilën palë. Fillimisht ndarazi me secilën. Mos u mjaftoni me postën. Në rastin e një ekipi të shpërndarë - flisni të paktën përmes videokonferencave. Mos u mjaftoni me thashetheme dhe përsëritje nga dëshmitarët. Kuptoni historinë, çfarë dëshiron secila palë, pse e dëshiron këtë, çfarë pret, a kanë provuar të zgjidhin këtë çështje më parë, çfarë do të ndodhë nëse ajo nuk zgjidhet, cilat janë opsionet e zgjidhjes që shohin, si e perceptojnë pozicionin e palës tjetër, çfarë mendojnë se është e drejtë ose e gabuar, etj. Ngarkohet në mendjen tuaj gjithë konteksti i mundshëm, pa paragjykime, duke supozuar se të gjithë kanë të drejtë. Ju nuk jeni brenda konfliktit, Ju jeni jashtë tij, në një pozicion meta. Nëse konteksti është i disponueshëm vetëm në një bisedë me email - të paktën lexoni atë në tërësi dhe bisedat përkatëse dhe dokumentet. Pas leximit - gjithsesi flisni me zë. Praktikisht do të dëgjoni diçka të rëndësishme që nuk është në email.

Momenti i tretë i rëndësishëm - qasja e përgjithshme ndaj komunikimit. Këto janë gjëra të zakonshme, asgjë kozmike, por ato kanë një rëndësi shumë të madhe. Nuk përpiqemi të kursejmë kohën, flasim me të gjithë pjesëmarrësit, kritikojmë jo personin, por shqyrtojmë pasojat e veprimeve të tij (jo “ti je i ashpër”, por “ndoshta, djemtë mund të ofendohen nga kjo gjë”), u japim mundësinë të ruajnë fytyrën, diskutojmë personalisht, dhe jo përpara një grupi.

Konfliktet zakonisht shkaktohen nga njëra nga dy arsye. E para lidhet me faktin nëse njeriu në momentin e konfliktit është në pozitat e një të rrituri ose në pozitat e një fëmije (për këtë më poshtë). Kjo është e lidhur me pjekurinë e tij emocionale, aftësinë për të menaxhuar emocionet e tij (çka, për të vërtetën, nuk është gjithmonë e lidhur me moshën e tij). Arsyeja tjetër e zakonshme - mangësia e procesit të punës, e cila krijon situata

Prandaj, në zgjidhjen e konfliktit (si edhe për çdo çështje tjetër), menaxheri duhet të ketë parasysh tre perspectiva: afatshkurtër - të zgjidhë çështjen/kontestin këtu dhe tani, afatmesëm - të minimizojë mundësinë e rikthimit të një konflikti për të njëjtin shkak, dhe afatgjatë - të zhvillojë një kulturë të rrituri brenda ekipit.

Në secilin nga ne ka një fëmijë të brendshëm, rreth tre-katër vjeç. Pjesën më të madhe të kohës në punë ai fle, por ndonjëherë zgjohet dhe merr kontrollin. Fëmija ka prioritetet e tij. Ai është i rëndësishëm të insistojë se ky është sandbox-i i tij, mamaja e do atë më shumë, makina e tij është më e mira (dizajni është më i miri, ai kodon më mirë se askush,…). Në një situatë konflikti, fëmija mund të shtyjë lodrat, të godasë këmbët dhe të godasë me lopatë, por ai nuk mund të zgjidhë çështje të rritura (arkitektura e zgjidhjes, qasjet në testimin automatike, afatet e lëshimit, etj.), ai nuk mendon në terma të përfitimit për ekipin. Fëmijën në konflikt mund ta inkurtoni, ta qetësoni dhe ta dërgoni të flejë, duke i kërkuar të thërrasë të rriturin e tij. Para se të filloni diskutimin në kushte konflikti, sigurohuni që tani po flisni me të rriturin, jo me fëmijën, dhe vetë jeni në pozita të rritura. Nëse qëllimi juaj i sinqertë në këtë moment është të zgjidhni një çështje serioze, jeni në pozita të rritura. Nëse qëllimi juaj është të godisni këmbët dhe të godisni me lopatë - kjo është një pozitë fëmijësh. Dërgoni fëmijën tuaj të brendshëm të flejë dhe thërrisni të rriturin, ose shtyni diskutimin. Njeriu merr një vendim emocional dhe më pas kërkon një justifikim racional për të. Vendimi i marrë nga fëmija duke u bazuar në prioritetet e fëmijërisë, nuk do të jetë optimal.

Përveç sjelljes në momentin e konfliktit, pozita e një personi, qoftë fëmijë apo i rritur, karakterizohet gjithashtu nga niveli i përgjegjësisë që është i gatshëm të marrë përsipër. Në manifestimet ekstreme, pozita fëmijë e një programuesi, e cila e kam hasur disa herë, duket kështu: kam shkruar kodin, ia kam dërguar për rishikim — puna ime ka mbaruar. Rishikuesit duhet ta shqyrtojnë dhe ta kombinojnë, QA duhet ta testojë, nëse do të ketë probleme — ata më njoftojnë. Siç është e çuditshme, edhe njerëz të rritur dhe me përvojë ndonjëherë silen në këtë mënyrë. Extremi tjetër i shkallës është se një person e sheh veten përgjegjës për të siguruar që kodi i tij të punojë, të jetë i mbuluar me teste, të jetë kontrolluar personalisht nga ai, të kalojë me sukses rishikimin (nëse nevojitet, nuk ka problem të kontaktoni rishikuesit, të diskutoni problemet me zë, etj.) dhe të kombinohet, QA do të ndihmojë sipas nevojës, skenarët e testimit do të përshkruhen, etj. Në raste normale, programuesi ose ndodhet afër skajit të rritur të shkallës, ose zhvendoset në atë anë ndërsa grumbullon përvojë (me kusht që ekipi të kultivojë kulturën e duhur). Në raste ekstreme, ai vazhdon të punojë, zakonisht duke mbajtur pozita fëmijë, atëherë ndodhin probleme dhe konflikte midis tij dhe ekipit.

Krijimi i një kulture të duhur dhe të rritur në ekip është një detyrë e rëndësishme për çdo menaxher. Kjo kërkon kohë të gjatë dhe përpjekje të përditshme, por rezultati ia vlen. Ka dy mënyra për të ndikuar në kulturën e ekipit — shembulli personal (i cili do të ndiqet patjetër, ekipi gjithmonë shikon liderin) dhe diskutimi dhe inkurajimi i sjelljes së duhur. Këtu nuk ka asgjë të ndërlikuar ose shumë formale, thjesht në diskutimin e problemeve vëreni se këtu mund të bëhej ndryshe, theksoni se e keni parë kur u zgjidh si duhej, lavdëroni, shënoni gjatë analizës së lëshimit, etj.

Le të shqyrtojmë disa situata tipike konfliktuale, nga më e thjeshta te më e ndërlikuara:

Konfliktet që nuk kanë të bëjnë me çështje pune

Mjaft shpesh në punë ndodhin konflikte që nuk lidhen me çështje pune. Shfaqja e tyre dhe lehtësia e zgjidhjes zakonisht lidhen drejtpërdrejt me nivelin e inteligjencës emocionale të pjesëmarrësve, nivelin e pjekurisë së tyre, dhe nuk lidhen me përsosmëri ose papërsosmëri të procesit të punës.

Shembuj tipikë — dikush nuk e përdor mjaft shpesh lavatriçen apo dushin, çka nuk i pëlqen atyre përreth, dikush ndihet nxehtë, ndësa një tjetër ka të ftohtë kur hap dritaren, dikush është shumë i zhurmshëm, ndërsa të tjerëve u nevojitet qetësi për të punuar, etj. Zgjidhja e konflikteve të tilla nuk duhet të shtyhet dhe lënë në dorë të fatit. Ato nuk do të zhduken vetë dhe do t'i shpërqendrojnë çdo ditë nga puna dhe do të helmojnë atmosferën në ekip. Fatmirësisht, zgjidhja e tyre zakonisht nuk përbën një problem të madh — mjafton të flasësh qetësisht (natyrisht, ballë për ballë) me kolegun që neglizhon higjenën, të sigurosh një renditje komode për ata që preferojnë qetësi/ freski, të blesh kufje akustike ose të vendosësh ndarje, etj.

Një shembull tjetër, që unë e kam hasur disa herë gjatë punës sime, është papajtueshmëria psikologjike e anëtarëve të ekipit. Për ndonjë arsye, njerëzit thjesht nuk mund të punojnë së bashku, çdo komunikim përfundon me zhurmë. Ndonjëherë kjo është e lidhur me faktin se njerëzit mbrojnë pikëpamje polare për ndonjë çështje të rëndësishme (zakonisht politike) dhe nuk dinë t'i lënë ato jashtë punës. Të bindësh ata të tolerojnë njëri-tjetrin ose të ndryshojnë sjelljen e tyre është një aktivitet mjaft i pafat. Përjashtimi i vetëm që kam hasur është kolegët e rinj me një perceptim të hapur, sjellja e të cilëve ende mund të ndryshohet gradualisht përmes bisedave periodike. Zakonisht, problemi zgjidhet me ndarjen e tyre në grupe të ndryshme, ose të paktën duke siguruar mundësinë e të paktën të takohen shumë rrallë për punë.

Në të gjitha situatat e përmendura, me të gjithë pjesëmarrësit duhet të flitet personalisht, të diskutohet situata, të interesohesh se a e shohin ata ndonjëherë problemin në këtë rast, të pyesësh se cilat, sipas mendimit të tyre, janë rrugët e zgjidhjes, të sigurosh pjesëmarrjen e tyre në marrjen e këtij vendimi.

Nga pikëpamja e optimizimit të procesit të punës (perspektiva afatmesme, për të cilën përmenda), nuk ka shumë për të bërë këtu, momenti i vetëm për optimizim është të merret parasysh faktori i përshtatshmërisë gjatë formimit të ekipit dhe të mos vendosen së bashku njerëz që do të kështë konflikte.

Në aspektin e kulturës së ekipit, situata të tilla ndodhin shumë më rrallë në ekipet me një kulturë të rritur, ku njerëzit respektojnë ekipin dhe kolegët dhe dinë të zgjidhin проблемet vetë. Për më tepër, këto konflikte zgjidhen shumë më lehtë (shpesh automatikisht) në ekipet ku niveli i besimit është i lartë, njerëzit kanë punuar së bashku për një kohë të gjatë dhe / ose komunikojnë shpesh jashtë orarit të punës.

Konfliktet e lidhura me çështje të punës:

Këto konflikte zakonisht shkaktohen nga të dyja shkaqet në të njëjtën kohë, si nga ana emocionale (për shkak se ndonjë pjesëmarrës nuk është në pozitat e rritura), ashtu edhe nga përsosmia e procesit të punës. Lloji më i zakonshëm i konflikteve që kam hasur është konflikti gjatë rishikimit të kodit ose diskutimeve mbi arkitekturën midis zhvilluesve.

Do të veçoja këtu dy raste tipike:

1) Në rastin e parë, zhvilluesi nuk arrin të marrë rishikimin e kodit nga një koleg. Patch-i është dërguar për rishikim, dhe nuk ndodh asgjë. Në pamje të parë, nuk ka një konflikt të qartë midis dy palëve, por nëse e mendoni, është një konflikt i tillë. Çështja e punës nuk zgjidhet, dhe njëra palë (e cila pret rishikimin) ndjen një diskomfort të dukshëm. Një nënlloj ekstrem i këtij rasti është zhvillimi në komunitet ose në ekipe të ndryshme, ku rishikuesi mund të mos jetë i interesuar për këtë kod të veçantë, ose për shkak të ngarkesës apo rrethanave të tjera, nuk mund të përqendrohet fare në kërkesën për rishikim, dhe mund të mos ketë një arbitër të jashtëm (të përbashkët për të dyja palët menaxher) në lidhje me këtë.

Qasja ndaj zgjidhjes që ndihmon në një situatë të tillë është pikërisht në perspektivën afatgjatë, kultivimin e maturisë. Së pari, funksionon aktiviteti i arsyeshëm. Mos pritet që kodi që është në rishikim të tërheqë vetë vëmendjen e rishikuesit. Duhet t'i ndihmojmë rishikuesit ta vërejnë atë. Pingoni disa njerëz, bëni një pyetje në sinkap, merrni pjesë në diskutime. Është e qartë se ngacmimi do të dëmtojë më shumë se do të ndihmojë, prandaj duhet të futni shëndoshin mendim. Së dyti, përgatitja paraprake funksionon mirë. Nëse ekipi kupton se çfarë dhe pse ndodh, përse është i nevojshëm ky kod, dizajni është diskutuar dhe miratuar më parë nga të gjithë, njerëzit më shumë do të vërejnë atë kod dhe do ta pranojnë për punë. Së treti, autoriteti funksionon. Nëse dëshiron që të të rishikohet, bëj shumë rishikime vetë. Bëj rishikime cilësore, me kontrole reale, teste reale, komente të dobishme. Nëse pseudonimi yt është i njohur në ekip nga ana e mirë, ka më shumë mundësi që të tërheqë vëmendjen ndaj kodit tënd.

Nga pikëpamja e procesit të punës, përmirësimet e mundshme këtu janë vendosja e duhur e prioriteteve, e cila është e orientuar për të ndihmuar zhvilluesin të arrijë qëllimet e tij dhe të ekipit (të rishikoni të tjerët, të shkruani letra në komunitet, të shoqëroni kodin me përshkrimin e arkitekturës, dokumentacionin, testet, të merrni pjesë në diskutime me komunitetin, etj.), mos lejoni bllokimin e patçave në radhë për një kohë të gjatë, e kështu me radhë.

2) Rast i dytë i zakonshëm i konflikteve gjatë rishikimit të kodit ose dizajnit janë pikëpamjet e ndryshme mbi çështje teknike, stilin e kodimit, zgjedhjen e mjeteve. Ka rëndësi të madhe niveli i besimit midis pjesëmarrësve, përkatësia në të njëjtin ekip, përvoja e punës së përbashkët. Stagnimi ndodh kur ndonjë nga pjesëmarrësit merr një pozite infantile, nuk përpiqet të dëgjojë atë që dëshiron të përcjellë bashkëbiseduesi. Shpesh, si qasja e propozuar nga pala tjetër ashtu edhe ajo e propozuar fillimisht mund të funksionojnë me sukses dhe nuk ka rëndësi thelbësore se cila duhet të zgjidhet.

Një herë një programues nga ekipi im (ta quajmë Pasha) përgatiti një patch me ndryshime për sistemin e shpërndarjes së pakos, të cilin e kishin zhvilluar dhe e mbante në dorë një koleg nga departamenti fqinj. Një prej tyre (Igori) kishte një mendim të fortë në lidhje me se si duhej të ishin konfiguruar shërbimet Linux gjatë shpërndarjes së pakove. Ky mendim ndryshonte nga qasja e propozuar në patch, dhe nuk arrinin të binin dakord. Si zakonisht, afatet ishin të ngushta, dhe duhej të arriteshim në ndonjë zgjidhje, ishte e nevojshme që dikush prej tyre të merrte një pozicion më të rritur. Pasha pranoi se të dyja qasjet kishin të drejtë të ekzistonin, por ai donte që opsioni i tij të kalonte, pasi nuk kishte ndonjë avantazh teknik të qartë as për njërën, as për tjetrën.

Diskutimi ynë dukej më pak më kështu (paqësisht të thjeshtuar, sigurisht, biseda zgjati gjysmë ore):

— Pasha, në disa ditë do të kemi feature freeze. Është e rëndësishme që të gjithçka ta mbledhim dhe të fillojmë testimin sa më shpejt të jetë e mundur. Si ta kalojmë Igorin?
— Ai dëshiron të konfigurojë shërbimet ndryshe, më ka lënë shumë komente ...
— Dhe çfarë ka atje, ndërrime të mëdha, shumë punë?
— Jo, jo, atje ka punë për disa orë, por në fund s’ka asnjë ndryshim, do të funksionojë edhe ashtu, përse është e nevojshme? Kam bërë një gjë që punon, le ta pranojmë atë.
— Dëgjo, sa kohë e keni diskutuar këtë?
— Po, tashmë jemi rreth një e gjysmë jave duke e kthyer.
— Em ... mund të zgjidhim një çështje për disa orë, e cila ka zgjatur një e gjysmë javë, dhe nuk e bëjmë këtë?
— No, por nuk dua që Igori të mendojë se kam pranuar ...
— Dëgjo, çfarë është më e rëndësishme për ty, të nxjerrësh versionin, së bashku me zgjidhjen tënde brenda, apo ta fitojmë Igorin? Mund ta fitojmë, por ka një mundësi të mirë të dështojmë me versionin.
— Epo ... do të ishte e bukur, sigurisht, t'i japim një mësim Igorikës, por mirë, versioni është më i rëndësishëm, pranoj.
— Të është vërtet aq e rëndësishme se çfarë mendon Igori? Të jem e sinqertë, atij i është krejtësisht e njëjta gjë, ai thjesht dëshiron një qasje të vetme në vende të ndryshme të asaj gjëje për të cilën ai është përgjegjës.
— Epo, mirë, le të bëj ashtu siç kërkon ai në komente, dhe të fillojmë testimin.
— Faleminderit, Pasha! Ishte e sigurt se nga ju dy, ti do ishe më i rritur, megjithëse Igori është më i madh se ti :)

Problemi u zgjidhur, lansimi është bërë në kohë, Pasha nuk ndjeu ndonjë pakënaqësi të veçantë, sepse ai vetë propozoi zgjidhjen dhe e realizoi atë. Igor ishte krejtësisht i kënaqur, pasi mendimi i tij u mor në konsideratë dhe u bë ashtu siç ai propozi.

Një tjetër lloj i një konflikti të tillë është zgjedhja mes zgjidhjeve teknike/librarieve/qasjeve në projekt, veçanërisht në një ekip të shpërndarë. Në një nga projektet që u pozicionua si duke përdorur C/C++, përfundimisht doli se menaxhimi teknik i projektit ishte kategorikisht kundër përdorimit të STL (Standard Template Library). Kjo është një bibliotekë standarde e gjuhës, që e thjeshton zhvillimin, ekipi ynë u ka besuar shumë. Doli që projekti ishte shumë më afër C se sa C++, gjë që nuk e frymëzoi shumë ekipin, pasi menaxhmenti kishte bërë përpjekje dhe kishte angazhuar vërtet programues të shkëlqyer. Në të njëjtën kohë, pjesa amerikane e ekipit, si inxhinierët ashtu edhe menaxherët, kishin punuar në kompani për një kohë të gjatë, ishin mësuar me gjendjen e tanishme, dhe ishin të kënaqur. Pjesa ruse e ekipit u mblodh së bashku shumë kohë më parë, për disa javë (përfshirë edhe mua). Pjesa ruse e ekipit nuk donte të heqë dorë nga qasja e zakonshme në zhvillim.

Diskutimet e pafundme me shkrim filluan mes dy kontinenteve, letërsi me tre-katër ekrana fluturonte këndej-tjetër, në dërgesa grupore dhe personale, nga programuesit — për programuesit dhe menaxherët. Siç ndodh zakonisht, letra të këtij madhësie nuk i lexonte askush, përveç autorëve dhe mbështetësve të zjarrtë. Bisedat dridheshin nga tensioni, duke transmetuar në të gjitha drejtimet shumë ide lidhur me avantazhet teknike të STL, sa mirë është testuar, e sigurt, dhe në përgjithësi, si është jeta me të, dhe sa e tmerrshme pa të.

Kjo zgjati mjaft gjatë, deri sa më në fund kuptova se po diskutonim anët teknike të çështjes, por problemi në të vërtetë nuk ishte teknik. Problemi nuk ishte te virtytet ose disavantazhet e STL-së ose kompleksiteti i punës pa të. Problemi ishte më shumë organizativ. Duhej të kuptonim si funksiononte kompania në të cilën punonim. Asnjë prej nesh nuk kishte përvojë të punës në një kompani të tillë. Ishte se pas zhvillimit të kodit dhe lëshimit të tij në prodhim, mbështetje e bënte një grup krejtësisht tjetër njerëzish nga ekipe të tjera, nga vende të tjera. Kjo ekip inxhinierik i madh prej disa dhjetra mijëra inxhinierësh (në total) mund të lejonte vetëm minimumin e bazuar në mjete teknike, thënë ndryshe, minimum minimorum. Çdo gjë që e tejkalonte standardin inxhinierik të vendosur në kompani, fizikisht nuk mund të mbështetej më tej. Niveli i ekipit përcaktohet nga niveli i anëtarëve më të dobët të tij. Pasi kuptuam motivacionin real e veprimeve të pjesës amerikane të ekipit, ky çështje u hoq nga rendi i ditës, dhe ne të gjithë së bashku zhvilluam dhe lëshuam me sukses produktin, duke përdorur standardet e pranuara në kompani. E-mailet dhe bisedat në këtë rast funksiononin keq, për të ardhur në një konsensus, ne patëm nevojë për disa udhëtime dhe shumë komunikim personal.

Nga pikëpamja e procesit të punës, në këtë rast të veçantë, do të ndihmonte ekzistenca e një përshkrimi të mjeteve të përdorura, kërkesat për to, kufizimet mbi shtimin e të rinjve, justifikimi i këtyre kufizimeve. Dokumente të tilla përputhen përafërsisht me ato që përshkrollen në pikat e Strategjisë së Ri-përdorimit dhe Mjedisit të Zhvillimit të udhëzuesit "Blloku i Menaxherit për Zhvillimin e Softuerit", i zhvilluar në NASA. Megjithëse është i vjetër, ai përshkruan mjaft mirë të gjitha aktivitete dhe fazat kryesore të planifikimit të zhvillimit të softuerit të këtij lloji. Ekzistenca e dokumenteve të tilla e thjeshton shumë procesin e diskutimit të cilat komponente dhe qasje mund të përdoren në produkt, dhe pse.

Nga pikëpamja e kulturës, është e qartë se me një qasje më të pjekur, në të cilën palët përpiqen të dëgjojnë dhe kuptojnë motivimin real të veprimeve të kolegëve dhe veprojnë në përputhje me prioritetet e projektit dhe ekipit, jo ego personale, konflikti do të zgjidhej më lehtë dhe më shpejt.

Në një konflikt tjetër për zgjedhjen e një zgjidhjeje teknike, më nevojitej gjithashtu një kohë e konsiderueshme për të kuptuar motivimin e njërit nga palët (ishte një rast shumë i pazakontë), por, pasi motivimi u bë i qartë, zgjidhja ishte e dukshme.

Situata është e tillë: në një ekip prej rreth 20 personash, shfaqet një zhvillues i ri, ta quajmë Stas. Instrumenti ynë standard për komunikim në ekip deri atëherë ishte Skype. Siç doli më vonë, Stas ishte një adhurues i madh i standardeve të hapura dhe të softuerit me kod burimi të hapur, dhe përdorte vetëm mjete dhe sisteme operative, për të cilat kodet burimore ishin në dispozicion publik, dhe që përdornin protokollet e përshkruara publikisht. Skype nuk bën pjesë në këto mjete. Ne kaluam një kohë të madhe duke diskutuar meritat dhe disavantazhet e këtij qasjeje, përpjekjet për të startuar analoge të Skype në sisteme të ndryshme operative, përpjekjet e Stas për të bindur ekipin të kalonte në standarde të tjera, të shkruante atij personalisht me email, të telefononte personalisht, të blinte një kompjuter të dytë posaçërisht për Skype, etj. Më në fund kuptova se kjo ishte një problem, në thelb, jo teknik dhe as organizativ, por më shumë një çështje bote, madje, mund të thuhet, religjioze (për Stas). Edhe sikur të ishim lidhur Stas dhe Skype (për të cilin tashmë ishin shpenzuar disa muaj), problemi do të shfaqej sërish me çdo mjet tjetër. Unë nuk kisha mjete reale për të ndryshuar botën e Stas, dhe nuk kishte asnjë arsye për të tentuar të ndryshoja botën e ekipit, i cili funksiononte mjaft mirë në këtë mjedis. Njeriu dhe kompania thjesht ishin ortogonale në botën e tyre. Në situata të tilla, një zgjidhje e mirë është organizative. Ne e transferuam Stas në një ekip tjetër, ku ishte më organik.

Sipas mendimit tim, arsyeja e këtij konflikti është përputhshmëria e kulturës personale të një personi të caktuar (i cili ka një mendim të fortë, që i pengon të pranojnë kompromise), me kulturën e kompanisë. Në këtë rast, sigurisht, është një gabim i menaxherit. Ishte gabim që në fillim ta merrnin atë në një projekt të këtij lloji. Stas përfundimisht kaloi në një projekt për zhvillimin e softuerit të hapur dhe atje pati sukses të shkëlqyer.

Një shembull i mirë i një konflikti të shkaktuar nga pozita fëminore e zhvilluesit dhe mangësitë e procesit të punës — një situatë në të cilën në mungesë të definition of done, zhvilluesi dhe ekipi QA kishin pritshmëri të ndryshme në lidhje me gatishmërinë e karakteristikës që iu dorëzua QA. Zhvilluesi mendonte se ishte e mjaftueshme të shkruante kodin dhe ta kalonte atë në QA — atje do të merreshin me të. Një programues mjaft i rritur dhe me përvojë, për të thënë të drejtën, por kjo ishte e gjitha për nivelin e tij të brendshëm të cilësisë. QA nuk ishte dakord me këtë dhe kërkoi që ai t’u tregonte dhe t’u përshkruante se çfarë kishte kontrolluar vetë, si dhe kërkoi një skenar testi për ta. Ata tashmë kishin pasur probleme në të kaluarën me funksionalitetin nga ky zhvillues dhe nuk donin të humbnin kohë përsëri. Në fakt, ata kishin të drejtë — funksionaliteti vërtet nuk punonte, ai nuk e kishte kontrolluar kodin para dorëzimit në QA.

Për të zgjidhur situatën, i kërkova atij që të më tregonte se gjithçka funksiononte vërtet (ai nuk funksiononte, dhe ai duhet të riparonte), ne biseduam me ekipin dhe me QA për definition of done (nuk e bëmë atë me shkrim, sepse nuk donim ta burokratisnim shumë procesin), dhe me këtë specialist ne së shpejti u ndamë (për lehtësimin e përgjithshëm).

Nga pikëpamja e procesit të punës, përmirësimet e mundshme në këtë rast janë: pranimi i definition of done, kërkesat për përkrahjen e çdo karakteristike me teste unike dhe integruese, përshkrimi i testimeve të kryera nga zhvilluesi. Në një nga projektet, ne matëm nivelin e mbulimit të kodit me teste gjatë CI dhe në rast se niveli i mbulimit pas shtimit të një patch-i, ra, testet u shënjuan si të pasuksesshme, dmth. çdo kod i ri mund të shtohej vetëm nëse kishte teste të reja për të.

Një tjetër shembull tipik i një konflikti, ngushtësisht i lidhur me organizimin e punës. Ne kemi një produkt, ekipin zhvillues të këtij produkti, ekipin e mbështetjes dhe klientin. Klienti ka probleme me produktin dhe i drejtohet mbështetjes. Mbështetja analizon problemin dhe kupton se problemi është në produkt, e transferon problemin tek ekipi i produktit. Ekipi i produktit ka një periudhë të ngarkuar, lançimi është në prag, kështu që biletat me problemin e klientit, të humbura ndër biletat e tjera tek zhvilluesi, të cilit i është caktuar, qëndrojnë të paprekura për disa javë. Mbështetja mendon se zhvilluesi po punon për problemin e klientit. Klienti pret dhe shpreson se po punohet mbi problemin e tij. Në realitet, nuk po ndodh asgjë. Pasi kalojnë disa javë, klienti më në fund vendos të pyesë për përparimin dhe pyet mbështetje. Mbështetja pyet zhvillimin. Zhvilluesi trembet, shikon listën e biletave dhe zbulon biletën nga klienti. Duke lexuar biletën nga klienti, kupton se informacioni për zgjidhjen e problemit nuk është i mjaftueshëm, dhe i duhen më shumë loggje dhe dump-e. Mbështetja kërkon informacion shtesë nga klienti. Dhe këtu klienti kupton se askush nuk ka punuar mbi problemin e tij gjatë gjithë kësaj kohe. Dhe do të bie një tërbim...

Në këtë situatë, zgjidhja e konfliktit është mjaft e qartë dhe lineare (të riparosh produktin, të përditësosh dokumentacionin dhe testet, të qetësosh klientin, të publikosh një hotfix, etj). Është e rëndësishme të analizohet procesi i punës dhe të kuptohet kush e ka përgjegjësinë për organizimin e ndërveprimit ndërmjet dy ekipeve, pse e gjithë kjo situatë u bë e mundur. Është e qartë se diçka duhet të rregullohet në proces - dikush duhet të monitorojë pamjen e përgjithshme pa kujtesë nga klientët, proaktivisht. Biletat nga klienti duhet të spikasin ndër biletat e tjera tek zhvilluesit. Mbështetja duhet të shohë nëse zhvillimi po punon aktualisht mbi biletat e saj, nëse jo - kur mund të fillojë të punojë, kur mund të pritet një rezultat. Mbështetja dhe zhvillimi duhet të komunikojnë herë pas here dhe të diskutojnë statusin e biletave, mbledhja e informacionit të nevojshëm për debugging duhet të jetë maksimalisht e automatizuar, etj.

Si në luftë armiku përpiqet të godasë në ndërprerjen mes dy njësive, po ashtu edhe në punë pika më e hollë dhe më e ndjeshme zakonisht është ndërveprimi mes ekipeve. Nëse menaxherët e mbështetjes dhe zhvillimit janë mjaft të pjekur, ata do të jenë në gjendje të rregullojnë procesin vetë; në të kundërt, procesi do të vazhdojë të prodhojë konflikte dhe probleme derisa të ndërhyjë një menaxher që mund ta rregullojë situatën.

Një shembull tjetër tipik, që e kam hasur disa herë në kompani të ndryshme, është situata në të cilën produkti shkruhet nga një ekip, testet automatike të integrimit nga një ekip tjetër, dhe infrastruktura në të cilën gjithçka funksionon mbahet nga një ekip i tretë. Problemet gjatë ekzekutimit të testeve ndodhin vazhdimisht, dhe shkaku i problemeve në to mund të jetë si produkti, ashtu edhe testet dhe infrastruktura. Zakonisht është problematike të dakordosh se kush duhet të kryejë analizën fillestare të problemeve, të regjistrojë gabimet, të analizojë logët e produktit, testeve dhe infrastrukturës, etj. Konfliktet këtu janë mjaft të shpeshta dhe, njëkohësisht, të njëjta. Në raste tensioni të lartë emocional, pjesëmarrësit shpesh bien në pozita fëminore, duke filluar diskutime si: “pse duhet të merrem me këtë?”, “ata prishen më shpesh”, etj.

Nga këndvështrimi i procesit të punës, hapat konkretë për zgjidhjen e problemit varen nga përbërja e ekipeve, lloji i testeve dhe produkti, etj. Në një nga projektet, ne implementuam turne periodike, ku ekipet e monitoronin testet në radhë, për çdo javë. Në një tjetër, analiza fillestare gjithmonë kryhej nga zhvilluesit e testeve, por analiza ishte mjaft bazike dhe produkti ishte mjaft stabil, kështu që kjo funksiononte mirë. E rëndësishme është të sigurohet transparenca e procesit, qartësia e pritshmërive për të gjitha palët dhe ndjenja e drejtësisë në situatë për të gjithë.

A është ndonjëherë konflikti në organizatë një problem, a është shenjë e keqe që në ekipin tuaj ndodhin shpesh (ose thjesht përkohësisht) konflikte? Në përgjithësi, jo, sepse nëse ka rritje, zhvillim, ka një dinamikë, atëherë lindin pyetje që kurrë nuk janë trajtuar më parë, dhe duke i zgjidhur ato, mund të përfshihen konflikte. Kjo është një tregues se disa fusha duhet të vihen në dukje, se ka fusha për përmirësim. Është keq nëse konfliktet ndodhin shumë shpesh, zgjidhen me vështirësi ose për një kohë të gjatë. Kjo, për siguri, është një shenjë e proceseve të punës që nuk janë të miratuara mjaftueshëm dhe e pamjaftueshmërisë së pjekurisë së ekipit.

Burimi: habr.com