Epigrafi:
Njëherë në një pyll u takuan Jezhushi dhe Dhelpra.
— Përshëndetje, Jezhush!
— Përshëndetje, Dhelpra!
Kështu, fjala për fjalën, shaka për shaka, dhe Jezhushi mori një goditje nga Dhelpra …
Poshtë janë mendimet e liderit tonë të ekipit, si dhe të drejtorit për zhvillimin e produktit RAS — Igor Marinat mbi specifikat e konflikteve në punë dhe metodat e mundshme për menaxhimin e tyre.
Shumica e konflikteve me të cilat përballemi në punë zhvillohen sipas një skenari të ngjashëm me atë të përshkruar më sipër në epigraf. Janë disa pjesëmarrës, fillimisht të vendosur miqësisht ndaj njëri-tjetrit, ata përpiqen të zgjidhin një çështje, por në fund problemi mbetet i zgjidhur, dhe marrëdhëniet midis pjesëmarrësve të diskutimit për çfarëdo arsye duken të prishura.
Jeta është e shumëanshme; në skenarin e përmendur më sipër ndodhin variacione. Ndonjëherë marrëdhëniet mes pjesëmarrësve fillimisht nuk janë të mira, ndonjëherë nuk ka as një pyetje që kërkon zgjidhje të menjëhershme (siç është, për shembull, në epigraf), ndonjëherë pas diskutimeve marrëdhëniet mbeten të njëjta si para fillimit të tyre, por çështja përfundimisht nuk zgjidhet.
Çfarë ka të përbashkët në të gjitha situatat që mund të përcaktohen si situata konflikti në punë?
Së pari, këtë e përbëjnë dy ose më shumë palë. Këto palë mund të jenë në pozita të ndryshme brenda organizatës, të jenë në marrëdhënie barazie (kolegë në ekip), ose në nivele të ndryshme hierarkike (shef - nënshtruar), të jenë individuale (punonjës) ose grupore (në raste konflikti mes një punonjësi dhe ekipit ose dy ekipeve), etj. Niveli i besimit midis pjesëmarrësve ka një ndikim të rëndësishëm në probabilitetin e konfliktit dhe lehtësinë e zgjidhjes së tij. Sa më mirë t’i njohin palët njëra-tjetrën, aq më i lartë është niveli i besimit, aq më i lartë është mundësia 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 personalisht, kanë më shumë të ngjarë të bien në një situatë konflikti kur zgjidhin një çështje të thjeshtë pune, sesa njerëzit që kanë komunikuar disa herë personalisht. Prandaj, gjatë punës në ekipe të shpërndara, është thelbësore të sigurohen takime personale periodike midis të gjithëve anëtarëve të ekipit.
Së pari, në një situatë konflikti në punë, palët ndodhen në një situatë që kërkon zgjidhjen e 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ë specifikës së situatës, palët zakonisht kanë mjaft kohë dhe mënyra të ndryshme për ta zgjidhur (formale, informale, takime, shkresa, vendime nga drejtuesit, qëllime dhe plane të ekipit, prania e një hierarkie, etj.). Kjo është ajo që e ndan situatën e zgjidhjes së një çështjeje pune (ose jo-pune) në organizatë nga, për shembull, zgjidhja e një çështjeje të rëndësishme: “Hë, djalë, nga cila lagje je?!” në rrugë, ose konflikti nga epigrafi. Në rastin e zgjidhjes së një çështjeje pune, rëndësi kanë cilësia e procesit të punës dhe kultura e zgjidhjes së çështjeve në ekip.
E treta, fakti përcaktues i konfliktit (në kontekst të diskutimit tonë) është se palët e procesit nuk mund të arrijnë një zgjidhje që i kënaq të gjitha palët. Situata kërkon ndërhyrjen e një palë të tretë, një arbitër të jashtëm. Ky pikë mund të duket i diskutueshëm, por, në thelb, nëse situata e konfliktit zgjidhet me sukses pa ndërhyrjen e një arbitri të jashtëm, problemi është zgjidhur me sukses dhe marrëdhëniet mes palëve nuk janë përkeqësuar, kjo është ajo situatë që duhet të synohet. Me siguri, për një konflikt të tillë, ndoshta nuk do të dijmë asgjë, ose do ta mësojmë aksidentalisht pas zgjidhjes së tij. Sa më shumë probleme që ekipi mund të zgjidhë vetë, aq më efektiv do të funksionojë.
Një tjetër tipar karakteristik i konfliktit që vlen të përmendet është intensiteti emocional gjatë zgjidhjes. Konflikti nuk është domosdoshmërisht i lidhur me një gradë të lartë emocionale. Pjesëmarrësit nuk kanë nevojë të bërtasin ose të përshkruajnë me duar për të qenë një situatë konflikti. Nëse çështja nuk zgjidhet dhe ndjenja emocionale është prezente (ndoshta nuk shprehet ose qartë në mënyrë të dukshme), kjo do të thotë që kemi një situatë konfliktesh.
A duhet të ndërhyjmë në situatat konfliktuale, apo është më mirë t'i lëmë ato të zgjidhen vetvetiu dhe të presim kur problemi do të zgjidhet? Po. Nuk është gjithmonë në fuqinë tuaj ose kompetencën tuaj të zgjidhni plotësisht një konflikt, por në çdo situatë, në një konflikt nga çdo shkallë, mund të merrni një qëndrim të pjekur, duke e nxjerrë kështu edhe disa njerëz përreth jush në të njëjtin nivel, duke zbutur pasojat negative të konfliktit dhe duke ndihmuar në zgjidhjen e tij.
Para se të shqyrtojmë disa shembuj të situatave konfliktuale, le të ndalemi në disa momente të rëndësishme, të zakonshme për të gjithë konfliktet.
Kur zgjidhni një konflikt, është e rëndësishme të jeni mbi përleshjen dhe jo brenda saj (kjo quhet ndonjëherë "të zënit një metapozicion"), domethënë, të mos përfshiheni në procesin e zgjidhjes si njëra nga palët. Ndryshe, si një arbitër i jashtëm që ndihmon në zgjidhje, do të forconi vetëm pozitat e njërit prej palëve në dëm të tjetrës. Kur merrni një vendim, është thelbësore që ky vendim të pranohet moralisht nga të gjitha palët, siç thonë, "të jetë blerë". Që, edhe nëse palët nuk ishin të entuziazmuara për vendimin e marrë, ato megjithatë të jenë sinqerisht të gatshme ta zbatojnë. Siç quhet, të jemi në gjendje të mosbiem dakord dhe të angazhohemi. Përndryshe, konflikti do të ndryshojë vetëm formën; zjarri që digjet dhe mbetet nën turfe do të shpërthejë përsëri në një moment të caktuar.
Momenti i dytë, i lidhur pjesërisht me të parin — nëse po merrni pjesë në zgjidhjen e konfliktit, merreni me shumë seriozitet në aspektin e komunikimeve dhe studimin e kontekstit. Flisni personalisht me secilën palë. Ndryshe me secilën, për fillim. Mos u kënaqni vetëm me postën. Në rastin e një ekipi të shpërnduar — flisni të paktën përmes videokonferencës. Mos u kënaqni me thashetheme dhe përsëritje të dëshmitarëve. Kuptoni historinë, çfarë dëshiron secila palë, pse dëshiron këtë, çfarë pret, a kanë provuar të zgjidhin këtë çështje më parë, çfarë do ndodhë nëse nuk zgjidhet, cilat janë opsionet e zgjidhjes që ata e shohin, si e përfytyrojnë pozitat e njëra-tjetrës, çfarë, sipas tyre, është e drejtë ose jo, etj. Ngarkoni në kokën tuaj gjithë kontekstin e mundshëm, pa paragjykime, duke supozuar se të gjithë kanë të drejtë. Ju nuk jeni brenda konfliktit, jeni jashtë tij, në një pozicion metak. Nëse konteksti është i disponueshëm vetëm në thread-in e postës — të paktën lexoni tërë atë dhe diskutimet e lidhura me të. Pasi të keni lexuar — gjithsesi flisni me zë. Praktikisht garantuar do të dëgjoni diçka të rëndësishme që nuk është në postë.
Një pikë e rëndësishme është qasja e përgjithshme ndaj komunikimit. Këto janë gjëra të zakonshme, asgjë kozmike, por ato kanë një rëndësi të madhe. S’duhet të përpiqemi të kursejmë kohë, të flasim me të gjithë pjesëmarrësit, të kritikojmë jo personin, por të shqyrtojmë pasojat e veprimeve të tij (jo "ti je i ashpër", por "ndoshta njerëzit mund të ofendohen nga kjo gjë"), të japim mundësi për të ruajtur fytyrën, bisedat t’i zhvillojmë personalisht dhe jo përpara një grupi.
Konfliktet zakonisht shkaktohen nga njëra nga dy arsye. E para lidhet me atë nëse ndihmojmë personin gjatë konfliktit të jetë në pozita të rritura apo fëmijë (për këtë më poshtë). Kjo lidhet me pjekurinë emocionale, aftësinë për të menaxhuar emocionet e tij (gjë që, për t’i treguar, nuk lidhet gjithmonë me moshën e tij). Arsyet e zakonshme të tjera janë pamjaftueshmëria e procesit të punës, që krijon situata të zonave gri, ku përgjegjësia është e shpërndarë midis pjesëmarrësve, pritjet e palëve nuk janë të qarta për njëri-tjetrin, dhe rolet në proces janë të paqarta.
Prandaj, në zgjidhjen e konfliktit (ashtu si dhe ndonjë çështje tjetër) menaxheri duhet të ketë parasysh tri perspektiva: perspektivën afatshkurtër — të zgjidhë çështjen/kontestin këtu dhe tani, perspektivën afatmesme — të minimalizojë mundësinë e shfaqjes së një konflikti tjetër për të njëjtën arsye, dhe perspektivën afatgjatë — të edukojë në ekip kulturën e një personi të rritur.
Çdo njëri prej nesh ka një fëmijë të brendshëm, rreth tre deri në katër vjeç. Shumicën e kohës ai fle në punë, por ndonjëherë zgjohet dhe merr kontrollin. Fëmija ka përparësitë e tij. Është e rëndësishme për të të insistojë se kjo është kutia e tij e rërës, nëna e do atë më shumë, makina e tij është më e mira (dizajni është më i mirë, ai programon më mirë se kushdo, ...). Në situatat e konfliktit, fëmija mund të shtrëngojë lodrat, të godasë me këmbë dhe të godasë me lopatë, por ai nuk mund të zgjidhë çështje të rritura (arkitektura e zgjidhjes, qasjet për testim automatik, afatet e lansimit, etj), ai nuk mendon në terma të dobisë për ekipin. Fëmijën në konflikt mund ta inkurajoni, ta ngushëlloni dhe ta dërgoni të flejë, duke i kërkuar atij të thërrasë të rriturin e tij. Para se të filloni diskutimin në kushte konflikti, sigurohuni se po flisni me të rriturin, jo me fëmijën, dhe gjithashtu qëndroni në pozitat e të rriturit. Nëse qëllimi juaj i sinqertë në këtë moment është të zgjidhni një çështje serioze, ju jeni në pozitën e një njeriu të rritur. Nëse qëllimi juaj është të godasë me këmbë dhe të godasë 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 për më vonë. Njeriu merr një vendim emocional dhe më pas kërkon një arsyetim racional për të. Vendimi i marrë nga fëmija, duke u bazuar në përparësitë fëminore, nuk do të jetë optimal.
Përveç sjelljes në momentin e konfliktit, pozita e fëmijëve ose e të rriturve karakterizohet gjithashtu nga niveli i përgjegjësisë që një person është i gatshëm të marrë mbi vete. Në manifestimet ekstreme, pozita fëminore e një programuesi, të cilën e kam takuar shpesh, duket kështu: kam shkruar kodin, e kam dërguar për rishikim — puna ime ka mbaruar. Rishikuesit duhet ta shohin dhe ta bashkojnë, QA duhet ta verifikojë, nëse do të ketë probleme — ata do më njoftojnë. Siç është e çuditshme, edhe njerëz mjaft të rritur dhe me përvojë ndonjëherë sillen në këtë mënyrë. Ana tjetër e skalës — një person e konsideron veten përgjegjës për të siguruar që kodi i tij të funksiononte, të mbulohej me teste, të kontrollohej personalisht nga ai, të kalonte rishikimin me sukses (nëse është e nevojshme, s’ka problem të kontaktojë rishikuesit, të diskutojë çështjet me zë, etj.) dhe të ishte bashkuar, QA do t'i ofrohet ndihmë nëse nevojitet, skenarët e testimit do të përshkruhen, etj. Në raste normale, programuesi ose fillimisht ndodhet më afër anës së të rriturve të skalës, ose zhvendoset atje me akumulimin e përvojës (me kusht që në ekip të kultivohet kultura e duhur). Në rastet ekstreme, ai vazhdon të punojë, zakonisht duke mbajtur pozita fëminore, dhe atëherë ai dhe ekipi i tij hasin herë pas here probleme dhe konflikte.
Edukimi në një ekip të një kulture të duhur dhe të rritur është një detyrë e rëndësishme për çdo menaxher. Kjo kërkon një 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 (që do të ndiqet patjetër, sepse ekipi gjithmonë shikon te lideri) dhe diskutimi dhe inkurajimi i sjelljeve të duhura. Ashtu siç nuk ka asgjë të komplikuar ose shumë formale, thjesht gjatë diskutimeve mbi problemet nënvizoni se si mund të kishte qenë bërë ndryshe, theksoni kur është arritur një zgjidhje e duhur, lavdëroni dhe bëni vërejtje në analizat e lirimeve, etj.
Të shqyrtojmë disa situata tipike konfliktuale, nga e thjeshta në të komplikuar:
Konfliktet që nuk lidhen me çështjet e punës
Mjaft shpesh ndodhin konflikte në punë që nuk lidhen me çështjet e punës. Shfaqja dhe lehtësia e zgjidhjes së tyre zakonisht janë drejtpërdrejt të lidhura me nivelin e inteligjencës emocionale të pjesëmarrësve, nivelin e tyre të pjekurisë, dhe nuk lidhen me përsosni ose mangësi të procesit të punës.
Shembuj tipikë — ndoshta dikush nuk e përdor mjaft shpesh makinën e lavanderisë ose dushin, gjë që nuk i pëlqen të tjerëve, njëri ndihet ngushtë, ndërsa tjetri ka ajër të ftohtë nëse hap dritaren, dikush është shumë i zhurmshëm, ndërsa të tjerët kanë nevojë për qetësi për të punuar, dhe kështu me radhë. Nuk është mirë të shtyhet zgjidhja e konflikteve të tilla dhe të lihen të shkojnë për së gjalli. Ato nuk do të zhduken vetvetiu dhe do të tërheqin vëmendjen nga puna çdo ditë, duke e helmuar atmosferën në ekip. Fatmirësisht, zgjidhja e tyre zakonisht nuk është shumë e vështirë — mjafton të bisedosh qetësisht (sigurisht, një nga një) me kolegun që injoron higjienën, të sigurosh një vendosje komode për ata që preferojnë qetësinë/ftohësi, të blesh kufje absorbues zhurmash ose të vendosësh ndarëse, etj.
Një tjetër shembull që më është ndodhur disa herë gjatë punës është papajtueshmëria psikologjike e anëtarëve të ekipit. Për disa arsye, njerëzit thjesht nuk mund të punojnë së bashku; çdo komunikim përfundon në një lëmsh. Ndonjëherë, kjo lidhet me faktin se ata mbajnë qëndrime polarizuese për ndonjë çështje të rëndësishme (zakonisht politike) dhe nuk janë në gjendje ta lënë atë jashtë punës. Të bindësh ata të durojnë njëri-tjetrin ose të ndryshojnë sjelljen e tyre është një detyrë mjaft të pafrytshme. Përjashtimi i vetëm që kam hasur është kolegët e rinj me një perceptim të hapur; sjellja e tyre ende mund të ndryshohet gradualisht përmes bisedave periodike. Zakonisht, problemi zgjidhet duke i ndarë në ekipe të ndryshme, ose, së paku, duke siguruar mundësinë për të takuar shumë rrallë në punë.
Në të gjitha situatat e përmendura, është e rëndësishme të flasësh personalisht me të gjithë pjesëmarrësit, të diskutosh situatën, të pyesësh nëse ata në të vërtetë e shohin një problem në këtë rast, të pyesësh se cilat janë, sipas mendimit të tyre, mundësitë për zgjidhje dhe të sigurosh pjesëmarrjen e tyre në procesin e marrjes së vendimit.
Në aspektin e optimizimit të procesit të punës (perspektiva afatmesme për të cilën përmenda), nuk ka shumë mundësi për të vepruar këtu, momenti i vetëm për optimizim është të merret parasysh faktori i përputhshmërisë gjatë formimit të ekipit dhe të mos vendosen së bashku njerëz që do të përplasen.
Në aspektin e kulturës së ekipit, situatat e tilla ndodhin shumë më rrallë në ekipe me një kulturë të pjekur, ku njerëzit respektojnë ekipin dhe kolegët dhe dinë të zgjidhin problemet vetë. Për më tepër, konfliktet e tilla zgjidhen shumë më lehtë (shpesh automatikisht) në ekipe 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 çështjet e punës:
Këto konflikte zakonisht shkaktohen nga të dyja arsyet në të njëjtën kohë, si nga emocionet (fakti që ndonjë nga pjesëmarrësit nuk është në pozita të përgjegjshme), ashtu dhe nga imperfeksioni i procesit të punës. Një nga llojet më të zakonshme të konflikteve që kam hasur janë konfliktet gjatë rishikimit të kodit ose diskutimit të arkitekturës mes zhvilluesve.
Do të shënoja dy raste tipike këtu:
1) Në rastin e parë, zhvilluesi nuk arrin të marrë rishikimin e kodit nga një koleg. Patch-i është dërguar për rishikim, por nuk ndodh asgjë. Me sa duket, nuk ka një konflikt të qartë midis dy palëve, por nëse mendojmë mirë, ky është një konflikt tërësisht i mundshëm. Problemi në punë nuk zgjidhet, njëra palë (e cila pret rishikimin) përjeton një shqetësim të dukshëm. Një nënlloj ekstrem i këtij rasti është zhvillimi në komunitet ose në ekipe të ndryshme, ku rishikuesi ndoshta nuk është i interesuar për këtë kod të veçantë, për shkak të ngarkesës ose rrethanave të tjera mund ta injorojë krejtësisht kërkesën për rishikim, dhe një arbitër të jashtëm (menaxher i përbashkët për të dy palët) mund të mos ekzistojë fare.
Qasja ndaj zgjidhjes, e cila ndihmon në një situatë të tillë, i përket pikërisht perspektivës afatgjatë, kulturës së një individi të rritur. Së pari, funksionon aktivizmi i arsyeshëm. Mos prit që kodi që është në rishikim ta tërheqë vetë vëmendjen e rishikuesit. Duhet ta ndihmosh rishikuesin ta vëren atë. Ping disa njerëz, bëj një pyetje në sinkap, merr pjesë në diskutime. Është e qartë se ngacmimi më shumë dëmton sesa ndihmon, prandaj duhet të përdorësh shëndetin e mendor. Së dyti, përgatitja e parakohshme funksionon mirë. Nëse ekipi kupton se çfarë dhe pse po ndodh, pse është e nevojshme ky kod, dizajni është diskutuar dhe miratuar paraprakisht nga të gjithë, atëherë njerëzit do të kenë më shumë shanse ta vërejnë këtë kod dhe ta pranojnë atë për punë. Së treti, autoriteti funksionon. Nëse do që të rishikohet kodi yt, bëj shumë rishikime vetë. Kryej rishikime cilësore, me kontrolle reale, teste të vërteta, komente të dobishme. Nëse nofka jote njihet në ekip nga një këndvështrim pozitiv, do të ketë më shumë mundësi që kodi yt të tërheqë vëmendjen.
Nga pikëpamja e procesit të punës, përmirësimet e mundshme këtu janë vendosja e duhur e prioriteteve, e cila ndihmon zhvilluesin të arrijë objektivat e tij dhe të ekipit (siç është shkruajtja e rishikimeve të tjerëve, dërgimi i email-eve në komunitet, mbështetje e kodit me përshkrim arkitekture, dokumentacion, teste, pjesëmarrje në diskutime në komunitet, etj.), si dhe të mos lejojë që patches të ngecin për një kohë të gjatë në radhë, dhe kështu me radhë.
2) Rasti i dytë i zakonshëm i konflikteve gjatë rishikimit të kodit ose dizajnit janë pikëpamje të ndryshme mbi çështje teknike, stilin e kodimit, zgjedhjen e mjeteve. Ka një rëndësi të madhe niveli i besimit midis pjesëmarrësve, përkatësia në të njëjtin ekip, dhe përvoja e punës së përbashkët. Një bllokim ndodh kur ndonjë pjesëmarrës merr një pozicion të infantilizuar, duke mos u përpjekur të dëgjojë atë që dëshiron të thotë biseduesi. Shpesh, si qasja e propozuar nga pala tjetër, ashtu edhe qasja e propozuar fillimisht, mund të funksionojnë me sukses dhe nuk ka rëndësi themelore se cila do të zgjidhet.
Një herë, një programues nga ekipi im (le t'i japim emrin Pasha) përgatiti një patch me ndryshime në sistemin e shpërndarjes së paketave, që ishte zhvilluar dhe mbajtur nga kolegët e departamentit fqinj. Një prej tyre (Igori) kishte një mendim të fortë në lidhje me atë si duhej të konfiguroheshin shërbimet e Linux-it gjatë shpërndarjes së paketave. Ky mendim ndryshonte nga qasja e propozuar në patch dhe ata nuk mundën të arrinin ndonjë marrëveshje. Si zakonisht, afatet ishin të ngushta dhe duhej të arrihej një zgjidhje; dikush nga ta duhej të merrte një qëndrim të pjekur. Pasha pranoi se të dyja qasjet kishin të drejtë të ekzistonin, por dëshira e tij ishte që varianti i tij të kalonte, pasi nuk kishte asnjë përparësi teknike të qartë as nga njëra as nga tjetra.
Diskutimi ynë dukej pak a shumë kështu (sigurisht, për shumë shkurtesa, biseda zgjati gjysmë ore):
— Pasha, pas disa ditësh kemi feature freeze. Është e rëndësishme që të mbledhim gjithçka dhe të fillojmë testimin sa më shpejt. Si mund ta kalojmë këtë me Igorin?
— Ai dëshiron ta konfigurojë shërbimin ndryshe, ka ngjitur shumë komente për mua ...
— Dhe çfarë atij, janë ndryshime të mëdha, shumë punë?
— Jo, nuk ka punë për më shumë se disa orë, por në fund nuk ka ndryshim, do të punojë njësoj, çfarë është nevoja për këtë? Kam bërë një gjë që funksionon, le ta pranojmë atë.
— Dëgjomë, sa kohë po e diskutoni këtë?
— Po, tashmë kemi rinovuar për rreth njëzet ditë.
— Em ... a mund të zgjidhim një çështje që ka marrë njëzet ditë për disa orë dhe nuk po e bëjmë këtë?
— Po, por nuk më pëlqen të mendoj se Igor mendon që unë kam kapitulloj ...
— Dëgjomë, çfarë është më e rëndësishme për ty, të lëshosh versionin me zgjidhjen tënde brenda, apo të mposhtësh Igorin? Mund ta mposhtim, por ka një mundësi të mirë të humbim me versionin.
— No ... do ishte e bukur, natyrisht, të turpëroj Igor, por mirë, versioni është më i rëndësishëm, pajtohem.
— A është vërtet kaq e rëndësishme për ty se çfarë mendon Igor? Ç honestly është më shumë ose më pak i indiferent, ai thjesht dëshiron një qasje të njëjtë në vende të ndryshme të gjërave për të cilat është përgjegjës.
— Mirë, le të bëj siç kërkon ai në komentet dhe të fillojmë testimin.
— Faleminderit, Pasha! Ishte e sigurt që nga ju dy do ishe më i pjekur, megjithëse Igor është më i madh se ti :)
Problemi u zgjidhur, lançi doli në kohë, Pasha nuk shfaqi pakënaqësi të madhe, pasi ai vetë propozoi zgjidhjen dhe e realizoi atë. Igor ishte i kënaqur, pasi mendimi i tij u mor parasysh dhe e bënë ashtu siç ai sugjeroi.
Një lloj tjetër i një konflikti të tillë në thelb është zgjedhja mes zgjidhjeve teknike/bibliotekave/afrove në projekt, veçanërisht në një ekip të shpërndarë. Në një nga projektet, që pozicionohej si përdorim i C/C++, në fund rezultoi 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ë thjeshton zhvillimin dhe ekipi ynë ishte shumë i zakonshëm me të. U zbulua se projekti ishte shumë më afër C sesa C++, gjë që nuk e frymëzonte shumë ekipin, pasi menaxhimenti kishte përzgjedhur disa programues të vërtetë të shkëlqyer. Ndërkohë, pjesa amerikane e ekipit, si inxhinierët ashtu edhe menaxherët, kishin punuar në kompani për një kohë të gjatë, u ishin përshtatur shikimeve ekzistuese dhe gjithçka i kënaqte. Pjesa ruse e ekipit u mblodh së bashku vetëm së fundmi, për disa javë (përfshirë edhe mua). Pjesa ruse e ekipit refuzonte kategorikisht të heqë dorë nga qasja e zakonshme në zhvillim.
Diskutimet e pafundme me shkrim filluan mes dy kontinenteve, me letra që fluturonin nga tre deri në katër ekrane në të dyja drejtimet, 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ë tyre të apasionuar. Bisedat ishin të ngarkuara, duke shkëmbyer në të dyja drejtimet mendime shumë-ekrane për avantazhet teknike të STL, sa mirë është testuar, sa e sigurt është, dhe si e bukur është jeta me të, dhe si e tmerrshme pa të.
Kjo ka zgjatur mjaft gjatë, deri sa unë përfundimisht e kuptova se ne ishim duke diskutuar anët teknike të çështjes, ndërsa problemi në realitet nuk ishte teknik. Problemi nuk është në meritat ose disfavorit e STL-së ose në kompleksitetin e punës pa të. Problemi është më shumë organizativ. Na nevojitej thjesht të kuptonim se si funksiononte kompania ku punonim. Askush nga ne nuk kishte përvojë të mëparshme në një kompani të tillë. Çështja ishte se pas zhvillimit të kodit dhe publikimit të tij në production, mbështetjen e siguronin njerëz krejtësisht të tjerë nga ekipe të tjera, nga vende të tjera. Kjo ekipë e madhe inxhinierike, që përbëhet nga disa dhjetëra mijëra inxhinierë (në tërësi), mund t'i lejonte vetes vetëm minimumin e përbashkët teknik, thuajse minimumi minimorum. Çdo gjë që përtej standardit inxhinierik të vendosur në kompaninë, fizikisht nuk mund të mbështetet më tej. Niveli i ekipit përcaktohet nga niveli i anëtarëve më të dobët. Pas që e kuptuam motivimin real veprimeve të ekipit amerikan, ky çështje u hoq nga agjenda, dhe së bashku arritëm të zhvillojmë dhe lëshojmë produktin, duke përdorur standardet e pranuara në kompani. E-mailet dhe bisedat në këtë rast funksionuan keq, dhe ishin të nevojshme disa vizita dhe shumë komunikim personal për të arritur një gjuhë të përbashkët.
Nga pikëpamja e procesit të punës, në këtë rast të veçantë, do të ndihmonte të kishte një përshkrim të mjeteve të përdorura, kërkesat për to, kufizimet në shtimin e të rinjve, dhe arsyetimin e këtyre kufizimeve. Dokumente të tilla përputhen në masë të madhe me ato të përshkruara në kapitujt Reuse Strategy dhe Development Environment të manualit 'Manager’s Handbook for Software Development', të zhvilluar në . Edhe pse është i vjetruar, ai përshkruan mjaft mirë të gjitha aktivitetet kryesore dhe fazat e planifikimit të zhvillimit të softuerit të këtij lloji. Prania e dokumenteve të tilla e thjeshton shumë procesin e diskutimit mbi komponentët dhe qasjet që mund të përdoren në produkt, dhe përse.
Nga pikëpamja kulturore, është e qartë se me një pozicion më të rritur, ku palët përpiqen të dëgjojnë dhe të kuptojnë motivimin e vërtetë të veprimeve të njëri-tjetrit dhe veprojnë në bazë të prioriteteve të projektit dhe ekipit, përkatësisht dhe jo egoizmit personal, konflikti do të zgjidhej më lehtë dhe më shpejt.
Në një konflikt tjetër për zgjedhjen e një zgjidhjeje teknike, gjithashtu më duhej një kohë e dukshme për të kuptuar motivimin e njërit prej palëve (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. Mjeti ynë standard për komunikim në ekip në atë kohë ishte Skype. Siç u zbulua më vonë, Stas ishte një fanatik i madh i standardeve të hapura dhe të softuerit me kod burim të hapur, dhe përdorte vetëm mjete dhe sisteme operative, të cilat burimet e tyre janë të disponueshme publikisht dhe që përdorin protokolle të përshkruara publikisht. Skype nuk i takon këtyre mjeteve. Ne kaluam shumë kohë duke diskutuar meritat dhe disavantazhet e këtij qasje, përpjekjet për të nisur alternativa të Skype në sisteme të ndryshme operative, përpjekjet e Stas për të bindur ekipin të kalonte në standarde të tjera, për t'i shkruar atij personalisht me email, për ta telefonuar atë personalisht, për të blerë një kompjuter të dytë special për Skype, etj. Në fund, e kuptova që kjo ishte një problem, në thelb, jo teknik dhe jo organizativ, përkundrazi ishte më shumë një çështje botëkuptimi, madje, mund të thuhet, një çështje religjioze (për Stas). Edhe nëse do të arrinim përfundimisht të lidhim Stas me Skype (për të cilin tanimë kishim shpenzuar disa muaj), problemi do të shfaqej përsëri me çdo mjet tjetër. Nuk kisha mjete reale për të ndryshuar botëkuptimin e Stas, dhe nuk kishte arsye për të përpjekur të ndryshoja botëkuptimin e ekipit, i cili funksiononte shkëlqyeshëm në këtë ambient. Njeriu dhe kompania ishin thjesht ortogonale në botëkuptim. Në situatat e tilla, një zgjidhje e mirë është organizative. Ne e transferuam Stasin në një ekip tjetër, ku ai ishte më i përshtatshëm.
Arsyeja e këtij konflikti, sipas mendimit tim, ka të bëjë me përputhshmërinë e kulturës personale të një individi (i cili ka një mendim të fortë që nuk lejon kompromisin) me kulturën e kompanisë. Në këtë rast, sigurisht, është një gabim i menaxherit. Fillimisht ishte e gabuar ta merrnin atë në një projekt të këtij lloji. Stasi përfundimisht kaloi në një projekt për zhvillimin e softuerit të hapur dhe atje arriti të ketë sukses të madh.
Një shembull i mirë i një konflikti të shkaktuar nga pozita fëmijërore e zhvilluesit dhe mangësitë e procesit të punës — një situatë në të cilën, në mungesë të një definition of done, zhvilluesi dhe ekipi i QA kishin pritshmëri të ndryshme në lidhje me gatishmërinë e karakteristikës që i ishte dorëzuar QA. Zhvilluesi mendonte se ishte mjaft të shkruante kodin dhe ta kalonte karakteristikën në QA — atje do të merreshin me të. Ai ishte një programues relativisht i rritur dhe me përvojë, megjithatë, ishte kështu një prag i brendshëm cilësie për të. QA nuk ishin dakord me këtë dhe kërkonin t'u tregonin dhe t'u përshkruanin atyre se çfarë kishte kontrolluar vetë, dhe kërkonin një skenar testimi për ta. Ata tashmë kishin pasur probleme në të kaluarën me funksionalitetin nga ky zhvillues dhe nuk donin të humbnin kohën e tyre përsëri. Për pasojë, ata kishin të drejtë — karakteristika vërtet nuk funksiononte, ai nuk kishte kontrolluar kodin para se ta dorëzonte në QA.
Për të zgjidhur situatën, i kërkova atij të më tregojë se gjithçka funksionon vërtet (nuk funksiononte, dhe atij i duhej t'i bënte disa riparime), biseduam me ekipin dhe me QA për definition of done (nuk e bëmë atë me shkrim, pasi nuk doja ta burokratisnim procesin shumë), ndërsa me këtë specialistu ne u ndamë së shpejti (për lehtësimin e të gjithëve).
Nga pikëpamja e procesit të punës, përmirësimet e mundshme në këtë rast janë disa përcaktime të definition of done, kërkesat për mbështetje për secilën veçori me testet unitare dhe integruese, përshkrimi i testimit të bërë nga zhvilluesi. Në një nga projektet, matëm nivelin e mbulimit të kodit me teste gjatë CI dhe në rast se niveli i mbulimit pas shtimit të një patch-i binte, testet shënoheshin si të dështuar, dmth. çdo kod i ri mund të shtohej vetëm nëse kishte teste të reja për të.
Një shembull tjetër tipik i konfliktit, i lidhur ngushtë me organizimin e procesit të punës. Ne kemi një produkt, ekipin e zhvillimit të këtij produkti, ekipin e mbështetjes dhe klientin. Klienti ka probleme me produktin, ai i drejtohet mbështetjes. Mbështetja analizon problemin dhe kupton se problemi është në produkt, ia kalon problemin ekipit të produktit. Ekipi i produktit ka një periudhë të ngarkuar, lançimi po afrohet, kështu që bileta e problemit nga klienti, e humbur mes biletave të tjera te zhvilluesi te i cili është caktuar, mbetet pa vëmendje për disa javë. Mbështetja mendon se zhvilluesi po punon mbi problemin e klientit. Klienti pret dhe shpreson se dikush po punon mbi problemin e tij. Në realitet, asgjë nuk po ndodh derisa, pas disa javësh, klienti më në fund vendos të pyesë për progresin dhe pyet mbështetjen se si po shkon. Mbështetja pyet zhvillimin. Zhvilluesi tronditet, rishikon listën e biletave dhe zbulon se ka një biletë nga klienti. Duke lexuar biletën nga klienti kupton se informatat për zgjidhjen e problemit nuk janë të mjaftueshme, dhe i nevojiten më shumë regjistrime dhe dump-e. Mbështetja kërkon informacion shtesë nga klienti. Dhe tani klienti kupton se mbi problemin e tij askush nuk ka punuar gjithë këtë kohë. Dhe shpërthen stuhia ...
Në këtë situatë, zgjidhja e konfliktit është mjaft e qartë dhe lineare (të riparosh produktin, të azhnosh dokumentacionin dhe testet, të qetësosh klientin, të lëshosh një hotfix, etj.). Është e rëndësishme të analizosh procesin e punës dhe të kuptosh kush mban përgjegjësinë për organizimin e komunikimit midis dy ekipeve, pse një situatë e tillë u bë e mundur në radhë të parë. E qartë është se duhet të punohet në proces — dikush duhet të monitorojë pamjen e përgjithshme pa rikujtime nga klientët, proaktivisht. Ticketet nga klientët duhet të dalin në pah nga të tjerat në radhët e zhvilluesve. Mbështetja duhet të shohë nëse zhvillimi po punon për ticketet e saj në atë moment, nëse jo — kur mund të fillojë të punojë, kur mund të pritet një rezultat. Mbështetja dhe zhvillimi duhet të komunikojnë rregullisht dhe të diskutojnë statusin e ticketëve, grumbullimi i informacionit të nevojshëm për debugim duhet të jetë sa më automatizuar.
As in war, where the opponent tries to strike at the seam between two units, in work, the most delicate and vulnerable spot usually turns out to be the interaction between teams. If support and development managers are mature enough, they can fix the process themselves; if not, the process will continue to generate conflicts and problems until a manager intervenes who can resolve the situation.
Një tjetër shembull karakteristik që kam hasur shpesh në kompani të ndryshme është situata ku një ekip shkruan produktin, testet automatike të integrimit zhvillohen nga një ekip tjetër, dhe infrastruktura që mbështet gjithçka menaxhohet nga një ekip i tretë. Problemet gjatë ekzekutimit të testeve ndodhin vazhdimisht, dhe shkaku i këtyre problemeve mund të jetë si produkti, ashtu edhe testet dhe infrastruktura. Zakonisht është problem të bihet dakord se kush duhet të bëjë analizën fillestare të problemeve, të regjistrojë defekte, të analizojë log-et e produktit, testeve dhe infrastrukturës, etj. Konfliktet këtu janë mjaft të zakonshme dhe, njëkohësisht, uniform. Në raste me emocion të lartë, pjesëmarrësit shpesh kalojnë në një pozitë fëmijërore dhe fillojnë diskutime si: “pse duhet unë të merrem me këtë”, “ata shpesh dështojnë”, etj.
Në aspektin e procesit, hapat konkret për zgjidhjen e problemit varen nga përbërja e ekipeve, lloji i testeve dhe produkti, etj. Në një nga projektet tona, ne vendosëm turne periodike, ku ekipet mbikëqyrnin testet me radhë, nga jave në javë. Në një tjetër, analiza fillestare është bërë gjithmonë nga zhvilluesit e testeve, por kjo analizë ishte mjaft bazike dhe produkti ishte mjaft i qëndrueshëm, kështu që kjo funksionoi 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ë së situatës për të gjithë.
A është ndonjëherë konflikti në organizatë një problem, a është një shenjë e keqe që në ekipin tuaj ndodhin shpesh (apo thjesht herë pas here) konflikte? Në përgjithësi, jo, sepse nëse ka rritje, zhvillim, ka ndonjë dinamikë, atëherë lindin pyetje që nuk janë trajtuar më parë, dhe gjatë zgjidhjes së tyre mund të ndodhin konflikte. Kjo është një tregues që disa fusha duhet të marrin vëmendje, që ka fusha për përmirësim. Është e keqe nëse konfliktet ndodhin shumë shpesh, zgjidhen me vështirësi ose gjatë. Kjo ndoshta është një shenjë e proceseve të punës që nuk janë aq të përshtatshme dhe e pjekurisë së pamjaftueshme të ekipit.
Burimi: habr.com
