Illuusio ainutlaatuisuudesta
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.
Jos oppimiskaari on pitkä (testaajalle), silloin ongelma yleensä ei ole muu kuin järjestelmäarkkitehtuurin. Ja silloin pitäisi miettiä, miksi moinen sekasotku on yleensäkään tehty. Silloin kun erilaisia viestintäprokollia on puolitusinaa, ollaan ajettu metsään ja pitkalle. Ainutlaatuisuuden sijaan tulee vastaan vain ainutlaatuisen huono arkkitehtuuri. 😉
Kaksi lisäongelmaa: Jos tuote ja tomiialan vie vuosien oppimisen, miten järjestelmän ostajilla on varaa hankkia moinen? Pitäisiköhän asialle tehdä jotain ja yksinkertaistaa käytettävyyttä. Ja oikeastaan pohtia uudestaan ala, jolla toimitaan. Kuulostaa siltä, että toimialassa on tehokkuusongelma.
No nyt Teemu veti kommenttisi hiljaiseksi ja nöyräksikin.
Puhut asiaa. Pohdinnan paikkasi osuvat naulan kantaan. Minulla ei ole muuta lisättävää!
Vastaan kuitenkin kysymykseesi: Minulla ei olisi varaa hankkia moista järjestelmää 🙂
Oltiin tosiaan Antin kanssa kupposella taannoin Boltonin koulutuksen yhteydessä ja silloin otin puheeksi oman yritysideani. Hieno työkalu pilvessä ja siihen päälle kaikki kilkkeet, joilla manuaalinen ja automaatiotestaus saataisiin harmonisesti niputettua. Kävi sitten ilmi, että uniikki ideani olikin jo Antin porukassa kehitteillä. Uniikkia…
Liikun vissiin eri piireissä kun en ole kuullut tätä väitettä kevein perustein vähään aikaan. Onko sinulle Antti oikeasti usein väitetty noin?
Perusteltua väite on minusta jos sovellus on hyvälaatuinen ja bugeja on vaikea löytää ja testattava ohjelmisto suunniteltu asiantuntijoille, esimerkiksi jollekin sairaanhoidon erikoisalalle. Jos ohjelma on huonolaatuinen, bugeja löytyy heikommallakin sovellusalueosaamisella. Jos ei, vaaditaan oikeasti osaamista bugien huomaamiseen. Tämänkaltaiset ohjelmistot ovat tietysti kalliita eikä meillä yksityishenkilöinä ole niihin varaa.
Elämme keskellä suurta muutosta ja teknologiapuolella tämä tarkoittaa ymmärryksen ja asenteiden täysikäännöstä muun muassa siinä miten laitteiden ja ohjelmien tulee toimia. Vielä vain muutama vuosi sitten yleinen käsitys oli se, että jos ihminen ei ymmärrä jotain tietokoneohjelmaa, niin ihminen on liian tyhmä sitä käsittääkseen. Tilanne juuri nyt tätä viestiä kirjoittaessani on se, että mikäli ihminen ei ymmärrä jotain tietoteknistä laitetta, niin silloin tämmöinen vimpain on auttamatta vanhanaikainen ja huonosti toteutettu.
Näemme asenteiden muutoksen yhteiskunnan jokaisessa lokerossa. Terveydenhuollon ammattilaiset sanovat suoraan, että heidän nykyiset työkalut ovat sietämättömiä ja niiden käyttö vaatii aikaa aivan liikaa ja tämä aika on toki pois aidosta terveydenhuoltotyöstä potilaan kanssa.
Esimerkkejä on aivan liikaa joten tyydyn käsittelemään vielä yhtä ehkä tämän vuoden mehukkainta helmeä – nimittäin tapaus VR. Vaikka järjestelmä nyt pysyykin pystyssä, niin se pitää silti pintansa kansalaiskeskustelussa niin toreilla kuin netin foorumeillakin. Lippujen-osto-systeemiä kun ei ole liian helppo käyttää ja ihmisten mielestä käytettävyyden pitäisi olla parempi vaikkakin siitä lipun saa ostettua. En muista että olisin vastaavaa keskustelua nähnyt koskaan tällä volyymilla kotimaisessa keskustelussa jonkin tietoteknisen laitteen käytettävyydestä.
Jos systeemin ymmärtäminen vie tekijöiltäkin aikaa vuoden tai kaksi, niin siitä voi päätellä sen, että loppukäyttäjä tuskin kokee laitteen käyttöä miellyttäväksi.
Päätän kommenttini Albert Einsteinin legendaariseen määritelmään asioiden monimutkaisuudesta ja yksinkertaisuudesta:
”Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.”
Kiitos Pekka, oli oikein antoisat keskustelut 🙂 Täytyy ottaa uudestaan heti kun törmätään.
Jukka, törmään tosiaan tuohon väitteeseen hämmentävän usein. Luulen, että se johtuu osaksi meidän ohjelmistotestauksen kick-off -tuotteesta. Siinä yksi vaatimus asiakkaan suuntaan on, että tutustumme heidän järjestelmäänsä tasan yhden päivän ajan. Sen jälkeen käärimme hihat ja ryhdymme toimeen. Siitä yleensä starttaa keskustelu asiakkaan bisneksen ja tuotteen ainutlaatuisuudesta. Kommentit ovat luokkaa: ”Ettehän te voi mitenkään onnistua, jos meidän tuotteen peruskoulutuskin vie aikaa viikon” Hassua on, että kuitenkin tähän mennessä olemme onnistuneet ihan joka kerta.
Ammattitestaaja, lainauksesi lämmittää kummasti mieltä! Luin tänään Tietoviikosta hauskan artikkelin juuri mainitsemaasi aiheeseen liittyen. Suosittelen tsekkaamaan: http://www.tietoviikko.fi/cio/tahmaako+tyokoneesi+moni+miettii+jo+lopputilia/a743029?s=by_talouselama
Antti, tykkään kick-off tuotteestanne. Tuolla lähestymistavalla pääsee varmasti auttamaan myös varsinaisten ongelmien, huonon laadun syiden ratkaisussa. Pidän erityisesti testauksen ja tekemisen selkeää yhdistämistä bisnekseen ja rahaan. Sen takia tätä tehdään. Liian moni meistä on tekemässä ja testaamassa vain softaa.
Olen varma että kick-off tuote toimii. Veikkaan että teitä kutsutaan apuun kun laatu on todella näkyvä ongelma. Silloin pienemmälläkin alan tuntemuksella löytää bugeja. Jopa helposti. Ja kun koko ongelmaa katsoo tuorein silmin, voi huomata että koko ratkaisutapa on virheellinen. Kuten Ammattitestaaja sanoo, usein se on tehty liian vaikeaksi. Vaihtoehtoja ja mahdollisuuksia on liikaa, kaikkia parametreja voi säätää vaikka ei tarvitsisi, jne. Toteutuksen ja testaamisen monimutkaisuus on samalla viety maksimiin.
Olen edelleen sitä mieltä että hyvälaatuisesta aivokirurgin aputyökalusta ja ohjelmistosta ei löydä niitä kaikkein vaikeimmin nähtäviä, vaikeasti löydettäviä ja silti potilaan turvallisuuden kannalta oleellisia bugeja, ellei tiedä paljonkin aivokirurgiasta. Ilman alan tuntemusta ne jää huomaamatta. En nyt puhu mistään käytettävyysongelmista tai raja-arvotesteillä softan kaatamisesta. Niitä löytää vaikka toinen käsi selän takana ja testaamalla peilin kautta rikkinäisellä näppiksellä.
Huonolaatuisesta tuotteesta, joihin törmää ihan liian usein, löytyy perusheuristiikkaa käyttäen ihan liikaa bugeja.
En siis yritä kiistää blogin väitettäsi. Haikailen vain maailmaa, jossa softa on niin hyvää että sovellusalan tuntemusta tarvitaan uusien bugien näkemiseksi. On olemassa projekteja ja tuotteita, joissa siihen on jo päästy.
Tuo hiekkalaatikko on kyllä hyvä vertaus. Moni meistä ohjelmistoalan ammattilaisista on istunut hiekkalaatikolla ja taputtanut ämpärin kylkeen ja toivonut ”tule, tule hyvä kakku, älä tule huono kakku.” Sitten, kun on ämpäistä päästetty irti, on jännitys lauennut ja päästy ihailemaan käsien jälkiä.
Moni kakku päältä kaunis – kuuluu vanha sanonta ja sopii myös tähän alaan. Hiekkakakun sisältähän löytyy monesti käpyjä, oksanpätkiä, männyn neulasia, kissan jätöksiä tai hiekka on liian märkää tai kuivaa. Kun kokemus karttuu kakun teossa oppii huomaamaan, että hiekanhan voi vaikka sihdata ensin ja kastella tarvittaessa ja kas laatu paranee.
Ainutlaatuista hiekkakakuissa on ainoastaan se mihin ja miten kakkuja käyttää, muuten ne ovat hiekkaa kaikki.
Jukka, Iso Joulukiitos erinomaisesta näkökulmasta. Tiedän kyllä itsekin muutamia malliesimerkkejä onnistuneista softatoteutuksista, joissa testauksen tärkein anti saavutetaan hyvin hyvin syvällisellä tietämyksellä softan arkkitehtuurista ja käyttötarkoituksista. Nämä tapaukset ovat valitettavasti vain yhden käden sormilla laskettavissa. Siksi meillä testausihmisillä onkin paljon annettavaa softakehitykselle sen toimialaan katsomatta.
Testipena. Mikä ihastuttava vertauskuva. Minä tykkään hiekkalinnoista ja lisäksi olen ihan Joulufiiliksissä 🙂
Kerran olen ollut projektissa jossa testauksen kohde oli CAD-ohjelmisto jolla pystyi suunnittelemaan vaikkapas talon tai polkupyörän. Moni insinööri on tutustunut CAD-ohjelmistoihin ja näin oli asian laita myös minun kohdalla, sillä olen suorittanut opiskeluaikana CAD-kurssin. Toisin sanoen tämä tarkoittaa sitä, että minun CAD-tuntemus on matala tai se puuttuu tyystin. Suurin piirtein samalla mallilla oli asiat kollegallani jonka kanssa uppouduimme tämän monimutkaisen erikoisammattilaisille suunnatun työkalun syövereihin.
Pystyimme suoriltaan testaamaan ja arvioimaan tietokoneohjelmalle tyypillisiä ominaisuuksia kuten käynnistys, sammutus, muistin kulutus, CPU jne. Käyttöliittymästä pystyi sanomaan sen verran, että siellä se on ja tuosta se vissiin suorittaa tallennuksen. Ei auttanut muuta kuin alkaa opettelemaan ohjelman aitoa käyttöä jotta kykenisimme sen testaamaan. Noin viikon väännön jälkeen pystyimme paikallistamaan virheitä piirrettyjen seinien materiaalien paksuuksista (eräässä tapauksessa tuli tuumina vaikka piti tulla sentteinä) ja kahden viikon jumpan jälkeen piirtofunktiosta alkoi paljastumaan yhtä sun toista.
Bugeja popsahteli liukuhihnalta ja samalla kun minä keskityin bugien raportoimiseen, niin kollegani sukelsi yhä syvemmälle ja syvemmälle CAD-maailmaan ja piirsi lopulta yksityiskohtaisen polkupyörän jossa oli pinnat renkaissa ja nätti hyvin muotoiltu penkki ynnä muuta polkupyörälle tyypillistä. Noin neljän viikon aikana löysimme kymmenittäin bugeja jotka asiakas hyväksyi ja lopuksi asiakas sanoi jotakin minkä tulen muistamaan aina. Asiakas sanoi: ”tämä tuote kyllä toimi ennen kuin te sen testasitte”. Moista kohteliaisuutta emme olleet aikaisemmin kuulleet testaustyössä.
Ammattitestaaja. Kiitos kommentistasi. Tai pikemminkin tarinastasi. Se oli opettavainen 🙂
Minusta tarinassasi piilee tähän teemaan erinomaisesti sopiva opetus. CAD-ohjelmistonne valmistaja oli ilmeisesti ymmärtänyt illuusion aiheuttaman ongelman ja uskaltautuneet kokeilemaan alaa etukäteen tuntematonta testausasiantuntijaa. Tässä tapauksessa pääsitte todistamaan että investointi kannatti.
Antti, kyllä tässä tapauksessa oli kyse juurikin siitä, että asiakas rohkeni tilaamaan ulkopuolisen testauksen. Asiakas oli siinä ymmärryksessä, että heidän tuote on viittävaille myyntikunnossa. Satunaiset ilmoitukset pilottitestaajilta sai managerin kuitenkin epäilemään, että onkohan kaikki bugit sittenkään tiedossa. Niimpä manageri päätti testauttaa tuotteen ammattitestaajilla ja voin kertoa, että tämä kaveri ei katunut sekuntiakaan päätöstään. Juttelimme myöhemmin, että ammattitestaukselle on paikkansa koko projektin elikaaren ajan eikä pelkästään lopussa. Olimme managerin kanssa täydellisessä harmoniassa loppuraportin jälkeen.