Elämme maailmassa, jossa ketterä menetelmä on kaikkialla käytössä. Kuuluisista teknologiajäteistä pieniin startup-yrityksiin kaikki käyttävät sitä tuotteidensa rakentamiseen. Kun opit ketterästä menetelmästä, olet ehkä törmännyt termiin ”vesiputousmenetelmä”.
Useimmat ketterää menetelmää käyttävät projektipäälliköt pitävät vesiputousmenetelmää vanhentuneena menetelmänä, jolla ei enää ole tarkoitusta vuonna 2023. Mutta onko tämä todella totta?
Varttuneena tuotepäällikkönä minulla on runsaasti kokemusta sekä ketterästä menetelmästä että vesiputousmenetelmästä. Vesiputousmenetelmän puolustukseksi perehdytään nyt tarkemmin siihen, mitä se on, miten se toimii ja milloin sitä on tarkoituksenmukaista käyttää.
Mistä vesiputouksen projektinhallintamenetelmässä on kyse?
Vesiputousmenetelmässä kehitysprojekteja hallitaan jakamalla ne erillisiin vaiheisiin ja käsittelemällä jokainen vaihe peräkkäin.
Vaikka suurten työmäärien jakaminen pienempiin osiin on ollut ihmisten käytössä aikojen alusta lähtien, vesiputousmenetelmän virallinen ”syntymä” tapahtui paljon myöhemmin – vuonna 1970, kun tuon ajan merkittävä tietojenkäsittelytieteilijä, tohtori Winston W. Royce, kuvasi sitä kirjassaan ”Suurten ohjelmistojärjestelmien kehityksen hallinta”.
Sen jälkeen siitä tuli tärkein tapa, jolla ohjelmistoyritykset hallitsivat projektejaan, kunnes maailma alkoi 2000-luvun alussa kallistua ketterän menetelmän suuntaan.
Miltä ohjelmistokehityksen elinkaari (SDLC) näyttää vesiputousmenetelmällä?
Toisin kuin ketterän menetelmän iteratiivinen ja inkrementaalinen rakenne, vesiputouksen SDLC:llä on sekä selkeä alku että loppu. Se jakaa koko ohjelmiston luomisprosessin viiteen eri vaiheeseen tai virstanpylvääseen, eikä yhden vaiheen työ ala ennen kuin edellinen vaihe on valmis. Visuaalisesti se näyttää tältä:
Työ etenee vaiheesta toiseen, kunnes se saavuttaa pohjan ja projektin katsotaan olevan ”valmis” – visuaalisesti tämä muistuttaa vesiputousta (tästä myös termi).
Tarkastellaan nyt tämän lineaarisen lähestymistavan jokaista vaihetta ja ymmärretään, mistä niissä on kyse.
Vaihe 1: Vaatimusten kerääminen
Kaikki alkaa projektin vaatimusten keräämisestä kaikilta sidosryhmiltä. Vaatimusvaiheen aikana projektipäälliköt laativat kattavan ja erittäin yksityiskohtaisen asiakirjan, joka kattaa projektin kaikki osa-alueet toiminnallisista vaatimuksista budjettiin ja riskisuunnitelmaan.
Have an account? Log In
Vaihe 2: Ratkaisun suunnittelu
Edellisessä vaiheessa kerättyjen vaatimusten perusteella projektiryhmä alkaa muotoilla ratkaisua ja suunnitella sitä. Tässä yhteydessä termi ”suunnittelu” viittaa tuotteen tekniseen rakenteeseen (järjestelmäsuunnittelu), tuotteen visuaaliseen ja vuorovaikutussuunnitteluun (UI/UX-suunnittelu) sekä fyysiseen suunnitteluun (jos kyseessä on fyysinen tuote).
Vaihe 3: Toteutus
Tässä vaiheessa varsinainen koodaus tapahtuu. Kehitystiimisi jäsenet alkavat rakentaa tuotetta suunnitteluvaiheessa luomiesi tuotosten perusteella.
Toisin kuin ketterässä menetelmässä, jossa projektin laajuutta ja suunnittelua voi muuttaa jatkuvasti, vesiputousmenetelmässä oletetaan, että noudatat suunnitteluasiakirjaa etkä ”kehitä” tuotettasi toteutusvaiheen aikana.
Vaihe 4: Testaus
Heti kun ohjelmistosuunnittelutiimi on saanut tuotteen rakentamisen valmiiksi, voimme siirtyä projektisuunnitelmamme seuraavaan vaiheeseen – testaukseen. Tiimisi alkaa tarkistaa tuotteesi mahdollisten virheiden, tietoturvahaavoittuvuuksien tai käyttökokemusongelmien varalta.
Testausvaiheen aikana tarkistat myös, vastaavatko lopputuotteen toiminnallisuus ja suunnittelu kahden ensimmäisen vaiheen aikana laatimiasi projektin vaatimusasiakirjoja.
Vaihe 5: Käyttöönotto ja julkaisun jälkeinen tuki
Olettaen, että tiimisi on löytänyt ja korjannut kaikki tuotteesi merkittävät ongelmat, on aika julkaista ratkaisu ja luovuttaa se asiakkaillesi ja loppukäyttäjillesi.
Ohjelmoijasi siirtyvät nyt ylläpitovaiheeseen keräämällä jatkuvasti asiakaspalautetta, tekemällä tarvittavat korjaukset sekä julkaisemalla tuotteestasi uusia korjausversioita ja päivityksiä.
Siinä kaikki, projektisi on valmis ja voit siirtyä seuraavaan!
Pitäisikö sinun siis käyttää vesiputousmenetelmää?
Jos sinä, ketterään ajattelutapaan nojaava projektipäällikkö (ainakin oletan niin), ajattelet tämän menetelmän olevan vanhanaikainen eikä sen käyttöä pitäisi koskaan harkita, olen kanssasi (kunnioittavasti) eri mieltä ja väitän, että vesiputousmenetelmä on itse asiassa parempi valinta tietyntyyppisiin projekteihin.
Käydään yhdessä läpi pari esimerkkiä osoittaakseni väitteeni todeksi.
Tapaustutkimuksia: vesiputousmenetelmä käytännössä
Kuten minkä tahansa monimutkaisen käsitteen kohdalla, jotkin konkreettiset esimerkit voivat auttaa ymmärtämään, miten menetelmä toimii tosielämässä. Tässä on siis muutama tosielämän projekteihin perustuva esimerkki (joissa olen saattanut itse olla mukana tai sitten en), jotta saat selkeämmän käsityksen siitä, miten vesiputouslähestymistapa toimii käytännössä.
Tapaus nro 1: tulliselvitysalusta Egyptin hallitukselle
Kuvitellaan, että olet osa yritystä, joka on saanut sopimuksen Egyptin kaltaisen suhteellisen suuren maan kansainvälisen kaupan ja tulliselvitysjärjestelmien nykyaikaistamisesta.
Egyptin hallitus haluaa satamaviranomaisjärjestelmän, joka hallinnoi kaikkien Egyptin eri satamiin saapuvien alusten lastiluetteloita (tulliasiakirja, joka sisältää tiedot kaikesta aluksessa olevasta lastista ja matkustajista).
Lisäksi he haluavat tämän järjestelmän integroituvan suoraan toiseen tuotteeseen, jonka he haluavat sinun rakentavan ja joka käsittelee kaikki maan tulliselvitykset (eli SAD-asiakirjat eli yhtenäiset hallinnolliset asiakirjat). Lomake on tavallisille ihmisille melko monimutkainen täytettäväksi, joten he haluavat sinun automatisoivan sen heidän puolestaan.
Egyptissä on monimutkainen verotus- ja tullimaksujärjestelmä, joka muuttaa verokantoja maahantuotavien tavaroiden tyypin, määrän ja muiden tekijöiden perusteella. Koska tavallisilla kansalaisilla ei ole aavistustakaan näistä verokannoista, Egyptin hallitus haluaa sovelluksesi laskevan kaiken automaattisesti kansalaisten puolesta heidän ilmoittamiensa tietojen perusteella ja antavan heidän maksaa verkossa luottokorteillaan.
Tämä vaikuttaa valtavalta hankkeelta, eikö vain? Kun toteutuksen yksityiskohtia viimeistellään, johto (ja ehkä jopa Egyptin hallitus) tulee luoksesi, projektipäällikön luo, ja kysyy, miten haluat järjestää tämän projektin toteutuksen.
Miksi ja miten sinun pitäisi käyttää vesiputousmenetelmää tässä tilanteessa:
Kaikki kansalliselle hallitukselle rakentamasi perustuu todennäköisesti lakiin tai parlamentin vahvistamaan päätökseen. Nämä päätökset sisältävät kaiken projektin yleisistä ehdoista (esimerkiksi kustannuksista ja aikataulusta) aina siihen, miten kaikki tarkalleen ottaen tulee toimimaan.
Kuulostaa ja näyttää vesiputousmenetelmän ensimmäisen vaiheen vaatimusmäärittelyasiakirjalta, eikö totta? Itse asiassa niin onkin, ja se tarkoittaa myös, ettet voi muuttaa toteutuksen yksityiskohtia, suunnittelua ja vaatimuksia lennossa, kuten ketterässä ohjelmistokehityksessä.
Johdin aiemmin tällaista tuotetta. Eräänä päivänä huomasimme, että voisimme parantaa käyttökokemusta merkittävästi tekemällä pari pientä muutosta liiketoimintalogiikkaan. Kerroimme ideastamme heti kanssamme työskennelleelle tulliviranomaisen edustajalle.
No, hän sanoi ei. Voisi kuvitella, että tällaisen ehdotuksen hylkääminen oli huono idea, mutta hänellä oli hyvä syy siihen, miksi sitä ei voitu toteuttaa.
Pienet muutoksemme olisivat tarkoittaneet muutosta kaavaan, jota hallitus käytti tietyn tuotteen verojen laskemiseen. Kaava oli vahvistettu laissa, joten sen muuttaminen olisi tarkoittanut koko kansallisen parlamentin koolle kutsumista ja asiasta äänestämistä.
More Articles
Tapaus nro 2: Ingenuity-helikopterin lennonohjausjärjestelmä
Ingenuity on nimi, jonka NASA antoi huipputeknologiselle helikopterille, jonka se rakensi ja lähetti Marsiin vuonna 2021. Tältä pikkuinen näyttää.
Kuvittele, että olisit yksi onnekas projektipäällikkö, joka vastasi tämän uskomattoman teknologian ohjelmiston kehittämisestä. Tiimisi piti erityisesti kirjoittaa koodi, joka ohjaisi helikopterin lentoa.
Lentokoneen (erityisesti helikopterin) lennonohjausjärjestelmän luominen on erittäin vaikeaa. Sinun on otettava huomioon kaikki fysiikan lait, jotka vaikuttavat lentolaitteeseesi lennon aikana, ja laskettava lapojen pyörimisnopeus, lapojen kulma sekä miljoona muuta asiaa.
Tehtäväsi on kuitenkin vieläkin monimutkaisempi. Helikopterisi täytyy lentää toisen planeetan pinnan yläpuolella, ja sen ilmakehä on 100 kertaa harvempi kuin Maassa.
Miksi ja miten sinun pitäisi käyttää vesiputousmenetelmää tässä tilanteessa:
Minun mielestäni vesiputouskehitys on tässä ainoa vaihtoehtosi. Ketterään projektinhallintaan verrattuna – jossa rakennat jotain pientä (MVP:n), otat sen käyttöön, käytät sitä tosielämässä, keräät palautetta ja parannat ratkaisua vähitellen palautteen perusteella – tällaisen projektin riskit ovat aivan liian suuret.
Voitko todella ottaa riskin ja tehdä Ingenuitysta virheellisen MVP:n ja lennättää sen 140 miljoonan mailin päähän Marsiin? Kukaan ei mitenkään suostuisi siihen.
Siksi sinun on rakennettava siitä lopullinen versio ja testattava sitten kaikki sen järjestelmät perusteellisesti, ennen kuin sinulla on tarvittava varmuus lähettää se punaista planeettaa kohti lentävään rakettiin.
Vesiputousmalli voi hyvin ja on edelleen käytössä!
Itse asiassa se on paljon suositumpi kuin olisit odottanut: puolessa kaikista projekteista maailmanlaajuisesti käytetään edelleen tätä kehitysmenetelmää.
Vaikka ketterien menetelmien yleistyminen on tehnyt maailmasta paremman paikan monille projektipäälliköille antamalla heidän julkaista tuotteita paljon aiemmin ja kehittää niitä käyttäjiltä saadun palautteen perusteella, vesiputousmalli on edelleen erittäin hyödyllinen menetelmä projekteihin, joissa joustavuus on rajallista ja virheiden sietokyky matala.
Toivottavasti pidit vesiputousmenetelmän käsittelystämme. Jos haluat lukea myös hieman lisää ketteristä menetelmistä, tässä on muutama suositus:
- Oppaamme aiheesta ketterä tuotehallinta.
- Kokoelma parhaita käytäntöjä aiheesta ketterä portfoliohallinta.
- Kuratoitu luettelomme parhaista ketterän tuotehallinnan työkaluista.
Nämä ovat vain kolme monista tuote- ja projektinhallintaa käsittelevistä oppaista ja artikkeleista. Saat lisää tietoa tilaamalla uutiskirjeemme.
