Virkeligheten biter
Man kan, noen ganger til og med på fruktbart vis, ta opp grunnleggende spørsmål om QA-prosess, verktøy, tankesett, etos og ekspertise. Noe som er flott. Disse temaene krever omfattende mental innsats av enhver ekte QA-profesjonell eller profesjonell under opplæring. De egner seg også godt for TED-foredrag, så det teller også til deres fordel. For du kan legge ut disse videoene på sosiale medier helt til Ragnarok kommer.
Men noen ganger er det også nødvendig å ta for seg de detaljerte realitetene i QA-berg-og-dal-banen, selv om det å forholde seg til disse realitetene utelukkende er en øvelse i rå pragmatisme, som ikke krever noen kvantesprang i prosessforståelse eller noen tenkning utenfor boksen.
Men snarere det stikk motsatte: Det å gå ned i gjørmen og dramaet rundt alt det boksen faktisk er altfor full av, kan ikke unngås ved å tenke utenfor den. For det er ikke en boks til å begynne med. Det er en Tordenkuppel.
Det er dette denne artikkelen handler om. Den har ikke noe nytt eller «banebrytende» å tilby, bare svært praktiske refleksjoner og råd basert på mine egne nervepirrende erfaringer som QA-leder gjennom flere tiår, samt lærdommer jeg har trukket fra dem. Min egen QA-ledervirkelighet, om man vil. Lærdommer som du selvfølgelig står fritt til å ignorere, motsi eller latterliggjøre etter eget forgodtbefinnende.
Det er klart for alle som har vært i QA-ledelse en stund, at det sentrale traumet ved denne erfaringen er å forhandle om det beryktede «skal leveres–skal ikke leveres»-møtet. Og å overleve det.
For det er her alt tilspisser seg, QA grilles som en drapsmistenkt, og detektivene er alle de andre «interessentene» (en eufemisme om det noen gang har vært en). Og, som alle detektiver, vil de bare at du skal undertegne tilståelsen.
Men det trenger ikke å være slik. Alt du trenger, er et ugjennomtrengelig alibi. Jeg skriver denne artikkelen for å gi deg et.
Tid for en historie
Den største feilen QA-ledere gjør når de går inn i et «skal leveres–skal ikke leveres»-møte, er manglende forberedelse. Eller snarere: mangel på effektiv forberedelse.
De fleste QA-ansvarlige eller -ledere går inn i dette møtet «forberedt» først og fremst, og ofte utelukkende, med feilstatistikk. Antall åpne problemer, antall åpne problemer i kategori A, antall åpne problemer i kategori B, og så videre. Noen ganger, hvis resten av teamet er heldig, vil den QA-ansvarlige kunne gi et vagt, impressionistisk bilde av hvilken testdekning QA har oppnådd frem til det tidspunktet. Vanligvis er imidlertid dataene de bruker til dette, ganske enkelt en oversikt over testene og testskriptene de har kjørt. Noe som slett ikke er et mål på den faktiske testdekningen. Dette er innsatsmålinger, ikke reelle kvalitetsmålinger.
Feilslutningen bak denne strategien går lenger enn å bruke tvetydige eller meningsløse målinger for å argumentere (på en eller annen måte?) for eller mot lansering. Feilen som gjøres her, er langt mer grunnleggende.
For QA-beslutningsstrategien som er skissert ovenfor, bygger på en åpenbar kategorifeil. QA-ledelsen i dette scenarioet antar at formålet med «skal leveres–skal ikke leveres»-møtet er å presentere data som andre skal ta til seg og selv ta en beslutning på grunnlag av. Ingenting kunne vært lenger fra sannheten eller mer skadelig for QAs autoritet.
Det resten av produktteamet forventer av QA-ledelsen i dette møtet, er ikke enda mer data. De forventer en klar og autoritativ avgjørelse om hvorvidt produktet skal lanseres eller ikke. Nå. I dag.
Test- og avviksdata vil selvfølgelig være nødvendige for å forsvare og skape oppslutning om den ekspertavgjørelsen QA måtte komme frem til. Men det er en autoritativ avgjørelse QA må levere.
Ellers fraskriver QA seg sitt unike ansvar overfor, og sin autoritet i, organisasjonen for produktleveranser. Det er i seg selv unnvikende og passiv-aggressivt. Noe som ikke gjør noe for å styrke QAs posisjon i den samme organisasjonen.
Over tid blir dette en dødsspiral for QAs muligheter til å bli en likeverdig stemme i utviklingsprosessen. En situasjon QA klager endeløst over, samtidig som QA ofte selv skaper sin egen irrelevans av nettopp denne grunnen.
Dette betyr at QA-ledelsen må gå inn i «skal leveres–skal ikke leveres»-møtet med en klar og overbevisende historie som leder frem til en entydig anbefaling. Med andre ord må du gå inn i møtet klar og villig til å signere på den stiplede linjen, i digitalt blod, for den anbefalingen du kommer med. Ingen sikring av egne innsatser. Ingen gjemming seg bak skjørtet til en plausibel benektelse.
For hvis du ikke gjør det, vil du og teamet ditt miste all troverdighet i organisasjonen. Og, enda verre, legge til rette for å ta all skylden hvis andre må ta beslutningen for deg, og resultatet blir en kvalitetskatastrofe hos kundene. Noe som, la oss være ærlige, er nøyaktig det de andre funksjonene ønsker skal skje. De vil legge skylden på deg for alt og bruke din egen vingling omkring produktkvaliteten som bevis mot deg.
En viktig faktor som muliggjør denne passiv-aggressive tilnærmingen til beslutningen om hvorvidt noe skal leveres, er overbevisningen — ofte brukt opportunistisk — om at «Det spiller ingen rolle hva jeg sier, de kommer til å levere uansett». Denne mentaliteten, denne strategiske omfavnelsen av avmakt, er nettopp det som opprettholder QAs organisatoriske avmakt. Snakk om en selvoppfyllende profeti!
Bortsett fra politikk og selvdestruktiv psykologi bygger denne strategien på en grunnleggende misforståelse av hva QA blir bedt om å levere i dette møtet. For QA blir faktisk ikke bedt om å avsi en ugjenkallelig beslutning om hvorvidt noe skal leveres eller ikke, selv om beslutningen du blir bedt om å ta offentlig, har denne offentlige formen.
Og ja, du må fortsatt presentere en autoritativ avgjørelse. Men for å gjøre det må du forstå spørsmålet du faktisk må besvare på en autoritativ måte.
Spørsmålet QA-ledelsen virkelig blir bedt om å besvare, er dette: Hva er risikoene – deres sannsynlige forekomst og alvorlighetsgrad i feltet – ved å levere i dag? I motsetning til for eksempel neste måned? Med andre ord blir du bedt om å gi en risikovurdering som gjør det mulig for toppledelsen å ta rasjonell risiko på det aktuelle tidspunktet.
Dette betyr at det definitive svaret ditt i møtet om hvorvidt produktet skal leveres eller ikke, i bunn og grunn er et definitivt svar om risiko. Ikke om hvorvidt knappen som sender raketten ut i verdensrommet, skal trykkes eller ikke.
Det betyr igjen at kvalitetsbildet du presenterer i dette møtet, til syvende og sist må være scenariobasert. Det vil si at det ikke vil være et enkelt ja eller nei, uansett hvor sterkt alle andre ønsker det for å fraskrive seg ethvert ansvar for beslutningen (noe som aldri skjer, ikke sant?). For å skissere det litt bør presentasjonen din ha to deler:
- For det første en autoritativ, *meningsfull* datadrevet fremstilling av den nåværende tilstanden for produktkvaliteten. Med måledata som underbygger den. Spoiler: Du kommer til å trenge mer enn feilstatistikk for å gjøre dette.
- For det andre en autoritativ vurdering av den latente kvaliteten som blir liggende ubrukt dersom beslutningen er å levere produktet nå. Er den så omfattende at det er verdt å legge til tid i utgivelsesplanen for å hente inn denne kvalitetsgjelden? Hvis ja, hvilke avveininger mellom tid og kvalitet anbefaler QA? Og hvilke konkrete områder av produktets funksjonalitet bør målrettes under denne utvidelsen, og hvordan skal vi vite at den latente kvaliteten er realisert?
Dette er faktisk ikke en måte å unngå spørsmålet som blir stilt på. Det er en måte å besvare det på i den fulle konteksten av alle parameterne, variablene og kostnadene som er knyttet til beslutningen – i dag, neste uke eller neste måned.
For – og dette er en sannhet du må brenne inn i QA-bevisstheten din – er den egentlige målgruppen din i dette møtet ikke de andre funksjonslederne. Det er toppledelsen. Enten de er fysisk til stede i møtet eller ikke. Det du sier, vil bli videreformidlet til dem umiddelbart. Stol på meg.
Og dette fungerer bare til din fordel. For det administrerende direktører og driftsdirektører liker mer enn noe annet, er å bli presentert for meningsfulle alternativer, underbygget av konkrete fakta og data. Det de hater mer enn noe annet, er å bare få beskjed om: «Eh, vi er ikke klare til å levere. Og vi kan ikke fortelle deg nøyaktig hvorfor. Men det kan hende vi kan gjøre det om fire måneder.» Det er derfor administrerende direktører går på jakt etter nye oppkjøp – for å få et helt nytt produktleveringsteam.
Den evigvarende klagen fra produktleveringsteam er at toppledelsen ved dekret fastsetter en hard utgivelsesdato som de nekter å inngå kompromiss om. Du bør kanskje spørre deg selv hvorfor de gjør dette så konsekvent.
Det er fordi de aldri får et definitivt svar på tilstanden til produktkvaliteten, og hvis den foretrukne leveringsdatoen deres ikke kan overholdes, hvilken dato det da kan skje. Derfor fastsetter de sin egen. Fordi produktteamet ikke har gitt dem noen meningsfulle alternativer.
Derfor må du gå inn i møtet om hvorvidt produktet skal leveres eller ikke, med en overbevisende, tredimensjonal, faktabasert og scenariobasert historie å fortelle, som leder frem til et autoritativt sett med anbefalinger. Disse kan selv inkludere meningsfulle alternativer for kostnader og gevinster knyttet til kvalitet rundt beslutningen om å levere – eller ikke. Å mumle i noen minutter om feilstatistikk og deretter overlate beslutningen til alle andre, er ikke den historien.
For å gjøre dette må du naturligvis ha din egen QA-metodikk, opplæring og måledata i toppform. Jeg har skrevet detaljerte artikler om disse emnene andre steder (det vil si på LI), men siden de er prosess-teoretiske, ligger de utenfor denne artikkelens pragmatiske fokus.
En lykkelig slutt
Det jeg har skrevet ovenfor, kan virke skremmende og kanskje litt selvmotsigende – på overflaten. Så la meg avslutte denne artikkelen med min erfaring fra et svært vellykket møte om hvorvidt produktet skulle leveres eller ikke. Et møte som gikk litt annerledes enn det jeg beskriver ovenfor, og annerledes enn jeg selv hadde forventet.
Teamet mitt hadde testet et helt nytt produkt. Ikke bare et nytt produkt, men et produkt som rettet seg mot en nisje selskapet ikke hadde tidligere erfaring med. Det var derfor et maraton av skjulte farer, ukjente ukjente og ubehagelige overraskelser helt fra starten.
Tiden var kommet for møtet om hvorvidt produktet skulle leveres eller ikke. I begynnelsen av perioden min som QA-direktør hadde jeg innført et strengt regime for hvordan vi skulle definere kvalitetsmåledata, inkludert måledata for testdekning som var kravbasert, ikke basert på moduler eller testskript. Vi hadde også ikke bare feilstatistikk, men statistikk over feiltrender og måledata for hastigheten på kodeendringer på plass for å styrke historien vår.
Og alle disse måledataene var utvilsomt positive. Alle systemer var klare. Ingen hvis/så-ellers-scenarier var nødvendige. For én gangs skyld så jeg ingen grunn til ikke å si det høyt og tydelig: «Lever det!», uten forbehold.
Teknisk sett var det imidlertid ikke min rolle å gjøre det. Prosjektet hadde blitt ledet av en av QA-lederne mine, og det falt på denne personen å avgi den autoritative dommen. Denne lederen oppsummerte alle måledataene nøyaktig og erkjente at de alle var positive.
Deretter begynte vedkommende, til min overraskelse, å nøle og vri seg når det gjaldt om produktet var klart til levering eller ikke. Jeg ble overrasket fordi vi selvfølgelig hadde diskutert hva QA sitt standpunkt skulle være før vi gikk inn i møtet. (Viktig merknad: Ikke overrask sjefen din i et møte. Noensinne.)
Jeg spurte lederen: «Hva skal til for at du skal føle deg komfortabel med å anbefale at produktet leveres? Hvis ikke i dag, så på et senere tidspunkt?»
Igjen til min store overraskelse kunne – eller ville – lederen ikke svare på spørsmålet mitt. Det ble klart for meg at denne lederen ganske enkelt ikke ønsket å ta ansvar for å fatte den beslutningen, for å signere på den stiplede linjen. Noe jeg syntes var svært skuffende.
Det var også en fornærmelse mot utviklingslederen for prosjektet, som hadde støttet QA-arbeidet uten ende og utviklet et førsteklasses produkt. Han fortjente ikke å bli tatt på sengen på denne måten. Det gjorde ikke jeg heller.
Så grep jeg inn og sa: «Jeg har verken sett eller hørt noen god grunn til å ikke lansere dette produktet I DAG. Det er QAs dom, og jeg, som QA-direktør, tar fullt ansvar for å fatte denne beslutningen.»
Jeg trodde utviklingslederen var i ferd med å kysse meg. Men etter dette møtet fikk QA enorm anerkjennelse og stor respekt fra utvikling, prosjektledelse og produktledelse.
Fordi veien til å bli tatt på alvor i vår verden går gjennom å ta ansvar offentlig. Noe jeg følte meg helt trygg på å gjøre i det øyeblikket, fordi historien vår hadde vært forberedt helt fra begynnelsen. Og den var skrevet med en lykkelig slutt i tankene.
Da produktet først ble lansert, viste det svært høy kvalitet ute i markedet og ble en stor suksess. Å utsette lanseringen for å unngå ansvaret for å ta en beslutning om å lansere eller ikke lansere ville bare ha resultert i en minimal økning i produktkvalitet, til en urimelig kostnad i form av penger og tid til markedet.
Hvordan vi gjorde det, er en annen historie for en annen dag.
Som alltid, lykke til med QA-arbeidet.
Relatert podkast: TEAMARBEID, KI OG KONTAINERISERING (MED MICHAEL RITCHSON FRA NASA)
