3.6.2013

Ketteryys haltuun: Miten ostan ketteriä IT-projekteja?

 

Ketteryys haltuun -artikkelisarjassa julkaistut muut osat:
Osa 1: Ketterän kehityksen yleiset periaatteet
Osa 2: Yleisimmät ketterät käytännöt
Osa 3: Scrum pähkinänkuoressa

Ketteryys haltuun -artikkelisarjassa kerrotaan ketterän kehittämisen periaatteista ja käytännön menetelmistä. Ketterä kehittäminen on kerännyt yhä enemmän huomiota, mutta ilmiö ei ole lainkaan yksiselitteinen eikä ketterän kehittämisen soveltaminen käytännössä ole aina yksinkertaista. Tämän artikkelisarjan tavoitteena on avata peruskäsitteitä ja auttaa ymmärtämään mitä ketteryys ohjelmistokehityksessä tarkoittaa.

Sarjan neljännessä osassa tarkastellaan ketterien it-projektien ostamista.

Voiko ketterän projektin ostaa kiinteällä hinnalla?

Tyypillisin kysymys ketterien projektien ostamisesta on, että voiko ketterän projektin ostaa kiinteällä hinnalla? Lyhyt vastaus kysymykseen on: Kyllä voi, mutta toimituksen sisältämiä ominaisuuksia ei voi ennakkoon lukita. Ketterän kehittämisen periaatteista puhuttaessa onkin aina suositeltavaa käydä myös läpi ketteryyden tuomat muutokset projektien ostamiseen.

Kaikkea ei voi saada – vaikka haluaisi.

Ketterän kehityksen kirjallisuudessa keskustellaan onneksi varsin paljon myös projektien ostamisesta. Usein perinteistä kolmen kulman mallia (hinta, laajuus, aikataulu) laajennetaan vielä neljännellä kulmalla, eli laadulla.

Asiakkaan tulisi siis projektin valmistelussa miettiä, että mitkä neljästä kulmasta ovat kaikkein tärkeimpiä omassa projektissa: 1) hinta, 2) laajuus, 3) aikataulu vai 4) laatu. Kaikkia neljää kun ei voi saada samassa projektissa. Käytännössä erilaiset yhdistelmät ovat myös vaikeampia toteuttaa kuin toiset. Esimerkiksi laajuuden ja aikataulun lukitseminen on yhdistelmä, joka harvoin käytännössä onnistuu, koska ohjelmistokehitys ei nopeudu aina samassa suhteessa vaikka tiimiin lisättäisiinkin uusia jäseniä (esim. kolmen hengen tiimi voi tuottaa laadukasta koodia lähes yhtä nopeasti kuin seitsemän hengen tiimi).

Yksi ketterien menetelmien takana oleva väitehän on, että kun kolme perinteistä kulmaa on yritetty kiinnittää (hinta, laajuus, aikataulu), niin riskinä on aina laadun joustaminen. Käytännössä tällä tarkoitetaan täysin kiinteähintaisia projekteja joille on asetettu tiukka aikataulu ja kuvattu tarkasti toimitettavat asiat. Tällöin valitettavaa realismia on, että sovelluskehittäjät pakotetaan tällöin tinkimään testaamisesta, rajoittamaan sovelluksen refaktorointia, tekemään nopeita korjauksia ja yleensäkin menemään siitä mistä aita on matalin – koska paine on kova. Tämän seurauksena tietojärjestelmän käyttökokemus kärsii, ja pahimmillaan myös ylläpitokustannukset kasvavat. Tätä voikin pitää yhtenä it-projektien huonon maineen taustalla olevasta perimmäisestä ongelmasta. Valitettavan usein tämä “kaikkien kulmien kiinnittäminen” liittyy myös perinteiseen vesiputousmalliin jonka mukaan edelleen usein halutaan toimia vaikka käsillä oleva projekti ei välttämättä vesiputousmalliin soveltuisikaan.

Millaisia projektimalleja ketterät menetelmät mahdollistavat?

Moni sanoo ketterien menetelmien soveltuvan ihan mihin vain tilanteeseen, mutta käytännössä useimmat projektit edustavat joko aikatauluvetoista mallia tai ominaisuusvetoista mallia. Tällöin muut asiat ovat alisteisia näille valituille asioille.

Projektimalli 1: Aikataulu edellä.

Ketterät menetelmät mahdollistavat aikataulun lukitsemisen varsin hyvin. Tällöin jos projektilla on selkeä deadline, niin laajuudesta on oltava valmis tinkimään. Tällöin toimintoja toteutetaan alusta saakka tiukasti prioriteettijärjestyksessä. Näin deadlinen koittaessa tekemättä on vain vähemmän tärkeitä toimintoja. Tällöin myös budjetti on helposti ennustettavissa, mutta aivan varmoja ei vain voida olla, että miten paljon ominaisuuksia budjetilla saadaan toteutettua.

Periaatteessa ketterät menetelmät mahdollistavat myös tiukan kustannuskurin, koska prosessi on läpinäkyvä ja ennakkoon asetettuun hintakattoon on helpompaa osua.

Tyypillisesti aikataulun ehdoilla menevät projektit ovat isoja uudistusprojekteja jotka liittyvät johonkin laajempaan tuotelanseeraukseen. Tällöin halutaan olla aivan varmoja siitä, että palvelu julkaistaan tiettynä päivänä ja sen halutaan myös ehdottoman varmasti olevan testattu ja toimiva julkaisuhetkellä. Samalla halutaan usein, että julkaisupäivänä tuotteessa olisi mukana mahdollisimman paljon suunniteltuja ominaisuuksia.

Voisikin jopa sanoa, että ketterät menetelmät sopivat parhaiten tilanteisiin joissa aikataulu on kriittinen. Toiseksi parhaiten ne sopivat tilanteisiin joissa aikataulu ja tietojärjestelmän laatu/sopivuus on tärkeintä.

Projektimalli 2: Ominaisuudet edellä.

Jos taas ominaisuudet ja näiden laatu on erittäin tärkeätä, niin ketterät menetelmät ovat myös hyvin soveltuvia. Erityisen hyvin ketteryys sopiikin projekteihin joissa tietojärjestelmän pitää ehdottomasti täyttää kaikki sille asetetut odotukset – ja täyttää ne vielä erittäin hyvin!

Tällöin kannattaa valmistautua joustamaan aikatauluissa ja hinnassa. Hyvä asia ketterissä menetelmissä on, että tavoitteiden realistisuus selviää nopeammin kuin perinteisissä menetelmissä. Todennäköisesti jo parin kuukauden jälkeen tiedetään, että tullaanko asetettuun aikataulutavoitteeseen osumaan. Samalla myös tiedetään varsin hyvin se, että mikä olisi realistinen aikataulu kun toteutuksen valmiusasteesta on hyvä käsitys. Myös kustannuksien osalta saadaan näin realistinen kuva nopeasti ja tarvittavia korjausliikkeitäkin voidaan vielä tehdä.

Tosin yksi käytännössä havaittuja ketterien menetelmien haasteita on projektiryhmän halu tehdä huippulaatua myös asioissa jotka eivät välttämättä vaatisi sitä. Tämä voi helposti johtaa suuriin kustannuksiin isoissa projekteissa ja siksi tiukoilla aikataulurajoilla työskentely on jopa suositeltavaa monissa ketterissä projekteissa.

Yhteenvetona voisi todeta, että ketterä kehitysmalli on suositeltava silloin kun asiakas pitää erityisen tärkeänä vähintään kahta kohtaa seuraavasta kolmesta kohdasta:

  • Jatkuva, todellinen tieto projektin tilasta, mikä perustuu todellisiin toiminnallisuuksiin, ei vain raportteihin ja dokumentaatioon.
  • Lupa muuttaa vaatimuksia ilman lisäkustannuksia! Muistaen kuitenkin, että erilaiset sopimukset mahdollistavat eri määrän joustoa. (Ja vaatimuksien lisäämisestä tietysti aina tulee kustannuksia, kaikissa mahdollisissa projektimalleissa.)
  • Ehdottoman varmuuden siitä, että kaikkein tärkeimmät toiminnot on toteutettuna ajallaan. (tai ainakin aikaisessa vaiheessa tiedon siitä jos tavoite ei tule onnistumaan)

Moni asiakas on valmis maksamaan näistä asioista ja myös sitoutumaan projektiin vahvemmin kuin mitä perinteisemmissä malleissa. Pelkästään näkyvyys prosessiin ja mahdollisuus todella luottaa aikatauluun ovat asioita, jotka saavat monet asiakkaat opettelemaan uudenlaista tekemisen mallia ja vaatimaan sitä toimittajiltaan.

Toisaalta on edelleen paljon projekteja joissa asiakas haluaa maksaa kiinteän summan rahaa ja odottaa saavansa vastineeksi tietyn paketin toimintoja toimitettuna tietyssä ajassa. Ketterien menetelmien isoin väite onkin, että jälkimmäinen tavoite pitää sisällään paljon riskejä aina kun tehdään asiakaskohtaisia tietojärjestelmiä ja tätä jälkimmäistä “räätälöity tietojärjestelmä pakettitoimituksena” -mallia ei tulisi ehkä käyttää missään tilanteissa! Tämä on toki kärjistys, mutta se kertoo paljon siitä millaisia kokemuksia ja ajattelua on ketterien menetelmien kehityksen taustalla.

“Hyvän diilin” tekeminen on vaikeampaa ostajalle

Ammattiostajan näkökulmasta ketterät menetelmät ovat kovin erilainen peto käsiteltäväksi kuin perinteinen kiinteähintainen paketti jossa lukitaan aikataulu, hinta ja laajuus. Kiinteähintaisen paketin vaatiminen epäilemättä mahdollistaa “hyvän diilin” tekemisen IT-toimittajan kanssa, jolloin mahdollisista virhearvioista vastuun kantaa IT-toimittaja. Tällaisessa ostamismallissa potentiaaliset riskit ovat kuitenkin aina merkittäviä myös asiakkaan kannalta. Jos kaikista sovituista asioista pidetään tiukasti kiinni, niin riskinä on, että IT-toimittajan on pakko joustaa laadussa (kun ohjelmistokehitystä ei esimerkiksi tekijöiden lisäämisellä voi kovin helposti nopeuttaa).

Alan kauhutarinoissa asiakas haluaa vain hyvän diilin ja IT-toimittaja haluaa tehdä kannattavan projektin – mutta kukaan ei oikeastaan ole kiinnostunut siitä ratkaiseeko toimitettava tietojärjestelmä asiakkaan ongelman. Ketterien menetelmien avulla huomio saadaan kiinnitettyä molemminpuolin siihen millaista tietojärjestelmää ollaan tekemässä. Kääntöpuolena on, että ammattiostajan näkökulmasta “hyvän diilin” tekeminen vaikeutuu.

Ammattiostajan huomion tulisikin ketterien projektien kohdalla kiinnittyä “paketin” sijasta tiimin osaamiseen, toimittajatahon toimintaprosesseihin ja sopimuksen joustavuustekijöihin. Usein ketterien projektien ostamisessa yhdistellään tuntilaskutusta ja tavoitehintamalleja. Esimerkiksi projektin alkuvaihe voidaan tehdä tuntilaskutuksella, mutta alkuvaiheen jälkeen voidaan siirtyä tavoitehintamalliin. Joskus myös kiinteähintaisia paketointeja käytetään. Myös tuntihinnoista on mahdollista neuvotella etenkin isommissa projekteissa, koska toimittajalla ei ole kiinteähintaiseen projektiin verrattavia riskejä.

Suositeltavaa luettavaa:


Artikkeli pohjautuu aiemmin Sinisessä Meteoriitissa menetelmäarkkitehtina työskennelleen Sami Poimalan tuottamiin koulutusmateriaaleihin ja artikkeleihin. Artikkelin on julkaistuun muotoon viimeistellyt ja täydentänyt Sinisessä Meteoriitissa aiemmin työskennellyt konsultti Perttu Tolvanen.

Perttu Tolvanen on sisällönhallinnan konsultti. Pertulla on kokemusta laajoista portaaliprojekteista joissa on sovellettu ketterän kehittämisen menetelmiä. Perttu Tolvanen työskentelee Sinisessä Meteoriitissa ja auttaa asiakkaita hankkeistuksessa, vaatimusmäärittelyissä ja teknologiavalinnoissa.

Sami Poimala on kokenut menetelmäarkkitehti ja ohjelmistokehittäjä. Sami on työskennellyt vuosia ketterän kehittämisen parissa Sinisessä Meteoriitissa ja myös kouluttanut paljon esimerkiksi Sinisen Meteoriitin henkilökuntaa ketterän kehittämisen saloihin. Sami Poimala työskentelee nykyisin omassa yrityksessään Offbeat Solutionsissa, jossa hän konsultoi asiakkaita ketterien ohjelmistoprojektien toteutuksessa, erityisesti Microsoft-teknologioiden maailmassa.

Sininen Meteoriitti on SharePoint-toteutuksiin erikoistunut ohjelmistoyritys, jonka projekteissa on hyödynnetty ketteriä menetelmiä jo vuosia.