<\/a><\/noindex>F\u00f6r det andra, i en konfliktsituation p\u00e5 jobbet befinner sig parterna i en situation d\u00e4r de m\u00e5ste l\u00f6sa en fr\u00e5ga som \u00e4r viktig f\u00f6r n\u00e5gon av parterna, f\u00f6r dem b\u00e5da eller f\u00f6r organisationen som helhet. I och med situationens karakt\u00e4r har parterna vanligtvis tillr\u00e4ckligt med tid och olika metoder f\u00f6r att l\u00f6sa den (formella, informella, m\u00f6ten, brev, beslutsfattande fr\u00e5n ledning, teamets m\u00e5l och planer, f\u00f6rekomsten av en hierarki, etc.). Detta skiljer sig fr\u00e5n situationer d\u00e4r man l\u00f6ser en arbetsrelaterad (eller icke-arbetsrelaterad) fr\u00e5ga i organisationen, till exempel att st\u00e4lla den viktiga fr\u00e5gan: \u201cHej, grabben, vilket omr\u00e5de kommer du ifr\u00e5n?!\u201d p\u00e5 gatan, eller konflikten i epigrafen. Vid l\u00f6sningen av en arbetsfr\u00e5ga \u00e4r kvaliteten p\u00e5 arbetsprocessen och kulturen f\u00f6r hur fr\u00e5gor l\u00f6ses i teamet av betydelse.<\/p>\n
F\u00f6r det tredje \u00e4r en avg\u00f6rande faktor f\u00f6r konflikten (sett utifr\u00e5n v\u00e5rt diskussion) det faktum att parterna i processen inte kan komma fram till en l\u00f6sning som \u00e4r acceptabel f\u00f6r alla parter p\u00e5 egen hand. Situationen kr\u00e4ver ett ingripande fr\u00e5n en tredje part, en extern medlare. Denna punkt kan tyckas kontroversiell, men om en konflikt har l\u00f6sts framg\u00e5ngsrikt utan ingripande av en extern medlare, har fr\u00e5gan l\u00f6sts framg\u00e5ngsrikt utan att relationerna mellan parterna f\u00f6rs\u00e4mrats. Detta \u00e4r en situation vi troligen inte ens f\u00e5r h\u00f6ra talas om, eller f\u00e5r veta om av en slump efter att den har l\u00f6sts. Ju fler fr\u00e5gor ett team kan l\u00f6sa p\u00e5 egen hand, desto mer effektivt kommer det att arbeta.<\/p>\n
En annan karakteristisk egenskap hos konflikten som \u00e4r v\u00e4rt att ber\u00f6ra \u00e4r graden av emotionell intensitet vid l\u00f6sningen. Konflikten \u00e4r inte n\u00f6dv\u00e4ndigtvis kopplad till h\u00f6g emotionell temperatur. Deltagarna beh\u00f6ver inte n\u00f6dv\u00e4ndigtvis skrika och vifta med armarna f\u00f6r att situationen faktiskt ska vara konfliktfylld. Om en fr\u00e5ga inte l\u00f6ses och en viss emotionell sp\u00e4nning \u00e4r n\u00e4rvarande (\u00e4ven om den kanske inte uttrycks tydligt ut\u00e5t), inneb\u00e4r det att vi har att g\u00f6ra med en konfliktsituation.<\/p>\n
B\u00f6r man verkligen ingripa i konfliktiska situationer, eller \u00e4r det b\u00e4ttre att l\u00e5ta dem l\u00f6sa sig sj\u00e4lva och v\u00e4nta p\u00e5 att problemet ska f\u00f6rsvinna? Ja. Det \u00e4r inte alltid inom din makt eller kompetens att helt l\u00f6sa 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\u00e5gra fler personer omkring dig, mildra de negativa konsekvenserna av konflikten och bidra till dess l\u00f6sning.<\/p>\n
Innan vi g\u00e5r igenom n\u00e5gra exempel p\u00e5 konfliktiska situationer, l\u00e5t oss stanna vid n\u00e5gra viktiga punkter som \u00e4r gemensamma f\u00f6r alla konflikter.<\/p>\n
N\u00e4r man l\u00f6ser en konflikt \u00e4r det viktigt att vara \u00f6ver striden, ist\u00e4llet f\u00f6r att vara mitt i den (detta kallas ibland att \"inta en metaposition\"), det vill s\u00e4ga att inte vara en del av beslutsprocessen f\u00f6r n\u00e5gon av sidorna. Annars, fr\u00e5n att vara en extern medlare som hj\u00e4lper till med l\u00f6sningen, kommer du bara att st\u00e4rka en parts position p\u00e5 bekostnad av den andra. Vid beslutsfattande \u00e4r det viktigt att beslutet accepteras moraliskt av alla parter, som det heter, \"k\u00f6pt\". S\u00e5, \u00e4ven om parterna inte \u00e4r entusiastiska \u00f6ver det beslut som fattats, b\u00f6r de \u00e5tminstone vara uppriktigt \u00f6verens om att f\u00f6lja det. Som man s\u00e4ger, vara i st\u00e5nd att vara oense men \u00e4nd\u00e5 f\u00f6rpliktad. Annars kommer konflikten bara att f\u00f6r\u00e4ndras; den gl\u00f6dande elden kommer att f\u00f6rbli under torven och vid n\u00e5got tillf\u00e4lle ofr\u00e5nkomligt blossa upp igen.<\/p>\n
Den andra punkten, som delvis \u00e4r relaterad till den f\u00f6rsta, \u00e4r att om du har best\u00e4mt dig f\u00f6r att delta i l\u00f6sningen av konflikten, s\u00e5 b\u00f6r du ta det p\u00e5 st\u00f6rsta allvar n\u00e4r det kommer till kommunikation och att f\u00f6rst\u00e5 kontexten. Prata personligen med varje part. Separat med varje part, till att b\u00f6rja med. N\u00f6j dig inte med e-post. Vid distribuerade team \u2014 prata \u00e5tminstone via videokonferens. N\u00f6j dig inte med rykten och \u00e5tersagor fr\u00e5n vittnen. F\u00f6rst\u00e5 historien, vad varje part vill, varf\u00f6r de vill ha det, vad de f\u00f6rv\u00e4ntar sig, om de har f\u00f6rs\u00f6kt l\u00f6sa fr\u00e5gan tidigare, vad som kommer att h\u00e4nda om den inte l\u00f6ses, vilka l\u00f6sningar de ser, hur de uppfattar den andra partens position, vad de anser \u00e4r r\u00e4tt eller fel, osv. Ladda ner all m\u00f6jlig kontext i ditt huvud, opartiskt, med antagandet att alla har sina sk\u00e4l. Du \u00e4r inte inne i konflikten, du \u00e4r utanf\u00f6r den, i en meta-position. Om kontexten endast \u00e4r tillg\u00e4nglig i en e-posttr\u00e5d \u2014 l\u00e4s d\u00e5 hela den och relaterade diskussionstr\u00e5dar och dokument. Efter att du har l\u00e4st \u2014 prata \u00e4nd\u00e5 i telefon. N\u00e4stan garanterat kommer du att h\u00f6ra n\u00e5got viktigt som inte finns i e-posten.<\/p>\n
Den tredje viktiga punkten handlar om det \u00f6vergripande tillv\u00e4gag\u00e5ngss\u00e4ttet i kommunikationen. Det \u00e4r vanliga saker, inget ut\u00f6ver det vanliga, men de har stor betydelse. F\u00f6rs\u00f6k inte spara tid, prata med alla deltagare, kritisera inte personen, utan betrakta konsekvenserna av deras handlingar (inte \"du \u00e4r of\u00f6rsk\u00e4md\", utan \"kanske kan folk bli s\u00e5rade av det h\u00e4r\"). Ge m\u00f6jlighet till att beh\u00e5lla sina ansikten, ha diskussioner personligen och inte framf\u00f6r k\u00f6ren.<\/p>\n
Konflikter orsakas vanligtvis av en av tv\u00e5 anledningar. Den f\u00f6rsta har att g\u00f6ra 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\u00f6rm\u00e5ga att hantera sina k\u00e4nslor (vilket f\u00f6r \u00f6vrigt inte alltid \u00e4r kopplat till deras \u00e5lder). Den andra vanliga orsaken \u00e4r brister i arbetsprocessen, vilket skapar gr\u00e5zoner d\u00e4r ansvaret \u00e4r otydligt mellan deltagarna, och parternas f\u00f6rv\u00e4ntningar \u00e4r inte tydliga f\u00f6r varandra, rollerna i processen \u00e4r otydliga. <\/p>\n
I konflikthantering (liksom i alla andra fr\u00e5gor) m\u00e5ste chefen ha i \u00e5tanke tre perspektiv: det kortsiktiga \u2013 att l\u00f6sa fr\u00e5gan\/konflikten h\u00e4r och nu, det medell\u00e5nga \u2013 att minska risken f\u00f6r att en liknande konflikt uppst\u00e5r igen, och det l\u00e5ngsiktiga \u2013 att odla en vuxen kultur i teamet. <\/p>\n
Inom oss alla finns ett inre barn, ungef\u00e4r tre till fyra \u00e5r gammalt. Det mesta av tiden p\u00e5 jobbet sover det, men ibland vaknar det och tar \u00f6ver. Barnet har sina egna prioriteringar. Det \u00e4r viktigt f\u00f6r det att h\u00e4vda att detta \u00e4r dess sandl\u00e5da, att mamma \u00e4lskar det mer, att dess leksak \u00e4r b\u00e4st (designen \u00e4r \u00f6verl\u00e4gsen, det programmerar b\u00e4ttre \u00e4n alla andra, \u2026). I konfliktens stund kan barnet krama sina leksaker, stampa med f\u00f6tterna och sl\u00e5 med en spade, men det kan inte l\u00f6sa vuxna fr\u00e5gor (designarkitektur, metoder f\u00f6r automatisk testning, tidsplaner f\u00f6r release, osv.), det t\u00e4nker inte i termer av nytta f\u00f6r teamet. Man kan uppmuntra, tr\u00f6sta och skicka barnet att sova, och be det kalla p\u00e5 sin vuxna. Innan en diskussion i konfliktens kontext b\u00f6rjar, se till att du pratar med den vuxna och inte med barnet, och st\u00e5 sj\u00e4lv p\u00e5 den vuxnas sida. Om ditt \u00e4kta m\u00e5l just nu \u00e4r att l\u00f6sa en allvarlig fr\u00e5ga, \u00e4r du p\u00e5 den vuxna m\u00e4nniskans position. Om ditt m\u00e5l \u00e4r att stampa och sl\u00e5 med en spade \u2013 \u00e4r det en barnslig position. Skicka ditt inre barn att sova och kalla p\u00e5 den vuxna, eller skjuta upp diskussionen. En m\u00e4nniska fattar ett k\u00e4nslom\u00e4ssigt beslut och letar sedan efter en rationell motivering. Ett beslut som fattas av barnet, baserat p\u00e5 barnets prioriteringar, kommer inte att vara optimalt.<\/p>\n
F\u00f6rutom beteendet vid en konflikt, karakteriseras en barns eller vuxens position ocks\u00e5 av den niv\u00e5 av ansvar som personen \u00e4r beredd att ta p\u00e5 sig. I extrema fall kan en programmerares barnsliga position, som jag har st\u00f6tt p\u00e5 flera g\u00e5nger, se ut s\u00e5 h\u00e4r: jag har skrivit koden, skickat den f\u00f6r granskning \u2013 mitt arbete \u00e4r klart. Granskarna ska se \u00f6ver den och sl\u00e5 samman den, QA ska kontrollera den, om det finns problem \u2013 de meddelar mig. Rent m\u00e4rkligt, \u00e4ven ganska vuxna och erfarna m\u00e4nniskor beter sig ibland p\u00e5 detta s\u00e4tt. I den andra \u00e4nden av skalan anser en person sig ansvarig f\u00f6r att hans kod fungerar, \u00e4r t\u00e4ckt av tester, har kontrollerats av honom personligen, har framg\u00e5ngsrikt klarat granskningen (om det beh\u00f6vs, inget problem att pingla granskarna, diskutera fr\u00e5gor muntligt, osv.) och har blivit sammanfogad, QA kommer att f\u00e5 hj\u00e4lp vid behov, testscenarier kommer att dokumenteras, osv. I normala fall befinner sig programmeraren antingen n\u00e4rmare den vuxna \u00e4nden av skalan fr\u00e5n b\u00f6rjan, eller r\u00f6r sig dit allteftersom hen f\u00e5r mer erfarenhet (f\u00f6rutsatt att den r\u00e4tta kulturen odlas i teamet). I extrema fall forts\u00e4tter hen att arbeta, oftast med en barnslig position, vilket leder till att hen och teamet periodiskt f\u00e5r problem och konflikter.<\/p>\n
Att skapa en korrekt och vuxen kultur i teamet \u00e4r en viktig uppgift f\u00f6r varje chef. Det kr\u00e4ver l\u00e5ng tid och dagliga anstr\u00e4ngningar, men resultatet \u00e4r v\u00e4rt det. Det finns tv\u00e5 s\u00e4tt att p\u00e5verka teamkulturen \u2013 genom personlig exempel (som andra kommer att f\u00f6lja, teamet ser alltid p\u00e5 ledaren) och genom att diskutera och uppmuntra korrekt beteende. H\u00e4r finns det inget mystiskt eller v\u00e4ldigt formellt, bara n\u00e4r man diskuterar problem, notera vad man kunde ha gjort p\u00e5 ett annat s\u00e4tt, understryka n\u00e4r n\u00e5got har l\u00f6sts korrekt, ber\u00f6m, och markera detta vid analyser av releaser, osv.<\/p>\n
L\u00e5t oss \u00f6verv\u00e4ga n\u00e5gra typiska konfliktsituationer, fr\u00e5n enkla till komplexa:<\/p>\n
Konflikter som inte r\u00f6r arbetsfr\u00e5gor<\/b><\/p>\n
Det h\u00e4nder ganska ofta att det uppst\u00e5r konflikter p\u00e5 jobbet som inte r\u00f6r arbetsfr\u00e5gor. Deras uppkomst och l\u00e4tthet att l\u00f6sa \u00e4r vanligtvis direkt kopplad till niv\u00e5n av emotionell intelligens hos deltagarna, deras niv\u00e5 av vuxenhet, och har ingen koppling till arbetsprocessens felfrihet eller ofullkomlighet.<\/p>\n
Typiska exempel \u00e4r att n\u00e5gon inte anv\u00e4nder tv\u00e4ttmaskinen eller duschen tillr\u00e4ckligt ofta, vilket irriterar andra, n\u00e5gon tycker att det \u00e4r kvavt medan en annan vill ha f\u00f6nstret \u00f6ppet f\u00f6r luft, n\u00e5gon \u00e4r f\u00f6r h\u00f6gljudd medan andra beh\u00f6ver tystnad f\u00f6r att arbeta, och s\u00e5 vidare. Det \u00e4r b\u00e4st att inte dra ut p\u00e5 konflikter av denna sort och inte l\u00e5ta dem utvecklas fritt. De kommer inte att l\u00f6sa sig sj\u00e4lva och kommer dagligen att distrahera fr\u00e5n arbetet och f\u00f6rst\u00f6ra st\u00e4mningen i teamet. Lyckligtvis brukar det inte vara stora problem att l\u00f6sa dem \u2014 det r\u00e4cker ofta med att lugnt prata (s\u00e5klart en och en) med en kollega som f\u00f6rsummar hygien, s\u00e4kerst\u00e4lla bekv\u00e4m placering av personer som f\u00f6redrar tystnad\/kylighet, k\u00f6pa ljudd\u00e4mpande h\u00f6rlurar eller s\u00e4tta upp sk\u00e4rmar, etc. <\/p>\n
Ett annat exempel som jag st\u00f6tt p\u00e5 flera g\u00e5nger under min karri\u00e4r \u00e4r psykisk inkompatibilitet bland teammedlemmar. Av n\u00e5gon anledning kan vissa personer helt enkelt inte arbeta tillsammans, varje kommunikation slutar i br\u00e5k. Ibland beror detta p\u00e5 att m\u00e4nniskor har helt olika \u00e5sikter om en br\u00e4nnande fr\u00e5ga (vanligtvis politisk) och inte kan l\u00e4mna dessa bakom sig p\u00e5 jobbet. Att f\u00f6rs\u00f6ka \u00f6vertyga dem att tolerera varandra eller \u00e4ndra sitt beteende \u00e4r oftast en meningsl\u00f6s syssels\u00e4ttning. Det enda undantaget jag har st\u00f6tt p\u00e5 \u00e4r unga kollegor med en \u00f6ppen inst\u00e4llning, deras beteende kan fortfarande gradvis \u00e4ndras genom periodiska samtal. Vanligtvis l\u00f6ses fr\u00e5gan framg\u00e5ngsrikt genom att dela upp dem i olika team, eller \u00e5tminstone ge m\u00f6jlighet att s\u00e4llan korsa varandras v\u00e4gar p\u00e5 jobbet.<\/p>\n
I alla ovan n\u00e4mnda situationer \u00e4r det viktigt att prata med alla deltagare individuellt, diskutera situationen, fr\u00e5ga om de \u00f6verhuvudtaget ser ett problem i detta fall, och fr\u00e5ga vilka l\u00f6sningar de anser \u00e4r m\u00f6jliga, samt s\u00e4kerst\u00e4lla deras delaktighet i beslutsprocessen.<\/p>\n
Ur ett arbetsprocessoptimeringsperspektiv (medeldistans som jag n\u00e4mnde), finns det inte mycket som kan g\u00f6ras p\u00e5 denna punkt, den enda m\u00f6jligheten till optimering \u00e4r att ta h\u00e4nsyn till kompatibilitetsfaktorn vid team's bildande och i f\u00f6rv\u00e4g undvika att s\u00e4tta ihop personer som kommer att skapa konflikter. <\/p>\n
Ur ett teamkultursperspektiv uppst\u00e5r s\u00e5dana situationer mycket s\u00e4llan i team med en mogen kultur, d\u00e4r folk respekterar teamet och kollegorna och kan l\u00f6sa fr\u00e5gor p\u00e5 egen hand. Dessutom l\u00f6ses s\u00e5dana konflikter mycket enklare (ofta automatiskt) i team d\u00e4r tilliten \u00e4r h\u00f6g, folk har arbetat tillsammans l\u00e4nge och\/eller ofta kommunicerar utanf\u00f6r arbetet.<\/p>\n
Konflikter relaterade till arbetsfr\u00e5gor:<\/b><\/p>\n
S\u00e5dana konflikter orsakas vanligtvis av b\u00e5da anledningarna samtidigt, b\u00e5de emotionell (det faktum att n\u00e5gon av deltagarna inte \u00e4r i en vuxen roll) och ofullkomligheten i sj\u00e4lva arbetsprocessen. Den vanligaste typen av konflikter som jag har st\u00f6tt p\u00e5 \u00e4r konflikter i processen av kodgranskning eller arkitekturdiskussioner mellan utvecklarna. <\/p>\n
Jag skulle h\u00e4r lyfta fram tv\u00e5 typiska fall:<\/p>\n
1) I det f\u00f6rsta fallet kan utvecklaren inte f\u00e5 kodgranskning av en kollega. Patchen har skickats f\u00f6r granskning, och ingenting h\u00e4nder. Vid f\u00f6rsta anblick verkar det inte finnas n\u00e5got uppenbart konflikt mellan de tv\u00e5 sidorna, men om man t\u00e4nker efter \u00e4r detta helt klart en konflikt. Arbetsfr\u00e5gan l\u00f6ses inte, en av sidorna (den som v\u00e4ntar p\u00e5 granskning) upplever tydlig obehag. En extrem underkategori av detta fall \u00e4r utveckling i communityn eller i olika team, d\u00e4r granskaren kan vara ointresserad av just den specifika koden, och p\u00e5 grund av arbetsbelastning eller andra omst\u00e4ndigheter kan helt enkelt ignorera beg\u00e4ran om granskning, och en extern domare (gemensam f\u00f6r b\u00e5da parter, en manager) kanske \u00f6verhuvudtaget inte finns. <\/p>\n
Tillv\u00e4gag\u00e5ngss\u00e4ttet f\u00f6r att l\u00f6sa s\u00e5dana situationer relaterar till l\u00e5ngsiktig perspektiv och en vuxen m\u00e4nniskas kultur. F\u00f6r det f\u00f6rsta fungerar rimlig aktivitet. Man b\u00f6r inte f\u00f6rv\u00e4nta sig att kod som h\u00e4nger i granskning automatiskt f\u00e5r uppm\u00e4rksamhet fr\u00e5n granskaren. Det \u00e4r n\u00f6dv\u00e4ndigt att hj\u00e4lpa granskare att se den. Ping-a n\u00e5gra personer, st\u00e4ll en fr\u00e5ga p\u00e5 svaret, delta i diskussioner. Det \u00e4r uppenbart att att vara p\u00e5tr\u00e4ngande snarare skadar \u00e4n hj\u00e4lper, s\u00e5 sunt f\u00f6rnuft m\u00e5ste anv\u00e4ndas. F\u00f6r det andra fungerar f\u00f6rberedelser mycket bra. Om teamet f\u00f6rst\u00e5r vad som h\u00e4nder och varf\u00f6r, varf\u00f6r denna kod \u00f6verhuvudtaget beh\u00f6vs, designen har diskuterats och godk\u00e4nts i f\u00f6rv\u00e4g av alla, kommer m\u00e4nniskor att vara mer ben\u00e4gna att uppm\u00e4rksamma s\u00e5dan kod och ta den i bruk. F\u00f6r det tredje fungerar auktoritet. Om du vill att andra ska granska din kod \u2013 granska mycket sj\u00e4lv. G\u00f6r kvalitetsgranskningar, med verkliga verifieringar, verkliga tester, anv\u00e4ndbara kommentarer. Om ditt nick \u00e4r k\u00e4nt i teamet p\u00e5 ett bra s\u00e4tt, \u00f6kar chansen att din kod f\u00e5r uppm\u00e4rksamhet.<\/p>\n
Ur ett arbetsprocessperspektiv kan m\u00f6jliga f\u00f6rb\u00e4ttringar h\u00e4r vara att s\u00e4tta r\u00e4tt prioriteringar, inriktade p\u00e5 att hj\u00e4lpa utvecklaren att n\u00e5 sina och teamets m\u00e5l (granska andras kod, skriva inl\u00e4gg i communityn, st\u00f6dja koden med arkitekturbeskrivningar, dokumentation, tester, delta i diskussioner med communityn, etc.), f\u00f6rhindra att patchar fastnar f\u00f6r l\u00e4nge i k\u00f6n, och s\u00e5 vidare. <\/p>\n
2) Det andra vanliga fallet av konflikter vid kod- eller designgranskning \u00e4r olika uppfattningar om tekniska fr\u00e5gor, kodningsstil, val av verktyg. Den niv\u00e5 av f\u00f6rtroende som finns mellan deltagarna, tillh\u00f6righeten till samma team och erfarenheten av att arbeta tillsammans har stor betydelse i detta avseende. En \u00e5terv\u00e4ndsgr\u00e4nd uppst\u00e5r n\u00e4r n\u00e5gon av deltagarna intar en barnslig position och inte f\u00f6rs\u00f6ker h\u00f6ra vad den andra vill f\u00f6rmedla. Ofta kan den f\u00f6reslagna ansatsen fr\u00e5n den andra sidan och den ansats som ursprungligen f\u00f6reslogs, b\u00e5da fungera framg\u00e5ngsrikt och det har ingen avg\u00f6rande betydelse vilken som v\u00e4ljs. <\/p>\n
En g\u00e5ng f\u00f6rberedde en programmerare i mitt team (l\u00e5t oss kalla honom Pasha) en patch med \u00e4ndringar i systemet f\u00f6r paketdistribution som utvecklades och underh\u00f6lls av kollegor fr\u00e5n en annan avdelning. En av dem (Igor) hade en stark \u00e5sikt om hur Linux-tj\u00e4nster skulle konfigureras vid distributionen av paket. Denna \u00e5sikt skilde sig fr\u00e5n den metod som f\u00f6reslogs i patchen, och de kunde inte komma \u00f6verens. Som vanligt var tidsfristen knapp, och vi beh\u00f6vde n\u00e5 ett beslut; n\u00e5gon av dem beh\u00f6vde ta en vuxen roll. Pasha erk\u00e4nde att b\u00e5da metoderna hade sin plats, men han ville att hans alternativ skulle g\u00e5 igenom eftersom det inte fanns n\u00e5gra tydliga tekniska f\u00f6rdelar med n\u00e5got av alternativen. <\/p>\n
V\u00e5r diskussion s\u00e5g ungef\u00e4r ut s\u00e5 h\u00e4r (mycket schematiskt, sj\u00e4lvklart, samtalet varade i en halv timme): <\/p>\n
\u2014 Pasha, vi har feature freeze om n\u00e5gra dagar. Det \u00e4r viktigt att vi f\u00e5r allt klart och p\u00e5b\u00f6rjar testningen s\u00e5 snabbt som m\u00f6jligt. Hur ska vi ta oss f\u00f6rbi Igor?
Fr\u00e5gan l\u00f6stes, releasen sl\u00e4pptes i tid, Pasha k\u00e4nde inget s\u00e4rskilt missn\u00f6je eftersom han sj\u00e4lv f\u00f6reslog l\u00f6sningen och genomf\u00f6rde den. Igor var \u00f6verlag n\u00f6jd, eftersom hans \u00e5sikter beaktades och de gjorde det som han f\u00f6reslog.<\/p>\n
En annan typ av samma konflikt handlar om valet mellan tekniska l\u00f6sningar\/bibliotek\/metoder i ett projekt, s\u00e4rskilt i ett distribuerat team. I ett projekt som positionerades som ett som anv\u00e4nde C\/C++, visade det sig till slut att den tekniska ledningen var kategoriskt emot anv\u00e4ndningen av STL (Standard Template Library). Detta \u00e4r ett standardbibliotek f\u00f6r spr\u00e5ket som f\u00f6renklar utvecklingen, och v\u00e5rt team var mycket vana vid det. Det visade sig att projektet var mycket n\u00e4rmare C \u00e4n C++, vilket inte inspirerade teamet, eftersom ledningen gjorde en insats och anst\u00e4llde riktigt duktiga C++-utvecklare. Samtidigt hade den amerikanska delen av teamet, b\u00e5de ingenj\u00f6rer och chefer, arbetat i f\u00f6retaget l\u00e4nge och var vana vid den nuvarande situationen; de var n\u00f6jda med det. Den ryska delen av teamet samlades d\u00e4remot p\u00e5 kort tid, inom n\u00e5gra veckor (inklusive mig). Den ryska delen av teamet ville kategoriskt inte ge upp det vanliga tillv\u00e4gag\u00e5ngss\u00e4ttet f\u00f6r utveckling.<\/p>\n
O\u00e4ndliga skriftliga diskussioner b\u00f6rjade mellan tv\u00e5 kontinenter, med meddelanden p\u00e5 tre till fyra sk\u00e4rmar som fl\u00f6g fram och tillbaka, i grupputskick och personligt, fr\u00e5n programmerare till programmerare och chefer. Som det ofta \u00e4r, l\u00e4ste ingen, f\u00f6rutom f\u00f6rfattarna och deras entusiastiska supportrar, meddelanden av den storleken. Chattarna knakade av sp\u00e4nning och skickade fram och tillbaka m\u00e5nga sk\u00e4rmstora \u00f6verv\u00e4ganden kring tekniska f\u00f6rdelar med STL, hur v\u00e4l testad och s\u00e4ker den \u00e4r, och hur underbart livet \u00e4r med den och hur hemskt det \u00e4r utan. <\/p>\n
Det h\u00e4r p\u00e5gick ganska l\u00e4nge, tills jag till slut ins\u00e5g att vi diskuterade de tekniska aspekterna av fr\u00e5gan, men problemet var i realiteten inte tekniskt. Problemet handlar inte om f\u00f6rdelarna eller nackdelarna med STL eller sv\u00e5righeten att arbeta utan den. Problemen var snarare organisatoriska. Vi beh\u00f6vde bara f\u00f6rst\u00e5 hur f\u00f6retaget som vi arbetade p\u00e5 var organiserat. Ingen av oss hade tidigare erfarenhet av att jobba i ett s\u00e5dant f\u00f6retag. Problemet var att efter att ha utvecklat koden och sl\u00e4ppt den i produktion, var det helt andra personer fr\u00e5n andra team, fr\u00e5n andra l\u00e4nder, som sk\u00f6tte underh\u00e5llet. Detta enorma ingenj\u00f6rsteam med flera tiotusentals ingenj\u00f6rer (totalt) hade bara r\u00e5d med det mest grundl\u00e4ggande tekniska minimum, s\u00e5 att s\u00e4ga, minimum minimorum. Allt som gick ut\u00f6ver det ingenj\u00f6rsstandard som fanns i f\u00f6retaget kunde fysiskt sett inte st\u00f6djas i framtiden. Niv\u00e5n p\u00e5 teamet definieras av niv\u00e5erna hos de svagaste medlemmarna. Efter att vi ins\u00e5g den verkliga motivationen<\/i> f\u00f6r den amerikanska delen av teamet, togs denna fr\u00e5ga bort fr\u00e5n agendan och vi utvecklade och sl\u00e4ppte framg\u00e5ngsrikt produkten tillsammans, d\u00e4r vi anv\u00e4nde de standarder som antagits i f\u00f6retaget. I detta fall fungerade e-post och chattar d\u00e5ligt, och f\u00f6r att n\u00e5 en gemensam grund kr\u00e4vdes flera resor och mycket personlig kommunikation.<\/p>\n
Utifr\u00e5n arbetsfl\u00f6det skulle det i detta specifika fall vara till hj\u00e4lp att ha en beskrivning av de anv\u00e4nda verktygen, krav p\u00e5 dem, begr\u00e4nsningar f\u00f6r att l\u00e4gga till nya och en motivering f\u00f6r s\u00e5dana begr\u00e4nsningar. Dessa dokument motsvarar ungef\u00e4r de som beskrivs i punkterna Reuse Strategy och Development Environment i handboken \"Manager's Handbook for Software Development\". NASA<\/a><\/noindex>. Trots sin \u00e5lder beskriver den utm\u00e4rkt alla huvudsakliga aktiviteter och steg i planeringen av programvaruutveckling av denna typ. Till\u00e4gget av s\u00e5dana dokument f\u00f6renklar diskussionen om vilka komponenter och metoder som kan anv\u00e4ndas i produkten och varf\u00f6r.<\/p>\nN\u00e4r det g\u00e4ller kulturen \u00e4r det uppenbart att med en mer mogen inst\u00e4llning, d\u00e4r parterna f\u00f6rs\u00f6ker h\u00f6ra och f\u00f6rst\u00e5 den verkliga motivationen bakom kollegornas agerande och agera utifr\u00e5n projektets och teamets prioriteringar snarare \u00e4n personligt ego, skulle konflikten ha l\u00f6sts enklare och snabbare.<\/p>\n
I ett annat fall d\u00e4r valet av teknisk l\u00f6sning orsakade en konflikt tog det mig ocks\u00e5 l\u00e5ng tid att f\u00f6rst\u00e5 motivationen hos en av parterna (fallet var verkligen ovanligt), men n\u00e4r motivationen v\u00e4l var klar blev beslutet uppenbart. <\/p>\n
Situationer \u00e4r som f\u00f6ljer: I ett team med ungef\u00e4r 20 personer dyker en ny utvecklare upp, l\u00e5t oss kalla honom Stas. V\u00e5rt standardkommunikationsverktyg i teamet var d\u00e5 Skype. Som visade sig senare var Stas en stor fan av \u00f6ppna standarder och \u00f6ppen k\u00e4llkod, och han anv\u00e4nde endast verktyg och operativsystem vars k\u00e4llkod fanns tillg\u00e4nglig offentligt och som anv\u00e4nde offentligt beskriva protokoll. Skype tillh\u00f6rde inte dessa verktyg. Vi spenderade en stor m\u00e4ngd tid p\u00e5 att diskutera f\u00f6r- och nackdelar med detta tillv\u00e4gag\u00e5ngss\u00e4tt, f\u00f6rs\u00f6ka starta alternativ till Skype p\u00e5 olika operativsystem, f\u00f6rs\u00f6ka \u00f6vertyga Stas att teamet skulle byta till andra standarder, skriva till honom personligen via e-post, ringa honom personligen via telefon, k\u00f6pa honom en andra dator speciellt f\u00f6r Skype, etc. Till slut ins\u00e5g jag att detta problem i grunden inte var tekniskt eller organisatoriskt, det var mer av en ideologisk fr\u00e5ga, man kan till och med s\u00e4ga en religi\u00f6s fr\u00e5ga (f\u00f6r Stas). \u00c4ven om vi slutligen kopplade ihop Stas med Skype (vilket stod oss dyrt flera m\u00e5nader), skulle problemet uppst\u00e5 igen med vilket annat verktyg som helst. Jag hade ingen verklig m\u00f6jlighet att \u00e4ndra Stas v\u00e4rdegrund, och det fanns ingen grund f\u00f6r att f\u00f6rs\u00f6ka f\u00f6r\u00e4ndra teamets v\u00e4rdegrund, som fungerade utm\u00e4rkt i denna milj\u00f6. M\u00e4nniskor och f\u00f6retag var helt enkelt orthogonala i sina v\u00e4rderingar. I s\u00e5dana situationer \u00e4r en bra l\u00f6sning oftast organisatorisk. Vi flyttade Stas till ett annat team d\u00e4r han var mer i sitt r\u00e4tta element.<\/p>\n
Anledningen till denna konflikt, enligt min mening, ligger i diskrepansen mellan den personliga kulturen hos en specifik person (som har en stark \u00e5sikt som hindrar honom fr\u00e5n att kompromissa) och f\u00f6retagets kultur. I detta fall \u00e4r det givetvis ett misstag fr\u00e5n ledarens sida. Det var fel fr\u00e5n b\u00f6rjan att anst\u00e4lla honom f\u00f6r ett projekt av denna typ. Stas \u00f6vergick till ett projekt inom \u00f6ppen k\u00e4llkod och trivs utm\u00e4rkt d\u00e4r.<\/p>\n
Ett bra exempel p\u00e5 en konflikt som orsakats av b\u00e5de utvecklarens barnsliga inst\u00e4llning och brister i arbetsprocessen \u00e4r en situation d\u00e4r utvecklaren och QA-teamet har olika f\u00f6rv\u00e4ntningar om f\u00e4rdigst\u00e4llandet av en funktion som skickats till QA, i avsaknad av en definition av klart. Utvecklaren trodde att det var tillr\u00e4ckligt att skriva koden och sl\u00e4ppa \u00f6ver funktionen till QA \u2014 d\u00e4r skulle de fixa det. Han var f\u00f6r \u00f6vrigt en ganska vuxen och erfaren programmerare, men han hade en l\u00e5g inre kvalitetsstandard. QA var inte n\u00f6jda med detta och kr\u00e4vde att han skulle visa och beskriva f\u00f6r dem vad han sj\u00e4lv hade kontrollerat, samt de ville ha ett testscenario. De hade tidigare haft problem med funktionalitet fr\u00e5n denna utvecklare och ville inte sl\u00f6sa sin tid igen. F\u00f6r \u00f6vrigt hade de r\u00e4tt \u2014 funktionen fungerade faktiskt inte, koden hade han inte kontrollerat innan den skickades till QA. <\/p>\n
F\u00f6r att l\u00f6sa situationen bad jag honom visa mig att allt verkligen fungerade (det gjorde det inte, och han fick \u00e5tg\u00e4rda det), vi diskuterade definitionen av klart med teamet och QA (vi gjorde den inte skriftlig eftersom vi inte ville byr\u00e5kratisera processen f\u00f6r mycket), och snart skildes vi fr\u00e5n denna specialist (till allas l\u00e4ttnad).<\/p>\n
N\u00e4r det g\u00e4ller arbetsprocessen \u00e4r m\u00f6jliga f\u00f6rb\u00e4ttringar i detta fall att ha en definition av klart, krav p\u00e5 att varje funktion ska ha enhetliga och integrerade tester, samt en beskrivning av testerna som genomf\u00f6rts av utvecklaren. I ett av projekten m\u00e4tte vi testt\u00e4ckningen av koden under CI och om t\u00e4ckningsgraden sj\u00f6nk efter att en patch lades till, m\u00e4rktes testerna som misslyckade, det vill s\u00e4ga, endast ny kod kunde l\u00e4ggas till om det fanns nya tester f\u00f6r den. <\/p>\n
\u00c4nnu ett typiskt exempel p\u00e5 en konflikt som \u00e4r n\u00e4ra kopplad till organisationen av arbetsprocessen. Vi har en produkt, ett utvecklingsteam f\u00f6r denna produkt, en supportteam och en kund. Kunden f\u00e5r problem med produkten och v\u00e4nder sig till supporten. Supporten analyserar problemet och inser att problemet ligger i produkten, de \u00f6verl\u00e4mnar problemet till produktteamet. Produktteamet har en hektisk period, utgivningen n\u00e4rmar sig, s\u00e5 \u00e4rendet med kundens problem, som hamnat bland de andra \u00e4rendena hos utvecklaren, som det \u00e4r tilldelat, h\u00e4nger utan uppm\u00e4rksamhet i flera veckor. Supporten tror att utvecklaren arbetar med kundens problem. Kunden v\u00e4ntar och hoppas att deras problem hanteras. I verkligheten h\u00e4nder det ingenting. N\u00e5gra veckor senare best\u00e4mmer sig kunden \u00e4ntligen f\u00f6r att kolla upp framstegen och fr\u00e5gar supporten hur det g\u00e5r. Supporten fr\u00e5gar utvecklingen. Utvecklaren rycker till, g\u00e5r igenom listan med \u00e4renden och uppt\u00e4cker \u00e4rendet fr\u00e5n kunden. Genom att l\u00e4sa kundens \u00e4rende f\u00f6rst\u00e5r han att informationen som beh\u00f6vs f\u00f6r att l\u00f6sa problemet \u00e4r otillr\u00e4cklig och att han beh\u00f6ver fler loggar och dumpningar. Supporten beg\u00e4r ytterligare information fr\u00e5n kunden. Och h\u00e4r inser kunden att ingen har arbetat med deras problem under hela denna tid. Och \u00e5skan kommer att sl\u00e5 ...<\/p>\n
I denna situation \u00e4r l\u00f6sningen av sj\u00e4lva konflikten ganska uppenbar och linj\u00e4r (att fixa produkten, uppdatera dokumentationen och testerna, lugna kunden, sl\u00e4ppa en hotfix, etc.). Det \u00e4r viktigt att analysera arbetsprocessen och f\u00f6rst\u00e5 vem som ansvarar f\u00f6r att organisera samarbetet mellan de tv\u00e5 teamen, varf\u00f6r en s\u00e5dan situation ens blev m\u00f6jlig. Det \u00e4r uppenbart att n\u00e5got m\u00e5ste \u00e5tg\u00e4rdas i processen \u2014 n\u00e5gon m\u00e5ste \u00f6vervaka den \u00f6vergripande bilden utan p\u00e5minnelser fr\u00e5n kunderna, proaktivt. \u00c4renden fr\u00e5n kunden b\u00f6r s\u00e4rskiljas bland de andra \u00e4rendena hos utvecklarna. Supporten b\u00f6r se om utvecklingen arbetar med deras \u00e4renden just nu, och om inte \u2014 n\u00e4r de kan b\u00f6rja arbeta, n\u00e4r ett resultat kan f\u00f6rv\u00e4ntas. Supporten och utvecklingen b\u00f6r regelbundet kommunicera och diskutera statusen f\u00f6r \u00e4rendena, insamlingen av den information som beh\u00f6vs f\u00f6r fels\u00f6kning b\u00f6r automatiseras s\u00e5 mycket som m\u00f6jligt, osv.<\/p>\n
Precis som hur en fiende p\u00e5 krig f\u00f6rs\u00f6ker sl\u00e5 mot skarven mellan tv\u00e5 enheter, visar det sig ocks\u00e5 att den mest k\u00e4nsliga och s\u00e5rbara punkten i arbetet ofta \u00e4r interaktionen mellan teamen. Om support- och utvecklingscheferna \u00e4r tillr\u00e4ckligt erfarna kan de sj\u00e4lva \u00e5tg\u00e4rda processen; om inte, kommer processen fortsatt att skapa konflikter och problem tills en chef tr\u00e4der in f\u00f6r att l\u00f6sa situationen.<\/p>\n
Ett annat karakteristiskt exempel som jag ofta har st\u00f6tt p\u00e5 i olika f\u00f6retag \u00e4r en situation d\u00e4r produkten utvecklas av ett team, de automatiska integrations testerna av ett annat team, och den infrastruktur d\u00e4r allt detta k\u00f6rs underh\u00e5lls av ett tredje team. Problem under testk\u00f6rningarna uppst\u00e5r st\u00e4ndigt, och orsaken till problemen kan ligga antingen i produkten, testerna eller infrastrukturen. Det \u00e4r ofta problematiskt att enas om vem som ska utf\u00f6ra den initiala problemanalysen, rapportera buggar, bearbeta loggar fr\u00e5n produkten, testerna och infrastrukturen, etc. Konflikter h\u00e4r \u00e4r ganska frekventa och samtidigt enhetliga. Vid h\u00f6g k\u00e4nslom\u00e4ssig intensitet faller deltagarna ofta tillbaka i en barnslig position, med diskussioner av typen: 'varf\u00f6r ska jag bry mig om det h\u00e4r?', 'de har oftare problem', osv. <\/p>\n
Ur arbetsprocessens perspektiv beror de specifika stegen f\u00f6r att l\u00f6sa fr\u00e5gan p\u00e5 teamens sammans\u00e4ttning, typen av tester och produkten, osv. I ett av projekten inf\u00f6rde vi periodiska vakter d\u00e4r teamen turades om att \u00f6vervaka testerna under en vecka. I ett annat projekt utf\u00f6rdes alltid den initiala analysen av testutvecklarna, men denna analys var ganska grundl\u00e4ggande och produkten var tillr\u00e4ckligt stabil, s\u00e5 det fungerade ganska bra. Det viktiga \u00e4r att s\u00e4kerst\u00e4lla processens transparens, tydlighet i f\u00f6rv\u00e4ntningarna f\u00f6r alla parter och en k\u00e4nsla av r\u00e4ttvisa i situationen f\u00f6r alla.<\/p>\n
\u00c4r konflikter inom organisationen ett problem, eller \u00e4r det ett d\u00e5ligt tecken att det ofta (eller till och med periodiskt) uppst\u00e5r konflikter i ditt team? I stort sett nej, eftersom n\u00e4r det sker tillv\u00e4xt, utveckling och dynamik, uppst\u00e5r fr\u00e5gor som tidigare aldrig har l\u00f6sts, vilket kan leda till konflikter. Det \u00e4r en indikator p\u00e5 att vissa omr\u00e5den beh\u00f6ver uppm\u00e4rksammas och att det finns utrymme f\u00f6r f\u00f6rb\u00e4ttringar. Det \u00e4r d\u00e5ligt om konflikter uppst\u00e5r f\u00f6r ofta, \u00e4r sv\u00e5ra eller tar l\u00e5ng tid att l\u00f6sa. Detta \u00e4r sannolikt ett tecken p\u00e5 otillr\u00e4ckligt utvecklade arbetsprocesser och en bristande mognad i teamet.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042d\u043f\u0438\u0433\u0440\u0430\u0444: \u0412\u0441\u0442\u0440\u0435\u0442\u0438\u043b\u0438\u0441\u044c \u043a\u0430\u043a-\u0442\u043e \u0432 \u043b\u0435\u0441\u0443 \u0401\u0436\u0438\u043a \u0438 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a. \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u0401\u0436\u0438\u043a! \u2014 \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439, \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043e\u043a! \u0422\u0430\u043a, \u0441\u043b\u043e\u0432\u043e \u0437\u0430 \u0441\u043b\u043e\u0432\u043e, \u0448\u0443\u0442\u043a\u0430 \u0437\u0430 \u0448\u0443\u0442\u043a\u043e\u0439, \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u043b \u0401\u0436\u0438\u043a \u043e\u0442 \u041c\u0435\u0434\u0432\u0435\u0436\u043e\u043d\u043a\u0430 \u043f\u043e \u043c\u043e\u0440\u0434\u0435 \u2026 \u041f\u043e\u0434 \u043a\u0430\u0442\u043e\u043c \u0440\u0430\u0441\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044f \u043d\u0430\u0448\u0435\u0433\u043e \u0442\u0438\u043c\u043b\u0438\u0434\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u0430 \u043f\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 RAS \u2014 \u0418\u0433\u043e\u0440\u044f \u041c\u0430\u0440\u043d\u0430\u0442\u0430 \u043e \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0435 \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432 \u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0445 \u043c\u0435\u0442\u043e\u0434\u0430\u0445 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0438\u043c\u0438. \u0411\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u043e\u0432, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27283,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-36457","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Konflikthantering](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")