Tag: Suomi

Jos Apple olisi tietokonevalmistaja muiden joukossa, se sanoisi: “Me teemme hienoja tietokoneita. Hoidamme homman suunnittelemalla kauniita laitteita ja virtaviivaisia käyttöliittymiä. Haluatko ostaa sellaisen?”

Nääh. Tylsää!

Apple ei kuitenkaan ole mikä tahansa tietokonevalmistaja. Applella on käytössään täsmälleen samat resurssit, sama maailmantalous ja markkinat kuin muillakin. Siitä huolimatta sen kassa pursuaa miljardeista dollareista ja tulos on tähtitieteellisen hyvä vuodesta toiseen.. Applen toiminta eroaa muista perustavalla tavalla.

Apple aloittaa näin: “Me uskomme, että vakiintuneet käytännöt tulee haastaa. Me uskomme, että nykyaikaisen ihmisen kannattaa ajatella toisin. Hommat me hoidamme suunnittelemalla kauniita laitteita ja virtaviivaisia käyttöliittymiä. Me vain satumme tekemään hienoja tietokoneita. Haluatko ostaa sellaisen?”

Applen toiminta, ajatusmaailma ja viestintä on täydellinen vastakohta kaikille muille. Sekä yrityksille, että ihmisille.

Jokainen ihminen maan päällä tietää, mitä hän tekee. Suurin osa heistä tietää myös sen, miten homma hoidetaan. Hämmästyttävän harva kuitenkaan tietää vastauksen kysymykseen miksi. Syyn siihen, miksi aamulla nousee sängystä. Tarkoituksen.

Valtaosa ihmisistä ja yrityksistä ajattelee, toimii ja viestii järjestyksessä:

1. Mitä?
2. Miten?
3. Miksi?

Apple ja muut menestyjät hoitavat homman täsmälleen päinvastoin.

Usein valitellaan, että testaus ei edelleenkään ole kovin arvostettu ala. Jaa miksiköhän?

Minä nousen aamulla sängystä, koska palan halusta saada aikaan huippulaatuisia tuotteita, joiden loppukäyttäjät voivat nauttia. Lisäksi lupaan auttaa ohjelmistokehityksestä kannattavampaa. Hommat hoidan metsästämällä bugit tutkivan testauksen menetelmin jo kehityksen aikana. Testaus on siis työtäni.

Meillä Proven toimistolla on aina ollut uskomaton kahvikuppien vuori keittiön pöydällä. Ne siivottiin tiskikoneeseen joka perjantai ja kirottiin isoon ääneen siinä samalla.

Miksei niitä voisi laittaa vaikka heti käytön jälkeen suoraan sinne, mihin aurinko ei paista?!

Sitten tuli Jaakko. Jaakolla on kummallinen taipumus. Hän tekee töitä aina vähän enemmän kuin on pakko. Ja tulokset puhuvat puolestaan. Mies ratkaisi ongelmamme samoin tein ja hyvin yksinkertaisella uhkauksella.

Enää yksikään kahvikuppi ei pyöri pöydillä. Nyt on vain alkanut jännittää, sillä Jaakko pakkaa Joulun jälkeen laukkunsa ja lentää Helsinkiin. Hän lähtee vahvistamaan Proven tiimiä pääkaupunkiseudulle koko kevääksi. Hyppivätkö hiiret nyt pöydillä, kun kissa ei ole paikalla?!

Tuskin, sillä tänä vuonna olemme oppineet taas jotain tärkeää. Ne pätevät testauksen lisäksi kaikille muillekin aloille.

Töitä kannattaa tehdä aina vähän enemmän kuin on pakko. Kun luottamus on saavutettu, niin kukaan ei enää hengitä niskaan. Tulostakin syntyy enemmän ja hymyilyttää aamusta iltaan.

Proven ja blogin koko tiimi toivottaa kaikille ihan huippua Joulua!

Kiireen taakse on helppoa piiloutua. Erityisesti silloin, kun kiire on todellista. Kiire on aivan ihastuttava tekosyy lykätä jotain epämiellyttävää tuonnemmaksi. Kukapa oikeasti haluaisi tietää minkälaisessa kunnossa softa on, jos se aiheuttaa vielä lisätöitä?

Nyt ei kyllä miteenkään ehdi. On aivan liian kiire. Testataan sitten vaikka maaliskuussa.

Ohjelmistohankkeissa kiire voi johtua monesta tekijästä. Hirveän usein projektiriskit kiteytyvät joko resurssi- tai aikatauluongelmiin.

• Tuntuu, että deadline puskee päälle ja palopesäkkeitä on vielä liikaa
• Tuntuu, että kehitystahti on repivää ja kiireistä
• Tuntuu, että projektissa onkin liian vähän miehitystä
• Tuntuu, että myynti on mennyt lupaamaan mahdottomia

Projektit alkavat usein mukavasti ja rauhallisesti. Sitten tahti alkaa kiristyä ja lopulta kiire ottaa niskalenkin. Viimeiset projektiviikot painetaan kebabin, kahvin ja univelan voimin. Se jos mikä on terveellistä. Lisäksi kiireestä on kivaa kerskailla kavereille.

Tällaiset ongelmat ovat tyypillisimpiä projekteissa, joissa testaus on hoidettu oman toimen ohessa. Testausta tehdään silloin kun ehditään ja joskus sen voi jättää myös hoitamatta. Kiire on niin ihana tekosyy.

Itse asiassa kiireen takia laiminlyöty testaus aiheuttaa juuri niitä ongelmia, jotka kiirettä pahentavat. Palopesäkkeiden hallinta, hätäpäivitykset ja takuukorjaukset pistävät deadlinet paukkumaan. Sitten resurssitkin loppuvat kesken.

Joskus on niin kiire soutaessa, että ei ehdi laittaa perämoottoria käyntiin. Silloin on syytä kääriä hihat ja poistua puolustusasemista. Lopeta kyyristely kiireen takana!

Kävin vasta pitkän keskustelun määrittelyn hankaluudesta. Eräässä yrityksessä projektin määrittelyvaihe aiheutti hirveästi vaivaa, sillä se tuntui kestävän joka kerta valtavan pitkään. Pahimmassa tapauksena jopa vuosia. Lopputuloksena kehitettävän ohjelmiston piirteistä oli sivukaupalla etukäteen spekuloitua aineistoa porkattavaksi.

Kukaan ei vain jaksanut lukea määrittelyjä jälkikäteen. Lopulta edes toteutus ei vastannut niitä. Tilanne on oikeastaan ihan tyypillinen isoissa ohjelmistoprojekteissa tai tapoihinsa juurtuneissa organisaatioissa.

Toimenpide-esitys ongelmien korjaamiseksi oli helppo.

Päättäkää ensin mikä on dokumentin maksimipituus. Sopikaa yhdessä, että jokainen dokumentti on korkeintaan kahden A4:sen mittainen. Sitten keskittykää kiteyttämään.

Pöydän toisella puolella tuli hiljaista. “Voiko muka niinkin tehdä?!”. Mielestäni voi. Ja pitääkin.

Minä tuotan helposti sivutolkulla jaarittelevaa ja joutavaa tekstiä. Jos siis tuntuu edes hetken samalta, niin suosittelen palaamaan Mark Twainin sanoihin.

Pyydän anteeksi, sillä minulla ei ollut aikaa kirjoittaa lyhyesti.

Tunnustan. Olen joskus aika laiska kaveri. Mielipiteeni kuvastavat sitä helposti:

1. Imurointi on perhanan tylsää hommaa. Samat neliöt viikosta toiseen.
2. Tiskaaminen on tukalaa. Pesuaine kuivattaa herkät insinöörin sormet.
3. Lumitöissä tulee hiki ja saa raitista ilmaa aivan liikaa. Ei sovi nörtille.
4. Laskujen maksaminen ahdistaa aina, vaikka näyttöpäättellä tehdäänkin.

Kun homma käy tylsäksi, niin luovuus puhkeaa kukkaan. Yhtäkkiä alan työskentelemään ongelmani ratkaisemiseksi tarmokkaasti. Hankin robotti-imurin, joka hoitaa noin 90% tylsyydestä. Tiskikoneeseen investointi helpottaa työkuormaa 85%. Lumitöihin lainaan naapurin lumilingon, jos homma käy tosi hikiseksi. Laskujen maksusta 80% hoituu automaattisesti verkkopankissa.

Automaatio todella helpottaa elämää. Käytän työkaluja juuri niinhin tehtäviin, joita ei huvita itse tehdä tai jotka haluan saada tehtyä nopeammin. Sellaisiin tehtäviin, joiden tekemisestä käsin ei ole minulle tai kotitaloudelle erityistä lisähyötyä. Sama oppi pätee ohjelmistokehitykseen ja -testaukseen.

• Älä automatisoi, jos käsityö tuottaa uusia tuloksia ja tuntuu mielekkäältä.
• Automatisoi, jos käsityö on supertylsää ja toistuvaa.

Automaation sudenkuoppa tulee yleensä siinä, että joku käsityöstä vieraantunut tekee päätökset yrityksen tai projektin suuntaviivoista. Silloin tavoitteeksi asettuukin toimivan lopputuloksen sijasta toimiva automaatio. Lopulta ihmiset työskentelevät väärän lopputuloksen eteen.

Ihmisillä on aina taipumus löytää tapoja tehdä vähemmän töitä. Luota siis luontaiseen laiskuuteen. Anna tiimillesi vapaat kädet valita välineet, niin automaatio löytää kyllä tiensä teillekin.

Katselin viikonloppuna vanhoja Kummeleita. Musacornerissa vieraina olivat progemuusikot Jussi Pattitussi ja Kikka Korea. He eivät tee lainkaan virheitä. Elämässäkään.

Ilmeisesti ammatistani johtuen ajatukset joutuivat sivuraiteille ja Kummelielämys oli pilalla. Keskustelen paljon ohjelmistokehittäjien kanssa ja toisinaan törmään muusikkoduon ajatusmalliin ihan oikeasti. Testausta ei tarvita, sillä tavoitteena on tehdä riittävän virheetöntä jälkeä jo koodatessa. Eli leipoa laatu sisään jo alkumetreillä.

Minusta laadun tavoittelu on aina hyvä idea. Usein vain unohtuu, että laatu on aina ihmisistä lähtöisin ja laadukkaiden lopputulosten tuottamiseen ihminen tarvitsee aina oppimisen. Täytyy oppia jo tehdyistä virheistä ja täytyy oppia välttämään uusia virheitä.

Vasta yksi jatkuvan oppimisen seurauksista on, että koodaaja tekee vähemmän virheitä.

Mielestäni bugittoman koodin tuottaminen on kuitenkin utopia. Lähelle voi toki päästä, jos pystyy investoimaan jumalaisiin koodaajiin, joilla on eliniän verran kokemusta juuri tästä kehitysympäristöstä, työn alla olevasta tuotteesta ja tuotteen liiketoiminta-alueesta. Käytännössä siis ihmisiä, jotka ovat jo oppineet kaiken, mitä opittavissa on. Sellainen investointi vain tulee helposti hirveän kalliiksi.

Mikäli käsissä sattuu olemaan sopivasti rahaa ja oikeita ihmisiä, niin laadun leipominen tuotekehitykseen voi onnistua. Täytyy vain osata vastata kysymykseen “Miten?”. Miten tuotekehitystiimin oppimiskäyrästä saadaan jyrkästi nouseva? Vastaus on itse asiassa melko yksinkertainen.

Ainoa tapa nopeaan oppimiseen on nopea palaute.

Todellisuudessa suurin ongelma matkalla kohti virheettömämpää maailmaa on ego. Vaatii nimittäin ihan älyttömästi pokkaa myöntää: Bugien päätymistä lopputuloksiin ei pysty mitenkään välttämään, jos rahaa ja aikaa on rajallisesti.

Kun tuon tosiasian on pystynyt kohtaamaan, niin loppumatka onkin helppo. Tarvitsee vain löytää sopivimmat välineet ja menetelmät nopean palautteen toteuttamiselle. Muusikkoduon tapauksessa suoritukset katsottiin videolta hidastettuna ja otettiin opiksi.

Ohjelmistokehityksessä voi hyödyntää esimerkiksi koodin katselmointi- ja tarkastusmenetelmiä, yksikkötestausta sekä jatkuvaa bugien metsästystä välittömästi tuotekehityksen tukena. Äkkiä näissä kaikissa palautemekanismeissa onkin kysymys testauksesta.

Tulosta syntyy, kun hyväksyt tosiasiat: Tee rohkeasti virheitä, huolehdi niiden nappaamisesta ajoissa ja varmista niistä oppiminen.

We all have been pondering about the future of Kimi Räikkönen. The discussion has been in the spotlight of sports channels as well as many home studios, like mine. As an eager fan I had been staring relentlessly at the countdown on WhatWillKimiDoNext.com -site.

The countdown reached zero at 12:00 yesterday. My heart was beating fiercely when I clicked the link that appeared. My curiosity was overwhelming. What will Kimi do next?!

The anticlimax was stunning. The link could not be opened. The target site was down!

Later on I found out that there was a clothing and design company Makia from Finland that was behind it all. They had build an impressive marketing campaing around a new line of clothing with Kimi -brand. It had a potential of being an impressive success story in marketing, but something went wrong.

Makia’s site looks really good and it probably has managed the visitor flow pretty well over the last years. But what really happens if the visitor count multiplies for example by 100 in an instant? What happens when years of work in marketing hits the sweet spot around the world?

Great deal of all energy, time and money invested simply vanishes. At the peak moment, the brand should have been bathing in the golden spotlight, but now it was all the deepest darkness instead!

Part of the problem can be explained by the mindset Makia has in business. They summarize the motto like this:

To me its not a shame to learn from the mistakes of others as well! I wager, it would not have bothered the marketing director of Makia either.

While executing a marketing campaing, one should always take all “what if” -scenarios into account. At Red Bull they most definitely had considered: “What if Felix Baumgartners parachute does not open after all?”

What if your campaing really succeeds? Have you tested that your web site really can perform under a heavy load?

Kimi Räikkösen tulevaisuutta on pohdittu maailman urheilutoimituksissa ja kotisohvilla kovasti. Kiihkeänä formulafanina myös minä olin tuijottanut viikkokaupalla laskuria ja lähtölaskentaa osoitteessa WhatWillKimiDoNext.com.

Odotus päättyi eilen kello 12:00. Sydän pamppaillen tuijotin laskurin pysähtymistä nollan kohdalle ja klikkasin alle ilmestynyttä linkkiä. Uteliaisuus tuntui sietämättömältä. Mitähän Kimi tekee seuraavaksi?

Antikliimaksi oli massiivinen. Linkki ei auennut. Kohdesivusto oli mennyt nurin käytännössä välittömästi kello 12 jälkeen.

Myöhemmin selvisi, että kyseessä oli maineikas suomalainen muotialan yritys Makia ja sen hurja markkinointikamppanja. Makia oli rakentanut uuden malliston yhteistyössä Kimin kanssa ja saanut maailman urheilumediat seuraamaan silmä tarkkana kamppanjan toteutumista! Markkinoinnin kannalta tempaus oli verraton. Oikea menestystarina, sanoisin. Mutta jokin meni vikaan.

Makian verkkosivut ovat varsin tyylikkäät ja ovat varmasti kestäneet tähänkin asti käyttäjävirran vaihtelua hyvin. Mutta mitä tapahtuu, jos käyttäjämäärä 100-kertaistuu hetkessä? Mitä tapahtuu, kun markkinointi vihdoin vuosien uurastamisen ja panostusten jälkeen osuu kultasuoneen?

Leijonan osa sijoitetusta energiasta, ajasta ja rahasta valuu hukkaan. Huippuhetkellä brändin olisi pitänyt paistatella parrasvaloissa, mutta tilalla onkin pimeys.

Osan ongelmista selittää toki Makian ajatusmalli nopeasta oppimisesta. Makian sivuilla summataan motto näin:

Mielestäni ei ole väärin ottaa opiksi myös muiden tekemistä virheistä. Se tuskin olisi haitannut Makian markkinointijohtajaakaan hirveästi.

Markkinointikampanjan toteutuksessa on aina syytä miettiä kaikki “entä jos” -skenaariot. Red Bullilla oli varmasti mietittynä skenaario “Entä, jos Felix Baumgartnerin laskuvarjo ei aukeakaan?“.

Entä, jos sinun kampanjasi oikeasti onnistuukin? Oletko jo testannut, että verkkosivusi varmasti kestää kuormituksen?

Me Provella päätimme tehdä törkeän tarjouksen! Rakennamme 5-päisen testauksen unelmajoukkueen ja tarjoamme 6kk työnäytteen ihan nahkoineen.

Viimeistään tässä vaiheessa yrityksen johtoryhmä ja hallitus hakkaavat toimitusjohtajan yhdessä takapihalla, sillä tämä avaus vetää näppärästi koko porukan samaan suohon.

Noniin. Sitten itse asiaan. Tiimi tulee sinun luoksesi ja työskentelee sinun välineilläsi. Sijoituspaikka on pääkaupunkiseutu. Tiimin kokoonpano tulee olemaan seuraava:

• 1 virkaiältään vanhempi testaaja johtajaksi (6v+)
• 4 virkaiältään nuorempaa testaajaa (1-2v)

Ja ennen kuin kysytte: Kaikki ovat suomalaisia, supliikkeja ja puhuvat sujuvasti myös englantia! Tässä ei siis nyt ole sitä paljon puhuttua koiraa haudattuna.

Kysymys on ihan törkeästi vain PR-tempusta, markkinoinnista ja oman edun tavoittelusta.

6kk kokonaishinta tälle iskuryhmälle on 88.000€ ja se laskutetaan kuukausittain 6:ssa yhtäsuuressa erässä, kukin 14 päivän laskutusajalla. Mikäli palkkaisit porukan ihan itse, niin hinnaksi tulisi helposti yli 130.000€. Tämä keikka menee helposti ihan höpöksi kannattavan liiketoiminnan näkökulmasta viimeistään sitten, kun järjestän jengille kaiken hyvän päälle 3 koulutuspäivää kuukaudessa.

Tiimi voi hoitaa yhden ison projektin tai useita pieniäkin. Koko porukka on käytettävissä 6kk juuri niihin testaustöihin, mihin parhaaksi näet. Ja sokerina pohjalla annan vinkin: jos olet riittävän törkeä kaveri, niin ostat tämän tiimin palvelukset omaan firmaasi ja myyt vähintään tuplahinnalla eteenpäin 😉

Lupaan rakentaa tämän tiimin syksyn aikana yhdelle suomessa toimivalle yritykselle, joka tarpeesta minulle henkilökohtaisesti ilmoittaa. Tarpeesta voi ilmoittaa suoraan sähköpostiini etunimi@prove.fi. Viestiin kannattaa kirjoittaa selvästi:

1. Yrityksen nimi ja tiimin toimipaikka
2. Lyhyt kuvaus projekteista, joissa testausta tarvitset
3. Ytimekäs tiivistys tuotekehityksen keskeisimmästä haasteesta

Valitsen sopivan yrityksen 12.10. kaikkien ilmoittautuneiden joukosta.

Viimeviikolla tutustuimme projektiin, joka oli kuukauden myöhässä määräajasta. Koska raha ajaa yritysten toimintaa ja testauksen tulee aina olla investointi päätimme selvittää mistä oli kysymys: Haastattelimme projektiryhmää.

Tuotekehityksen sykli yrityksessä oli kokonaisuudessaan 3 kuukautta ja testaus painottui syklin loppuun. Haastattelun jälkeen saatoimme todeta, että syklin loppusuoralla löydettyjen bugien määrä oli, kuten aina, yllättänyt tuotekehityksen housut kintuissa. Bugien määrä ei kuitenkaan ollut suurin haaste. Ongelmien korjaaminen vain vei aina hämmentävän paljon aikaa. Mutta miksi niin kävi?

Ajatellaanpa tilannetta, kun Kauno Koodaaja rakentaa uuden ominaisuuden. Koodirivejä tulee paukuteltua helposti satoja. Kaunon elo-syyskuussa tuottama koodi päätyy testausvaiheeseen lokakuussa ja bugiraportteja alkaa tipahdella. Korjaustoimet voivat alkaa, mutta mitäpä luulette: Muistaako Kauno vielä mitä muutoksia koodiin tuli elokuussa tehtyä?

Onko ollenkaan ihme, että vanhojen koodirivien kaivelu vie paljon aikaa?

Totesimme, että sama ongelma vaivasi lähes systemaattisesti projekteja, joiden tuotekehityssyklit olivat pitkiä ja testaus painottui loppusuoralle. Ensin tuli koodauksen monologi, sitten testauksen vuoro. Tuotekehitys oli ja pysyi tahmeana. Ratkaisuvaihtoehtoja ongelmaan keksimme kaksi:

1. Nopeutetaan palautesykliä pakottamalla kehitys ja testaus vuoropuheluun
2. Budjetoidaan aina projektille pitkästi korjausaikaa ja toivotaan parasta

Ei varmaan tarvitse olla hirmuinen ruudinkeksijä, että arvaa kumman vaihtoehdon tuotekehityksen johto valitsi.

Tuotekehitys on aina tiimipeliä. Laatu on myös aikatauluissa pysymistä. Vain nopea dialogi testauksen ja kehityksen kesken voi tuottaa nopeita tuloksia.