Sähköinen resepti. Potilastietojärjestelmä. Sähköisen äänestyksen kokeilu. Presidentti Obaman sairausvakuutusuudistus. VR:n matkalippujen myyntisovellus. Esimerkkejä epäonnistuneista ohjelmankehitysprojekteista on helppo poimia otsikoista. Mutta julkisuus on vain jäävuoren huippu. Yksityisellä puolella epäonnistuneet hankkeet haudataan talon sisällä, harvoin niitä lähdetään repostelemaan mediassa.
Ja isojakin ruumiita tulee. Ohjelmisto-ongelmat kaatoivat Nokian matkapuhelinliiketoiminnan. Nokian mukaan he eivät älynneet olla ohjelmatalo. Väite on naurettava. Nokian käyttöjärjestelmätiimi oli kymmenen kertaa isompi kuin se porukka, joka ohjelmoi Androidin Samsungin puhelimiin.
Mikä insinöörejä
riivaa? Miksei ohjelmia osata tehdä - vai onko vika
projektinhallinnassa? Selityksiä voisi tarjota, koetan tarjota
kolmea: 1. projektit annetaan osaamattomille amatööreille. 2.
projektien päätöksenteko on ammattitaidotonta, 3. insinööritaidon
perinteistä ei osata ottaa oppia.
Vaikeat projektit joutuvat
amatöörien käsiin?
Kokeneet
projektitalot onnistuvat projekteissaan, koska niiden parhaat
asiantuntijat pystyvät tehokkaaseen ja toimivaan
projektijohtamiseen. Tähän ei voi väittää vastaan, mutta
katsotaan tilannetta tarkemmin. Miksi sitten kokeneet projektitalot
eivät tee näitä valtakunnan kriittisiä projekteja. Syy voin olla
seuraava. Jos projekti on niin sanotusti helppo, sen määrittely
onnistuu hyvin ja projektihenkilöstö pitää projektin hallinnassa.
Projektista saadaan sen kuluessa täsmällisesti etenevä ja
ennusteen mukaisesti tarkentuva kuva. Oikeastaan jopa projektin
johtaminen on silloin jo suorastaan turhaa. Projektin kulkuhan
arvattiin oikein, ja se olisi onnistunut muutenkin ja pienemmin
hallintokuluin.
Ja sitten se iso mutta. Asiansa osaava projektitalo
osaa valita projekteja, jotka ovat hallittavissa, tai ne osataan
muuttaa hallittaviksi. Hyvä projektitalo osaa myös rajata
vastuunsa, niinpä se ei ota niskoilleen projekteja, joiden
onnistuminen on epävarmaa. Joten hankalat projektit todella joutuvat
usein amatöörien käsiin. Amatöörit saavat vastuulleen juuri
niitä hankkeita, joita on hankala määritellä niin selkeästi,
että ne voitaisiin edes siirtää projektiammattilaisille.
Tietysti on myös
totta, että ohjelmistoalalla amatöörin ja ammattilaisen raja on
häälyvä. Raja on häälyvä ohjelmistofirmojen välillä, mutta se
on häälyvä myös niiden sisällä. On vaikea selvittää,
kuka osaa ja mitä osaa ja mikä firma osaa. Se kun riippuu myös
kontekstista - eli millaisesta ohjelmasta onkaan kysymys.
Ei osata johtaa eikä tehdä
järkeviä päätöksiä
Uskomme
mielellämme, että johtaminen perustuu johdettavien asioiden
tuntemiseen. Jossain määrin se pitää paikkansa, ja se pitää
paikkansa erityisesti johtamisen alemmilla tasoilla, eli kun
päätetään projekteista ja johdetaan niitä. Ohjelmistopuolella
sisältöjohtaminen on kuitenkin erityisen vaikeaa.
Ohjelmistotekniikka on kehittynyt suuntaan, jossa dokumentointi ja
strukturointi on kustannussyistä minimoitu. Ohjelmointi on tiimien
sisäistä intensiivistä sosiaalista toimintaa, ulkopuolelta sitä
on vaikea edes tarkkailla, saati ymmärtää.
Niinpä, kun pitäisi tehdä
tärkeitä ohjelmia tai julkishallinnon ohjelmia, päätöksenteko
siirtyy nopeasti organisaatiossa ylöspäin, tasolle, jossa sisällön
osuudesta ei enää voi juuri puhua. Ja tulokset puhuvat puolestaan.
Insinööriperinne unohtui
Julkisuudessa
esillä olleilla ohjelmistoilla on eräs yhteinen piirre. Ne toimivat
osana ihmisten johtamia järjestelmiä. Teknisin termein, kyseessä
ovat monimutkaiset ihminen - kone- systeemit. Tällaisten
järjestelmien määrittely ja suunnittelu ovat vaativia, koska
erilaisia toiminnan ja väärän toiminnan mahdollisuuksia on niin
paljon. Tämä on traagista, koska tietokoneilla olisi niin suuria
mahdollisuuksia parantaa ja tehostaa palveluja. Ongelma on
erityisesti siinä, että kehitettävillä järjestelmillä ei juuri
ole esikuvia, ja vaikka olisi, niitä ei voisi modulaarisuuden
puutteen ja lisenssiongelmien takia hyödyntää. Ohjelmien evoluutio
nimittäin poikkeaa teknologian valtavirrasta. Perinteinen teknologia
kootaan erillisistä osista, jotka puolestaan ovat kehittyneet
vähitellen pitkän kehityshistorian kautta.
”Kerralla
valmiiksi” - kehitysmalli on vaarallinen, ja huonosti modulaaristen
ohjelmistojen kohdalla tilanne on erityisen paha. Ohjelmistoissa
tosin jäljitellään evoluutiota vaiheittain tarkentuvan
kehitysmallin avulla. Toimintamallia sanotaan - mielestäni
hirtehisesti - ”ketteräksi ohjelmoinniksi”. Mutta käytännössä
mallille ei anneta riittävää aikaa. Ihminen-kone järjestelmissä
malli edellyttää myös käytön aloittamista siinä vaiheessa, kun
järjestelmä on vielä epäkypsä. Sitä vain ei voi välttää -
joten ohjelmista saatavat ikävät kokemukset ovat tulleet
jäädäkseen.
Olen pohdiskellut kehitysprojektien ongelmia - myös laajemmin kuin ohjelmien osalta - tarkemmin kirjassani ”Projektitoiminnan musta kirja”.
