Business Analyst, Solution Analyst, vaatimusmäärittelijä vai ketterään kehitykseen viittaavat Epic Owner tai Product Owner? Mitä näiden titteleiden haltijat oikeastaan tekevät ja miksi hyvin samankaltaisista tehtävistä käytetään montaa eri nimikettä?

Tarpeiden tunnistamiseen ja kuvaamiseen liittyvä työ on keskeinen osa onnistuneita kehitysprojekteja, mutta sille on yllättävän vaikea löytää yhtä yhteistä käsitettä tai roolinimeä, joka terminä avautuisi samalla tavalla kaikille.

Jotkut puhuvat vaatimusmäärittelystä tai määrittelystä, toiselle sama tai ainakin melkein sama asia on palvelumuotoilua. Ketterissä malleissa taas puhutaan backlog refinementin tekemisestä. Tässä blogissa on pohdintaa siitä, miten myös tekijöiden roolinimet vaihtelevat ja yhteenvetoa siitä, mitä roolia pitäisi milloinkin käyttää.

Itselläni termi ”vaatimusmäärittelijä” kuulosti vielä vuosi sitten hieman vanhahtavalta 90-luvun termiltä. 2000-luvun alussa Big Four -konsulttiyrityksissä puhuttiin Business Analysteista, mutta tämä oli juniortason nimike eli usein se ensimmäinen nimike, jonka vasta opinahjostaan valmistunut konsultti saattoi saada.

Ketterissäkin menetelmissä määritellään vaatimuksia

Ketterissä toimintamalleissa, kuten SAFessa, nimikkeitä Business Analyst tai Requirement Analyst ei yleensä käytetä lainkaan. Tämä ei kuitenkaan tarkoita, etteikö ketterässä kehityksessä tehtäisi vaatimusmäärittelyä – päinvastoin. Vaatimusten tunnistaminen, tarkentaminen ja priorisointi ovat keskeinen osa ketterää tekemistä, vaikka työ jakautuukin useamman roolin kesken.

Ketterät mallit korostavat asiakaslähtöisyyttä ja nimenomaan sellaisten tuoteominaisuuksien rakentamista, joille olisi suurin tarve ja liiketoiminnallinen arvo. Ketterässä mallissa vaatimuksia määrittelee ja käsittelee useampi eri taho. Vaatimukset omistaa Epic Owner, joka ottaa vastuun tietyn osa-alueen liiketoiminnallisista tarpeista, tietystä ylätason kehitysteemasta. Epic Owner toimii tiiviissä yhteistyössä Product Ownerien kanssa, joiden tehtävänä taas on priorisoida ketterän tiimin tekemistä tietyllä (teknisellä) osa-alueella.

Monissa organisaatioissa toimintamalli ei kuitenkaan ole puhtaasti ketterä tai perinteinen, vaan jotain näiden väliltä. Tällöin myös roolinimikkeet alkavat elää. Tässä kontekstissa johtava vaatimusmäärittelijä toimii luontevana yläkäsitteenä, joka ei sido tekemistä tiettyyn menetelmään, vaan se kuvaa vastuuta ja osaamisen tasoa mallista riippumatta.

Viime aikoina vaatimusmäärittely ja siihen liittyvä terminologia ovat nousseet uudelleen esiin keskusteluissa. Erityisesti nyt, kun tekoäly tehostaa itse koodaamista, kehityksen seuraava pullonkaula nähdään yhä useammin juuri tarpeiden tunnistamisessa, jäsentämisessä ja kuvaamisessa. Tämä tekee vaatimusmäärittelytyöstä ajankohtaisempaa kuin pitkään aikaan.

Selkeyttä vaatimusmäärittelijä-termien viidakkoon

Termien merkitykset, eroavaisuudet ja suhteet toisiinsa jäivät kuitenkin mietityttämään itseäni ja ryhdyin pohtimaan, miltä nämä asiat näyttäisivät käsitemallissa. Olen erittäin ihastunut kaikenlaisiin kaavioihin ja halusin nähdä miltä termiviidakko näyttää kuvaksi piirrettynä. Kaikkein parasta ja kivointa on piirtää kaavio ihan itse, mutta tällä kertaa pyysin apuja AI:lta.

Muutama loppupäätelmä termeistä vaatimusmäärittelijä, Solutions Analyst ja Business Analyst

Ajatus 1:

Termit vaatimusmäärittelijä ja Business Analyst tarkoittavat akateemisella tasolla periaatteessa hieman eri asioita: vaatimusmäärittelijä keskittyy tietojärjestelmävaatimuksiin ja Business Analyst liiketoiminnan analyysiin.

Käytännössä näitä molempia rooleja tekee kuitenkin usein yksi ja sama henkilö. Tällöin taitaa olla makuasia, kumpaa nimikettä tästä henkilöstä käytetään. Vaatimusmäärittelijän on työssään selvitettävä liiketoiminnan, eli siis asiakkaan tarpeita, joten hän tekee työnsä ohella liiketoiminnan analyysia. Toisaalta liiketoiminnan analyysiä ei oikein enää nykyään pysty tekemään ottamatta kantaa tietojärjestelmiin. Organisaatioissa on harvoin enää prosesseja tai toimintoja, joilla ei ole minkäänlaista tietojärjestelmätukea.

Ajatus 2:

Ketterässä mallissa on selvää, että Epic Owner ja Product Owner ovat kokeneen ammattilaisen rooleja, joihin liittyy paljon vastuuta ja päätöksentekoa.

Vaatimusmäärittelijällä ja Business Analystilla ei perinteisessä vesiputousmallissa useinkaan ole ihan samanlaista päätöksentekovaltaa kuin Epic ja Product Ownereilla ketterässä mallissa. Tämän vuoksi voi tuntua, että nämä roolit (vaatimusmäärittelijä ja Business Analyst) ovat tehtäviä, joita juuri opinajostaan valmistunut voisi tehdä ensimmäisinä töinään.

Kun me puhumme johtavasta vaatimusmäärittelijästä, haluamme korostaa sitä, että kyseisessä roolissa toimivan täytyy haluta ja uskaltaa ottaa vaatimuksista vastuu. Toinen vaihtoehto voisi olla Requirements Manager, mutta tämä taipuu hieman monimutkaiseksi suomennokseksi. Vai kuulostaako vaatimustenhallintapäällikkö sittenkin vakuuttavalta?

Palvelumuotoilija-nimikkeellä toimiva puolestaan tekee vähän samaa, mutta kuitenkin hieman eri asiaa kuin vaatimusmäärittelijä. Tästä taitaakin tulla seuraavan blogin aihe.

Miten on sinun organisaatiossasi? Millaisia nimikkeitä vaatimusmäärittelyyn liittyen teiltä löytyy?