Konflikthantering i ett team – en balansgång eller en livsnödvändighet?

Motto:
En gång i tiden möttes Igelkotten och Lilla Björnen i skogen.
- Hej igelkott!
- Hej, lilla björn!
Så, ord för ord, skämt för skämt, blev igelkotten träffad i ansiktet av den lilla björnen...

Nedan är en diskussion från vår teamledare, samt RAS produktutvecklingschef Igor Marnat, om detaljerna kring arbetskonflikter och möjliga metoder för att hantera dem.

De flesta av de konflikter vi möter på jobbet utvecklas enligt ett scenario som liknar det som beskrivs i epigrafen ovan. Det finns flera deltagare som initialt är ganska positivt inställda till varandra, de försöker lösa något problem, men i slutändan förblir problemet olöst, och av någon anledning visar sig relationerna mellan deltagarna i diskussionen vara förstörda.

Livet är mångsidigt och variationer förekommer i scenariot som beskrivs ovan. Ibland är relationen mellan deltagarna inte särskilt bra initialt, ibland finns det inte ens en fråga som kräver en direkt lösning (som t.ex. i epigrafen), ibland efter diskussionen förblir relationen densamma som innan den började, men problemet är i slutändan inte löst.

Vad är vanligt i alla situationer som kan definieras som en situation av arbetskonflikt?



För det första finns det två eller flera sidor. Dessa parter kan uppta olika platser i organisationen, vara i ett jämställdhetsförhållande (kollegor i ett team), eller på olika nivåer i hierarkin (chef - underordnad), vara individuella (anställda) eller grupp (vid konflikter mellan en anställd och ett team eller två team) och så vidare. Sannolikheten för konflikter och hur lätt det är att lösa dem påverkas i hög grad av nivån på förtroendet mellan deltagarna. Ju bättre parterna känner varandra, desto högre förtroende, desto större är chansen att de kommer överens. Till exempel är medlemmar i ett distribuerat team som aldrig har interagerat ansikte mot ansikte mer benägna att uppleva konflikter över en enkel arbetsfråga än personer som har haft åtminstone några ansikte mot ansikte interaktioner. När man arbetar i distribuerade team är det därför mycket viktigt att se till att alla teammedlemmar träffas med jämna mellanrum personligen med varandra.

För det andra, i en konfliktsituation på jobbet, är parterna i en situation där de löser en fråga som är viktig för en av parterna, för dem båda eller för organisationen som helhet. Samtidigt, på grund av situationens särdrag, har parterna vanligtvis tillräckligt med tid och en mängd olika sätt att lösa det (formella, informella, möten, brev, ledningsbeslut, närvaron av mål och planer för teamet, faktum om en hierarki, etc.). Detta skiljer sig från situationen för att lösa ett arbete (eller icke-arbete) i en organisation från att till exempel lösa en viktig fråga: "Eh, grabb, vilket område kommer du ifrån?!" på gatan, eller konflikten från epigrafen. Vid lösning av en arbetsfråga spelar kvaliteten på arbetsprocessen och kulturen för att lösa frågor i teamet roll.

För det tredje är den avgörande faktorn för konflikten (ur vår diskussions synvinkel) det faktum att parterna i processen inte självständigt kan komma fram till en lösning på frågan som passar alla parter. Situationen kräver ingripande av en tredje part, en extern skiljedomare. Denna punkt kan tyckas kontroversiell, men i huvudsak, om konfliktsituationen framgångsrikt löstes utan ingripande av en extern skiljedomare, frågan löstes framgångsrikt och parternas relationer inte försämrades, det är denna situation som vi bör sträva efter. . Vi kommer med största sannolikhet inte ens att veta om en sådan konflikt, eller så kommer vi att få reda på det av en slump när den är löst. Ju fler problem ett team kan lösa på egen hand, desto effektivare blir det.

Ett annat karaktäristiskt drag i konflikten som är värt att beröra är graden av känslomässig intensitet under beslutet. Konflikt är inte nödvändigtvis förknippat med en hög känslomässig nivå. Deltagarna behöver inte skrika och vifta med armarna för att situationen i grunden ska bli en konflikt. Frågan är inte löst, en viss känslomässig spänning finns (kanske är den inte tydligt uttryckt utåt), vilket gör att vi står inför en konfliktsituation.

Är det överhuvudtaget nödvändigt att ingripa i konfliktsituationer, eller är det bättre att låta deras lösning ta sin gång och vänta på att problemet löser sig? Behöver. Det ligger inte alltid i din makt eller kompetens att lösa konflikten fullständigt, men i alla situationer, i en konflikt av vilken skala som helst, kan du ta en vuxenposition och därigenom ta med dig fler människor omkring dig, mildra de negativa konsekvenserna av konflikt och bidra till dess lösning.

Innan vi tittar på några exempel på konfliktsituationer, låt oss titta på några viktiga punkter som är gemensamma för alla konflikter.

När man löser en konflikt är det viktigt att stå över kampen, och inte inuti den (det kallas också att ”ta en metaposition”), det vill säga att inte vara en del av en av parterna i lösningsprocessen. Annars kommer en extern skiljedomare att bistå beslutet bara att stärka den ena partens ställning till skada för den andra parten. När man fattar ett beslut är det viktigt att det är moraliskt accepterat av alla parter, som de säger, "köpta". Så att även om parterna inte var nöjda med det fattade beslutet, gick de åtminstone uppriktigt med på att genomföra det. Som man säger, att kunna vara oense och engagera sig. Annars kommer konflikten helt enkelt att ändra utseende, den pyrande elden kommer att ligga kvar under torvmossen och någon gång oundvikligen blossa upp igen.

Den andra punkten, delvis relaterad till den första, är att om du redan har bestämt dig för att delta i att lösa konflikten, ta den så seriöst som möjligt ur kommunikationssynpunkt och studera sammanhanget. Prata personligen med var och en av parterna. Separat med varje, till att börja med. Nöj dig inte med post. I fallet med ett distribuerat team, prata åtminstone via videolänk. Nöj dig inte med hörsägen och ögonvittnesrapporter. Förstå historien, vad varje sida vill, varför de vill ha det, vad de förväntar sig, har de försökt lösa detta problem tidigare, vad kommer att hända om det inte löses, vilka lösningar ser de, hur föreställer de sig positionen för andra sidan, vad tycker de, rätt eller fel osv. Ladda alla möjliga sammanhang i ditt huvud, med ett öppet sinne, förutsatt att alla har rätt. Du är inte inne i konflikten, du är utanför den, i en metaposition. Om sammanhanget bara är tillgängligt i en inläggstråd, läs åtminstone den i sin helhet och de trådar och dokument som är relaterade till den. När du har läst den, prata fortfarande med din röst. Du kommer nästan garanterat att höra något viktigt som inte kommer med posten.

Den tredje viktiga punkten är det allmänna förhållningssättet till kommunikation. Det här är vanliga saker, inget kosmiskt, men de är väldigt viktiga. Vi försöker inte spara tid, vi pratar med alla deltagare, vi kritiserar inte personen, men vi överväger konsekvenserna av hans handlingar (inte "du är oförskämd", utan "kanske killarna kan bli förolämpade av denna sak”), ger vi möjligheten att rädda ansiktet, vi för diskussioner personligen, inte framför linjen.

Konflikter orsakas vanligtvis av en av två orsaker. Den första är relaterad till om en person vid tidpunkten för konflikten befinner sig i en vuxens eller ett barns position (mer om detta nedan). Detta beror på hans känslomässiga mognad, förmågan att hantera sina känslor (som för övrigt inte alltid är relaterad till hans ålder). Den andra vanliga orsaken är ofullkomligheten i arbetsprocessen, vilket skapar situationer med gråzoner där ansvaret är utspritt mellan deltagarna, parternas förväntningar inte är transparenta för varandra och rollerna i processen är suddiga.

Följaktligen, vid lösning av en konflikt (liksom alla andra frågor), måste en chef ha tre perspektiv i åtanke: kortsiktigt - för att lösa problemet/konflikten här och nu, medellång sikt - för att minimera sannolikheten för att en annan konflikt ska uppstå av samma anledning, och långsiktigt - att odla en vuxenkultur i teampersonen.

Var och en av oss har ett inre barn, ungefär tre eller fyra år gammalt. Han sover mest på jobbet, men vaknar ibland och tar kontrollen. Barnet har sina egna prioriteringar. Det är viktigt för honom att insistera på att det här är hans sandlåda, hans mamma älskar honom mer, hans maskin är bäst (designen är bäst, han programmerar bäst, ...). I en konfliktsituation kan ett barn trycka på leksaker, stampa fötterna och knäcka sin spatel, men han kan inte lösa vuxenproblem (lösningsarkitektur, tillvägagångssätt för automatiserad testning, releasedatum, etc.), han tänker inte i termer av fördelar för laget. Ett barn i konflikt kan uppmuntras, tröstas och skickas till sängs genom att be honom ringa sin vuxen. Innan du börjar en diskussion i en konfliktsituation, se till att du pratar med en vuxen, inte ett barn, och att du själv befinner dig i en vuxens position. Om ditt ärliga mål för tillfället är att lösa ett allvarligt problem, är du i en vuxens position. Om ditt mål är att stampa med fötterna och knäcka skulderbladet är detta en barnslig position. Skicka ditt inre barn i säng och ring en vuxen, eller boka om diskussionen. En person fattar ett känslomässigt beslut och letar sedan efter en rationell motivering för det. Ett beslut som tas av ett barn utifrån barns prioriteringar kommer inte att vara optimalt.

Utöver beteende vid tidpunkten för konflikt kännetecknas ett barns eller vuxens position också av den nivå av ansvar som en person är beredd att ta på sig. I sina extrema manifestationer ser den barnsliga positionen för en programmerare, som jag har träffat mer än en gång, så här: Jag skrev koden, skickade den för granskning - mitt arbete är klart. Granskare bör granska det och godkänna det, QA bör kontrollera det, om det finns problem kommer de att meddela mig. Märkligt nog beter sig ibland ganska mogna och erfarna människor på det här sättet. Den andra änden av skalan är att en person anser sig själv vara ansvarig för att se till att hans kod fungerar, omfattas av tester, har blivit personligen kontrollerad av honom, har klarat granskningen (vid behov är det inga problem att pinga granskare, diskutera frågor med röst, etc.) och har undertryckts, QA kommer att ge hjälp vid behov, testscenarier kommer att beskrivas, etc. I vanliga fall börjar programmeraren antingen närmare den vuxna änden av skalan, eller flyttar dit allt eftersom han får erfarenhet (förutsatt att rätt kultur odlas inom teamet). I extrema fall fortsätter han att arbeta, vanligtvis tar han en barnslig position, då har han och teamet med jämna mellanrum problem och konflikter.

Att fostra rätt, mogen kultur i ett team är en viktig uppgift för alla chefer. Det tar lång tid och daglig ansträngning, men resultatet är värt det. Det finns två sätt att påverka teamkulturen – att leda med gott exempel (vilket definitivt kommer att följas; teamet ser alltid till ledaren) och diskutera och belöna rätt beteende. Det finns inget abstrut eller väldigt formellt här heller, bara när man diskuterar problem, märk att något kunde ha gjorts här, betona att du märkt när det var rätt beslutat, beröm, notera under releasegranskningen osv.

Låt oss överväga flera typiska konfliktsituationer, från enkla till komplexa:

Konflikter som inte är relaterade till arbetsfrågor

Ganska ofta finns det konflikter på jobbet som inte är relaterade till arbetsfrågor. Deras förekomst och lätthet att upplösa är vanligtvis direkt relaterade till nivån på deltagarnas känslomässiga intelligens, deras mognadsnivå och är inte relaterade till perfektion eller ofullkomlighet i arbetsprocessen.

Typiska exempel: någon använder inte tvättmaskinen eller duschar tillräckligt ofta, vilket andra inte gillar, någon är kvav, medan andra får vind om de öppnar fönstret, någon bullrar för mycket och andra behöver tystnad för att fungera, och så vidare. Det är bättre att inte fördröja lösningen av konflikter av detta slag och att inte låta dem ta sin kurs. De kommer inte att lösa sig på egen hand och kommer att distrahera dig från jobbet varje dag och förgifta atmosfären i teamet. Lyckligtvis är det oftast inte ett stort problem att lösa dem - prata bara lugnt (en-mot-en, förstås) med en kollega som struntar i hygienen, ge bekväma sittplatser för människor som föredrar tystnad/svalka, köp ljudabsorberande hörlurar eller installera skiljeväggar , etc.

Ett annat exempel som jag stött på flera gånger under mitt arbete är teammedlemmarnas psykologiska inkompatibilitet. Av någon anledning kan människor helt enkelt inte arbeta tillsammans, varje interaktion slutar i en skandal. Ibland beror detta på att människor har polära åsikter om någon brådskande fråga (oftast politisk) och inte vet hur de ska lämna dem utanför arbetet. Att övertyga dem att tolerera varandra eller ändra sitt beteende är en ganska meningslös uppgift. Det enda undantaget jag har stött på är unga kollegor med öppna uppfattningar, deras beteende kan fortfarande gradvis förändras genom periodiska samtal. Vanligtvis löses problemet framgångsrikt genom att dela upp dem i olika team, eller åtminstone ge möjligheten att överlappa varandra på jobbet mycket sällan.

I alla ovanstående situationer är det värt att prata med alla deltagare personligen, diskutera situationen, fråga om de överhuvudtaget ser ett problem i det här fallet, fråga vad de tycker är lösningarna och se till att de är med och gör detta. beslut.

Ur synvinkeln att optimera arbetsprocessen (det medelfristiga perspektivet som jag nämnde), kan inte mycket göras här, den enda punkten för optimering är att ta hänsyn till kompatibilitetsfaktorn när man bildar ett team och inte att sätta människor tillsammans i förväg vem som kommer i konflikt.

Ur ett teamkulturperspektiv uppstår sådana situationer mycket mer sällan i team med en mogen kultur, där människor respekterar teamet och kollegorna och vet hur man löser problem självständigt. Dessutom löses sådana konflikter mycket lättare (ofta automatiskt) i team där det finns ett högt förtroende, människor har arbetat tillsammans länge och/eller kommunicerar ofta utanför arbetet.

Konflikter relaterade till arbetsfrågor:

Sådana konflikter orsakas vanligtvis av båda orsakerna samtidigt, både känslomässiga (det faktum att en av deltagarna inte är i en vuxen position) och ofullkomligheten i själva arbetsprocessen. Den kanske vanligaste typen av konflikter som jag har stött på är konflikter under kodgranskning eller arkitekturdiskussioner mellan utvecklare.

Jag skulle lyfta fram två typiska fall här:

1) I det första fallet kan utvecklaren inte få en kodgranskning från en kollega. Patchen skickas för granskning och ingenting händer. Vid första anblicken finns det ingen uppenbar konflikt mellan de två sidorna, men om man tänker efter så är det här en ganska stor konflikt. Arbetsfrågan är inte löst, en av parterna (väntar på granskning) upplever uppenbart obehag. En extrem subtyp av det här fallet är utveckling i en gemenskap eller i olika team, medan granskaren kanske inte är intresserad av denna specifika kod, på grund av laddning eller andra omständigheter, kanske inte uppmärksammar granskningsbegäran alls, och den externa skiljemannen (en chef gemensam för båda sidor) ) kanske inte existerar alls.

Det lösningssätt som hjälper i en sådan situation relaterar just till det långsiktiga perspektivet, en vuxens kultur. För det första fungerar smart aktivitet. Du ska inte förvänta dig att koden som hänger på recensionen kommer att dra till sig granskarens uppmärksamhet. Vi måste hjälpa granskarna att lägga märke till honom. Pingani ett par personer, ställ en fråga om syncape, delta i diskussioner. Uppenbarligen är det mer sannolikt att obehag skadar än hjälper, du måste använda sunt förnuft. För det andra fungerar förberedelserna bra. Om teamet förstår vad som händer och varför, varför den här koden överhuvudtaget behövs, designen har diskuterats och kommit överens om i förväg med alla, är det mer sannolikt att folk uppmärksammar sådan kod och accepterar den för arbetet. För det tredje, auktoritet fungerar. Om du vill bli recenserad, gör många recensioner själv. Gör recensioner av hög kvalitet, med riktiga kontroller, riktiga tester och användbara kommentarer. Om ditt smeknamn är välkänt i teamet är chansen större att din kod kommer att märkas.

Ur arbetsflödessynpunkt är möjliga förbättringar här korrekt prioritering som syftar till att hjälpa utvecklaren att nå sina och teamets mål (granska andra, skriva brev till communityn, åtfölja koden med en arkitekturbeskrivning, dokumentation, tester, delta i diskussioner med community, etc.), förhindra att patchar hänger i kön för länge, och så vidare.

2) Det andra vanliga fallet av konflikter under kod- eller designgranskningar är olika syn på tekniska frågor, kodningsstil och val av verktyg. Av stor betydelse i det här fallet är nivån av förtroende mellan deltagarna, att tillhöra samma team och erfarenhet av att arbeta tillsammans. En återvändsgränd uppstår när en av deltagarna intar en barnslig ställning och inte försöker höra vad samtalspartnern vill förmedla till honom. Ofta kan både det tillvägagångssätt som föreslagits av den andra parten och det inledningsvis föreslagna tillvägagångssättet fungera framgångsrikt och det spelar i princip ingen roll vilken man ska välja.

En dag förberedde en programmerare från mitt team (låt oss kalla honom Pasha) en patch med ändringar av paketdistributionssystemet, som utvecklades och stöddes av kollegor från en närliggande avdelning. En av dem (Igor) hade sin egen starka åsikt om exakt hur Linux-tjänster skulle konfigureras när paket distribueras. Denna åsikt skilde sig från det tillvägagångssätt som föreslagits i patchen, och de kunde inte hålla med. Som vanligt rann deadlines ut och det var nödvändigt att komma fram till något slags beslut, det var nödvändigt att en av dem tog en vuxenställning. Pasha insåg att båda tillvägagångssätten har rätt till liv, men han ville att hans alternativ skulle passera, eftersom Varken det ena eller det andra alternativet hade några uppenbara tekniska fördelar.

Vår diskussion såg ut ungefär så här (väldigt schematiskt pågick förstås samtalet i en halvtimme):

– Pasha, vi har en funktionsfrysning om några dagar. Det är viktigt att vi får ihop allt och börjar testa så snart som möjligt. Hur kan vi ta oss igenom Igor?
— Han vill ställa in tjänster på ett annat sätt, han fastnade kommentarer där åt mig...
- Och vad är det, stora förändringar, mycket väsen?
– Nej, det är arbete i ett par timmar, men i slutändan är det ingen skillnad, det kommer att fungera åt båda hållen, varför är detta nödvändigt? Jag gjorde något som fungerar, låt oss acceptera det.
- Lyssna, hur länge har ni diskuterat allt det här?
– Ja, vi har markerat tid i en och en halv vecka nu.
- Um... kan vi lösa ett problem på ett par timmar som redan har tagit en och en halv vecka, och inte göra det?
- Jo, ja, men jag vill inte att Igor ska tro att jag kastade mig...
- Lyssna, vad är viktigare för dig, att utfärda en frigivning, tillsammans med ditt beslut inuti, eller att döda Igor? Vi kan blockera det, då finns det dock en god chans att flyga igenom med releasen.
– Tja... det vore såklart coolt att torka Igors näsa, men okej, släppet är viktigare, jag håller med.
– Är det verkligen så viktigt för dig vad Igor tycker? För att vara ärlig bryr han sig inte alls, han vill bara ha ett enhetligt tillvägagångssätt på olika platser av saken som han är ansvarig för.
– Nåväl, ok, låt mig göra som han ber i kommentarerna och låt oss börja testa.
- Tack, Pasha! Jag var säker på att ni skulle vara den mer mogna av er två, även om Igorek är äldre än du :)

Problemet löstes, releasen släpptes i tid, Pasha kände inte mycket missnöje, eftersom han själv föreslog en lösning och genomförde den. Igor var allmänt nöjd, eftersom... Hans åsikt togs i beaktande och de gjorde som han föreslog.

En annan typ av i huvudsak samma konflikt är valet mellan tekniska lösningar/bibliotek/tillvägagångssätt i ett projekt, speciellt i ett distribuerat team. I ett av projekten, som positionerades som att använda C/C++, visade det sig att den tekniska förvaltningen av projektet var kategoriskt emot att använda STL (Standard Template Library). Detta är ett standardspråkbibliotek som förenklar utvecklingen, och vårt team är väldigt vana vid det. Det visade sig att projektet ligger mycket närmare C än C++, vilket inte inspirerade teamet särskilt mycket, eftersom ledningen gjorde sitt bästa och värvade riktigt coola plusspelare. Samtidigt hade den amerikanska delen av teamet, både ingenjörer och chefer, arbetat i företaget under lång tid, var vana vid det rådande läget och var nöjda med allt. Den ryska delen av laget samlades ganska nyligen, inom några veckor (inklusive jag). Den ryska delen av laget ville kategoriskt inte överge den vanliga inställningen till utveckling.

Ändlösa skriftliga diskussioner började mellan de två kontinenterna, brev på tre eller fyra skärmar flög fram och tillbaka, i grupputskick och personliga, från programmerare till programmerare och chefer. Som vanligt lästes brev av denna längd av ingen utom författarna och deras ivriga anhängare. Chattarna knarrade av spänning och skickade tankar på flera skärmar i olika riktningar angående de tekniska fördelarna med STL, hur väl testad den är, hur säker den är och i allmänhet hur underbart livet är med det och hur hemskt det är utan det. .

Allt detta varade ganska länge, tills jag till slut insåg att vi diskuterade de tekniska aspekterna av frågan, men problemet var i själva verket inte tekniskt. Problemet är inte fördelarna eller nackdelarna med STL eller svårigheten att arbeta utan det. Problemet är snarare organisatoriskt. Vi behövde bara förstå hur företaget vi arbetade för fungerade. Ingen av oss hade tidigare erfarenhet av att arbeta i ett sådant företag. Saken var den att efter att koden utvecklats och släppts i produktion, sköttes supporten av helt andra personer från andra team, från andra länder. Detta enorma ingenjörsteam på flera tiotusentals ingenjörer (totalt) hade bara råd med ett helt grundläggande minimum av tekniska medel, så att säga, ett minimum minimorum. Allt som gick utöver den tekniska standard som fastställdes i företaget fysiskt kunde inte stödjas i framtiden. Nivån på ett lag bestäms av nivån på dess svagaste medlemmar. Efter att vi förstått verklig motivation handlingar från den amerikanska delen av teamet togs denna fråga bort från agendan, och tillsammans utvecklade och släppte vi produkten framgångsrikt med de standarder som antagits av företaget. Brev och chattar i det här fallet fungerade inte bra, det krävdes flera resor och mycket personlig kommunikation för att komma fram till en gemensam nämnare.

Ur arbetsflödets synvinkel skulle det i just detta fall hjälpa att ha en beskrivning av de verktyg som används, krav på dem, restriktioner för att lägga till nya och motivering för sådana restriktioner. Sådana dokument motsvarar ungefär de som beskrivs i avsnitten Återanvändningsstrategi och utvecklingsmiljö i "Manager's Handbook for Software Development", utvecklad i NASA. Trots sin ålder beskriver den perfekt alla huvudaktiviteter och planeringsstadier av mjukvaruutveckling av detta slag. Att ha sådana här dokument gör det väldigt enkelt att diskutera vilka komponenter och tillvägagångssätt som kan användas i en produkt och varför.

Ur en kulturell synvinkel, uppenbarligen, med en mer mogen position, där parterna försöker höra och förstå den verkliga motivationen för sina kollegors handlingar och agerar utifrån projektets och teamets prioriteringar, och inte det personliga egot , skulle konflikten lösas lättare och snabbare.

I en annan konflikt kring valet av en teknisk lösning tog det mig också märkbart lång tid att förstå motivationen hos en av parterna (det var ett mycket ovanligt fall), men efter att motiveringen var klar var lösningen uppenbar.

Situationen är denna: en ny utvecklare dyker upp i ett team på cirka 20 personer, låt oss kalla honom Stas. På den tiden var vårt standardverktyg för kommunikation som ett team Skype. Som det visade sig senare var Stas ett stort fan av öppna standarder och programvara med öppen källkod, och använde endast verktyg och operativsystem vars källor var allmänt tillgängliga och som använde offentligt beskrivna protokoll. Skype är inte ett av dessa verktyg. Vi ägnade mycket tid åt att diskutera fördelarna och nackdelarna med detta tillvägagångssätt, försök att lansera analoger av Skype på olika operativsystem, Stas försök att övertyga teamet att byta till andra standarder, skriva till honom personligen via post, ringa honom personligen på telefon, köpa en andra dator till honom specifikt för Skype, etc. Slutligen insåg jag att detta problem i huvudsak inte är tekniskt eller organisatoriskt, det är snarare ideologiskt, till och med, kan man säga, religiöst (för Stas). Även om vi så småningom kopplade ihop Stas och Skype (vilket tog flera månader) skulle problemet uppstå igen på varje efterföljande instrument. Jag hade inga verkliga medel till mitt förfogande för att förändra Stas världsbild, och det fanns ingen anledning att försöka förändra världsbilden för ett team som fungerade perfekt i den här miljön. Personen och företaget var helt enkelt ortogonala i sin världsbild. I sådana situationer är en bra lösning organisatorisk. Vi flyttade över Stas till ett annat lag, där han var mer organisk.

Anledningen till denna konflikt är enligt min mening diskrepansen mellan den personliga kulturen hos en viss person (som har en stark åsikt som inte tillåter honom att kompromissa) och företagets kultur. I det här fallet är det förstås chefens fel. Det var till en början fel att ta honom på ett projekt av det här slaget. Stas flyttade så småningom till ett mjukvaruutvecklingsprojekt med öppen källkod och utmärkte sig där.

Ett bra exempel på en konflikt som orsakas av både utvecklarens barnsliga attityd och bristerna i arbetsprocessen är en situation där, i avsaknad av en definition av gjort, utvecklaren och QA-teamet har olika förväntningar på beredskapen av funktionen överförs till QA. Utvecklaren trodde att det räckte med att skriva koden och kasta funktionen över stängslet till QA – de skulle reda ut det där. En ganska mogen och erfaren programmerare, förresten, men det var hans interna tröskel för kvalitet. QA höll inte med om detta och krävde att visa och beskriva för dem vad han själv kontrollerat och krävde ett testmanus för dem. De hade haft problem med funktionalitet från den här utvecklaren tidigare och ville inte slösa bort sin tid igen. Förresten, de hade rätt - funktionen fungerade verkligen inte, han kontrollerade inte koden innan han skickade den till QA.

För att lösa situationen bad jag honom visa mig att allt verkligen fungerade (det fungerade inte, och han var tvungen att fixa det), vi pratade med teamet och med QA-definitionen av gjort (de klarade sig inte i skriver, eftersom vi inte ville göra processen för byråkratisk ), ja, vi skildes snart med denna specialist (till allmän lättnad).

Ur arbetsflödets synvinkel är möjliga förbättringar i det här fallet närvaron av en definition av gjort, krav på stöd för varje enhetsfunktion och integrationstester och en beskrivning av tester som utförts av utvecklaren. I ett av projekten mätte vi nivån av kodtäckning genom tester under CI och om täckningsnivån sjönk efter att ha lagt till en patch så markerades testerna som misslyckade, d.v.s. ny kod kunde bara läggas till om det fanns nya tester för den.

Ett annat typiskt exempel på en konflikt som är nära relaterad till organisationen av arbetsprocessen. Vi har en produkt, ett produktutvecklingsteam, ett supportteam och en kund. Kunden har problem med produkten och kontaktar support. Support analyserar problemet och förstår att problemet finns i produkten och överför problemet till produktteamet. Produktteamet är i en hektisk tid, en release närmar sig, så en biljett med ett problem från en kund, förlorad bland de andra biljetterna från utvecklaren som den är tilldelad, hänger i flera veckor utan uppmärksamhet. Support tycker att utvecklaren jobbar med kundens problem. Kunden väntar och hoppas att deras problem bearbetas. I verkligheten händer ingenting ännu. Efter några veckor bestämmer sig kunden äntligen för att intressera sig för framstegen och frågar support hur det går. Support efterfrågar utveckling. Utvecklaren ryser, tittar igenom listan över biljetter och hittar en biljett från kunden där. När han läser en biljett från en kund förstår han att det inte finns tillräckligt med information för att lösa problemet, och han behöver fler loggar och soptippar. Support begär ytterligare information från kunden. Och då inser kunden att ingen har jobbat med hans problem hela tiden. Och åskan kommer att slå...

I den här situationen är lösningen på själva konflikten ganska uppenbar och linjär (fixa produkten, uppdatera dokumentation och tester, blidka kunden, släppa en snabbkorrigering, etc.). Det är viktigt att analysera arbetsprocessen och förstå vem som är ansvarig för att organisera samspelet mellan de två teamen, och varför denna situation blev möjlig i första hand. Det är tydligt vad som behöver fixas i processen – någon måste övervaka helhetsbilden utan påminnelser från kunder, proaktivt. Biljetter från kunden ska sticka ut bland andra biljetter från utvecklare. Support bör se om utvecklingsteamet för närvarande arbetar med sina biljetter, och om inte, när det kan börja fungera och när resultat kan förväntas. Support och utveckling bör regelbundet kommunicera och diskutera status för biljetter, insamlingen av information som är nödvändig för felsökning bör automatiseras så mycket som möjligt, etc.

Precis som i krig försöker fienden träffa korsningen mellan två enheter, så i arbetet är den mest känsliga och sårbara punkten vanligtvis interaktionen mellan team. Om support- och utvecklingsansvariga är tillräckligt gamla kommer de att kunna fixa processen själva, om inte kommer processen att fortsätta generera konflikter och problem tills en chef ingriper som kan fixa situationen.

Ett annat typiskt exempel som jag har sett upprepade gånger i olika företag är en situation där en produkt skrivs av ett team, automatiska integrationstester för den skrivs av ett andra team, och infrastrukturen som allt drivs på åtföljs av en tredje team. Problem när man kör tester uppstår hela tiden och orsaken till problem i dem kan vara både produkten och testerna och infrastrukturen. Det är vanligtvis problematiskt att komma överens om vem som ska utföra den initiala analysen av problem, filbuggar, tolka loggar av produkten, tester och infrastruktur osv. Konflikter här är mycket frekventa, och samtidigt enhetliga. Vid hög emotionell intensitet hamnar deltagarna ofta i en barnslig position och diskussioner börjar i serien: "varför ska jag pyssla med det här", "de går sönder oftare" osv.

Ur ett arbetsflödesperspektiv beror de specifika stegen för att lösa ett problem på sammansättningen av teamen, typen av tester och produkt, etc. I ett av projekten införde vi periodisk tjänst, där teamen övervakade testerna en i taget, vecka för vecka. I den andra gjordes den initiala analysen alltid av testutvecklarna, men analysen var väldigt grundläggande och produkten var ganska stabil, så det fungerade bra. Nyckeln är att säkerställa att processen är transparent, att förväntningarna är tydliga för alla parter och att situationen känns rättvis för alla.

Är konflikter ens ett problem i en organisation? Är det ett dåligt tecken att konflikter ofta (eller bara periodvis) uppstår i ditt team? Generellt nej, för om det finns tillväxt, utveckling, finns det någon form av dynamik, då uppstår frågor som aldrig tidigare har lösts, och när man löser dem kan konflikter uppstå. Detta är en indikator på att vissa områden behöver uppmärksammas, att det finns områden att förbättra. Det är dåligt om konflikter uppstår väldigt ofta, är svåra att lösa eller tar lång tid. Detta är med största sannolikhet ett tecken på otillräckligt strömlinjeformade arbetsprocesser och otillräcklig mognad hos teamet.

Källa: will.com