Tarpeen jatkuva kirkastaminen tuottaa parempia ohjelmistoprojekteja
Upcoming SlideShare
Loading in...5
×
 

Tarpeen jatkuva kirkastaminen tuottaa parempia ohjelmistoprojekteja

on

  • 252 views

Artikkelini PRY:n projektitoiminta lehdessä (2013)

Artikkelini PRY:n projektitoiminta lehdessä (2013)

Statistics

Views

Total Views
252
Views on SlideShare
252
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tarpeen jatkuva kirkastaminen tuottaa parempia ohjelmistoprojekteja Tarpeen jatkuva kirkastaminen tuottaa parempia ohjelmistoprojekteja Document Transcript

  • 2/2013 OSAAMINEN KUNTOON Olemme uudistaneet sivumme! käy klikkaamassa > www.pry.fi Projektiyhdistyksen suuret saappaat s. 4-5 Oi Suomi, päiväs' vielä koittaa s. 6-9 Comparing PM Certifications s. 20-22 Suomalaisorganisaatiot Megasuuntauksen jälkijunassa? s. 16-18 Projektitoiminnan menestysresepti! IPMA Delta case: Swisscom IT Services s. 28-31 Puolivallaton projektinjohtaja s. 100-105
  • Osaaminen kuntoon Tarpeen jatkuva kirkastaminen tuottaa Parempia ohjelmistoprojekteja Teksti: Marko Taipale Ohjelmistoprojekteissa puhutaan paljon tilaajan ja toimittajan vastuusta. Rajanveto on vaikeaa ja ohjelmistoprojektit epäonnistuvat turhan usein. Käsittelen tämän artikkelin puitteissa erästä merkittävää juurisyytä epäonnistumisille. Tilaaja haluaa saada tarpeenmukaisen ratkaisun, mutta ei välttämättä tiedosta, että hän ei voi kaikilta osin tietää tarvettaan. Tämä takia ratkaisu itse asiassa löytyy tilaajan ja toimittajan yhteistyöllä sen sijaan, että se voidaan etukäteen määritellä. Jos projektin tilaaja delegoi omien tarpeidensa kirkastamisen toimittajalle, hän altistaa projektin lähes varmalle epäonnistumiselle. Onnistuakseen paremmin, tilaajan tulee itse kirkastaa tarvettaan jatkuvasti ja valmistautua tekemään päätöksiä. Artikkelin tavoite on kertoa, miten tilaaja ja toimittaja huolehtivat tarpeenmukaisen ratkaisun syntymisestä. Vertaan toisiinsa kahta projektin tilaamisen lähestymistapaa: 1) ”Ratkaisu edellä”, missä tarpeen ymmärtäminen delegoidaan projektin toimittajalle ja 2) ”Tarvetta kirkastetaan jatkuvasti”, missä projektin tilaaja huolehtii tarpeestaan koko projektin ajan. 42
  • Ratkaisu edellä On tärkeää, että jokainen ohjelmistoprojekti nähdään myös toiminnan kehittämisen projektina Tarvetta kirkastetaan jatkuvasti Pieleen menneen projektin jälkeen tilaaja pohtii, mitä hänen ja hänen sidosryhmiensä pitäisi tarpeestaan ymmärtää, jotta ohjelmistoprojekti voisi tuottaa tarpeenmukaisia ratkaisuja. Hän listaa: - Nykyiset prosessit, joita ohjelmisto tulee jollain tapaa palvelemaan - Tulevaisuuden prosessit, joissa tietojärjestelmä hoitaa oman osuutensa - Kuka käyttää tätä järjestelmää ja mihin? - Mitä tarpeita, toiminnallisia tai laadullisia, tähän ohjelmistoon tai koko prosessiin liittyy? - Mihin tekniseen ja toiminnalliseen ympäristöön ohjelmisto tulee osaksi? - Mitä riskejä tähän kokonaisuuteen liittyy ja mitä minun pitää päättää nyt, mitä voin päättää myöhemmin? Tarpeen mukainen ratkaisu Tarpeen jatkuva kirkastaminen Projektin tilaaja on tehnyt liiketoimintalaskelman ja päättää tilata uuden ohjelmistoprojektin. Projektin toimittaja tulee paikalle ja sitoutuu toimittamaan. Parin vuoden päästä ohjelmistoa otetaan käyttöön. Tarkastelen tätä lähestymistapaa kuvan 1 mukaisella kuvaajalla. Tyypillinen tilaajan lähtökohta on epäselvä kuvitelma siitä, mitä lähdetään tekemään, ja toisaalta vähäinen ymmärrys omasta ympäristöstä, prosesseista, käyttäjistä ja yritysarkkitehtuurista. Tilattavan ohjelmiston kuitenkin toivotaan täyttävän jokin tunnistetuista tarpeista ja täten päätetään aloittaa ohjelmistoprojekti. Ohjelmistoprojekti vedetään läpi mallikkaasti (kohta 1), tilaajan toiveiden tynnyri toimitetaan, ainakin joltain osin, ja näin alkaa käyttöönotto. Käyttöönoton yhteydessä esiintyy joukko ongelmia: tuotettu ratkaisu ei palvelekaan käyttäjiä, eikä se sovikaan yhteen tilaajan yrityksen toimintatapojen kanssa ja muuttaa vain vanhan toimintatavan sähköiseksi. Ongelmat tuottavat paljon muutospyyntöjä (kohta 2) ja niiden seurauksena ohjelmistoprojekti ylittää taloudelliset sekä ajalliset raamit. Ja mikä pahinta, tilaaja voi silti todeta toimineensa oikein, koska hän on antanut toimeksiannon ja sitä on noudatettu - tai jos ei ole, niin hän voi syyttää toimittajaa väärintulkinnoista ja osaamattomuudesta. Lopulta tilaajan sidosryhmät (käyttäjät, päättäjät jne.) eivät halua, voi tai osaa sitoutua uuden ratkaisun käyttöönottoon. Tilaaja miettii, mikä oikein meni pieleen. 2 1 Epäselvyys Tekninen ratkaisu Kuva 1. ERGMANN Attorneys at Law Teollisuuden asianajotoimisto Projektirakentaminen . Energia . Teknologia Asianajotoimisto Bergmann Oy Eteläranta 4 B 9 00130 Helsinki p. +358 9 6962 070 office@bergmann.fi www.bergmann.fi PROJEKTITOIMINTA 2/2013 43
  • Tarpeen jatkuva kirkastaminen Tarpeen mukainen ratkaisu 4 2 3 1 Epäselvyys Tekninen ratkaisu Kuva 2. Tilaaja lähtee työstämään tarpeenmukaista ratkaisua yhteistyössä toimittajan kanssa kuvan 2 mukaisesti. Tilaaja ymmärtää, että ensisijaisesti hänen pitäisi sisäistää oma tarpeensa ja uuden ohjelmiston vaikutus toimintatapoihin jo ennen tilaamista. Tarkastelemalla aikaisempia hankkeitaan hän on oppinut, että tarve tai siihen sovitettu ratkaisu ei kaikilta yksityiskohdiltaan ole määriteltävissä etukäteen, vaan ratkaisu ja tarpeet kirkastuvat ohjelmistoprojektin edetessä. Tilaaja päättää panostaa ensimmäiseen loikkaan (kohta 3) kohti lopullista tavoitetta ja löytää ne kohdat, joiden ratkaiseminen on nyt välttämätöntä. Tilaaja osallistaa Osallistaminen sitouttaa sidosryhmän ratkaisemaan yhteisiä haasteita ja auttaa sisäistämään, mistä oikein on kysymys sidosryhmän pohtimaan nykyistä toimintatapaa ja tulevaa muutosta, missä uusi ohjelmisto hoitaa omaa tonttiansa. Osallistaminen sitouttaa sidosryhmän ratkaisemaan yhteisiä haasteita ja auttaa sisäistämään, mistä oikein on kysymys. Kun ensimmäinen loikka on tehty, tilaaja ja toimittaja tarkastelevat tuloksia. Seuraava loikka (kohta 4) aloitetaan tarkastelemalla tarpeita ja niihin kohdistuneita muutoksia yhdessä, jotta varmistetaan mahdollisimman tarpeenmukainen ratkaisu. Näin jatketaan aina projektin loppuun asti. Toimittajan ja tilaajan välinen yhteistyö loikkien yhteydessä luo puitteet molemminpuoliselle iteratiiviselle oppimiselle. Oppiminen konkretisoituu tilaajalle siten, että hän ymmärtää paremmin oman tarpeensa. Toimittaja pystyy puolestaan kohdistamaan ratkaisun paremmin tilaajan tarpeeseen. Oppimisen myötä molemmille osapuolille kirkastuu, kuinka ratkaisu soveltuu ympäristöön. Tilaajan, toimittajan ja sidosryhmien osallistaminen jatkuu koko projektin ajan, jotta tarpeenmukaisesta ratkaisusta voidaan varmistua loikka-loikalta. Tarinan opetus Tarinan tarkoitus on osoittaa, että olitpa sitten ohjelmistoprojektin ostaja tai yrityksen sisäinen tilaaja, tarpeen kirkastamiseen kannattaa kiinnittää huomiota. On tärkeää, että jokainen ohjelmistoprojekti nähdään myös toiminnan kehittämisen projektina, mikä korostaa jatkuvan tarpeen kirkastamisen merkitystä entisestään. Tarpeenmukaisuutta vaalimalla tilaaja saa paremman ratkaisun nopeammin ja edullisemmin. Lisäksi osallistamalla sidosryhmät mukaan tilaaja sitouttaa heidät käyttöönottoon. Kun tilaajan huomio siirtyy lopputuloksen sijasta matkaan, määränpäässä odottaa tarpeenmukainen ratkaisu – ratkaisu, joka on löytynyt yhteistyössä toimittajan ja oman sidosryhmän kanssa. Marko Taipale toimii johtavana konsulttina Goseilla ja kehittää ketterään hankintaan liittyviä palveluita hankintavalmistelu.fi:ssa. marko.taipale@gosei.fi +358 40 578 6447 twitter: @markotaipale 44