Tarvitsemmeko enää projekteja?

Ketterien menetelmien yksi ultimatum on tehdä projektit tarpeettomiksi. Mutta mitä tämä tarkoittaa? Emmekö enää yritä saada mitään valmiiksi? Vai emmekö enää tarvitse suunnitelmaa työntekoon?

Onnistuessaan ketterä-tapa on molemmissa parempi. Saamme enemmän valmiiksi ja suunnittelemme tehokkaammin.

Mikä oikein on projekti?

Aloitetaan siitä, mitä projekti tarkoittaa. Projekti on väliaikainen rupeama, jossa nimetty joukko ihmisiä on toteuttamassa kokonaisuutta tietyllä aikataululla ja budjetilla. Projektilla on suunnitelma, jossa määritetään tehtävät sekä lopputuotokset. Eli kun tarvitaan jokin uusi tuote tai sovellus, tehdään suunnitelma, jotta saadaan selville tekemisen kustannukset. Projekti onnistuu varmemmin, jos kommunikoimme ja ohjaamme tekemistä tarkemmin sekä seuraamme budjettia aikataulun ja työtuntien muodossa. Myös suunnitelman laatu vaikuttaa, sillä mitä tarkempi suunnitelma, sitä paremmin voimme kattaa riskiskenaariot.

Projekti on väliaikainen rupeama, jossa nimetty joukko ihmisiä on toteuttamassa kokonaisuutta tietyllä aikataululla ja budjetilla.

Mutta kuka tässä mallissa seuraa valmistumista, tarpeen vastaavuutta ja varsinkin liiketoimintahyödyn toteutumista? Myös projektin väliaikainen luonne sekä hierarkkinen suunnittelu ja johtaminen aiheuttavat vääriä resurssivalintoja.

Usein joudun kuulemaan tarinoita, joissa kerrotaan projektin onnistuneen 50%:sti: saimme käytettyä budjetin suunnitellussa aikataulussa, mutta tuote ei aivan valmistunut. Projektilla on myös erittäin vahva taipumus paisua kooltaan hallitsemattomasti jo suunnittelu- vaiheessa. Tämä on luonnollista, kun ajattelemme, että tärkeässä hankkeessa emme voi epäonnistua, joten teemme niin hyvän suunnitelman, että se ottaa huomioon kaikki mahdolliset kombinaatiot ja niiden riskit. Skenaariot kartoitetaan ja riskeille luodaan laimennussuunnitelmat. Tarvitsemme siis selvitys- ja määrittelyvaiheen aliprojekteja, jotka rinnakkain tehtynä tuottavat yksityiskohdat varsinaiselle tekemiselle, kun vain lisäämme tarpeeksi resursseja. Mistä voimme saada kaikki nuo osaajat – varsinkin, jos tehdään jotain uutta toiminnallisuutta uusiin asiakastarpeisiin? Emme mistään, sillä suurin osa laajan projektin riskeistä paljastuu vasta tekemisen aikana, vaikka tekisimme vähemmän kokeellista selkeään tarpeeseen.

Projektityön määritelmä:
– Väliaikainen ryhmä, jolla ei väliaukaisuudesta johtuen ole yhteisiä rutiineja, ei ryhmäkemiaa, eikä välttämättä kokemusta ko. aiheesta ja sovelluksesta
– Projektilla on vaiheistettu aikataulu

Ketterä toiminta ratkaisuna?

Suurin muutos ketterässä toimintatavassa onkin juuri projektinhallinta. Kehittäjän työpäivään muutosta ei juuri tule, varsinkaan itse kehitystyöhön ei sitäkään vähää. Samaan tapaan teemme muutoksia koodiin kuin ennenkin ja kirjaamme tehtävät tehdyiksi tai viat korjatuiksi. Mikä siis muuttuu?

Jos tiimiä ajatellaan yksikkönä, jolla on tietty käyttöaste, sen käyttöastetta voidaan parantaa poistamalla joutokäyntiä. Projektimallissa joutokäyntiä syntyy paljon.

Useimmiten kehitysosasto on pullonkaula, ainakin useimmissa kustannuksiaan seuraavissa organisaatiossa. Toisin sanoen meillä on aina enemmän toivomuksia ja tarpeita uusista ominaisuuksista kuin mitä pystymme ikinä tekemään. Tuotteen kehitysjono on pitkä ja viatkin pitäisi korjata, ainakin ne kriittisimmät. Lean-ajatusmallissa, josta Agilekin juontaa juurensa, pyritään läpimenomäärää (thoroughput) kehittämään. Tämä tehdään tunnistamalla pullonkaulat ja optimoimaan näiden osien toimintaa. Mutta miten pullonkaulaa voidaan optimoida?

Jos tiimiä ajatellaan tuotantotaloudellisesti yksikkönä, jolla on tietty käyttöaste, voimme parantaa käyttöastetta poistamalla joutokäyntiä. Projektimallilla toimimisesta joutokäyntiä syntyy aika paljon. Projektin käynnistäminen vaatii erinäisten asioiden odottelua: välineet, käyttöoikeudet, opettelu ja muut. Lisäksi hyvän kommunikoinnin varmistamiseksi tarvitsemme kick-off -palaverin, milestone 1, 2, 3, 4, 5, 6, 7 -dokumentointijaksot, statusraportit ja –palaverit. Lopetus palaverin, Lessons Learned -yhteenvedon sekä paljon muuta.  Voidaankin sanoa, että ketterässä malissa tähän pullonkaulaongelmaan on selkeä ratkaisu: tiimi on pysyvä ryhmä, jolle johto ’syöttää’ tehtäviä halutussa prioriteettijärjestyksessä. Eli tiimi toimii kokoajan täydellä teholla. Tarkemmin sanottuna sataprosenttisen tehokkaasti, kun optimityömäärä on tutkitusti noin 80% työajasta. Priorisointi, uusien tarpeiden tunnistaminen ja myyntityö tapahtuu tämän rinnalla.

Itse asiassa suurin muutos tapahtuu tiedonkulun lisääntymisessä ja vuorovaikutuksessa. Enää tietoa ei valu pelkästään managementistä kehittäjillepäin, vaan meillä on selkeät viestintämallit sekä vaatimusten molemmin puolisen ymmärtämiselle että työn edistymiselle eli viestintäkanava takaisin on olemassa. Agile-toimintapa korostaa myös läsnäolon ja fyysisten palaverien merkitystä: ihmiselle on ominaista viestiä muutenkin kuin kirjoitetussa formaalissa muodossa. Vaikeasti ymmärrettävät ja uudet kokonaisuudet vaativat ratkaisun hahmottamiseen tarinoita, eli narratiiveja: esimerkkejä tarpeista ja varsinkin toteutusmahdollisuuksista.

Tehokas kommunikaatio tehostaa työntekoa

Sanotaan, että toiset kehittäjät ovat jopa 100 kertaa tehokkaampia kuin toiset. Yksi selitys tälle on, että nykyään sovelluskehittäminen on paljolti erilaisten valmiiden kirjastojen tai (pilvi)palveluluiden käyttämistä. Eli tehokas ja hyvä kehittäjä yhdistelee olemassa olevia komponentteja toisiinsa, lisää puuttuvat osat ja luo näin jo valmiiksi varmennettuja toiminnallisuuksia osista, jotka hän tuntee aiemmista kokemuksista. Yhtäältä tällaisten mahdollisuuksien selittäminen, toisaalta liiketoiminnan omituisuuksien valottaminen toiselle osapuolelle on hankalaa ilman, että pääsemme kertomaan ja piirtämään valkotaululle mitä oikein tarkoitamme.

Kommunikointia parantamaan on kehitetty ketterien menetelmien Scrum-malli, joka suosittelee toistuvia esittelytapahtumia.

Perinteinen hierarkkinen malli on luonut menetelmiä, kuten UML, TOGAF, BPML näiden asioiden kuvaamiselle. Menetelmät ovat toimivia, mutta työläitä käyttää ja oppia. Kun lisäämme tähän faktan valintojen tuomien kombinaatioiden määrästä alamme ymmärtää, miten valtavaan työmäärään määrittely voi johtaa. Ketterrällä mallilla tehtyyn sovellukseen voi kuulua myös dokumentaatio ja tarkka kuvaus yo. notaatiolla, mutta sitä ei tehdä kuin oikeaksi havaitulle toiminnallisuudelle eikä sitä ylitehdä, jotta toinen osapuoli varmasti ymmärtäisi mitä haluamme. Riittää, että täytämme kehitysryhmän, johon tässä luen liiketoiminnan ja kehityksen, ulkopuoliset tarpeet esimerkiksi viranomaiset, loppuasiakkaat ja muut. Eli suunnittelemme kokoajan, mutta dokumentoimme vähemmän, koska vältämme turhaa dokumentointia. Toisaalta jatkuva suunnan tarkentaminen vaihtoehtojen selvetessä ohjaa meitä oikeanlaisen sovelluksen tekemiseen. Ehkä dokumentaatioksi riittää toimiva sovellus, joka on jatkuvasti varmennettu automaattisilla testeillä ja valvonnalla.

Kommunikointia parantamaan on kehitetty ketterien menetelmien Scrum-malli, joka suosittelee toistuvia esittely- ja katselmointitapahtumia. Demosessio on enemmän kuin palaveri: siihen kaikki sidosryhmät ovat tervetulleita, eli kyseisen kehitysiteraation tuotosta esitellään kaikille halukkaille. Tällä avoimella lähestymisellä pyritään siihen, että työn eteneminen ei jää kenellekään epäselväksi, mutta enemmän sillä halutaan saada tietoa seuraaviin kehitysvaiheisiin. Toisin sanoen näyttämällä kuinka järjestelmä nyt toimii ja kuinka valmiiksi saadut osat toteuttavat tarpeet, liiketoiminnan edustajat saavat käsityksen siitä, millainen tuleva systeemi on käyttää ja miten se vastaa tarpeisiin.

Parhaimmillaan tehdyt toteutukset tai käytetyt kirjastokomponentit vastaavat sellaisenaan riittävän hyvin jo muutamiin kehityslistalla oleviin vaatimuksiin. Tämän avulla pääsemme priorisoimaan listaa uusiksi ja jopa poistamaan hankalina pitämiämme ominaisuuksia, koska nämä toimivat jo riittävän hyvin, eli tuottavat sen asiakasarvon, jonka niiltä olemme halunneet. Lyhyesti sanottuna työjonon priorisoinnin tarkoitus on aina keskittyä seuraavaksi arvokkaimpiin ominaisuuksiin ja saada mahdollisimman paljon asiakasarvoa aikaiseksi jokaisessa iteraatiossa.

Scrum-mallin edellytykset:
1. Vaatimusten omistajat/tilaajat, eli liiketoiminnan edustajat, seuraavat kehitysiteraatioita ja antavat palautteensa. Tähän motivoi valmiiden ominaisuuksien näkeminen ja mielellään kokeileminen.
2. Kehitystiimien kyvykkyys tehdä kaikenlaisia ominaisuuksia mahdollisimman valmiiksi.

Moniosaaminen on vahvuus

Kehitystiimin moniosaamisella on muitakin positiivisia vaikutuksia kuin vain tiimeistä riippumaton priorisointimahdollisuus työjonon suhteen. Lean-mallissa pyritään vähentämään jonoja, joita syntyy riippuvuuksista prosessin eri osien, eli meidän ohjelmistotuotantolaitoksessa, erilaisen tiimin ulkopuolisten resurssien välillä. Perinteisesti monet yhtenäisyyttä vaativat toiminnot, kuten arkkitehtuurisuunnittelu tai -testaus on jätetty tiimien ulkopuolelle. Tämän lisäksi arkkitehdit on voitu myös jakaa tarkasti omille sovellusalueilleen, jolloin hyväksynnän saaminen arkkitehtuurilinjaukselle voi joutua odottamaan kiireisen arkkitehdin vapaata aikaa tai loman loppumista. Kun tiimin tekeminen riippuu ulkopuolisesta rajallisesta resurssista, tästä syntyy väistämättä odotusta tai ainakin viivästystä optimaaliseen tekotahtiin verrattuna. Agile-metodologiassa tätä ongelmaa poistamaan on useampiakin ratkaisuja. Tärkeimpänä kuitenkin organisaation sisäisten riippuvuuksien tunnistaminen ja poistaminen. Riippuvuudet on monesti rakennettu tiukasti organisaation perustuksiin ja vaatiikin johdon sitoutumista ja uskallusta siirtää esimerkiksi arkkitehtuurivastuuta tiimeille.

Lean-mallissa pyritään vähentämään jonoja, joita syntyy riippuvuuksista prosessin eri osien välillä.

Kehitystiimin sisäisen testauksen osalta hyötyjen ymmärtäminen on helpompaa. Jos tiimi itse testaa tuotoksiaan mahdollisimman paljon ennen julkaisua, löytää se myös vikoja ennen kuin ne ovat päässet eteenpäin. Näin ollen vältymme vikaraporteilta, ylimääräisiltä testauskierroksilta ja muulta, eli toisin sanoen voimme poistaa turhaa työtä eli ’waste’:a, kun vikoja ei tarvitse dokumentoida eikä kierrättää pidemmän kaavan kautta. Tiimin tavoite on siis pyrkiä toimittamaan mahdollisimman vikavapaata koodia ja itseohjautuvasti korjata viat ennen jakelua.

Usein pohditaan, miten voimme korjata vikoja ilman, että niitä kirjataan vikatietokantaan. Kyse on taas vastuun antamisesta tiimille: vika on vika vasta, kun se kehitystiimin ulkopuolella. Jos Kehittäjä ei kirjoittanut virhettä koodin alkuunkaan, niin ei se silloin olisi myöskään vika. Samoin, jos tiimi itse löytää vian ja korjaa sen, se ei ole vika. Itseohjautuvan tiimin tulisi pystyä valitsemaan tapa, jolla se hallinnoi integraatioiden aikana omaa tekemistään. Tiimi voi valita, että se käyttää vikatietokantaa, mutta se voi tehdä sen kevyemmin ja säästää vaivaa.

Jatkuvuus tekee työnteosta sujuvampaa

Pysyvät pitkäaikaiset tiimit kehittyvät monella tavalla tehokkaammiksi. Ensimmäinen ilmiö on varsin luonnollinen. Tiimin jäsenet, jotka tuntevat toisensa työskentelevät tehokkaammin, koska heillä ei kulu aikaa toisten erityistaitojen ja vahvuuksien arvailuun. He osaavat ohjata oikeat työt oikeille tekijöille. Tämä edellyttää tiimin jatkuvaa keskinäisten asioiden parantamista ja yhteen hiileen puhaltamista. Toinen merkittävä vaikutus syntyy jatkuvasta oppimisesta. Nykyään kehitettävät systeemit ovat hyvin monimutkaisia ja liiketoiminnan mallit vaikeasti ymmärrettävissä. Monialaisen tiimin ratkoessa laajoja kokonaisuuksia se oppii ymmärtämään liiketoiminnan lainalaisuuksia ja hyödyntämään käytössä olevia mahdollisuuksia. Tietämys tarkoittaa kykyä toimia vajailla lähtötiedoilla (Kuhn & Jackson, 2008).

Pysyvät pitkäaikaiset tiimit kehittyvät monella tavalla tehokkaammiksi. He osaavat ohjata oikeat työt oikeille tekijöille.

Miten siis voimme toimia ilman projekteja? Projektit tai hankkeet ovat isompia kokonaisuuksia, jotka tähtäävät uusien toiminnallisuuksien tuottamiseen tai tuotteen parantamiseen. Eli muutoksia, jotka tuottavat määriteltyä asiakasarvoa. Tärkeää tällaiselle kokonaisuudelle on, että se tuottaa lopulta enemmän arvoa kuin mitä se maksaa. Liiketoiminta-arvon syntyminen voi edellyttää isompia muutoksia, niinpä nämä kokonaisuudet ovat tärkeitä myös jatkossakin. Skaalattaessa ketterää kehitysmallia useampia tiimejä käsittäväksi ja ulottaessa se myös yrityksen johtoon tarvitsemme salkun hallintamallia. Ketterässä mallissa perinteisiä hankkeita vastaavia kokonaisuuksia käsitellään Epic:einä eli tehtäväkokonaisuuksina.

Erona hankeelle ja projektille on Epic-jonon jatkuva priorisointi ja jatkuva liiketoimintaomistajuus. Usein projekti luovutetaan kehitysorganissatiolle sen jälkeen, kun liiketoimintajohto on saanut rahoituksen hankittua ja ensimmäiset milestone-portit ovat läpäisty. Tämän jälkeen projektin perään kysellään, kun aikataulu alkaa olla loppunut. Usein vastaus on kuitenkin täydellisesti onnistuneen sisällön sijasta nippu selvittämättömiä ongelmia ja loppuneet rahat. Tässä yksi tärkeä syy sille miksi liiketoimintajohdon pitää aidosti omistaa tehtäväkokonaisuudet ja seurata niiden tuotoksia jatkuvasti. Hyvä käytäntö on se, että tehtäväkokonaisuuksilla on selkeä prioriteetti joka perustuu suoraan rahalliseen hyötyyn. Toisin sanoen saat omalle kokonaisuudelle paremman prioriteetin sitä mukaan kun perustelet liiketoiminnan hyötyä paremmin tai saat toimivien osien toteutus kustannuksia pienennettyä.

Tähän meillä on mahdollisuus, jos osaamme ohjata tiimien työtä aina isoimman hyödyn tuottaviin ominaisuuksiin. Muistetaan, että ketterät tiimit tuottavat aina toimivia tuotteita jokaisen iteraation jälkeen, josta voimme todentaa, miten paljon arvoa viimeisimmällä versiolla jo saadaan tehtyä. Onko meillä jo niin hyvä tuote, että tuottoa alkaa syntyä? Laiskan johtajan hankkeet tippuvat prioriteetissa alaspäin ja eivät tuota yritykselle mitään. Tämä tuottamattomuus saadaan näkyviin ja ammattinsa osaavat johtajat saavat ansaitun arvostuksen.

Mitä seuraavaksi? Oletetaan, että viiden vuoden kuluttua suurin osa ohjelmistokehityksestä ja muustakin tuote/palvelukehityksestä on jättänyt projektimallin sivuun ja keskittynyt asiakkaan arvontuottamiseen. Niin mitä voimme seuraavaksi parantaa? Contribyten Tulevaisuuden Tuotekehitys yhteisö koittaa löytää juuri tähän vastauksia.

Haluaisitko siirtyä aikaa syövästä projektimallista ketterämpiin menetelmiin? Contribyte auttaa! Tutustu Agile- ja Lean-coachauksiimme sekä erilaisiin ketteryyskoulutuksiin.