Jos tietojärjestelmän tekisin

Hypoteettinen ajatusleikki: mitä tekisin jos minut laitettaisiin kehittämään tietojärjestelmää, jonka eteneminen on jämähtänyt byrokratiaan: suunnitelmien viilaamiseen, kokouksien pyörittämiseen ja neuvotteluihin? (Tämä ei viittaa mihinkään tiettyyn järjestelmään, mutta ottaa aineksia useasta todellisesta hankkeesta.)

 
Ensimmäiseksi nyhtäisin osallisista irti hankkeen ja järjestelmän todellisen ja täsmällisen tarkoituksen. Tämä kun on usein piilossa prosessi- ja välinekuvausten alla. Tarkoituksena ei ole tehdä järjestelmää, tietokantaa tai palvelua, vaan ratkaista jokin ongelma. Tai useampi ongelma, joilla on prioriteettijärjestys.

Sitten katsoisin onko hanke mitenkään järkevä suhteessa resursseihin, ja että ratkaistavana oleva ongelma voidaan ylipäätään ratkaista tietojärjestelmän avulla. Usein ongelma on suurelta osin epätekninen – esim. puuttuvaa luottamusta tai erimielisyyksiä toimintaperiaatteista voi olla vaikea ratkaista tietojärjestelmällä. Oletetaan että hanke on järkevä, ja että mukana on ainakin yhden osaavan ohjelmoijan kehitystiimi.

Seuraavaksi ottaisin Scrum product ownerin (= tuoteomistajan?) roolin. Minä päättäisin mitä tehdään ja olisin vastuussa tavoitteiden saavuttamisesta. Jos päätösvalta on ollut aiemmin ohjausryhmällä, komitealla tai muulla keskustelukerholla, saa se toki jatkaa toimintaansa, mutta vain neuvoa-antavana. Päätökset tekisin yksin. Myöskään kirjoittamattomia sääntöjä ja perinteitä en huomioisi, paitsi ongelman ymmärtämisessä.

Kehittämisessä käytettäisiin ketteriä menetelmiä, tietty. Julistaisin että ensimmäinen versio on valmiina kahden viikon päästä. Viikko tehtäisiin töitä, toinen viikko olisi varalla mm. kädenvääntöön entisten vastuuhenkilöiden kanssa.

Product ownerina tapaisin niitä joiden ongelmaa ollaan ratkaisemassa, sekä kuuntelisin ja kyselisin. Tavoitteena on ymmärtää nykytilaa, tavoitetilaa ja niiden välistä ristiriitaa. Ihmisiltä ei kannata kysyä mitä pitäisi tehdä (tästä päättää product owner), vaan mitä on tehty, mitä ongelmia on ollut, mitä pitäisi saavuttaa ja miksi.

Kun olisin ymmärtänyt perusasiat, suunnittelisin kehitystiimin kanssa yksinkertaisimman mahdollisen välineen, joka on käyttäjille hyödyllinen (suhteessa nykytilaan) ja ratkaisee palan ongelmasta. Tässä vaiheessa kilpailtaisiin hullujen ideoiden tuottamisessa – voittaja on se joka ideoi eniten. Näistä sitten muovailtaisiin järkevä suunnitelma.

Product ownerin ja kehitystiimin välisessä keskustelussa olisi tärkeää että kaikki ymmärtävät mitä ollaan tavoittelemassa: mitä ongelmia tehtävillä ominaisuuksilla ollaan ratkaisemassa. Ongelman ymmärtäminen antaa kaikille mahdollisuuden ehdottaa parempia ratkaisuja. Ei voida olettaa että product owner osaisi valita parhaat tekniset ratkaisut joka tehtävään.

Suunnitelmat julkaistaisiin avoimesti kaikkien ihmeteltäviksi. Kuuntelisin kommentteja ja vastaväitteitä, mutta vain ymmärtääkseni paremmin ratkaistavan ongelman luonnetta (enkä suinkaan noudattaakseen kritiikkiä).

Kehitystiimi valitsisi käytettävän tekniikan: tietokanta-alustan, ohjelmointikielen, käytettävät frameworkit jne. Tekniset ratkaisut tehtäisiin kun niiden aika tulee eteen, ei aiemmin. Ongelmat kun ovat usein erilaisia kuin ennakoitiin, ja tulevat eteen eri aikaan kuin suunniteltiin.

Jos (kun) resurssit olisivat niukkoja, tähdättäisiin kaikessa yksinkertaisuuteen ja joustavuuteen. Elegantit ja oppikirjanmukaiset suunnitelmat ovat turhia, jos niitä ei pystytä toteuttamaan käytettävässä ajassa.

Kun jossain täytyisi joustaa, joustettaisiin vähentämällä ominaisuuksia tai tekemällä asiat yksinkertaisemmin. Aikataulussa ei lipsuta, vaan seuraava versio julkaistaan kahden viikon jakson päättyessä.

Product ownerina huolehtisin että kukaan ei pääse häiritsemään kehitystiimiä jakson aikana, esim. vaatimalla käyttäjätukea tai uusia ominaisuuksia.

Kahden viikon kuluttua julkaistaisiin ensimmäinen versio järjestelmästä.

Jos päättävä taho toteaisi että hanketta ei jatketa, olisi lopputuloksena toimiva järjestelmä, joka tekee edes jotain. Jos hanketta jatkettaisiin, alkaisi kierto taas alusta.

 
Tämä on vain hieman kärjistetty esimerkki. Kun kerroin product ownerina tämänsuuntaisista kehitysmenetelmistä norjalaisille kollegoille, totesivat he kaksi asiaa: ”Ehkä meidän pitäisi lähettää kehittäjämme oppimaan tänne eikä Ruotsiin” ja ”Ihmettelen että olet vielä elossa!” Onnistuminen ei toki tällä menetelmällä ole varmaa, mutta kuitenkin todennäköisempää ja nopeampaa kuin komitea-vesiputousmallilla, ainakin jos product owner osaa hommansa.

Kommentteja?