Epigraf:
Engang mødtes Pindsvinet og den lille bjørn i skoven.
- Hej Hedgehog!
- Hej, lille bjørn!
Så, ord for ord, joke for joke, blev pindsvinet ramt i ansigtet af den lille bjørn...
Nedenfor er en diskussion fra vores teamleder, samt RAS produktudviklingsdirektør Igor Marnat, om det specifikke ved arbejdskonflikter og mulige metoder til at håndtere dem.
De fleste af de konflikter, vi støder på på arbejdspladsen, udvikler sig efter et scenarie, der ligner det, der er beskrevet i epigrafen ovenfor. Der er flere deltagere, som i starten er ret gunstigt indstillede over for hinanden; de forsøger at løse et eller andet problem, men i sidste ende forbliver problemet uløst, og af en eller anden grund viser sig relationerne mellem deltagerne i diskussionen at være forkælet.
Livet er mangfoldigt, og der forekommer variationer i scenariet beskrevet ovenfor. Nogle gange er forholdet mellem deltagerne ikke særlig godt i starten, nogle gange er der ikke engang et problem, der kræver en direkte løsning (som f.eks. i epigrafen), nogle gange efter diskussionen forbliver forholdet det samme som før det begyndte, men problemet er i sidste ende ikke løst.
Hvad er fælles i alle situationer, der kan defineres som en situation med arbejdskonflikt?
For det første er der to eller flere sider. Disse parter kan indtage forskellige steder i organisationen, være i et ligeværdigt forhold (kolleger i et team) eller på forskellige niveauer i hierarkiet (chef - underordnet), være individuelle (medarbejder) eller gruppe (i tilfælde af konflikt mellem en medarbejder og et team eller to teams) og så videre. Sandsynligheden for konflikt og den nemme løsning er i høj grad påvirket af tillidsniveauet mellem deltagerne. Jo bedre parterne kender hinanden, jo højere grad af tillid, jo større er chancen for, at de bliver enige. For eksempel er medlemmer af et distribueret team, der aldrig har interageret ansigt-til-ansigt, mere tilbøjelige til at opleve konflikter over et simpelt arbejdsproblem end folk, der har haft mindst et par ansigt-til-ansigt interaktioner. Derfor, når du arbejder i distribuerede teams, er det meget vigtigt at sikre, at alle teammedlemmer mødes med jævne mellemrum personligt med hinanden.
For det andet er parterne i en konfliktsituation på arbejdspladsen i en situation, hvor de løser et eller andet problem, som er vigtigt for en af parterne, for dem begge eller for organisationen som helhed. På samme tid, på grund af situationens særlige forhold, har parterne normalt nok tid og en række forskellige måder at løse det på (formelle, uformelle, møder, breve, ledelsesbeslutninger, tilstedeværelsen af teamets mål og planer, et hierarki osv.). Dette er forskelligt fra situationen med at løse et arbejde (eller ikke-arbejde) problem i en organisation fra for eksempel at løse et vigtigt spørgsmål: "Eh, knægt, hvilket område kommer du fra?!" på gaden, eller konflikten fra epigrafen. Ved løsning af et arbejdsproblem er kvaliteten af arbejdsprocessen og kulturen for løsning af problemer i teamet afgørende.
For det tredje er den afgørende faktor for konflikten (set fra vores diskussions synspunkt) det faktum, at parterne i processen ikke selvstændigt kan komme til en løsning på problemet, der passer alle parter. Situationen kræver indgriben fra en tredjepart, en ekstern dommer. Dette punkt kan virke kontroversielt, men i det væsentlige, hvis konfliktsituationen blev løst uden indgriben fra en ekstern voldgiftsdommer, problemet blev løst med succes, og parternes forhold blev ikke forværret, dette er den situation, vi bør stræbe efter. . Vi vil højst sandsynligt ikke engang vide om en sådan konflikt, eller vi finder ud af det ved et tilfælde, efter at den er løst. Jo flere problemer et team kan løse på egen hånd, jo mere effektivt vil det være.
Et andet karakteristisk træk ved konflikten, som er værd at berøre, er graden af følelsesmæssig intensitet under beslutningen. Konflikt er ikke nødvendigvis forbundet med et højt følelsesmæssigt niveau. Deltagerne behøver ikke at råbe og vifte med armene, for at situationen i bund og grund er en konflikt. Spørgsmålet er ikke løst, en vis følelsesmæssig spænding er til stede (måske er det ikke klart udtrykt udadtil), hvilket betyder, at vi står over for en konfliktsituation.
Er det overhovedet nødvendigt at gribe ind i konfliktsituationer, eller er det bedre at lade deres løsning gå sin gang og vente på, at problemet løser sig selv? Behøver. Det er ikke altid i din magt eller kompetence at løse konflikten fuldstændigt, men i enhver situation, i en konflikt af enhver skala, kan du indtage en voksenposition, og derved bringe flere mennesker omkring dig til det, afbøde de negative konsekvenser af konflikt og bidrage til løsningen heraf.
Inden vi ser på nogle få eksempler på konfliktsituationer, lad os se på et par vigtige punkter, der er fælles for alle konflikter.
Når man løser en konflikt, er det vigtigt at være over kampen, og ikke inde i den (det kaldes også at "tage en metaposition"), altså ikke at være en del af en af parterne i løsningsprocessen. Ellers vil det kun styrke den ene parts position til skade for den anden part, hvis en ekstern dommer bistår afgørelsen. Når du træffer en beslutning, er det vigtigt, at den er moralsk accepteret af alle parter, som de siger, "købt". Så selv om parterne ikke var tilfredse med den trufne beslutning, gik de i det mindste oprigtigt med til at gennemføre den. Som man siger, at kunne være uenige og forpligte sig. Ellers vil konflikten blot ændre udseende, den ulmende ild forbliver under tørvemosen og vil på et tidspunkt uundgåeligt blusse op igen.
Det andet punkt, delvist relateret til det første, er, at hvis du allerede har besluttet dig for at deltage i løsningen af konflikten, skal du tage det så alvorligt som muligt ud fra et kommunikationssynspunkt og at studere konteksten. Tal personligt med hver af parterne. Separat med hver, til at begynde med. Nøj dig ikke med post. I tilfælde af et distribueret hold, tal i det mindste via videolink. Vær ikke tilfreds med rygter og øjenvidnerapporter. Forstå historien, hvad hver side ønsker, hvorfor de ønsker det, hvad de forventer, har de prøvet at løse dette problem før, hvad vil der ske, hvis det ikke bliver løst, hvilke løsninger ser de, hvordan forestiller de sig positionen af anden side, hvad tænker de, rigtigt eller forkert osv. Indlæs al mulig kontekst i dit hoved med et åbent sind, forudsat at alle har ret. Du er ikke inde i konflikten, du er udenfor den, i en metaposition. Hvis konteksten kun er tilgængelig i en indlægstråd, skal du i det mindste læse den i sin helhed og de tråde og dokumenter, der er relateret til den. Når du har læst den, skal du stadig tale med din stemme. Du er næsten garanteret at høre noget vigtigt, som ikke er med posten.
Det tredje vigtige punkt er den generelle tilgang til kommunikation. Det er almindelige ting, ikke noget kosmisk, men de er meget vigtige. Vi forsøger ikke at spare tid, vi taler med alle deltagerne, vi kritiserer ikke personen, men vi overvejer konsekvenserne af hans handlinger (ikke "du er uhøflig", men "måske fyrene kan blive stødt af denne ting"), giver vi mulighed for at redde ansigt, vi fører diskussioner personligt, ikke foran linjen.
Konflikter er normalt forårsaget af en af to årsager. Den første er relateret til, om en person på konflikttidspunktet er i en voksen eller et barns stilling (mere om dette nedenfor). Dette skyldes hans følelsesmæssige modenhed, evnen til at styre sine følelser (som i øvrigt ikke altid er relateret til hans alder). Den anden almindelige årsag er ufuldkommenhed i arbejdsprocessen, som skaber situationer med gråzoner, hvor ansvaret er spredt mellem deltagerne, parternes forventninger ikke er gennemsigtige for hinanden, og roller i processen er sløret.
I overensstemmelse hermed skal en leder ved løsning af en konflikt (såvel som ethvert andet problem) huske på tre perspektiver: kortsigtet - for at løse problemet/konflikten her og nu, mellemlang sigt - for at minimere sandsynligheden for, at en anden konflikt opstår af samme grund, og langsigtet - at dyrke en voksenkultur i teampersonen.
Hver af os har et indre barn på omkring tre eller fire år. Han sover det meste af tiden på arbejdet, men vågner nogle gange og tager kontrollen. Barnet har sine egne prioriteter. Det er vigtigt for ham at insistere på, at dette er hans sandkasse, hans mor elsker ham mere, hans maskine er den bedste (designet er det bedste, han programmerer det bedste, ...). I en konfliktsituation kan et barn trykke på legetøj, trampe med fødderne og knække sin spatel, men han kan ikke løse voksne problemer (løsningsarkitektur, tilgange til automatiseret test, udgivelsesdatoer osv.), han tænker ikke i fordele for holdet. Et barn i konflikt kan opmuntres, trøstes og sendes i seng ved at bede ham om at ringe til sin voksne. Inden du starter en diskussion i en konfliktsituation, skal du sikre dig, at du taler med en voksen, ikke et barn, og at du selv er i en voksens position. Hvis dit ærlige mål i øjeblikket er at løse et alvorligt problem, er du i en voksen position. Hvis dit mål er at trampe med fødderne og knække dit skulderblad, er dette en barnlig stilling. Send dit indre barn i seng og ring til en voksen, eller flyt samtalen. En person træffer en følelsesmæssig beslutning og leder derefter efter en rationel begrundelse for den. En beslutning truffet af et barn ud fra børns prioriteter vil ikke være optimal.
Ud over adfærd på konflikttidspunktet er et barns eller voksens position også kendetegnet ved det ansvarsniveau, som en person er klar til at påtage sig. I sine ekstreme manifestationer ser den barnlige position af en programmør, som jeg har mødt mere end én gang, sådan her: Jeg skrev koden, sendte den til gennemgang - mit arbejde er færdigt. Anmeldere bør gennemgå det og godkende det, QA bør tjekke det, hvis der er problemer, vil de give mig besked. Mærkeligt nok opfører selv ret modne og erfarne mennesker nogle gange sådan. Den anden ende af skalaen er, at en person anser sig selv for at være ansvarlig for at sikre, at hans kode fungerer, er dækket af test, er blevet personligt tjekket af ham, har bestået gennemgangen (hvis det er nødvendigt, er der ingen problemer med at pinge anmeldere, diskutere problemer med stemme osv.) og er blevet undertrykt, vil QA yde assistance om nødvendigt, testscenarier vil blive beskrevet osv. I normale tilfælde starter programmøren enten tættere på den voksne ende af skalaen eller flytter dertil, 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, normalt indtager han en barnlig stilling, så har han og teamet med jævne mellemrum problemer og konflikter.
At fremme den rette, modne kultur i et team er en vigtig opgave for enhver leder. Det tager lang tid og daglig indsats, men resultatet er det værd. Der er to måder at påvirke teamkulturen på – at lede med et godt eksempel (som helt sikkert vil blive fulgt; teamet ser altid til lederen) og diskutere og belønne den rigtige adfærd. Her er der heller ikke noget abstrut eller meget formelt, bare når man diskuterer problemer, læg mærke til, at der kunne være gjort noget her, læg mærke til, at du bemærkede, hvornår det blev besluttet rigtigt, ros, noter under udgivelsesgennemgangen osv.
Lad os overveje flere typiske konfliktsituationer, fra simple til komplekse:
Konflikter, der ikke er relateret til arbejdsproblemer
Ganske ofte er der konflikter på arbejdet, som ikke er relateret til arbejdsproblemer. Deres forekomst og lette opløsning er normalt direkte relateret til niveauet af følelsesmæssig intelligens hos deltagerne, deres niveau af modenhed og er ikke relateret til perfektion eller ufuldkommenhed af arbejdsprocessen.
Typiske eksempler: nogen bruger ikke vaskemaskinen eller bruser ofte nok, hvilket andre ikke kan lide, nogen er indelukket, mens andre får vind, hvis de åbner vinduet, nogen larmer for meget, og andre har brug for stilhed for at arbejde, og snart. Det er bedre ikke at forsinke løsningen af konflikter af denne art og ikke at lade dem gå deres vej. De vil ikke løse sig selv og vil distrahere dig fra arbejdet hver dag og forgifte atmosfæren i teamet. Heldigvis er det normalt ikke et stort problem at løse dem - bare tal roligt (en-til-en, selvfølgelig) med en kollega, der forsømmer hygiejnen, sørger for behagelige siddepladser til folk, der foretrækker stilhed/kølighed, køb lydabsorberende hovedtelefoner eller installer skillevægge , etc.
Et andet eksempel, som jeg stødte på flere gange under mit arbejde, er teammedlemmernes psykologiske uforenelighed. Af en eller anden grund kan folk simpelthen ikke arbejde sammen; enhver interaktion ender i en skandale. Nogle gange skyldes det, at folk har polære synspunkter om et presserende emne (normalt politisk) og ikke ved, hvordan de skal lade dem stå uden for arbejdet. At overbevise dem om at tolerere hinanden eller ændre deres adfærd er en ret forgæves opgave. Den eneste undtagelse, jeg er stødt på, er unge kolleger med åbne opfattelser; deres adfærd kan stadig gradvist ændres gennem periodiske samtaler. Normalt løses problemet med succes ved at adskille dem i forskellige teams, eller i det mindste give mulighed for at overlappe hinanden på arbejdet meget sjældent.
I alle ovenstående situationer er det værd at tale med alle deltagere personligt, diskutere situationen, spørge, om de overhovedet ser et problem i denne sag, spørge, hvad der efter deres mening er løsningerne, og sikre deres deltagelse i at lave dette afgørelse.
Ud fra et synspunkt om at optimere arbejdsprocessen (det mellemlange perspektiv, som jeg nævnte), kan der ikke gøres meget her; det eneste punkt for optimering er at tage hensyn til kompatibilitetsfaktoren, når du danner et team og ikke at sætte folk sammen på forhånd, hvem der vil konflikte.
Fra et teamkulturperspektiv opstår sådanne situationer meget sjældnere i teams med en moden kultur, hvor folk respekterer teamet og kollegerne og ved, hvordan man løser problemer selvstændigt. Derudover løses sådanne konflikter meget nemmere (ofte automatisk) i teams, hvor der er en høj grad af tillid, folk har arbejdet sammen i lang tid og/eller kommunikerer ofte uden for arbejdet.
Konflikter relateret til arbejdsproblemer:
Sådanne konflikter er normalt forårsaget af begge årsager på én gang, både følelsesmæssige (det faktum, at en af deltagerne ikke er i en voksen position) og ufuldkommenhed i selve arbejdsprocessen. Måske er den mest almindelige type konflikter, som jeg er stødt på, konflikter under kodegennemgange eller arkitekturdiskussioner mellem udviklere.
Jeg vil fremhæve to typiske tilfælde her:
1) I det første tilfælde kan udvikleren ikke få en kodegennemgang fra en kollega. Patchen sendes til gennemgang, og der sker ikke noget. Ved første øjekast er der ingen åbenlys konflikt mellem de to sider, men hvis man tænker over det, er det noget af en konflikt. Arbejdsspørgsmålet er ikke løst, en af parterne (venter på anmeldelse) oplever tydeligt ubehag. En ekstrem undertype af denne sag er udvikling i et fællesskab eller i forskellige teams, mens anmelderen muligvis ikke er interesseret i denne særlige kode, på grund af indlæsning eller andre omstændigheder, måske slet ikke er opmærksom på anmodningen om gennemgang, og den eksterne dommer (en leder, der er fælles for begge sider) ) eksisterer måske slet ikke.
Den løsningstilgang, der hjælper i en sådan situation, forholder sig netop til det langsigtede perspektiv, en voksens kultur. For det første virker smart aktivitet. Du skal ikke forvente, at koden, der hænger på anmeldelsen, vil tiltrække anmelderens opmærksomhed. Vi skal hjælpe anmelderne med at lægge mærke til ham. Pingani et par mennesker, stille et spørgsmål om syncape, deltage i diskussioner. Naturligvis er det mere sandsynligt, at uopmærksomhed skader end hjælper, du skal bruge din sunde fornuft. For det andet fungerer forberedelsen godt. Hvis teamet forstår, hvad der sker og hvorfor, hvorfor denne kode overhovedet er nødvendig, designet er blevet diskuteret og aftalt på forhånd med alle, er det mere sandsynligt, at folk er opmærksomme på en sådan kode og accepterer den til arbejdet. For det tredje virker autoriteten. Hvis du ønsker at blive anmeldt, så lav en masse anmeldelser selv. Lav anmeldelser af høj kvalitet med rigtige kontroller, rigtige tests og nyttige kommentarer. Hvis dit kaldenavn er velkendt i teamet, er der større chance for, at din kode bliver bemærket.
Fra et workflow-synspunkt er mulige forbedringer her korrekt prioritering rettet mod at hjælpe udvikleren med at nå sine og teamets mål (gennemgå andre, skrive breve til fællesskabet, ledsage koden med en arkitekturbeskrivelse, dokumentation, test, deltage i diskussioner med fællesskab osv.), forhindre patches i at hænge for længe i køen og så videre.
2) Det andet almindelige tilfælde af konflikter under kode- eller designgennemgange er forskellige syn på tekniske problemer, kodningsstil og valg af værktøjer. Af stor betydning i dette tilfælde er graden af tillid mellem deltagerne, tilhørsforhold til samme team og erfaring med at arbejde sammen. En blindgyde opstår, når en af deltagerne indtager en barnlig holdning og ikke forsøger at høre, hvad samtalepartneren ønsker at formidle til ham. Ofte kan både den tilgang, der er foreslået af den anden part, og den fremgangsmåde, der blev foreslået i første omgang, godt fungere med succes, og det er principielt ligegyldigt, hvilken man skal vælge.
En dag forberedte en programmør fra mit team (lad os kalde ham Pasha) en patch med ændringer til pakkeimplementeringssystemet, som blev udviklet og understøttet af kolleger fra en naboafdeling. En af dem (Igor) havde sin egen stærke mening om præcis, hvordan Linux-tjenester skulle konfigureres, når pakker implementeres. Denne udtalelse adskilte sig fra den tilgang, der blev foreslået i plastret, og de kunne ikke blive enige. Som sædvanlig var deadlines ved at løbe ud, og det var nødvendigt at træffe en eller anden form for beslutning, det var nødvendigt for en af dem at indtage en voksenstilling. Pasha erkendte, at begge tilgange har ret til liv, men han ønskede, at hans mulighed skulle bestå, fordi Hverken den ene eller den anden mulighed havde nogen åbenlyse tekniske fordele.
Vores diskussion så nogenlunde sådan her ud (meget skematisk varede samtalen selvfølgelig i en halv time):
- Pasha, vi har en funktionsfrysning om et par dage. Det er vigtigt, at vi får samlet det hele og begynder at teste så hurtigt som muligt. Hvordan kan vi komme igennem Igor?
— Han vil gerne oprette tjenester anderledes, han satte kommentarer der til mig...
- Og hvad er der, store ændringer, meget ballade?
- Nej, der er arbejde i et par timer, men i sidste ende er der ingen forskel, det går begge veje, hvorfor er det nødvendigt? Jeg har lavet noget, der virker, lad os acceptere det.
- Hør her, hvor længe har du diskuteret alt det her?
- Ja, vi har markeret tid i halvanden uge nu.
- Um... kan vi løse et problem på et par timer, der allerede har taget halvanden uge, og ikke gøre det?
- Nå, ja, men jeg vil ikke have, at Igor skal tro, at jeg kastede mig ud...
- Hør her, hvad er vigtigere for dig, at udstede en løsladelse sammen med din beslutning indeni, eller at dræbe Igor? Vi kan blokere den, så er der dog en god chance for at flyve igennem med udgivelsen.
- Nå... det ville selvfølgelig være fedt at tørre Igors næse, men okay, udgivelsen er vigtigere, jeg er enig.
- Er det virkelig så vigtigt for dig, hvad Igor mener? For at være ærlig giver han slet ikke en helvede, han vil bare have en samlet tilgang forskellige steder af den ting, som han er ansvarlig for.
- Nå, ok, lad mig gøre, som han beder om i kommentarerne, og lad os begynde at teste.
- Tak, Pasha! Jeg var sikker på, at af jer to ville du være den mere modne, selvom Igorek er ældre end dig :)
Problemet blev løst, udgivelsen blev frigivet til tiden, Pasha følte ikke meget utilfredshed, fordi han foreslog selv en løsning og gennemførte den. Igor var generelt tilfreds, fordi... Der blev taget hensyn til hans mening, og de gjorde, som han foreslog.
En anden type i det væsentlige samme konflikt er valget mellem tekniske løsninger/biblioteker/tilgange i et projekt, især i et distribueret team. I et af projekterne, som blev positioneret til at bruge C/C++, viste det sig, at den tekniske styring af projektet var kategorisk imod at bruge STL (Standard Template Library). Dette er et standardsprogbibliotek, der forenkler udviklingen, og vores team er meget vant til det. Det viste sig, at projektet er meget tættere på C end på C++, hvilket ikke inspirerede teamet særlig meget, fordi ledelsen gjorde deres bedste og rekrutterede rigtig seje plusspillere. Samtidig havde den amerikanske del af teamet, både ingeniører og ledere, arbejdet i virksomheden i længere tid, var vant til den eksisterende tilstand og var tilfredse med alt. Den russiske del af holdet blev samlet for ganske nylig, inden for et par uger (inklusive mig). Den russiske del af holdet ønskede kategorisk ikke at opgive den sædvanlige tilgang til udvikling.
Endeløse skriftlige diskussioner begyndte mellem de to kontinenter, breve på tre eller fire skærme fløj frem og tilbage, i gruppemails og personlige, fra programmører til programmører og ledere. Som det sædvanligvis er tilfældet, blev breve af denne længde læst af ingen undtagen forfatterne og deres ivrige tilhængere. Chats knirkede af spænding og sendte tanker på flere skærme i forskellige retninger om de tekniske fordele ved STL, hvor godt testet det er, hvor sikkert det er, og generelt hvor vidunderligt livet er med det, og hvor forfærdeligt det er uden det .
Det hele varede ret lang tid, indtil jeg endelig indså, at vi diskuterede de tekniske aspekter af problemet, men problemet var i virkeligheden ikke teknisk. Problemet er ikke fordelene eller ulemperne ved STL eller vanskeligheden ved at arbejde uden det. Problemet er snarere organisatorisk. Vi skulle bare forstå, hvordan den virksomhed, vi arbejdede for, fungerede. Ingen af os havde erfaring med at arbejde i sådan en virksomhed før. Sagen var, at efter at koden var udviklet og frigivet til produktion, blev support varetaget af helt andre mennesker fra andre teams, fra andre lande. Dette enorme ingeniørhold på flere titusindvis af ingeniører (i alt) havde kun råd til et helt grundlæggende minimum af tekniske midler, så at sige et minimumsminimum. Alt, der gik ud over den tekniske standard, der er etableret i virksomheden fysisk, kunne ikke understøttes i fremtiden. Et holds niveau bestemmes af niveauet på dets svageste medlemmer. Efter vi forstod reel motivation handlinger fra den amerikanske del af teamet, blev dette emne fjernet fra dagsordenen, og sammen udviklede og frigav vi produktet med succes ved hjælp af de standarder, som virksomheden har vedtaget. Breve og chats i dette tilfælde fungerede ikke godt, det tog adskillige ture og en masse personlig kommunikation at nå frem til en fællesnævner.
Ud fra arbejdsgangens synspunkt vil det i dette særlige tilfælde hjælpe at have en beskrivelse af de anvendte værktøjer, krav til dem, restriktioner for tilføjelse af nye og begrundelse for sådanne restriktioner. Sådanne dokumenter svarer nogenlunde til dem, der er beskrevet i afsnittene Genbrugsstrategi og udviklingsmiljø i "Manager's Handbook for Software Development", udviklet i . På trods af sin alder beskriver den perfekt alle de vigtigste aktiviteter og planlægningsstadier af softwareudvikling af denne art. At have dokumenter som dette gør det meget nemt at diskutere, hvilke komponenter og tilgange der kan bruges i et produkt, og hvorfor.
Fra et kulturelt synspunkt, naturligvis med en mere moden position, hvor parterne forsøger at høre og forstå den reelle motivation af deres kollegers handlinger og handler ud fra projektets og teamets prioriteter og ikke det personlige ego. , ville konflikten blive løst nemmere og hurtigere.
I en anden konflikt om valget af en teknisk løsning tog det mig også mærkbar tid at forstå motivationen hos en af parterne (det var en meget usædvanlig sag), men efter motivationen var klar, var løsningen indlysende.
Situationen er denne: en ny udvikler dukker op i et team på omkring 20 personer, lad os kalde ham Stas. På det tidspunkt var vores standardværktøj til kommunikation som et team 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 kilder var offentligt tilgængelige, og som brugte offentligt beskrevne protokoller. Skype er ikke et af disse værktøjer. Vi brugte meget tid på at diskutere fordele og ulemper ved denne tilgang, forsøg på at lancere analoger af Skype på forskellige operativsystemer, Stas' forsøg på at overbevise holdet om at skifte til andre standarder, skrive til ham personligt via mail, ringe til ham personligt på telefon, købe ham en anden computer specielt til Skype osv. Til sidst indså jeg, at dette problem i bund og grund ikke er teknisk eller organisatorisk, det er temmelig ideologisk, endda, kan man sige, religiøst (for Stas). Selvom vi til sidst tilsluttede Stas og Skype (hvilket tog flere måneder), ville problemet opstå igen på ethvert efterfølgende instrument. Jeg havde ingen reelle midler til min rådighed til at ændre Stas' verdensbillede, og der var ingen grund til at forsøge at ændre verdensbilledet for et team, der fungerede perfekt i dette miljø. Personen og virksomheden var simpelthen ortogonale i deres verdensbillede. I sådanne situationer er en god løsning organisatorisk. Vi flyttede Stas til et andet hold, hvor han var mere organisk.
Årsagen til denne konflikt er efter min mening uoverensstemmelsen mellem en bestemt persons personlige kultur (som har en stærk mening, der ikke tillader ham at gå på kompromis) og virksomhedens kultur. I dette tilfælde er det naturligvis lederens fejl. Det var oprindeligt forkert at tage ham med på et projekt af denne art. Stas flyttede til sidst til et open source softwareudviklingsprojekt og udmærkede sig der.
Et godt eksempel på en konflikt forårsaget af både udviklerens barnlige holdning og manglerne i arbejdsprocessen er en situation, hvor udvikleren og QA-teamet i mangel af en definition af udført har forskellige forventninger til beredskabet mht. funktionen overført til QA. Udvikleren mente, at det var nok at skrive koden og smide funktionen over hegnet til QA - de ville ordne det derude. En ret moden og erfaren programmør i øvrigt, men det var hans interne tærskel for kvalitet. QA var uenig i dette og krævede at vise og beskrive for dem, hvad han selv havde tjekket, og krævede et testscript til dem. De havde tidligere haft problemer med funktionalitet fra denne udvikler og ønskede ikke at spilde deres tid igen. Forresten havde de ret - funktionen virkede virkelig ikke, han tjekkede ikke koden, før han sendte den til QA.
For at løse situationen bad jeg ham om at vise mig, at alt virkelig fungerede (det virkede ikke, og han var nødt til at ordne det), vi talte med teamet og med QA-definitionen af færdig (de nåede det ikke i skriver, fordi vi ikke ønskede at gøre processen for bureaukratisk ), ja, vi skilte snart med denne specialist (til generel lettelse).
Fra arbejdsgangens synspunkt er mulige forbedringer i dette tilfælde tilstedeværelsen af en definition af udført, krav til understøttelse af hver enhedsfunktion og integrationstest og en beskrivelse af test udført af udvikleren. I et af projekterne målte vi niveauet af kodedækning ved test under CI, og hvis dækningsniveauet faldt efter tilføjelse af en patch, blev testene markeret som mislykkede, dvs. enhver ny kode kunne kun tilføjes, hvis der var nye tests for den.
Et andet typisk eksempel på en konflikt, der er tæt knyttet til tilrettelæggelsen af arbejdsprocessen. Vi har et produkt, et produktudviklingsteam, et supportteam og en kunde. Kunden har problemer med produktet og kontakter support. Support analyserer problemet og forstår, at problemet er i produktet og overfører problemet til produktteamet. Produktteamet er i en travl tid, en udgivelse nærmer sig, så en billet med et problem fra en kunde, tabt blandt de andre billetter fra udvikleren, som den er tildelt, hænger i flere uger uden opmærksomhed. Support mener, at udvikleren arbejder på kundens problem. Kunden venter og håber, at der arbejdes på deres problem. I virkeligheden sker der ikke noget endnu. Efter et par uger beslutter kunden sig endelig for at interessere sig for fremskridtene og spørger support, hvordan det går. Support beder om udvikling. Udvikleren gyser, kigger gennem listen over billetter og finder en billet fra kunden der. Når han læser en billet fra en kunde, forstår han, at der ikke er nok information til at løse problemet, og han har brug for flere logfiler og lossepladser. Support anmoder om yderligere oplysninger fra kunden. Og så indser kunden, at ingen har arbejdet på hans problem hele tiden. Og torden vil ramme...
I denne situation er løsningen på selve konflikten ret indlysende og lineær (fix produktet, opdater dokumentation og test, formilde kunden, frigiv et hotfix osv.). Det er vigtigt at analysere arbejdsprocessen og forstå, hvem der er ansvarlig for at organisere samspillet mellem de to teams, og hvorfor denne situation blev mulig i første omgang. Det er klart, hvad der skal rettes i processen – nogen skal overvåge det samlede billede uden påmindelser fra kunderne, proaktivt. Billetter fra kunden skal skille sig ud blandt andre billetter fra udviklere. Support bør se, om udviklingsteamet i øjeblikket arbejder på sine billetter, og hvis ikke, hvornår det kan begynde at arbejde, og hvornår resultater kan forventes. Support og udvikling bør med jævne mellemrum kommunikere og diskutere status for billetter, indsamling af nødvendige oplysninger til fejlretning bør automatiseres så meget som muligt osv.
Ligesom fjenden i krig forsøger at ramme krydset mellem to enheder, så i arbejdet er det mest følsomme og sårbare punkt normalt samspillet mellem teams. Hvis support- og udviklingscheferne er gamle nok, vil de selv kunne ordne processen, hvis ikke vil processen fortsætte med at generere konflikter og problemer, indtil en leder griber ind, som kan rette op på situationen.
Et andet typisk eksempel, som jeg har set gentagne gange i forskellige virksomheder, er en situation, hvor et produkt er skrevet af et team, automatiske integrationstest for det er skrevet af et andet team, og infrastrukturen, som det hele drives på, ledsages af et tredje. hold. Der opstår hele tiden problemer ved afvikling af test, og årsagen til problemer i dem kan både være produktet og testene og infrastrukturen. Det er normalt problematisk at blive enige om, hvem der skal udføre den indledende analyse af problemer, filfejl, parselogs af produktet, test og infrastruktur mv. Konflikter her er meget hyppige og på samme tid ensartede. I tilfælde af høj følelsesmæssig intensitet falder deltagerne ofte i en barnlig position, og diskussioner begynder i serien: "hvorfor skal jeg pille ved det her", "de går oftere i stykker" osv.
Fra et workflow-perspektiv afhænger de specifikke trin til at løse et problem af sammensætningen af teamene, typen af test og produkt osv. I et af projekterne indførte vi periodisk vagt, hvor teams overvågede tests én ad gangen, uge for uge. I den anden blev den indledende analyse altid lavet af testudviklerne, men analysen var meget grundlæggende, og produktet var ret stabilt, så det fungerede godt. Nøglen er at sikre, at processen er gennemsigtig, at forventningerne er klare for alle parter, og at situationen føles fair for alle.
Er konflikt overhovedet et problem i en organisation?Er det et dårligt tegn, at konflikter ofte (eller bare periodisk) opstår i dit team? Generelt nej, for hvis der er vækst, udvikling, er der en form for dynamik, så opstår der problemer, som aldrig er blevet løst før, og når de løses, kan der opstå konflikter. Dette er en indikator for, at nogle områder har brug for opmærksomhed, at der er områder til forbedring. Det er slemt, hvis konflikter opstår meget ofte, er svære at løse eller tager lang tid. Dette er højst sandsynligt et tegn på utilstrækkeligt strømlinede arbejdsprocesser og utilstrækkelig modenhed i teamet.
Kilde: www.habr.com