Avainsana: Opiskelu

Monesti asiakkaan mielestä projektipäällikkö on firman tyhmin jätkä. Hän ei ole joustava, ei ota kuuleviin korviinsa uusia ehdotuksia ja on luotaantyöntävä. Miksihän näin on?

Yleensä asiakkaalta tulevat muutokset ovat pieniä muutoksia. Ainakin heidän omasta mielestään. Mitä muutoksen käsittely tarkoittaa projektille?

Ensinnäkin kutsuu paluu suunnittelupöydän ääreen. Pitää tarkistaa että uusi idea ei ole ristiriidoissa vanhojen kanssa. Seuraavaksi suunnitellaan toteutus ja aikataulutetaan se. Lopulta uusi idea toteutetaan ja testataan. Pitää tarkistaa, onko järjestelmä edelleen yhtenäinen ja vakaa. Jos näin on, on uusi idea saatu vietyä ohjelmistoon.

Samaan aikaan asiakas haluaa pitää kiinni alussa sovituista (IT-alalla todennäköisesti hyvin tiukoista) aikatauluista. Lisää rahaa ei haluta maksaa. Projektin myöhästymisestä sakotetaan. Samalla kuitenkin jo pelkkä ehdotus viivästyttää projektia. Projektipäällikkö joutuu asettamaan jonkun tutkimaan (tai tutkimaan itse), voidaanko uusi ominaisuus toteuttaa. Vaikka toteutukselle löytyisi este ja sitä ei toteutettaisi, aikaa on silti mennyt hukkaan.

Entä jos ajan säästämiseksi nopeutetaan hieman suunnittelua. Tehdään vanhojen ratkaisuiden pohjalta ja säästetään näin aikaa. Se saattaa oikeasti toimia ja ohjelmisto valmistuu aikataulussa sopimuksen mukaan. Jos kyseessä on asiakkaalle räätälöity ohjelmisto, on sopimukseen todennäköisesti kirjattu myös ylläpito. Ohjelmiston elinkaaressa ylläpitoon kohdistuvat kulut ovat noin 67% koko kuluista. Eli suurimman laskun asiakas saa ylläpidosta. Tätä ei yleensä käsitetä.

Ylläpitovaiheessa löydetyt virheet ja korjaukset maksavat 4-10 kertaa enemmän, kuin kehitysaikana tehdyt korjaukset tai parempi suunnittelu (yleensäkin ajan kulutus). Vertauskuvana voidaan pitää kerrostaloa, jonka alimman kerroksen seinät on rakennettu huonosti ja ne pitää uusia. Projekti tulee olemaan todella massiivinen.

Vaikka projektipäällikkö ennen kaikkea on huolissaan omasta projektista, niin hän silti pitää myös asiakkaan puolta. Kun ohjelmoija kirjoittaa hyvää ja ylläpidon kannalta mietittyä koodia, säästöt ylläpitopuolella kompensoivat mahdolliset menetykset kehitysaikana nopeasti.

Nyrkkisääntönä voidaan pitää, että mitä aikaisemmin ohjelmistokehitysprosessissa säästetään aikaa, sitä enemmän se lopulta maksaa. Esimerkkinä voidaan ottaa Denverin lentokentän matkatavarankäsittelyjärjestelmä, joka budjetoitiin olevan 200 miljoonan dollarin projekti. Laatujärjestelmän puuttuessa ja suunnitteluvirheiden takia projekti myöhästyi aikataulusta 16 kuukautta ja maksoi asiakkaalle 3 miljardia dollaria yli budjetin. Syyllisten haku on tietenkin vähän turhaa, mutta asiakkaan lisäksi ongelmia lienee aiheuttanut kehittymättömät ohjelmistotuotantoprosessit, suurien projektien hallinan vaikeus ja ehkä ihan yksilötasolla tehdyt virheet.

Vaikka tarinastani voisi saada sellaisen kuvan, että asiakas on softafirman pahin vastustaja, niin ei kuitenkaan ole. Ennen kaikkea peräänkuulutan myös asiakkaan ammattitaitoa. Jos kyseessä on edes hieman pikku projektia isompi, suosittelen lämpimästi ulkoisen avun käyttöä ohjelmiston tilaamisessa. Halvin tarjous ei ole välttämättä paras ja tiukimman työaika-arvion esittäjä ei välttämättä toteuta ratkaisua nopeiten. Konsultin palkkio on kuin karkkiraha siihen verrattuna, että joudutaan kuukausien ja kuukausien viivästyksiin.

! Teen kandityötä ohjelmistotuotantoprosessien soveltamisesta pienyrityksiin. Kirjoitan blogiin työhön liittyviä (mutta ei välttämättä kuuluvia) mietintöjä.

Englanninkieliselle termille affordance ei taida olla kunnollista suomenkielistä vastinetta. Se tarkoittaa kuitenkin jonkin, esimerkiksi esineen, ominaisuutta fyysisesti viestittää kuinka sitä käytetään. Otetaan esimerkiksi ovi. Siinä on kahva ja se viestittää meille, että sitä pitää kääntää, jotta ovi aukeaa. Sitä tarkoittaa affordance, suomeksi käännettynä varmaankin sitten affordanssi.

Käyttöliittymien ja käytettävyyden luennoilla luennoitsija on monta kertaa manannut VR:n laitteita käytettävyydeltään huonoiksi. Erityisesti käsinojaradio on saanut risuja.

Tänään huomasin sen itsekin. Sen lisäksi, että radiota ei yksinkertaisesti saa kuullokkeilleni tarpeeksi hiljaiselle, niin painikkeet ovat tunnottomat ja epätarkat. Mistään ei voi tietää, osuuko nappiin, sillä se ei painu. Mitään feedbackiä ei tule muuten kuin korviin. Ohjain myös bugittaa. Äänenvoimakkuuden pienentämistä yrittäessä minulla lähti kanavat juoksemaan. Lopulta hermostuin siihen, että kuulokkeeni soivat täysiä ja vaihdoin MP3-soittimeeni.

Creativen MuVossa affordanssi on kyllä kohdallaan. Muistan, että se sopi käteeni heti. Lähdin testaamaan heti paketista otettuani (ja ladattuani pari biisiä siihen) sitä lenkille ja vaihtelin kappaleita lenkin aikana käsi taskussa, ilman näkökontaktia, aivan kuin olisin käyttänyt laitetta aina. Se tuntui luonnolliselta ja loogiselta. En tiedä onko luomus vahinko vai tarkasti suunniteltu, mutta Creativelle täytyy nostaa hattua. Todella miellyttävä käyttää.