Todellisuus puree
QA-prosessin, työkalujen, ajattelutavan, eetoksen ja asiantuntemuksen perustavanlaatuisiin kysymyksiin voi paneutua, joskus jopa hedelmällisesti. Mikä on hienoa. Nämä aiheet edellyttävät huomattavaa älyllistä ponnistelua jokaiselta todelliselta laadunvarmistuksen ammattilaiselta tai alalle kouluttautuvalta ammattilaiselta. Niistä saa myös hyviä TED-puheita, joten sekin puhuu niiden puolesta. Voit nimittäin julkaista näitä videoita sosiaalisessa mediassasi aina Ragnarökin saapumiseen asti.
Mutta joskus on myös tarpeen perehtyä QA:n vuoristoradan arkisiin ja raadollisiin todellisuuksiin, vaikka näiden todellisuuksien tarkastelu olisikin pelkkää raakaa pragmatismia eikä vaatisi kvanttihyppyjä prosessin ymmärtämisessä tai laatikon ulkopuolista ajattelua.
Vaan juuri päinvastoin: vajoamista siihen mutaan ja draamaan, jota tuo laatikko on aivan liian täynnä, ei voi välttää ajattelemalla sen ulkopuolelta. Koska kyse ei alun perinkään ole laatikosta. Se on Ukkosareena.
Tätä tämä artikkeli siis käsittelee. Se ei tarjoa mitään uutta tai “pelin muuttavaa”, vaan ainoastaan hyvin käytännöllisiä pohdintoja ja neuvoja, jotka perustuvat omiin hermoja raastaviin kokemuksiini QA-johtajana useiden vuosikymmenten ajalta sekä niistä ammentamiini oppeihin. Oma QA-johtotason todellisuuteni, niin sanoakseni. Opit, jotka voit tietenkin vapaasti jättää huomiotta, kiistää tai pilkata parhaaksi katsomallasi tavalla.
Jokaiselle, joka on toiminut QA-johtajana jonkin aikaa, on selvää, että tuon kokemuksen keskeinen trauma on neuvottelu pahamaineisessa “julkaistaanko–ei julkaistaanko” -kokouksessa. Ja siitä selviytyminen.
Sillä juuri silloin kaikki kulminoituu, QA:ta grillataan kuin murhasta epäiltyä ja kaikki etsivät ovat muita “sidosryhmiä” (jos koskaan on ollut olemassa eufemismia). Ja kaikkien etsivien tavoin he haluavat sinulta vain, että allekirjoitat tunnustuksen.
Mutta sen ei tarvitse mennä niin. Tarvitset vain vedenpitävän alibin. Kirjoitan tämän artikkelin tarjotakseni sinulle sellaisen.
Tarinan aika
Suurin virhe, jonka QA-johtajat tekevät mennessään julkaistaanko–ei julkaistaanko-kokoukseen, on valmistautumisen puute. Tai pikemminkin tehokkaan valmistautumisen puute.
Useimmat QA-vetäjät tai -päälliköt menevät tähän kokoukseen “valmistautuneina” ensisijaisesti ja usein yksinomaan virhemittareiden avulla. Avoimien ongelmien määrä, avoimien A-luokan ongelmien määrä, avoimien B-luokan ongelmien määrä, ja niin edelleen. Jos muu tiimi on onnekas, QA-vetäjä pystyy joskus antamaan edes epämääräisen, vaikutelmiin perustuvan käsityksen siitä, kuinka kattavasti QA on testannut tuotetta siihen mennessä. Yleensä tähän käytetty data on kuitenkin vain luettelo suoritetuista testeistä ja testiskripteistä. Se ei lainkaan mittaa todellista testikattavuutta. Nämä ovat työmäärämittareita, eivät todellisia laatumittareita.
Tämän strategian taustalla oleva virhepäätelmä ei rajoitu epäselvien tai merkityksettömien mittareiden käyttöön jonkinlaisen perustelun muodostamiseksi julkaisun puolesta tai sitä vastaan. Tässä tehty virhe on paljon perustavanlaatuisempi.
Sillä edellä kuvattu QA:n päätösstrategia perustuu ilmeiseen kategorialliseen virheeseen. Tässä tilanteessa QA-johto olettaa, että julkaistaanko–ei julkaistaanko-kokouksen tarkoituksena on esittää muille dataa, jonka he itse käsittelevät ja jonka perusteella he tekevät päätöksen. Mikään ei voisi olla kauempana totuudesta tai vahingollisempaa QA:n auktoriteetille.
Mitä muu tuotetiimi tässä kokouksessa odottaa QA-johdolta, ei ole jälleen lisää dataa. Se odottaa selkeää ja auktoritatiivista tuomiota siitä, julkaistaanko tuote vai ei. Nyt. Tänään.
Testaus- ja virhedatat ovat tietenkin tarpeen, jotta QA:n asiantuntijatuomiota voidaan perustella ja jotta sille saadaan hyväksyntä. Mutta QA:n on esitettävä auktoritatiivinen tuomio.
Muuten QA luopuu ainutlaatuisesta vastuustaan ja auktoriteetistaan tuotekehitysorganisaatiossa. Se on pohjimmiltaan välttelevää ja passiivis-aggressiivista toimintaa. Eikä se vahvista QA:n asemaa kyseisessä organisaatiossa.
Ajan mittaan se johtaa QA:n mahdollisuuksien kannalta tuhoisaan kierteeseen, jossa QA:sta ei koskaan tule tasavertaista ääntä kehitysprosessissa. QA valittaa tilanteesta loputtomasti, mutta on usein juuri tästä syystä oman merkityksettömyytensä aiheuttaja.
Tämä tarkoittaa, että QA-johdon on mentävä julkaistaanko–ei julkaistaanko-kokoukseen mukanaan selkeä ja vakuuttava tarina, joka johtaa yksiselitteiseen suositukseen. Toisin sanoen sinun on mentävä kokoukseen valmiina ja halukkaana allekirjoittamaan pisteviivalle digitaalisella verelläsi minkä tahansa esittämäsi suosituksen. Et voi pelata varman päälle. Et voi piiloutua uskottavan kiistettävyyden helman alle.
Sillä jos et toimi näin, sinä ja tiimisi menetätte kaiken uskottavuutenne organisaatiossa. Ja mikä vielä pahempaa, asetatte itsenne tilanteeseen, jossa saatte kaiken syyn niskoillenne, jos muiden täytyy tehdä päätös puolestanne ja lopputuloksena on tuotannossa tapahtuva laatukatastrofi. Rehellisesti sanottuna juuri sitä muut toiminnot haluavat tapahtuvan. Ne haluavat syyttää teitä kaikesta ja käyttää omaa jahkailuanne tuotteen laadusta todisteena teitä vastaan.
Yksi keskeinen mahdollistaja tälle passiivis-aggressiiviselle lähestymistavalle julkaistaanko–ei julkaistaanko-päätökseen on vakaumus — jota usein käytetään opportunistisesti — että “ei ole väliä, mitä sanon, he julkaisevat joka tapauksessa”. Tämä ajattelutapa, tämä strateginen voimattomuuden omaksuminen, ylläpitää juuri QA:n organisatorista voimattomuutta. Puhutaan itsensä toteuttavasta ennusteesta!
Politiikasta ja itseään sabotoivasta psykologiasta riippumatta tämä strategia perustuu perustavanlaatuiseen väärinkäsitykseen siitä, mitä QA:lta tuossa kokouksessa pyydetään. QA:ta ei nimittäin todellisuudessa pyydetä tekemään peruuttamatonta julkaistaanko–ei julkaistaanko-päätöstä, vaikka päätös, joka sinua pyydetään julkisesti tekemään, esitetäänkin julkisessa muodossa juuri sellaisena.
Ja kyllä, sinun on edelleen esitettävä auktoritatiivinen tuomio. Mutta voidaksesi tehdä sen, sinun on ymmärrettävä kysymys, johon sinun on tosiasiassa vastattava auktoritatiivisesti.
Kysymys, johon laadunvarmistuksen johtoa todella pyydetään vastaamaan, kuuluu näin: Mitkä ovat julkaisemisen riskit — niiden todennäköinen esiintyvyys ja vakavuus tuotantoympäristössä — tänään? Entä jos julkaiseminen siirrettäisiin esimerkiksi ensi kuuhun? Toisin sanoen teitä pyydetään tekemään riskiarvio, joka mahdollistaa ylimmän johdon järkevän riskinoton kyseisellä hetkellä.
Tämä tarkoittaa, että lopullinen vastauksenne julkaistaanko vai ei -kokouksessa on viime kädessä lopullinen vastaus riskistä. Kyse ei ole siitä, painetaanko painiketta, joka laukaisee raketin avaruuteen.
Tästä puolestaan seuraa, että kokouksessa esittämänne laatukuvaus on viime kädessä perustuttava skenaarioihin. Toisin sanoen vastaus ei ole yksinkertainen kyllä tai ei, vaikka kaikki muut kuinka haluaisivat sen olevan sellainen voidakseen vapauttaa itsensä päätöksestä aiheutuvasta vastuusta (mikä ei koskaan pidä paikkaansa, vai mitä?). Hieman kaavamaisesti esityksenne tulisi koostua kahdesta osasta:
- Ensinnäkin arvovaltainen ja *merkityksellisesti* dataan perustuva kuvaus tuotteen laadun nykytilasta. Sen tueksi tarvitaan mittareita. Juonipaljastus: tarvitsette tähän enemmän kuin virhemittareita.
- Toiseksi arvovaltainen arvio siitä, kuinka paljon piilevää laatua jää saavuttamatta, jos tuote päätetään julkaista nyt. Onko tätä laatua niin paljon, että julkaisuaikatauluun kannattaa lisätä aikaa laatudebtin kuromiseksi umpeen? Jos on, millaisia ajan ja laadun välisiä kompromisseja laadunvarmistus suosittelee? Ja mihin tuotteen toiminnallisuuden erityisalueisiin tämän pidennyksen aikana pitäisi keskittyä, ja mistä tietäisimme, että piilevä laatu on saatu toteutettua?
Tämä ei itse asiassa ole tapa väistää esitettyä kysymystä. Se on tapa vastata siihen ottaen täysimääräisesti huomioon kaikki kyseiseen päätökseen liittyvät parametrit, muuttujat ja kustannukset — tänään, ensi viikolla tai ensi kuussa.
Koska — ja tämä totuus on syytä iskostaa laadunvarmistusta koskevaan ajatteluusi — todellinen yleisösi tässä kokouksessa eivät ole muut toimintojen johtajat. Se on ylin johto. Riippumatta siitä, ovatko he fyysisesti läsnä kokouksessa vai eivät. Se, mitä sanot, välitetään heille viipymättä. Luota minuun tässä asiassa.
Ja tämä toimii vain sinun eduksesi. Sillä toimitusjohtajat ja operatiiviset johtajat arvostavat enemmän kuin mitään muuta sitä, että heille esitetään merkityksellisiä vaihtoehtoja konkreettisten tosiasioiden ja tietojen tukemina. Eniten he inhoavat sitä, että heille vain sanotaan: “Öh, emme ole valmiita julkaisemaan. Emmekä pysty kertomaan tarkalleen miksi. Mutta ehkä pystymme siihen neljän kuukauden kuluttua.” Tämän vuoksi toimitusjohtajat etsivät uusia yritysostoja — saadakseen kokonaan uuden tuotteen toimitustiimin.
Tuotteen toimitustiimien ikuinen valitus on, että ylin johto määrää yksipuolisesti ehdottoman julkaisupäivän, josta se kieltäytyy joustamasta. Voisit kysyä itseltäsi, miksi he tekevät näin niin johdonmukaisesti.
Siksi, etteivät he koskaan saa lopullista vastausta tuotteen laadun tilasta eivätkä siihen, mikä päivämäärä olisi mahdollinen, jos heidän suosimaansa julkaisupäivää ei voida saavuttaa. Siksi he määräävät oman päivämääränsä. Tuotetiimi ei ole jättänyt heille mielekkäitä vaihtoehtoja.
Siksi sinun on mentävä julkaistaanko vai ei -kokoukseen vakuuttavan, moniulotteisen, tosiasioihin ja skenaarioihin perustuvan kuvauksen kanssa. Sen tulee johtaa arvovaltaisiin suosituksiin, jotka voivat itsessään sisältää mielekkäitä laadun kustannus–hyötyvaihtoehtoja siitä, julkaistaanko tuote vai ei. Muutaman minuutin mutiseminen virhemittareista ja päätöksen jättäminen kaikkien muiden tehtäväksi ei ole tällainen kuvaus.
Tämän toteuttamiseksi oman laadunvarmistusmenetelmäsi, koulutuksesi ja mittarisi on tietenkin oltava huippukunnossa. Olen kirjoittanut näistä aiheista yksityiskohtaisia artikkeleita muualla (eli LI:ssä), mutta prosessiteoreettisina ne jäävät tämän artikkelin pragmaattisen näkökulman ulkopuolelle.
Onnellinen loppu
Edellä kirjoittamani saattaa vaikuttaa uhkaavalta ja ehkä hieman ristiriitaiselta — ainakin pinnalta katsottuna. Päätän siis tämän artikkelin kertomalla kokemuksestani erittäin onnistuneessa julkaistaanko vai ei -kokouksessa. Kokous eteni hieman eri tavalla kuin edellä kuvaan, ja eri tavalla kuin edes itse odotin.
Tiimini oli testannut täysin uutta tuotetta. Kyse ei ollut vain uudesta tuotteesta, vaan tuotteesta, joka vastasi yritykselle ennestään tuntemattoman tuotemarkkinaraon tarpeeseen. Se oli alusta alkaen piilevien vaarojen, tuntemattomien tuntemattomien ja epämiellyttävien yllätysten maraton.
Julkaistaanko vai ei -kokouksen aika koitti. Olin toimikauteni alussa laadunvarmistusjohtajana ottanut käyttöön tiukan toimintamallin laatumittareiden määrittelyyn, mukaan lukien testikattavuuden mittarit, jotka perustuivat vaatimuksiin eivätkä moduuleihin tai testikomentosarjoihin. Meillä oli käytössä myös virhemittareiden lisäksi virhetrendien mittarit ja koodimuutosten nopeuden mittarit kertomuksemme tueksi.
Ja kaikki nämä mittarit olivat kiistatta positiivisia. Kaikki järjestelmät olivat valmiina. Jos–niin–muuten-skenaarioita ei tarvittu. En nähnyt kerrankin mitään syytä olla sanomatta kovaan ääneen ja yksiselitteisesti: “Julkaistaan!”, ilman ehtoja.
Teknisesti se ei kuitenkaan ollut minun tehtäväni. Projektia oli johtanut yksi laadunvarmistuspäälliköistäni, ja hänen tehtävänään oli antaa kyseinen arvovaltainen päätös. Tämä päällikkö tiivisti kaikki mittarit täsmällisesti ja totesi, että ne olivat kaikki positiivisia.
Sitten hän yllätyksekseni epäröi ja kierteli sitä, oliko tuote valmis julkaistavaksi vai ei. Yllätyin tietenkin siksi, että olimme keskustelleet laadunvarmistuksen kannasta ennen kokousta. (Tärkeä huomautus: Älä yllätä esihenkilöäsi kokouksessa. Älä koskaan.)
Kysyin päälliköltä: “Mitä tarvittaisiin, jotta voisit suositella julkaisupäätöstä hyvillä mielin? Jos ei tänään, niin tulevaisuudessa?”
Jälleen yllätyksekseni johtaja ei pystynyt — tai halunnut — vastaamaan kysymykseeni. Minulle kävi selväksi, ettei tämä johtaja yksinkertaisesti halunnut ottaa vastuuta päätöksen tekemisestä ja nimensä panemisesta alle. Se oli mielestäni äärimmäisen pettymyksellistä.
Se oli myös loukkaus projektin suunnittelupäällikköä kohtaan. Hän oli tukenut QA-työtä väsymättä ja suunnitellut ensiluokkaisen tuotteen. Hän ei ansainnut joutua tällä tavoin yllätetyksi. En minäkään.
Niinpä astuin esiin ja sanoin: ”En ole nähnyt enkä kuullut yhtäkään hyvää syytä olla julkaisematta tätä tuotetta TÄNÄÄN. Se on QA:n päätös, ja minä QA-johtajana otan täyden vastuun tämän päätöksen tekemisestä.”
Luulin, että suunnittelupäällikkö aikoi suudella minua. Mutta tuon kokouksen jälkeen QA sai suunnittelutiimiltä, projektinhallinnalta ja tuotehallinnalta valtavasti arvostusta ja kunnioitusta.
Koska meidän maailmassamme vakavasti otetuksi tulemisen edellytys on vastuun ottaminen julkisesti. Tunsin oloni täysin turvalliseksi tehdessäni niin sillä hetkellä, koska tarinaamme oli valmistauduttu alusta lähtien. Ja se oli kirjoitettu onnellinen loppu mielessä.
Tuote osoitti julkaisun jälkeen käytössä erinomaista laatua ja oli suuri menestys. Julkaisun lykkääminen vastuun välttämiseksi julkaisupäätöksessä olisi johtanut vain tuotteen laadun mitättömään paranemiseen kohtuuttomilla rahallisilla ja markkinoillepääsyyn kuluvilla aikakustannuksilla.
Se, miten teimme sen, on toisen päivän tarina.
Kuten aina, paljon onnea QA-työhönne.
Aiheeseen liittyvä podcast: TIIMITYÖ, TEKOÄLY JA KONTAINERISOINTI (NASA:N MICHAEL RITCHSONIN KANSSA)
