Lean, mean and clean – me olemme, onko asiakas?

Ohjelmistoalalla heitellään tiettyjä termejä paljon ilmaan; on matalia organisaatioita, ketterää kehitystä sekä lean-ajattelua. Termit kuulostavat hienoilta ja myyviltä, mutta kuinka selkeitä ja ymmärrettäviä ne ovat? Ymmärtääkö asiakas termejä? Tarvitseeko asiakkaan edes ymmärtää? Entä jos asiakkaan organisaatio on kaikkea muuta kuin ketterä tai matala? Voiko silloin yhteistyötä saada onnistuneesti toimimaan toimittajan ja asiakkaan välillä? Väitän että voi, jos organisaatioiden sisäinen toiminta maltetaan pitää ulkona projektista ja kehitystiimien vastuuta kasvatetaan.
Ohjelmistokehitys on muuttunut viimeisen kymmenen vuoden aikana valtavasti. Perinteiset vesiputousmallit ja tiukat määrittelyprojektit ovat katoamassa. Projektit halutaan viedä läpi ilman hidasteita mahdollisimman kevyesti ja yksinkertaisesti – englanninkielistä sanontaa käyttäen lean, mean and clean. Tällainen toimintamalli on tehokas kevyissä organisaatioissa, mutta asettaa haasteita hierarkkisiin organisaatioihin. Uudet toimintatavat voivat vain vaikeuttaa asiakkaan toimintaa, jos ne eivät sovellu haluttuun ympäristöön. Tästä kärsii niin asiakas kuin toimittaja.
Projektin aikana tulee pitää erillään ne osa-alueet, joissa modernit toimintatavat ovat parhaimmillaan. Asiakkaan omalle organisaatiolle jätetään tehtävät, joissa hierarkkisuudesta ei ole haittaa. Ketterissä menetelmissä tuotteenomistajalta vaaditaan nopeita ja selkeitä päätöksiä. Projektia aloittaessa pitää määritellä tarkasti tuotteenomistajan vastuut ja velvollisuudet. Yksi ratkaisu on päätöksenteon vastuutus tuotteenomistajalle. Tuotteenomistaja kertoo tarkalleen, mitä haluaisi tehtävän, jonka perusteella tiimi toteuttaa tuotteen. Tämä asettaa tuotteenomistajalle haasteen toimialan ja teknologioiden tuntemisesta, sitoutuneisuudesta sekä omasta aktiivisuudesta.
Usein toimivampi ratkaisu on keventää tuotteenomistajan työtä ja siirtää vastuuta kehitystiimille. Tällöin tuotteenomistajan päätettäväksi jää korkean tason vaatimukset ja julkaisusuunnitelmat. Asiakas näyttäytyy suurten linjojen päätöksissä organisaatiolleen tutulla tavalla ja toimittaja toimii ketterästi. Asiakkaalle tarjotaan mustan laatikon mallia; jos järjestelmä toimii asiakkaan haluamalla tavalla, se riittää. Palvelun yksityiskohdilla asiakasta ei vaivata. Malli vaatii tiimiltä itsenäistä otetta ja tuntemusta toteutettavasta järjestelmästä.
Tuotteen onnistuminen on aina sekä tuotteenomistajan että kehitystiimin vastuulla. Tärkeintä on sopia yhteiset pelisäännöt projektin alussa, jotta vastuut ja velvollisuudet ovat selvät. Organisaatioiden sisäiset erot eivät ole este modernien toimintatapojen käytölle. Jotta voimme olla lean and clean, pitää joskus olla sopivasti mean.