Ohjelmistoprojektin sudenkuopat ja miten ne vältetään

By Rami Juvonen

Tiesitkö, että suurin osa ohjelmistoprojekteista epäonnistuu?

Jopa kokeneet ammattilaiset kokevat ohjelmistoprojektien hallinnan hankalaksi. Digitalisaation myötä ohjelmistotyön määrä on kuitenkin jatkuvassa kasvussa. Tässä helppotajuinen selviytymisopas kaikille ohjelmistoprojektien parissa työskenteleville.

Kirja sisältää johdanto-osuuden ohjelmistoprojektien perusteisiin, joten aikaisempaa ohjelmisto-osaamista lukijalta ei edellytetä. Toisaalta kirja tarjoaa uutta tietoa jopa ohjelmistoprojektien konkareille. Kirja soveltuu myös mainiosti kurssimateriaaliksi alan opintoihin ja helpottaa siirtymistä opiskelijasta ohjelmistotiimin tuottoisaksi jäseneksi.

• Language: Suomi
• Publisher: Books on Demand
• Release date: May 2, 2018
• ISBN: 9789528073147

Rami Juvonen

Kirjoittaja on koulutuksiltaan tietotekniikan diplomi-insinööri ja opettaja. Hän on työskennellyt yritysmaailman ohjelmistoprojekteissa vuodesta 2004 lähtien.

Book preview

Sisällys

Esipuhe ja kiitokset

Johdanto

Ohjelmistoprojektien projektimallit ja toteutusmenetelmät

Vesiputousmalli

Ketterät menetelmät

Scrum

Kanban

Protoilu

Ohjelmistotestaus

DevOps

Projektin valmisteluvaihe

Liian suuri projekti

Halvalla myyty projekti

Valmiiksi myöhässä oleva projekti

Tekemistä ei mielletä projektiksi

Heikko tai olematon business case

Priorisointi

Organisaation muutos

Kaikille sopiva

Loppukäyttäjien kuunteleminen

Muuttuva maailma, muuttuvat vaatimukset

Yllätyksiä tulee aina

Etappien määrittely ja riskianalyysin tärkeys

Ohjelmistotyön ostaminen

Sopivan toimittajan valinta

Monitoimittajaprojektit

Kypsymättömät prosessit

Väärä toteutusmenetelmä

Työmäärän arvioinnin menetelmät

Projektissa toimiminen

Projektikommunikaatio ja sen puute

Johtaminen ja johtajuus

80:20 sääntö

Fokus tuotteen tekemiseen

Avoimen lähdekoodin hyödyntäminen

Me emme keksineet sitä

Projektin muutoshallinta

Projektin loppuvaihe

Päättymätön projekti

Käyttöönottovaihe

Virheistä oppiminen

Tuotosten kerääminen

Yrityskulttuuri ja projektitiimin yhteistyö

Uusliberalismi ja nykyiset johtamistrendit

Mittarien asettaminen ja palkitseminen

Kasvu yrityskauppojen kautta

Voimaa liittoutumalla

Offshoraus

Ryhmädynamiikka ja roolit

Ongelmat työilmapiirissä

Ulkoisten konsulttien käyttö

Varjo-IT

Kustannuksissa pihistely

Tietoturvavaatimukset

Onnistumisia ohjelmistoprojekteissa

Kuopasta nouseminen

Suurta ketterästi

Yhteenveto

Lähteet

Esipuhe ja kiitokset

Työskenneltyäni vuosia ohjelmistoprojektien parissa, olen kohdannut monia projektien kulkuun liittyviä vaikeuksia ja todennut samojen ongelmien toistuvan yhä uudelleen. Tämä johdatti minut pohdiskelemaan, miksi Suomessa ei tarjota juurikaan koulutusta näiden ongelmien tunnistamiseen, välttämiseen ja varsinkin ennaltaehkäisyyn? Tunnistettuani tämän puutteen, päätin ryhtyä toimeen tilanteen parantamiseksi. Keväällä 2017 opetin aiheesta Tampereen ammattikorkeakoulussa ja samoihin aikoihin varmistui suunnitelmani kirjoittaa aiheesta myös kirja, jota parhaillaan luet.

Ystäväni Kari Juopperi, Joonas Leponen ja Kai Tusa tukivat hanketta toimimalla oikolukijoina. IT-alan ammattilaisina he tarjosivat myös lukuisia arvokkaita parannusehdotuksia kirjan sisältöön.

Kirjan oikolukijoina toimivat myös veljeni Jari Juvonen ja Matti Juvonen, sekä vaimoni Anni Juvonen. He eivät työskentele IT-alalla, joten heidän palautteensa auttoi ymmärtämään, miten aihe avautuu ohjelmistoprojekteja vähemmän tuntevalle lukijalle. Perheeni toimi ymmärtäväisenä ja vahvana tukena kirjoitustyöni aikana.

Tämän kirjan kirjoitustyöhön on saatu Suomen tietokirjailijat ry:n myöntämä apuraha.

Haluan esittää yhteisen kiitokseni kaikille kirjan syntyyn myötävaikuttaneille tahoille.

Ylöjärvellä maaliskuussa 2018

Rami Juvonen

Johdanto

On hämmästyttävää, kuinka suuri osa ohjelmistoprojekteista epäonnistuu. Jos epäonnistumiseksi tulkitaan aikataulusta luisuminen, budjetin pettäminen tai lopputuotteen puutteellinen toiminnallisuus, vain noin kolmasosa ohjelmistoprojekteista onnistuu (Ryhänen 2012). Onneksi perehtymällä ohjelmistoprojektien yleisimpiin ongelmiin ja niiden ratkaisuihin pystymme varmasti kasvattamaan onnistuvien projektien osuutta jatkossa.

Mikä on epäonnistumisen hinta? Varsin korkea, sillä Järvenpään ja Kankareen (2013) mukaan epäonnistuneissa IT-hankkeissa haaskataan Suomessa vuosittain noin 7 miljardia euroa. Globaalisti epäonnistumiset kasvattavat IT-projektien kuluja vuodessa noin kolmella biljoonalla dollarilla (Kim & kumppanit 2012)! Julkisuudessa riepoteltavat epäonnistuneet projektit ja hankkeet ovat tietenkin vain jäävuoren huippu, sillä yritykset pyrkivät kätkemään mokansa. Julkishallinnon hankkeet ovat otsikoissa verrattain usein, koska niihin liittyvät hankaluudet on vaikeampi salata. Vielä jonkin aikaa sitten projektia voitiin pitää myönteiseksi ymmärrettynä muotisanana (Karlsson & Marttala 2001), mutta nykyään termi IT-projekti herättää valitettavasti lähinnä negatiivisia mielleyhtymiä. Haasteenamme on oikaista tämä suuntaus, jolloin pystymme nauttimaan onnistuneiden projektien tuottamasta euforiasta.

Tämän kirjan lukemisesta hyötyvät kaikki, jotka jollain tapaa työskentelevät ohjelmistoprojektien parissa. Digitalisaation myötä ohjelmistotyön määrä on jatkuvassa kasvussa. Näin ollen monet henkilöt ja organisaatiot, joilla ei ole aikaisempaa kokemusta ohjelmistoprojekteista, pääsevät niihin tutustumaan. Epäonnistuneiden ohjelmistoprojektien verrattain suuri osuus on todiste siitä, että tämän kaltaista kirjaa tarvitaan – nyt ja etenkin tulevaisuudessa.

Kirjan sisältö on jäsennelty siten, että ohjelmistoprojektien ammattilaiset voivat halutessaan jättää ensimmäisen luvun väliin ja jatkaa lukemista suoraan luvusta Projektin valmisteluvaihe. Muille lukijoille ensimmäisestä luvusta aloittaminen on ehdottoman suositeltavaa. Se tarjoaa perustiedot ohjelmistoprojekteissa yleisesti noudatettavista menetelmistä ja työvaiheista. Näihin perehtyminen ennen pidemmälle lukemista tekee kirjan muun sisällön helpommin ymmärrettäväksi. Toivotan mukavia lukuhetkiä ja positiivisia oivalluksia kirjan parissa.

Ohjelmistoprojektien projektimallit

ja toteutusmenetelmät

Valtaosa IT-alalla tehtävästä tuotekehitystyöstä on projektimuotoista. Jotta voimme käsitellä ohjelmistoprojektien sudenkuoppia, on ensiksi tarpeen ymmärtää ohjelmistoprojektin tyypillinen rakenne – eräänlainen alalla muotoutunut projektin arkkityyppi. Havaintojeni perusteella väittäisin, että organisaatiokohtaiset projektimallit eroavat tässä esitetystä vain yksityiskohdiltaan. Kuva 1 havainnollistaa projektin yleisen mallin, projektin ohjausrakenteen sekä projektin olennaisimmat dokumentit.

kuva 1: Projektin yleinen malli

Business case (tälle termille ei ole hyvää vakiintunutta suomennosta) sisältää mahdollisimman realistisen arvion projektin toteuttamisesta koituvasta rahallisesta hyödystä.

Ohjausryhmä on projektin ylin päättävä elin.

Projektipäällikkö johtaa projektitiimiä ja pitää ohjausryhmän jäsenet tietoisina projektin etenemisestä.

Asettamisasiakirja sisältää alustavan kuvauksen projektin tavoitteista, rajauksista ja sidosryhmistä. Se on erityisen tärkeä projektin hahmotteluvaiheessa, kun varsinaista projektisuunnitelmaa ei ole vielä laadittu. Asettamisasiakirjaa voidaan hyödyntää projektitoteutuksen tarjouspyynnön liitteenä.

Sopimukset laaditaan esimerkiksi projektin asiakkaan ja ohjelmistotoimittajan välillä, mikäli projektin toteutus tai osa työvoimasta ostetaan talon ulkopuolelta.

Projektisuunnitelma sisältää kuvauksen projektin tavoitteista, sidosryhmistä, vastuujaosta, aikataulusta, etapeista, kustannuksista, resursoinnista, tarvittavista hankinnoista, raportointikäytännöistä, muutoshallinnasta sekä riskeistä.

Raportit ovat käytössä monella tasolla. Projektitiimi raportoi työn edistymisestä projektipäällikölle, joka puolestaan raportoi pääkohdat ohjausryhmälle.

Muutoshallinta käsittää projektin aikana esitettävät vaatimusmuutokset ja muutoshallinnan toteuttaminen on ohjelmistoprojektien arkipäivää. Muutospyyntöjen hallintaan ja käsittelyyn tulee olla projektissa yhdessä sovittu tapa.

Suunnitelman tarkennus tarkoittaa tässä projektin tuotosten käyttöönoton tarkempaa suunnittelua. Käyttöönotto sinänsä tulee huomioida jo projektin alkuvaiheissa, mutta ajankohdan lähestyessä suunnitelmaa on aiheellista uudelleenarvioida ja muokata tarpeen mukaan. Käyttöönottosuunnitelma voi olla osa projektisuunnitelmaa tai oma kokonaisuutensa. Joskus käyttöönottovaihe käsitellään jopa omana käyttöönotto- tai toimitusprojektinaan.

Harjoittelu tarkoittaa tässä käyttöönoton harjoittelua esimerkiksi asiakkaan oikeaa toimintaympäristöä mahdollisimman pitkälti vastaavassa testiympäristössä.

Loppuraportti kokoaa tavalla tai toisella yhteen projektissa opitun, kohdatut sudenkuopat sekä jatkosuunnitelmat.

Mikäli olet jo ollut tekemisissä ohjelmistoprojektien kanssa, olet todennäköisesti törmännyt termeihin kuten vesiputousmalli, ketterät menetelmät ja Scrum. Mikäli sinulla ei vielä ole kokemusta ohjelmistoprojekteista, ihmettelet varmaan mitä nämä ovat. Lyhyesti sanottuna kyse on toteutusvaiheen menetelmistä, joiden avulla hallinnoidaan ohjelmistotuotteen kehitystä. Seuraavaksi esiteltäviä menetelmiä käytetään tyypillisesti kuvan 1 toteutusnuolen kohdalla. Ne voivat kuitenkin sisältää myös esimerkiksi tuotosten käyttöönottoon liittyviä toimintatapoja. Muitakin menetelmiä ohjelmistoprojektien toteuttamiseen tietenkin on, mutta tähän on kerätty yleisesti käytetyimmät. Projektin toteutuksessa ja käyttöönotossa voidaan myös hyödyntää useita menetelmiä sekä niiden yhdistelmiä.

Vesiputousmalli

Aloitamme toteutusmenetelmien tarkastelun vesiputousmallista, sillä se on monen muun menetelmän kantaisä. Vesiputousmallin nimi kuvaa menetelmää varsin hyvin. Ideana nimittäin on, että vaiheet seuraavat toisiaan ja aikaisempiin vaiheisiin ei enää palata. Voit ajatella tätä myös rappusina, joissa jokainen porras on oma vaiheensa, joten astelet rappusia vain alaspäin ja samalla projekti etenee. Vesiputousmallin hyvänä puolena on yksinkertaisuus ja selkeys – huonona puolena taas se, ettei menetelmä oikein toimi. Tosielämässä näet tulee tämän tästä tarve palata aikaisempaan vaiheeseen ja muuttaa suunnitelmia tai toteutusta. Vesiputousmallin keksijänä pidetty Winston W. Royce kyllä tiedosti tämän tarpeen ja määritteli ohjelmistokehitysmallinsa siten, että myös edellisiin vaiheisiin palaaminen on sallittua. Roycen julkaisu (1970) alkaa kuitenkin puutteellisen vesiputousmallin esittelyllä ja suositeltu tapa kehittää ohjelmistoja määritellään vasta julkaisun loppupuolella. Roycen julkaisua luettiin ja siteerattiin huolimattomasti, jolloin puutteellisesta mallista vähitellen muodostui ohjelmistoprojektien de facto -standardi. Tämä klassinen vesiputousmalli on esitetty kuvassa 2.

kuva 2: Vesiputousmalli yksinkertaisimmillaan

Kun aloitin ohjelmistosuunnittelijan palkkatyöni vuonna 2004, vesiputousmalli eri variaatioineen oli vielä yleisimmin käytetty ohjelmistokehitysmenetelmä. Hyvin pian alkoi kuitenkin ketterien menetelmien esiinmarssi myös Suomessa.

Ketterät menetelmät

Ketteriä menetelmiä voidaan pitää vastavetona vesiputousmallin kankeudelle. Vuonna 2001 joukko ohjelmistokehittäjiä järjesti parin päivän tapaamisen Utahissa keskustellakseen käyttämistään menetelmistä. Kehittäjät päättivät nimittää parhaita menetelmiään ketteriksi ja perustivat niiden käytön edistämistä ajavan Agile Alliance -järjestön. Ketterien menetelmien pohjana olevat arvot ja keskeiset periaatteet on määritelty Agile Manifestossa (Agile Alliance 2001). Arvot kuuluvat seuraavasti:

"Löydämme parempia tapoja tehdä ohjelmistokehitystä, kun teemme sitä itse ja autamme muita siinä. Kokemuksemme perusteella arvostamme:

Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja

Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota

Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja

Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa

Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän."

Tässä yhteydessä on syytä todeta, että kuten vesiputousmallin tapauksessa, myös ketterien menetelmien kohdalla joitakin asioita on tulkittu väärin. On vaikeaa sanoa, missä määrin kyse on aidoista väärinymmärryksistä ja milloin väärinymmärrykseen ovat johtaneet pyrkimykset tehdä ohjelmistoja halvalla ja nopeasti. Esimerkiksi arvo, joka asettaa toissijaiseksi kattavan dokumentaation, halutaan joskus ymmärtää siten, että speksausta (spesifikaatioiden eli suunnitteludokumenttien laadintaa) ei tarvitse tehdä. Sehän kuulostaa hienolta ja vapauttavalta! Samalla säästyy aikaa ja rahaa. Kunnon koodarit eivät muutenkaan välitä speksata, koska he mieluiten koodaavat. Mutta pysähdytäänpä tähän hetkeksi. Jos speksaamista ei tehdä missään muodossa, tavalla tai toisella, tarkoittaa se, ettei toteutettavaa ohjelmistoa suunnitella. Haluaisitko sinä esimerkiksi ajaa autolla, jota ei ole varsinaisesti suunniteltu,