Projektin ei tarvitse olla painajainen



Lähes jokainen voi hyvällä omallatunnolla sanoa olleensa mukana projektissa tavalla tai toisella. Ja ihan liian iso osa on kokenut myös projektityöhön liittyvää epäselvyyttä, aikataulupaineita ja projektiriippuvuuksien tuskaa, mistä syystä pahimmillaan projektista on tullut sallittu synonyymi painajaiselle. Projektin onnistumisen kannalta on tärkeää, että tavoite ja sen tekemiseksi tarvittavat resurssit ja aikataulu on ymmärretty oikein. Ketterien menetelmien käyttö puolestaan lyhentää palautesykliä ja mahdollistaa dynaamiset muutokset aikataulussa, tavoitteissa ja resursseissa.

Ohjelmistoprojektien monimutkaisuudesta

Neutraalisti katsottuna projekti on kokonaisuus, jolle on määritelty ajallinen alku, loppu ja selkeä päämäärä sekä tekijät, joilla päämäärä on saavutettavissa. Varsinkin isomman kokoluokan projekteissa kompleksisuutta lisäävät erilaiset riippuvuudet.

Ohjelmistopuolella kompleksisuus johtuu usein myös systeemien monimutkaisuudesta, olemassa olevan ympäristön perintönä saadusta vanhentuneesta koodista tai pysyvästi sementoiduista taaksepäin yhteensopivuus -vaatimuksista. Tai kun on otettu teknistä velkaa jättämällä koodin siivous kiireessä sivuun.

Ohjelmistoprojektien haasteet harvoin tekijöiden syytä

Harvoin ohjelmistoprojektien ongelmat liittyvät kuitenkaan tekijäporukkaan, joka yleensä koostuu asiantuntijoista ja alansa ammattilaisista. Heillä on tarvittava osaaminen ja halu oppia, joilla taklataan kiukkuisimmatkin riippuvuudet tai tekniset haasteet. He osaavat myös määrittää järkevät etenemisvaihtoehdot, kun törmätään isompaan siirtokivilohkareeseen.

Mikä ohjelmistoprojekteissa sitten mättää?

Mikä ohjelmistoprojekteista sitten tekee niin kiharaisia? Ja miksi asiakkaat saavat eteensä järjestelmiä tai käyttöliittymiä ymmärryksen tuolta puolen? Vastauksia lienee yhtä monta kuin on tuuliajolle menneitä projektejakin. Usein taustalla kuitenkin kytee tekemisen jäykkyys tai joku seuraavista perustavaa laatua olevista projektihelmasynneistä – perinteisen projektikolmion kautta katseltuna:

Puhun mielelläni ohjelmistokehityksessä ihmisistä resurssien sijaan ihan vaan siksi, että ihmiset ne käytännössä toteuttavat ohjelmistojen toiminnallisuudet. Muu resursointi tulee yleensä laiteinvestointien, jne. puolesta ja näillä katetaan pidemmän aikavälin tarpeita.

1. Epäselvä tai epärealistinen tavoite

Selkeys siitä, mitä on tarkoitus saada aikaiseksi näyttelee isoa roolia projektin onnistumisessa. Harmittavan usein (sisäinen/ulkoinen) asiakas tai arkkitehti lähtee harhailemaan tontiltaan ja päätyy kuvaamaan sitä, miten hänen haluamansa asia toteutetaan, kun se mitä oikeasti tarvittaisiin, olisi selkeä tarpeen kuvaus. Kehittäjät kyllä keksivät järkevimmän toteutustavan, kunhan heille kerrotaan mitä halutaan ja miksi. Speksailu vailla vastuuta kokonaisjärjestelmän toimivuudesta on tietysti jännää, mutta useimmiten se hidastaa ja hankaloittaa kehitystiimien työtä –  heille kun olennaisinta olisi saada ymmärrys siitä, mitä halutaan. Näennäisen valmiin ratkaisun ojentaminen kehittäjille alentaa heidät samalla puhtaiksi koodikirjureiksi, mikä myös syö tekijöiden motivaatiota.

Ajan käyttäminen siihen, että pystyy kertomaan selkeästi mikä on ratkaistava ongelma, missä asiayhteydessä ongelma esiintyy ja millainen vaikutus sillä on asiakkaan elämään on tärkein panostus, jonka tilaajapuoli voi kehitystyölle antaa. Lopusta huolehtivat asiansa osaavat ja systeemiä ylpeydellä ylläpitävät koodarit.

2. Riittämättömät resurssit tavoitteen saavuttamiseksi

Eli keksitään se Hillittömän Hieno Juttu, joka tarttis tehdä ja mielellään heti. Sitten ei kuitenkaan olla valmiita valitsemaan niitä asioita, mitä sitten jätetään tekemättä tai miettimään, mikä oikeasti on paras taho toteuttamaan haluttu toiminnallisuus ja mitä nämä tiimit parhaillaan tekevät. Tai kieltäydytään kuulemasta toteuttajien arviota siitä, millaisella työpanoksella toiminnallisuus on tehtävissä.

Taas kerran tullaan siis takaisin siihen, että pitäisi olla kyky ja halu miettiä, mikä nyt olikaan tekemisen tärkeysjärjestys ja mihin rahkeet riittävät. Tai pohtia, mitä se tarkoittaa, kun järjestelmään lähdetään lisäämään toiminnallisuutta ns. sankaritöinä. Valmis toiminnallisuus pitäisi kuitenkin nähdä myös ylläpidon, skaalautuvuuden, suorituskyvyn ja jatkokehityksen, jne. vinkkelistä. Puoliksi tai sinnepäin tehdyt toiminnallisuudet ja järjestelmät ovat ne kalleimmat toteutuksen puolesta, oli tekijä sitten omasta talosta haalittu iskujoukko tai ulkoinen konsultti.

Ohjelmistoprojektit harvoin onnistuvat sillä, että liiketoimintapuolen Excel saadaan näyttämään rivit nätisti. Ihmisten osaamisen taso, oppimiskäyrä tai vaikkapa koodaamisen nopeus eivät ole vakioita ja riippuvat paljolti esim. käytettävien teknologioiden tai kielten tuttuudesta. Kehittäjätkin ovat ihmisiä, joilla on oma työn ulkopuolinen elämä (vaikka legenda toisin väittääkin). Heillä on yhtä lailla perheitä, koiria, lomia ja tarpeita hoitaa ne samat pankkiasiat kuin tilaajillakin. Tällaiset pitää huomioida, kun mietitään missä ajassa lopputulos voi realistisesti valmistua.

3. Epärealistinen aikataulu

Yllämainittujen lisäksi projektin onnistumiseen voi helposti vaikuttaa asettamalla aikataulun, jossa on mahdotonta pysyä ottaen huomioon asetetut (epäselvät/ristiriitaiset) tavoitteet ja (puuttuvat) kehittäjät.

Epäonnistumista voi pedata sillä, että ei kysytä asiantuntijoilta, mitä toiminnallisuuden toteuttaminen aidosti vaatii ja neuvotella sen jälkeen riittävästä toteutuksen tasosta – aikataulu, haluttu laatutaso ja tekijöiden saatavuus huomioiden. Kun luullaan, että yhden valintaruudun toteutus hoituu yhtä sukkelaan kuin designerin  flash-animaationa toteuttama näkymä, vaikka taustajärjestelmiin saman toteuttaminen myös niiden ei-toivottujen käyttäjätarinoiden (ns. rainy day -skenaariot) ja lokituksen & auditoinnin kanssa on huomattavasti työläämpää. Ja näitähän tehdään, jotta käyttäjiä voidaan jatkossa myös tukea. Tästähän ei se flash-animaatio kerro mitään.

Lue lisää Pimeän agilen välttämisestä.

Ketterä toteutus kokonaisuudessaan edullisempi

Valittu tapa tehdä ohjelmistoprojekti on kunkin organisaation päätettävissä. Itse olen paketoinut projekteja sekä vesiputousmallilla että ketterillä menetelmillä, eikä menetelmä itsessään ole kynnyskysymys.

Jos valita saan, hoidan projektini ketterästi. En siksi, että se olisi jollain tapaa viileämpää jutella ketterästi Scrumia tai Kanbania, vaan siksi, että ketterä toteutustapa mahdollistaa käyttäjää paremmin palvelevan ja kokonaiskuvassa edullisemmaksi tulevan toteutuksen.

Nopeat muutokset, joita väistämättä tulee, ovat mahdollisia niin tavoitteissa, budjetoinnissa kuin aikataulussa – maailma harvoin pysähtyy odottamaan, että juuri minun edellisenä vuonna kerran määrittelemäni projekti valmistuu seuraavaksi jouluksi muuttumattomana.

Kullankallis käyttäjäpalaute

Mitä nopeammin aidot käyttäjät pääsevät testaamaan ominaisuuksia, sitä nopeammin saadaan palautetta kehitystyöhön sekä korjauksia takaisin ominaisuuksiin. Pienilläkin muutoksilla on toisinaan ratkaiseva merkitys käyttäjän kannalta – ketterässä kehityksessä nopea palautesykli ja jatkuva parantaminen kuuluvat tekemisen luonteeseen.

Minusta projekteja on aina ollut hauskaa tehdä, kiitos ässien kehitystiimien ja arvokkaan asiakaspalautteen. Projektit rullaavat varsinkin, jos ne on valmisteltu huomioiden kolme kulmakiveä:

  1. tavoite
  2. ihmiset + mahdolliset muut resurssit
  3. aikataulu.

Kaikki muu on sen jälkeen pienempää ratkottavaa.

 

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *