<\/a><\/noindex>For det andet, i en konflikt situation p\u00e5 arbejdet befinder parterne sig i en situation, hvor de skal l\u00f8se et sp\u00f8rgsm\u00e5l, der er vigtigt for en af parterne, for begge eller for organisationen som helhed. P\u00e5 grund af situationens karakter har parterne normalt tilstr\u00e6kkelig tid og forskellige m\u00e5der at l\u00f8se det p\u00e5 (formelle, uformelle, m\u00f8der, breve, ledelsens beslutninger, tilstedev\u00e6relsen af m\u00e5l og teamplaner, hierarkiets eksistens, osv.). Dette adskiller sig fra situationen, hvor man skal l\u00f8se et arbejdsrelateret (eller ikke-arbejdsrelateret) sp\u00f8rgsm\u00e5l i organisationen, som for eksempel n\u00e5r man siger: \u201cHey, fyr, hvilken by er du fra?!\u201d p\u00e5 gaden, eller konflikten fra epigrafen. Ved l\u00f8sning af arbejdsrelaterede sp\u00f8rgsm\u00e5l er kvaliteten af arbejdsprocessen og kulturen omkring probleml\u00f8sning i teamet afg\u00f8rende.<\/p>\n
For det tredje er en afg\u00f8rende faktor i konflikten (set i lyset af vores diskussion) det faktum, at parterne i processen ikke kan komme til en enighed om en l\u00f8sning, der tilfredsstiller alle. Situationen kr\u00e6ver indblanding fra en tredjepart, en ekstern voldgiftsmand. Dette punkt kan virke omstridt, men i virkeligheden, hvis den konfliktfyldte situation blev l\u00f8st uden indblanding fra en ekstern voldgiftsmand, og sp\u00f8rgsm\u00e5let er blevet l\u00f8st tilfredsstillende uden at forholdet mellem parterne er forv\u00e6rret, er det den situation, man b\u00f8r str\u00e6be efter. En s\u00e5dan konflikt vil vi sandsynligvis ikke engang f\u00e5 kendskab til, eller vi vil tilf\u00e6ldigt h\u00f8re om den efter dens l\u00f8sning. Jo flere sp\u00f8rgsm\u00e5l teamet kan l\u00f8se selvst\u00e6ndigt, desto mere effektivt vil det arbejde.<\/p>\n
En anden karakteristisk egenskab ved konflikten, som er v\u00e6rd at n\u00e6vne, er graden af f\u00f8lelsesm\u00e6ssig intensitet under l\u00f8sningen. Konflikten er ikke n\u00f8dvendigvis forbundet med et h\u00f8jt f\u00f8lelsesm\u00e6ssigt niveau. Deltagerne beh\u00f8ver ikke at r\u00e5be og vifte med h\u00e6nderne for, at situationen reelt kan v\u00e6re konfliktfyldt. Hvis et sp\u00f8rgsm\u00e5l ikke bliver l\u00f8st, og der er en vis f\u00f8lelsesm\u00e6ssig sp\u00e6nding til stede (m\u00e5ske ikke \u00e5benlyst udtrykt), s\u00e5 er vi i en konflikt situation.<\/p>\n
Skal man overhovedet gribe ind i konfliktfyldte situationer, eller er det bedre at lade dem l\u00f8se sig selv og vente p\u00e5, at problemet forsvinder af sig selv? Ja, det skal man. Det er ikke altid i ens magt eller kompetence at l\u00f8se konflikten fuldst\u00e6ndigt, men i enhver situation, uanset konfliktens omfang, kan du indtage en voksen position, hvorved du ogs\u00e5 kan l\u00f8fte andre omkring dig, mildne den negative indflydelse af konflikten og bidrage til dens l\u00f8sning.<\/p>\n
F\u00f8r vi ser p\u00e5 nogle eksempler p\u00e5 konfliktfyldte situationer, lad os kort fokusere p\u00e5 nogle vigtige punkter, der g\u00e6lder for alle konflikter.<\/p>\n
N\u00e5r du skal l\u00f8se en konflikt, er det vigtigt at v\u00e6re over konflikten og ikke indg\u00e5 i den (dette kaldes ogs\u00e5 at indtage en metaposition), hvilket betyder, at du ikke skal v\u00e6re en del af \u00e9n af parterne i l\u00f8sningen. Ellers vil du som en ekstern m\u00e6gler, der hj\u00e6lper med l\u00f8sningen, blot forst\u00e6rke den ene sides position p\u00e5 bekostning af den anden. N\u00e5r der tr\u00e6ffes beslutninger, er det vigtigt, at de er moralsk acceptable for alle parter, som man siger, 'k\u00f8bt'. S\u00e5 selvom parterne ikke er begejstrede for den tr\u00e6ffede beslutning, skal de i det mindste v\u00e6re oprigtigt enige om at f\u00f8lge den. Man skal kunne sige, at man er uenig, men alligevel forpligte sig. Ellers vil konflikten blot \u00e6ndre form; den gl\u00f8dende ild vil forblive under overfladen og uundg\u00e5eligt blusse op igen p\u00e5 et tidspunkt.<\/p>\n
Det andet punkt, der delvist er relateret til det f\u00f8rste, er, at hvis du har besluttet dig for at deltage i konfliktl\u00f8sningen, s\u00e5 tag det meget alvorligt med hensyn til kommunikation og kontekstforst\u00e5else. Tal personligt med hver af parterne. Start med at tale med dem hver for sig. V\u00e6r ikke tilfreds med bare at bruge e-mail. I tilf\u00e6lde af et distribueret team, s\u00e5 tal mindst over video. V\u00e6r ikke tilfreds med rygter og vidnefortalelser. Forst\u00e5 historien, hvad hver part \u00f8nsker, hvorfor de \u00f8nsker det, hvad de forventer, om de har pr\u00f8vet at l\u00f8se dette problem tidligere, hvad der vil ske, hvis det ikke bliver l\u00f8st, hvilke l\u00f8sninger de ser, hvordan de ser den anden parts position, hvad de mener er rigtigt eller forkert osv. Indl\u00e6s s\u00e5 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\u00e6ngelig i e-mail-tr\u00e5den, s\u00e5 l\u00e6s hele tr\u00e5den og de relaterede diskussioner og dokumenter. Efter du har l\u00e6st det, s\u00e5 tal stadig med stemmen. Du vil n\u00e6sten helt sikkert h\u00f8re noget vigtigt, som ikke er i mailen.<\/p>\n
Det tredje vigtige punkt er den generelle tilgang til kommunikation. Det er almindelige ting, ingenting spektakul\u00e6rt, men de har stor betydning. Vi fors\u00f8ger ikke at spare tid, taler med alle deltagere, kritiserer ikke personen, men ser p\u00e5 konsekvenserne af deres handlinger (ikke \"du er grov\", men \"m\u00e5ske kan folk f\u00f8le sig s\u00e5ret af dette\"), giver mulighed for at bevare ansigt, og afholder diskussioner personligt, ikke foran en gruppe.<\/p>\n
Konflikter opst\u00e5r normalt af en af to grunde. Den f\u00f8rste 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\u00f8lelsesm\u00e6ssige modenhed og evnen til at styre deres f\u00f8lelser (hvilket i \u00f8vrigt ikke altid er relateret til deres alder). Den anden almindelige \u00e5rsag er mangler i arbejdsprocessen, som skaber gr\u00e5zoner, hvor ansvaret er spredt mellem deltagerne, og parternes forventninger ikke er klare for hinanden, og rollerne i processen er uklare. <\/p>\n
I konfliktl\u00f8sning (ligesom i alle andre sp\u00f8rgsm\u00e5l) skal lederen have tre perspektiver i tankerne: kortsigtet - l\u00f8se sp\u00f8rgsm\u00e5let\/konflikten her og nu, mellemsigtet - minimere sandsynligheden for, at en anden konflikt opst\u00e5r af samme \u00e5rsag, og langsigtet - at opbygge en kultur af voksne mennesker i teamet. <\/p>\n
Vi b\u00e6rer alle p\u00e5 et indre barn, omkring tre til fire \u00e5r gammelt. Det meste af tiden sover det p\u00e5 arbejdet, men nogle gange v\u00e5gner det og tager styringen. Barnet har sine egne prioriteter. Det er vigtigt for det at insistere p\u00e5, 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\u00f8j, stampe med f\u00f8dderne og sl\u00e5 med skovlen, men det kan ikke l\u00f8se voksne problemer (l\u00f8sningens arkitektur, metoder til automatiseret testning, tidsplaner for udgivelser osv.), det t\u00e6nker ikke i termer af fordel for teamet. Barnet i konflikten kan opmuntres, tr\u00f8stes og sendes i seng, mens man beder det om at kalde sin voksne. F\u00f8r 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\u00e5r p\u00e5 den voksne position. Hvis dit \u00e6rlige m\u00e5l lige nu er at l\u00f8se et alvorligt sp\u00f8rgsm\u00e5l, er du i den voksne persons position. Hvis dit m\u00e5l er at stampe med f\u00f8dderne og sl\u00e5 med skovlen - s\u00e5 er det en b\u00f8rns position. Send dit indre barn i seng og kald p\u00e5 den voksne, eller uds\u00e6t diskussionen. En person tr\u00e6ffer f\u00f8lelsesm\u00e6ssige beslutninger, og derefter s\u00f8ger de en rationel begrundelse for dem. En beslutning truffet af barnet, baseret p\u00e5 b\u00f8rns prioriteter, vil ikke v\u00e6re optimal.<\/p>\n
Udover adf\u00e6rden i konflikt\u00f8jeblikket karakteriseres den b\u00f8rne- eller voksenposition, en person indtager, ogs\u00e5 ved det ansvarsniveau, de er villige til at p\u00e5tage sig. I ekstreme tilf\u00e6lde tager en programmerers b\u00f8rneposition ofte form af: jeg har skrevet koden, sendt den til gennemgang \u2014 mit arbejde er slut. Gennemgangsteamet skal se p\u00e5 det og fusionere det, QA skal teste det, og hvis der er problemer, s\u00e5 skal de informere mig. Underligt nok opf\u00f8rer selv ret voksne og erfarne personer sig nogle gange p\u00e5 denne m\u00e5de. Den anden ende af skalaen er, at en person anser sig selv for at v\u00e6re ansvarlig for, at hans kode virker, er d\u00e6kket af tests, er blevet gennemg\u00e5et personligt af ham, er blevet godkendt (hvis det er n\u00f8dvendigt, er der ikke noget problem med at kontakte gennemgangsteamet, diskutere sp\u00f8rgsm\u00e5l ansigt til ansigt osv.) og er blevet fusioneret, QA vil tilbyde hj\u00e6lp om n\u00f8dvendigt, testscenarier vil blive beskrevet osv. I normale tilf\u00e6lde vil programmereren enten fra starten v\u00e6re t\u00e6ttere p\u00e5 den voksne ende af skalaen, eller bev\u00e6ge sig derhen, efterh\u00e5nden som han f\u00e5r erfaring (forudsat at den rigtige kultur dyrkes i teamet). I ekstreme tilf\u00e6lde forts\u00e6tter han med at arbejde med en typisk b\u00f8rneposition, og s\u00e5 opst\u00e5r der j\u00e6vnligt problemer og konflikter for ham og teamet.<\/p>\n
At skabe en korrekt, voksen kultur i teamet er en vigtig opgave for enhver leder. Det kr\u00e6ver lang tid og daglige anstrengelser, men resultatet er det v\u00e6rd. Der er to m\u00e5der at p\u00e5virke teamkulturen p\u00e5 \u2014 personlig indflydelse (som teamet vil f\u00f8lge, da de altid ser p\u00e5 lederen) og diskussion og opmuntring af korrekt adf\u00e6rd. Her er der ikke noget mystisk eller s\u00e6rligt formelt, blot n\u00e5r man diskuterer problemer, s\u00e5 bem\u00e6rk, hvad der kunne v\u00e6re gjort anderledes, understreg at du har bem\u00e6rket det, n\u00e5r der er blevet l\u00f8st korrekt, ros dem, tag det op ved gennemgangen af udgivelser osv.<\/p>\n
Lad os se p\u00e5 nogle typiske konfliktsituationer, fra den simple til den komplekse:<\/p>\n
Konflikter, der ikke er relateret til arbejdsopgaver<\/b><\/p>\n
Ofte opst\u00e5r der konflikter p\u00e5 arbejdet, som ikke er relateret til arbejdsopgaver. Deres opst\u00e5en og lethed i l\u00f8sning er normalt direkte relateret til deltagerne niveau af f\u00f8lelsesm\u00e6ssig intelligens, deres modenhed og ikke relateret til perfektion eller ufuldkommenhed i arbejdsprocessen.<\/p>\n
Typiske eksempler er \u2013 nogen bruger ikke vaskemaskinen eller bruseren ofte nok, hvilket irriterer de omkringliggende, nogen har brug for mere luft, mens en anden f\u00f8ler det tr\u00e6k, der opst\u00e5r, n\u00e5r vinduet \u00e5bnes, en person er for h\u00f8jlydt, mens andre har brug for stilhed for at arbejde osv. Det er bedst ikke at tr\u00e6kke konflikten i disse tilf\u00e6lde og lade den g\u00e5 sin gang. De vil ikke forsvinde af sig selv og vil dagligt tage fokus fra arbejdet og forgifte atmosf\u00e6ren i teamet. Heldigvis er det normalt ikke et stort problem at l\u00f8se disse \u2013 det kr\u00e6ver blot en rolig snak (selvf\u00f8lgelig \u00e9n-til-\u00e9n) med kollegaen, der fors\u00f8mmer hygiejnen, tilbyde komfortabel placering for dem, der foretr\u00e6kker stilhed\/temperatur, k\u00f8be st\u00f8jreducerende hovedtelefoner eller ops\u00e6tte skillev\u00e6gge osv. <\/p>\n
Et andet eksempel, jeg har st\u00f8dt p\u00e5 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\u00e6nderi. Nogle gange skyldes det, at folk har diametralt modsatte synspunkter p\u00e5 et eller andet br\u00e6ndende emne (normalt politisk) og ikke kan efterlade dem udenfor arbejdet. At overbevise dem om at tolerere hinanden eller \u00e6ndre deres adf\u00e6rd er et ret h\u00e5bl\u00f8st projekt. Den eneste undtagelse, jeg har set, er unge kolleger med en \u00e5ben opfattelse, hvis adf\u00e6rd endnu kan \u00e6ndres gradvist gennem periodiske samtaler. Normalt l\u00f8ses sp\u00f8rgsm\u00e5let ved at splitte dem op i forskellige teams, eller i det mindste ved at sikre, at de sj\u00e6ldent krydser stierne p\u00e5 arbejdet.<\/p>\n
I alle de n\u00e6vnte situationer b\u00f8r man tale med alle deltagere enkeltvis, diskutere situationen, sp\u00f8rge dem, om de overhovedet ser et problem i dette tilf\u00e6lde, og sp\u00f8rge, hvilke l\u00f8sninger de mener, der er, samt sikre deres deltagelse i beslutningsprocessen.<\/p>\n
Set fra et optimeringsperspektiv for arbejdsprocessen (den mellemlang sigt, som jeg n\u00e6vnte), er der ikke meget, der kan g\u00f8res her. Den eneste mulighed for optimering er at tage hensyn til kompatibilitetsfaktoren, n\u00e5r man sammens\u00e6tter et team og p\u00e5 forh\u00e5nd undg\u00e5 at s\u00e6tte folk sammen, der vil komme til at konflikte. <\/p>\n
Set fra teamkulturens perspektiv opst\u00e5r s\u00e5danne situationer meget sj\u00e6ldnere i teams med en m avanceret kultur, hvor folk respekterer teamet og kollegerne og kan l\u00f8se sp\u00f8rgsm\u00e5l selvst\u00e6ndigt. Derudover l\u00f8ses s\u00e5danne konflikter meget lettere (ofte automatisk) i teams, hvor tillidsniveauet er h\u00f8jt, folk har arbejdet sammen i lang tid og\/eller ofte kommunikerer uden for arbejdet.<\/p>\n
Konflikter relateret til arbejdssp\u00f8rgsm\u00e5l:<\/b><\/p>\n
Disse konflikter skyldes som regel begge \u00e5rsager p\u00e5 \u00e9n gang, b\u00e5de den f\u00f8lelsesm\u00e6ssige (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. <\/p>\n
Jeg ville fremh\u00e6ve to typiske tilf\u00e6lde her:<\/p>\n
1) I det f\u00f8rste tilf\u00e6lde kan udvikleren ikke f\u00e5 kode review fra en kollega. Patch'en er sendt til review, og der sker intet. Ved f\u00f8rste \u00f8jekast er der ingen \u00e5benlys konflikt mellem de to parter, men ved n\u00e6rmere eftertanke er det en reel konflikt. Arbejdssp\u00f8rgsm\u00e5let bliver ikke l\u00f8st, og den ene part (den der venter p\u00e5 review) oplever \u00e5benlyst ubehag. En ekstrem underkategori af denne situation er udvikling i et community eller i forskellige teams, hvor revieweren m\u00e5ske ikke er interesseret i denne specifikke kode, og p\u00e5 grund af belastning eller andre omst\u00e6ndigheder muligvis slet ikke l\u00e6gger m\u00e6rke til anmodningen om review, og der er muligvis slet ingen ekstern dommer (en f\u00e6lles leder for begge parter). <\/p>\n
Tilgangen til l\u00f8sningen, der hj\u00e6lper i en s\u00e5dan situation, handler netop om den langsigtede perspektiv, kulturen for en voksen person. For det f\u00f8rste fungerer fornuftig aktivitet. Man skal ikke forvente, at koden, der h\u00e6nger til gennemgang, selv vil fange gennemgangsmandens opm\u00e6rksomhed. Man skal hj\u00e6lpe gennemg\u00e6ngere med at l\u00e6gge m\u00e6rke til det. Ping et par personer, stil et sp\u00f8rgsm\u00e5l p\u00e5 synkroniseringen, deltag i diskussionerne. Det er tydeligt, at insisteren sandsynligvis vil skade mere, end det vil hj\u00e6lpe, s\u00e5 der skal anvendes sund fornuft. For det andet fungerer forberedelsen godt. Hvis teamet forst\u00e5r, hvad der sker, og hvorfor, hvorfor denne kode overhovedet er n\u00f8dvendig, og designet blev diskuteret og godkendt p\u00e5 forh\u00e5nd af alle, vil folk sandsynligvis l\u00e6gge m\u00e6rke til en s\u00e5dan kode og tage den til sig. For det tredje fungerer autoritet. Hvis du vil have, at din kode bliver gennemg\u00e5et, s\u00e5 s\u00f8rg for at lave mange gennemgange selv. Lav kvalitetsgennemgange med reelle kontroller, reelle tests og nyttige kommentarer. Hvis dit navn er kendt i teamet p\u00e5 en god m\u00e5de, er chancerne st\u00f8rre for, at din kode f\u00e5r opm\u00e6rksomhed.<\/p>\n
Fra et arbejdsm\u00e6ssigt perspektiv er mulige forbedringer her den rigtige prioritering, der er rettet mod at hj\u00e6lpe udvikleren med at n\u00e5 sine m\u00e5l og teamets m\u00e5l (at gennemg\u00e5 andres arbejde, skrive indl\u00e6g til f\u00e6llesskabet, ledsage koden med arkitekturbeskrivelser, dokumentation, tests, deltage i diskussioner med f\u00e6llesskabet osv.), undg\u00e5 at forlade patches for l\u00e6nge i r\u00e6kken, og s\u00e5 videre. <\/p>\n
2) Den anden almindelige situation med konflikter under kodereview eller design er forskellige synspunkter p\u00e5 tekniske sp\u00f8rgsm\u00e5l, kodningsstil og valg af v\u00e6rkt\u00f8jer. Det er af stor betydning for tillidsniveauet mellem deltagerne, tilh\u00f8righeden til det samme team, samt erfaringen med samarbejde. Deadlock opst\u00e5r, n\u00e5r en af deltagerne indtager en barnlig position og ikke pr\u00f8ver at h\u00f8re, hvad samtalepartneren pr\u00f8ver at formidle. Ofte kan b\u00e5de den tilgang, der foresl\u00e5s af den anden part, og den tilgang, der oprindeligt blev foresl\u00e5et, fungere med succes og er ikke principielt vigtige for valget. <\/p>\n
En gang forberedte en programmer fra mit team (lad os kalde ham Pasha) en patch med \u00e6ndringer til pakkeimplementeringssystemet, som blev udviklet og vedligeholdt af kolleger fra en n\u00e6rliggende afdeling. En af dem (Igor) havde en st\u00e6rk mening om, hvordan Linux-tjenester skulle konfigureres ved implementeringen af pakker. Denne mening adskilte sig fra den tilgang, der blev foresl\u00e5et i patchen, og de kunne ikke blive enige. Som s\u00e6dvanligt pressede tidsfristerne, og det var n\u00f8dvendigt at finde en l\u00f8sning \u2014 nogen m\u00e5tte tage en voksens position. Pasha anerkendte, at begge tilgange havde deres ret til at eksistere, men han \u00f8nskede, at hans version skulle godkendes, da der ikke var nogen \u00e5benlyse tekniske fordele ved den ene eller den anden. <\/p>\n
Vores diskussion s\u00e5 omtrent s\u00e5ledes ud (temmelig skematiske, selvf\u00f8lgelig, samtalen varede en halv time): <\/p>\n
\u2014 Pasha, vi har feature freeze om et par dage. Det er vigtigt, at vi f\u00e5r alt samlet og begynder testen s\u00e5 hurtigt som muligt. Hvordan kommer vi forbi Igor?
Sp\u00f8rgsm\u00e5let blev l\u00f8st, udgivelsen blev frigivet til tiden, Pasha f\u00f8lte ikke nogen s\u00e6rlig utilfredshed, da han selv foreslog l\u00f8sningen og gennemf\u00f8rte den. Igor var generelt tilfreds, da hans mening blev taget i betragtning, og de gjorde det, som han havde foresl\u00e5et.<\/p>\n
En anden form for den samme konflikt er valget mellem tekniske l\u00f8sninger\/biblioteker\/metoder i projektet, is\u00e6r i et distribueret team. I et af de projekter, der blev pr\u00e6senteret som v\u00e6rende baseret p\u00e5 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\u00e6ttere p\u00e5 C end p\u00e5 C++, hvilket ikke gjorde teamet s\u00e6rlig inspireret, da ledelsen havde arbejdet h\u00e5rdt for at samle nogle virkelig dygtige C++-udviklere. Samtidig havde den amerikanske del af teamet, b\u00e5de ingeni\u00f8rer og ledere, arbejdet i virksomheden i lang tid, tilpasset sig den nuv\u00e6rende situation, og de var tilfredse. Den russiske del af teamet blev derimod samlet for nylig, kun f\u00e5 uger f\u00f8r (herunder mig). Den russiske del af teamet \u00f8nskede kategorisk ikke at opgive den velkendte tilgang til udvikling.<\/p>\n
Der begyndte uendelige skriftlige diskussioner mellem de to kontinenter, emails med tre-fire sk\u00e6rme fl\u00f8j frem og tilbage, b\u00e5de i gruppe-mail og personligt, fra programm\u00f8rer til programm\u00f8rer og ledere. Som det ofte sker, blev emails af denne st\u00f8rrelse ikke l\u00e6st af nogen, undtagen forfatterne og deres ivrige tilh\u00e6ngere. Chats knirkede af sp\u00e6ndinger, idet de sendte mange-sk\u00e6rms 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\u00e6rdeligt det er uden. <\/p>\n
Det tog ret lang tid, f\u00f8r jeg endelig inds\u00e5, at vi diskuterede de tekniske aspekter af sp\u00f8rgsm\u00e5let, men problemet var i virkeligheden ikke teknisk. Problemet l\u00e5 ikke i fordele eller ulemper ved STL eller i kompleksiteten ved at arbejde uden den. Problemet var snarere organisatorisk. Vi skulle blot forst\u00e5, hvordan virksomheden, vi arbejdede for, var organiseret. Ingen af os havde tidligere erfaring med at arbejde i en s\u00e5dan virksomhed. Efter udviklingen af koden og dens udrulning til produktion, blev vedligeholdelsen udf\u00f8rt af helt andre mennesker fra andre teams i andre lande. Dette enorme ingeni\u00f8rteam best\u00e5ende af flere tusinde ingeni\u00f8rer kunne kun tillade sig det helt basale minimum af tekniske midler, s\u00e5 at sige, minimum minimorum. Alt, hvad der gik ud over den ingeni\u00f8rm\u00e6ssige standard, der var fastsat i virksomheden, kunne ikke under nogen omst\u00e6ndigheder blive underst\u00f8ttet efterf\u00f8lgende. Niveauet for et team bestemmes af niveauet af dets svageste medlemmer. Efter at vi forstod den reelle motivation<\/i> bag handlingerne fra den amerikanske del af teamet, blev dette sp\u00f8rgsm\u00e5l fjernet fra dagsordenen, og vi udviklede og lancerede sammen produktet, ved hj\u00e6lp af de standarder, der var fastsat i virksomheden. I dette tilf\u00e6lde fungerede e-mails og chats d\u00e5rligt, og for at n\u00e5 til enighed kr\u00e6vede det flere rejser og meget personligt samv\u00e6r.<\/p>\n
Fra et arbejdsprocesperspektiv ville det i denne specifikke sag v\u00e6re nyttigt at have en beskrivelse af de anvendte v\u00e6rkt\u00f8jer, kravene til dem, begr\u00e6nsningerne for tilf\u00f8jelse af nye samt begrundelsen for disse begr\u00e6nsninger. S\u00e5danne dokumenter svarer nogenlunde til dem, der er beskrevet i punkterne Reuse Strategy og Development Environment i manualen \"Manager's Handbook for Software Development\", udarbejdet i NASA<\/a><\/noindex>. P\u00e5 trods af sin alder beskriver den glimrende alle de grundl\u00e6ggende aktiviteter og faser i planl\u00e6gningen af softwareudvikling af denne art. Tilstedev\u00e6relsen af s\u00e5danne dokumenter g\u00f8r det meget nemmere at diskutere, hvilke komponenter og tilgange der kan anvendes i produktet, og hvorfor.<\/p>\nFra et kulturelt perspektiv ville det v\u00e6re \u00e5benlyst, at med en mere moden tilgang, hvor parterne fors\u00f8ger at h\u00f8re og forst\u00e5 den reelle motivation bag kollegaernes handlinger og handler ud fra projektets og teamets prioriteter snarere end personlig ego, ville konflikten v\u00e6re blevet l\u00f8st lettere og hurtigere.<\/p>\n
I en anden konflikt, der opstod p\u00e5 grund af valget af teknisk l\u00f8sning, tog det mig ogs\u00e5 betydelig tid at forst\u00e5 motivationen for en af parterne (det var en meget us\u00e6dvanlig sag), men efter at motivationen var klar, var l\u00f8sningen \u00e5benlys. <\/p>\n
Situationen er s\u00e5dan: I et team p\u00e5 cirka 20 personer kommer der en ny udvikler, lad os kalde ham Stas. Vores standardv\u00e6rkt\u00f8j til kommunikation i teamet var p\u00e5 det tidspunkt Skype. Som det senere viste sig, var Stas en stor fan af \u00e5bne standarder og open source-software og brugte kun v\u00e6rkt\u00f8jer og operativsystemer, hvis kildekode er offentligt tilg\u00e6ngelig, og som anvender offentligt beskrevede protokoller. Skype h\u00f8rer ikke til disse v\u00e6rkt\u00f8jer. Vi brugte en enorm m\u00e6ngde tid p\u00e5 at diskutere fordele og ulemper ved denne tilgang, fors\u00f8ge at k\u00f8re alternativer til Skype p\u00e5 forskellige operativsystemer, Stas' fors\u00f8g p\u00e5 at overtale teamet til at skifte til andre standarder, skrive til ham personligt via e-mail, ringe til ham personligt via telefon, k\u00f8be en anden computer specielt til Skype, osv. Endelig inds\u00e5 jeg, at dette problem i sin essens ikke var teknisk eller organisatorisk; det var snarere verdensanskuelsesm\u00e6ssigt, ja, man kunne endda sige religi\u00f8st (for Stas). Selv hvis vi til slut fik Stas til at bruge Skype (hvilket tog flere m\u00e5neder), ville problemet opst\u00e5 igen med det n\u00e6ste v\u00e6rkt\u00f8j. Jeg havde ikke reelle midler til at \u00e6ndre Stas' verdensopfattelse, og der var ikke nogen grund til at fors\u00f8ge at \u00e6ndre verdensopfattelsen for teamet, som fungerede fint i dette milj\u00f8. Mennesket og virksomheden var simpelthen ortogonale i deres verdensanskuelse. I s\u00e5danne situationer er en god l\u00f8sning organisatorisk. Vi flyttede Stas til et andet team, hvor han var mere i harmoni.<\/p>\n
\u00c5rsagen til denne konflikt ligger, efter min mening, i uoverensstemmelsen mellem den personlige kultur hos en specifik person (som har en st\u00e6rk mening, der forhindrer ham i at g\u00e5 p\u00e5 kompromis) og virksomhedens kultur. I dette tilf\u00e6lde er det selvf\u00f8lgelig en fejl fra lederens side. Det var forkert fra starten af at ans\u00e6tte ham til et projekt af denne art. Stas sluttede med at g\u00e5 over til et projekt om udvikling af open source-software, hvor han klarede sig fremragende.<\/p>\n
Et godt eksempel p\u00e5 en konflikt, der opst\u00e5r p\u00e5 grund af b\u00e5de udviklerens b\u00f8rnelige tilgang og mangler i arbejdsgangen - en situation hvor, i frav\u00e6ret af en definition af f\u00e6rdig, har udvikleren og QA-teamet forskellige forventninger til, hvorn\u00e5r en funktion er klar til QA. Udvikleren mente, det var tilstr\u00e6kkeligt at skrive koden og sende funktionen over til QA - de ville finde ud af det der. Det var faktisk en ret erfaren programm\u00f8r, men han havde bare en lavere kvalitetsstandard. QA var uenige i dette og kr\u00e6vede at f\u00e5 vist og beskrevet, hvad han selv havde verificeret, og de insisterede p\u00e5 et testscenarie til dem. De havde tidligere haft problemer med funktionaliteten fra denne udvikler og \u00f8nskede ikke at spilde tid igen. For \u00f8vrigt havde de ret - funktionen virkede faktisk ikke, koden blev ikke verificeret f\u00f8r overdragelse til QA. <\/p>\n
For at l\u00f8se situationen bad jeg ham vise mig, at alt faktisk fungerede (det gjorde det ikke, og han m\u00e5tte rette det), vi diskuterede definitionen af f\u00e6rdig med teamet og QA (vi gjorde det ikke skriftligt, da vi ikke \u00f8nskede at g\u00f8re processen for bureaukratisk), og med denne specialist adskilte vi os snart (til alles lettelse).<\/p>\n
Set fra et arbejdsgangsperspektiv er de mulige forbedringer i dette tilf\u00e6lde - tilstedev\u00e6relsen af en definition af f\u00e6rdig, krav til at hver funktion skal have enhed og integrationstest, samt beskrivelse af testningen udf\u00f8rt af udvikleren. I et af projekterne m\u00e5lte vi d\u00e6kningen af koden med tests under CI, og hvis d\u00e6kningen faldt efter tilf\u00f8jelse af en patch, blev testene markeret som ikke best\u00e5et, dvs. enhver ny kode kunne kun tilf\u00f8jes, hvis der ogs\u00e5 blev tilf\u00f8jet nye tests til den. <\/p>\n
Endnu et klassisk eksempel p\u00e5 en konflikt, der er t\u00e6t 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\u00e6rmer sig, s\u00e5 ticketen med problemet fra kunden, der er blevet overset blandt de andre tickets til udvikleren, der er tildelt den, h\u00e6nger flere uger uden opm\u00e6rksomhed. Supporten tror, at udvikleren arbejder p\u00e5 kundens problem. Kunden venter og h\u00e5ber, at der arbejdes p\u00e5 hans problem. I virkeligheden sker der ikke noget. Efter et par uger beslutter kunden endelig at sp\u00f8rge om fremdriften og kontakter supporten. Supporten sp\u00f8rger udviklingen. Udvikleren ryster p\u00e5 hovedet, gennemg\u00e5r ticketlisten og opdager kunden ticketen. Ved at l\u00e6se ticketen fra kunden forst\u00e5r han, at der ikke er tilstr\u00e6kkelig information til at l\u00f8se 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\u00e6ret nogen, der har arbejdet p\u00e5 hans problem hele tiden. Og der vil komme torden \u2026<\/p>\n
I denne situation er l\u00f8sningen p\u00e5 selve konflikten ret \u00e5benlys og lige til (fiks produktet, opdater dokumentationen og testene, berolig kunden, udsend en hotfix, osv.). Det er vigtigt at analysere arbejdsprocessen og forst\u00e5, hvem der har ansvaret for at organisere samarbejdet mellem de to teams, og hvorfor denne situation overhovedet kunne opst\u00e5. Det st\u00e5r klart, at noget skal rettes i processen \u2014 nogen skal overv\u00e5ge det overordnede billede uden p\u00e5mindelser fra kunderne, proaktivt. Tickets fra kunderne skal fremh\u00e6ves blandt de andre tickets hos udviklerne. Supporten skal kunne se, om udviklingen arbejder p\u00e5 deres tickets i \u00f8jeblikket; hvis ikke, hvorn\u00e5r de kan begynde at arbejde, og hvorn\u00e5r resultaterne kan forventes. Support og udvikling skal kommunikere og diskutere status for tickets regelm\u00e6ssigt, og indsamlingen af den n\u00f8dvendige information til fejlfinding skal v\u00e6re s\u00e5 automatiseret som muligt, osv.<\/p>\n
Som i krig fors\u00f8ger modstanderen at ramme forbindelsen mellem to enheder, er det i arbejdet typisk det mest skr\u00f8belige og s\u00e5rbare punkt, der viser sig at v\u00e6re samarbejdet mellem teams. Hvis support- og udviklingscheferne er voksne nok, kan de selv reparere processen, hvis ikke, vil processen forts\u00e6tte med at skabe konflikter og problemer, indtil en leder griber ind og kan rette op p\u00e5 situationen.<\/p>\n
Et andet karakteristisk eksempel, som jeg ofte har set i forskellige virksomheder, er den situation, hvor produktet udvikles af \u00e9n gruppe, automatiserede integrationstest udf\u00f8res af en anden gruppe, og infrastrukturen, hvori alt dette k\u00f8rer, vedligeholdes af en tredje gruppe. Problemer opst\u00e5r konstant under testk\u00f8rslerne, og \u00e5rsagerne til problemerne kan v\u00e6re b\u00e5de produktet, testene og infrastrukturen. Det er normalt problematisk at blive enige om, hvem der skal lave den f\u00f8rste analyse af problemerne, indberette fejl, analysere logfiler fra produktet, testene og infrastrukturen osv. Konflikter her er ret almindelige og samtidig ensartede. I tilf\u00e6lde af h\u00f8j f\u00f8lelsesm\u00e6ssig intensitet falder deltagerne ofte ind i en barnlig position, og diskussionerne begynder i stil med: \"hvorfor skal jeg have med det at g\u00f8re\", \"de har oftere problemer\", osv. <\/p>\n
Set fra et arbejdsprocessuelt perspektiv afh\u00e6nger de specifikke skridt til at l\u00f8se problemet af teamenes sammens\u00e6tning, typen af test og produktet osv. I et af projekterne indf\u00f8rte vi regelm\u00e6ssige vagtordninger, hvor teamene overv\u00e5gede testene p\u00e5 skift, uge for uge. I et andet projekt blev den f\u00f8rste analyse altid udf\u00f8rt af testudviklerne, men analysen var ret grundl\u00e6ggende, og produktet var tilstr\u00e6kkeligt stabilt, s\u00e5 det fungerede ganske godt. Hovedpointen er at sikre gennemsigtighed i processen, tydelighed i forventningerne for alle parter og en f\u00f8lelse af retf\u00e6rdighed i situationen for alle.<\/p>\n
Er konflikt overhovedet et problem i organisationen, eller er det et d\u00e5rligt tegn, at der ofte (eller blot indimellem) opst\u00e5r konflikter i dit team? Generelt nej, for hvis der er v\u00e6kst, udvikling, eller en eller anden dynamik, vil der opst\u00e5 sp\u00f8rgsm\u00e5l, der aldrig tidligere har v\u00e6ret l\u00f8st, og konflikt kan opst\u00e5 i forbindelse med deres l\u00f8sning. Det er en indikator p\u00e5, at der er omr\u00e5der, der kr\u00e6ver opm\u00e6rksomhed, og at der er plads til forbedringer. Det er d\u00e5rligt, hvis konflikter opst\u00e5r meget ofte, og de er sv\u00e6re eller langvarige at l\u00f8se. Dette er sandsynligvis et tegn p\u00e5, at arbejdsprocesserne ikke er tilstr\u00e6kkeligt finjusterede, og at teamet ikke er tilstr\u00e6kkeligt modent.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
![\"H\u00e5ndtering](\"\/wp-content\/uploads\/2019\/07\/de379c9eedec8cecda6651b5339a0277.jpg\")