Arkisto: lokakuu 2009



Testaus ei taputtele selkään

30. lokakuuta, 2009 | Kirjoittaja: Antti Niittyviita

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.

Feature managerin heiniä

23. lokakuuta, 2009 | Kirjoittaja: Antti Niittyviita

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ä.

Väitän, että metriikat kuvaavat sitä suppeammin todellisuutta mitä korkeammalle tieto matkustaa. Aivan kuten lasten pelissä ”rikkinäinen puhelin”.

Usein alas ammutuissa projekteissa tekijät tietävät tuleeko tuotteesta mitään jo kauan ennen kuin ratkaisu johtoportaassa on edes tehty. Minusta tämä on vahva merkki siitä, että informaation kulku takkuilee. Kommunikaatio ei pelaa.

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ä.

Workshopin ajatuksia testauksen raportoinnista

16. lokakuuta, 2009 | Kirjoittaja: Jaakko Sakaranaho

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.

Draamaa, oi draamaa! Osa 2.

9. lokakuuta, 2009 | Kirjoittaja: Lasse Määttä

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.

Draamaa, oi draamaa! Osa 1.

2. lokakuuta, 2009 | Kirjoittaja: Lasse Määttä

Läpinäkyvyys ja luotettavuus. Aah, miten ihania kliseitä!

Kuten tiedämme, monet yritykset hehkuttavat julkisesti olevansa asiakkailleen läpinäkyviä ja luotettavia yhteistyökumppaneita. Yksinkertaistamalla asia pelkälle ihmissuhdetasolle, tarkoittaisi tämä mm. parisuhteessa sitä, ettei kumppaneiden välillä ole salaisuuksia eikä toisen silmään kus.. loroteta. Kuulostaapas mielenkiintoiselta vertauskuvalta, joten otetaanpas tämä sitten päivän epistolaksi ja jatketaanpa ajatusleikkiä tässä ihanassa humaanissa maailmassa muuttaen projektit, asiakkat, yritykset, konsultit, prosessit ja projektihenkilöstö ihmismäisen-tarinamaiseen muotoon. Draamaksi!
Let the story begin!
Aluksi skipataan kaikki itsestään selvät onnelliset ensimmäiset hetket ja lässyn lässyt. Kaikki ovat rakastuneita ja silleen. Onnensa kukkuloilla. Luodaan toiveita ja luvataan kumppanille kaikkea kivaa. Pilvilinnoja. Rakennetaan henkistä organisaatiota ja aletaan speksaamaan yhteistä tulevaisuutta. Aletaan toteuttamaan valmistuneita speksejä, jotka on niin monesti yhteisinä hetkinä katselmoitu ja hyväksytty. Esiinnytään julkisesti yhdessä ja armottomalla kiihkolla ja innolla esitellään yhteistyön ensimmäinen hedelmä. Mutta entäs sitten, kun jommalla kummalla alkaa tökkiä?
Ongelmat. Hmm… Niistähän on vaikea keskustella, eikö vain? Pääsi on täynnä pieniä projektihenkilöitä, jotka kirjaavat henkilökohtaiseen virhetietokantaan ongelmia ongelmien jälkeen. Näiden kertominen suhteen toiselle osapuolelle voi olla hankalaa riippuen virheen vakavuudesta. Minor-tason ongelmat voidaan vielä puida ruokapöydässä tai saunan lauteilla, mutta sitä vakavammat pidät toki itselläsi, ettet loukkaa toista ja pahimmassa tapauksessa petä hänen luottamustaan. Et halua kerjätä itsellesi ongelmia, vaan pyrit ratkaisemaan ne itseksesi.
Päivät, viikot ja kuukaudet kuluvat. Sisäinen projektihenkilöstösi on aktiivisesti yrittänyt kehittää, korjata ja testata suhdettasi, mutta koska suuremmat ongelmat ovat vain kasautuneet, on suhdetuotteesta tullut jo lähes läpimätä. Korjauskelvoton. Sitä itseään! Samaan aikaan kumppanisi on onnellisen tietämätön sisälläsi möyryävistä ongelmista ja on onnensa huipulla. ”Kuinka ihana kumppani minulla onkaan”, hän tuumii mielessään. ”Vain pieniä ongelmia, mutta nekin olemme helposti pystyneet ratkomaan”, hän vielä jatkaa. ”Tästä tulee menestystarina!”, sinisilmäisesti päättäen.
Aika se vain jatkaa kulkemistaan ja olet viisauksissasi alkanut kasvattamaan henkistä organisaatiota oman sisäisen projektihenkilöstön ja kumppanisi väliin. Tämä organisaatio pitää huolen kommunikoinnista ja varsinkin siitä, ettei kukaan sisäisestä projektihenkilöstöstäsi pääse lipsauttamaan mitään kriittistä ja/tai negatiivista kumppanillesi, sillä siitähän tulisi kiukkua, mökötystä ja kyyneliä. Kauheata! Organisaation ansiosta, alat olla vaitonainen ja kykenet puhumaan asioista vain, kun sinut siihen pakotetaan. Tässä vaiheessa viisaampi kumppani alkaa jo huolestua. Pintapuolisesti iloisesta ja rehdistä tapauksesta onkin paljastumassa jotain pimeää, jonne ei pääse tunkeutumaan. ”Mitä ihmettä se pimittää? Onkohan kaikki nyt kunnossa?”, hän ihmettelee.
Ja sama ilman dramatisointia…
Asiakassuhteiden luonnin jälkeen lähdetään luomaan asiakkaalle omaa tuotetta, josta luvataan tehdä vähintäänkin state-of-arttia. Molemmat osapuolet ovat ihastuneita uudesta projektista. Projektille aletaan luomaan organisaatiota, joka lähtee kehittämään tuotteelle alustavaa dokumentaatiota, vaatimuksia ja arkkitehtuuria. Lopuksi yhteisten katselmointien jälkeen hyväksytään tulevan tuotteen lopullinen muoto. Tämän jälkeen siirrytään normaliin tapaan julkisuuteen hehkuttamaan uutta yhteistyökuviota, joka tulee tuottamaan tulevaisuudessa upeita lopputuloksia.

Projektin edetessä, syntyy normaalisti virheitä, joita laadunvarmistus aina säännöllisesti etsii ja löytää. On kuitenkin monesti huolestuttavaa, ettei tämä paljon puhuttu läpinäkyvyys ulotu mainostekstiä pitemmälle. Vain pienimmät ongelmat tai ne, jotka asiakas varmasti itsekkin löytää, tullaan julkaisemaan yhteisissä palavereissa ja release noteissa. Suuremmat haudataan maton alle ja toivotaan, että ne saadaan korjattua ennen kuin kädessä on vain tikittävä aikapommi. Ei uskalleta tai haluta olla avoimia. Tietyllä tavalla ottaa oikeaoppisesti vastuuta tekemisistään.

Ajan edetessä ongelmat alkavat kerääntyä ja koska monesti tiukat ennaltasovitut aikataulut eivät anna mahdollisuutta käyttää suuria työpanoksia ongelmien ratkaisemiseen, alkaa tuotteen pohja pettää. Tässä vaiheessa olisikin hyvä pysähtyä ja asiakkaan kanssa aloittaa keskustelut, jotta havaitut ongelmat saataisiin ratkaistua ja uusien ominaisuuksien kehittämistä viallisen pohjan päälle lykättyä, kunnes ongelmat on ratkaistu. Monesti ei kuitenkaan näin tapahdu. Annetaan asiakkaan luulla, että kaikki on hyvin ja tuote etenee aikataulussaan.
Aika vain jatkaa kulkuaan ja ongelmat alkavat olla jo ilmeisiä. Asiakas on huomannut, että tuote ei tule valmistumaan aikataulussa ja siinä on ongelmia. Tuotekehitysorganisaation päälle rakennetaan täysin erillinen kommunikaatiokanava asiakkaan suuntaan, joka keskustelee ongelmista. Tätä kutsutaan filtteriksi. Kehittäjät ja laadunvarmistus pudotetaan pois keskustelufoorumeista, sillä totuus tuotteen todellisesta tilasta halutaan pitää kaunisteltuna, jottei esimerkiksi koko projektia ammuttaisi tässä vaiheessa alas ja täten menetettäisi suurta asiakasta suurine rahasalkkuineen. Asiakasta pidetään jännityksessä, sillä myönnetään ongelmien olemassa olo, muttei läheskään siinä laajuudessa, missä ne oikeasti on.
Kuulostaako yhtään tutulta? Pystytkö samaistumaan? Löytyykö omakohtaisia kokemuksia? Tarina jatkuu. Lopputulokset ja ratkaisut, omissa todellisissa muodoissaan, nähdään ensi viikolla. Kuka voittaa, kuka häviää. Vai oliko tässäkään tarinassa voittajia alkuunkaan?