Hankintalaki on tekosyy – 7 neuvoa päättäjälle

Kun ostaa sian säkissä, se ei ole hankintalain vika – vaikka julkishallinnon puolella sen taakse helposti piiloudutaan. Turhan harva tietää, ettei hankintalaki estä tekemästä hyvää ostosta. Julkishallinnossa hankitaan jatkuvasti laajoja järjestelmiä kohtuukustannuksilla ja loistavalla laadulla.

Se mikä ei julkisella puolella onnistu, on jättihankkeen nopea läpivienti. Jonkun on pitänyt käynnistää hankinta jopa vuosia ennen kuin uutta järjestelmää tarvitaan, jottei projekti menisi mönkään.

Hankintalaki, huolellinen tarveanalyysi, kilpailutus ja hankkeen läpivienti vaativat julkisella sektorilla jokainen enemmän aikaa ja taitoa kuin vastaavan hankkeen läpivienti yksityisellä puolella.

Alla 7 neuvoani päättäjälle


1. Eriytä valmisteluvaihe.
Kaikkein vaikeinta tuntuu olevan se, että hankinnan ja määrittelyn pitää olla täysin erillään toisistaan. Ei riitä, että valitsee parhaan tuotteen tai palvelun tarjotuista, vaan valinnan kriteerit on pitänyt asettaa jo ennen hankinnan läpivientiä. Tilanne on joskus yhtä koominen, kuin aviopuolison lähettäminen hänelle vieraaseen kauppaan. Tarkimmatkaan ohjeet eivät riitä ja oivariinin ja ruokakerman sijaan kassista löytyy helposti pari senttiä halvempaa tarjousvoita ja kahvikermaa.

2. Kehitä osto-osaamista. Käytännössä hankintoja pitää tehdä jatkuvasti ja tarkasti, jotta hankintataidot kehittyvät ja säilyvät. Isojen hankintojen ammattilainen on kuin kirurgi, joka tarvitsee kokonaisen yliopistollisen sairaalan potilasmassan, jotta käsi pysyy vakaana. Monessa organisaatiossa ei yksinkertaisesti ole riittävästi isoja hankintoja ammattitaidon kehittämiseksi ja säilyttämiseksi.

3. Resursoi riittävällä tasolla. Jatkuvien hankintojen parhaille ammattilaisille on tarjolla töitä kosolti sekä julkisella että yksityisellä puolella. Haasteena on se, että vain harva julkisen puolen organisaatio on perustanut virkoja, joiden palkkaus vastaa työn vaativuutta. Vielä harvempi aloittaa työt riittävän aikaisin, jotta välttyisi paniikilta ja ‘veren maku suussa’ -vaiheilta.

4. Maalaa visio ja polku ymmärrettävästi. Hankinnasta on vaikeaa saada poliittinen päätös tilanteessa, jossa nykyinen ratkaisu tuntuu olevan vielä ihan käyttökelpoinen. Poliittinen päättäjä on harvoin toimialan ammattilainen ja sellaisten päätösten teko, joista ei ole näkyvää hyötyä nykyisellä vaalikaudella vaatii lujaa poliittista selkärankaa.

5. Aloita ajoissa. Kiusallisen vaikeaksi ajoissa hankinnan aloittamisen tekee valmistelevan työn näennäinen helppous…jonkun on tutustuttava toimittajiin, alalla tyypillisiin ratkaisuihin, sopimusmalleihin, käyttöönottojen vaikeuksiin ja sudenkuoppiin. Etäisen johtajan voi olla vaikea erottaa toisistaan lahjakasta markkinan ja omien tarpeiden selvittäjää messuilla käyvästä laiskottelijasta.

6. Valaise päätöksentekoa. Monessa virastossa on helpompi saada miljoonabudjetti hankkeelle, jonka luullaan olevan helppo, sillä sitä ei ole riittävästi tutkittu, kuin sellaiselle, jonka tunnetut vaikeudet ja sudenkuopat on selvitetty, dokumentoitu ja selätetty hyvällä hankintatavalla. Jälkimmäisessä joudutaan dokumentoimaan riskit, edellisessä päätös voidaan tehdä kuin riskejä ei olisikaan.

Tätä projektien fiksun hankinnan teemaa sanoittaa myös mainio Helsingin Sanomien juttu, lue ex-nokialaisen psykologin Ari-Pekka Skarpin haastattelu.

7. Suosi ketterää. Ari-Pekka Skarp ehdottaa pilkkomaan hankkeen ketterän metodologian mukaisesti ja niin ehdotamme mekin Codentossa. Kaupunki rakennetaan talo kerrallaan ja laaja systeemi niin, että jokaisen laajennuksen jälkeen on toimiva, entistä parempi systeemi. Lähes kaikki suuret tietojärjestelmien kertahankinnat voidaan palastella sarjaksi pienempiä ja samalla riskittömämpiä hankintoja.

Eikä tässä vielä kaikki, alla muutama nämä seitsemän neuvoa koostavaa vinkkiä, eräänlainen hankinnan litmustesti:

+1. Bonusneuvo “vendor-lock-in”. Monimutkaisten palvelujen hankinta on aina vaikeaa. Tee kaikkesi, että voit vaihtaa toimittajaa kesken hankkeen ilman suurempia kustannuksia tai myöhästymisiä. Tämä “jos et käyttäydy kunnolla, en leiki kanssasi” on parasta mitä julkisessa hankinnassa voi omalle toteutustiimille hankinnan aikana antaa.

+2. Bonusneuvo “nuukailu”. Jos pisteytyskriteerit jättävät hankintahinnalle suurimman painoarvon, et todennäköisesti ole ymmärtänyt, mitä kollegasi järjestelmällä aikovat tehdä. Jos painotat hankintahintaa samalla itseasiassa väheksyt hyötyjä ja tulet helposti valinneeksi järjestelmän, josta on vähiten hyötyä. Sekä hinnalla että laadulla on hankinnassa merkitystä, kallein ei välttämättä ole paras. Hankintahinnan painotus johtaa helposti siihen, että todellinen hankintakustannus on moninkertainen hankintahintaan nähden, koska minimisetti ei sittenkään riittänyt työnne tekemiseen.

Petri Aukia
Twitter @aukia

#hankintalaki #julkishallinto #osto-osaaminen #ketteryys #lean #johtaminen #länsimetro 

Onko sinulla softaprojektissasi kiltti vai rötväke tuoteomistaja?

Organisaatiomme toimivat aika hyvin silloin, kun tehdään tuttua jo moneen kertaan tehtyä uudestaan ja uudestaan. Ruotsinlaivat ovat useimmiten ajallaan perillä ja matkalla uskomattoman monimutkaiset ravintola- ja hotelliprosessit toimivat varsin luotettavasti. Kaikki on tehty jo kymmeniä tuhansia kertoja ja tämä näkyy suorituksen eleettömässä varmuudessa.

Ketteriä menetelmiä käytetään lähes poikkeuksetta silloin, kun organisaatio tekee jotain ihan uutta. Esimerkiksi sellaista ohjelmistoa, jota ei koskaan ennen ole tehty tai markkinoinnissa isoa ponnistusta, jota ei ennen ole yritetty.

Ketterät menetelmät tuovat tähän luovaan kaaokseen järjestystä, rauhaa ja riskienhallintaa. Työt sovitaan siten, että kokonaisuudesta saa selvän kuvan missä vaiheessa tahansa. Pitkän yksin puurtamisen sijaan suositaan lyhyissä pätkissä työskentelyä, jotta varmistetaan se, että ollaan matkalla kohti oikeaa maalia.

Ketteryydessä vaikeinta on ketteryyden säilyttäminen 

Kaikki olisikin hyvin, ellei ketterät hankkeet useimmiten toimisi budjettiorganisaatioissa, joissa ollaan totuttu toistettaviin suorituksiin. Ketterän hankkeen voi olla vaikea saada rahoitusta, elleivät suunnitelmat ole tarkkaan kuvattuja sekä työmäärän että budjetin osalta. Haasteena tässä mallissa on asettaa nämä oikein, sillä esimerkiksi tiimin jäsenten sairaslomia flunssakaudella ei voi etukäteen tarkasti ennustaa.

Mikäs siinä – näinhän kaikki muutkin toimivat meillä, sanoo iso pomo. Ja haasteita on luvassa. Tuoteomistajan kärsivällisyyttä koetellaan monin tavoin. Tuoteomistajan ottamalla roolilla on merkitystä.

Kiltti tuoteomistaja

Paradoksaalisesti isossa organisaatiossa ketteryys toimii paremmin rötväkkeiden kuin kilttien käsissä. Kiltit – budjetista ja ominaisuuksista tiukkaan kiinni pitävät – tuoteomistajat keskittyvät siihen miten raha saadaan riittämään tarkalleen sovittujen ominaisuuksien tekoon matkan varrella sattuneista vastoinkäymisistä huolimatta.

Tällä mallilla tekeminen on valtavan stressaavaa, eikä tässä saada ketteryydestä mitään hyötyä. Kun kaikki on jo etukäteen lyöty lukkoon on koko ketterä koneisto kuin keisarin uudet vaatteet. Kiltti tuoteomistaja keskittyy tiimin valvontaan ja paijaamiseen, ja työaika käytetään tiukasti omalla konttorilla, koska budjettiylityksen riski on aina käsin kosketeltavissa.

Rötväke tuoteomistaja

Urastaan vähät välittävä rötväke keskittyy hankkeen todelliseen tavoitteeseen: maailman myyvimpään käyttöliittymään tai mikä kulloinkin on hankkeen todellinen tarkoitus. Kunnon rohkea rötväke osaa löytää ohjelmistoprojektin ominaisuuslistoista ne, joita ilman tuotetta ei synny, ja käyttää koko loppuominaisuusjoukon budjetin siihen, että projekti varmasti tuottaa käyttäjille juuri sen, mitä lähdettiin metsästämään.

Rötväkkeen on tavattava valtava määrä potentiaalisia asiakkaita ja käyttäjiä projektin ajan. Hän ei voi viettää koko viikkoa toimistolla vaan fokuksessa on yrittää löytää se, mikä onnistuessaan antaa anteeksi puuttuvat ominaisuudet.

Siinä missä kiltti tuoteomistaja tietää aina, mitä vielä pitää tehdä, rötväkkeelle hankkeen alussa loppupuolen ominaisuudet ovat helposti hämärän peitossa. Kiltisti vedetyssä projektissa ensimmäinen käyttöliittymä on usein riittävän hyvä. Vastaavasti rötväkkeelle riittää vasta se, joka todella saa käyttäjät haluamaan sitä mitä ollaan tekemässä.

Rötväke muuttaa ketterän käsissään leaniksi, oli siihen lupa tai ei.

Toimi näin, iso pomo

Älä pakota kilttejä tuoteomistajiasi väärään laatikkoon, pomo. Äläkä oleta, että kiltteys tai rötväkkyys olisi sukupuoleen sidottu ominaisuus.

Ketterä hanke, jonka koko budjetti menee niiden ominaisuuksien tekoon, joista on sovittu, on yksinkertaisesti väärin budjetoitu. Ja syy hankkeen korkealle riskitasolle on sinun väärässä budjetointitavassasi.

Jos rahaa ei ole, pakota kaikki miettimään, miten voisitte vähemmillä ominaisuuksilla varmistaa ratkaisun toimivuuden käytännössä. Apua löytyy kyllä kun ymmärrät, että tässä mallissa budjetointi pakottaa muut seiskan laatuun, tavoitellun kiitettävän sijaan.

Ketterät kehitystiimit kaipaavat lean-maailmasta inspiroitunutta johtajaa.

Lukusuositus: kollegani Karoliina Luodon laatima Tuoteomistajan Scrum-pikaopas.

Petri Aukia
Twitter @aukia

#tuoteomistaja #ketterä #ketteryys #postketterä #postagile #lean #scrum #ithanke

Hyvää, halvalla ja nopeasti – valitse kaikki kolme

“Hyvää, halvalla, nopeasti – valitse kaksi kolmesta” viittaa milloin projektin läpivientiin, milloin palvelun toimittamiseen. Äkkiseltään tämä synteesi näyttäisi pitävän paikkansa.

  • Hyvää ja halvalla näyttäisi tarkoittavan, että elanto joudutaan hankkimaan muualta ja tätä hanketta edistetään vain sellaisissa väleissä, kun ei ole muuta tekemistä. Asiakas saa tilauksensa halvalla, mutta joutuu odottamaan.
  • Halvalla ja nopeasti tarkoittanee, että palvelua tai tuotetta ei ehditä suunnittelemaan asiakaskohtaisesti. Jos asiakas ei saa mitä hän haluaa, laatu koetaan heikkona.
  • Nopeasti ja hyvää tarkoittaa usein, että joudutaan keskittymään vain tähän tilaukseen ja muut asiakkaat odottavat. Näin vain yksi asiakas kerrallaan vastaa operoinnin kustannuksista, jolloin hinta on helposti korkea.

Edellä kuvatuissa tilanteissa keskitytään ajattelemaan työntekijää kustannuksena. Ajatellaan, että suurempi määrä työntekijöitä kasvattaa kuluja ja nopeuttaa työn tekemistä. Jos kokonaisuutta katsotaan toisen paradigman kautta, tilanne on erilainen.

Nopea on halpa

Palvelun tuottamisen kustannus määrittelee sitä hintaa, jolla palvelua voi kannattavasti myydä. Se, mitä asiakas arvostaa vaikuttaa taas siihen, miten paljon asiakas on palvelusta valmis maksamaan.

Vaikuttaa siis siltä, että on tärkeää ymmärtää mitä asiakas haluaa. Ja toisaalta asiakkaan haluama palvelu kannattaa myös tuottaa kustannustehokkaasti. Prosessisyklin tehokkuus (PCE) on tunnusluku, joka lasketaan juuri näitä tietoja käyttäen. PCE on prosessissa asiakkaalle arvoa tuova aika jaettuna prosessin läpimenoajalla.

Palvelun tuottamisen kustannus per tuotettu palvelu laskee prosessin tehokkuuden kasvaessa. Tämä vaikutus voidaan siirtää palvelun hinnoitteluun.

Prosessitehokkuuden kasvusta seuraa kaksi asiaa. Palvelun tuottaminen nopeutuu ja sen hinta vähenee. Mutta miten tehokkuutta sitten voi parantaa?

On mahdollista muuttaa osa asiakkaalle arvoa tuomattomasta tekemisestä sellaiseksi, että asiakas kokee saavansa siitä arvoa. Esimerkiksi jotkin huvipuistot ovat pyrkineet muuttamaan jonotusaikaa hukasta hyödyksi rakentamalla varsinaisen huvituksen ympärille laajemman tarinan, jonka jonottaja saattaa kokea, jos ei hyödylliseksi, niin ainakin vähemmän pahaksi kuin jonotuksen. Joissain tilanteissa tällainen asiakaskokemuksen muuttaminen voi onnistua, mutta kokonaisaika ei vähene.

Asiakkaan kokemukseen vaikuttamista helpompi reitti prosessitehokkuuden lisäämiseen on tunnistaa niitä asioita, joista asiakas ei ole valmis maksamaan ja poistaa näitä systemaattisesti. Tunnistetaan ja poistetaan tekemisestä mm. jonoja, eräprosessointia, uudelleen työstöä ja virheitä. Hukkaa poistamalla päästään  suurempiin parannuksiin kuin tekemisen nopeutta lisäämällä.

Entä miten saada hyvää laatua?

Laadulla voidaan tarkoittaa esimerkiksi sitä, että toteutetaan asiakkaalle juuri niin hyvä tuote tai palvelu, kuin on suunniteltu. Ja ollaan valmiita kehittämään palvelua asiakkaiden palautteeseen perustuen.

Suunnitellusta poikkeamisen eli variaation vaikutukset pysyvät useimmiten aisoissa silloin, kun on aikaa tehdä, tarkistaa ja korjata. Mutta tämä on ristiriidassa “nopeasti” tavoitteen kanssa.

Mitä enemmän variaatiota tekemisessä on ja mitä korkeampi on prosessin käyttöaste, sen hitaammin prosessi on kyvykäs tuottamaan palvelua.

Saatetaan ajatella, että työntekijöistä aiheutuvia kuluja vähentämällä säästetään ja että kannattaa pitää käyttöaste korkealla, kun kerran joka tapauksessa maksamme resursseista. Tämä lähestyminen kuitenkin hidastaa prosessin läpimenoa, eli heikentää prosessin tehokkuutta, eli kasvattaa hintaa per tuotettu palvelu.

Resurssien käyttöasteen maksimoinnin sijaan kannattaa vähentää variaatiota ja keskittyä prosessitehokkuuden kasvattamiseen. Tämä mahdollistaa nopean, halvan ja laadukkaan palvelun.

Resepti: hyvää, halvalla ja nopeasti

  1. Kuvaa prosessi tarvittavalla tarkkuudella, arvovirtakartta on hyvä tapa.
  2. Tunnista asiakasarvo ja selvitä prosessin tehokkuus lähtötilanteessa.
  3. Aseta haastavat, mutta saavutettavissa olevat tavoitteet kehittämiselle.
  4. Käytä lean menetelmiä turhan poistamiseksi ja tarvittavan nopeuttamiseksi.
  5. Mieti, mitä variaatio tarkoittaa organisaatiosi prosesseissa ja vähennä sitä systemaattisesti.

Tuoteomistaja, ahdistaako ketterä kehitys?

Ketterät kehitysmenetelmät ratkovat tehokkaasti kehitystiimin pulmia, mutta eivät juuri auta tuoteomistajan haasteissa. Sen sijaan ne ovat monien tuoteomistajan kohtaamien ongelmien juurisyy. Ongelmien ratkaisu vaatii muita menetelmiä.

Ketterällä mallilla lähdettiin ratkomaan kolmea pulmaa:

  1. Kehittäjien työ on tehokkaampaa, kun työtä ei koko ajan häiritä.
  2. Liiallinen dokumentaatio ei itse asiassa olekaan välttämätöntä.
  3. Softaprojekti, joka on luovittavissa oikeaan suuntaan, on parempi kuin vuoksiksi raiteille tiukasti sidottu etenemistapa.

Ketterä kehitys, ketteryys, on ollut kuluneen vuosikymmenen megatrendi ohjelmistokehityksessä ja se on korvannut monessa hankkeessa totutun toimintatavan, vesiputousmallin. Uudelle tavalle toimia keksittiin iteratiivista kehitystä hienompi konteksti ja termit – ja sanastoomme ilmestyivät ketteryys, ketterä ja agile. Ketterä kehitys löi läpi koko ICT-alan ja nykyisin ketterää ohjelmistokehitystä tehdään Suomessa valtavirtana pelifirmoista pankkisoftaan saakka.

Miten tuoteomistaja hyötyy ketterästä?

Valitettavasti ketterä kehitys jätti softahanketta vetävän johtajan tai tuoteomistajan leikin, riemun ja uusien ratkaisujen ulkokehälle. Ennen vastuuroolissa oli kuukausia aikaa miettiä mitä tarvitaan ja miten saadaan kaikkien hyväksyntä jokaisen vaiheen sisällölle. Nyt vastuunkantaja joutuu kahden viikon välein yksin taistelemaan projektin puolesta tuulimyllyjä vastaan. Se ei useinkaan ole se voittava arpa.

Kun päätettäviä asioita on käsillä kahden viikon välein, vaatii malli tuekseen selkeän päätöksentekotavan. Näin usein ei ole aikaa miettiä kaikkea alusta asti vaan tarvitaan roteva selkäranka, jonka varassa saa nopeasti tehtyä hyviä päätöksiä.

Selkärankana ei toimi pelkkä hähmäinen visio eikä sellaista ehdi jokaista hanketta varten tyhjästä rakentaakaan. Parempaa tekemistä löytyy aina. Post-ketteryys edellyttää valmismallia, joka soveltuu organisaation tulevaisuuden kannalta kriittisimpään päätöksentekoon.

Post-ketteryys = lean + ketterä

Olen käyttänyt lean-maailmasta tuttuja lähestymistapoja ketterien kehityshankkeiden tukemiseen nyt parisen vuotta ja kokemukseni on, että lähestymistapa on lähes kaikissa tapauksissa nappivalinta.

Lean-maailman Toyotat ja Four Seasons -hotellit ovat lähteneet ratkomaan samaa pulmaa kuin ketterä tuoteomistaja: “miten palveluamme tai tuotettamme kannattaisi parantaa, jotta kauppa kävisi paremmin?”

Hyvä tuoteomistaja tai liiketoiminnan kehittäjä: et varmaankaan ole ensimmäistä kertaa tämän kimurantin pulman edessä – valmiita ratkaisuja löytyy, samoin kirjallisuutta, konsultteja ja parhaita käytäntöjä. Älä jää yksin kääntelemään backlogia talikolla, vaan etsi avuksesi lean-maailman voittavia ratkaisuja. Post-ketteryys on täällä.

Lukusuositus: kollegani Karoliina Luodon laatima Tuoteomistajan Scrum-pikaopas.

Petri Aukia
Twitter @aukia

#tuoteomistaja #ketterä #ketteryys #postketterä #postagile #lean #scrum #ithanke

***

Kuva: Flickr CC / Stewart Black 

Projektin ei tarvitse olla painajainen

Lähes jokainen voi hyvällä omallatunnolla sanoa olleensa mukana projektissa tavalla tai toisella. Ja ihan liian iso osa on kokenut myös projektityöhön liittyvää epäselvyyttä, aikataulupaineita ja projektiriippuvuuksien tuskaa, mistä syystä pahimmillaan projektista on tullut sallittu synonyymi painajaiselle. Projektin onnistumisen kannalta on tärkeää, että tavoite ja sen tekemiseksi tarvittavat resurssit ja aikataulu on ymmärretty oikein. Ketterien menetelmien käyttö puolestaan lyhentää palautesykliä ja mahdollistaa dynaamiset muutokset aikataulussa, tavoitteissa ja resursseissa.

Ohjelmistoprojektien monimutkaisuudesta

Neutraalisti katsottuna projekti on kokonaisuus, jolle on määritelty ajallinen alku, loppu ja selkeä päämäärä sekä tekijät, joilla päämäärä on saavutettavissa. Varsinkin isomman kokoluokan projekteissa kompleksisuutta lisäävät erilaiset riippuvuudet.

Ohjelmistopuolella kompleksisuus johtuu usein myös systeemien monimutkaisuudesta, olemassa olevan ympäristön perintönä saadusta vanhentuneesta koodista tai pysyvästi sementoiduista taaksepäin yhteensopivuus -vaatimuksista. Tai kun on otettu teknistä velkaa jättämällä koodin siivous kiireessä sivuun.

Ohjelmistoprojektien haasteet harvoin tekijöiden syytä

Harvoin ohjelmistoprojektien ongelmat liittyvät kuitenkaan tekijäporukkaan, joka yleensä koostuu asiantuntijoista ja alansa ammattilaisista. Heillä on tarvittava osaaminen ja halu oppia, joilla taklataan kiukkuisimmatkin riippuvuudet tai tekniset haasteet. He osaavat myös määrittää järkevät etenemisvaihtoehdot, kun törmätään isompaan siirtokivilohkareeseen.

Mikä ohjelmistoprojekteissa sitten mättää?

Mikä ohjelmistoprojekteista sitten tekee niin kiharaisia? Ja miksi asiakkaat saavat eteensä järjestelmiä tai käyttöliittymiä ymmärryksen tuolta puolen? Vastauksia lienee yhtä monta kuin on tuuliajolle menneitä projektejakin. Usein taustalla kuitenkin kytee tekemisen jäykkyys tai joku seuraavista perustavaa laatua olevista projektihelmasynneistä – perinteisen projektikolmion kautta katseltuna:

Puhun mielelläni ohjelmistokehityksessä ihmisistä resurssien sijaan ihan vaan siksi, että ihmiset ne käytännössä toteuttavat ohjelmistojen toiminnallisuudet. Muu resursointi tulee yleensä laiteinvestointien, jne. puolesta ja näillä katetaan pidemmän aikavälin tarpeita.

1. Epäselvä tai epärealistinen tavoite

Selkeys siitä, mitä on tarkoitus saada aikaiseksi näyttelee isoa roolia projektin onnistumisessa. Harmittavan usein (sisäinen/ulkoinen) asiakas tai arkkitehti lähtee harhailemaan tontiltaan ja päätyy kuvaamaan sitä, miten hänen haluamansa asia toteutetaan, kun se mitä oikeasti tarvittaisiin, olisi selkeä tarpeen kuvaus. Kehittäjät kyllä keksivät järkevimmän toteutustavan, kunhan heille kerrotaan mitä halutaan ja miksi. Speksailu vailla vastuuta kokonaisjärjestelmän toimivuudesta on tietysti jännää, mutta useimmiten se hidastaa ja hankaloittaa kehitystiimien työtä –  heille kun olennaisinta olisi saada ymmärrys siitä, mitä halutaan. Näennäisen valmiin ratkaisun ojentaminen kehittäjille alentaa heidät samalla puhtaiksi koodikirjureiksi, mikä myös syö tekijöiden motivaatiota.

Ajan käyttäminen siihen, että pystyy kertomaan selkeästi mikä on ratkaistava ongelma, missä asiayhteydessä ongelma esiintyy ja millainen vaikutus sillä on asiakkaan elämään on tärkein panostus, jonka tilaajapuoli voi kehitystyölle antaa. Lopusta huolehtivat asiansa osaavat ja systeemiä ylpeydellä ylläpitävät koodarit.

2. Riittämättömät resurssit tavoitteen saavuttamiseksi

Eli keksitään se Hillittömän Hieno Juttu, joka tarttis tehdä ja mielellään heti. Sitten ei kuitenkaan olla valmiita valitsemaan niitä asioita, mitä sitten jätetään tekemättä tai miettimään, mikä oikeasti on paras taho toteuttamaan haluttu toiminnallisuus ja mitä nämä tiimit parhaillaan tekevät. Tai kieltäydytään kuulemasta toteuttajien arviota siitä, millaisella työpanoksella toiminnallisuus on tehtävissä.

Taas kerran tullaan siis takaisin siihen, että pitäisi olla kyky ja halu miettiä, mikä nyt olikaan tekemisen tärkeysjärjestys ja mihin rahkeet riittävät. Tai pohtia, mitä se tarkoittaa, kun järjestelmään lähdetään lisäämään toiminnallisuutta ns. sankaritöinä. Valmis toiminnallisuus pitäisi kuitenkin nähdä myös ylläpidon, skaalautuvuuden, suorituskyvyn ja jatkokehityksen, jne. vinkkelistä. Puoliksi tai sinnepäin tehdyt toiminnallisuudet ja järjestelmät ovat ne kalleimmat toteutuksen puolesta, oli tekijä sitten omasta talosta haalittu iskujoukko tai ulkoinen konsultti.

Ohjelmistoprojektit harvoin onnistuvat sillä, että liiketoimintapuolen Excel saadaan näyttämään rivit nätisti. Ihmisten osaamisen taso, oppimiskäyrä tai vaikkapa koodaamisen nopeus eivät ole vakioita ja riippuvat paljolti esim. käytettävien teknologioiden tai kielten tuttuudesta. Kehittäjätkin ovat ihmisiä, joilla on oma työn ulkopuolinen elämä (vaikka legenda toisin väittääkin). Heillä on yhtä lailla perheitä, koiria, lomia ja tarpeita hoitaa ne samat pankkiasiat kuin tilaajillakin. Tällaiset pitää huomioida, kun mietitään missä ajassa lopputulos voi realistisesti valmistua.

3. Epärealistinen aikataulu

Yllämainittujen lisäksi projektin onnistumiseen voi helposti vaikuttaa asettamalla aikataulun, jossa on mahdotonta pysyä ottaen huomioon asetetut (epäselvät/ristiriitaiset) tavoitteet ja (puuttuvat) kehittäjät.

Epäonnistumista voi pedata sillä, että ei kysytä asiantuntijoilta, mitä toiminnallisuuden toteuttaminen aidosti vaatii ja neuvotella sen jälkeen riittävästä toteutuksen tasosta – aikataulu, haluttu laatutaso ja tekijöiden saatavuus huomioiden. Kun luullaan, että yhden valintaruudun toteutus hoituu yhtä sukkelaan kuin designerin  flash-animaationa toteuttama näkymä, vaikka taustajärjestelmiin saman toteuttaminen myös niiden ei-toivottujen käyttäjätarinoiden (ns. rainy day -skenaariot) ja lokituksen & auditoinnin kanssa on huomattavasti työläämpää. Ja näitähän tehdään, jotta käyttäjiä voidaan jatkossa myös tukea. Tästähän ei se flash-animaatio kerro mitään.

Lue lisää Pimeän agilen välttämisestä.

Ketterä toteutus kokonaisuudessaan edullisempi

Valittu tapa tehdä ohjelmistoprojekti on kunkin organisaation päätettävissä. Itse olen paketoinut projekteja sekä vesiputousmallilla että ketterillä menetelmillä, eikä menetelmä itsessään ole kynnyskysymys.

Jos valita saan, hoidan projektini ketterästi. En siksi, että se olisi jollain tapaa viileämpää jutella ketterästi Scrumia tai Kanbania, vaan siksi, että ketterä toteutustapa mahdollistaa käyttäjää paremmin palvelevan ja kokonaiskuvassa edullisemmaksi tulevan toteutuksen.

Nopeat muutokset, joita väistämättä tulee, ovat mahdollisia niin tavoitteissa, budjetoinnissa kuin aikataulussa – maailma harvoin pysähtyy odottamaan, että juuri minun edellisenä vuonna kerran määrittelemäni projekti valmistuu seuraavaksi jouluksi muuttumattomana.

Kullankallis käyttäjäpalaute

Mitä nopeammin aidot käyttäjät pääsevät testaamaan ominaisuuksia, sitä nopeammin saadaan palautetta kehitystyöhön sekä korjauksia takaisin ominaisuuksiin. Pienilläkin muutoksilla on toisinaan ratkaiseva merkitys käyttäjän kannalta – ketterässä kehityksessä nopea palautesykli ja jatkuva parantaminen kuuluvat tekemisen luonteeseen.

Minusta projekteja on aina ollut hauskaa tehdä, kiitos ässien kehitystiimien ja arvokkaan asiakaspalautteen. Projektit rullaavat varsinkin, jos ne on valmisteltu huomioiden kolme kulmakiveä:

  1. tavoite
  2. ihmiset + mahdolliset muut resurssit
  3. aikataulu.

Kaikki muu on sen jälkeen pienempää ratkottavaa.