Lukuaika: 5 minuuttia
Ohjelmistokehityksessä hyvää, nopeaa ja halpaa on vaikea saavuttaa. Voimmeko saada kaikki kolme? Onko mahdollista saavuttaa tasapaino? Kerromme siitä tässä.
Monet meistä ohjelmistoalalla työskentelevistä ovat projektitarjouksia, konsultaatioita tai kustannusarvioita aloittaessaan kohdanneet lähes väistämättömän markkinoilta tulevan pakon: kehitettävä hyviä, nopeita ja halpoja ohjelmistoja. Onko mahdollista saada nämä kolme muuttujaa samaan aikaan? Onko tämä ajatus utopistinen?
Voittaaksemme vastata tähän kysymykseen ja nähdäksemme tämän postulaatin toteuttamiskelpoisuuden on tärkeää, että käymme ensin läpi kaksi keskeistä ajatusta.
Minkä hinnan laitat aineettomalle kokonaisuudelle?
Ohjelmisto on aineeton tuote; emme voi nähdä sitä emmekä tietää sen hyvyyttä ennen kuin se on valmis. Hinnan asettaminen ohjelmistokehitykselle on jotain monimutkaista (paitsi jos ostetaan pakettiohjelmistoja räätälöidyn kehityksen sijaan), ei ainoastaan sen arvon subjektiivisuuden vuoksi (joka perustuu moniin kriteereihin), vaan myös siksi, että on olemassa eroja siitä, onko projekti helpompi vai monimutkaisempi toteuttaa.
Estimates, menestyksen peruspilari
Kun otetaan huomioon aineettoman risteyskohta, oikean arvion tekeminen -ja mahdollisimman tarkan, koska se on likimääräinen-, on erittäin tärkeää, jotta vältetään budjetin ylitykset ja ajanhukka.
Sisältöön liittyvä:
Pitäen mielessä, että hyvä arvio on kehitysprojektin onnistumisen perusta, emme voi sivuuttaa sitä tosiasiaa, että jokainen arvio muunnetaan työtunneiksi. Tiimin jäsenten ammatillinen laatu ja heidän kokemuksensa ovat suoraan verrannollisia kehitystyön kustannuksiin.
Lyhyesti sanottuna, kun tiedämme, että projektin arvioinnin, suunnittelun ja toteutuksen suorittavat ihmiset, voimme päätellä, että ammattilaisten laatu ja asiantuntemus vaikuttavat projektin kustannuksiin.
Hyvä, nopea ja halpa
Kun olemme ymmärtäneet, että ohjelmisto on aineeton kokonaisuus, jonka hintaa on vaikea määritellä, varsinkin jos ei ole selkeää arviota, jatketaan selittämällä hyvän, nopean ja halvan ominaisuuksia ja sitä, miten niitä on mahdollista yhdistää, mutta ei saada kaikkia kolmea samanaikaisesti.
Hyvä ja nopea
Nopeudella on mahdollista tehdä jotain hyvää. Tämän saavuttamiseksi on tärkeää tehdä hyvä arvio ja sen jälkeen hyvä projektin toteutussuunnitelma, jotta nopeus ei vaikuta lopputuloksen laatuun.
Laadun ja nopeuden saavuttamisen avain on projektin parissa työskentelevissä ihmisissä, joiden on oltava riittävän päteviä tarttumaan projektiin. Muista, että ammattilaisten laatu on määräävä tekijä kustannusten kannalta.
Tulee ottaa huomioon, että nopeus voi olla tuottavuuden vastainen tekijä: Teoriassa tiimi (ja sen jäsenet) saavuttavat tuotantohuipun tietyssä ajassa ja säilyttävät sen projektin loppuun asti. Mitä suurempi nopeus on, sitä lyhyempi aika tiimi on tuottavuuden huipulla.
Niin ikään koordinointi on myös analysoitava tekijä: Mitä enemmän ihmisiä työskentelee rinnakkain, sitä enemmän koordinointia tarvitaan (ehkä koordinaattoreiksi pitäisi lisätä useampia henkilöitä).
Hyvä ja nopea pätee erityisesti kriittisiin tai avainprojekteihin, joissa tuotteen laatu on taattava hinnalla millä hyvänsä. Näissä tapauksissa tarvitaan tiimejä, joilla on paljon kokemusta. Tällöin ratkaisu on hyvä ja nopea, mutta myös kallis.
Nopea ja halpa
Tässä on toinen kolmen muuttujan yhdistelmistämme: Yksinkertaisin tapa tehdä jotain nopeasti ja halvalla on tehdä se ilman laatua tai ainakin olla tietoinen siitä, että se voi olla huonompi kuin haluttu. Voimme uhrata laadun tiettyyn pisteeseen asti, kunhan ohjelmisto ei käsittele kriittistä tietoa tai se ei ole riippuvainen jostain organisaation arkaluontoisesta osasta.
Nopeusvaikutusten vuoksi – koska tulevaisuudessa sovelluksen laatua voidaan parantaa – on mahdollista lähteä tuotantoon niin, että tuotteen keskeiset ominaisuudet toimivat. Näissä tapauksissa voidaan tehdä näin:
- Vähentää koodin laatua
- Yhentää sen käytettävyyttä
- Jättää koodin tarkistukset sivuun
- Vähentää laadunvalvontaa ja testausta.
Toimimalla näin saamme mitä todennäköisimmin perustoiminnallisuuden omaavan työkalun, mutta emme kuitenkaan saa sataprosenttisen tyydyttävää tuotetta. Sen käytettävyys ei ehkä ole paras mahdollinen, samoin kuin koodin laatu, ja sen laajennettavuus (mahdollisuus muutoksiin tai laajennuksiin) ja uudelleenkäytettävyys voivat olla ongelmallisia.
Tämä koskee demosovelluksia, konseptin testausta, ei-kriittisiä ohjelmistoja tai mitä tahansa sovellusta, joka on skaalautuva tai laajennettavissa ajan mittaan.
Hyvää ja halpaa
Annan teille viimeisen yhtälömme: Jos asiakas haluaa hyvän ja halvan ratkaisun, hän ei voi odottaa nopeaa toimitusta.
Jotain hyvää ja hyväksyttävään hintaan voidaan tehdä, mutta ajan kustannuksella. Periaatteessa, jos aikaa on, on helpompi suunnitella – koska tehtäviä ei ole niin paljon rinnakkain eikä koordinointia tarvita niin paljon – ja osallistuvien ihmisten tuottavuushuippu pysyy huipussaan pidempään.
Jotain hyvää ja halpaa sopii projekteihin, joissa aika ei ole kriittinen muuttuja, sekä inkrementaalisiin projekteihin tai tiimeihin, joilla on osittaisia aikoja (joilla on sisäisiä projekteja tai aloitteita).
Ei kannata olla huomaamatta tätä: Ohjelmiston laatu tai hinta:
Yhteenvetona
Ohjelmistokehityksessä postulaattia ohjelmistokehityksen hyvä, nopea ja halpa on hyvin vaikea saavuttaa. Pystymme aina saamaan niistä kaksi, mutta joudumme luopumaan jäljelle jäävästä. Näin on mahdollista saavuttaa laatu sovitussa ajassa ja kohtuullisin kustannuksin; on vain osattava löytää tasapaino näiden kolmen muuttujan välille, tunnettava niiden seuraukset ja se, miten ne ovat yhteydessä toisiinsa, jotta tasapaino saavutetaan.
Tämän tasapainon saavuttaminen on mahdollista, kunhan arvioinnit, koordinointi, työryhmän valinta, työmenetelmät sekä työkalujen ja tekniikoiden käyttö ovat oikeita.
Oletko saavuttanut tasapainon näiden muuttujien välillä jossakin hankkeessa? Miten teit sen?
