Konflikthantering i team – balansakt eller livsnödvändighet?

Epigraf:
En gång möttes Igelkotten och Nalle i skogen.
— Hej, Igelkott!
— Hej, Nalle!
Så, ord för ord, skämt för skämt, fick Igelkotten en känga av Nalle ...

Under texten följer tankar från vår teamledare och produktutvecklingschef RAS — Igor Marnat om arbetskonflikters specifika natur och möjliga hanteringsmetoder.

De flesta konflikter vi stöter på på jobbet följer ett mönster som liknar det som beskrivs ovan i epigrafen. Det finns flera deltagare, som från början är inställda på varandra vänligt, de försöker lösa en viss fråga, men i slutändan förblir problemet olöst och relationerna mellan diskussionsdeltagarna blir av någon anledning försämrade.

Livets mångfald innebär att det finns variationer i det beskrivna scenariot. Ibland är relationerna mellan deltagarna inte särskilt bra från början, ibland finns det inte ens en specifik fråga som kräver omedelbar lösning (som i epigrafen), ibland förblir relationerna oförändrade även efter diskussionen, men frågan blir ändå inte löst.

Vad har då alla situationer som kan definieras som arbetskonflikter gemensamt?



För det första involverar det två eller fler parter. Dessa parter kan befinna sig på olika nivåer inom organisationen, ha en jämlik relation (kollegor i ett team), eller vara på olika hierarkiska nivåer (chef — anställd), vara individuella (anställd) eller gruppbaserade (vid konflikter mellan en anställd och ett team eller mellan två team), och så vidare. Nivån av förtroende mellan deltagarna påverkar starkt sannolikheten för konflikt och hur lätt den kan lösas. Ju bättre parterna känner varandra och ju högre nivå av förtroende, desto större chans att de kommer överens. Till exempel är anställda i ett distribuerat team som aldrig träffats personligen mer benägna att hamna i konflikt vid lösningen av en enkel arbetsfråga än personer som har träffats personligen åtminstone några gånger. Därför är det mycket viktigt att säkerställa regelbundna personliga möten för alla teammedlemmar i distribuerade team.

För det andra, i en konfliktsituation på jobbet befinner sig parterna i en situation där de måste lösa en fråga som är viktig för någon av parterna, för dem båda eller för organisationen som helhet. I och med situationens karaktär har parterna vanligtvis tillräckligt med tid och olika metoder för att lösa den (formella, informella, möten, brev, beslutsfattande från ledning, teamets mål och planer, förekomsten av en hierarki, etc.). Detta skiljer sig från situationer där man löser en arbetsrelaterad (eller icke-arbetsrelaterad) fråga i organisationen, till exempel att ställa den viktiga frågan: “Hej, grabben, vilket område kommer du ifrån?!” på gatan, eller konflikten i epigrafen. Vid lösningen av en arbetsfråga är kvaliteten på arbetsprocessen och kulturen för hur frågor löses i teamet av betydelse.

För det tredje är en avgörande faktor för konflikten (sett utifrån vårt diskussion) det faktum att parterna i processen inte kan komma fram till en lösning som är acceptabel för alla parter på egen hand. Situationen kräver ett ingripande från en tredje part, en extern medlare. Denna punkt kan tyckas kontroversiell, men om en konflikt har lösts framgångsrikt utan ingripande av en extern medlare, har frågan lösts framgångsrikt utan att relationerna mellan parterna försämrats. Detta är en situation vi troligen inte ens får höra talas om, eller får veta om av en slump efter att den har lösts. Ju fler frågor ett team kan lösa på egen hand, desto mer effektivt kommer det att arbeta.

En annan karakteristisk egenskap hos konflikten som är värt att beröra är graden av emotionell intensitet vid lösningen. Konflikten är inte nödvändigtvis kopplad till hög emotionell temperatur. Deltagarna behöver inte nödvändigtvis skrika och vifta med armarna för att situationen faktiskt ska vara konfliktfylld. Om en fråga inte löses och en viss emotionell spänning är närvarande (även om den kanske inte uttrycks tydligt utåt), innebär det att vi har att göra med en konfliktsituation.

Bör man verkligen ingripa i konfliktiska situationer, eller är det bättre att låta dem lösa sig själva och vänta på att problemet ska försvinna? Ja. Det är inte alltid inom din makt eller kompetens att helt lösa en konflikt, men i varje situation, i en konflikt av vilken storlek som helst, kan du inta en vuxen position, vilket i sin tur kan dra in några fler personer omkring dig, mildra de negativa konsekvenserna av konflikten och bidra till dess lösning.

Innan vi går igenom några exempel på konfliktiska situationer, låt oss stanna vid några viktiga punkter som är gemensamma för alla konflikter.

När man löser en konflikt är det viktigt att vara över striden, istället för att vara mitt i den (detta kallas ibland att "inta en metaposition"), det vill säga att inte vara en del av beslutsprocessen för någon av sidorna. Annars, från att vara en extern medlare som hjälper till med lösningen, kommer du bara att stärka en parts position på bekostnad av den andra. Vid beslutsfattande är det viktigt att beslutet accepteras moraliskt av alla parter, som det heter, "köpt". Så, även om parterna inte är entusiastiska över det beslut som fattats, bör de åtminstone vara uppriktigt överens om att följa det. Som man säger, vara i stånd att vara oense men ändå förpliktad. Annars kommer konflikten bara att förändras; den glödande elden kommer att förbli under torven och vid något tillfälle ofrånkomligt blossa upp igen.

Den andra punkten, som delvis är relaterad till den första, är att om du har bestämt dig för att delta i lösningen av konflikten, så bör du ta det på största allvar när det kommer till kommunikation och att förstå kontexten. Prata personligen med varje part. Separat med varje part, till att börja med. Nöj dig inte med e-post. Vid distribuerade team — prata åtminstone via videokonferens. Nöj dig inte med rykten och återsagor från vittnen. Förstå historien, vad varje part vill, varför de vill ha det, vad de förväntar sig, om de har försökt lösa frågan tidigare, vad som kommer att hända om den inte löses, vilka lösningar de ser, hur de uppfattar den andra partens position, vad de anser är rätt eller fel, osv. Ladda ner all möjlig kontext i ditt huvud, opartiskt, med antagandet att alla har sina skäl. Du är inte inne i konflikten, du är utanför den, i en meta-position. Om kontexten endast är tillgänglig i en e-posttråd — läs då hela den och relaterade diskussionstrådar och dokument. Efter att du har läst — prata ändå i telefon. Nästan garanterat kommer du att höra något viktigt som inte finns i e-posten.

Den tredje viktiga punkten handlar om det övergripande tillvägagångssättet i kommunikationen. Det är vanliga saker, inget utöver det vanliga, men de har stor betydelse. Försök inte spara tid, prata med alla deltagare, kritisera inte personen, utan betrakta konsekvenserna av deras handlingar (inte "du är oförskämd", utan "kanske kan folk bli sårade av det här"). Ge möjlighet till att behålla sina ansikten, ha diskussioner personligen och inte framför kören.

Konflikter orsakas vanligtvis av en av två anledningar. Den första har att göra med huruvida en person i konflikten befinner sig i en vuxens position eller ett barns position (mer om detta nedan). Det handlar om deras emotionella mognad, förmåga att hantera sina känslor (vilket för övrigt inte alltid är kopplat till deras ålder). Den andra vanliga orsaken är brister i arbetsprocessen, vilket skapar gråzoner där ansvaret är otydligt mellan deltagarna, och parternas förväntningar är inte tydliga för varandra, rollerna i processen är otydliga.

I konflikthantering (liksom i alla andra frågor) måste chefen ha i åtanke tre perspektiv: det kortsiktiga – att lösa frågan/konflikten här och nu, det medellånga – att minska risken för att en liknande konflikt uppstår igen, och det långsiktiga – att odla en vuxen kultur i teamet.

Inom oss alla finns ett inre barn, ungefär tre till fyra år gammalt. Det mesta av tiden på jobbet sover det, men ibland vaknar det och tar över. Barnet har sina egna prioriteringar. Det är viktigt för det att hävda att detta är dess sandlåda, att mamma älskar det mer, att dess leksak är bäst (designen är överlägsen, det programmerar bättre än alla andra, …). I konfliktens stund kan barnet krama sina leksaker, stampa med fötterna och slå med en spade, men det kan inte lösa vuxna frågor (designarkitektur, metoder för automatisk testning, tidsplaner för release, osv.), det tänker inte i termer av nytta för teamet. Man kan uppmuntra, trösta och skicka barnet att sova, och be det kalla på sin vuxna. Innan en diskussion i konfliktens kontext börjar, se till att du pratar med den vuxna och inte med barnet, och stå själv på den vuxnas sida. Om ditt äkta mål just nu är att lösa en allvarlig fråga, är du på den vuxna människans position. Om ditt mål är att stampa och slå med en spade – är det en barnslig position. Skicka ditt inre barn att sova och kalla på den vuxna, eller skjuta upp diskussionen. En människa fattar ett känslomässigt beslut och letar sedan efter en rationell motivering. Ett beslut som fattas av barnet, baserat på barnets prioriteringar, kommer inte att vara optimalt.

Förutom beteendet vid en konflikt, karakteriseras en barns eller vuxens position också av den nivå av ansvar som personen är beredd att ta på sig. I extrema fall kan en programmerares barnsliga position, som jag har stött på flera gånger, se ut så här: jag har skrivit koden, skickat den för granskning – mitt arbete är klart. Granskarna ska se över den och slå samman den, QA ska kontrollera den, om det finns problem – de meddelar mig. Rent märkligt, även ganska vuxna och erfarna människor beter sig ibland på detta sätt. I den andra änden av skalan anser en person sig ansvarig för att hans kod fungerar, är täckt av tester, har kontrollerats av honom personligen, har framgångsrikt klarat granskningen (om det behövs, inget problem att pingla granskarna, diskutera frågor muntligt, osv.) och har blivit sammanfogad, QA kommer att få hjälp vid behov, testscenarier kommer att dokumenteras, osv. I normala fall befinner sig programmeraren antingen närmare den vuxna änden av skalan från början, eller rör sig dit allteftersom hen får mer erfarenhet (förutsatt att den rätta kulturen odlas i teamet). I extrema fall fortsätter hen att arbeta, oftast med en barnslig position, vilket leder till att hen och teamet periodiskt får problem och konflikter.

Att skapa en korrekt och vuxen kultur i teamet är en viktig uppgift för varje chef. Det kräver lång tid och dagliga ansträngningar, men resultatet är värt det. Det finns två sätt att påverka teamkulturen – genom personlig exempel (som andra kommer att följa, teamet ser alltid på ledaren) och genom att diskutera och uppmuntra korrekt beteende. Här finns det inget mystiskt eller väldigt formellt, bara när man diskuterar problem, notera vad man kunde ha gjort på ett annat sätt, understryka när något har lösts korrekt, beröm, och markera detta vid analyser av releaser, osv.

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

Konflikter som inte rör arbetsfrågor

Det händer ganska ofta att det uppstår konflikter på jobbet som inte rör arbetsfrågor. Deras uppkomst och lätthet att lösa är vanligtvis direkt kopplad till nivån av emotionell intelligens hos deltagarna, deras nivå av vuxenhet, och har ingen koppling till arbetsprocessens felfrihet eller ofullkomlighet.

Typiska exempel är att någon inte använder tvättmaskinen eller duschen tillräckligt ofta, vilket irriterar andra, någon tycker att det är kvavt medan en annan vill ha fönstret öppet för luft, någon är för högljudd medan andra behöver tystnad för att arbeta, och så vidare. Det är bäst att inte dra ut på konflikter av denna sort och inte låta dem utvecklas fritt. De kommer inte att lösa sig själva och kommer dagligen att distrahera från arbetet och förstöra stämningen i teamet. Lyckligtvis brukar det inte vara stora problem att lösa dem — det räcker ofta med att lugnt prata (såklart en och en) med en kollega som försummar hygien, säkerställa bekväm placering av personer som föredrar tystnad/kylighet, köpa ljuddämpande hörlurar eller sätta upp skärmar, etc.

Ett annat exempel som jag stött på flera gånger under min karriär är psykisk inkompatibilitet bland teammedlemmar. Av någon anledning kan vissa personer helt enkelt inte arbeta tillsammans, varje kommunikation slutar i bråk. Ibland beror detta på att människor har helt olika åsikter om en brännande fråga (vanligtvis politisk) och inte kan lämna dessa bakom sig på jobbet. Att försöka övertyga dem att tolerera varandra eller ändra sitt beteende är oftast en meningslös sysselsättning. Det enda undantaget jag har stött på är unga kollegor med en öppen inställning, deras beteende kan fortfarande gradvis ändras genom periodiska samtal. Vanligtvis löses frågan framgångsrikt genom att dela upp dem i olika team, eller åtminstone ge möjlighet att sällan korsa varandras vägar på jobbet.

I alla ovan nämnda situationer är det viktigt att prata med alla deltagare individuellt, diskutera situationen, fråga om de överhuvudtaget ser ett problem i detta fall, och fråga vilka lösningar de anser är möjliga, samt säkerställa deras delaktighet i beslutsprocessen.

Ur ett arbetsprocessoptimeringsperspektiv (medeldistans som jag nämnde), finns det inte mycket som kan göras på denna punkt, den enda möjligheten till optimering är att ta hänsyn till kompatibilitetsfaktorn vid team's bildande och i förväg undvika att sätta ihop personer som kommer att skapa konflikter.

Ur ett teamkultursperspektiv uppstår sådana situationer mycket sällan i team med en mogen kultur, där folk respekterar teamet och kollegorna och kan lösa frågor på egen hand. Dessutom löses sådana konflikter mycket enklare (ofta automatiskt) i team där tilliten är hög, folk har arbetat tillsammans länge och/eller ofta kommunicerar utanför arbetet.

Konflikter relaterade till arbetsfrågor:

Sådana konflikter orsakas vanligtvis av båda anledningarna samtidigt, både emotionell (det faktum att någon av deltagarna inte är i en vuxen roll) och ofullkomligheten i själva arbetsprocessen. Den vanligaste typen av konflikter som jag har stött på är konflikter i processen av kodgranskning eller arkitekturdiskussioner mellan utvecklarna.

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

1) I det första fallet kan utvecklaren inte få kodgranskning av en kollega. Patchen har skickats för granskning, och ingenting händer. Vid första anblick verkar det inte finnas något uppenbart konflikt mellan de två sidorna, men om man tänker efter är detta helt klart en konflikt. Arbetsfrågan löses inte, en av sidorna (den som väntar på granskning) upplever tydlig obehag. En extrem underkategori av detta fall är utveckling i communityn eller i olika team, där granskaren kan vara ointresserad av just den specifika koden, och på grund av arbetsbelastning eller andra omständigheter kan helt enkelt ignorera begäran om granskning, och en extern domare (gemensam för båda parter, en manager) kanske överhuvudtaget inte finns.

Tillvägagångssättet för att lösa sådana situationer relaterar till långsiktig perspektiv och en vuxen människas kultur. För det första fungerar rimlig aktivitet. Man bör inte förvänta sig att kod som hänger i granskning automatiskt får uppmärksamhet från granskaren. Det är nödvändigt att hjälpa granskare att se den. Ping-a några personer, ställ en fråga på svaret, delta i diskussioner. Det är uppenbart att att vara påträngande snarare skadar än hjälper, så sunt förnuft måste användas. För det andra fungerar förberedelser mycket bra. Om teamet förstår vad som händer och varför, varför denna kod överhuvudtaget behövs, designen har diskuterats och godkänts i förväg av alla, kommer människor att vara mer benägna att uppmärksamma sådan kod och ta den i bruk. För det tredje fungerar auktoritet. Om du vill att andra ska granska din kod – granska mycket själv. Gör kvalitetsgranskningar, med verkliga verifieringar, verkliga tester, användbara kommentarer. Om ditt nick är känt i teamet på ett bra sätt, ökar chansen att din kod får uppmärksamhet.

Ur ett arbetsprocessperspektiv kan möjliga förbättringar här vara att sätta rätt prioriteringar, inriktade på att hjälpa utvecklaren att nå sina och teamets mål (granska andras kod, skriva inlägg i communityn, stödja koden med arkitekturbeskrivningar, dokumentation, tester, delta i diskussioner med communityn, etc.), förhindra att patchar fastnar för länge i kön, och så vidare.

2) Det andra vanliga fallet av konflikter vid kod- eller designgranskning är olika uppfattningar om tekniska frågor, kodningsstil, val av verktyg. Den nivå av förtroende som finns mellan deltagarna, tillhörigheten till samma team och erfarenheten av att arbeta tillsammans har stor betydelse i detta avseende. En återvändsgränd uppstår när någon av deltagarna intar en barnslig position och inte försöker höra vad den andra vill förmedla. Ofta kan den föreslagna ansatsen från den andra sidan och den ansats som ursprungligen föreslogs, båda fungera framgångsrikt och det har ingen avgörande betydelse vilken som väljs.

En gång förberedde en programmerare i mitt team (låt oss kalla honom Pasha) en patch med ändringar i systemet för paketdistribution som utvecklades och underhölls av kollegor från en annan avdelning. En av dem (Igor) hade en stark åsikt om hur Linux-tjänster skulle konfigureras vid distributionen av paket. Denna åsikt skilde sig från den metod som föreslogs i patchen, och de kunde inte komma överens. Som vanligt var tidsfristen knapp, och vi behövde nå ett beslut; någon av dem behövde ta en vuxen roll. Pasha erkände att båda metoderna hade sin plats, men han ville att hans alternativ skulle gå igenom eftersom det inte fanns några tydliga tekniska fördelar med något av alternativen.

Vår diskussion såg ungefär ut så här (mycket schematiskt, självklart, samtalet varade i en halv timme):

— Pasha, vi har feature freeze om några dagar. Det är viktigt att vi får allt klart och påbörjar testningen så snabbt som möjligt. Hur ska vi ta oss förbi Igor?
— Han vill konfigurera tjänsterna på ett annat sätt, han har klistrat in kommentarer till mig ...
— Och vadå, stora förändringar, mycket arbete?
— Nej, det tar bara ett par timmar, men slutresultatet blir ju detsamma, det kommer att fungera ändå, varför göra detta? Jag har gjort något som fungerar, låt oss godkänna det.
— Hör du, hur länge har ni diskuterat detta?
— Vi har stått still i nästan en och en halv vecka.
— Eh ... kan vi lösa frågan som redan tagit en och en halv vecka på bara ett par timmar, och gör inte det?
— Ja, men jag vill inte att Igor ska tro att jag vikit mig ...
— Hör du, vad är viktigast för dig, att få ut releasen med din lösning inuti, eller att slå ner Igor? Vi kan slå ner honom, men då finns det en bra chans att vi missar releasen.
— Tja ... det skulle ju vara kul att få Igor på fall, men visst, releasen är viktigare, jag går med på det.
— Är det verkligen så viktigt för dig vad Igor tycker? Ärligt talat, han bryr sig överhuvudtaget inte, han vill bara ha en enhetlig metod i olika delar av den grej han ansvarar för.
— Okej, låt mig göra som han ber i kommentarerna, så börjar vi testningen.
— Tack, Pasha! Jag var säker på att av er två skulle du visa dig vara den mer mogna, även om Igor är äldre än du :)

Frågan löstes, releasen släpptes i tid, Pasha kände inget särskilt missnöje eftersom han själv föreslog lösningen och genomförde den. Igor var överlag nöjd, eftersom hans åsikter beaktades och de gjorde det som han föreslog.

En annan typ av samma konflikt handlar om valet mellan tekniska lösningar/bibliotek/metoder i ett projekt, särskilt i ett distribuerat team. I ett projekt som positionerades som ett som använde C/C++, visade det sig till slut att den tekniska ledningen var kategoriskt emot användningen av STL (Standard Template Library). Detta är ett standardbibliotek för språket som förenklar utvecklingen, och vårt team var mycket vana vid det. Det visade sig att projektet var mycket närmare C än C++, vilket inte inspirerade teamet, eftersom ledningen gjorde en insats och anställde riktigt duktiga C++-utvecklare. Samtidigt hade den amerikanska delen av teamet, både ingenjörer och chefer, arbetat i företaget länge och var vana vid den nuvarande situationen; de var nöjda med det. Den ryska delen av teamet samlades däremot på kort tid, inom några veckor (inklusive mig). Den ryska delen av teamet ville kategoriskt inte ge upp det vanliga tillvägagångssättet för utveckling.

Oändliga skriftliga diskussioner började mellan två kontinenter, med meddelanden på tre till fyra skärmar som flög fram och tillbaka, i grupputskick och personligt, från programmerare till programmerare och chefer. Som det ofta är, läste ingen, förutom författarna och deras entusiastiska supportrar, meddelanden av den storleken. Chattarna knakade av spänning och skickade fram och tillbaka många skärmstora överväganden kring tekniska fördelar med STL, hur väl testad och säker den är, och hur underbart livet är med den och hur hemskt det är utan.

Det här pågick ganska länge, tills jag till slut insåg att vi diskuterade de tekniska aspekterna av frågan, men problemet var i realiteten inte tekniskt. Problemet handlar inte om fördelarna eller nackdelarna med STL eller svårigheten att arbeta utan den. Problemen var snarare organisatoriska. Vi behövde bara förstå hur företaget som vi arbetade på var organiserat. Ingen av oss hade tidigare erfarenhet av att jobba i ett sådant företag. Problemet var att efter att ha utvecklat koden och släppt den i produktion, var det helt andra personer från andra team, från andra länder, som skötte underhållet. Detta enorma ingenjörsteam med flera tiotusentals ingenjörer (totalt) hade bara råd med det mest grundläggande tekniska minimum, så att säga, minimum minimorum. Allt som gick utöver det ingenjörsstandard som fanns i företaget kunde fysiskt sett inte stödjas i framtiden. Nivån på teamet definieras av nivåerna hos de svagaste medlemmarna. Efter att vi insåg den verkliga motivationen för den amerikanska delen av teamet, togs denna fråga bort från agendan och vi utvecklade och släppte framgångsrikt produkten tillsammans, där vi använde de standarder som antagits i företaget. I detta fall fungerade e-post och chattar dåligt, och för att nå en gemensam grund krävdes flera resor och mycket personlig kommunikation.

Ur arbetsprocessens perspektiv skulle det i det här specifika fallet ha varit till hjälp att ha en beskrivning av de verktyg som användes, kraven på dem, begränsningar för att lägga till nya och en motivering för dessa begränsningar. Sådana dokument motsvarar ungefär de som beskrivs i punkterna Reuse Strategy och Development Environment i handboken “Manager’s Handbook for Software Development”, som utvecklades i NASA. Trots sin ålder beskriver den utmärkt alla huvudsakliga aktiviteter och steg i planeringen av programvaruutveckling av denna typ. Tillägget av sådana dokument förenklar diskussionen om vilka komponenter och metoder som kan användas i produkten och varför.

När det gäller kulturen är det uppenbart att med en mer mogen inställning, där parterna försöker höra och förstå den verkliga motivationen bakom kollegornas agerande och agera utifrån projektets och teamets prioriteringar snarare än personligt ego, skulle konflikten ha lösts enklare och snabbare.

I ett annat fall där valet av teknisk lösning orsakade en konflikt tog det mig också lång tid att förstå motivationen hos en av parterna (fallet var verkligen ovanligt), men när motivationen väl var klar blev beslutet uppenbart.

Situationer är som följer: I ett team med ungefär 20 personer dyker en ny utvecklare upp, låt oss kalla honom Stas. Vårt standardkommunikationsverktyg i teamet var då Skype. Som visade sig senare var Stas en stor fan av öppna standarder och öppen källkod, och han använde endast verktyg och operativsystem vars källkod fanns tillgänglig offentligt och som använde offentligt beskriva protokoll. Skype tillhörde inte dessa verktyg. Vi spenderade en stor mängd tid på att diskutera för- och nackdelar med detta tillvägagångssätt, försöka starta alternativ till Skype på olika operativsystem, försöka övertyga Stas att teamet skulle byta till andra standarder, skriva till honom personligen via e-post, ringa honom personligen via telefon, köpa honom en andra dator speciellt för Skype, etc. Till slut insåg jag att detta problem i grunden inte var tekniskt eller organisatoriskt, det var mer av en ideologisk fråga, man kan till och med säga en religiös fråga (för Stas). Även om vi slutligen kopplade ihop Stas med Skype (vilket stod oss dyrt flera månader), skulle problemet uppstå igen med vilket annat verktyg som helst. Jag hade ingen verklig möjlighet att ändra Stas värdegrund, och det fanns ingen grund för att försöka förändra teamets värdegrund, som fungerade utmärkt i denna miljö. Människor och företag var helt enkelt orthogonala i sina värderingar. I sådana situationer är en bra lösning oftast organisatorisk. Vi flyttade Stas till ett annat team där han var mer i sitt rätta element.

Anledningen till denna konflikt, enligt min mening, ligger i diskrepansen mellan den personliga kulturen hos en specifik person (som har en stark åsikt som hindrar honom från att kompromissa) och företagets kultur. I detta fall är det givetvis ett misstag från ledarens sida. Det var fel från början att anställa honom för ett projekt av denna typ. Stas övergick till ett projekt inom öppen källkod och trivs utmärkt där.

Ett bra exempel på en konflikt som orsakats av både utvecklarens barnsliga inställning och brister i arbetsprocessen är en situation där utvecklaren och QA-teamet har olika förväntningar om färdigställandet av en funktion som skickats till QA, i avsaknad av en definition av klart. Utvecklaren trodde att det var tillräckligt att skriva koden och släppa över funktionen till QA — där skulle de fixa det. Han var för övrigt en ganska vuxen och erfaren programmerare, men han hade en låg inre kvalitetsstandard. QA var inte nöjda med detta och krävde att han skulle visa och beskriva för dem vad han själv hade kontrollerat, samt de ville ha ett testscenario. De hade tidigare haft problem med funktionalitet från denna utvecklare och ville inte slösa sin tid igen. För övrigt hade de rätt — funktionen fungerade faktiskt inte, koden hade han inte kontrollerat innan den skickades till QA.

För att lösa situationen bad jag honom visa mig att allt verkligen fungerade (det gjorde det inte, och han fick åtgärda det), vi diskuterade definitionen av klart med teamet och QA (vi gjorde den inte skriftlig eftersom vi inte ville byråkratisera processen för mycket), och snart skildes vi från denna specialist (till allas lättnad).

När det gäller arbetsprocessen är möjliga förbättringar i detta fall att ha en definition av klart, krav på att varje funktion ska ha enhetliga och integrerade tester, samt en beskrivning av testerna som genomförts av utvecklaren. I ett av projekten mätte vi testtäckningen av koden under CI och om täckningsgraden sjönk efter att en patch lades till, märktes testerna som misslyckade, det vill säga, endast ny kod kunde läggas till om det fanns nya tester för den.

Ännu ett typiskt exempel på en konflikt som är nära kopplad till organisationen av arbetsprocessen. Vi har en produkt, ett utvecklingsteam för denna produkt, en supportteam och en kund. Kunden får problem med produkten och vänder sig till supporten. Supporten analyserar problemet och inser att problemet ligger i produkten, de överlämnar problemet till produktteamet. Produktteamet har en hektisk period, utgivningen närmar sig, så ärendet med kundens problem, som hamnat bland de andra ärendena hos utvecklaren, som det är tilldelat, hänger utan uppmärksamhet i flera veckor. Supporten tror att utvecklaren arbetar med kundens problem. Kunden väntar och hoppas att deras problem hanteras. I verkligheten händer det ingenting. Några veckor senare bestämmer sig kunden äntligen för att kolla upp framstegen och frågar supporten hur det går. Supporten frågar utvecklingen. Utvecklaren rycker till, går igenom listan med ärenden och upptäcker ärendet från kunden. Genom att läsa kundens ärende förstår han att informationen som behövs för att lösa problemet är otillräcklig och att han behöver fler loggar och dumpningar. Supporten begär ytterligare information från kunden. Och här inser kunden att ingen har arbetat med deras problem under hela denna tid. Och åskan kommer att slå ...

I denna situation är lösningen av själva konflikten ganska uppenbar och linjär (att fixa produkten, uppdatera dokumentationen och testerna, lugna kunden, släppa en hotfix, etc.). Det är viktigt att analysera arbetsprocessen och förstå vem som ansvarar för att organisera samarbetet mellan de två teamen, varför en sådan situation ens blev möjlig. Det är uppenbart att något måste åtgärdas i processen — någon måste övervaka den övergripande bilden utan påminnelser från kunderna, proaktivt. Ärenden från kunden bör särskiljas bland de andra ärendena hos utvecklarna. Supporten bör se om utvecklingen arbetar med deras ärenden just nu, och om inte — när de kan börja arbeta, när ett resultat kan förväntas. Supporten och utvecklingen bör regelbundet kommunicera och diskutera statusen för ärendena, insamlingen av den information som behövs för felsökning bör automatiseras så mycket som möjligt, osv.

Precis som hur en fiende på krig försöker slå mot skarven mellan två enheter, visar det sig också att den mest känsliga och sårbara punkten i arbetet ofta är interaktionen mellan teamen. Om support- och utvecklingscheferna är tillräckligt erfarna kan de själva åtgärda processen; om inte, kommer processen fortsatt att skapa konflikter och problem tills en chef träder in för att lösa situationen.

Ett annat karakteristiskt exempel som jag ofta har stött på i olika företag är en situation där produkten utvecklas av ett team, de automatiska integrations testerna av ett annat team, och den infrastruktur där allt detta körs underhålls av ett tredje team. Problem under testkörningarna uppstår ständigt, och orsaken till problemen kan ligga antingen i produkten, testerna eller infrastrukturen. Det är ofta problematiskt att enas om vem som ska utföra den initiala problemanalysen, rapportera buggar, bearbeta loggar från produkten, testerna och infrastrukturen, etc. Konflikter här är ganska frekventa och samtidigt enhetliga. Vid hög känslomässig intensitet faller deltagarna ofta tillbaka i en barnslig position, med diskussioner av typen: 'varför ska jag bry mig om det här?', 'de har oftare problem', osv.

Ur arbetsprocessens perspektiv beror de specifika stegen för att lösa frågan på teamens sammansättning, typen av tester och produkten, osv. I ett av projekten införde vi periodiska vakter där teamen turades om att övervaka testerna under en vecka. I ett annat projekt utfördes alltid den initiala analysen av testutvecklarna, men denna analys var ganska grundläggande och produkten var tillräckligt stabil, så det fungerade ganska bra. Det viktiga är att säkerställa processens transparens, tydlighet i förväntningarna för alla parter och en känsla av rättvisa i situationen för alla.

Är konflikter inom organisationen ett problem, eller är det ett dåligt tecken att det ofta (eller till och med periodiskt) uppstår konflikter i ditt team? I stort sett nej, eftersom när det sker tillväxt, utveckling och dynamik, uppstår frågor som tidigare aldrig har lösts, vilket kan leda till konflikter. Det är en indikator på att vissa områden behöver uppmärksammas och att det finns utrymme för förbättringar. Det är dåligt om konflikter uppstår för ofta, är svåra eller tar lång tid att lösa. Detta är sannolikt ett tecken på otillräckligt utvecklade arbetsprocesser och en bristande mognad i teamet.

Källa: habr.com