Ei vain koodia

Ohjelmoijan työ mielletään usein pelkäksi tietokoneen näpyttelyksi ja näyttöpäätteen ääressä istumiseksi. Sitä myöten ohjelmoijien ei ajatella tietävän tuon taivaallista ympäröivästä maailmasta. Menestyvän ohjelmoijan on kuitenkin ymmärrettävä maailmaa paljon laajemmin, kuin pelkän ohjelmakoodin kautta.

Tosiasia on, että ohjelmoijan päivät kuluvat suurimmaksi osaksi oman näyttöpäätteen ääressä ohjelmakoodia näpytellen. Ohjelmistokehittäjä joutuu kuitenkin tekemään jatkuvasti ratkaisuja tekemänsä ohjelman teknisestä rakenteesta ja monesti myös käyttäjälle näkyvästä käyttöliittymästä. Ratkaisunsa koodari tekee oman kokemuksensa ja tietämyksensä perusteella. Siksi on tärkeää, että ohjelmoija tuntee ohjelmistotekniikan lisäksi myös tulevan ohjelmiston tilaajan ja käyttäjän (jotka ovat varsin usein eri henkilöt) tarpeet. Lisäksi ohjelmoijan on tunnettava myös kaikki fyysisen maailman ohjelmalle asettamat rajoitteet.

Ajatellaanpa esimerkkinä vaikkapa lämpöpumpun etäohjausta. Ohjelmoijan ydintehtävä on tehdä ohjelma, jolla voidaan ohjata lämpöpumpun toimintaa. Ohjelmakoodin tuottaminen sujuu koodarilta mennen tullen, kunhan vain tietää mitä pitää koodata. Lämpöpumpun käyttäjän tärkein tavoite lienee riittävän lämpimän veden tuottaminen ja asunnon pitäminen sopivan lämpöisenä. Ohjelman tilaajana on mitä todennäköisimmin lämpöpumpun valmistaja tai maahantuoja, joka haluaa taata laitteen parhaan mahdollisen toiminnan ja pitkän käyttöiän.

Loppukäyttäjälle ohjelmoijan on toteutettava selkeä käyttöliittymä, josta käyttäjä voi asettaa halutun lämpötilan. Jotta lämpötila myös muuttuisi käyttäjän tekemien asetusten mukaan on ohjelmoijan kirjoitettava ohjelmakoodi, joka ohjaa joukkoa erilaisia venttiileitä, pumppuja ja kompressoreita ja muita laitteita. Tämä edellyttää jo hieman LVI-tekniikan ymmärtämistä. Jotta laite kestäisi mahdollisimman pitkään, on ohjelmoijan lisäksi huomioitava joukko erilaisia laitteen kuluvien osien rasitukseen liittyviä viiveitä ja varmistuksia ettei ohjelmakoodi vahingoita laitetta.

Ohjelmoinnissa menestyminen edellyttää siis  myös syvällistä ohjelmoitavan asian tuntemusta. Hyvä koodari käyttääkin paljon aikaa selvittääkseen mitä loppukäyttäjä ja ohjelman tilaaja tarvitsevat ja miten maailma tietokoneen ulkopuolella toimii. Harva koodari kun on koulutukseltaan esimerkiksi LVI-asentaja. Ohjelmoijan tärkeimpänä tiedon lähteenä onkin työn tilaaja, jolle ohjelmoija voi esittää tarkentavat kysymyksensä. Hyvän koodarin tunnistaa siitä, että hän kyselee paljon ja näin hankkii tietämystä siitä miten maailma toimii. Kun ohjelmoija kyselee paljon, ei se ole merkki siitä, että hän olisi tyhmä tai ettei hän ymmärtäisi asioita. Päin vastoin, tämä osoittaa, että ohjelmoija hankkii riittävästi tietoa tehdäkseen parhaan mahdollisen ohjelman.

Ohjelmointia ei kannata tehdä pelkästään ohjelmoinnin vuoksi vaan siksi, että ohjelman avulla ratkaistaan jokin olemassa oleva ongelma tai parannetaan toimintaa. Koodarin on ohjelmoinnin lisäksi hankittava asiantuntemus useilta eri toimialoilta voidakseen tehdä työnsä hyvin. Vaikka LVI-asentajan ammattitaitoa koodari tuskin saavuttaa ilman ammatillista koulutusta, on hänestä tultava ammatillinen moniosaaja.

Hyvä koodari pitää projektin budjetin kunnossa

Usein ajatellaan, että ohjelmoijan tehtävä on ohjelmoida ja asiakkaan vastuulle jää projektin suitsiminen siten, että projektin budjetti ei karkaa käsistä. Hyvä nörtti kuitenkin pitää huolta myös kustannusten pysymisestä aisoissa ja varmistaa, että ohjelmiston hankinta on asiakkaalle kannattava investointi tulevaisuuteen.

Tietojärjestelmäprojektien tarpeilla ja vaatimuksilla on tapana muuttua ja kehittyä projektin edetessä. Kun tietämys ja kokemus lisääntyy sekä tilaajalla että ohjelmoijalla, voidaan projektin kuluessa todeta, että alkuperäinen suunnitelma ei olekaan täydellinen. Tarve, jota uudella järjestelmällä lähdettiin täyttämään voi ollakin toissijainen, jonkin muun tarpeen ollessa merkittävästi tärkeämpi. Tiheät keskustelut tilaajan ja toimittajan kesken auttavat tekemään muutoksia suunnitelmiin ketterästi  kun tilanne niin vaatii.

Ohjelmoijan ja tilaajan välisen tiiviin yhteistyön merkitys näkyy myös budjetissa. Ohjelmoijan tehtävänä on pitää tilaaja jatkuvasti tietoisena eri ratkaisuvaihtoehtojen kustannusvaikutuksista. Hyvä ohjelmistotoimittaja uskaltaa kyseenalaistaa tilaajan toiveita. Tämä ei tarkoita sitä, etteikö asiakas olisi oikeassa. Koodarin tehtävänä on kuitenkin varmistaa, että hän on ratkaisemassa asiakkaan kannalta tärkeintä mahdollista ongelmaa.

14084-175

Olen ansainnut elantoni lähemmäs kahdenkymmenen vuoden ajan ohjelmistoprojektien parissa. Joskus projekti päällikkönä ja joskus ohjelmakoodia tuottavana koodarina. Kun muistelen vuosia taaksepäin, ei muistu mieleeni ainoatakaan projektia, missä järjestelmälle asetettavat vaatimukset eivät olisi muuttuneet tuotekehityksen aikana. Hyvin usein syy muutokselle on kaupan este. Asiakas (eli tietojärjestelmän tilaaja ja tuleva ylpeä omistaja) esittelee tulevaa järjestelmää omille asiakkuuksilleen (eli loppukäyttäjille)  jo tuotekehitysprojektin aikana ja pyrkii saamaan kaupaksi järjestelmään perustuvia palveluita.

Ostaisin teiltä tämän palvelun muuten, mutta sehän ei vielä tee asiaa X

Myyntitilanteissa loppukäyttäjät monesti huomauttavat järjestelmissä olevista puutteista, joita ei alunperin ole osattu ajatellakaan. Yleensä kommentit ovat muotoa: “Ostaisin teiltä tämän palvelun muuten, mutta sehän ei vielä tee asiaa X”. Koska ketterä kehitys mahdollistaa suunnitelmien muuttamisen kesken projektin voivat järjestelmän kehittäjä ja tilaaja sopia, että tällainen kaupan este poistetaan hetimiten, jotta projekti alkaa tuottamaan rahavirtoja tilaajalle mahdollisimman nopeasti.

Ohjelmistoratkaisuilla on käytännössä mahdollista tehdä lähes mitä tahansa, jolloin toiveita esitettäessä mopo karkaa joskus käsistä. Siksi on mahdollista, että epähuomiossa keskitytään tekemään toimenpiteitä, joiden takaisinmaksuaika on huomattavasti muita seikkoja pidempi. Kun tärkeimmät asiat hoidetaan ensin, varmistetaan, että järjestelmän toteuttaminen maksaa itsensä takaisin mahdollisimman nopeasti. Keskitytään niihin asioihin jotka tuovat tilaajalle rahaa pankkitilille mahdollisimman nopeasti.

Hyvä ohjelmistotoimittaja ajattelee aina asiakkaan etua ja sitä, mitä asiakas palvelusta saa. Yritystoiminnassa yleensä tärkeintä on se, mitä jää viivan alle. Kun ohjelmistotoimittaja ja tilaava rakentavat järjestelmää yhdessä, he myös menestyvät yhdessä. Asiakkaan etu on myös ohjelmistotoimittajan etu.

Puhe on halpaa – puhumattomuus kallista

Yleensä tietojärjestelmän tilaaja ei ole IT-alan ammattilainen eikä IT-alan ammattilainen tunne tilaajan liiketoimintaa. Jotta asiakas saisi sellaisen ohjelmiston kuin haluaa, on yhteistyön tilaajan ja ohjelmoijien välillä oltava saumatonta. Talk is cheap sanoo amerikkalainen. Saumattoman yhteistyön ytimessä on avoin keskustelu. Ilman toimivaa viestintää projekti menee auttamattomasti pieleen.

Tietojärjestelmäprojektit ovat usein otsikoissa valtavien viivästymisten, budjettiylitysten ja huonon toiminnallisuuden seurauksena. Maailmalla vallitsee käsitys, että tietojärjestelmähankkeet epäonnistuvat useammin kuin onnistuvat. Kun sekä järjestelmän tilaaja ja toimittaja ymmärtävät toisiaan ja toteuttavat järjestelmän yhdessä, on odotettavissa onnistunut projekti ja hyvä lopputulos.

Yhdessä tekemisen ytimessä on jatkuva viestintä. Tietojärjestelmän tilaajan ei tarvitse olla IT-alan ammattilainen, hänen tehtävänään on kuvata ohjelmoijille oman liiketoimintansa tavoitteet ja tarpeet mitkä ohjelmoijien tulisi ratkaista. Vastaavasti ohjelmoijien tulee kysyä riittävästi kysymyksiä tilaajalta, jotta he voivat käyttää omaa asiantuntemustaan tilaajan ongelman ratkaisemiseksi. Taloushallinnon ohjelmistoa tehtäessä nörteistä tuskin koskaan tulee kirjanpitäjiä, mutta kirjanpitäjän on opetettava koodarille perusasiat.

Vuosia sitten olin mukana projektissa, jossa tehtiin kirjanpidon järjestelmää. Tilaaja puhui luontevasti siitä, miten rahaa siirretään esimerkiksi velkatililtä myyntitilille. Tilien määrärästä hämmentyneenä kysyin miten monta pankkitiliä yrityksellä oikeastaan oli. Vastaus oli yksi. Entisestään hämmentyneenä ihmettelin mistä velkatileistä ja myyntitileistä oikeastaan oli kyse jos pankkitilejä oli vain yksi. Selvisihän siinä yleensä kun kirjanpitäjä puhuu tilistä hän tarkoittaa kirjanpidon tiliä mikä on täysin eri asia kun pankkitili. Siitä se sitten lähti – nörtin kirjanpidon opiskelu.