Seuraavassa Ihku-laskentapalvelun julkaisuversiossa (1.3) on yksi eniten toivotuimmista ominaisuuksista eli hankekansiot. Tämä ominaisuus on ollut suunnittelupöydällä jo pitkään ja vihdoinkin pääsemme julkaisemaan ominaisuudesta ensimmäisen, toiminnallisen kokonaisuuden kaikille käyttäjille.
Lähtökohtana toteutukselle, kuten yleensäkin Ihku-laskentajärjestelmää suunniteltaessa, oli ymmärtää käyttäjän tarvetta ja sitä haastetta, jota ominaisuus tulisi ratkaisemaan. Tarpeet vaihtelivat hankehausta aina eri suunnitteluvaiheiden hallintaan. Eri käyttäjäryhmillä (organisaation pääkäyttäjät, konsultit, suunnittelijat) oli kaikilla hieman oma näkemyksensä tarpeesta ja mahdollisesta toteutuksesta.
Hankekansioiden toiminnallisuutta on testattu sisäisissä testiympäristöissämme ja lisää uusia toiminnallisuuksia ei näillä näkymin ole tulossa tähän julkaisuversioon. Julkaisun kylkiäisinä kirjoitamme myös ohjeistukseemme uuden ominaisuuden toiminnan käyttöohjeet. Ohjeet julkaistaan ominaisuuden julkaisun yhteydessä.
Kehittäjämme ja hankeosalaskennan määrittelyn vetäjä Tomi Räsänen kertoo, miten hankekansion kehitys eteni ja miten ne saivat kohta julkaistavan muotonsa.
“Tällä rakkaalla lapsella on ollut monta nimeä: hankelinkitys, hankesalkku, hankeryhmä,… Päädyimme sanaan kansio, joka kuvastaa sitä hierarkiaa joka käyttäjille on tuttu mm. Windows-maailman tiedostojen kansiorakenteesta.” Räsänen aloittaa.
Kuvateksti: Rautalankaa: Mitäs jos sittenkin tunnistesanojen avulla?
“Ensimmäisiä hahmotelmia hankekansioiden ideologiasta piirreltiin valkotaululle Big Roomissa jo keväällä 2019.” muistelee Räsänen.
Hankekansioiden kehityspolku ei ole poikkeava kun puhutaan ohjelmistoprojektista. Arki on sitä, että asioita pitää priorisoida ja joskus olennaiselta tuntuvat ominaisuudet joutuvat väistymään vielä tärkeämpien toiminnallisuuksien tieltä.
“Ensimmäisissä suunnitelmissa ymmärsimme sen, että Ihkun Hanke, joka voi sisältää rajoittamattoman määrän laskelmia ja rakennusosia, on liian pieni yksikkö. Pohdittiin ylemmän tason mahdollisuutta, Projektia. Siinä ajatuksena oli, että useita hankkeita voisi yhdistää massiiviseksi projektiksi, joka auttaisi sisarhankkeita kulkemaan Ihkussa käsi kädessä. Siitä päästiin uuden määrittelyn äärellle: mikä on sisarhanke? Missä kulkee hankkeen raja? Tässä vaiheessa haastattelimme sekä suunnittelijoita että tilaajakaupunkien edustajia.” Räsänen summaa alkuvaiheen suunnitelmia ja haasteita.
Kuvateksti: Rautalankaa: Miten käyttäjä navigoi hankekansioihin?
Samaan aikaan pohdinnassa oli, että voisiko uudella ratkaisulla tukea hankkeiden löytymistä Ihkussa. Yhtenä kehitysaihiona oli nimittäin, samaan aikaan hankekansioiden kanssa, hankkeiden löytämisen ja haun parantaminen. Olimme saaneet hyvää palautetta rakennusosakirjaston hausta ja pohdimme miten hankkeiden haun pitäisi toimia. Pyrkimyksenä oli, parhaassa tapauksessa, ratkaista useampi käyttäjätarve yhdellä ratkaisulla. “Useamman käyttäjätarpeen ratkaiseminen yhtä aikaa on hieman riskaabelia, mutta oikein tehtynä resursseja säästävää ja käytettävyyttä parantavaa toimintaa.” Räsänen kommentoi.
“Jossain vaiheessa ideamoottorit ja villit, toiveiden tynnyreitä täyttävät keskustelut, piti lopettaa ja siirtyä takaisin käytännöllisyyteen. Hylkäsimme kasan rautalankoja ja valitsimme parhaiten toimivia ideoita jatkojalostukseen. Tässä vaiheessa määrittelyä siirryimme rautalangoista JIRAan.” Räsänen kertoo kehityksen etenemisestä.
Jira on Ihku-allianssissa käytetty työnohjauksen ja priorisoinnin työväline, jonka läpi kaikki toteutukseen asti päässeet ominaisuudet kahlaavat tiensä. Jirassa ominaisuuksia hyväksytetään, testataan, iteroidaan, toteutetaan ja tuotannoidaan.
Hyvin suunniteltu on puoliksi suunniteltu
Usein ohjelmistokehityksen, ja varsinkin ketterän sellaisen, ominaisuus on että tieto tarkentuu ja lisääntyy ominaisuuksien valmistumisen edetessä. Hankekansiot ei ollut poikkeus tässä suhteessa.
Räsänen kuvailee määrittelyn ja sovelluskehityksen rajapintojen ongelmallisuutta: “Valmiiksi määritellyt tiketit (pienin toteutettava osa kokonaisuudesta) eivät sitten olleetkaan valmiita, kun ohjelmistokehittäjät (eli devaajat) ottivat homman työpöydilleen. Se missä määrittely oli kauniisti hahmotellut toiminnalliset tarpeet, kehittäjät tarvitsevat laadukkaaseen toteutukseen yksityiskohtaiset tiedot ja tarkat määritykset kaikelle. Ja kaikella tarkoitan kaikkea: pikselin värikoodista tietokannan toimintaan ja kaikki siltä väliltä. Pikselin väri löytyy graafikon työkalusta Figmasta ja tietokannan toiminnasta kehittäjät sopivat yhteiset periaatteet omissa teknisissä kokouksissaan. Esimerkkinä voisin antaa, että kun kansio poistetaan, poistetaanko se vai merkitäänkö se vain poistetuksi? Kaikki tämä tieto löytyy Jiran tiketeiltä.”
Kuvateksti: Jira: Hankekansioiden tehtävälistaa
Tässä kohtaa määrittelyä tiedostettiin myös tarve muuttaa hankkeen tilaa. Jatkossa hankkeen voi siis merkitä aktiiviseksi, passiiviseksi tai rakennetuksi. Tällä tavoin myös hankekansionäkymässä voi suodattaa itselleen merkityksellisiä hankkeita.
Kuvateksti: Testiympäristö: Valmistuneita ominaisuuksia testataan omassa ympäristössään yhdessä kehittäjien, määrittelijöiden ja käyttäjien kanssa
