Epigraf:
En dag mødtes Tornerose og Bjørnen i skoven.
— Hej, Tornerose!
— Hej, Bjørn!
Så, ord for ord, vittighed efter vittighed, og Tornerose fik et slag fra Bjørnen ...
Under katten er skrivelser fra vores teamleder samt direktør for produktudvikling RAS — Igor Marnat om specifikationen af arbejds konflikter og mulige ledelsesmetoder.
De fleste konflikter, vi står overfor på arbejde, udvikler sig efter et scenarie, der ligner det, der er beskrevet ovenfor i epigrafen. Der er flere deltagere, som i begyndelsen er indstillet venligt overfor hinanden, de forsøger at løse et spørgsmål, men problemet forbliver uopklaret, og relationerne mellem deltagerne viser sig af en eller anden grund at være beskadiget.
Livet er mangfoldigt; der opstår variationer i den beskrevne situation. Nogle gange er relationerne mellem deltagerne ikke særlig gode fra starten, nogle gange findes der ikke engang et spørgsmål, der kræver umiddelbar løsning (som i epigrafen), nogle gange forbliver relationerne de samme, efter at diskussionen er startet, men spørgsmålet bliver ikke løst til sidst.
Hvad er der så fælles i alle situationer, der kan defineres som en arbejds konflikt?
For det første er der to eller flere parter. Disse parter kan befinde sig på forskellige pladser i organisationen, have lige forhold (kolleger i teamet), eller være på forskellige hierarkiske niveauer (chef — underordnet), være individuelle (medarbejder) eller gruppebaserede (i tilfælde af konflikt mellem en medarbejder og et team eller to teams), og så videre. Sandsynligheden for konflikt og letheden ved at løse den påvirkes stærkt af tillidsniveauet mellem deltagerne. Jo bedre parterne kender hinanden, jo højere tillidsniveau, desto større er chancen for, at de når til enighed. For eksempel er medarbejdere i et distribueret team, der aldrig har kommunikeret personligt, mere tilbøjelige til at havne i en konflikt, når de skal løse et simpelt arbejds spørgsmål, end folk der i det mindste har kommunikeret personligt et par gange. Derfor er det meget vigtigt at sørge for periodiske personlige møder mellem alle teammedlemmer i distribuerede teams.
For det andet, i en konflikt situation på arbejdet befinder parterne sig i en situation, hvor de skal løse et spørgsmål, der er vigtigt for en af parterne, for begge eller for organisationen som helhed. På grund af situationens karakter har parterne normalt tilstrækkelig tid og forskellige måder at løse det på (formelle, uformelle, møder, breve, ledelsens beslutninger, tilstedeværelsen af mål og teamplaner, hierarkiets eksistens, osv.). Dette adskiller sig fra situationen, hvor man skal løse et arbejdsrelateret (eller ikke-arbejdsrelateret) spørgsmål i organisationen, som for eksempel når man siger: “Hey, fyr, hvilken by er du fra?!” på gaden, eller konflikten fra epigrafen. Ved løsning af arbejdsrelaterede spørgsmål er kvaliteten af arbejdsprocessen og kulturen omkring problemløsning i teamet afgørende.
For det tredje er en afgørende faktor i konflikten (set i lyset af vores diskussion) det faktum, at parterne i processen ikke kan komme til en enighed om en løsning, der tilfredsstiller alle. Situationen kræver indblanding fra en tredjepart, en ekstern voldgiftsmand. Dette punkt kan virke omstridt, men i virkeligheden, hvis den konfliktfyldte situation blev løst uden indblanding fra en ekstern voldgiftsmand, og spørgsmålet er blevet løst tilfredsstillende uden at forholdet mellem parterne er forværret, er det den situation, man bør stræbe efter. En sådan konflikt vil vi sandsynligvis ikke engang få kendskab til, eller vi vil tilfældigt høre om den efter dens løsning. Jo flere spørgsmål teamet kan løse selvstændigt, desto mere effektivt vil det arbejde.
En anden karakteristisk egenskab ved konflikten, som er værd at nævne, er graden af følelsesmæssig intensitet under løsningen. Konflikten er ikke nødvendigvis forbundet med et højt følelsesmæssigt niveau. Deltagerne behøver ikke at råbe og vifte med hænderne for, at situationen reelt kan være konfliktfyldt. Hvis et spørgsmål ikke bliver løst, og der er en vis følelsesmæssig spænding til stede (måske ikke åbenlyst udtrykt), så er vi i en konflikt situation.
Skal man overhovedet gribe ind i konfliktfyldte situationer, eller er det bedre at lade dem løse sig selv og vente på, at problemet forsvinder af sig selv? Ja, det skal man. Det er ikke altid i ens magt eller kompetence at løse konflikten fuldstændigt, men i enhver situation, uanset konfliktens omfang, kan du indtage en voksen position, hvorved du også kan løfte andre omkring dig, mildne den negative indflydelse af konflikten og bidrage til dens løsning.
Før vi ser på nogle eksempler på konfliktfyldte situationer, lad os kort fokusere på nogle vigtige punkter, der gælder for alle konflikter.
Når du skal løse en konflikt, er det vigtigt at være over konflikten og ikke indgå i den (dette kaldes også at indtage en metaposition), hvilket betyder, at du ikke skal være en del af én af parterne i løsningen. Ellers vil du som en ekstern mægler, der hjælper med løsningen, blot forstærke den ene sides position på bekostning af den anden. Når der træffes beslutninger, er det vigtigt, at de er moralsk acceptable for alle parter, som man siger, 'købt'. Så selvom parterne ikke er begejstrede for den træffede beslutning, skal de i det mindste være oprigtigt enige om at følge den. Man skal kunne sige, at man er uenig, men alligevel forpligte sig. Ellers vil konflikten blot ændre form; den glødende ild vil forblive under overfladen og uundgåeligt blusse op igen på et tidspunkt.
Det andet punkt, der delvist er relateret til det første, er, at hvis du har besluttet dig for at deltage i konfliktløsningen, så tag det meget alvorligt med hensyn til kommunikation og kontekstforståelse. Tal personligt med hver af parterne. Start med at tale med dem hver for sig. Vær ikke tilfreds med bare at bruge e-mail. I tilfælde af et distribueret team, så tal mindst over video. Vær ikke tilfreds med rygter og vidnefortalelser. Forstå historien, hvad hver part ønsker, hvorfor de ønsker det, hvad de forventer, om de har prøvet at løse dette problem tidligere, hvad der vil ske, hvis det ikke bliver løst, hvilke løsninger de ser, hvordan de ser den anden parts position, hvad de mener er rigtigt eller forkert osv. Indlæs så meget som muligt af konteksten i dit sind, uden forudindtagethed, og antag, at alle har ret. Du er ikke inde i konflikten; du er udenfor, i en metaposition. Hvis konteksten kun er tilgængelig i e-mail-tråden, så læs hele tråden og de relaterede diskussioner og dokumenter. Efter du har læst det, så tal stadig med stemmen. Du vil næsten helt sikkert høre noget vigtigt, som ikke er i mailen.
Det tredje vigtige punkt er den generelle tilgang til kommunikation. Det er almindelige ting, ingenting spektakulært, men de har stor betydning. Vi forsøger ikke at spare tid, taler med alle deltagere, kritiserer ikke personen, men ser på konsekvenserne af deres handlinger (ikke "du er grov", men "måske kan folk føle sig såret af dette"), giver mulighed for at bevare ansigt, og afholder diskussioner personligt, ikke foran en gruppe.
Konflikter opstår normalt af en af to grunde. Den første handler om, hvorvidt en person under konflikten befinder sig i en voksen- eller barnets position (om dette vil blive uddybet nedenfor). Dette relaterer sig til deres følelsesmæssige modenhed og evnen til at styre deres følelser (hvilket i øvrigt ikke altid er relateret til deres alder). Den anden almindelige årsag er mangler i arbejdsprocessen, som skaber gråzoner, hvor ansvaret er spredt mellem deltagerne, og parternes forventninger ikke er klare for hinanden, og rollerne i processen er uklare.
I konfliktløsning (ligesom i alle andre spørgsmål) skal lederen have tre perspektiver i tankerne: kortsigtet - løse spørgsmålet/konflikten her og nu, mellemsigtet - minimere sandsynligheden for, at en anden konflikt opstår af samme årsag, og langsigtet - at opbygge en kultur af voksne mennesker i teamet.
Vi bærer alle på et indre barn, omkring tre til fire år gammelt. Det meste af tiden sover det på arbejdet, men nogle gange vågner det og tager styringen. Barnet har sine egne prioriteter. Det er vigtigt for det at insistere på, at det er dens sandkasse, at mor elsker det mest, og at dens bil er den bedste (designet er det bedste, det programmerer bedre end alle andre, osv.). I konfliktsituationen kan barnet klemme sine legetøj, stampe med fødderne og slå med skovlen, men det kan ikke løse voksne problemer (løsningens arkitektur, metoder til automatiseret testning, tidsplaner for udgivelser osv.), det tænker ikke i termer af fordel for teamet. Barnet i konflikten kan opmuntres, trøstes og sendes i seng, mens man beder det om at kalde sin voksne. Før diskussionen i en konflikt passerer, skal du sikre dig, at du taler med en voksen og ikke med et barn, og at du selv står på den voksne position. Hvis dit ærlige mål lige nu er at løse et alvorligt spørgsmål, er du i den voksne persons position. Hvis dit mål er at stampe med fødderne og slå med skovlen - så er det en børns position. Send dit indre barn i seng og kald på den voksne, eller udsæt diskussionen. En person træffer følelsesmæssige beslutninger, og derefter søger de en rationel begrundelse for dem. En beslutning truffet af barnet, baseret på børns prioriteter, vil ikke være optimal.
Udover adfærden i konfliktøjeblikket karakteriseres den børne- eller voksenposition, en person indtager, også ved det ansvarsniveau, de er villige til at påtage sig. I ekstreme tilfælde tager en programmerers børneposition ofte form af: jeg har skrevet koden, sendt den til gennemgang — mit arbejde er slut. Gennemgangsteamet skal se på det og fusionere det, QA skal teste det, og hvis der er problemer, så skal de informere mig. Underligt nok opfører selv ret voksne og erfarne personer sig nogle gange på denne måde. Den anden ende af skalaen er, at en person anser sig selv for at være ansvarlig for, at hans kode virker, er dækket af tests, er blevet gennemgået personligt af ham, er blevet godkendt (hvis det er nødvendigt, er der ikke noget problem med at kontakte gennemgangsteamet, diskutere spørgsmål ansigt til ansigt osv.) og er blevet fusioneret, QA vil tilbyde hjælp om nødvendigt, testscenarier vil blive beskrevet osv. I normale tilfælde vil programmereren enten fra starten være tættere på den voksne ende af skalaen, eller bevæge sig derhen, efterhånden som han får erfaring (forudsat at den rigtige kultur dyrkes i teamet). I ekstreme tilfælde fortsætter han med at arbejde med en typisk børneposition, og så opstår der jævnligt problemer og konflikter for ham og teamet.
At skabe en korrekt, voksen kultur i teamet er en vigtig opgave for enhver leder. Det kræver lang tid og daglige anstrengelser, men resultatet er det værd. Der er to måder at påvirke teamkulturen på — personlig indflydelse (som teamet vil følge, da de altid ser på lederen) og diskussion og opmuntring af korrekt adfærd. Her er der ikke noget mystisk eller særligt formelt, blot når man diskuterer problemer, så bemærk, hvad der kunne være gjort anderledes, understreg at du har bemærket det, når der er blevet løst korrekt, ros dem, tag det op ved gennemgangen af udgivelser osv.
Lad os se på nogle typiske konfliktsituationer, fra den simple til den komplekse:
Konflikter, der ikke er relateret til arbejdsopgaver
Ofte opstår der konflikter på arbejdet, som ikke er relateret til arbejdsopgaver. Deres opståen og lethed i løsning er normalt direkte relateret til deltagerne niveau af følelsesmæssig intelligens, deres modenhed og ikke relateret til perfektion eller ufuldkommenhed i arbejdsprocessen.
Typiske eksempler er – nogen bruger ikke vaskemaskinen eller bruseren ofte nok, hvilket irriterer de omkringliggende, nogen har brug for mere luft, mens en anden føler det træk, der opstår, når vinduet åbnes, en person er for højlydt, mens andre har brug for stilhed for at arbejde osv. Det er bedst ikke at trække konflikten i disse tilfælde og lade den gå sin gang. De vil ikke forsvinde af sig selv og vil dagligt tage fokus fra arbejdet og forgifte atmosfæren i teamet. Heldigvis er det normalt ikke et stort problem at løse disse – det kræver blot en rolig snak (selvfølgelig én-til-én) med kollegaen, der forsømmer hygiejnen, tilbyde komfortabel placering for dem, der foretrækker stilhed/temperatur, købe støjreducerende hovedtelefoner eller opsætte skillevægge osv.
Et andet eksempel, jeg har stødt på flere gange i min tid, er den psykologiske inkompatibilitet mellem teammedlemmer. Af en eller anden grund kan folk bare ikke arbejde sammen, og hver kommunikation slutter i skænderi. Nogle gange skyldes det, at folk har diametralt modsatte synspunkter på et eller andet brændende emne (normalt politisk) og ikke kan efterlade dem udenfor arbejdet. At overbevise dem om at tolerere hinanden eller ændre deres adfærd er et ret håbløst projekt. Den eneste undtagelse, jeg har set, er unge kolleger med en åben opfattelse, hvis adfærd endnu kan ændres gradvist gennem periodiske samtaler. Normalt løses spørgsmålet ved at splitte dem op i forskellige teams, eller i det mindste ved at sikre, at de sjældent krydser stierne på arbejdet.
I alle de nævnte situationer bør man tale med alle deltagere enkeltvis, diskutere situationen, spørge dem, om de overhovedet ser et problem i dette tilfælde, og spørge, hvilke løsninger de mener, der er, samt sikre deres deltagelse i beslutningsprocessen.
Set fra et optimeringsperspektiv for arbejdsprocessen (den mellemlang sigt, som jeg nævnte), er der ikke meget, der kan gøres her. Den eneste mulighed for optimering er at tage hensyn til kompatibilitetsfaktoren, når man sammensætter et team og på forhånd undgå at sætte folk sammen, der vil komme til at konflikte.
Set fra teamkulturens perspektiv opstår sådanne situationer meget sjældnere i teams med en m avanceret kultur, hvor folk respekterer teamet og kollegerne og kan løse spørgsmål selvstændigt. Derudover løses sådanne konflikter meget lettere (ofte automatisk) i teams, hvor tillidsniveauet er højt, folk har arbejdet sammen i lang tid og/eller ofte kommunikerer uden for arbejdet.
Konflikter relateret til arbejdsspørgsmål:
Disse konflikter skyldes som regel begge årsager på én gang, både den følelsesmæssige (i det nogen af deltagerne ikke er i en voksen position) og den imperfekte arbejdsproces. Den mest almindelige konflikt, jeg har oplevet, er konflikter under code review eller diskussioner om arkitektur mellem udviklerne.
Jeg ville fremhæve to typiske tilfælde her:
1) I det første tilfælde kan udvikleren ikke få kode review fra en kollega. Patch'en er sendt til review, og der sker intet. Ved første øjekast er der ingen åbenlys konflikt mellem de to parter, men ved nærmere eftertanke er det en reel konflikt. Arbejdsspørgsmålet bliver ikke løst, og den ene part (den der venter på review) oplever åbenlyst ubehag. En ekstrem underkategori af denne situation er udvikling i et community eller i forskellige teams, hvor revieweren måske ikke er interesseret i denne specifikke kode, og på grund af belastning eller andre omstændigheder muligvis slet ikke lægger mærke til anmodningen om review, og der er muligvis slet ingen ekstern dommer (en fælles leder for begge parter).
Tilgangen til løsningen, der hjælper i en sådan situation, handler netop om den langsigtede perspektiv, kulturen for en voksen person. For det første fungerer fornuftig aktivitet. Man skal ikke forvente, at koden, der hænger til gennemgang, selv vil fange gennemgangsmandens opmærksomhed. Man skal hjælpe gennemgængere med at lægge mærke til det. Ping et par personer, stil et spørgsmål på synkroniseringen, deltag i diskussionerne. Det er tydeligt, at insisteren sandsynligvis vil skade mere, end det vil hjælpe, så der skal anvendes sund fornuft. For det andet fungerer forberedelsen godt. Hvis teamet forstår, hvad der sker, og hvorfor, hvorfor denne kode overhovedet er nødvendig, og designet blev diskuteret og godkendt på forhånd af alle, vil folk sandsynligvis lægge mærke til en sådan kode og tage den til sig. For det tredje fungerer autoritet. Hvis du vil have, at din kode bliver gennemgået, så sørg for at lave mange gennemgange selv. Lav kvalitetsgennemgange med reelle kontroller, reelle tests og nyttige kommentarer. Hvis dit navn er kendt i teamet på en god måde, er chancerne større for, at din kode får opmærksomhed.
Fra et arbejdsmæssigt perspektiv er mulige forbedringer her den rigtige prioritering, der er rettet mod at hjælpe udvikleren med at nå sine mål og teamets mål (at gennemgå andres arbejde, skrive indlæg til fællesskabet, ledsage koden med arkitekturbeskrivelser, dokumentation, tests, deltage i diskussioner med fællesskabet osv.), undgå at forlade patches for længe i rækken, og så videre.
2) Den anden almindelige situation med konflikter under kodereview eller design er forskellige synspunkter på tekniske spørgsmål, kodningsstil og valg af værktøjer. Det er af stor betydning for tillidsniveauet mellem deltagerne, tilhørigheden til det samme team, samt erfaringen med samarbejde. Deadlock opstår, når en af deltagerne indtager en barnlig position og ikke prøver at høre, hvad samtalepartneren prøver at formidle. Ofte kan både den tilgang, der foreslås af den anden part, og den tilgang, der oprindeligt blev foreslået, fungere med succes og er ikke principielt vigtige for valget.
En gang forberedte en programmer fra mit team (lad os kalde ham Pasha) en patch med ændringer til pakkeimplementeringssystemet, som blev udviklet og vedligeholdt af kolleger fra en nærliggende afdeling. En af dem (Igor) havde en stærk mening om, hvordan Linux-tjenester skulle konfigureres ved implementeringen af pakker. Denne mening adskilte sig fra den tilgang, der blev foreslået i patchen, og de kunne ikke blive enige. Som sædvanligt pressede tidsfristerne, og det var nødvendigt at finde en løsning — nogen måtte tage en voksens position. Pasha anerkendte, at begge tilgange havde deres ret til at eksistere, men han ønskede, at hans version skulle godkendes, da der ikke var nogen åbenlyse tekniske fordele ved den ene eller den anden.
Vores diskussion så omtrent således ud (temmelig skematiske, selvfølgelig, samtalen varede en halv time):
— Pasha, vi har feature freeze om et par dage. Det er vigtigt, at vi får alt samlet og begynder testen så hurtigt som muligt. Hvordan kommer vi forbi Igor?
— Han ønsker at konfigurere tjenesterne anderledes, han har smidt en hel del kommentarer på mig ...
— Og hvad er der, store ændringer, meget arbejde?
— Nej, der er arbejde for et par timer, men i sidste ende gør det ikke nogen forskel, begge metoder fungerer. Hvorfor er det nødvendigt? Jeg har lavet noget, der virker, lad os tage det.
— Hør, hvor længe har I allerede diskuteret det hele?
— Vi har faktisk været i gang i halvanden uge.
— Øhm ... kan vi ikke på et par timer løse et problem, der allerede har taget halvanden uge, og ikke gøre det?
— Nå, ja, men jeg vil ikke have, at Igor tænker, at jeg gav op ...
— Hør, hvad er vigtigere for dig — at få udgivet versionen med din løsning inde i den, eller at besejre Igor? Vi kan besejre ham, men så er der en god chance for, at vi missede udgivelsen.
— Nå ... det ville selvfølgelig være sjovt at få snuden på Igor, men fint, udgivelsen er vigtigere, jeg er enig.
— Er det virkelig så vigtigt for dig, hvad Igor tænker? Ærligt talt, han er ligeglad, han vil bare have en ensartet tilgang i forskellige dele af det, han ansvarer for.
— Nå, okay, lad mig gøre det, som han beder om i kommentarerne, og så starter vi testen.
— Tak, Pasha! Jeg var sikker på, at du ville vise dig som den mere modne af de to, selvom Igor er ældre end dig :)
Spørgsmålet blev løst, udgivelsen blev frigivet til tiden, Pasha følte ikke nogen særlig utilfredshed, da han selv foreslog løsningen og gennemførte den. Igor var generelt tilfreds, da hans mening blev taget i betragtning, og de gjorde det, som han havde foreslået.
En anden form for den samme konflikt er valget mellem tekniske løsninger/biblioteker/metoder i projektet, især i et distribueret team. I et af de projekter, der blev præsenteret som værende baseret på C/C++, viste det sig, at projektets tekniske ledelse var kategorisk imod brugen af STL (Standard Template Library). Dette er et standardbibliotek for sproget, som forenkler udviklingen, og vores team var meget vant til det. Det viste sig, at projektet var meget tættere på C end på C++, hvilket ikke gjorde teamet særlig inspireret, da ledelsen havde arbejdet hårdt for at samle nogle virkelig dygtige C++-udviklere. Samtidig havde den amerikanske del af teamet, både ingeniører og ledere, arbejdet i virksomheden i lang tid, tilpasset sig den nuværende situation, og de var tilfredse. Den russiske del af teamet blev derimod samlet for nylig, kun få uger før (herunder mig). Den russiske del af teamet ønskede kategorisk ikke at opgive den velkendte tilgang til udvikling.
Der begyndte uendelige skriftlige diskussioner mellem de to kontinenter, emails med tre-fire skærme fløj frem og tilbage, både i gruppe-mail og personligt, fra programmører til programmører og ledere. Som det ofte sker, blev emails af denne størrelse ikke læst af nogen, undtagen forfatterne og deres ivrige tilhængere. Chats knirkede af spændinger, idet de sendte mange-skærms overvejelser frem og tilbage om de tekniske fordele ved STL, hvor godt den er testet, hvor sikker den er, og generelt hvor vidunderligt livet er med den, og hvor forfærdeligt det er uden.
Det tog ret lang tid, før jeg endelig indså, at vi diskuterede de tekniske aspekter af spørgsmålet, men problemet var i virkeligheden ikke teknisk. Problemet lå ikke i fordele eller ulemper ved STL eller i kompleksiteten ved at arbejde uden den. Problemet var snarere organisatorisk. Vi skulle blot forstå, hvordan virksomheden, vi arbejdede for, var organiseret. Ingen af os havde tidligere erfaring med at arbejde i en sådan virksomhed. Efter udviklingen af koden og dens udrulning til produktion, blev vedligeholdelsen udført af helt andre mennesker fra andre teams i andre lande. Dette enorme ingeniørteam bestående af flere tusinde ingeniører kunne kun tillade sig det helt basale minimum af tekniske midler, så at sige, minimum minimorum. Alt, hvad der gik ud over den ingeniørmæssige standard, der var fastsat i virksomheden, kunne ikke under nogen omstændigheder blive understøttet efterfølgende. Niveauet for et team bestemmes af niveauet af dets svageste medlemmer. Efter at vi forstod den reelle motivation bag handlingerne fra den amerikanske del af teamet, blev dette spørgsmål fjernet fra dagsordenen, og vi udviklede og lancerede sammen produktet, ved hjælp af de standarder, der var fastsat i virksomheden. I dette tilfælde fungerede e-mails og chats dårligt, og for at nå til enighed krævede det flere rejser og meget personligt samvær.
Set fra et arbejdsprocessuelt perspektiv, ville tilstedeværelsen af en beskrivelse af de anvendte værktøjer, kravene til dem, begrænsninger for tilføjelse af nye, samt en begrundelse for sådanne begrænsninger, have været nyttigt i denne specifikke situation. Sådanne dokumenter svarer nogenlunde til det, der er beskrevet i punkterne Reuse Strategy og Development Environment i håndbogen “Manager’s Handbook for Software Development”, udarbejdet i . På trods af sin alder beskriver den glimrende alle de grundlæggende aktiviteter og faser i planlægningen af softwareudvikling af denne art. Tilstedeværelsen af sådanne dokumenter gør det meget nemmere at diskutere, hvilke komponenter og tilgange der kan anvendes i produktet, og hvorfor.
Fra et kulturelt perspektiv ville det være åbenlyst, at med en mere moden tilgang, hvor parterne forsøger at høre og forstå den reelle motivation bag kollegaernes handlinger og handler ud fra projektets og teamets prioriteter snarere end personlig ego, ville konflikten være blevet løst lettere og hurtigere.
I en anden konflikt, der opstod på grund af valget af teknisk løsning, tog det mig også betydelig tid at forstå motivationen for en af parterne (det var en meget usædvanlig sag), men efter at motivationen var klar, var løsningen åbenlys.
Situationen er sådan: I et team på cirka 20 personer kommer der en ny udvikler, lad os kalde ham Stas. Vores standardværktøj til kommunikation i teamet var på det tidspunkt Skype. Som det senere viste sig, var Stas en stor fan af åbne standarder og open source-software og brugte kun værktøjer og operativsystemer, hvis kildekode er offentligt tilgængelig, og som anvender offentligt beskrevede protokoller. Skype hører ikke til disse værktøjer. Vi brugte en enorm mængde tid på at diskutere fordele og ulemper ved denne tilgang, forsøge at køre alternativer til Skype på forskellige operativsystemer, Stas' forsøg på at overtale teamet til at skifte til andre standarder, skrive til ham personligt via e-mail, ringe til ham personligt via telefon, købe en anden computer specielt til Skype, osv. Endelig indså jeg, at dette problem i sin essens ikke var teknisk eller organisatorisk; det var snarere verdensanskuelsesmæssigt, ja, man kunne endda sige religiøst (for Stas). Selv hvis vi til slut fik Stas til at bruge Skype (hvilket tog flere måneder), ville problemet opstå igen med det næste værktøj. Jeg havde ikke reelle midler til at ændre Stas' verdensopfattelse, og der var ikke nogen grund til at forsøge at ændre verdensopfattelsen for teamet, som fungerede fint i dette miljø. Mennesket og virksomheden var simpelthen ortogonale i deres verdensanskuelse. I sådanne situationer er en god løsning organisatorisk. Vi flyttede Stas til et andet team, hvor han var mere i harmoni.
Årsagen til denne konflikt ligger, efter min mening, i uoverensstemmelsen mellem den personlige kultur hos en specifik person (som har en stærk mening, der forhindrer ham i at gå på kompromis) og virksomhedens kultur. I dette tilfælde er det selvfølgelig en fejl fra lederens side. Det var forkert fra starten af at ansætte ham til et projekt af denne art. Stas sluttede med at gå over til et projekt om udvikling af open source-software, hvor han klarede sig fremragende.
Et godt eksempel på en konflikt, der opstår på grund af både udviklerens børnelige tilgang og mangler i arbejdsgangen - en situation hvor, i fraværet af en definition af færdig, har udvikleren og QA-teamet forskellige forventninger til, hvornår en funktion er klar til QA. Udvikleren mente, det var tilstrækkeligt at skrive koden og sende funktionen over til QA - de ville finde ud af det der. Det var faktisk en ret erfaren programmør, men han havde bare en lavere kvalitetsstandard. QA var uenige i dette og krævede at få vist og beskrevet, hvad han selv havde verificeret, og de insisterede på et testscenarie til dem. De havde tidligere haft problemer med funktionaliteten fra denne udvikler og ønskede ikke at spilde tid igen. For øvrigt havde de ret - funktionen virkede faktisk ikke, koden blev ikke verificeret før overdragelse til QA.
For at løse situationen bad jeg ham vise mig, at alt faktisk fungerede (det gjorde det ikke, og han måtte rette det), vi diskuterede definitionen af færdig med teamet og QA (vi gjorde det ikke skriftligt, da vi ikke ønskede at gøre processen for bureaukratisk), og med denne specialist adskilte vi os snart (til alles lettelse).
Set fra et arbejdsgangsperspektiv er de mulige forbedringer i dette tilfælde - tilstedeværelsen af en definition af færdig, krav til at hver funktion skal have enhed og integrationstest, samt beskrivelse af testningen udført af udvikleren. I et af projekterne målte vi dækningen af koden med tests under CI, og hvis dækningen faldt efter tilføjelse af en patch, blev testene markeret som ikke bestået, dvs. enhver ny kode kunne kun tilføjes, hvis der også blev tilføjet nye tests til den.
Endnu et klassisk eksempel på en konflikt, der er tæt relateret til organiseringen af arbejdsprocessen. Vi har et produkt, et udviklingsteam for dette produkt, et supportteam og en kunde. Kunden oplever problemer med produktet og kontakter supporten. Supporten analyserer problemet og indser, at problemet ligger i produktet, hvorefter de videreformidler problemet til produktteamet. Produktteamet har travlt, da en udgivelse nærmer sig, så ticketen med problemet fra kunden, der er blevet overset blandt de andre tickets til udvikleren, der er tildelt den, hænger flere uger uden opmærksomhed. Supporten tror, at udvikleren arbejder på kundens problem. Kunden venter og håber, at der arbejdes på hans problem. I virkeligheden sker der ikke noget. Efter et par uger beslutter kunden endelig at spørge om fremdriften og kontakter supporten. Supporten spørger udviklingen. Udvikleren ryster på hovedet, gennemgår ticketlisten og opdager kunden ticketen. Ved at læse ticketen fra kunden forstår han, at der ikke er tilstrækkelig information til at løse problemet, og han har brug for flere logs og dumps. Supporten anmoder om yderligere information fra kunden. Og her indser kunden, at der ikke har været nogen, der har arbejdet på hans problem hele tiden. Og der vil komme torden …
I denne situation er løsningen på selve konflikten ret åbenlys og lige til (fiks produktet, opdater dokumentationen og testene, berolig kunden, udsend en hotfix, osv.). Det er vigtigt at analysere arbejdsprocessen og forstå, hvem der har ansvaret for at organisere samarbejdet mellem de to teams, og hvorfor denne situation overhovedet kunne opstå. Det står klart, at noget skal rettes i processen — nogen skal overvåge det overordnede billede uden påmindelser fra kunderne, proaktivt. Tickets fra kunderne skal fremhæves blandt de andre tickets hos udviklerne. Supporten skal kunne se, om udviklingen arbejder på deres tickets i øjeblikket; hvis ikke, hvornår de kan begynde at arbejde, og hvornår resultaterne kan forventes. Support og udvikling skal kommunikere og diskutere status for tickets regelmæssigt, og indsamlingen af den nødvendige information til fejlfinding skal være så automatiseret som muligt, osv.
Som i krig forsøger modstanderen at ramme forbindelsen mellem to enheder, er det i arbejdet typisk det mest skrøbelige og sårbare punkt, der viser sig at være samarbejdet mellem teams. Hvis support- og udviklingscheferne er voksne nok, kan de selv reparere processen, hvis ikke, vil processen fortsætte med at skabe konflikter og problemer, indtil en leder griber ind og kan rette op på situationen.
Et andet karakteristisk eksempel, som jeg ofte har set i forskellige virksomheder, er den situation, hvor produktet udvikles af én gruppe, automatiserede integrationstest udføres af en anden gruppe, og infrastrukturen, hvori alt dette kører, vedligeholdes af en tredje gruppe. Problemer opstår konstant under testkørslerne, og årsagerne til problemerne kan være både produktet, testene og infrastrukturen. Det er normalt problematisk at blive enige om, hvem der skal lave den første analyse af problemerne, indberette fejl, analysere logfiler fra produktet, testene og infrastrukturen osv. Konflikter her er ret almindelige og samtidig ensartede. I tilfælde af høj følelsesmæssig intensitet falder deltagerne ofte ind i en barnlig position, og diskussionerne begynder i stil med: "hvorfor skal jeg have med det at gøre", "de har oftere problemer", osv.
Set fra et arbejdsprocessuelt perspektiv afhænger de specifikke skridt til at løse problemet af teamenes sammensætning, typen af test og produktet osv. I et af projekterne indførte vi regelmæssige vagtordninger, hvor teamene overvågede testene på skift, uge for uge. I et andet projekt blev den første analyse altid udført af testudviklerne, men analysen var ret grundlæggende, og produktet var tilstrækkeligt stabilt, så det fungerede ganske godt. Hovedpointen er at sikre gennemsigtighed i processen, tydelighed i forventningerne for alle parter og en følelse af retfærdighed i situationen for alle.
Er konflikt overhovedet et problem i organisationen, eller er det et dårligt tegn, at der ofte (eller blot indimellem) opstår konflikter i dit team? Generelt nej, for hvis der er vækst, udvikling, eller en eller anden dynamik, vil der opstå spørgsmål, der aldrig tidligere har været løst, og konflikt kan opstå i forbindelse med deres løsning. Det er en indikator på, at der er områder, der kræver opmærksomhed, og at der er plads til forbedringer. Det er dårligt, hvis konflikter opstår meget ofte, og de er svære eller langvarige at løse. Dette er sandsynligvis et tegn på, at arbejdsprocesserne ikke er tilstrækkeligt finjusterede, og at teamet ikke er tilstrækkeligt modent.
Kilde: habr.com
