Ketterä hankinta vaatii hyvän valmistelun ja ensimmäisen vaiheen suunnittelua

Projektin valmistelun ja suunnittelun ohittamista perustellaan usein ketterillä projektimalleilla, mutta projektin laadukas valmistelu ei ole ristiriidassa ketterän kehittämisen kanssa – päin vastoin.

North Patrol on suunnitteluun erikoistunut konsulttitoimisto. Suunnittelemme, autamme teknologiavalinnoissa, kilpailutamme. Emme myy toteutusprojekteja, emmekä lisenssejä, olemme aidosti asiakkaan puolella.

Sami Kalanen

19.4.2021

Sami Kalanen


Useimmat ketterät projektimenetelmät lähtevät siitä, että projektin visiota ja tärkeimpiä linjauksia koskevat suunnitelmat tehdään ennen ketterän toteutuksen aloittamista, ja yksityiskohtien suunnittelu tehdään osana toteutusvaiheen sprintejä.

Ketterissä menetelmissä projektin suunnittelun ja valmistelun työvaiheet on kuitenkin usein kuvattu hyvin kevyesti, tai yksinkertaisesti niissä on vain oletettu, että linjaukset on jo tehty ennen projektin käynnistämistä. Tämä johtaa usein siihen harhakäsitykseen, ettei ketteriin projekteihin lainkaan kuuluisi valmistelutyötä.

Product owner ei keksi vaatimuksia tyhjästä

Ketterissä menetelmissä (esim. Scrum) tuoteomistajan eli product ownerin vaativana roolina on välittää organisaation tarpeet ja prioriteetit toteuttajien tietoon. Usein erityisesti teknisten toimittajien odotuksena on, että asiakkaan product owner pystyisi yksin kuvaamaan hankkeen vaatimukset ja vastaamaan kaikkiin kysymyksiin ”lennosta”.

Product owner laatii ja priorisoi projektin backlogin, mutta esimerkiksi scrum ei juuri ota kantaa siihen, miten product owner sen tekee.

Projektin kehitysjonon eli backlogin luominen edellyttää kuitenkin paljon yhteistyötä, suunnittelua ja dokumentointia asiakasorganisaation sisällä. Projektin vaatimukset syntyvät harvoin product ownerin ”omasta päästä”, vaan ne perustuvat käyttäjiltä ja organisaatiolta kerättyihin tarpeisiin ja niiden pohjalta tehtävään suunnittelutyöhön, johon osallistuu usein laajojakin työryhmiä.

Hankkeen valmisteluvaiheessa tehty työ toimii toteutuksen aikaisen tarkemman suunnittelutyön pohjana ja mahdollistaa product ownerin mielekkään itsenäisen työskentelyn, kun projektin suuntaviivat on jo ennakkoon määritelty asiakasorganisaation sisällä.

Valmistelu- ja suunnittelutyön dokumentointi ketterässä prosessissa

Ketterät menetelmät korostavat toimivan ohjelmiston olevan ensisijainen tavoite, eikä dokumentaatiolla ole samaa itseisarvoa kuin useissa perinteisemmissä malleissa. Tämä ei kuitenkaan tarkoita, ettei ketterään projektiin sisältyisi suunnittelua ja suunnitelmien dokumentointia. Suunnittelua tehdään päinvastoin jatkuvasti, sekä ennen projektin käynnistystä että koko projektin ajan.

Seuraavassa kuvassa esitetty Agile alliancen malliin perustuva Microsoft Azure DevOps Boardsin dokumentointihierarkia kuvaa hyvin projektin tavoitteiden ja vaatimusten muodostaman hierarkian.

Ylätasolla olevat suunnitelmat (Portfolio Backlog; Epic, Feature) kuvaavat projektin tavoitteet ja keskeisimmät toiminnalliset vaatimukset, jotka määräytyvät jo ennen projektin käynnistystä. Tämän tason suunnitelmat linjataan yleensä projektin esiselvitysvaiheessa.

Toteutusvaiheen suunnitelmat (Backlog, User story, Task) taas syventävät vaatimusten määrittelyä sekä toteutuksen yksityiskohtia, ja ne tarkentuvat toteutuksen kuluessa. Ennen toteutuksen käynnistystä laadittu vaatimusmäärittely toimii toteutusvaiheen suunnitelmien pohjana.


Kuva 1. Suunnittelutyön dokumentointi ketterässä projektissa.
(Agile-prosessi: https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process )

Suunnittelu scrum-projektissa

Yleisimmin ohjelmistotyössä käytetyn projektimallin, Scrumin, ydin on sprinteinä tapahtuvan toteutustyön organisoinnissa ja hallinnassa. Scrum itsessään ottaa yllättävän vähän kantaa siihen, kuinka suunnittelutyö tulisi organisoida ennen projektia ja sen aikana.

Projektimalli olettaa, että projektilla on olemassa visio, mutta malli ei ota kantaa siihen, kuinka se syntyy. Projektimalli myös olettaa, että product owner laatii ja priorisoi projektin backlogin, mutta ei juuri ota kantaa siihen, miten product owner sen tekee.

Arkkitehtuurisuunnittelua (tai arkkitehdin roolia) scrum ei myöskään sisällä, vaan arkkitehtuurin oletetaan syntyvän ketterästi tiimin työnä. Käytännössä projektin onnistumisen kannalta on kuitenkin toivottavaa, että arkkitehtuuri on ainakin karkealla tasolla määritelty ennen kuin projekti käynnistyy.

Myöskään esim. käyttöliittymä- tai visuaaliselle suunnittelulle scrumissa ei ole varsinaista toimintatapaa, vaan sen oletetaan tapahtuvan toteutustiimin sisällä osana toteutusta. Tämä on ristiriidassa käytännön kanssa, sillä asiakasorganisaatio harvoin haluaa käynnistää toteutusta näkemättä minkäänlaista ajatusta lopputuloksen toiminta-ajatuksesta tai lopputuloksista.

Projektia edeltävä valmistelu- ja suunnitteluvaihe siis käytännössä vaaditaan lähes aina projektin käynnistämiseksi, mutta suunnittelutyötä ei yleensä piirretä auki scrum-prosessiin, vaan se ikään kuin piilotetaan ”kaikkivaltiaan” product owner -roolin sisälle.

Seuraavassa kuvassa on esitetty karkea kuvaus siitä, kuinka esiselvitys- ja vaatimusmäärittelyvaiheissa tehtävä valmistelu- ja suunnittelutyö käytännössä toimii scrum-projektin lähtökohtana.

Kuva 2. Esiselvitys ja vaatimusmäärittely Scrum-projektin lähtökohtina.
(Scrum-prosessi: https://scrumstudy.wordpress.com/2014/07/24/what-is-scrum/)

Vaatimusmäärittely on digiprojektissa keskeinen dokumentti, jonka avulla konkretisoidaan tietojärjestelmän tai verkkopalvelun suunnittelu, hahmotetaan tekniset ratkaisut, pyydetään toteuttajalta perusteltu työmäärä- tai kustannusarvio ja ohjataan ketterän toteutustyön työtehtäviä. North Patrolin vetämässä määrittelytyössä vaatimukset saadaan kirjattua laadukkaasti, asiantuntevasti ja kustannustehokkaasti.

Esiselvitys varmistaa projektin lähtökohdat

Riippumatta käytettävistä projektimenetelmistä, ennen uuden digihankkeen käynnistämistä projektin tavoitteet ja laajuus kannattaa aina tarkentaa tekemällä esiselvitys, joka toimii pohjana projektin tarkemmalle suunnittelulle ja toteutustyölle.

Ketterän projektin esiselvityksen tärkein tehtävä on tunnistaa, mitä projektin ensimmäiseltä julkaistavalta lopputulokselta (MVP) odotetaan.

Esiselvityksen tavoitteena on kirkastaa projektin tavoitteet ja sen lopputuloksena olevan ratkaisun pitkän tähtäimen visio sekä konkreettinen ensimmäisen vaiheen konsepti. Toinen tehtävä on luoda projektille riittävät linjaukset ratkaisun arkkitehtuurista ja käytettävistä teknologioista. Kolmas keskeinen tehtävä esiselvitysvaiheessa on luoda taloudelliset ja aikataululliset raamit projektin toteutukselle.

Hyvässä esiselvityksessä otetaan kantaa seuraaviin asioihin:

  • projektin tausta ja tavoitteet
  • alustava palvelukonsepti ja keskeiset vaatimukset
  • arkkitehtuuri ja toteutusteknologiat
  • työmäärä ja kustannukset
  • projektin vaiheistus ja aikataulu (tiekartta)
  • projektin resursointi, organisointi ja hallinta

Esiselvitysvaiheessa voidaan kartoittaa tarpeita esim. haastattelemalla ratkaisun käyttäjiä ja muita sidosryhmiä sekä kokeilla erilaisia ratkaisuvaihtoehtoja esim. kevyillä prototyypeillä. Ketterän projektin esiselvityksen ehkä tärkein tehtävä onkin tunnistaa, mitä projektin ensimmäiseltä julkaistavalta lopputulokselta (MVP) odotetaan.

Ketterä hankinta vaatii selkeän vision ja arkkitehtuuriratkaisut

Ketterien menetelmien käyttöä perustellaan usein sillä, että isoja, monimutkaisia järjestelmiä ei voi suunnitella etukäteen. Yksityiskohtien suunnittelu voidaankin hyvin jättää toteutusvaiheen tehtäväksi, mutta erityisesti suurissa kehittämishankkeissa selkeä visio ja arkkitehtuuriratkaisut ovat ensiarvoisen tärkeitä ketterän toteutuksen sujuvalle läpiviennille ja onnistuneille lopputuloksille.

Lue lisää: Tietojärjestelmähankkeiden esiselvitys – North Patrolin mallit ja menetelmät

PS. Sinua voisi kiinnostaa tulossa oleva ilmainen webinaarimme: Digitaaliset asiointipalvelut – Erilaiset konseptit ja toteutuksen eri vaihtoehdot (11.12.2024 klo 10:00). Ilmoittaudu webinaariin

Lue palveluistamme Pyydä tarjous

Sami Kalanen

DI Sami Kalanen on hankesuunnittelun, vaatimusmäärittelyjen ja kilpailutuksien asiantuntija. Sami konsultoi asiakkaita hankkeiden valmistelussa ja vaatimusten määrittelyssä sekä tukee asiakkaita projektien kilpailuttamisessa ja toimittajan työn valvonnassa. Hänen erityisalueitaan ovat mm. laajat, teknisesti haastavat verkkopalveluprojektit sekä julkishallinnon kilpailutukset.

Sami on työskennellyt verkkopalveluprojektien parissa 90-luvun puolivälistä lähtien. Aiemmassa työhistoriassaan Sami on toiminut mm. suuressa teollisuuskonsernissa verkkopalveluiden tilaajana, johtotehtävissä verkkopalveluja toimittavissa yrityksissä, puolueettoman konsultointitoimiston toimitusjohtajana ja partnerina sekä teleoperaattorin tuotepäällikkönä.

Asiointipalvelut ja ekstranetit

Autamme digitaalisten asiointikanavien suunnittelussa, määrittelyssä ja kilpailutuksessa. Etsimme asiakasystävälliset itsepalveluratkaisut, virtaviivaiset asiointiprosessit ja kustannustehokkaat teknologiat asiointiin, jäsenpalveluihin ja ekstranettiin.

Lue palveluistamme

Pyydä tarjous

North Patrol auttaa onnistumaan

Meitä on kymmenen konsulttia, kaikki kokeneita suunnittelijoita tai teknologia-asiantuntijoita. Joka vuosi viemme läpi yli 50 projektia, joissa autamme hankkeensa eri vaiheissa olevia asiakkaitamme luomaan uusia digipalveluja ja tietojärjestelmiä. Asiakkaamme ovat olleet erittäin tyytyväisiä työhömme (arvosana 9,5/10), ja monet heistä palaavat asiakkaiksi yhä uudestaan.

Olemme apunasi, kun kaipaat puolueetonta näkemystä teknologiavalintoihin, kirkastusta palvelukonseptin ideaan, tarkennusta vaatimusten määrittelyyn, konkreettista tukea tarjouskilpailuun tai ohjausta toteutusprojektin läpivientiin.

Ota selvää firmastamme

Miten erotumme kilpailijoistamme?

  • Digipalveluiden suunnitteluun erikoistuminen

    Olemme erikoistuneet digipalveluiden laadukkaaseen suunnittelutyöhön ja vaatimusmäärittelyyn. Missiomme on auttaa asiakkaita onnistumaan hankkeissaan luomalla mahdollisimman hyvät lähtökohdat toteutusvaiheelle – oli sitten kyse ketterästä toteutuksesta omalla tiimillä tai kumppanin kanssa tehtävästä hankkeesta tai julkisesti kilpailutettavasta urakasta.

  • Emme myy koodausta emmekä lisenssejä

    Moni teknologiakonsultti suosittelee asiakkailleen teknisiä ratkaisuja, joita sama talo myös toteuttaa. Meillä tätä vinoumaa ei ole. Tavoitteena on aina löytää asiakkaalle parhaiten soveltuva ohjelmistoratkaisu, oli se sitten räätälöity ratkaisu, saas-palvelu, avoimen lähdekoodin alusta tai näiden yhdistelmä.

  • Tehokkuus, tavoitteellisuus ja tuloksellisuus

    Toimeksiannoillemme sovitaan aina konkreettinen lopputuotos, jonka avulla asiakas pääsee hankkeessaan eteenpäin. Hioutuneiden menetelmiemme ja kokeneiden konsulttiemme ansiosta pystymme tuottamaan sen tehokkaasti, yllättävän vähäisillä työmäärillä, ja rahallesi syntyy vastinetta.

Siirry takaisin sivun alkuun