Så förbereder du dig för och överlever beslut om lansering eller inte

Det är alltså detta den här artikeln handlar om. Den har inget nytt eller ”spelförändrande” att erbjuda, bara mycket praktiska reflektioner och råd baserade på mina egna nagelbitande erfarenheter som QA-ledare under flera decennier samt de lärdomar jag har dragit av dem. Min egen QA-chefsrealism, så att säga. Lärdomar som du naturligtvis kan ignorera, motsäga eller håna efter eget gottfinnande.

Det står klart för alla som har arbetat med QA-ledarskap under någon längre tid att det centrala traumat i den erfarenheten är att förhandla om det ökända mötet ”leverera eller inte leverera”. Och att överleva det. 

För det är här allt ställs på sin spets, QA förhörs som en mordmisstänkt och alla andra ”intressenter” är detektiverna (om det någonsin har funnits en eufemism). Och precis som alla detektiver vill de bara att du ska skriva under bekännelsen.

Men det behöver inte vara så. Allt du behöver är ett vattentätt alibi. Jag skriver den här artikeln för att ge dig ett.

Dags för en berättelse

Det största misstaget QA-ledare gör inför ett möte om huruvida något ska levereras eller inte är bristande förberedelser. Eller snarare brist på effektiva förberedelser. 

De flesta QA-ledare eller QA-chefer går in i det här mötet ”förberedda” främst, och ofta uteslutande, med felstatistik. Antalet öppna ärenden, antalet öppna ärenden i kategori A, antalet öppna ärenden i kategori B och så vidare. Ibland kan QA-ledaren, om resten av teamet har tur, ge en vag och impressionistisk bild av vilken testtäckning QA har uppnått fram till den tidpunkten. Vanligtvis består underlaget de använder för detta dock helt enkelt av en förteckning över tester och testskript som de har kört. Det är inte alls ett mått på den faktiska testtäckningen. Det här är insatsmått, inte verkliga kvalitetsmått.

Villfarelsen bakom den här strategin sträcker sig längre än att använda tvetydiga eller meningslösa mått för att argumentera för (någon typ av?) leverans eller utebliven leverans. Misstaget som görs här är mycket mer grundläggande.

QA-beslutsstrategin som beskrivs ovan bygger nämligen på ett uppenbart kategorimisstag. QA-ledningen i det här scenariot antar att syftet med mötet om huruvida något ska levereras eller inte är att presentera data som andra ska ta till sig och själva fatta ett beslut utifrån. Inget kunde vara längre från sanningen eller mer skadligt för QA:s auktoritet.

Det resten av produktteamet förväntar sig av QA-ledningen på det här mötet är inte ännu mer data. De förväntar sig ett tydligt och auktoritativt besked om huruvida produkten ska levereras eller inte. Nu. I dag. 

Självklart kommer test- och feldata att behövas för att försvara och få stöd för det expertbesked QA än kommer fram till. Men det är ett auktoritativt besked QA måste ge. 

Annars överger QA sitt unika ansvar för, och sin auktoritet inom, organisationen för produktleverans. Det är i grunden undvikande och passivt aggressivt. Vilket inte gör något för att stärka QA:s ställning inom samma organisation. 

Med tiden blir det en dödsspiral för QA:s möjligheter att bli en jämbördig röst i utvecklingsprocessen. En situation som QA klagar oavbrutet på, men som QA ofta själv är upphov till genom att på just detta sätt göra sig irrelevant.

Det innebär att QA-ledningen måste gå in i mötet om huruvida något ska levereras eller inte med en tydlig och övertygande berättelse som leder fram till en otvetydig rekommendation. Med andra ord måste du gå in i mötet redo och villig att skriva under på den streckade linjen, med digitalt blod, för vilken rekommendation du än ger. Inga garderingar. Inget gömmande bakom kjolarna på en plausibel förnekbarhet. 

För om du inte gör det kommer du och ditt team att förlora all trovärdighet i organisationen. Och, ännu värre, bädda för att få skulden för allt om andra måste fatta beslutet åt er och resultatet blir en kvalitetskatastrof ute på fältet. Vilket, om vi ska vara ärliga, är exakt vad de andra funktionerna vill ska hända. De vill skylla allt på er och använda ert eget velande kring produktkvaliteten som bevis mot er.

En viktig möjliggörare för detta passivt aggressiva förhållningssätt till beslutet om huruvida något ska levereras eller inte är övertygelsen — som ofta används opportunistiskt —  att ”Det spelar ingen roll vad jag säger, de kommer att leverera ändå”. Detta tankesätt, denna strategiska anpassning till maktlöshet, är precis det som upprätthåller QA:s organisatoriska maktlöshet. Tala om en självuppfyllande profetia! 

Bortsett från politik och självdestruktiv psykologi bygger den här strategin på ett grundläggande missförstånd av vad QA förväntas bidra med på det mötet. QA ombeds nämligen inte att faktiskt fatta ett oåterkalleligt beslut om leverans eller utebliven leverans, även om det beslut du offentligt ombeds fatta tar just den offentliga formen. 

Och ja, du måste fortfarande ge ett auktoritativt besked. Men för att göra det måste du förstå vilken fråga du faktiskt måste besvara auktoritativt.

Frågan som QA-ledningen verkligen ombeds besvara är denna: Vilka är riskerna — deras sannolika förekomst och allvarlighetsgrad i fält — med att lansera idag? I stället för, säg, nästa månad? Med andra ord, du ombeds att tillhandahålla en riskbedömning för att möjliggöra rationellt risktagande från den högsta ledningens sida vid det aktuella tillfället. 

Detta innebär att ditt definitiva svar under mötet om lansering eller ingen lansering i slutändan är ett definitivt svar om risk. Inte om huruvida man ska trycka på knappen som skjuter upp raketen i rymden.

Vilket i sin tur innebär att den kvalitetsbild du presenterar under mötet i slutändan måste vara scenariobaserad. Det vill säga, det kommer inte att vara ett enkelt ja eller nej, oavsett hur gärna alla andra vill ha det så för att slippa allt ansvar för beslutet (vilket aldrig är fallet, eller hur?). För att schematisera det något bör din presentation ha två delar:

• För det första ett auktoritativt, *meningsfullt* datadrivet uttalande om produktkvalitetens aktuella status. Med mätvärden som stöd. Spoilervarning: Du kommer att behöva mer än felmätvärden för att göra detta.
• För det andra en auktoritativ bedömning av den latenta kvalitet som kommer att lämnas obeaktad om beslutet blir att lansera produkten nu. Är den så omfattande att det är värt att lägga till tid i lanseringsplanen för att ta itu med den ackumulerade kvalitetsskulden? Om så är fallet, vilka avvägningar mellan tid och kvalitet rekommenderar QA? Och vilka specifika områden av produktens funktionalitet skulle behöva fokuseras på under denna förlängning, och hur skulle vi veta att den latenta kvaliteten hade realiserats?

Detta är faktiskt inte ett sätt att undvika frågan som ställs. Det är ett sätt att besvara den i det fullständiga sammanhanget av alla parametrar, variabler och kostnader som är förknippade med beslutet — idag, nästa vecka eller nästa månad. 

För, och detta är en sanning du behöver bränna in i ditt QA-medvetande, är din verkliga målgrupp under det mötet inte de andra funktionsansvariga. Det är den högsta ledningen. Oavsett om de fysiskt närvarar vid mötet eller inte. Det du säger kommer att vidarebefordras till dem omgående. Lita på mig.

Och detta fungerar bara till din fördel. För det som vd:ar och operativa chefer uppskattar mer än något annat är att få meningsfulla alternativ presenterade för sig, underbyggda av konkreta fakta och data. Det de avskyr mer än något annat är att bara få höra: ”Eh, vi är inte redo att lansera. Och vi kan inte säga exakt varför. Men det kanske vi kan om fyra månader.” Det är därför vd:ar ger sig ut på jakt efter nya förvärv — för att få ett helt nytt produktleveransteam. 

Det återkommande klagomålet från produktleveransteam är att den högsta ledningen genom dekret fastställer ett hårt lanseringsdatum som de vägrar att kompromissa om. Du kanske bör fråga dig själv varför de gör detta så konsekvent. 

Det beror på att de aldrig kan få ett definitivt svar på produktkvalitetens status, och om deras önskade lanseringsdatum inte kan hållas, vilket datum som då kan hållas. Därför fastställer de sitt eget. Eftersom produktteamet inte har gett dem några meningsfulla alternativ.

Du måste alltså gå till mötet om lansering eller ingen lansering med en övertygande, tredimensionell, faktabaserad och scenariobaserad berättelse att presentera, som leder fram till en auktoritativ uppsättning rekommendationer, vilka i sig kan innehålla meningsfulla alternativ kring kostnader och nyttor avseende kvalitet i beslutet att lansera — eller inte. Att mumla i några minuter om felmätvärden och sedan lämna beslutet åt alla andra är inte den berättelsen.

Självklart måste du för att göra detta ha din egen QA-metodik, utbildning och dina mätvärden i toppskick. Jag har skrivit detaljerade artiklar om dessa ämnen på andra håll (dvs. på LI), men eftersom de är processteoretiska ligger de utanför den pragmatiska inriktningen i den här artikeln.

Ett lyckligt slut

Det jag har skrivit ovan kan verka skrämmande och kanske något motsägelsefullt — på ytan. Så låt mig avsluta den här artikeln med min erfarenhet av ett mycket framgångsrikt möte om lansering eller ingen lansering. Ett som gick något annorlunda än det jag beskriver ovan, och annorlunda även jämfört med hur jag förväntade mig att det skulle gå.

Mitt team hade testat en helt ny produkt. Inte bara en ny produkt, utan en som riktade sig mot en produktnisch som företaget saknade tidigare erfarenhet av. Så det var från början ett maraton av dolda faror, okända okända faktorer och obehagliga överraskningar.

Tiden kom för mötet om lansering eller ingen lansering. I början av min tid som QA-chef hade jag infört ett strikt regelverk för hur vi skulle definiera kvalitetsmätvärden, inklusive mätvärden för testtäckning som var kravbaserad, inte baserad på moduler eller testskript. Vi hade också inte bara felmätvärden, utan även mätvärden för feltrender och mätvärden för kodändringshastighet på plats för att stärka vår berättelse. 

Och alla dessa mätvärden var otvetydigt positiva. Alla system var gröna. Inga scenarier av typen om/så/annars behövdes. För en gångs skull såg jag ingen anledning att inte säga högt och tydligt: ”Lansera!”, utan förbehåll. 

Tekniskt sett var det dock inte min roll att göra det. Projektet hade nämligen letts av en av mina QA-chefer, och det föll på den personen att avge den auktoritativa bedömningen. Denna chef sammanfattade korrekt alla mätvärden och bekräftade att de alla var positiva. 

Sedan började chefen, till min förvåning, tveka och sväva på målet kring huruvida det var redo att lanseras eller inte. Jag blev förvånad eftersom vi naturligtvis hade diskuterat vilken ståndpunkt QA skulle inta innan vi gick in i mötet. (Viktig anmärkning: Överraska aldrig din chef på ett möte.)

Jag frågade chefen: ”Vad skulle krävas för att du skulle känna dig trygg med att rekommendera ett lanseringsbeslut? Om inte idag, så längre fram?”

Återigen till min förvåning kunde — eller ville — chefen inte svara på min fråga. Det stod klart för mig att den här chefen helt enkelt inte ville ta ansvar för att fatta det beslutet, för att skriva under på den streckade linjen. Vilket jag tyckte var oerhört nedslående. 

Det var också en förolämpning mot teknikchefen för projektet, som hade varit oavbrutet stöttande i QA-arbetet och hade utvecklat en förstklassig produkt. Han förtjänade inte att bli tagen på sängen på det här sättet. Det gjorde inte jag heller.

Så jag ingrep och sa: ”Jag har varken sett eller hört något gott skäl till att inte lansera den här produkten IDAG. Det är QA:s utlåtande, och jag, som QA-chef, tar fullt ansvar för att fatta det här beslutet.”

Jag trodde att teknikchefen var på väg att kyssa mig. Men efter det mötet fick QA ett enormt anseende och stor respekt från teknikavdelningen, projektledningen och produktledningen. 

För vägen till att bli tagen på allvar i vår värld går genom att offentligt ta ansvar. Vilket jag kände mig helt trygg med att göra i det ögonblicket, eftersom vår berättelse hade förberetts för redan från början. Och den hade skrivits med ett lyckligt slut i åtanke.

Produkten visade, när den väl hade lanserats, mycket hög kvalitet ute på fältet och blev en stor framgång. Att fördröja lanseringen för att slippa ta ansvar för beslutet om huruvida produkten skulle lanseras eller inte hade bara lett till en minimal ökning av produktkvaliteten, till en orimlig kostnad i pengar och tid till marknaden. 

Hur vi gjorde det är en annan historia för en annan dag.

Som alltid önskar jag dig lycka till i ditt QA-arbete.

Relaterad podcast: TEAMWORK, AI OCH KONTAINERISERING (MED NASA:S MICHAEL RITCHSON)