Ohjelmistoprojektin hallinta: miten projekti pysyy aikataulussa ja budjetissa

Useimmat ohjelmistoprojektit, jotka ylittävät ajan ja budjetin, eivät kaadu teknisiin ongelmiin. Ne kaatuvat siihen, että ohjelmistoprojektin hallintaa ei kohdeltu ammattimaisesti alusta asti — laajuus oli epäselvä, päätökset olivat hitaita tai ongelmat tulivat esiin liian myöhään korjattaviksi edullisesti.

Tässä artikkelissa käymme läpi, miten ohjelmistoprojekteja hallitaan niin, että ne pysyvät raiteillaan — parhaat käytännöt, jotka erottavat toimittavan projektin jatkuvasti jatkettavasta, ja miten ne rakennetaan sisään alusta alkaen.

Laajuusongelma

Yleisin syy ohjelmistoprojektin hallinnan ongelmiin on laajuus, jota ei ole määritelty riittävän selkeästi alussa. Ei määrittelemätön — useimmilla projekteilla on kuvaus. Mutta kuvaus jättää riittävästi tulkinnanvaraa, ja nämä tulkinnat tulevat näkyviin vasta kun työ on käynnissä.

Ratkaisu ei ole spesifioida kaikki etukäteen. Ratkaisu on tunnistaa ne päätökset, joissa väärä oletus maksaisi viikkoja — ja ratkaista ne ennen kehityksen aloittamista.

Hyödyllinen kysymys jokaisen projektin alussa: jos rakennamme tarkalleen sen, mitä tässä kuvataan, ja se toimii täydellisesti, ratkeaako liiketoimintaongelma? Jos vastaus on epävarma, laajuus kaipaa lisätyötä.

Kiinteä laajuus vai avoin yhteistyö

Ohjelmistoprojektin hallinta näyttää erilaiselta riippuen siitä, miten yhteistyö on rakennettu. Kiinteän laajuuden projektit — joissa toimitettava, aikataulu ja budjetti sovitaan etukäteen — toimivat hyvin, kun vaatimukset ovat aidosti vakaita ja hyvin ymmärrettyjä.

Avoimet yhteistyösuhteet — joissa tiimi työskentelee jatkuvasti ja prioriteetit asetetaan viikoittain — sopivat paremmin tilanteisiin, joissa vaatimukset ovat vielä kehittymässä tai yrityksen täytyy pystyä muuttamaan suuntaa nopeasti.

Useimmat ohjelmistoprojektit asettuvat jonnekin näiden väliin. Sen ymmärtäminen, missä mallissa toimitaan — ja johtaminen sen mukaisesti — on yksi tärkeimmistä tekijöistä onnistuneessa toteutuksessa.

Miten ohjelmistoprojekteja hallitaan: projektin onnistunut aloitus

Hyvä ohjelmistoprojektin hallinta alkaa ennen ensimmäistä kehityspäivää. Muutama asia, joka merkitsee eniten rakennusvaiheessa:

Toimivaa ohjelmistoa toimitetaan usein — kahden viikon välein — ja se katselmoidaan niiden ihmisten kanssa, jotka tulevat käyttämään sitä. Kyse ei ole menetelmistä itsensä vuoksi. Kyse on tiedosta. Projekti, joka toimittaa kahden viikon välein, antaa liiketoiminnalle tietoa ajoissa ennen kuin päätökset kallistuvat.

Selvitetään, kuka voi tehdä mitkä päätökset ja kuinka nopeasti. Projektit hidastuvat, kun päätökset kestävät liian kauan. Tuote- tai projektivastaava, joka on oikeasti tavoitettavissa ja valtuutettu päättämään, on ohjelmistoprojektin hallinnalle arvokkaampi kuin johtotason henkilö, joka vastaa kolmen päivän kuluttua.

Laajuusmuutokset tehdään näkyviksi. Jokainen projekti kohtaa muutoksia. Kysymys ei ole siitä, muuttuuko laajuus, vaan miten muutoksia käsitellään. Projektit, jotka ottavat muutoksia vastaan epävirallisesti, päätyvät huomattavasti sovittua suuremmiksi — eikä kukaan ole selkeästi vastuussa erosta.

Mitä tämä tarkoittaa käytännössä

Muutama asia, joka tekee suurimman käytännön eron ohjelmistoprojektin hallinnassa:

Jonkun liiketoimintapuolelta täytyy olla tavoitettavissa koko projektin ajan. Kehittäjällä, joka ei saa vastausta, on kaksi vaihtoehtoa: odottaa tai tehdä oletus. Kahden päivän odottelu pienessä päätöksessä, useita kertoja viikossa, vaikuttaa merkittävästi toimitusaikatauluihin.

Päätökset dokumentoidaan niitä tehtäessä. Päätöksen perustelut ovat yhtä arvokkaat kuin itse päätös. Kuuden kuukauden kuluttua, kun konteksti on muuttunut, se on ero sujuvan sopeutumisen ja pitkän väittelyn välillä.

Lyhyet syklit pitävät tiimin rehellisenä. Aikataulusta jälkeen jääminen on vaikeampaa, kun se mitataan viikoissa. Ongelmat nousevat esiin aikaisemmin, kun niitä on vielä halvat korjata.

Mitä tehdä, kun projekti on jo jäljessä

Joskus projekti on jo jäljessä ennen kuin nämä mallit ovat käytössä. Ensimmäinen askel on rehellinen arvio: mitä sovittiin, mitä on toimitettu ja mikä on realistinen polku valmistumiseen.

Aikataulun venyttäminen toiveajattelun pohjalta ei auta ketään. Kehittäjien lisääminen myöhässä olevaan projektiin ei myöskään — integrointi vie aikaa, joka olisi voitu käyttää toimittamiseen.

Hyödyllisemmät vaihtoehdot ovat: jäljellä olevan laajuuden supistaminen välttämättömään, päätöksentekoprosessin selkeyttäminen tai jäljellä olevan työn jakaminen pienemmiksi toimituksiksi.

Mikään näistä ei ole helppo keskustelu. Mutta kaikki ovat hyödyllisempiä kuin optimismi.

Aikataulussa ja budjetissa pysyvät projektit ovat selkeän laajuuden, nopeiden päätösten, lyhyiden toimitusskylien ja rehellisten keskustelujen tulos. Hyvä ohjelmistoprojektin hallinta tarkoittaa näiden rakentamista sisään alusta alkaen.

Jos suunnittelette ohjelmistoprojektia ja haluatte miettiä, miten se kannattaa rakentaa, jutellaan siitä mielellään.