Epigrafi:
Njëherë e një kohë, Iriqi dhe Ariu i Vogël u takuan në pyll.
- Përshëndetje, Iriq!
- Përshëndetje, Ariu i Vogël!
Pra, fjalë për fjalë, shaka për shaka, Iriqi u godit në fytyrë nga Ariu i Vogël...
Më poshtë është një diskutim nga drejtuesi i ekipit tonë, si dhe Drejtori i Zhvillimit të Produkteve RAS, Igor Marnat, në lidhje me specifikat e konflikteve të punës dhe metodat e mundshme për menaxhimin e tyre.
Shumica e konflikteve që hasim në punë zhvillohen sipas një skenari të ngjashëm me atë të përshkruar në epigrafin e mësipërm. Ka disa pjesëmarrës që fillimisht janë të prirur mjaft mirë ndaj njëri-tjetrit; ata po përpiqen të zgjidhin një çështje, por në fund problemi mbetet i pazgjidhur dhe për disa arsye marrëdhëniet midis pjesëmarrësve në diskutim rezultojnë të prishura.
Jeta është e larmishme dhe ndryshimet ndodhin në skenarin e përshkruar më sipër. Ndonjëherë marrëdhënia midis pjesëmarrësve nuk është shumë e mirë fillimisht, ndonjëherë nuk ka as një çështje që kërkon një zgjidhje të drejtpërdrejtë (si p.sh. në epigraf), ndonjëherë pas diskutimit marrëdhënia mbetet e njëjtë si përpara fillimit, por çështja nuk zgjidhet përfundimisht.
Çfarë është e zakonshme në të gjitha situatat që mund të përkufizohen si situatë konflikti në punë?
Së pari, ka dy ose më shumë anë. Këto palë mund të zënë vende të ndryshme në organizatë, të jenë në një marrëdhënie barazie (kolegë në ekip), ose në nivele të ndryshme të hierarkisë (shefi - vartës), të jenë individuale (punonjës) ose grupore (në rastet e konfliktit midis një punonjës dhe një ekip ose dy ekipe), e kështu me radhë. Mundësia e konfliktit dhe lehtësia e zgjidhjes së tij ndikohen shumë nga niveli i besimit midis pjesëmarrësve. Sa më mirë që palët ta njohin njëra-tjetrën, sa më i lartë të jetë niveli i besimit, aq më e lartë është mundësia që ato të arrijnë një marrëveshje. Për shembull, anëtarët e një ekipi të shpërndarë që nuk kanë ndërvepruar kurrë ballë për ballë, kanë më shumë gjasa të përjetojnë konflikt për një çështje të thjeshtë pune sesa njerëzit që kanë pasur të paktën disa ndërveprime ballë për ballë. Prandaj, kur punoni në ekipe të shpërndara, është shumë e rëndësishme të siguroheni që të gjithë anëtarët e ekipit të takohen periodikisht personalisht me njëri-tjetrin.
Së dyti, në një situatë konflikti në punë, palët janë në një situatë të zgjidhjes së një çështjeje të 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ë të njëjtën kohë, për shkak të specifikave të situatës, palët zakonisht kanë kohë të mjaftueshme dhe mënyra të ndryshme për ta zgjidhur atë (formale, joformale, takime, letra, vendime menaxheriale, prania e qëllimeve dhe planeve të ekipit, fakti i një hierarkie, etj.). Kjo është e ndryshme nga situata e zgjidhjes së një çështjeje pune (ose jopune) në një organizatë nga, për shembull, zgjidhja e një pyetjeje të rëndësishme: “Eh, fëmijë, nga cila zonë jeni?!” në rrugë, apo 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ë çështjeve në ekip.
Së treti, faktori përcaktues i konfliktit (nga pikëpamja e diskutimit tonë) është fakti që palët në proces nuk mund të arrijnë në mënyrë të pavarur një zgjidhje të çështjes që i përshtatet të gjitha palëve. Situata kërkon ndërhyrjen e një pale të tretë, një arbitri të jashtëm. Kjo pikë mund të duket e diskutueshme, por, në thelb, nëse situata e konfliktit u zgjidh me sukses pa ndërhyrjen e një arbitri të jashtëm, çështja u zgjidh me sukses dhe marrëdhëniet e palëve nuk u përkeqësuan, kjo është situata për të cilën duhet të përpiqemi. . Me shumë mundësi nuk do të dimë as për një konflikt të tillë, ose do ta zbulojmë rastësisht pasi të zgjidhet. Sa më shumë çështje që një ekip mund të zgjidhë vetë, aq më efektiv do të jetë.
Një tipar tjetër karakteristik i konfliktit që ia vlen të preket është shkalla e intensitetit emocional gjatë vendimit. Konflikti nuk është domosdoshmërisht i lidhur me një nivel të lartë emocional. Pjesëmarrësit nuk duhet të bërtasin dhe të tundin krahët që situata të jetë, në thelb, një konflikt. Çështja nuk zgjidhet, ekziston një tension i caktuar emocional (ndoshta nuk shprehet qartë nga jashtë), që do të thotë se jemi përballur me një situatë konflikti.
A është e nevojshme të ndërhyhet fare në situatat e konfliktit, apo është më mirë ta lëmë zgjidhjen e tyre të marrë rrugën e vet dhe të presim që problemi të zgjidhet vetë? Duhet të. Nuk është gjithmonë në fuqinë ose kompetencën tuaj për të zgjidhur plotësisht konfliktin, por në çdo situatë, në një konflikt të çdo shkalle, ju mund të merrni një pozicion të rritur, duke sjellë kështu disa njerëz të tjerë rreth jush në të, duke zbutur pasojat negative të konflikti dhe të kontribuojë në zgjidhjen e tij.
Përpara se të shohim disa shembuj të situatave të konfliktit, le të shohim disa pika të rëndësishme të përbashkëta për të gjitha konfliktet.
Gjatë zgjidhjes së një konflikti, është e rëndësishme të jesh mbi luftën, dhe jo brenda saj (kjo quhet edhe "marrja e një meta-pozicioni"), domethënë të mos jesh pjesë e njërës prej palëve në procesin e zgjidhjes. Përndryshe, të kesh ndihmë nga një arbitr i jashtëm, vendimi vetëm do të forcojë pozicionin e njërës nga palët në dëm të palës tjetër. Kur merrni një vendim, është e rëndësishme që ai të pranohet moralisht nga të gjitha palët, siç thonë ata, "blerë". Kështu që, edhe nëse palët nuk ishin të kënaqura me vendimin e marrë, të paktën sinqerisht pranuan ta zbatonin atë. Siç thonë ata, të jesh në gjendje të mos pajtohesh dhe të angazhohesh. Përndryshe, konflikti thjesht do të ndryshojë pamjen e tij, zjarri i djegur do të mbetet nën torfe dhe në një moment në mënyrë të pashmangshme do të ndizet përsëri.
Pika e dytë, pjesërisht e lidhur me të parën, është që nëse tashmë keni vendosur të merrni pjesë në zgjidhjen e konfliktit, merreni atë sa më seriozisht të jetë e mundur nga pikëpamja e komunikimit dhe studimit të kontekstit. Flisni personalisht me secilën nga palët. Më vete me secilën, për fillim. Mos u kënaq me postën. Në rastin e një ekipi të shpërndarë, të paktën flisni përmes lidhjes video. Mos u mjaftoni me thashethemet dhe raportet e dëshmitarëve okularë. Kuptoni historinë, çfarë dëshiron secila palë, pse e dëshiron, çfarë presin, a janë përpjekur ta zgjidhin më parë këtë çështje, çfarë do të ndodhë nëse nuk zgjidhet, çfarë zgjidhjesh shohin ata, si e imagjinojnë pozicionin e ana tjetër, çfarë mendojnë ata, të drejtë apo të gabuar, etj. Ngarkoni të gjithë kontekstin e mundshëm në kokën tuaj, me një mendje të hapur, duke supozuar se të gjithë kanë të drejtë. Nuk je brenda konfliktit, je jashtë tij, në një metapozicion. Nëse konteksti është i disponueshëm vetëm në një temë postimi, të paktën lexoni atë në tërësi dhe temat dhe dokumentet që lidhen me të. Pasi ta keni lexuar, vazhdoni të flisni me zërin tuaj. Ju jeni pothuajse të garantuar të dëgjoni diçka të rëndësishme që nuk është në postë.
Pika e tretë e rëndësishme është qasja e përgjithshme ndaj komunikimit. Këto janë gjëra të zakonshme, asgjë kozmike, por janë shumë të rëndësishme. Ne nuk përpiqemi të kursejmë kohë, ne flasim me të gjithë pjesëmarrësit, nuk e kritikojmë personin, por marrim parasysh pasojat e veprimeve të tij (jo "je i vrazhdë", por "ndoshta djemtë mund të ofendohen nga kjo gjë”), ne japim mundësinë për të shpëtuar fytyrën, ne zhvillojmë diskutime personalisht, jo përpara rreshtit.
Konfliktet zakonisht shkaktohen nga një nga dy arsyet. E para lidhet me faktin nëse një person në momentin e konfliktit është në pozitën e një të rrituri apo në pozitën e një fëmije (më shumë për këtë më poshtë). Kjo është për shkak të pjekurisë së tij emocionale, aftësisë për të menaxhuar emocionet e tij (që, nga rruga, nuk lidhet gjithmonë me moshën e tij). Arsyeja e dytë e zakonshme është papërsosmëria e procesit të punës, e cila krijon situata të zonave gri në të cilat përgjegjësia shpërndahet midis pjesëmarrësve, pritshmëritë e palëve nuk janë transparente ndaj njëra-tjetrës dhe rolet në proces janë të paqarta.
Prandaj, në zgjidhjen e një konflikti (si dhe çdo çështje tjetër), një menaxher duhet të ketë parasysh tre këndvështrime: afatshkurtër - për të zgjidhur çështjen/konfliktin këtu dhe tani, afatmesëm - për të minimizuar mundësinë e një konflikti tjetër. për të njëjtën arsye, dhe afatgjatë - për të kultivuar një kulturë të rritur në personin e ekipit.
Secili prej nesh ka një fëmijë të brendshëm, rreth tre ose katër vjeç. Ai fle shumicën e kohës në punë, por ndonjëherë zgjohet dhe merr kontrollin. Fëmija ka prioritetet e veta. Është e rëndësishme që ai të insistojë që kjo është kutia e tij e rërës, nëna e tij e do më shumë, makina e tij është më e mira (dizajni është më i miri, ai programon më të mirën, ...). Në një situatë konflikti, një fëmijë mund të shtypë lodrat, të godasë këmbët dhe të çajë shpatullën e tij, por ai nuk mund të zgjidhë çështjet e të rriturve (arkitektura e zgjidhjeve, qasjet ndaj testimit të automatizuar, datat e lëshimit, etj.), Ai nuk mendon për përfitimet për ekipin. Një fëmijë në konflikt mund të inkurajohet, ngushëllohet dhe dërgohet në shtrat duke i kërkuar të thërrasë të rriturin e tij. Përpara se të filloni një diskutim në një situatë konflikti, sigurohuni që po flisni me një të rritur, jo me një fëmijë, dhe se ju vetë jeni në pozitën e një të rrituri. Nëse qëllimi juaj i ndershëm për momentin është të zgjidhni një çështje serioze, ju jeni në pozitën e një të rrituri. Nëse qëllimi juaj është të shtypni këmbët dhe të plasni shpatullën, ky është një pozicion fëminor. Dërgojeni fëmijën tuaj të brendshëm në shtrat dhe telefononi një të rritur, ose riplanifikoni diskutimin. Një person merr një vendim emocional dhe më pas kërkon një justifikim racional për të. Një vendim i marrë nga një fëmijë i bazuar në prioritetet e fëmijëve nuk do të jetë optimal.
Përveç sjelljes në momentin e konfliktit, pozicioni i fëmijës ose i të rriturit karakterizohet edhe nga niveli i përgjegjësisë që një person është gati të marrë mbi vete. Në manifestimet e tij ekstreme, pozicioni fëminor i një programuesi, të cilin e kam takuar më shumë se një herë, duket kështu: Shkrova kodin, e dërgova për rishikim - puna ime mbaroi. Rishikuesit duhet ta shqyrtojnë dhe ta miratojnë, QA duhet ta kontrollojë, nëse ka probleme do të më njoftojnë. Mjaft e çuditshme, madje edhe njerëzit mjaft të pjekur dhe me përvojë ndonjëherë sillen në këtë mënyrë. Ana tjetër e shkallës është që një person e konsideron veten përgjegjës për t'u siguruar që kodi i tij funksionon, është i mbuluar nga testet, është kontrolluar personalisht nga ai, ka kaluar me sukses rishikimin (nëse është e nevojshme, nuk ka asnjë problem të tingëllojë recensues, të diskutojë çështje me zë, etj.) dhe është shtypur, QA do të ofrojë ndihmë nëse është e nevojshme, do të përshkruhen skenarë testimi, etj. Në raste normale, programuesi ose fillon më afër fundit të shkallës së të rriturve, ose lëviz atje ndërsa fiton përvojë (me kusht që të kultivohet kultura e duhur brenda ekipit). Në raste ekstreme, ai vazhdon të punojë, zakonisht duke marrë një pozicion fëminor, pastaj ai dhe ekipi kanë periodikisht probleme dhe konflikte.
Nxitja e kulturës së duhur dhe të pjekur në një ekip është një detyrë e rëndësishme për çdo menaxher. Duhet një kohë e gjatë dhe përpjekje e përditshme, por rezultati ia vlen. Ka dy mënyra për të ndikuar në kulturën e ekipit - udhëheqja me shembull (i cili patjetër do të ndiqet; ekipi gjithmonë shikon te lideri) dhe diskutimi dhe shpërblimi i sjelljes së duhur. As këtu nuk ka asgjë të pakuptimtë apo shumë formale, vetëm kur diskutoni probleme, vini re se këtu mund të ishte bërë diçka, theksoni se e keni vënë re kur është vendosur saktë, lëvdata, shënimi gjatë rishikimit të publikimit, etj.
Le të shqyrtojmë disa situata tipike konflikti, nga e thjeshta në komplekse:
Konflikte që nuk lidhen me çështjet e punës
Shumë shpesh në punë ka konflikte që nuk lidhen me çështjet e punës. Shfaqja dhe lehtësia e zgjidhjes së tyre zakonisht lidhen drejtpërdrejt me nivelin e inteligjencës emocionale të pjesëmarrësve, nivelin e tyre të pjekurisë dhe nuk lidhen me përsosmërinë ose papërsosmërinë e procesit të punës.
Shembuj tipikë: dikush nuk përdor shpesh lavatriçen ose dushin, gjë që të tjerëve nuk u pëlqen, dikush është i mbytur, ndërsa të tjerëve u vjen era nëse hapin dritaren, dikush është shumë i zhurmshëm dhe të tjerët kanë nevojë për heshtje për të punuar, dhe kështu me radhë. Është më mirë të mos vononi zgjidhjen e konflikteve të këtij lloji dhe të mos i lini të ndjekin rrugën e tyre. Ata nuk do zgjidhen vetë dhe do ju largojnë çdo ditë nga puna dhe do ju helmojnë atmosferën në ekip. Për fat të mirë, zgjidhja e tyre zakonisht nuk është një problem i madh - thjesht flisni me qetësi (një me një, sigurisht) me një koleg që neglizhon higjienën, siguroni ndenjëse të rehatshme për njerëzit që preferojnë heshtjen/freskinë, blini kufje që thithin zërin ose instaloni ndarje. , etj.
Një shembull tjetër që kam hasur disa herë gjatë punës sime është papajtueshmëria psikologjike e anëtarëve të ekipit. Për disa arsye, njerëzit thjesht nuk mund të punojnë së bashku; çdo ndërveprim përfundon në një skandal. Ndonjëherë kjo është për shkak të faktit se njerëzit kanë pikëpamje polare për ndonjë çështje urgjente (zakonisht politike) dhe nuk dinë t'i lënë ato jashtë punës. Bindja e tyre për të toleruar njëri-tjetrin ose për të ndryshuar sjelljen e tyre është një detyrë mjaft e kotë. Përjashtimi i vetëm që kam hasur janë kolegët e rinj me perceptime të hapura; sjellja e tyre ende mund të ndryshohet gradualisht përmes bisedave periodike. Zakonisht çështja zgjidhet me sukses duke i ndarë në ekipe të ndryshme, ose të paktën duke ofruar mundësinë për të mbivendosur në punë shumë rrallë.
Në të gjitha situatat e mësipërme, ia vlen të bisedoni me të gjithë pjesëmarrësit personalisht, të diskutoni situatën, të pyesni nëse ata shohin ndonjë problem në këtë rast fare, të pyesni se cilat, sipas mendimit të tyre, janë zgjidhjet dhe të sigurohet pjesëmarrja e tyre për ta bërë këtë. vendim.
Nga pikëpamja e optimizimit të procesit të punës (perspektiva afatmesme që përmenda), këtu nuk mund të bëhet shumë; e vetmja pikë për optimizim është të merret parasysh faktori i përputhshmërisë kur formohet një ekip dhe të mos vendosen njerëz. së bashku paraprakisht kush do të konfliktohet.
Nga këndvështrimi i kulturës së ekipit, situata të tilla lindin shumë më rrallë në ekipe me një kulturë të pjekur, ku njerëzit respektojnë ekipin dhe kolegët dhe dinë t'i zgjidhin çështjet në mënyrë të pavarur. Përveç kësaj, konflikte të tilla zgjidhen shumë më lehtë (shpesh automatikisht) në ekipe ku ka një nivel të lartë besimi, njerëzit kanë punuar së bashku për një kohë të gjatë dhe/ose komunikojnë shpesh jashtë punës.
Konfliktet në lidhje me çështjet e punës:
Konflikte të tilla zakonisht shkaktohen nga të dyja arsyet njëherësh, si emocionale (fakti që njëri nga pjesëmarrësit nuk është në pozitën e një të rrituri) ashtu edhe papërsosmëria e vetë procesit të punës. Ndoshta lloji më i zakonshëm i konflikteve që kam hasur janë konfliktet gjatë rishikimeve të kodit ose diskutimeve të arkitekturës midis zhvilluesve.
Këtu do të veçoja dy raste tipike:
1) Në rastin e parë, zhvilluesi nuk mund të marrë një rishikim të kodit nga një koleg. Patch-i dërgohet për rishikim dhe asgjë nuk ndodh. Në pamje të parë, nuk ka asnjë konflikt të dukshëm mes dy palëve, por nëse e mendoni mirë, ky është një konflikt i madh. Çështja e punës nuk zgjidhet, njëra nga palët (në pritje të një rishikimi) përjeton shqetësim të dukshëm. Një nënlloj ekstrem i këtij rasti është zhvillimi në një komunitet ose në ekipe të ndryshme, ndërsa rishikuesi mund të mos jetë i interesuar për këtë kod të veçantë, për shkak të ngarkimit ose rrethanave të tjera, mund të mos i kushtojë fare vëmendje kërkesës për rishikim dhe arbitri i jashtëm (një menaxher i përbashkët për të dyja palët) ) mund të mos ekzistojë fare.
Qasja e zgjidhjes që ndihmon në një situatë të tillë lidhet pikërisht me perspektivën afatgjatë, kulturën e një të rrituri. Së pari, aktiviteti i zgjuar funksionon. Ju nuk duhet të prisni që kodi i varur në rishikim të tërheqë vëmendjen e vetë recensuesit. Ne duhet t'i ndihmojmë recensuesit ta vërejnë atë. Pingani disa njerëz, bëni një pyetje për sinkape, merrni pjesë në diskutime. Natyrisht, imponimi ka më shumë gjasa të dëmtojë sesa të ndihmojë, ju duhet të përdorni sensin e përbashkët. Së dyti, përgatitja paraprake funksionon mirë. Nëse ekipi e kupton se çfarë po ndodh dhe pse, pse është i nevojshëm fare ky kod, dizajni është diskutuar dhe rënë dakord paraprakisht me të gjithë, njerëzit kanë më shumë gjasa t'i kushtojnë vëmendje një kodi të tillë dhe ta pranojnë atë për punë. Së treti, autoriteti funksionon. Nëse dëshironi të rishikoheni, bëni shumë rishikime vetë. Bëni rishikime me cilësi të lartë, me kontrolle reale, teste reale dhe komente të dobishme. Nëse pseudonimi juaj është i njohur mirë në ekip, ka një shans më të madh që kodi juaj të vërehet.
Nga pikëpamja e rrjedhës së punës, përmirësimet e mundshme këtu janë prioritizimi i saktë që synon të ndihmojë zhvilluesin të arrijë qëllimet e tij dhe të ekipit (rishikoni të tjerët, shkruani letra për komunitetin, shoqëroni kodin me një përshkrim të arkitekturës, dokumentacion, teste, merrni pjesë në diskutime me komuniteti, etj.), parandaloni që arna të varen në radhë për një kohë të gjatë, e kështu me radhë.
2) Rasti i dytë i zakonshëm i konflikteve gjatë rishikimeve të kodit ose dizajnit janë pikëpamjet e ndryshme mbi çështjet teknike, stili i kodimit dhe zgjedhja e mjeteve. Me rëndësi të madhe në këtë rast është niveli i besimit ndërmjet pjesëmarrësve, që i përkasin të njëjtit ekip dhe përvoja e punës së bashku. Një qorrsokak ndodh kur njëri nga pjesëmarrësit merr një pozicion fëminor dhe nuk përpiqet të dëgjojë atë që bashkëbiseduesi dëshiron t'i përcjellë. Shpesh, si qasja e propozuar nga pala tjetër ashtu edhe qasja e propozuar fillimisht mund të funksionojnë me sukses dhe në parim nuk ka rëndësi se cilën të zgjedhësh.
Një ditë, një programues nga ekipi im (le ta quajmë Pasha) përgatiti një patch me ndryshime në sistemin e vendosjes së paketave, i cili u zhvillua dhe u mbështet nga kolegë nga një departament fqinj. Njëri prej tyre (Igor) kishte mendimin e tij të fortë në lidhje me saktësisht se si duhet të konfigurohen shërbimet Linux gjatë vendosjes së paketave. Ky mendim ndryshonte nga qasja e propozuar në patch, dhe ata nuk mund të pajtoheshin. Si zakonisht, afatet po mbaronin dhe ishte e nevojshme të merrej një lloj vendimi; ishte e nevojshme që njëri prej tyre të merrte një pozicion të rritur. Pasha e kuptoi se të dyja qasjet kanë të drejtën e jetës, por ai donte që opsioni i tij të kalonte, sepse As njëra dhe as e dyta nuk kishin ndonjë avantazh të dukshëm teknik.
Diskutimi ynë dukej diçka e tillë (shumë skematikisht, natyrisht, biseda zgjati gjysmë ore):
- Pasha, pas pak ditësh kemi një ngrirje të veçorive. Është e rëndësishme që të mbledhim gjithçka dhe të fillojmë testimin sa më shpejt të jetë e mundur. Si mund ta kalojmë Igorin?
— Ai kërkon të vendosë shërbime ndryshe, më ka ngulur komentet atje...
- Dhe çfarë ka, ndryshime të mëdha, shumë bujë?
- Jo, ka nja dy orë punë, por në fund të fundit nuk ka ndryshim, do të funksionojë sido që të jetë, pse është e nevojshme kjo? Kam bërë diçka që funksionon, le ta pranojmë.
- Dëgjo, sa kohë ke që i diskuton të gjitha këto?
- Po, kemi një javë e gjysmë që shënojmë kohën.
- Hm... a mund ta zgjidhim një çështje brenda disa orësh që ka marrë tashmë një javë e gjysmë dhe të mos e bëjmë?
- Epo, po, por nuk dua që Igor të mendojë se jam dorëzuar...
- Dëgjo, çfarë është më e rëndësishme për ty, të lëshosh një lirim, bashkë me vendimin tënd brenda, apo të vrasësh Igorin? Ne mund ta bllokojmë atë, atëherë, megjithatë, ka një shans të mirë për të fluturuar me lëshimin.
- Epo ... do të ishte mirë, sigurisht, të fshija hundën e Igorit, por në rregull, lëshimi është më i rëndësishëm, jam dakord.
- A është vërtet kaq e rëndësishme për ju ajo që mendon Igor? Për të qenë i sinqertë, ai nuk ia merr mendja fare, thjesht do një qasje të unifikuar në vende të ndryshme të gjësë për të cilën është përgjegjës.
- Epo, ok, më lër të bëj ashtu siç kërkon ai në komente dhe le të fillojmë testimin.
- Faleminderit Pasha! Isha i sigurt se nga ju të dy do të ishit më të pjekurit, megjithëse Igorek është më i madh se ju :)
Çështja u zgjidh, lirimi u lirua në kohë, Pasha nuk ndjeu shumë pakënaqësi, sepse ai vetë propozoi një zgjidhje dhe e zbatoi atë. Igor në përgjithësi ishte i kënaqur, sepse ... Mendimi i tij u mor në konsideratë dhe vepruan siç sugjeroi ai.
Një lloj tjetër i të njëjtit konflikt në thelb është zgjedhja midis zgjidhjeve teknike/bibliotekave/qasjeve në një projekt, veçanërisht në një ekip të shpërndarë. Në një nga projektet, i cili u pozicionua si duke përdorur C/C++, rezultoi se menaxhimi teknik i projektit ishte kategorikisht kundër përdorimit të STL (Standard Template Library). Kjo është një bibliotekë standarde e gjuhëve që thjeshton zhvillimin dhe ekipi ynë është shumë i mësuar me të. Doli që projekti është shumë më afër C-së sesa C++, gjë që nuk e frymëzoi shumë ekipin, sepse drejtuesit u përpoqën më të mirën dhe rekrutuan lojtarë plus shumë të mirë. Në të njëjtën kohë, pjesa amerikane e ekipit, inxhinierë dhe menaxherë, kishin punuar në kompani për një kohë të gjatë, ishin mësuar me gjendjen ekzistuese dhe ishin të kënaqur me gjithçka. Pjesa ruse e ekipit u mblodh kohët e fundit, brenda pak javësh (përfshirë mua). Pjesa ruse e ekipit kategorikisht nuk donte të braktiste qasjen e zakonshme ndaj zhvillimit.
Filluan diskutime të pafundme me shkrim midis dy kontinenteve, letrat në tre ose katër ekrane fluturonin mbrapa dhe mbrapa, në postime në grup dhe në ato personale, nga programuesit te programuesit dhe menaxherët. Siç ndodh zakonisht, letra të kësaj gjatësie nuk lexoheshin nga askush përveç autorëve dhe mbështetësve të tyre të zjarrtë. Bisedat kërcasin nga tensioni, duke kaluar mendime në shumë ekrane në drejtime të ndryshme në lidhje me avantazhet teknike të STL, sa mirë është i testuar, sa i sigurt është dhe në përgjithësi, sa e mrekullueshme është jeta me të dhe sa e tmerrshme është pa të .
E gjithë kjo zgjati shumë, derisa më në fund kuptova se po diskutonim aspektet teknike të çështjes, por problemi në realitet nuk ishte teknik. Problemi nuk janë avantazhet ose disavantazhet e STL ose vështirësia për të punuar pa të. Problemi është më tepër organizativ. Thjesht duhej të kuptonim se si funksiononte kompania për të cilën punonim. Askush prej nesh nuk kishte përvojë pune në një kompani të tillë më parë. Puna ishte se pasi kodi u zhvillua dhe u lëshua në prodhim, mbështetja u trajtua nga njerëz krejtësisht të ndryshëm nga ekipe të tjera, nga vende të tjera. Ky ekip i madh inxhinierik prej disa dhjetëra mijëra inxhinierësh (në total) mund të përballonte vetëm një minimum plotësisht bazë mjetesh teknike, si të thuash, një minimum minimal. Çdo gjë që shkonte përtej standardit inxhinierik të vendosur në kompani fizikisht nuk mund të mbështetej në të ardhmen. Niveli i një ekipi përcaktohet nga niveli i anëtarëve të tij më të dobët. Pasi e kuptuam motivim real veprimet e pjesës amerikane të ekipit, kjo çështje u hoq nga rendi i ditës, dhe së bashku ne zhvilluam dhe lëshuam me sukses produktin duke përdorur standardet e miratuara nga kompania. Letrat dhe bisedat në këtë rast nuk funksionuan mirë, u deshën disa udhëtime dhe shumë komunikime personale për të arritur në një emërues të përbashkët.
Nga pikëpamja e rrjedhës së punës, në këtë rast të veçantë, do të ndihmonte të kishim një përshkrim të mjeteve të përdorura, kërkesat për to, kufizimet për shtimin e të rejave dhe justifikimin për kufizime të tilla. Dokumentet e tilla përafërsisht korrespondojnë me ato të përshkruara në paragrafët Strategjia e Ripërdorimit dhe Mjedisi i Zhvillimit të "Doracakut të Menaxherit për Zhvillimin e Softuerit", zhvilluar në . Pavarësisht nga mosha e tij, ai përshkruan në mënyrë të përsosur të gjitha aktivitetet kryesore dhe fazat e planifikimit të zhvillimit të softuerit të këtij lloji. Pasja e dokumenteve të tilla e bën shumë të lehtë diskutimin se cilat komponentë dhe qasje mund të përdoren në një produkt dhe pse.
Nga pikëpamja kulturore, padyshim, me një pozicion më të pjekur, në të cilin palët përpiqen të dëgjojnë dhe kuptojnë motivimin real të veprimeve të kolegëve të tyre dhe të veprojnë bazuar në prioritetet e projektit dhe ekipit, dhe jo në egon personale. , konflikti do të zgjidhej më lehtë dhe më shpejt.
Në një konflikt tjetër për zgjedhjen e një zgjidhjeje teknike, m'u desh gjithashtu një kohë e dukshme për të kuptuar motivimin e njërës prej palëve (ishte një rast shumë i pazakontë), por pasi motivimi ishte i qartë, zgjidhja ishte e qartë.
Situata është kjo: një zhvillues i ri shfaqet në një ekip prej rreth 20 personash, le ta quajmë Stas. Në atë kohë, mjeti ynë standard për komunikim si ekip ishte Skype. Siç doli më vonë, Stas ishte një adhurues i madh i standardeve të hapura dhe softuerit me burim të hapur, dhe përdorte vetëm mjete dhe sisteme operative, burimet e të cilave ishin të disponueshme publikisht dhe që përdornin protokolle të përshkruara publikisht. Skype nuk është një nga këto mjete. Kaluam shumë kohë duke diskutuar avantazhet dhe disavantazhet e kësaj qasjeje, përpjekjet për të nisur analoge të Skype në sisteme të ndryshme operative, përpjekjet e Stas për të bindur ekipin të kalonte në standarde të tjera, t'i shkruante atij personalisht me postë, ta telefononte personalisht në telefon, blej atij një kompjuter të dytë enkas për Skype, etj. Më në fund, kuptova se ky problem, në thelb, nuk është teknik ose organizativ, është më tepër ideologjik, madje, mund të thuhet, fetar (për Stasin). Edhe nëse përfundimisht do të lidhnim Stas dhe Skype (që zgjati disa muaj), problemi do të lindte përsëri në çdo instrument të mëvonshëm. Nuk kisha asnjë mjet real në dispozicionin tim për të ndryshuar botëkuptimin e Stasit dhe nuk kishte asnjë arsye të përpiqesha të ndryshoja botëkuptimin e një ekipi që funksiononte në mënyrë perfekte në këtë mjedis. Personi dhe kompania ishin thjesht ortogonale në botëkuptimin e tyre. Në situata të tilla, një zgjidhje e mirë është organizative. Ne e transferuam Stasin në një ekip tjetër, ku ai ishte më organik.
Arsyeja e këtij konflikti, për mendimin tim, është mospërputhja midis kulturës personale të një personi të caktuar (i cili ka një mendim të fortë që nuk e lejon atë të bëjë kompromis) dhe kulturës së kompanisë. Në këtë rast, sigurisht që është gabim i menaxherit. Fillimisht ishte gabim ta merrje në një projekt të këtij lloji. Stas përfundimisht u zhvendos në një projekt të zhvillimit të softuerit me burim të hapur dhe shkëlqeu atje.
Një shembull i mirë i një konflikti të shkaktuar si nga qëndrimi fëmijëror i zhvilluesit ashtu edhe nga mangësitë e procesit të punës është një situatë në të cilën, në mungesë të një përkufizimi të kryer, zhvilluesi dhe ekipi i SC kanë pritshmëri të ndryshme në lidhje me gatishmërinë e funksioni i transferuar në QA. Zhvilluesi besonte se ishte e mjaftueshme për të shkruar kodin dhe për ta hedhur funksionin mbi gardh në QA - ata do ta zgjidhnin atë atje. Një programues mjaft i pjekur dhe me përvojë, meqë ra fjala, por ky ishte pragu i tij i brendshëm për cilësi. QA nuk u pajtua me këtë dhe kërkoi t'u tregonte dhe përshkruante atyre atë që kishte kontrolluar vetë, dhe kërkoi një skenar testimi për ta. Ata kishin pasur probleme me funksionalitetin nga ky zhvillues në të kaluarën dhe nuk donin të humbnin kohën e tyre përsëri. Nga rruga, ata kishin të drejtë - funksioni me të vërtetë nuk funksionoi, ai nuk e kontrolloi kodin përpara se ta dërgonte në QA.
Për të zgjidhur situatën, i kërkova të më tregonte se gjithçka me të vërtetë funksionoi (nuk funksionoi dhe ai duhej ta rregullonte), ne biseduam me ekipin dhe me përkufizimin e QA të kryer (ata nuk ia dolën me shkrim, sepse nuk donim ta bënim procesin shumë burokratik), mirë, shpejt u ndamë me këtë specialist (për lehtësim të përgjithshëm).
Nga pikëpamja e rrjedhës së punës, përmirësimet e mundshme në këtë rast janë prania e një përkufizimi të kryer, kërkesat për mbështetjen e secilës veçori të njësisë dhe testet e integrimit, si dhe një përshkrim i testimit të kryer nga zhvilluesi. Në një nga projektet, ne matëm nivelin e mbulimit të kodit me teste gjatë CI dhe nëse niveli i mbulimit binte pas shtimit të një patch, testet u shënuan si të dështuara, d.m.th. çdo kod i ri mund të shtohej vetëm nëse do të kishte teste të reja për të.
Një shembull tjetër tipik i një konflikti të lidhur ngushtë me organizimin e procesit të punës. Ne kemi një produkt, një ekip zhvillimi produkti, një ekip mbështetës dhe një klient. Klienti ka probleme me produktin dhe kontakton mbështetjen. Mbështetja analizon problemin dhe kupton se problemi është në produkt dhe ia transferon problemin ekipit të produktit. Ekipi i produktit është në një kohë të ngarkuar, një lëshim po afron, kështu që një biletë me një problem nga një klient, e humbur midis biletave të tjera të zhvilluesit të cilit i është caktuar, varet për disa javë pa vëmendje. Mbështetja mendon se zhvilluesi po punon për problemin e klientit. Klienti pret dhe shpreson që problemi i tyre po punohet. Në realitet, asgjë nuk po ndodh ende. Pas disa javësh, klienti më në fund vendos të interesohet për përparimin dhe kërkon mbështetje se si po shkojnë gjërat. Mbështetja kërkon zhvillim. Zhvilluesi dridhet, shikon listën e biletave dhe gjen një biletë nga klienti atje. Duke lexuar një biletë nga një klient, ai e kupton se nuk ka informacion të mjaftueshëm për të zgjidhur problemin dhe ai ka nevojë për më shumë trungje dhe deponi. Mbështetja kërkon informacion shtesë nga klienti. Dhe atëherë klienti kupton se askush nuk ka punuar për problemin e tij gjatë gjithë kësaj kohe. Dhe bubullima do të godasë ...
Në këtë situatë, vetë zgjidhja e konfliktit është mjaft e dukshme dhe lineare (rregullimi i produktit, përditësimi i dokumentacionit dhe testimi, qetësimi i klientit, lëshimi i një rregullimi të drejtpërdrejtë, etj.). Është e rëndësishme të analizohet procesi i punës dhe të kuptohet se kush është përgjegjës për organizimin e ndërveprimit midis dy ekipeve dhe pse kjo situatë u bë e mundur në radhë të parë. Është e qartë se çfarë duhet të rregullohet në proces - dikush duhet të monitorojë pamjen e përgjithshme pa kujtime nga klientët, në mënyrë proaktive. Biletat nga klienti duhet të dallohen midis biletave të tjera nga zhvilluesit. Mbështetja duhet të shohë nëse ekipi i zhvillimit po punon aktualisht me biletat e tij dhe nëse jo, kur mund të fillojë të punojë dhe kur mund të priten rezultatet. Mbështetja dhe zhvillimi duhet të komunikojnë dhe diskutojnë periodikisht statusin e biletave, mbledhja e informacionit të nevojshëm për korrigjimin duhet të automatizohet sa më shumë që të jetë e mundur, etj.
Ashtu si në luftë armiku përpiqet të godasë kryqëzimin midis dy njësive, ashtu edhe në punë pika më delikate dhe më e cenueshme është zakonisht ndërveprimi ndërmjet ekipeve. Nëse menaxherët e mbështetjes dhe zhvillimit janë mjaft të vjetër, ata do të jenë në gjendje ta rregullojnë vetë procesin, nëse jo, procesi do të vazhdojë të gjenerojë konflikte dhe probleme derisa të ndërhyjë një menaxher që mund ta rregullojë situatën.
Një shembull tjetër tipik që e kam parë vazhdimisht në kompani të ndryshme është një situatë në të cilën një produkt shkruhet nga një ekip, testet automatike të integrimit për të shkruhen nga një ekip i dytë dhe infrastruktura në të cilën operohet e gjitha shoqërohet nga një i tretë. ekipi. Problemet gjatë ekzekutimit të testeve lindin gjatë gjithë kohës, dhe shkaku i problemeve në to mund të jetë si produkti, ashtu edhe testet dhe infrastruktura. Zakonisht është problematike të bihet dakord se kush duhet të kryejë analizën fillestare të problemeve, gabimet e skedarëve, analizën e regjistrave të produktit, testet dhe infrastrukturën, etj. Konfliktet këtu janë shumë të shpeshta dhe, në të njëjtën kohë, uniforme. Në rastin e intensitetit të lartë emocional, pjesëmarrësit shpesh bien në një pozicion fëminor dhe diskutimet fillojnë në seri: "pse duhet të ngatërroj me këtë", "ata prishen më shpesh", etj.
Nga këndvështrimi i rrjedhës së punës, hapat specifikë për të zgjidhur një problem varen nga përbërja e ekipeve, lloji i testeve dhe produktit, etj. Në një nga projektet, ne prezantuam detyrën periodike, në të cilën ekipet monitoronin testet një nga një, javë pas jave. Në anën tjetër, analiza fillestare bëhej gjithmonë nga zhvilluesit e testit, por analiza ishte shumë themelore dhe produkti ishte mjaft i qëndrueshëm, kështu që funksionoi mirë. Çelësi është të sigurohet që procesi të jetë transparent, që pritshmëritë të jenë të qarta për të gjitha palët dhe që situata të ndihet e drejtë për të gjithë.
A është konflikti një problem në një organizatë?A është një shenjë e keqe që konfliktet ndodhin shpesh (ose thjesht periodikisht) në ekipin tuaj? Në përgjithësi, jo, sepse nëse ka rritje, zhvillim, ka një lloj dinamike, atëherë lindin çështje që nuk janë zgjidhur kurrë më parë dhe gjatë zgjidhjes së tyre mund të lindin konflikte. Ky është një tregues se disa fusha kanë nevojë për vëmendje, se ka fusha për përmirësim. Është keq nëse konfliktet lindin shumë shpesh, janë të vështira për t'u zgjidhur ose zgjasin shumë. Kjo ka shumë të ngjarë një shenjë e proceseve të punës të thjeshtuara në mënyrë të pamjaftueshme dhe pjekurisë së pamjaftueshme të ekipit.
Burimi: www.habr.com