Tarinoita IT-hankkeiden ihmemaasta
Lukijamme on lähestynyt meitä erittäin kiinnostavalla tarinalla julkisen sektorin IT-hankkeista. Tarina herättää varmasti fiiliksiä sekä puolesta, että vastaan.
Hei,
Olen lukenut blogistanne vuosien varrella pari juttua joissa on ohimennen puhuttu julkisista IT-projekteista. Haluaisin nyt tuoda tähän aiheeseen lisävalaistusta.
Olin hiljattain isohkossa julkisen puolen IT-projektissa pääkaupunkiseudulla. Tavallisesta poikkeavaksi tilanteen teki se, että Tilaaja oli hankkinut itselleen ammattitestauksen turvaamaan tilauksen tason. Minä olin yksi näistä Tilaajan testaajista.
Kyseessä oli SAP-ympäristössä pyörivä järjestelmä. Järjestelmässä oli useita osia ja näille omat Toimittajansa ja kaikkien Toimittajien piti saada omat palikkansa keskustelemaan toisten Toimittajien palikoiden kanssa.
No aloitimme tietenkin heti testaustyön kun työmaalle päästiin. Toimittajat olivat saaneet rakennettua järjestelmän jo sille mallille, että järjestelmän eri osiin pystyi kirjautumaan ja niitä yksittäisinä palikoina testaamaan. Vain parin tunnin päästä testauksen aloittamisesta oli selvää, että nyt saattaa hyvin tulla bugien kirjoittamisen uusi Suomen ennätys tai jopa Maailman ennätys. Korostan, että olimme vasta aloittaneet Toimittajien yksittäisten järjestelmän osien testauksen. Bugeja löytyi kaikilta ohjelmistotestauksen osa-alueilta alkaen käytettävyydestä aina turvallisuuteen asti.
Raportoimme välittömästi bugit ja kun raportti saavutti Toimittajat, niin alkoi show jota en ole urallani kertaakaan aikaisemmin nähnyt. Toimittajat ottivat välittömän puolustusaseman ja alkoivat asemasodan testausta vastaan.
Emme osanneet testata, testasimme prosessin vastaisesti ja testasimme täysin vääriä asioita.
Yksi SAP-Toimittajan edustaja huusi ihan suoraa huutoa, sillä bugeja oli liikaa. He eivät olisi millään niitä halunneet korjata niitä, ainakaan samalla rahalla.
Tästä “prosessin vastaisesta” testauksesta nousi oma suosikkini. Toimittajat olivat sitä mieltä, että kun on prosessiksi sovittu nappien painamisjärjestys 1 ja 2 niin se on sitten se eikä muita hyväksytä. Me tottakai testasimme myös mitä tapahtuu kun painaa 2 ja 1, ja niinhän sieltä paljastui että luvattoman monessa kohtaa järjestelmä rakoili ja lopulta kaatui.
On älytöntä olettaa, että loppukäyttäjä ei koskaan painaisi nappeja väärässä järjestyksessä.
Minulle alkoi selviämään pala kerrallansa, että mistä on kyse. Toimittajat olivat vuosikausien aikana tottuneet siihen, että bugien korjaus laskutetaan erikseen ja siitä oli muodostunut heille merkittävä osa projektin laskutusta. Toimittajille on hyvää businesta IT-projektin venyminen, sillä heille se tarkoittaa isompaa laskutusta ja voit uskoa minua kun sanon, että laskutus juokseen.
Toisinaan vitsailin kollegani kanssa, että taitaa olla laskutus Toimittajan ainoa asia mikä toimii hyvin. Minulle jäi käsitys, että oli varsinkin SAP-Toimittajille ensimmäinen kerta kun he kokivat, että Tilaaja testautti tilauksen ulkopuolisilla ammattilaisilla ennen tilauksen hyväksymistä ja tämä nyt sitten tavallaan vaaransi Toimittajien normaalit laskutusrutiinit. Itse henkilökohtaisesti selitin Tilaajalle, että näin bugisesta toimituksesta ei kannata maksaa mitään ja että ennen kuin edes harkitaan laskun maksua, niin bugit on korjattava ja testaamalla todettava korjatuiksi.
Ehdimme toimia Tilaajan palomuurina puoli vuotta kunnes sitten eräänä päivänä tuli ilmoitus:
Johtokunta oli päättänyt antaa potkut Tilaajan testaustiimille.
No eipäs siinä mitään ihmeellistä, ajattelin. Olimme saaneet kuitenkin jo paljon asioita etenemään ja opetettua Tilaajalle tärkeitä asioita IT-järjestelmien tilausprosessista ja softatestauksesta. Olin siis kohtuullisen tyytyväinen kaikesta huolimatta, mutta toki samalla ymmärsin sen, että valmista ei tule tästäkään hankkeesta vuosikausiin, mutta hyvin lähellä he olivat.
Tässä ei kuitenkaan ollut vielä kaikki. Vielä projektissa olessani, sain kuulla että tässä johtokunnassa istuu näppärästi Tilaajan ja Toimittajan edustajat yhdessä. Toki on hyvä asia, että Tilaajalla ja Toimittajalla on yhteinen foorumi, mutta tämä johtokunta pystyy päättämään esimerkiksi että poistetaanko Tilaajalta testaus.
Päätöksen tämän kirjoituksen laatimisesta tein kuitenkin vasta sen jälkeen kun kuulin toiselta testaajakollegaltani, että hänen julkisen puolen IT-projektissa oli johtokunnassa sama järjestys. Heillä vain oli testaustulokset heitetty lähes sellaisenaan roskiin. Kyseinen IT-hanke meni pahasti pieleen ja saimme kaikki lukea siitä valtakunnan ykkösmedioissa.
Tarinahan jatkuisi vaikka kuinka pitkään ja herkullisista yksityiskohdista ei ole puutetta. Lopuksi mainittakoon vielä yksi sellainen. Koimme nimittäin tilanteen, missä Toimittajat olisivat halunneet myydä Tilaajalle omat testaajansa tai “konsulttinsa” kuten SAP-piireissä on tapana sanoa. Tämä on ajatuksena aivan käsittämätön.
Tilannehan olisi täsmälleen sama, jos huoltaisit itse oman autosi ja suorittaisit vielä katsastuksen päälle omakätisesti.
Kaikesta huolimatta kyseinen projekti oli minulle ehkä urani paras. En nimittäin ole armeija-aikani jälkeen nähnyt kun aikuinen mies huutaa ja ulisee täyttä kurkkua työaikana. Sain kokea hurjan konkreettisesti testauksen tehon ja minä tarvitsin tämän kokemuksen. Tästä on hienoa jatkaa.
Kun Toimittaja huutaa kurkku suorana, on testaaja saattanut tehdä jotakin oikein.
Pitäisiköhän perustaa itleaks sivusto julkisen hankinnan kähmintää varten..
Oisko muuten ylikätevää jos päätettäis ihan lakitasolla että johtajat saa bonareita, jos projektit ei kuse valtion IT hallinnossa.
Hei, tämä vaikuttaa sellaiselta tilanteelta, että tästä pitäisi kyllä ilmoittaa poliisille. Lahjonta ja korruptio vaikuttavat tapauksessa selvältä. Jääviysasema myös.
Pystyykö pakettisoftassa kuten SAP nappeja painamaan väärässä järjestyksessä? Vai onko kysessä toimittajan tekemä customointi? Jotenkin tuntuis että vanilla-SAP:in pitäis noilta osin toimia out of the box. Käytettävyys on sit asia erikseen 🙂
Tuo kertomus oli täysin normaali julkishallinnon projektin tarina. Sitten tietohallintopäälliköstä riippuu pitkälti, miten asiat jatkuvat. Yhdessä palaverissa toimittajan kitinälle tietohallintopäällikkö totesi suoraan, että turpa kiinni. Sitten taas on niitä projekteja, joissa tietohallintopäällikkö pitää järjestelmätoimittajan sanaa Jumalan sanana ja sitä ei kyseenalaisteta.
Ongelma ei ole vain toimittajan ongelma, vaan myös tilaajan ongelma. Ensinnäkin hyväksytään aivan törkeitä sopimuksia. Joissain tilanteissa jopa kielletään sopimustasolla ulkopuolisten testaajien tai tarkastajien käyttö, tai sitten toimittaja pystyy estämään tarkastukset sanoen vain, että tarkastus vaatii muiden asiakkaiden tietoturvan tai toimittajan liiketoimintasalaisuuden.
Monestihan kuvio menee, että ekana kilpailutetaan määrittely, jonka voittaa yksi iso. Sitten sen pohjalta itse hanke, jonka voittaa se sama iso. Käyttöpalvelut sitten hankitaan joltain muulta. Laadunvalvonta ja projektinhallinta on sitten helppo ostaa siltä yhdeltä isolta. Se yksi iso siis johtaa, valvoo ja hoitaa kommunikoinnin. Ja tekee tietenkin itse määrittelemän tuotteen.
Hyvin kirjoitettu, ja vahvasti testaajan näkökulmasta. Olisi kuitenkin mielestäni hyvä, jos näkisi myös sen toisen puolen eli kuinka tilauksia neuvotellaan, hinnoista sovitaan ja sopimuksia tehdään. Asiakasorganisaatioilla on kova tarve päästä kiinteähintaiseen sopimukseen kiinteillä vaatimuksilla. Niinpä kaikki sellainen ”yleinen” tieto, jota ei ole kirjoitettu ylös aktiivisesti jätetään ulos vaatimuksista, ja jokainen bugi siinä ettei järjestelmä edes tee sitä mihin se on oltu hankkimassa on uusia vaatimuksia. Mallissa on paljon vikaa, ja yhtälailla tilaajan kuin toimittajan päässä. Ajatus siitä, että malli korjattaisiin testaamalla on kuitenkin absurdi. Sopimustekstistä ja toiminnan puitteista se lähtee. Monesti asiakkaan testausorganisaatioilla ei edes ole sitä sopimustekstiä käsissään, ja siinä sovitaan että ei ne asiakkaan vaatimukset vaan ne yhdessä sovitut määritykset tätä laajuutta ohjaa. Alkuun tarvittiin toimiva järjestelmä (vaatimus), ja sitten määriteltiin teoria miten se voitaisiin tehdä (määritys) ja teoria ei vaan toimi käytännössä.
Kyllähän yhteisen projektin ohjausryhmässä pitää olla sekä asiakkaan että toimittajan väkeä. Ja useinkaan asiakkaan testausorganisaatio ei ole edustettuna. Ohjausryhmäpäätösten taustalla on useimmiten paljon enemmän ulottuvuuksia kuin vain se että päätetään lakkauttaa testaaminen. Saattaisin itsekin koittaa rauhoittaa projektitilannetta vastaavalla liikkeellä, varsinkin jos tosiaan homma on mennyt metsään jo tilausvaiheessa.
Onneksi vaihteeksi tekee töitä tuotekehityksessä, jossa ei käytetä puolta ajasta (ja rahasta) siihen että väännetään kättä siitä onko ehdottomasti reagoitava asia bugi vai muutospyyntö (kuka maksaa) vaan koitetaan rakentaa askeleittain parempaa tuotetta.
Maaret Pyhäjärvi; vai että koodista löytyvät selvät koodausvirheet ovat yht’äkkiä tilaajan ja testausryhmän(!) syytä? Taidat saada palkkasi joltain näistä surullisenkuuluisista softataloista.
Mielestäni tämä postaus kommentteineen kertoo sen kuinka kaukana ns. ”asiantuntijamyynti” on perinteisestä palvelumyynnistä. Hyvin tuote- ja prosessivetoista. Se tärkein eli asiakasnäkökulma puuttuu. Ja insinöörimäinen ajattelutapa siitä kuinka monimutkaisempi on parempi.
Minä asiakkaana olen isompia ja pienempiä sovelluksia / kokonaisia hankkeita ostaneena päätynyt siihen että nykyisin kun toimin osakkaana alan yrityksessä ja palveluiden tuotteistajana, että asiakas ostaa lopputuloksen. Toimittajan ammattitaitoa on määritellä homma hyväkatteiseksi ja tietää miten se tehdään. Samalla hintaan sisällytetään x-määrä korjaustöitä koska virheitä / bugeja tulee AINA. On hinnoittelutaidottomuutta jos ei osaa leipoa näitä tunteja hintaan. Asiakkaat alkavat usein myös lisäämään vaatimuksiaan projektin edetessä tai muuttamaan suunnitelmaa. Näistä rapsahtaa lasku aina. Mutta omia virheitä (bugeja) ei laskuteta asiakkaalla.
Julkisella sektorilla toki ongelmansa aiheuttaa myös se että hinta on määräävä tekijä. Toimittaja kuitenkin pystyy tähänkin vaikuttamaan löytämällä muitakin kilpailuetuja kuin hinnan tai yrityksen suuruuden. Suuruus tarkoittaa usein vain raskaampaa organisaatiota ja useampaa vastuunpakoilijaa.
Ja kähmintä on sitten ihan oma lukunsa.
”Tilannehan olisi täsmälleen sama, jos huoltaisit itse oman autosi ja suorittaisit vielä katsastuksen päälle omakätisesti.”
Melko kärjistetysti sanottu. Kyllä monella Toimittajalla on oma testausorganisaatio. Ei se ulkopuolisen testausfirman käyttö autuaaksi tee.
Mitenhän tuo (julkisen puolen) IT-hankintaprosessi pitäisi hoitaa, jotta varsinaista työtä ei valuisi laskutuksen puolelle tuotteen saamiseksi asianmukaiselle tasolle…
Puhutteleva tarina taas kerran. IT-hankkeiden ostamiseen ja johtamiseen kaivattaisiin kipeästi parempaa koulutusta ja tukea. Tällä hetkellä Suomessa poltetaan vuosittain satoja miljoonia veroeuroja taivaan tuuliin. Houston julkaisee ”Ketterän kehityksen ostajan oppaan” syksyllä joka toivottavasti tuo julkisellekin puolelle hieman työkaluja hankkeiden ostamiseen paloissa ja hallitusti. Go testaajat!
Hei
Olen työskennellyt pitkään julkisella sektorilla. Aiemmin edustamissani organisaatioissa oli omaa teknistä osaamista palkattuina henkilöinä. Oikeistopuhurin seurauksena nämä ihmiset on täytynyt tietenkin laittaa ulos ja ostaa palvelut yrityksiltä. On kuulemma tehokkaampaa ja laadukkaampaa. Aiemmin omat palkatut henkilöt olivat asiantuntijoita. He tekivät itse ja mitä eivät osanneet, ostettiin ulkoa, mutta oman asiantuntijuuden kera. Nyt julkisen sektorin asiantuntemusta on ulkoistettu ja ihmetellään, kun ei ole osaamista A tehdä itse ja B johtaa hankintoja. Kuinka voisikaan olla? Kokoomuksen mielestä tämä on tehokasta. Konsultit ym. kiittävät.
Toinen puoli on se, että julkisen sektorin ohjelmat ovat oikeasti monimutkaisia. Valtavia henkilötietojärjestelmiä jne. Ne vaativat hieman syvällisempää ja varmempaa tuotantoa kuin nämä kännyköiden soittoäänet tai muut vapaa-ajan palvelut, joiden kohdalla on otettu ihan normiksi, että välillä homma ei pelaa ja jonotat päiväkausia jonkin yksityisen firman neuvontanumeroon, eikä homma silti ratkea. Vastaavaan ei ole varaa esim. sairaalasa.
Kaupallinen malli ja kulttuuri IT-järjestelmähankinnoissa pitäisi tervehdyttää. Sanoisin, että yleisen kulttuurin ja ostajien osaamattomuuden vuoksi, hankintojen urakkarajat määritellään niin että kaiken extran maksaa Tilaaja. Keikka menee aina sille joka halvimmalla myy. Busineksessa menestyvät ne, joilla eniten röyhkeyttä vääntää näistä asioista. Lopulta ostajat saavat mitä tilaavat, eli markkinoilla on vain samanlaisia toimittajia.
”Ja insinöörimäinen ajattelutapa siitä kuinka monimutkaisempi on parempi. ”
Simple, elegant, and wrong.
Onpas taas mutkia vedetty suoraksi. Tässä näkee taas että kaksi it-toimittajaa ei pysty tekemään Suomessa yhdessä hommia. Huisaa olisi kuulla myös toisen toimittajan mielipiteet tästä testaus-toimittajasta.
On tullut tuo julkisen puolen it-touhu nähtyä niin ison kuin pienen toimittajan näkökulmasta ja jos kilpailutus säännöissä lukee että ”Vähintään 100M liikevaihto” niin kyllähän pienet jyrätään heti kättelyssä. Hieno on että isot kunnat ovat luoneet oman verkostonsa mistä tätä samaa kuppasta voidaan jatkaa vaikka järkevämpää olisi pyörittää rahat oman kunnan pienemmissä firmoissa.. On niin nähty tää fyrkan lypsäminen että oikein pahaa tekee. Loppupeleissä ollaan kuitenkin me kansalaiset niitä maksumiehiä tässäkin..
Artikkeli yritti ilmeisesti sanoa, että suomalainen ohjelmisto-osaaminen on onnetonta, ei edes pakettiohjelmistoa saada asennettua.
Vai?
Viitaten tuohon ”insinöörien ajattelutapaan että monimutkainen on parempi”, tässäpä teos joka valottaa sitä ongelmaa ja mitä sille pitäisi tehdä: http://www.amazon.com/Why-Software-Sucks-What-About/dp/0321466756
Kiitos hyvästä postauksesta. En tiedä it-alasta tai ohjelmoinnista yhtään mitään, osittain siksi että ammattilaiset harvoin osaavat puhua työstään taviksille ymmärrettävästi. Olen kuitenkin ollut valtiolla töissä ja seurannut mm. tätä e-reseptisotkua (huom.oikea kirj.asu) ja uutisia kuinka se on sujunut Virossa paljon näppärämmin. Tämä juttu oli selkeä ja mielenkiintoinen.
Jos kyse on julkisen sektorin julkisesta projektista, niin miksi jättää kertomatta mistä hankkeesta todellisuudessa on kyse?
Tämä, jo klassikoksi käynyt Dilbert taitaa kiteyttää tarinan melko tehokkaasti:
http://dilbert.com/strips/comic/2000-03-19/
P.S. Massiivinen kommenttivyöry ja jakojen määrä Twitterissä ja FB:ssä. Superkiitokset teille kaikille lukijoille! Blogin uusi kävijäennätys taisi syntyä tänään!
Tämän voisi kääntää englanniksi, huomioarvo varmasti riittäisi kotimaan rajojen ulkopuolellekin. 🙂
Heh.
Suomalaisten Tilaajien osto-osaaminen on käsittämättömän huonolla tasolla.
Toimitussopimuksissa hyväksytään mukisematta , miettimättä muita vaihtoehtoja. Toimittajat sekä heidän Konsultinsa ovat valitettavan usein toisiinsa vahvasti sidoksissa jolloin riippumattomuus on enemmäkin kyseenalaista kuin todellista.
Vastaavasti Tilaajan puolen vaatimusmäärittelyt ovat luokkaa:
”Me tarvittais nyt tämmönen systeemi jolla saadaan mopon paukkulaakerin peräöljy vaihdettua”.
Tee sellainen sopimus jossa on selkeät hyväksymiskriteerit, sanktiot myöhästymisistä puolin ja toisin, IPRt huomioitu ja varmista, että projektin ohjausryhmä on RIIPPUMATON TOIMITTAJASTA. Tilaajan puolelta tarvitaan henkilö jolla on oikeasti mandaatti tehdä päätöksiä, tietohallinon edusta, loppukäyttäjien edustaja ja Toimittajalta henkilö jolla myös mandaatti päättää asioista. Enempää ei tarvita eikä saa olla.
Tässä minun IMHO
Koko tilausjärjestelmässä on sellainen valuvika, että suositaan suuria hankkeita ja tarkkoja speksejä ja että ohjelman omistusoikeus jää tuottajalle. Nämä pitäisi kääntää kaikki päinvastaisiksi. Eli jos julkishallinto tilaa jotain, olisi edellytyksenä, että kaiken koodin tekijänoikeus siirtyy avoimella lisenssillä tilaajalle ja sitä kautta kenen tahansa jatkokehitettäväksi. Tämä katkaisee kahleet, joilla tilaaja on sidottu jatkoprojekteihin. Sen jälkeen tilauksista tehdään pieniä, parin tonnin pumpseja, jotka rakentavat uusia yksityiskohtia olemassaolevaan avoimeen järjestelmään. Jollain kevyellä hallinnollisella käytännöllä rahat annetaan kenelle tahansa, joka ensimmäisenä on tuottanut halutun toiminnallisuuden tuottaman koodinpätkän tai korjannut olemassaolevassa koodissa olevan bugin.
Matti. Minusta erinomainen lähtökuoppa osto-osaajan tarkistuslistaksi. Tuostahan kääräisee äkkiä pikaoppaan kasaan ja alkaa vetämään koulutuksia!
Jos ostaja ottaisi edes ISO-12207:n kouraan, kävisi sen läpi ja pohtisi, toteutuvatko siinä olevat asiat edes jollain tasolla, projektit olisivat jo voiton puolella. Monesti nähnyt esimerkiksi sen, että kellään ei ole kokonaiskuvaa projektin etenemisestä. Projektiin olisi riittäny lukea:
6.3.2.3.1.1 The manager shall monitor the overall execution of the project, providing both internal reporting of the project progress and external reporting to the acquirer as defined in the contract.
Tuo on pelkkää tervettä järkeä, mutta hankinnoissa niin usein tuntuu unohtuvan se.
Hauska kirjoitus, joka kuvastaa monia pielessä olevia asioita. Varmasti etenkin julkisen sektorin puolella, mutta myös monessa muussa isommassa projektissa.
On testausta ja on testausta ja testausvaihetta ja testausvaihetta. Opetusmielessä ja asioiden julkituomisen puolesta kannatan kaiken alalla vallitsevan kökön popularisoimista ja mutkien suoriksi vetämistä, sen puolesta kirjoitus on oikein hyvä.
Hieman oudoksun muutamia juttuja, joiden toki tässä tapauksessa oletan olevan kärjistyksiä (joskin qa-ammattilaisisten parissa olen myös törmännyt varsin erikoisiin asenteisiin suhteessa muihin toimituksissa mukana oleviin ryhmiin).
Toivoakseni qa:n tehtävä missään projekteissa ei ole pääasiassa bugien raportoiminen, ja toivottavasti qa-ihmiset eivät yleisesti pidä onnistumisen merkkinä sitä, että kukaan huutaa kurkku suorana. Moinen kuulostaa hieman, no, ei hirvittävän ammattimaiselta.
Oletettavasti myös tässä projektissa, kuin kaikissa muissakin isoissa projekteissa, on pyritty välttämään poteroihin kaivautumista kaikkien osapuolten toimesta. Töitä on varmasti tehty hurjasti sen eteen, että kommunikaatio qa-ihmisten ja esimerkiksi kehittäjien välillä toimii kuin rasvattu, ilman että mikään osapuoli korostaa omaa erinomaisuuttaan.
Totta puhuen yllämainittu on eittämättä vaikein osa mitä tahansa ohjelmistoprojektia, ja enpä usko että tässäkään tapauksessa mikään osapuoli selviää ns. puhtain paperein. Oletettevasti ns. ulkoiset qa-konsultit toimivat myös omien sopimustensa piirissä, en tiedä kuinka paljon nämä suuntautuvat ongelmien ratkaisuun, verrattuna ongelmien raportoimiseen.
Ohjelmistoprojektit ovat pääasiassa yhteistyöprojekteja. Kaikinpuoleinen rintamien rakentelu eri vaiheiden väliin on omiaan varmistamaan, että lopputuloksena on ns. ”kusista paskaa”.
Ehdottomasti arvostan sekä qa-ammattilaisten työtä, että julkisen puolen hankintojen popularisointia jotta näistä asioista saadaan oikeasti keskustelua aikaiseksi myös alan ulkopuolella. Huudattamalla toimittajia vaan saadaan harvoin mitään aikaan.
Just samaa peetä tälläkin hetkellä. Kyllä julkkaripuolta osataan kusettaa toimittajien puolelta.
Toimittaja ei testaa itse mitään ja asiakkaan ammattitestaajat ohitetaan mennen tullen, koska he rikkovat status quon.
Onko asiakkaan vastuuhenkilöillä vielä usko joulupukkiin tallella vai mitä tää pelleily oikeen on?
mistä tää Heimonen saa palkkansa?
kyllä testaajan päätehtävä on AINA raportoida vikoja. piste.
Toimittajat todellakin laskuttavat asiakkaalta kun korjaavat omia vikojaan. aivan käsittämätöntä touhua. Kuka tollo tekee tälläsiä sopimuksia?
Sama kun Nokia pyytäisi jos ostetun kännykän vikojen korjaamisesta lisähintaa.
”tällä ei voi soittaa”, ”maksa 10e lisää niin taas toimii”
toisaalta ei se ole tyhmä joka pyytää vaan se joka maksaa.
Mistäs Jii saa palkkansa?
EIkös testauksen tarkoitus ole varmistaa softan laatu.
”EIkös testauksen tarkoitus ole varmistaa softan laatu.”
Softan laadun varmistaminen sisältää, mutta ei rajoitu, bugien (vikojen) raportoimiseen. Jos bugeja ei raportoida, ei softalla ole laadun varmistusta. Bugien rapotoiminen on kriittinen osa laadunvalvontaa, jos jotain muuta kuvittelee on pihalla kuin lumiukko.
Niinhän se pitäisi olla, että toimittaja maksaisi itse omat mokansa, mutta kenen pussista se sitten menee, jos koodari ja testaaja ovat eri mieltä siitä, miten jonkun jutun pitäisi toimia, kun tilaaja on itse toimittanut toimittajalle bugisen speksin? Kuka speksin testaa vai testataanko niitä yleensä ollenkaan?
Toteutuksen tekijä on sokea tuotteen arvioimisessa ja tässä testaaja tulee todella tärkeään rooliin. Testaajan tarkoitus on varmistaan tuotteen laatu kyseenalaistamalla toteutus. Testaaja ei pelkästään raportoi vikoja vaan myös huomioita tuotteesta. Nämä voivat olla niin positiivisia kuin negatiivisia. Näiden perusteella voidaan myös saada tärkeää palautetta jatkokehitystä tai muutospyyntöä varten.
OHJE KIRJOITTAJILLE: Pysykää kommenteissa asialinjalla. Väittely on hyvästä, mutta muiden kommentoijien henkilöön käyminen tai palkanmaksajan arvuuttelu ei kuulu tälle foorumille. Varmasti riittää keskusteltavaa ihan asiastakin.
Kyllä testaus on aloitettu ilman muuta liian myöhään jos vasta tuossa vaiheessa kääritään hihat ja käydään jo ”toimivan” softan kimppuun. Itse aloitin eräässä vetämässäni projektissa testausjengin mukana roikottamisen (sillointällöin palaveri, dokumentit kulkivat) jo analyysivaiheen alkumetreillä. Ensimmäinen testaus oli varhaisen vaiheen analyysidokumentin katselmus, jossa yksi testauspuolen kaveri oli mukana tutustuttuaan dokumentaatioon kunnolla (allokoitiin aikaa ja toimitettiin prujut ajoissa). Tuloksena oli, että vaatimuksiin lisättiin yksi ainoa kohta, jonka seurauksena sitten myöhemmän vaiheen testaus oli suunnattoman paljon helpompaa. Myöhemmissä vaiheissa testauskaverin mukanaololla oli myös vaikutusta toteutuspriorisointiin. Eli jos testauksen kavereita pidetään oikeasti mukana eikä vain muodon vuoksi, siitä voi olla hyötyä muutenkin kuin että prosessin reunaehdot täyttyvät ja projektikohtaisessa prosessikatselmoinnissa saadaan rasti ruutuun. Vahinko vaan että se maksaa. Siis juuri siinä vaiheessa kun kaveri istuu palaverissa, sen sijaan että testaisi jotain rupisempaa systeemiä. Jälkeenpäin ällistys oli suuri kun huomattiin että (integraatio- ja järjestelmä-) testaus oli ajallisesti lyhytkestoisempaa (kaverit tunsivat järjestelmän) ja löydetyt bugit vähäisempiä vakavuudeltaan kuin talon muissa laajuudeltaan ja vaativuudeltaan samankaltaisissa projekteissa. Muistaakseni yhtään ainoaa showtopperia ei löytynyt lopullisissa testauksissa vaikka niitä talkoilla haettiinkin. Ne olivat löytyneet jo paljon aiemmin, pahimmat jo analyysi- ja designdokumenttien katselmoinneissa. Kokonaisuudessaan testauksen ”hinta” oli pienempi kuin muissa samanlaisissa projekteissa.
Tuo laadunvarmistus -juttu on mielenkiintoinen. Kun mun järjen mukaan testaaminen ei voi mitenkään varmistaa tuotteen laatua, testaaja testaa tuotetta ja raportoi tuotteen laadun. Sen jälkeen projektin johdolla on tehtävänä tehdä päätöksiä bugien korjauksesta etc. raporttien pohjalta. Mutta jos johto ei kykene tekemään päätöksiä niin vaikka kuinka testaajat testaisivat niin laatu ei parane.
Toinen hassu pointti testauksen maailmassa on tämä ”testaatte väärin” -läppä. Miten on mahdollista testata väärin? Eikö softa pitäisi olla niin rakennettu, että sitä ei voi käyttää eri tavoin/tarkoitukseen kuin se on suunniteltu? Eli siis väärin.
On mielenkiintoista ajatella mitä loppukäyttäjä sitten tekee kun hän sattuu toistamaan tuotetta käyttäessä tämän ”väärin testatun” testin. Käyttääkö hän sitten tuotetta väärin? Ja ymmärtääkö tämä loppukäyttäjä toimittajan vastauksen ”Ei siinä mitään vikaa ole, käytät sitä väärin”
Itselläni saattaisi tulla ns. kahvit näppikselle jos joku mulle vastaisi että tuotteessa ei ole mitään vikaa, sinussa on.
IT-projektien läpivientiä tukemaan erikoistuneita konsulttitaloja on useita. Se, mikseivät tilaajat heti alkuun palkkaa varsinaisten toimittajien ulkopuolelta konsulttia näihin mittaviin IT-hankkeisiin on täysin käsittämätöntä. Pätevien konsulttien avulla varmistettaisiin se, ettei sopimuksiin pääse tilaajan kannalta täysin älyttömiä ehtoja ja se, ettei tilaaja suoraan sanottuna kusta linssiin.
Freelancepohjalta aika pirun monta projektia seuranneena sanoisin, että SAP toimittajissa on suuria eroja. Parissa suomalaisessa firmassa kokemus on kumuloitunut siihen malliin, että projektit onnistuvat suunnilleen odotusten mukaan. Samaan aikaan en ole nähnyt yhtään offshore toteutusta, joka täyttäisi hyvän laadun vaatimukset.
Joku kommentoi standardiSAPin toiminnallisuutta. Se on testattu hyvin vuosien saatossa ja nykyään pitää olla aika syvällä jonkin harvinaisen tai sitten uuden toiminnallisuuden syövereissä, että löydät vikoja. Eri asia taas on se, että intialainen koodari käy yrittämässä lukea tietoja tietokannasta transaktion sisällä, jolloin mahdolliset muutokset jäävät huomaamatta. Tällöin on juuri kysymys nappien painamisesta järjestyksessä 1 & 2. Jos et ole tallettanut dokumenttia ennen kuin yrität tehdä jotain muuta, niin pieleen menee. Harmi vaan, että juuri nämä testausskriptit sementoivat prosessia niin, että toiminnallisuus tulee aina testattua samalla tavalla.
Eikö sen kuitenkin pitäisi mennä niin, että nämä toimittajat ovat itse sisäisesti omat softansa testanneet ennen kuin ne toimitetaan asiakkaalle? Asiakkaan testaus sitten varmistaa omilla testeillään, että softa tosiaan on sitä mitä on luvattu. Jos asiakkaan oma testaus löytää bugeja (pahoja sellaisia kuten vaikka kirjoitusvirhe käyttöliittymässä, koska se kertoo heti sen, että softaa ei ole testattu) tilatusta softasta, niin kyllä silloin homman on mennyt pieleen jo kauan ennen varsinaista toimitusta.
Parastahan tässä kaikessa on aina se että osoitellaan sormella kaikkiin mahdollisiin suuntiin ja kommentoidaan ”tuo ei osaa”, ”tuo ei halua”, ”nuo on tyhmiä”, ”kyllä minä, mutta kun muut..”, jne.. Heimosella on hyvä pointti siitä, että softan tekeminen on yhteistyötä. Sekä kehityksen, qa:n ja asiakkaan taholta. Nykyiset systeemit on niin monimutkaisia, ettei paraskaan määrittely riitä erittelemään kaikkia vaatimuksia tarpeeksi tarkalla tasolla että kehittäjät sen pystyisivät tekemään kerralla oikein. Ja vastaavasti parhaatkaan kehittäjät eivät saa järjestelmää tehtyä kerralla oikein, puhumattakaan siitä että laadunvarmistus tai asiakas ensimmäisellä testauksella löytäisivät kaikki mahdolliset ongelmat. Tekeminen on vain niin paljon helpompaa jos kaikki myöntävät että inhimillisiä erehdyksiä sattuu ja tekisivät parhaansa yhdessä että niitä sattuu mahdollisimman vähän ja ne huomataan mahdollisimman pian, sen sijaan että osoiteltaisiin sormella ja etsittäisiin syyllisiä.
Tyylikäs kirjoitus säälittävästä tilanteesta. Jatka samaan malliin!
Loistava juttu taasen. Tosin, itselleni ei mikään yllätys..
Valitttavaa on, että ohjelmistotalot käyttää tarjouskilpailuja hyväkseen: tarjotaan duunia (tahallaan liian) halvalla ja jokaikinen ei-speksattu juttu/työ laskutetaan myöhemmin lisänä. Kyllä ois tekemätöntä työtä ja paljon olla maksajan puolella suunnittelamassa testausta! Ihmetellä täytyy, kuink samat firmat porskuttaa vaan..
Olen tällaisten ohjelmien ”loppukäyttäjä”, tämä juttu selitti paljon sitä, miksi niin moni asia on saattanut mennä pieleen meille lykätyissä työajan- ja matkanhallintaohjelmissa, joiden käyttämiseen menee paljon enemmän työaikaa kuin vanhan ajan paperilomakkeen tai excel-pohjan kanssa. Lisähintaa tulee vielä paljon siitä, että työntekijöiden työteho laskee ja nurpiintuminen kasvaa, kun kaikista yrityksistä huolimatta raportinteko tyssää viimeisellä sivulla peruuttamattomasti esimerkiksi selittämättömään herjaan ”numero rivillä -6 ei ole arvo”. Kun keskushallinto moittii alaisia ohjelmavihamielisyydestä ja alaiset keskushallintoa nurjuudesta, taustalla voikin olla osin se että molemmat kärsivät huonoista ohjelmista mutta eivät voi vaikuttaa siihen tarpeeksi ja nyppivät sitten toisiaan. Hyvin valaiseva juttu! Sitten kun vielä oikeasti pystyisi vaikuttamaan niihin organisaation jäseniin jotka tekevät hankintapäätökset. (Nimim. pariin kertaan palautepalavereissa ollut.)
Usein on vielä niin että iso IT talot pystyvät painamaan tarjouskilpailuissa hinnat niin alas (lue: polkevat hintoja), jolloin moni ihan pätevä pienempi tarjoaja jää ulos kilvasta auttamatta. Sitten kas kas, kun projekti on voitettu, todelliset voitot kääritään a) bugien korjauksesta b) muutostöistä ja jatkokehityksetä. Ja näin hankkijaparka on IT talon armoilla vuosiksi eteen päin. Ja sama iso IT tarjoaja toistaa saman kuvion seuraavan hankkijan kohdalla, ja eikä vahingossakaan tehdä järjestelmiä jotka olisivat keskenään yhteensopiva. Niistä pitää maksaa erikseen, ja paljon.
On myös totta että ostopuolella on puuttellista osaamista. Valitettavan usein myös ostajan vastuuhenkilö(t) pelkää enemmän oman pallinsa puolesta eikä uskalla tehdä oikeita päätöksiä. Määrittely on monesti myös puuttelinen, eikä sen tekemiseen läheskään aina tarvita syvällistä IT-osaamista tms., ihan maalaisjärjellä pärjää yllättävän pitkälle.
Julkisella alalla joskus työskennelleenä ja nimenomaan tarjouspyyntöjen laatijana voin sanoa, että tarjousten tekijä on ollut joko äärimmäisen typerä tai muuten vaan osaamaton hommaansa. Tarjoukset tehdään pyyntöjen perusteella ja sitä saa mitä pyydetään. Jos et tarjouspyynnössä vaadi tiettyjen projektin osien kuuluvan koko sopimukseen, niin heikoilla ollaan, kun ongelmia esiintyy. Tarjous tulee tehdä ammattilaisen kanssa niin, että saat käsiisi täysin käyttövalmiin tuotteen ja juuri siihen hintaan, kun on luvattu eikä penniäkään yli. Jos hanke venyy toimittajan puolesta, se menee toimittajan ei tilaajan pussista. Vähän niinkuin ”avaimet käteen” -taloissa. Mitä järkeä on ostaa valmistalo jossa ei ole ovenkahvoja?
Yksityisellä sektorilla tarjouspyynnön tekijällä ei olisi kauaa työpaikkaa. Julkisella niitä suojasellaisia on joka projektiin oma ja ihan vierestä olen nähnyt miten tehotonta toimintaa se on. Ootellaan ja lähetellään samasta asiasta viikkotolkulla sähköpostia puolin ja toisin, kun sen asian olisi voinut hoitaa puhelimitse 10 minuutissa (paitsi että asiakas syö sinut puhelimitse, eikö?). Samalla projektin vetäjiä koulutetaan tyhjänpäiväisillä ja turhilla oppimispäivillä, kun tarjolla olisi valmistakin työvoimaa. ”No ei me voida, kun Matti on tehnyt näitä hommia 40 vuotta ja me luotetaan Mattiin” Valitettavasti Matin IT juna meni jo 10v sitten ohi. Toki onhan Matti saanut itselleen uuden älypuhelimen käyttöön työn puolesta, mutta ei halua opetella käyttämään sitä. ”Ei mun enää kannata, kun jään 2v. päästä eläkkeelle. Tää NMT on vielä ihan hyvä”. No, ei se haittaa. Matti on aina saanut hyvää palkkaa työn tuottavuudesta huolimatta, käytti sitten älypuhelinta tai NMT:tä.
Minusta ko. kirjoitusta on aika turha rajata vain yksityiselle sektorille. Sama problematiikka on kaikissa projekteissa.
Projektin tavoite/tehtävä on tuottaa sovitulla panoksella sovittu toiminnallisuus. Käytännössä tämä tarkoittaa alihankkijan kannalta sitä, että projektin tulee toteuttaa sovituilla resursseilla sovittu toiminnallisuus sillä tarkkuudella/laadulla, että se toimii takuuajan.
Takuuajan jälkeen, toimittaja on usein ainut joka sitä pystyy huoltamaan ja mitä enemmän toteutuksessa on kehitettävää, sen parempi.
Sisäisten IT osastojen omat softaprojektit usein ”onnistuvat” paremmin sen takia, että tekijät joutuvat itse myös ylläpito tehtäviin. Mukavuudenhaluiset koodarit tuota ylläpitoa yrittävät välttää, joten tekevät kerralla niin hyvää kuin osaavat. Samoin palaute ”bugeista” tulee organisaation sisältä suorempaan ja työkaverit osaavat kyllä henkilöidä ongelmat.
Toki sisäisesti toteutetuissa projekteissa aikataulut ja kustannukset saattavat venyä ja vanua – mutta laatu on usein parempaa. Ulkoinen toimittaja pitää kiinni kustannuksista ja huonostikirjoitetuista määrityksistä, toimituken laadun joustaessa.
Ehkä yksi iso parannuksen kohde näissä projekteissa olisi määritykset. Jos määritykset on kirjoitettu riittävän tarkasti, silloin toimittajan ongelma on osata laskea mitä sen toteuttaminen maksaa ja testaajallakin on tukevampi selkänoja mitävasten testata ja vaatia laatua.
Suomi maailman vähiten korruptoitunut maa….ihan varmasti joo!
Pitkään keskusteluketjuun pitää vielä jatkaa mikä minua ihmetytti kaikkein eniten asiakaspuolen projekteja tehdessä. Toimittajat kyllä korjaavat virheet sopimuksen mukaan jopa maksutta kun virhe todetaan, mutta minun kokemissani tilanteissa korjaamisen työmäärä oli keskimäärin puolikasta päivää kaikkine toimineen. Sen sijaan sen virheen kaivamiseen esiin ja taisteluun siitä että onko se virhe vai muutospyyntö joutuu asiakasorganisaatio sijoittamaan hyväksymistestauksen aikana keskimäärin miestyöviikon.
Epäsuhta on siinä, että toimittajat eivät itse testaa tavoilla joilla virheet löytyvät, ja virheen korjaaminen riittää – ei hyvityksiä virheen aiheuttamasta lisäinvestoinnista asiakkaalla. Etenkin kun korjauksen jälkeenhän asiakas saattaa aloittaa testauksensa joiltain osin alusta.
Onkohan sitten niin, että palataan kuitenkin ohjelmistokehityksen alkujuurille ja siellä testaukseen. Maaretin kirjoitus palautti joitain muistoja..
Olen käynyt auttamassa ohjelmistotaloja jotka ovat tehneet ohjelmistoja vuosia ja testauksen ovat hoitaneet koodaajat. Kun sitten on järjestetty asianmukainen testaus, niin ovat koodaritkin saaneet käyttää aikansa koodaamiseen testaamisen sijaan. Havaintojeni mukaan tuloksena on ollut parempaa koodia ja testaus on löytänyt laadukkaampia bugeja. Lisäksi testaus toimii yhteistyössä koodaajien kanssa ja kertoo esimerkiksi, että onko laite järkevästi käytettävissä ja niin edelleen.
Tässähän on ollut ihan selvästi ammattitaidoton tilaaja asialla. Toimittajathan ei maksa mistään mitään ylimääräistä ja jos aukkoja jää, niin TOTTAKAI ne käytetään hyväksi. Ei näitä töitä nyt ihan pilvin pimein tuolta julkiselta sektorilta ole tarjolla, että kun hyvä projekti eteen sattuu niin niistä pidetään kiinni kynsin hampain ja kaikki ”imetään” mitä vain mahdollista.
Tuo kirjoitus osoittaa jälleen kerran miten heikosti ohjelmistoalan osaajat ja tietysti asiakkaansa osaavat IT-alan teoriaa ja menetelmiäkään. He eivät kykene rakentamaan malleja kehittämistään systeemeistä ja siksi keskustelun taito puuttuu ja siksi testejäkään ei osata laatia. Lisäksi vanhemmat konkarit on potkittu yrityksistä pois – ne, joilla olisi ollut toimiala-asiantuntemustakin ymmärtää asiakkaitten bisnestä. Nuoret nörtit eivät ole siitä kiinnostuneitakaan. Ikärasismi siis vain pahentaa ohjelmistojen laatua.
Ihmisten kiinnostus IT-alaan hiipuu, jos siellä kovin paljon toheloidaan. Kuka kehtaa sanoa olevansa testaaja tai ohjelmoija?