Author: ohjelmistotestaus

Uusi blogin osoite, vanhat vinkeet.

Silti harmittaa.

Testauksenhallintatyökalun osalta iso kauppa oli ns. lähes kiinni. Lupasimme vähentää (potentiaalisen) asiakkaamme laadunvarmistuskuluja 15%. He uskoivat sen.

Sitten meille näytettiin kämmentä! Miksi näin?

Olimme myymässä (potentiaaliselle) asiakkaallemme testauksenhallinnan tehostamista, eli vastaavan työn tekemistä vähemmällä tuntimäärällä. Valitettavasti emme tajunneet, että asiakkaamme asiakas maksaa edelleen testauksesta mieluummin tunti- kuin laatuperusteisesti. Emme ymmärtäneet paikkaamme arvoketjussa. (Potentiaalisella) asiakkaallamme ei ollut mitään syytä parantaa laadunvarmistusprosessiaan.

Ajattelumalli oli kutakuinkin seuraava:

• Maksamme 100 rahaa jokaista 100 testaukseen käytettyä aikayksikköä kohti
• Odotamme teidän löytävän yhden virheen jokaista aikayksikköä kohti
• Emme maksa tippaakaan enempää, vaikka saisitte kiinni 2 virhettä jokaista aikayksikköä kohti, koska hinnoittelemme alihankintatyömme tuntiperusteisesti. Alihankkijoiden vertailu on helpompaa siten!

Prosessin tehostaminen olisi tarkoittanut suoraan 15% pienempää laskutusta. Kuka sellaista haluaa?

Nykyään puhumme kovasti työn tuottavuuden kasvattamisesta. Käsittääkseni tuottavuuden kasvu tarkoittaa sitä, että samassa ajassa saadaan enemmän aikaiseksi. Tai vastaavasti sama määrä töitä saadaan tehtyä vähemmässä ajassa. Tuottavuuden kasvattamiseen vaikuttaa ensisijaisesti osaaminen. Osaamisen kautta työpäivän aikana saadaan aikaiseksi enemmän hyödykkeitä ja palveluita.

Ammattiliike vaihtaa autosi renkaat puolessa tunnissa. Kuinka paljon enemmän olisit valmis maksamaan siitä, että vaihtoon kuluisikin tunti? Maksaisitko tuplat? Tuskin. Minuakin kiinnostaa enemmän sovitun työn ja tuloksen lopullinen hinta kuin tuntiveloitus.

Isot laivat kääntyvät kovin hitaasti. Asiakkaamme (potentiaalinen) on aloittanut neuvottelunsa oman asiakkaansa siitä, että voisivat ottaa suuremman vastuun laadunvarmistustyöstä. Näin jokainen osapuoli voi keskittyä kokonaistuottavuuden kasvattamiseen.

Silloin myös laadunvarmistusprosessin kehittämiselle on tilausta. Me olemme siinä hyviä.

“Hirvi!” kuuluu pelkääjän paikalta. Kuski ei paina jarrua vaan kysyy ensin “Missä?”. Tottakai eläin on ensin nähtävä omin silmin ennen kuin painetaan jarrua. Tietenkään näin ei aina tieliikenteessä käy, mutta tuotekehityksessä tämä on arkipäivää.

Virheitä on kahdenlaisia. Niitä jotka tapahtuvat systemaattisesti ja niitä jotka tapahtuvat toisinaan. Jälkimmäiset ovat sitä sarjaa jonka tapahtumiseen olosuhteiden ja ajoitusten täytyy osua erityisen hyvin kohdalleen että virhe ilmenee.

Tällaisten virheiden raportointi on työlästä ja korjaaminen vielä työläämpää. Usein nämä virheet jäävätkin pitkäksi aikaa hoitamatta. Virheraportteja pallotellaan tuotekehityksestä testaukseen ja takaisin.

Developer: Could not reproduce, please retest on build 5
Test engineer: Still happens on 1 out of 10 tries
Developer: Could not reproduce, please retest on build 6, please provide a screenshot
Test engineer: Still happens… Did you even investigate?

Kallisarvoista aikaa kuluu tyhjänpäiväiseen pallotteluun todellisen syyn tutkimisen sijaan. Erityisesti tämä ongelma kertaantuu multi-site projekteissa, joissa kehitys tehdään kahdella aikavyöhykkeellä. Virheiden pallottelu saattaa kestää viikkoja ilman todellisia ratkaisuja.

Miksi testaajalla niin usein on raskas todistustaakka siitä että virhe todellakin ilmaantuu? Täytyy tuottaa kuvankaappauksia tai jopa videoita virheestä ennen kuin devaus oikeasti ottaa ongelman tutkintaan. Ongelma täytyy siis ensin omin silmin nähdä. Joskus testaajan on jopa kaivettava speksit esiin ja osoitettava niistä että raportti on todellakin vika eikä feature. Lopulta ongelmien selvittely tällä tavalla eskaloituu myös organisaatiossa ylöspäin ja ratkaisujen kustannukset kasaantuvat.

Tällaiset tilanteet johtuvat siitä että testaus ja tuotekehitys ovat niin usein napit vastakkain. Ei ole keskustelua, kommunikaatio ei ole pelannut ja tuotteen etu on unohtunut.

Ydinvoimalan suunnittelu- ja rakennusvaiheessa turvallisuustekijät ovat aivan oleellisessa asemassa. Työmailla on erikseen nimetyt henkilöt, jotka tarkastavat muiden tekemän työn. Kavereiden tulee olla kokeneita ja asiansa osaavia.

Auton voi katsastaa ainoastaan pätevä henkilö. Autoinsinöörin koulutus, työkokemusta, katsastuksen erikoiskurssit jne pätevöittävät tehtävään. Nollakoulutuksella ei pääse töihin.

Sähkötyömailla on nimetty vastuuhenkilö, joka tarkastaa kytkentöjen turvallisuuden. Ja kuittaa pöytäkirjat omalla nimellään.

Lääketieteellisiin toimenpiteisiin vaaditaan tietty pätevyys.

Kaikki edellämainitut asiat ovat yleisen turvallisuuden kannalta oleellisia, joten laadunvarmistuksen tulee olla huippuluokkaa. Mahdolliset virheet voivat johtaa kuolemiin, joten laaduntarkkailu on erityisen ymmärrettävää.

Entäs nämä:

Viskin- ja viinintuottajat ovat erityisen tarkkoja tuotoksiensa laadusta. Laaduntarkkailusta vastaavat henkilöt ovat omaan asiaansa vihkityneitä ja pitkän kokemuksen omaavia. Mieleen tulee valkopartainen ukkeli. Huono laatu voidaan myydä bulkkituotantoon, mutta oman brandin alla nitä ei markkinoille päästetä. Vaikka juoma päähän menisikin.

Musiikkiteollisuudessa levy-yhtiön edustajana toimii tuottaja. Tuottaja on se henkilö, joka vahtii levyn laatua aina biisien tekemisestä nauhoitukseen ja miksaukseen. Sisäinen laaduntarkkailija siis. Harvoin ihan kokemattomia kavereita.

Kummassakaan ei ole kysymys ihmishengistä, vaikka huono musiikki tai hapokas viini voivat joskus tympäistäkin.

Miten laadunvarmistuksen tärkeys näkyy ohjelmistojen kehityksessä?

• Meillä ei ole alalle valmistavaa yliopisto-/AMK-koulutusta
• Testaustehtäviä pidetään porttina oikeisiin kehitystehtäviin (“Noo, testaile nyt tämä kesä, katsotaan ensi kesänä sitten koodaushommia.”)
• Testaajien urapolku tyssää käytännössä testimanagerin tehtäviin. Seuraava askel on projektipäällikkö. Testausalan osaaminen ei pääse kehittymään.
• Testaajan palkka on saman työkokemuksen omaavaa koodaajaa reilusti huonompi

Ja edelleen puhutaan henkilöistä, joiden tulisi arvioida toisten työn tuloksia kriittisesti.

Softafirman väittäessä laadun olevan tärkeää, kannattaa kysyä miten se näkyy laadunvarmistajien arvostuksessa. Kohdellaanko testausta naapurin vähäpoikana, jota tuotekehityksen isot pojat pitävät lähinnä riesana? Vai pyydetäänkö testaus tasavertaisena peliin mukaan? Miten teillä?

Tuli kannattavammaksi myydä sutta halvalla kuin laatua kalliilla! Lepää rauhassa ammattimies!

…kirjoitti Markku Saksa Taloussanomien kolumnissaan näin ajettiin ammattimies alas. Nykytrendi tosiaankin tuntuu olevan nopea tuoton tavoittelu laadun kustannuksella. Onko testaaminen siis enää kannattavaa? Ylilaadun ja riittävän laadun rajat molemmat liikkuvat huonompaa kohti. Loppuasiakaskin on alkanut tyytymään siihen mitä tarjolla on.

Itse en koskaan osta kodintekniikan tuotteista ensimmäistä versiota. Mieluummin odotan että tuote on kunnolla testattu ja pahimmat viat on ehditty korjaamaan. Kaupassakin tsekkaan aina tarrat useampien pakettien kyljestä kuten parasta ennen päiväyksen maitopurkista. Tsekkaapa ensikerralla huvikseen tietoja usb-kovalevystäsi tai reitittimestäsi kaupan hyllyssä. Vertaile sarjanumerotarrojen tietoja. On jännää huomata kuinka monta eri versiota saman mallin tuotteesta voi hyllystä löytyä. Testausta on ulkoistettu loppukäyttäjälle. En tykkää!

Ammattilaisutta ei minusta silti ole ajettu täysin alas. Nykyammattilaisuutta on keskittyä oikeisiin asioihin.

Apple teki minusta ovelan tempun laadunvarmistuksen näkökulmasta puhelinbisneksellään. Koko tuotekehitys on silmin nähtävästi lähtenyt siitä että loppukäyttäjälle tarjotaan positiivisia käyttäjäkokemuksia. Todellisuudessa iPhonen taustalla oleva toiminnallisuus ei ole niin hyvää. Tyypihyväksyntätestit takkuavat ja operaattoria ahdistaa kun yksi iPhone saattaa kerralla varata kymmenien puhelinten verran verkon resursseja. Mutta ei se haittaa kun laadussa on panostettu juuri oikeaan paikkaan.

Laatukustannusten oikean ajoittamisen lisäksi laatukustannuksia pitää siis keskittää siihen missä se eniten merkitsee. Loppukäyttäjätuotteilla kannattaa keskittyä käyttäjäkokemuksiin. Se on myös bisnesriskien hallintaa.

Jatketaan hivenen viime viikon asiasta. Väitin kirjoituksessa, että testauksen tarkoituksen selvittäminen testaustiimille vähentää turhaa työtä. Mennään vielä pykälää korkeammalle.

Testauksen tarkoituksen määrittelee loppuviimein se optimitaso, millä ulkoisten laatukustannusten ja sisäisten laatukustannusten summa on mahdollisimman pieni. Raa’asti yksinkertaistaen ulkoisilla laatukustannuksilla tarkoitetaan tuotepalautuksista, takaisinvedoista, imagotappioista jne. koituvia kustannuksia. Sisäisillä kustannuksilla tarkoitetaan tuotteen kehityksen aikaisia testaus- ja virheenkorjauskustannuksia.

Aukipiirrettynä edellinen näyttää seuraavalta:

Optimitason määrittäminen on periaatteen tasolla varsin suoraviivaista toimintaa. Omat testauskustannuksetkin voidaan kohtuullisen hyvällä tarkkuudella saada selville ja niihin voidaan vaikuttaa mm. käyttötarkoitukseen sopivilla työkaluilla ja prosessien kehitämisellä. Eli kustannusten kertymisen kulmakerrointa saadaan loivennettua. On helppo ymmärtää, että virheiden etsiminen ja korjaaminen ikuisuuksiin ei palvele taloudellista tulosta.

Tulevien ulkoisten kustannusten arvioinnissa ensisijaisena lähteenä on aikaisempien hankkeiden ja projektien “jälkikustannusten” läpikäyminen. Toimintansa vakiinnuttaneissa yrityksissä on toivottavasti aikaisempi data tallella, mutta tuoreiden yrityksen kohdalla tämä voi olla hankalaa. Projektihistoriaa ei välttämättä ole riittävästi tarjolla. Silloin täytyy tehdä optimitason määrittely parhaan arvauksen mukaan.

Mitäpä luulette, tekisikö Sampo Pankki jotakin testauksen suhteen toisin, jos nyt aloittaisi verkkopankin muutosprojektin? Taikka sähköisen äänestyksen toteuttanut porukka?

Testaus ei ole kuluerä vaan investointi. Testaukseen investointi panostaa virheiden löytämiseen halvimmassa mahdollisessa vaiheessa. Kohtele testausta kuten mitä tahansa muuta investointia, kunnioittaen ja systemaattisesti.

Antti kertoi kirjoituksessaan “Feature managerin heiniä”, että projektissa oli käytetty varsin luovaa ja ketterää testitapausten päivittämistä. Kun projektin kannalta ikävään kohtaan testitapaus oli merkattu failiksi, muutettiin testiä siten, että tulokseksi tulikin pass.

Mikä onkaan testauksen tarkoitus? Voihan olla, että testitapaus oli vain niin spesifinen ja epätodennäköinen, että sen tuloksesta ei tarvitse välittää. Mutta silloin moista testitapausta ei olisi pitänyt edes alunperin laatia.

Kuinka monessa projektissa ylipäätään mietitään, että miksi jotakin testataan?

Cem Kaner toteaa mm. artikkelissaan What Is a Good Test Case, että testauksen tarkoitus tulee pitää mielessä testauksen suunnitteluvaiheessa. Miten muuten voisimme määritellä testauksen resurssit, työkalut, laatia testitapaukset jne?

Avataan Kanerin ajatuksia hieman. Testauksen tarkoituksen määrittelee testattavasta kohteesta, testauksen vaiheesta, kohteen ja käyttötarkoituksen kriittisyydestä jne. Näiden määrittelyjen jälkeen testauksen tarkoitus voi olla yksi tai useampia seuraavista:

• Teknisen tuen ja asiakaspalvelun kustannusten minimointi. Pyritään löytämään ne virheet, jotka aiheuttaisivat tekniseen tukeen paljon yhteydenottoja. Tällaisia voisivat olla esimerkiksi pankkien verkkopalvelut.
• Minimoida turvallisuudesta johtuvat syytteet. Onnettomuuteen tai loukkaantumiseen johtavien virheiden löytäminen on etusijalla. Lennonjohtosoftan kaatuminen voi aiheuttaa toimittajalle kylmää hikoilua.
• Tarkastus ohjelman spesifikaatiota vastaan. Ainoastaan spesifikaation vaatimukset testataan, muita mahdollisia kombinaatioita ei testata. Ei soveltune loppukäyttäjätuotteisiin 🙂
• Löytää tavat tuotteen käyttämiseen virheistä huolimatta. Vaikka jokin tapa ei toimisikaan spesifikaation mukaan, ei virhe ole kriittinen jos sen voi kiertää. Tähän ohjelmien käyttäjät ovatkin varmasti tottuneet.

Lista ei todellakaan ole täydellinen, mutta toimii esimerkinomaisesti. Jos Feature manager olisi ennen testausvaiheen alkua määritellyt testauksen tarkoituksen, ei a) epäkelpoja testitapauksia olisi suunniteltu tai b) olisi “vääriä” testituloksia.

Pysähdy hetkeksi, ennen kuin aloitat testauksen. Selvitä itsellesi ja tiimillesi, että miksi tässä oikein ollaan testaamassa. Turha riuhtominen jää paljon vähemmälle. Säästyy hermoja, aikaa ja rahaa. Lisäksi mahdollisuudet projektin läpimenoon kasvavat oleellisesti.

Onko teillä, blogin lukijat, täysin selvillä, että miksi asioita tehdään? Kertokaa hyviä tai huonoja kokemuksia.

Liiketoiminnan kehittämiskonsultin tehtävä ei ole taputella asiakasta selkään ja sanoa, että tässä firmassa on hommat hyvin hoidossa. Konsultti arvioi firman toimintaa armottomasti, etsii kehityskohteita ja nostaa ongelmat esiin.

Vaan eikös kuulostakin testaukselta?

Testauksen tehtävä ei ole tuottaa todisteita siitä kuinka hyvää softaa tässä vaiheessa onkaan saatu aikaan. Testauksen tehtävä on täsmälleen sama kuin edellä mainitulla konsultilla. Nostetaan kissa pöydälle ja katsotaan mistä kohdin ja millä tavoin softaa kannattaa lähteä parantamaan. Kaikissa projekteissa tietenkään näin ei käy.

Väitän, että testauksen tuloksilla on taipumusta värittyä aina kun testaus toimii osana tulosvastuullista kehittäjätiimiä. Jos en aivan väärin muista, niin Qentinelin Esko Hannula esitti taannoin lehtihaastattelussa rakennusteollisuuteen liittyvän kysymyksen:

Päästäisitkö sinä rakennuttajan tekemään myös kiinteistösi rakennustarkastuksen?

Minä en päästäisi. Minusta on älytöntä toteuttaa suuria tietojärjestelmähankkeita tilaamalla kaikki palvelut, toteutuksesta testaukseen, samalta toimittajalta. Menestyvätkö tällaiset hankkeet oikeasti hyvin vai onko puutteita kokemusten keräämisessä?

Saat paremmat tulokset tietojärjestelmähankkeestasi erottamalla testaus tuotevastuusta.

Suurissa tuotekehitysprojekteissa on usein suuri organisaatio. Tuotekehityksen osista vastaavilla hepuilla on kiinnostavan kuuloisia titteleitä, kuten feature manager. Miten nämä kaverit sitten liittyvätkään testaukseen?

Tyypillisestä tuotekehitysorganisaatiosta löytyy tuotevastuuta kantavat johtajat, yksittäisten projektien tai ominaisuuksien vastuuta kantavat johtajat ja sitten itse tekijät. Tekemisen todellisista tuloksista annettavat näytöt organisaatiossa ylöspäin ovat usein kivoja käppyröitä ja diagrammeja. Metriikoita, joilla mitataan työn hyvyyttä.

Ei varmasti tarvitse kovin pitkään pohdiskella mistä informaatio projektin hyvyydestä nykyisin tulee? Mitkä ovat ne metriikat, jotka kulkeutuvat organisaatiossa aina ylöspäin?

Olin kerran projektissa, jossa testaustiimini vastasi joukosta tuoteprojektin yksittäisiä ominaisuuksia. Perinteisen testaustavan mukaan meillä oli isot testispeksit tarkkojen tapauskuvausten kera. Virheitäkin löytyi ja niistä raportoitiin aktiivisesti. Testiraportit sisälsivät listauksen löydetyistä uusista virheistä ja testauksen perusmetriikat. Perusmetriikkaa olivat testien läpäisyprosentti suhteessa kaikkiin suunniteltuihin tapauksiin sekä suhteessa ajettuihin tapauksiin. Lisäksi mitattiin skipattujen testitapausten määrää ja syitä.

Organisaatiossa ylempänä mitattiin tuotteen kypsyyttä nimenomaan testien läpäisyprosentin tai maturiteetin perusteella. Läpäisyprosentit koko projektin ajan olivat heikot suhteessa tavoiteltuun 95%:iin. Todelliset testien tulokset olivat jossain välillä 40%-80% eivätkä ne kasvaneet kuten toimivassa projektissa tyypillisesti. Projektin aikana vakiintui käytännöksi katselmoida osa-aluekohtaisesti testitulokset “feature managerin” kanssa.

Katselmoinnin lopputuloksena hyvin usein fail statuksen saaneita testitapauksia väännettiin pass statukseen ja merkittiin testitapauksen kommentteihin: “Vika huomioitu. Korjataan seuraavaan releaseen”. Toinen vaihtoehto oli muuttaa testitapausta siten, että faili saatiin väkisin passiksi.

Ensimmäinen vääristymä testituloksiin siis tapahtui jo näin aikaisessa vaiheessa. Onko siis tässä tilanteessa minkäänlaista syytä olettaa, että lisää vääristymiä ei tapahdu myös viestin edetessä pidemmälle?

Tuotteen kypsyyden arvioiminen läpäisyprosentin perusteella ei perinteisessä hierarkisessa organisaatiossa toimi. Läpäisyprosentti on juuri niin hyvä kuin yhdessä sovitaan. Korjaavat toimenpiteet ovat varmasti jokaisen tiedossa.

Hyväksy tulokset sellaisina kuin ne testauksesta saadaan. Kommunikoi asiat avoimesti koko organisaatiossa. Ole avoin äläkä kiillota tuloksia. Käytä niitä tuotteen ja toimintatapojen parantamisvälineenä.

TestausOSYn Oulun osasto järjesti viime viikolla workshopin testauksenhallinnan asioista. Sain toimia tapahtuman ja keskustelun vetäjänä. Kiitoksia vielä osallistujille vilkkaasta keskustelusta. Eniten juteltiin testauksen raportoinnista. Käydään lyhesti läpi osallistujien näkemyksiä asiasta.

Aivan aluksi puhuttiin testauksen raportoinnin tehtävistä, ts. mitä asioita raporttien avulla haluttiin selvittää. Tässäpä listausta:

• Testien kattavuus eli code coverage
• Ohjelmiston testattavuus
• Testien ajamiseen käytetty aika
• Tavoitteiden seuranta
• Testauksen tehokkuuden seuranta
• Virheiden läpivuoto projektin aikana
• Virhekertymä projektin eri vaiheissa
• Testitapausten pass/fail-suhde
• Verifioidut vaatimukset
• Virheiden vakavuus
• Tuotteen maturiteetti

Näiden raporttivaatimusten lisäksi todettiin, että käsintehtävä raportointi on tylsää ja vie kohtuuttoman paljon aikaa. Siksi raporttien pitäisi tulla oikeiden töiden sivutuotteena.

Siinä on erilaisia toiveita melkoisesti. Ja tuossa tuskin on lähellekään kaikki. Ovatko kaikki raportit kaikissa tapauksissa mielekkäitä? Tuskin. Miten testauksen raportointi tulisi rakentaa?

Kaikki lähtee tietenkin tuotteen käyttötarkoituksesta ja tuotekehityksen toimintatavoista. On täysin eri asia raportoida ydinvoimalan ohjausjärjestelmän kuin tietokonepelin testauksesta. Vastaavasti vesiputousmallia käyttävien yritysten raportointitarpeet lienevät oleellisesti erilaisia ketterillä menetelmillä kehittäviin yritykseen nähden.

Riippumatta toimintatavoista ja tuotekehitettävästä tuotteen käyttötarkoituksesta, testauksen raportoinnin tarkoitus voidaan palauttaa kahteen peruskysymykseen:

1. Raporttien on kyettävä antamaan tietoa tuotteen maturiteetista ja pystyttävä arvioimaan mahdollisten virhetilanteiden vaikutuksia *)

2. Raportin perusteella pitää voida tehdä aikataulutukseen liittyviä päätelmiä eli raportin perusteella voidaan vastata kysymykseen “Milloin olemme valmiita?”

Kun raportti kertoo sopivalla tavalla mitä on testattu, miksi on testattu ja miten on testattu, saadaan testaus tukemaan tuotteen koko elinkaarta. Tämä helpottaa paitsi laadunvarmistuksen, myös kehityksen ja tuotetuen keskittymistä oikeisiin asioihin. Loppukäyttäjät kiittävät.

*) Tapaamisessa todettiin, että maturiteetti itsessään voi olla hankala mittari käyttää. Maturiteetin määrittelylle on hirmuinen määrä vaihtoehtoja. Ensi viikon tekstissä Antti pyörittelee eri metriikoita vaihtoehdoksi maturiteetille.

Noniin. Jatketaanpas. Jos et ole vielä lukenu ensimmäistä osaa, lue se ensiksi päästäksesi edes osittain kärryille!

Let the story continue.

Kuten elämässä yleensä, niin tässäkin vaiheessa lopputulokselle on monia vaihtoehtoja. Esimerkiksi:

1. Tilanne muuttuu koko ajan tukalammaksi ja huomaatkin kumppanisi hakeutuvan uusiin kuvioihin ja lopulta jättävän sinut ongelminesi. Alat tuhoamaan sisäistä projektihenkilöstöäsi lempijuomallasi alkoholilla, kunnes jäljelle ei jää enää mitään. Olet omillasi.

2. Menette terapiaan, jossa tilannetta saadaan parannettua hieman, sillä jo major-tason ongelmat alkavat tulla julkiseksi. Luot henkisesti rinnakkaisen virhetietokannan, jonne päivittyvät vain ne ongelmat, jotka eivät saa tilannetta räjähtämään käsiin. Tämä virhetietokanta on avoinna nyt kumppanillesi. Jatkatte yhteiseloanne vähemmän tyytyväisinä, mutta jatkattepa kuitenkin. Ainakin hetkisen. Kunnes…

3. Suhteenne jatkuu yhä onnettomampana, eikä kumpikaan osapuoli menesty. Lopputulos voi kääntyä syksyisenä yönä surulliseksi. Yhdelle tai molemmille. Yhtäaikaa tai perätysten. Hukattu potentiaali korostuu ylilyönteinä. Murheellista.

4. Jonkin critical-tason asian paljastuttua, puhutte asiat suoraan ja joko jatkatte elämäänne hyvässä yhteisymmärryksessä avoimin kortein tai pistätte kantapäät yhteen ja lähdette erisuuntiin hyvin pettyneinä toisiinne.

Haarojen 1 ja 3 lopputulos nyt on täysin ennakoitava, mutta jatketaanpa tätä “flowta” nyt muuten:

Käyt kehityskeskusteluita omassa mielessäsi ja kavereiden kesken. Lopputuloksena tulette päätelmään: “Voi jospa olisin ollut avoin ja rehellinen koko suhteen ajan, olisi suhde todennäköisesti vieläkin hyvissä voimissa. Ja jos taas se ei olisi niitä ongelmia kestänyt, olisi se joutanutkin päättyä ajallaan.”

Rankan kehityskeskustelun jälkeen luotte sinulle uuden strategian ja järjestättekin kavereiden kanssa saunaillan, jonka jälkeen suunnistatte pikkupienissänne kaupungille ja lähimmälle lihatiskille. Jos sieltä uusi kumppani löytyisi. Saapuessanne paikalle, pongaatkin paikalta äärettömän potentiaalisen tapauksen, jolla huhujen mukaan on talouskin kohdallaan. Päätät tehdä taktisen hyökkäyksen: “Tästäpä minulle uusi kumppani… Hinnalla millä hyvänsä”, ajattelet päässäsi. Saavut hänen luokseen, tarjoat muutaman drinkin ja kun tulee oikean esittelyn aika, sanoo hän sinulle: “Aaaa! Minäpä olen kuullutkin sinusta edelliseltä kumppaniltasi, sillä hän on hyviä tuttujani. Mutta oli kiva tutustua ja oikein mukavaa illanjatkoa teille kaikille” ja poistuu tanssilattian vilskeeseen. “Siis mitä ihmettä tapahtu?! Haisenko minä?! Mitä mitä…”, käyt pääsi sisällä. Masennut ja poistut paikasta pää painuksissa kohti kotia, joka sekin muistuttaa sinua vielä edellisestä kumppanistasi, mutta ei siitä sen enempää…

Elelet jonkin aikaa yksin tai parhaassakin tapauksessa saat tyytyä vähemmän potentiaalisiin kumppaneihin, jotka eivät sinua pitkällä aikavälillä pysty tyydyttämään. Maineesi on kärsinyt ja se tulee haittaamaan toimintaa vielä pitkään. Eräänä pimenevänä iltana sinut nähtiin matkaavan kohti sumuavaa horisonttia. “Miksi en ollut avoin ja läpinäkyvä”, kuultiin sinun vaikertelevan ennen kuin hävisit yhä sakenevaan sumuun.

Draamaa oi draamaa. Sitä tämä elämä on! Kahden keskeinen kumppanuus ja sen vaikeudet. Elämää! Kuulostaako tutulta?

Yrittänyttä ei laiteta ja silleen. Onhan näitä onneksi positiivisiakin poikkeuksia olemassa. Jotkut luovat suhdetuotteestaan niin hyvän kerralla, ettei ensimmäisen pariutumisen jälkeen tarvitse koskaan lähtä uutta kumppania edes etsimään. Kaikki on niin sanotusti loksahtanut kohdalleen heti. Well done. Hatunnoston ja aploodien arvoinen suoritus!

Mutta hei, oletteko koskaan kuullut multivendor-termistä? Sellaisesta, jossa samaa suhdetuotetta rakentaa useampikin toimija. Yksi nainen ja useita miehiä. Tai päinvastoin. Yhtä avoimesti ja läpinäkyvästi, kuten mainostetaan.. eihhhhhhhh. Joku voisi jopa pessimistiksi haukkua, mutta olen vain skeptinen. Jos ei edes kaksin tahdo onnistua niin mitenkäs nyt sitten… Onneksi on kuitenkin niitä, jotka hanskaavat tämänkin!

Ja sama ilman dramatisointia…

Kuten kaikkialla, on tässäkin tilanteessa mahdollisia vaihtoehtoja monia. Tässä muutama:

1. Ongelmien kasaantuessa, asiakas alkaa aktiivisesti etsimään parempia vaihtoehtoja tuotteensa toteuttamiseksi ja lopulta löydettyään, asteittain siirtämään kehitystä uudelle organisaatiolle. Mitä suurempi riski ja panostus projektia tekevälle organisaatiolle oli, sitä todennäköisemmin se johtaa yt-neuvotteluihin ja henkilöstön tympääntymiseen. Lopulta ammattitaitoisimmat lähtevät vapaaehtoisesti uusiin kuvioihin toisiin yrityksiin ja heikoimmat joudutaan joko irtisanomaan, lomauttamaan tai he jatkaavaat taistelua vailla ammattitaitoista tukea

2. Aletaan järjestämään palavereita yhä useammin ja useammin. Tuotteen major-tason ongelmat alkavat selvitä asiakkaalle ja se saa heidät huolestumaan. Virhetietokanta luvataan aukaista asiakkaalle täydessä mittakaavassa. Todellisuudessa virhetietokanta ei olekkaan sama, kuin kehityksen käytössä oleva vaan sinne filtteroidaan vain sellaiset ongelmat, jotka nähdään tarpeelliseksi. Projektia jatketaan vähemmän onnellisissa merkeissä, kunnes seuraava pommi on valmis laukeamaan.

3. Projektia jatketaan onnettomien tähtien alla käyttäen jo kertaalleen epäonnistuneita prosesseja. Kumpikin osapuoli ajautuu omilla tahoillaan ongelmiin, joka voi kaataa joko molemmat tahot tai vain toisen. Tuote epäonnistuu, eikä siinä ollutta potentiaalia saada koskaan toteutettua ja markkinoille asti.

4. Jokin äärimmäisen kriittinen asia tulee julki, joka johtaa syvälliseen tutkiskeluun asiakkaan ja tuottavan organisaation kesken. Tässä tilanteessa voi käydä kuinka tahansa. Joko tuottava organisaatio muuttaa lopullisesti toimintatapojaan avoimempaan suuntaan ja saa sille hyväksyntää tai projekti loppuu kuin seinään, koska asiakas ei halua enää käyttää rahojaan epäonnistumisen pelossa, koska ei luota enää toiseen osapuoleen.

Unohtaen vaihtoehtojen 1 ja 3 lopputuloksen, projektia jatketaan muiden mahdollisten vaihtoehtojen takia. Projekti on nyt karahtanut karille ja tuntuvasti ja päättynyt ennalta-arvattavin tuloksin.

Yrityksen sisällä aletaan käymään vakavia kehityskeskusteluita, joissa puidaan epäonnistuneen projektin vaiheita, toimintatapoja ja lopputulosta. Yleisesti päädytään siihen lopputulokseen, että rehellisyys, luotettavuus ja läpinäkyvyys olisi todennäköisesti pelastanut asiakassuhteen tai jollei se olisi sitä tehnyt, olisi tuottava organisaatio kuitenkin pelannut kortteja avoimesti ja täten säästynyt vähintäänkin osittaiselta maineen menetykseltä.

Kehityskeskusteluiden pohjalta luodaan uusi s
trategia, jota lähdetään jalkauttamaan innokkaasti.

Uusasiakashankinnassa tärkeäksi keinoksi on huomattu referenssit, mutta edellisen projektin epäonnistuttua, sitä ei pystytä käyttämään. Alan ollessa globaali, yritysten ja niiden johtohahmojen verkostoitumisen johdosta, maine on kulkenut myyjiä nopeammin ja vaikeuttaa äärimilleen uuden projektin hankkimista, sillä usko projektin onnistumiseen kyseisen organisaation kanssa on vähissä. Megadiilejä ei enää helpolla saavuteta jos ollenkaan.

Uusien projektien hankinta on tyssännyt kuin seinään. Parhaassakin tapauksessa saadut diilit ovat pieniä tai ainakin huomattavasti tavoiteltuja pienempiä eivätkä täten tuo suurta kassavirtaa. Yrityksen maine on kärsinyt ja sillä on huomattava urakka edessään, jotta maine saadaan palautettua edes osittain ja suurten asiakkaiden luottamus herätettyä uudestaan. Organisaatiossa tunnustetaan itselleen epäonnistumisen karvas kalkki ja päivitellään syntynyttä tilannetta. Läpinäkyvyydellä olisi nämäkin sudenkuopat pystytty välttämään. Pahimmassa tapauksessa koko yritys vaipuu suuresta tekijästä unholaan joko syntyneen luonnollisen pienenemisen johdosta tai sulautuessaan suurempaan yritykseen. Peli on hävitty.

Onneksi tämä ei ole IT-alalla täysin yleinen käytäntö, sillä positiivisestikin käyttäytyviä yrityksiä löytyy. En yleistä, mutta seuraan huolestuneena.

Jos kahden yrityksen välinen toiminta voi olla näin vaikeaa, vaikeaksi se vasta käy, kun liitetään projekteihin useita toimittajia, jotka kaikki toimivat samalla periaatteella ollen “läpinäkyviä”. Jokainen voi kuvitella, minkälainen soppa syntyy kaikkien pitäessä omaa pesäänsä puhtaana ja vierittäessä vastuuta toisille.

Mitä tästä turinatuokiosta voimmekaan tulkita ja oppia. Toivottavasti ainakin sen, mitä peittely tuo tullessaan. Jos joku lukija tuntee piston sydämmessään, toivon lämpimästi toimintatapojen vaihtamista. Joidenkin uhkapeli pelataan aina työntekijöiden tulevaisuudella. Eli myynnin pitää muistaa realiteetit ja tuottavan organisaation on toimitettava aina sitä, mitä on luvattu, ilman valheita ja peittelyitä. Paraskaan laadunvarmistys ei pysty paikkaamaan virheitä, joita aikaisemmissa portaissa tehdään. Olkaa läpinäkyviä ja luotettavia toimittajia asiakkaillenne! Täten varmistatte paremman tulevaisuuden.