Andersin COO Jon Tarkiainen on projektijohtamisen konkari. Nyt hän pureutuu lean-ajatteluun sovelluskehityksen ja digitaalisen hukan näkökulmasta. Kestävän ohjelmistokehityksen missiomme oleellisin osa on hukan eli turhan työn ja kustannusten välttäminen ja leanin perusperiaatehan käsittelee juuri tätä. Lue alta seitsemän sovelluskehityksen sudenkuoppaa, jotka luovat hukkaa.
Andersin COO Jon Tarkiainen on projektijohtamisen konkari. Nyt hän pureutuu lean-ajatteluun sovelluskehityksen ja digitaalisen hukan näkökulmasta. Kestävän ohjelmistokehityksen missiomme oleellisin osa on hukan eli turhan työn ja kustannusten välttäminen ja leanin perusperiaatehan käsittelee juuri tätä. Lue alta seitsemän sovelluskehityksen sudenkuoppaa, jotka luovat hukkaa.
Aiemmissa blogikirjoituksissani olen puhunut paljon ketteryydestä (mm. Ketterän kehityksen periaatteet). Tällä kertaa tarkastelun aiheena on miten Agile ja Lean voivat yhdessä edistää kestävää ohjelmistokehitystä. Tarvitseeko aina rakentaa uutta heittämällä kaikki vanha romukoppaan, vai onko mahdollista kierrättää jotain? Voiko toimintatapoja kehittämällä varmistaa, että rajalliset resurssit käytetään oikeisiin asioihin oikeaan aikaan?
Leanin perusteet
Leanin juuret juontavat Toyotan autotehtaalle 1930 luvulle. Lisää leanista ja sen historiasta voi lukea täältä https://www.lean.org/WhatsLean/. Leanissa yhtenä keskeisenä teemana on hukan (waste) välttäminen. Leanissa on seitsemän erilaista hukkaa, joita pyritään välttämään.
SOVELLUSKEHITYKSEEN ADAPTOITUNA TÄMÄ HUKAT OVAT:
- Osittain tehty työ. Pyritään rajaamaan, miten montaa asiaa työstetään samanaikaisesti. Loistava työkalu avuksi tähän on Kanban-taulu, minkä avulla voidaan rajata, että uutta asiaa ei oteta työn alle ennen kuin edellinen on saatu valmiiksi.
- Ylimääräinen työ. Ei tehdä ylilaatua tai ominaisuuksia mitä asiakas ei ole pyytänyt. Käytetään hyväksi jo olemassa olevia järjestelmiä ja järjestelmien osia. Kestävää jos mikä!
- Uudelleen oppiminen. Tällä viitataan pääasiassa siihen, että tiimin sisällä jaetaan oppia toisille. Se minkä yksi kehittäjä on oppinut kantapään kautta tai opiskelemalla jotain uutta tulee jakaa myös toisille. Toiminta ei ole kovinkaan kestävällä pohjalla, jos ei osata tai haluta jakaa omia kokemuksiaan toisille. Tämä on pitkälti kysymys kulttuurista. Ihmisille pitää luoda ympäristö missä on turvallista sanoa, “Hei, minä mokasin, mutta haluan jakaa siitä saamani opit teidän kanssanne.”. Pitää myös antaa tiimille aikaa pitää retroja ja muita tilaisuuksia missä tietoa voi jakaa muille. Loppujen lopuksi tiedon jakaminen on halvempaa kuin saman asian oppiminen eri tahoilla useaan kertaan.
- Siirrot toisille (handoffs). Vältetään työvaiheiden siirtoa muille, tiimin ulkopuolella oleville. Siirtämisessä kuluu aina aikaa ja jonkun toisen täytyy ehkä opetella jotain mikä osataan jo luovuttavassa tiimissä (kts. edellinen kohta). Lisäksi siirroissa on olemassa aina se riski että, jotain tietoa jää siirtymättä, mikä aiheuttaa taas lisää selvittämistä ja työtä.
- Viiveet. Kaikenlainen odottaminen ja siitä johtuvat viiveet ovat hukkaa, joita voidaan välttää hyvällä suunnittelulla. Kaikkea ei tarvitse määritellä etukäteen valmiiksi, mutta tulee varmistua siitä, että kun tietoa tarvitaan, se on myös silloin saatavissa.
- Kontekstin vaihtaminen. Asioiden välillä hyppiminen ei ole mitenkään tehokasta. Pyritään antamaan ihmisille työrauha saattaa kesken oleva työ valmiiksi ilman keskeytyksiä.
- Virheet. Bugeja ei voi täysin välttää, mutta niistä aiheutuvan hukan voi minimoida. Tiedossa olevat bugit tulisi korjata mahdollisimman nopeasti. Jokainen kerta, kun bugi aiheuttaa ongelman tuotannossa, täytyy jonkun tehdä jotain korjaavia toimenpiteitä tuotantoympäristössä. Se voi olla vähäpätöinen kiertotie, jonka käyttäjä pystyy itse tekemään tai isompi ongelma, joka vaatii useamman ihmisen työpanoksen. Niin tai näin, jokainen kerta on ylimääräistä työtä, joka vältetään korjaamalla bugi. Toki täytyy muista, että kaikkia harvoin tapahtuvia bugeja ei välttämättä tarvitse korjata heti, jos sillä vältetään kohdan 2. ylilaatu.
Edellä mainitut seitsemän kohtaa voi kategorisoida kahteen ;erityyppiseen hukkaan, digitaaliseen hukkaan ja prosessihukkaan. Kohdat 1. ja 2. ovat digitaalista hukkaa, eli koodia mikä tulee käyttöön pitkällä viiveellä (jopa ei koskaan)tai turhaa koodia.
Loput ovat prosessihukkaa, eli asioita mitä voi tehostaa, jättää tekemättä tai tehdä fiksummin. Asiakkaana digitaalinen hukka on hyvinkin konkreettista ja sen arvo on helppoa ymmärtää. Prosessihukka voi olla asiakkaalle vaikeampaa ymmärtää, koska se on luonteeltaan abstraktimpaa eikä aina edes asiakkaalle näkyvää.
Miten välttää hukkaa?
Me Andersilla olemme sitoutuneet auttamaan asiakkaitamme ymmärtämään hukan välttämisen tärkeyden, jotta visiomme kestävästä ohjelmistokehityksestä toteutuu ja sen tuoma hyöty konkretisoituu myös asiakkaillemme.
Digitaalista tai prosessihukkaa voidaan minimoida, ehkäistä ja poistaa kun projektisuunnitelma on huolella laadittu. Kun asiakas ja toimittaja ovat samalla sivulla projektin laajuudesta, aikataulusta ja priorisoinnista, suunnitelmaa on helppo viedä eteenpäin ja edellä mainitut sudenkuopat 1.-7. on mahdollista hyppiä yli.
Minimoidaksemme omaa digitaalista hukkaamme Andersilla, olemme nyt panostaneet vielä perusteellisempaan projektisuunnitteluun, julkaisimme PMO -osaston ja keskitymme asiakkaamme digitaalisen kokonaiskuvan hahmottamiseen. Laajemmassa kuvassa asiakkaan sekä toimittajan tulisi ymmärtää projektisuunnitelman kokonaisuus, eli mihin projektilla tähdätään. Yrityksen digitaalisen tavoitetilan selvitys, tulevaisuuden arkkitehtuurin ja roadmapin kokoaminen ovat avainasemassa kauaskantoisten päätösten teossa.
AURINKOISET TERVEISET KOTITOIMISTON TAKAPIHALTA MOCCAN KANSSA! KUVAN OTTAMINEN SUJUI NÄPPÄRÄSTI VÄLITUNTIAKTIVITEETTINA.
Jon Tarkiainen
COO
Anders Innovations
