Miksi ohjelmistoprojekti kestää pidempään kuin arvioitu

Lähes jokainen, joka on tilannut ohjelmistoprojektin, tunnistaa saman kaavan: alkuperäinen aikataulu vaikutti järkevältä, ja silti julkaisu tapahtui kuukausia myöhässä. Selitykseksi tarjotaan usein “ohjelmistokehitys on vain vaikeaa,” mikä on totta juuri sen verran, että se ei auta ketään. Viive syntyy lähes aina muutamassa ennustettavassa kohdassa, ei satunnaisesti pitkin projektia.

Epäselvä laajuus on ensimmäinen ja suurin syy

Projekti, joka alkaa lauseella “rakentakaa meille varausjärjestelmä” ilman kirjoitettua kuvausta näytöistä, käyttäjärooleista ja siitä, mikä on nimenomaisesti rajattu pois, on jo jäljessä aikataulusta — kehitystiimi käyttää aikataulun sen selvittämiseen sen sijaan, että suunnittelisi sen ympärille. Kyse ei ole huonosta tiimistä, vaan siitä, milloin vaikeat kysymykset esitettiin.

Kunnollinen määrittelyvaihe ennen rakentamisen alkua siirtää nämä kysymykset kohtaan, jossa niihin vastaaminen on halpaa, sen sijaan että ne ilmaantuisivat kesken neljännen sprintin muodossa “hetkinen, piti tämän roolin nähdä myös raportit?”

Toisen järjestelmän rajapinta ei ole koskaan niin selvä kuin paperilla

Projekti, jonka pitää integroitua kirjanpitojärjestelmään, ERP:hen tai maksupalveluun, perii toisen osapuolen dokumentaation — tai sen puutteen. Rajapinta, joka näyttää dokumentaatiossa hyvältä, voi paljastua hitaaksi testiympäristöltä, puutteelliselta virheenkäsittelyltä tai pääsyltä, joka vaatii tukipyynnön kolmannelle osapuolelle, jota kumpikaan projektin osapuoli ei hallitse. Tämä ei ole tekosyy, vaan riski, joka pitää kirjata aikatauluun alusta lähtien puskurina, ei myöhemmin yllätyksenä.

Hyväksymiskierrokset ovat usein piilotettu pullonkaula

Luonnos, joka odottaa viikon vastausta päättäjältä, ei menetä vain sitä viikkoa — se menettää vauhdin, ja seuraava jonossa oleva tehtävä aloitetaan usein väärältä pohjalta odottamisen aikana. Projektit, joissa on nopea, ennustettava palaute yhdeltä vastuuhenkilöltä, etenevät selvästi nopeammin kuin projektit, joissa hyväksyntä vaatii kokouksen, joka löytyy kalenterista vasta kahden viikon päästä.

Viiveen syy	Mikä oikeasti auttaa
Epäselvä laajuus alussa	Kirjoitettu määrittely ennen koodausta
Epäselvä kolmannen osapuolen rajapinta	Puskuri aikatauluun, varhainen tekninen selvitys
Hidas hyväksyntä	Yksi vastuullinen päättäjä, kiinteä vastausaika
Myöhäiset muutokset laajuuteen	Vaiheistettu toimitus, näkyvät välitulokset joka toinen viikko

Myöhäiset muutokset maksavat enemmän kuin samat muutokset alussa

Uusi ominaisuus, joka lisätään toisella viikolla, maksaa yleensä juuri sen verran kuin se maksaa. Sama ominaisuus lisättynä kymmenennellä viikolla voi vaatia jo rakennetun logiikan purkamista, koska sitä ei suunniteltu mukaan alusta lähtien. Mielen muuttaminen kesken projektin ei ole kohtuutonta — kohtuutonta on olettaa, että se on ilmaista tehdä myöhään.

Jatkuvat, näkyvät toimitukset joka toinen viikko ovat tähän tehokkain vastalääke, ei siksi että se pakottaisi asiakkaan päättämään nopeammin, vaan koska väärä oletus tulee näkyväksi toisella viikolla oikeana näyttönä sen sijaan että se paljastuisi kymmenennellä viikolla yllätyksenä.

Mitä voitte itse tehdä ennen projektin alkua

Yksittäinen asia, joka säästää eniten aikaa teidän eduksenne, on nimetä yksi päättäjä ennen koodauksen alkua — ei työryhmää, vaan yksi henkilö, jolla on valtuudet sanoa kyllä tai ei ilman erillistä kokousta jokaista päätöstä varten. Se kuulostaa pieneltä asialta. Käytännössä se on usein juuri se ero, joka ratkaisee, pitääkö aikataulu vai ei.

Toiseksi hyödyllisintä on varmistaa, että pääsyt ja tunnukset integroitaviin järjestelmiin ovat valmiina ennen rakentamisen alkua, ei tehtävänä, joka etsitään esiin vasta kun kehittäjät kysyvät niitä. Viikon odotus kolmannen osapuolen toimittajan myöntämälle pääsyoikeudelle vie aikataulusta yhtä paljon kuin tekninen viive, vaikka kyse ei ole yhdestäkään koodirivistä kyseisellä viikolla.

Mitä sopimuksesta kannattaa tarkistaa etukäteen

Tarjous, joka lupaa tietyn valmistumispäivän mutta ei kerro, mitä tapahtuu jos asiakkaan puolelta tuleva palaute viipyy, jättää riskin näkymättömäksi kunnes se toteutuu. Kannattaa kysyä suoraan, miten aikataulu muuttuu, jos hyväksymiskierros venyy, ja kuka siitä vastaa. Rehellinen toimittaja osaa vastata tähän etukäteen, ei vasta kun viive on jo tapahtunut.

Mitä realistinen aika-arvio oikeasti sisältää

Aika-arvio, joka laskee mukaan vain koodaukseen kuluvan ajan, ei ole realistinen arvio — siitä puuttuu määrittely, integraatiotestaus, hyväksymiskierrokset ja puskuri sille ennakoimattomalle, joka ilmaantuu lähes jokaisessa tietyn kokoluokan projektissa. Rakennamme tämän puskurin näkyväksi osaksi aikataulua sen sijaan, että se ilmenisi hiljaisena viiveenä, josta kukaan ei ole etukäteen puhunut.

Tämä tarkoittaa myös, että tarjous ilman kuvausta siitä, kuka päättää mitäkin ja kuinka nopeasti, ei ole täydellinen tarjous — siitä puuttuu osa, joka useimmiten ratkaisee, pitääkö aikataulu.

Miten me oikeasti suunnittelemme tätä vastaan

Aloitamme kirjoitetulla määrittelyllä, emme siksi että se näyttää hyvältä tarjouksessa, vaan koska väärän oletuksen korjaaminen paperilla on halvinta. Toimitamme käyttökelpoista ohjelmistoa joka toinen viikko, jotta väärä suunta havaitaan ajoissa, ei myöhään. Ja nimeämme yhden päättäjän per asiakas jo alussa, koska projekti, joka odottaa kokousta saadakseen vastauksen, häviää aina aikaa riippumatta siitä, kuinka hyvin koodi on kirjoitettu.

Katsokaa, miltä tämä lähestymistapa näyttää käytännössä work-sivulla, tai lukekaa lisää siitä, miten rakennamme räätälöityjä ohjelmistoprojekteja ensimmäisestä keskustelusta lähtien. Jos osa aikataulupäätöksestä liittyy siihen, kannattaako projekti ylipäätään räätälöidä vai ratkaista valmisohjelmistolla, valmisohjelmisto vai räätälöity ratkaisu on hyvä lukea ennen kuin aikataulua aletaan edes suunnitella.

Aikataulu, joka ei kerro, kuka hyväksyy mitäkin ja kuinka nopeasti, ei ole aikataulu. Se on toive, jolla on päivämäärät.

Tämä pätee riippumatta projektin koosta: pieni sisäinen työkalu ja monivuotinen järjestelmäuudistus kärsivät samoista neljästä syystä, vain eri mittakaavassa.

Jos haluatte rehellisen arvion omasta aikataulustanne, keskustelu yhteydenottolomakkeen kautta vie asiaa eteenpäin nopeammin kuin yksikään artikkeli ohjelmistoprojektien viiveistä.