Ketterä projektimalli on tuttu monelle IT-alalla työskentelevälle. Ketterä kehitysmalli on lyönyt läpi ohjelmistoprojekteissa joustavuutensa ansiosta, joka on kriittisen tärkeää jatkuvasti muuttuvassa ja digitalisoituvassa liiketoimintaympäristössä. Koska ohjelmistokehitys vaatii tiimityötä, on kommunikaation ja päätöksenteon oltava jouhevaa ja tiimiläisten ymmärrettävä oma roolinsa. Tässä blogissa kerromme, mitä asiakkaan on hyvä muistaa ketterän ohjelmistoprojektin aikana.
Asiakkaan tärkein tehtävä ohjelmistoprojektin määrittelyvaiheessa on jakaa tietoa organisaation tarpeista ja kuvattava sen toimintaa liiketoimintaympäristössään. Avoin ja oma-aloitteinen kommunikaatio on avain määrittelyssä onnistumiseen. Koska kehitystiimi ei voi tuntea kaikkien toimialojen tai organisaatioiden ominaispiirteitä, on asiakkaan jaettava rohkeasti myös sellaista tietoa, jota kehitystiimi ei osaa edes kysyä.
Kehitystiimin tehtävä on jäsennellä asiakkaan jakama tieto ja mallintaa sen pohjalta ratkaisu, kuten integraatio tai ohjelmisto, joka vastaa asiakkaan haasteeseen. Tällöin on vastavuoroisesti kehitystiimin tehtävä auttaa asiakasta ymmärtämään heidän työtään. Esimerkiksi ohjelmistosuunnitelman tiekarttaan nimettyjen työvaiheiden priorisointiin on haastavaa ottaa kantaa, jos alan termistö ei ole hanskassa. Avoin kommunikaatio tarkoittaa myös sitä, että asiakas ja kehitystiimi puhuvat aina kansankielisesti. Molemmilla osapuolilla tulee olla rohkeutta kysyä aina termistöstä tai aiheesta, jota ei ymmärrä.
Ketterä projektimalli vaatii sitoutuneisuutta paitsi ohjelmistokehitystiimiltä myös työn tilanneelta asiakkaalta. Asiakkaan näkökulmasta ketterä kehitysmalli on antoisa tapa edetä digihankkeissa, sillä ohjelmiston logiikkaan voi tutustua projektin lomassa ja omat kehitysehdotukset näkee nopealla aikasyklillä käytännössä. Lisäksi projektin jatkuva arviointi takaa onnistuneen lopputuloksen. Ketterä toimintatapa vaatii kuitenkin ymmärrystä ja päätöksentekokykyä.
Päätöksentekoprosessi ei saa olla jäykkä, sillä ketterä projektimalli perustuu työn jatkuvaan arviointiin ja kehittämiseen. Tämä asettaa vaatimukset asiakkaan yhteyshenkilölle: hänellä tulee olla kykyä projektin ja ohjelmiston arviointiin, sekä päätäntävaltaa seuraavien askeleiden priorisointiin. Asiakkaan tehtävä on olla oman toimialansa asiantuntija, joten hänen täytyy luottaa kehitystiimin asiantuntijuuteen ohjelmistoprojektin suhteen. Määrittelyvaiheessa onkin tärkeää määritellä myös vastuualueiden rajat projektiin liittyviin päätöksiin. Mitä asiakkaan yhteyshenkilö saa päättää yksin ja millaisia päätöksiä kehitystiimi voi tehdä itsenäisesti?
Mitä ketterän projektimallin päätöksenteossa tulee ottaa huomioon?
Kuinka usein kokoonnutaan ja ketkä kuuluvat projektitiimiin?
Mitkä ovat päätöksentekokriteerit? Esimerkiksi kiireellisyys ja merkittävyysluokka
Mitä asiakkaan yhteyshenkilö saa päättää itsenäisesti ja kenen puoleen hän kääntyy suuremmissa päätöksissä?
Mitkä päätökset voidaan tehdä välittömästi esimerkiksi kehitystiimin kesken?
Miten päätökset dokumentoidaan ja missä dokumentaatio on kaikkien osallisten saatavilla?
Liian usein kuullaan tarinoita siitä, kuinka hanke ylitti budjettinsa. Budjettiohjauksen kannalta on tärkeää, että asiakkaan yhteyshenkilö tietää päätöstä tehdessään sen vaikutukset hankkeen kokonaisbudjettiin. Toimittajan onkin kommunikoitava asiakkaalle avoimesti tämän päätösten vaikutuksista hankkeen kokonaiskustannuksiin. Tämän lisäksi asiakkaan edustajan on onnistuttava viestimään tästä hankkeen ohjaus- ja sidosryhmille. Hyvä budjetinohjaus taataan laadukkaalla hankkeen kehitysjonon läpikäynnillä sekä avoimella ja riittävällä viestinnällä.
Ohjelmistoprojektissa tiimityöskentely on tärkeää kehitystiimin ja asiakkaan välillä. Saumaton kommunikaatio mahdollistaa onnistuneen ohjelmistoprojektin ja pitkäikäisen ohjelmiston, joka skaalautuu palvelemaan organisaation tarpeita muuttuvassa liiketoimintaympäristössä.
Mutta mitä kaikkea määrittelyvaiheessa tulee ottaa huomioon, jotta kehitys on tarpeeksi pitkäkantoista? Meillä Alfamella on vuosien kokemus onnistuneista ohjelmistoprojekteista, joten paketoimme yksiin kansiin oppaan ohjelmistokehityksen vaatimusmäärittelystä. Lataa opas!