Avainsanat: ‘liiketoiminta’

Illuusio ainutlaatuisuudesta

maanantai, 19 joulukuuta, 2011 | Kirjoittaja: Antti Niittyviita

Keskustelen paljon tuotekehitystä ammatikseen tekevien ihmisten kanssa. Jotkut tekevät monimutkaisia suunnittelujärjestelmiä. Toiset taas hankalia verkkosovelluksia. Kolmannessa yrityksessä työskennellään tuotannonohjausjärjestelmien kanssa. Kaikki kuulostavat niin kovin erilaisilta. Minusta on ollut kiinnostavinta huomata, että näissä keskusteluissa on poikkeuksetta yksi yhteinen tekijä. Kaikki nimittäin kertovat kuorossa:

Meidän tuotteemme ja toimialamme on niin ainutlaatuinen, että uusien kavereiden sisäänajo vie vuosia

Höpö höpö, sanon minä. Teidän toimialanne ja bisneksenne varmaankin on ainutlaatuista, mutta teidän tuotteenne on softa muiden joukossa. Siellä pyörii aina samat ohjelmointikielet, rajapinnat, serverit ja clientit kuin kaikilla muillakin. Softakehityksenne tavat ovat ihan samanlaiset kuin sadassa muussakin softaa tekevässä firmassa. Samanlaiset bugit toistuvat järjestelmästä toiseen oli kysymys kuluttaja-asiakkaiden web-palvelusta tai teollisuusyrityksen valvontasoftasta.

Toimialaosaaminen on toki kaikilla aloilla tarpeellista, mutta tiedättekö mitä ne ihmiset ihan jokaisessa firmassa ovat ammatiltaan? He kuuluvat ohjelmistojen kehitystiimeihin. He ovat ihan tavallisia koodaajia, testaajia, speksaajia ja managereita. Heillä kaikilla on hyvin samankaltainen tausta. Ja loppupeleissä he osaavat hommansa perhanan hyvin.

Toimivaa koodia syntyy, bugeja löytyy ja designikaan ei ole mikään ongelma. Toimialan ymmärtäminen karttuu kyllä vuosien varrella, mutta ihan yhtä kovaa kyytiä tekijät urautuvat ja kuppikuntaistuvat. Halutaan kiihkeästi uskoa omaan ainutlaatuisuuteen. Lopulta uusia ideoita syntyy vähemmän ja hommia paiskitaan jääräpäisesti samalla tavalla kuin niitä on “meillä aina tehty”.

Väitän, että toimialasi ainutlaatuisuus on illuusio mikä syntyy, kun istut kavereinesi samalla hiekkalaatikolla liian pitkään. Välillä kannattaa käydä tuulettumassa ulkona. Katsoa avoimin mielin, miten muut tekevät sitä ihan samaa työtä kuin sinäkin.

P.S. Onko sinun tuotteesi ainutlaatuinen? Eikö sitä voi testata ilman vuosikausien kokemusta? Ilmoitta asiasta minulle, niin lähetän täysin ummikon testaajan paikalle. Väitän, että kahdessa viikossa kaverista tulee hyödyllinen testaustiimin jäsen. Jos näin ei käy, saat rahasi takaisin ja tarjoan nöyränä poikana kostean illallisen.

Share

Ei mikään turha kuluerä

maanantai, 28 maaliskuuta, 2011 | Kirjoittaja: Antti Niittyviita

Oletko koskaan reklamoinut saamastasi tuotteesta tai palvelusta? Oletko koskaan vienyt tuotetta takuuhuoltoon? Tältä homma näyttää tiskin toiselta puolelta tarkasteltuna.

  1. Asiakaspalvelu kuuntelee valituksesi ja yrittää auttaa: 10 min
  2. Tekninen asiakaspalvelu yrittää korjata vian kanssasi: 10 min
  3. Lopulta tekninen asiakaspalvelu kirjaa virheraportin: 10 min
  4. Tukivastaava tutkii raportin, testaa ja lähettää sen tuotekehitystiimille: 1 tunti
  5. Tuotekehitystiimi tutkii, korjaa ja testaa: 10 htp (70 tuntia)
  6. Korjaus jaellaan nykyisille asiakkaille, mikäli mahdollista 2 htp (15 tuntia)
  7. Lähetetään palaute valituksen tehneelle asiakkaalle läpi koko ketjun: yht 30 min

Kun yksi asiakas valittaa, niin silloin ei vielä lähdetä tekemään korjaavia töitä. Kun 100 asiakasta valittaa on vian syykin varmasti ilmeinen. Koko valitusrumba vie yhden valituksen kohdalta noin 2 tuntia. Kun valittajia on 100, se tekee 200 tuntia. Korjaaminen ja korjauksen jakelu syö vielä 85 tuntia.

Siis yhteensä 285 tuntia! Työpäivissä se tekee 38. Hyvinkin maltillisella 350 euron päiväkustannuksella koko show syö rahaa 13.300 €! Eikä siihen ole vielä laskettu virheellisestä tuotteesta aiheutunutta imagohaittaa tai mielipahaa asiakaskunnassa. Lisäksi korjauksen jakelu voi todellisuudessa viedä jopa 100 kertaa enemmän aikaa, mikäli se vaatii tuotteen takaisin kutsumisen.

Testauksen tehtävä on eliminoida mahdollisiman tehokkaasti nämä kustannukset jo tuotekehityksen aikana, ennen kuin tuote on käynyt yhdelläkään asiakkaalla.

On siis täysin turha selitellä, miksi testaus on vain turha kuluerä.

Share

Näkymätön käsi ohjaa meitä

tiistai, 18 tammikuuta, 2011 | Kirjoittaja: Antti Niittyviita

Yksilön oma etu toimii yhteisön edun hyväksi. Väitteen esitti nykyaikaisen taloustieteen isäksikin tituleerattu Adam Smith jo 1700-luvulla. Samankaltaisilla linjoilla oli myös meidän Chydenius aikanaan.

Mainitun periaatteen Smith esitti vertauskuvalla “näkymätön käsi“. Homman nimi on siinä että järkevät, omaa etuaan ajavat ihmiset hyödyttävät kaikkia pidemmällä aikavälillä. Periaatteen mukaan homma toimii silloin kun ihmiset eivät saa pakottaa toisia vaan voivat hyötyä näistä vain tarjoamalla vastapalveluksia (*). Näkymätön käsi on siis vapaassa taloudessa ihmisten toimintaa ohjaava voima. Päätökset ja tekeminen hyödyttävät kaikkia osapuolia.

Softakehityksessä sama periaate näkyy nyt entistä selvemmin. Parhaisiin tuloksiin pääsevät organisaatiot ovat yleensä rakenteeltaan hyvin matalia. Niissä korostuu työntekemisen malli, jossa tehdyt ratkaisut ovat kaikille hyväksi. Esimerkiksi työkaluvalinnat eivät synny managementtipäätöksillä vaan itse tekijöiden tarpeista. Managementti hyötyy kun tulosta syntyy nopeammin, työntekijä hyötyy kun työkaluksi valitaan hänelle helpoin ratkaisu. Tällaisissa organisaatioissa johtajuutta ei usein anneta vaan se on myös ansaittava.

Online-pelit ovat mielestäni mainio esimerkki tästä. World of Warcraftissa kaikki pelaajat aloittavat yksin, mutta suurimmat tavoitteet voidaan saavuttaa ainoastaan toimivina tiimeinä. WoWissa kykenevimmät yksilöt valitaan johtajiksi tarveperusteisesti. Johtajuus on kestävää ainoastaa siinä tapauksessa että se hyödyttää tiimin kaikkia jäseniä.

Muinoin johtajat valikoivat seuraajiaan. Uhkaajat pudotettiin pelistä teloittamalla tai karkottamalla maasta. Siis pakottamisella ja pelolla. Nykyisin ihmiset valitsevat ketä haluavat seurata. Nämä valinnat palvelevat aina jollakin tavalla omaa etua. Käytännöllisin esimerkki on Twitter, jossa Lady Gagaa seuraa lähes 8 miljoonaa ihmistä. Barack Obamalla seuraajia on yli 6 miljoonaa ja minulla alle 10. Vielä on siis vähän tekemistä :)

No. Homman pointti lienee kuitenkin selvä. Twitterissä yksilöt hyötyvät seuraamisesta ainakin sosiaalisesti, Twitter.com hyötyy valtavista käyttäjämääristä taloudellisesti, Lady Gaga ja Barack Obama taas hyötyvät hommasta vähintäänkin PR-mielessä.

Hyvä asiakas. Tavoittele avoimesti omaa etuasi. Niin minäkin teen. Se on lopulta kaikkien etu!

* Vastapalvelukset voivat olla oikeasti palvelua, hyödykkeitä tai vaikkapa rahaa.

Share

Nyt on poonukset pelissä

keskiviikko, 12 tammikuuta, 2011 | Kirjoittaja: Antti Niittyviita

Kun vuoden vaihde painoi hetki sitten päälle, niin testaajan työkuorma kasvoi aivan yllättäen. Softakehityksestä hävisi järki totaalisesti. Testaajasta tuli syyllinen, kun tulosta ei syntynyt deadlineen mennessä. Mitä siis tapahtui?

Homman nimi on siinä, että testausta käytetään tuotekehityksen tukena. Tietysti se on hieno ja toimiva ajatus, paitsi jouluna.

  1. Kysymys testaajalle: Miksi meidän regressiotestissä on vieläkin niin paljon faileja?
  2. Ohjeistus testipäällikkölle: Kannustahan vähän sitä testitiimiä, että saadaan vihreä palkki nousemaan!
  3. Case katselmoinnin agenda: Miten testitapauksia pitäisi korjata, että pass rateksi saataisiin 98%?
  4. Toimittaja testaajalle: Eeeei tuo ole defekti, pistä case vihreeksi vaan!
  5. Pitääkö palkata lisää testaajia?

Testausta käytetään häikäilemättömästi hyväksi nimenomaan silloin kun on bonukset pelissä. Silloin tarvitaan hopeareunustettua totuutta että tavoitteet saavutetaan. Helpoimmin se käy, kun testataan softa kuntoon. Näin testaajat painavat täysin turhaa työtä koko loppuvuoden. Devaajat ovat tyytyväisiä, kun kaikki näyttää hyvältä. Managementti vain hymyilee ja rahaa kuluu vielä lisäksi uskomaton määrä perusteettomiin bonuksiin.

Minun on pakko vastata edellisiin kohtiin:

  1. Siksi kun softa on vieläkin ihan romuna
  2. Just joo! Testaamallahan ne virheet korjaantuu
  3. Heitän pallon takaisin: Miten softaa pitäisi korjata, että pass rateksi saadaan 98%?
  4. Kyllä se on defekti, jos loppukäyttäjää ***uttaa armottomasti
  5. Ei varmaankaan. Näyttää siltä että nyt tehdään vääriä asioita!

Se on oikeasti kallis tikki, jos et uskalla ottaa kantaa näihin jouluhullutuksiin tänäkään vuonna!


Share

Kenen etu laadunvarmistus oikeasti on?

tiistai, 17 elokuuta, 2010 | Kirjoittaja: Antti Niittyviita

Ohjelmistokehityksen alihnakinnassa ja softaratkaisuiden ostamisessa on vakiintunut käytäntö ostaa tuotekehitys ja testaus samalta palveluntarjoajalta. Näin saatetaan tehdä koska tuntuu työläältä pyörittää kahta toimittajaa yhdessä projektissa. Sehän tuplaa myös projektinhallinnan työmäärän. Toisaalta saatetaan nähdä asia myös tuotekehityksen etuna. Se on ketterämpää kun kehitys ja testaus tulevat saman katon alta.

Usein näin järkeillessä kuitenkin unohtuu karu totuus, joka avautuu taannoisessa Dilbert-stripissä hauskalla tavalla:

Dilbert.com

Olemme aikaisemminkin kysyneet että kenen etua testaus palvelee silloin kun toimittaja on myös tuotteen testaaja?

Ongelmakenttä ei kuitenkaan ole yksiselitteinen. Tuoreessa Kauppalehden jutussa käsitellään Solteqin toteuttaman kassajärjestelmäprojektin epäonnistumista. Tässä projektissa testaus laiminlyötiin erittäin vakavalla tavalla tilausketjun jokaisessa vaiheessa:

Toimittaja on syyllinen siksi että se ei suorittanut järjestelmän testausta tuotantoympäristössä. Toisaalta tilaaja on syyllinen siksi että se ei huolehtinut laadunvarmistuksen toteuttamisesta etujensa mukaisesti. Kaiken lisäksi tilaaja teki ensimmäisen inventaarion vasta puoli vuotta kassajärjestelmän päivityksen jälkeen.

Kokenut testausasiantuntija olisi muutaman päivän työllä laatinut turvallisen suunnitelman järjestelmän tuotantoon siirtämisestä. Jos vain tilaaja tai toimittaja olisi huomannut laadunvarmistuksen asiantuntijalta tällaista kysyä. Kaikki olisivat säästäneet pitkän pennin.

Aikaisemmin väitimme että ohjelmistohankkeiden tilaajan on syytä hoitaa itselleen laatupoliisi valvomaan hänen etujaan. Solteqin tapauksessa oikeus kuitenkin katsoi että täysimääräisessä korvausvastuussa onkin järjestelmähankkeen toimittaja. Oikeus katsoi toimittaja olevan vastuussa projektin kauppasumman lisäksi myös tilaajan arvioiduista tappioista. Softavirheen kokonaiskustannukseksi Solteqille tuli 8000 euron sijasta huimat 560.000 euroa.

Solteqilta oli rohkea veto tulla tämän tapauksen kanssa julkisuuteen. Uskon että he ovat läksynsä oppineet ja softatoimitusten laatu on jatkossa täysin eri tasolla. Suosittelen Solteqia.

Oikeuden päätöksestä viisastuneena myös Ohjelmistotestaus.fi korjaa väittämää:

Tilaaja ja toimittaja: Varmistakaa aina yhdessä että laadunvarmistus hoituu ammattimaisesti ja objektiivisesti. Se jos mikä, on kaikkien etu!

Share