Virkeligheden bider
Man kan, nogle gange endda på frugtbar vis, beskæftige sig med grundlæggende spørgsmål om QA-processer, værktøjer, tankegang, etik og ekspertise. Hvilket er godt. Disse emner kræver en betydelig mental indsats fra enhver ægte QA-professionel eller professionel under oplæring. De egner sig også godt til TED-talks, så det taler bestemt til deres fordel. For man kan lægge de videoer på sine sociale medier, indtil Ragnarok indtræffer.
Men nogle gange er det også nødvendigt at beskæftige sig med QA-rutsjebanens helt konkrete realiteter, selv hvis det udelukkende er en øvelse i rå pragmatisme, som ikke kræver kvantespring i procesforståelsen eller tænkning uden for boksen.
Men faktisk det stik modsatte: Man kan ikke undgå at bevæge sig ned i det mudder og drama, som netop det, boksen er alt for fuld af, indebærer, ved at tænke uden for den. For det er slet ikke en boks til at begynde med. Det er en Thunderdome.
Det er altså det, denne artikel handler om. Den har ikke noget nyt eller “banebrydende” at tilbyde, kun meget praktiske refleksioner og råd baseret på mine egne neglebidende oplevelser som QA-leder gennem flere årtier samt de erfaringer, jeg har draget af dem. Min egen QA-ledelsesvirkelighed, så at sige. Erfaringer, som du naturligvis frit kan ignorere/modsige/gøre nar af, som du finder passende.
Det står klart for enhver, der har arbejdet med QA-ledelse i længere tid, at det centrale traume ved denne oplevelse er at forhandle det berygtede “udgiv-ikke-udgiv”-møde. Og at overleve det.
For det er her, alt kulminerer, QA bliver afhørt som en mordmistænkt, og detektiverne er alle de andre “interessenter” (et eufemisme, hvis der nogensinde har været et). Og ligesom alle detektiver vil de kun have én ting fra dig: at du underskriver tilståelsen.
Men sådan behøver det ikke at være. Det eneste, du har brug for, er et vandtæt alibi. Jeg skriver denne artikel for at give dig et.
Historietid
Den største fejl, QA-ledere begår, når de går ind til et udgiv-ikke-udgiv-møde, er manglende forberedelse. Eller rettere: mangel på effektiv forberedelse.
De fleste QA-ledere eller -chefer går primært, og ofte udelukkende, ind til dette møde med fejlstatistik. Et antal åbne problemer, antal åbne problemer i kategori A, antal åbne problemer i kategori B, og så videre. Nogle gange vil QA-lederen, hvis resten af teamet er heldigt, være i stand til at give et vagt, impressionistisk indtryk af, hvilken testdækning QA har opnået indtil det tidspunkt. Som regel består de data, de bruger til dette, dog blot af en oversigt over de tests og testskripter, de har kørt. Hvilket på ingen måde er en måling af den faktiske testdækning. Det er indsatsmålinger, ikke reelle kvalitetsmålinger.
Fejlslutningen bag denne strategi rækker videre end brugen af tvetydige eller meningsløse målinger til at argumentere (på en eller anden måde?) for eller imod en udgivelse. Den fejl, der begås her, er langt mere grundlæggende.
For den QA-beslutningsstrategi, der er skitseret ovenfor, bygger på en åbenlys kategorifejl. QA-ledelsen i dette scenarie antager, at formålet med udgiv-ikke-udgiv-mødet er at fremlægge data, som andre skal forbruge og selv træffe en beslutning på baggrund af. Intet kunne være længere fra sandheden eller mere skadeligt for QAs autoritet.
Det, resten af produktteamet forventer af QA-ledelsen på dette møde, er ikke endnu flere data. De forventer en klar og autoritativ afgørelse om, hvorvidt produktet skal udgives eller ej. Nu. I dag.
Test- og fejlinddata vil naturligvis være nødvendige for at forsvare og skabe opbakning til den ekspertvurdering, QA måtte nå frem til. Men QA skal levere en autoritativ afgørelse.
Ellers svigter QA sit særlige ansvar for og sin autoritet i organisationen for produktlevering. Det er grundlæggende undvigende og passivt-aggressivt. Hvilket ikke gør noget for at styrke QAs position i den samme organisation.
Over tid bliver det en dødsspiral for QAs muligheder for at få en ligeværdig stemme i udviklingsprocessen. Det er en situation, QA klager uendeligt over, men som QA ofte selv er ophav til, når denne selv samme grund gør QA irrelevant.
Det betyder, at QA-ledelsen skal gå ind til udgiv-ikke-udgiv-mødet med en klar og overbevisende fortælling, der fører frem til en entydig anbefaling. Med andre ord skal du gå ind til mødet klar og villig til at skrive under på den stiplede linje, i digitalt blod, på den anbefaling, du fremsætter. Ingen gardering. Ingen gemmen sig bag plausibel benægtelse.
For hvis du ikke gør det, mister du og dit team al troværdighed i organisationen. Og endnu værre: I gør jer selv ansvarlige for at få hele skylden, hvis andre er nødt til at træffe beslutningen for jer, og resultatet bliver en kvalitetskatastrofe i produktionen. Hvilket, hvis vi skal være ærlige, præcis er det, de andre funktioner ønsker skal ske. De vil give dig skylden for alt og bruge din egen vaklen i spørgsmålet om produktkvalitet som bevis imod dig.
En vigtig faktor, der muliggør denne passivt-aggressive tilgang til udgiv-ikke-udgiv-beslutningen, er overbevisningen — ofte opportunistisk fremført — om, at “Det er ligegyldigt, hvad jeg siger, de udgiver det alligevel”. Denne tankegang, denne strategiske indtagelse af magtesløshed, er præcis det, der fastholder QAs organisatoriske afmagt. Tal om en selvopfyldende profeti!
Ud over politik og selvdestruktiv psykologi bygger denne strategi på en grundlæggende misforståelse af, hvad QA bliver bedt om at levere på mødet. For QA bliver faktisk ikke bedt om at træffe en uigenkaldelig udgiv-ikke-udgiv-beslutning, selvom den beslutning, du offentligt bliver bedt om at træffe, antager denne offentlige form.
Og ja, du skal stadig fremlægge en autoritativ afgørelse. Men for at gøre det skal du forstå det spørgsmål, du faktisk skal besvare autoritativt.
Det spørgsmål, QA-ledelsen virkelig bliver bedt om at besvare, er dette: Hvilke risici — deres sandsynlige forekomst og alvorlighed i felten — er der ved at udsende i dag? I modsætning til for eksempel næste måned? Med andre ord bliver du bedt om at levere en risikovurdering, der gør det muligt for den øverste ledelse at tage rationelle risici på det pågældende tidspunkt.
Det betyder, at dit endelige svar på mødet om, hvorvidt produktet skal udsendes eller ej, i sidste ende er et endeligt svar om risiko. Ikke om, hvorvidt man skal trykke på knappen, der sender raketten ud i det ydre rum.
Det betyder igen, at den kvalitetsfortælling, du præsenterer på mødet, i sidste ende skal være scenariebaseret. Det vil sige, at det ikke vil være et simpelt ja eller nej, uanset hvor meget alle andre ønsker det for at fralægge sig ethvert ansvar for beslutningen (hvilket aldrig er tilfældet, vel?). For at skematisere det en smule bør din præsentation have to dele:
- For det første en autoritativ, *meningsfuldt* datadrevet erklæring om den aktuelle tilstand af produktkvaliteten. Med målinger til at understøtte den. Spoiler: Du får brug for mere end fejlmålinger for at gøre dette.
- For det andet en autoritativ vurdering af den latente kvalitet, der vil blive efterladt på bordet, hvis beslutningen er at udsende produktet nu. Er den så stor, at det kan betale sig at føje tid til udgivelsesplanen for at indfri denne kvalitetsgæld? Hvis ja, hvilke afvejninger mellem tid og kvalitet anbefaler QA? Og hvilke specifikke områder af produktets funktionalitet skal målrettes under denne forlængelse, og hvordan ved vi, at den latente kvalitet er blevet realiseret?
Dette er faktisk ikke en måde at undvige det spørgsmål, der bliver stillet, på. Det er en måde at besvare det i den fulde sammenhæng af alle de parametre, variabler og omkostninger, der er forbundet med den beslutning — i dag, i næste uge eller næste måned.
For — og dette er en sandhed, du skal brænde ind i din QA-bevidsthed — er dit egentlige publikum på det møde ikke de andre funktionsansvarlige. Det er den øverste ledelse. Uanset om de fysisk er til stede på mødet eller ej. Det, du siger, vil blive viderebragt til dem med det samme. Stol på mig.
Og det er kun en fordel for dig. For det, CEO'er og COO'er bedst kan lide, er at blive præsenteret for meningsfulde muligheder, understøttet af konkrete fakta og data. Det, de hader mere end noget andet, er blot at få at vide: "Øh, vi er ikke klar til at udsende. Og vi kan ikke fortælle dig præcis hvorfor. Men det kan vi måske om fire måneder." Det er derfor, CEO'er går på jagt efter nye opkøb — for at få et helt nyt produktleveringsteam.
Den tilbagevendende klage fra produktleveringsteams er, at den øverste ledelse ved dekret fastsætter en hård udgivelsesdato, som de nægter at gå på kompromis med. Du bør måske spørge dig selv, hvorfor de gør dette så konsekvent.
Det skyldes, at de aldrig kan få et endeligt svar på produktkvalitetens tilstand, og hvis deres foretrukne udsendelsesdato ikke kan overholdes, hvilken dato det så kan ske. Så de fastsætter deres egen. Fordi produktteamet ikke har givet dem nogen meningsfulde alternativer.
Du skal derfor gå til mødet om, hvorvidt produktet skal udsendes eller ej, med en overbevisende, tredimensionel, faktabaseret og scenariebaseret fortælling, der fører frem til et autoritativt sæt anbefalinger, som selv kan omfatte meningsfulde muligheder for omkostninger og gevinster ved kvalitet i forbindelse med beslutningen om at udsende — eller lade være. At mumle i et par minutter om fejlmålinger og derefter overlade beslutningen til alle andre er ikke den fortælling.
For at gøre dette skal du naturligvis have din egen QA-metode, træning og dine målinger i tiptop stand. Jeg har skrevet detaljerede artikler om disse emner andre steder (dvs. på LI), men da de er proces-teoretiske, ligger de uden for denne artikels pragmatiske fokus.
En lykkelig slutning
Det, jeg har skrevet ovenfor, kan måske virke skræmmende og muligvis en smule selvmodsigende — på overfladen. Så lad mig afslutte denne artikel med min erfaring fra et meget vellykket møde om, hvorvidt produktet skulle udsendes eller ej. Et møde, der forløb en smule anderledes end det, jeg beskriver ovenfor, og anderledes end jeg selv havde forventet.
Mit team havde testet et helt nyt produkt. Ikke blot et nyt produkt, men et produkt, der henvendte sig til en produktniche, som virksomheden ikke tidligere havde erfaring med. Så det var fra starten et maraton af skjulte farer, ukendte ukendte og ubehagelige overraskelser.
Tiden var kommet til mødet om, hvorvidt produktet skulle udsendes eller ej. I begyndelsen af min tid som QA-direktør havde jeg indført et strengt regime for, hvordan vi skulle definere kvalitetsmålinger, herunder målinger for testdækning, der var kravbaseret og ikke baseret på moduler eller testskripter. Vi havde også ikke blot fejlmålinger, men målinger af fejludviklingen samt målinger af hastigheden på kodeændringer på plads for at styrke vores fortælling.
Og alle disse målinger var uden tvivl positive. Alle systemer var klar. Nej, der var ikke behov for scenarier af typen hvis/så/ellers. For en gangs skyld så jeg ingen grund til ikke at sige højt og tydeligt: "Udsend det!" uden forbehold.
Teknisk set var det dog ikke min rolle at gøre det. Projektet var nemlig blevet ledet af en af mine QA-chefer, og det var denne persons opgave at afsige den autoritative dom. Denne chef opsummerede præcist alle målingerne og anerkendte, at de alle var positive.
Derefter begyndte chefen til min overraskelse at tøve og være usikker på, om det var klar til udsendelse eller ej. Jeg blev overrasket, fordi vi naturligvis havde drøftet, hvad QA's holdning ville være, inden vi gik ind til mødet. (Vigtig bemærkning: Overrask aldrig din chef på et møde. Aldrig.)
Jeg spurgte chefen: "Hvad skulle der til, for at du ville føle dig tryg ved at anbefale en beslutning om udsendelse? Hvis ikke i dag, så i fremtiden?"
Igen til min overraskelse kunne — eller ville — lederen ikke besvare mit spørgsmål. Det stod klart for mig, at denne leder simpelthen ikke ønskede at tage ansvar for at træffe den beslutning, for at sætte sin underskrift på den stiplede linje. Hvilket jeg fandt dybt skuffende.
Det var også en fornærmelse mod den tekniske leder på projektet, som havde været uendeligt støttende over for QA-indsatsen og havde skabt et førsteklasses produkt. Han fortjente ikke at blive taget på sengen på den måde. Det gjorde jeg heller ikke.
Så trådte jeg frem og sagde: “Jeg har hverken set eller hørt nogen god grund til ikke at sende dette produkt på markedet I DAG. Det er QA's dom, og jeg tager som QA-direktør det fulde ansvar for at træffe denne beslutning.”
Jeg troede, at den tekniske leder var på nippet til at kysse mig. Men efter det møde opnåede QA massiv anerkendelse og enorm respekt fra udvikling, projektledelse og produktledelse.
Fordi vejen til at blive taget alvorligt i vores verden går gennem offentligt at tage ansvar. Hvilket jeg følte mig helt tryg ved at gøre på det tidspunkt, fordi vores historie var blevet forberedt på helt fra begyndelsen. Og den var skrevet med en lykkelig slutning for øje.
Da produktet først var udgivet, viste det høj kvalitet i praksis og blev en stor succes. At forsinke udgivelsen for at undgå ansvaret for at træffe en beslutning om, hvorvidt det skulle sendes på markedet eller ej, ville kun have resulteret i en minimal stigning i produktkvaliteten til en urimelig pris i form af penge og tid til markedet.
Hvordan vi gjorde det, er en anden historie til en anden dag.
Som altid ønsker jeg dig held og lykke med din QA-indsats.
Relateret podcast: TEAMARBEJDE, AI OG KONTAINERISERING (MED NASA'S MICHAEL RITCHSON)
