”Agile-markkina synnytti lihakaupan” 

Devisioonan Jouni Heikniemi kirjoitti varsin pitkän ja perusteellisen jatkokirjoituksen allekirjoittaneen aiempaan artikkeliin ”Iso osa kotimaisesta ohjelmistoalasta on henkilöstövuokrausta”. Heikniemi tarttuu etenkin asiakkaiden lisääntyneeseen vastuuseen ohjelmistokehityksen laadusta. Kun toimittajat ovat siirtyneet CV-kauppaan, on asiakkaiden huolehdittava yhä laajemmin tekemisen laadusta.

Toimittajat toki kehittävät yksittäisiä osaajia, ehkä jopa enemmän kuin aiemmin, mutta eivät panosta projektien sisällä tapahtuvan yhteistoiminnan kehittämiseen, kun sopimukset ovat käytännössä henkilöstövuokrausta.

Heikniemen pitkä kirjoitus kannattaa lukea kokonaisuudessaan, koska tämänkaltainen vain osia lainaava referointi ei tee pitkälle tarinalle oikeutta.

>> Järjestelmäprojektit: Henkilöstövuokrausta vai toimittajan vastuunkantoa? (Jouni Heikniemi, 13.10.2021)

Heikniemi kritisoi myös alan sisäistä keskustelua, joka polarisoituu hyvin herkästi, vaikka arkitodellisuus on paljon kirjavampaa. Kaikista malleista löytyy omat ääri-ilmiönsä.

”Aiheesta käytävä keskustelu polarisoituu helposti, koska minkä tahansa hankemallin ääritapaukset ovat aina karmaisevia, ja niistähän ne anekdootit syntyvät. Katastrofiprojektien auditointikeikoilla on nähty tolkuttoman riitaantuneita kiinteähintaisia hässäköitä, joissa yhteisymmärrys projektin sisällöstä on kadonnut projektin ensimmäisen kolmanneksen aikana ja myöhempi muutoshallinta on vetänyt sekä budjetit punaiselle että silmät mustaksi. Aivan yhtä lailla vastaan on tullut agile-säätöjä, joissa toimittaja on painellut ovesta sisään minimityömääräarviolla, mutta sprintit eivät vain ole koskaan ottaneet loppuakseen.”

Heikniemi tuntuu olevan allekirjoittaneen kanssa samoilla linjoilla siitä, että kokonaisuutena IT-alan hankehallinta on todella vaihtelevalla tasolla tällä hetkellä. Isojakin hankkeita tehdään erittäin heikolla osaamisella ja tulokset ovat sen mukaisia. Ala väittelee paljon uusimmista teknologioista ja prosessimalleista, vaikka useimmat tiimit ja asiakkaat eivät oikeastaan noudata mitään kovin selkeätä menetelmää tai tee asioita edes erityisen suunnitelmallisesti. Tätä sekavaa käytännön arkea eivät ole agile-menetelmät olennaisesti muuttaneet.

Heikniemi tiivistää hyvin myös alkuperäisen kirjoituksen havaintoa menetelmäkehityksen kriisistä, kun vuokratuilla ohjelmistokehittäjillä ei ole enää selkeätä motivaatiota parantaa laatua tai prosesseja, vaan he keskittyvät ensijaisesti täyttämään tilaajan ilmaisemat toiveet ja tavoitteet. Jos tilaaja ei vaadi menetelmäkehitystä, ei sitä todennäköisesti kukaan teekään.

”Kun ketterästä projektitoimituksesta siirrytään henkilöstövuokraukseen, tekijät eivät muutu tippaakaan sen vastuuttomammiksi, mutta suhde tekemiseen muuttuu: Kun rooli on nimenomaan olla tuntilaskutteisena toteuttajana asiakkaan työnohjauksen alaisena, toteutustyö on juuri se mitä tehdään. Työmenetelmiäkin voidaan kehittää vaikka miten paljon – kunhan asiakas pyytää. Mutta kuinka usein se pyytää? Meidän kokemuksemme on, että henkilöstövuokrauksen tyyppisissä asetelmissa menetelmäkehitys jää usein sivurooliin, koska yksittäisessä hankkeessa se on suhteellisesti kallista ja yleisellä tasolla vaikeaa: parhaat käytännöt pitäisi sitten jalkauttaa kaikkiin projekteihin, joiden tekijät on muodostettu välillä jopa eri organisaatioista CV-poimintamenetelmällä.”

On myös syytä todeta, että Heikniemikään ei demonisoi henkilöstövuokrausta tai agile-tekemistä (kuten ei ollut allekirjoittaneenkaan jutun idea), vaan nostaa esiin ensisijaisesti mallin haasteita (joita on kaikissa menetelmissä), ja korostaa syntyviä ongelmia, jos mallia käytetään erittäin laajasti tai osaamattomissa käsissä. Tämä seuraava kappale esimerkiksi tiivistää erittäin hyvin myös allekirjoittaneen ja North Patrolin kokemuksia alan tämän hetkisestä tilanteesta:

”Tarkoituksemme ei ole missään nimessä moittia ketteryyttä tai edes henkilövuokrausta, vaan osoittaa niihin liittyvät fundamentaaliset haasteet. Teknisen tuotteistuksen, vakioitujen toimintamenetelmien ja kehitystyön menetelmäosaamisen kehittäminen vaatii tietoisia panostuksia, ja useissa tilanteissa luontevin panostaja on ohjelmistopalveluita ammattimaisesti tuottava yritys, joka pystyy toistuvien projektien myötä myös keräämään tästä työstä saatavan hyödyn – siis käytännössä tehokkuuden ja ennustettavuuden parantumisen.

Jos tämä tekninen toimitusvastuullinen taho jää pois yhtälöstä henkilöstövuokrauksen myötä, vastuu työtavoista tipahtaa joko bodyshopatuille konsulttiyksilöille tai asiakkaalle itselleen. Parhaassa tapauksessa asiakas saa tunnetulta konsulttitalolta hankkeeseensa valmiiksi yhteen sulautuneen tiimin, jolla menetelmät ja niiden kehittäminen ovat jo hanskassa. Valitettavasti tuntuu, että jokaista tällaista onnistumista kohden löytyy kymmenen tapausta, joissa hankkeeseen resursoidaan eri puolilta keräiltyjä palkkasotureita, jotka ryhtyvät projektin kuluessa etsimään yhteistä säveltä. Menetelmäkehitysvastuun voi kantaa asiakaskin, mutta sepä onkin vaikea laji, ja mestarit sitä myöten varsin harvassa.”

Ja edelleen, timanttisia in-house-tiimejä toki löytyy tästäkin maasta, mutta harvassa ovat ne paikat, joissa huipputiimi kohtaa myös yhtä osaavan tilaajaorganisaation.

”Mikään tässä ei tietenkään tarkoita sitä, etteikö in house -tiimi voisi tehdä timanttista työtä, mutta vain harva asiakasyritys pystyy resursoimaan ja johtamaan projektit niin hyvin, että tämä toteutuisi toistuvasti ja luotettavasti. Vaikka hankitut koodarit olisivat kuinka osaavia ja monia hankkeita nähneitä, heille asetettu rooli ohjaa usein ajattelua nimenomaan konkreettiseen, optimistiseen devausputkeen. Tästä meillä on kokemusta itsellämmekin, kun ajoittain on tullut tällaista bodyshopping-tyyppistä keikkaa heitettyä: kyllä siinä kova seniorikin on sosiaalisesti vaikeassa välikädessä, kun pitäisi alkaa liputtamaan hankkeen organisoinnin puutteista.”

Heikniemen pitkä kirjoitus kääntyy loppupuolella myös ylläpidettävyyden ja ratkaisujen elinkaareen suuntaan, joiden kohdalla Heikniemi toteaa aiheeseen olennaisesti liittyvän kysymyksen olevan myös valinta valmistuotteiden ja räätälöidyn kehittämisen välillä. Omassa johdossa olevan tiimin kanssa työskenneltäessähän usein päädytään räätälöityihin ratkaisuihin, jopa tilanteissa joissa markkinoilla olisi paljon valmisratkaisuja samaan tarpeeseen. Heikniemi tiivistää hyvin tätä ilmiötä, ja miksi se on varsin ymmärrettävä seuraus valitusta tekemisen mallista.

”Tärkeä ja vaikea aiheeseen liittyvä kysymys on tasapaino räätälöinnin ja valmistuotteiden välillä: jos tehdään täysin räätälöidysti, kustannusten ennakointi on haastavaa ja lopputulos on aina sataprosenttisesti omalla vastuulla – hyvässä ja pahassa. Jos taas projekti rakennetaan valmistuotekonseptien ympärille, menetetään osa joustavuudesta ja joudutaan murehtimaan tausta-alustan kustannuksista ja roadmapista, mutta vastineeksi saatetaan saada olennaisiakin kustannussäästöjä niin toteutus- kuin ylläpitovaiheissakin.

Jos valmisratkaisu perustuu tuotteeseen tai vaikka avoimen lähdekoodin tuotteen päälle rakennettuihin toimittajakohtaisiin laajennuksiin, onko täyttä toimittajavapautta mahdollista saavuttaa, ainakaan taloudellisesti järkevästi? Toisaalta mitä vähemmän toimittajaorganisaatiolla on roolia hankkeen suunnittelussa ja toteutuksessa, sitä todennäköisimmin kehittäjätiimit tuntuvat valitsevan täysin pitkästä tavarasta tehdyn ratkaisun. Tämä on ymmärrettävääkin: vahvasti tuotevetoinen kehitys vaatii yleensä hyvin vakiintuneita toimintatapoja ollakseen tehokasta, ja näitä tapoja on vaikea muodostaa, jos tiimillä ei ole ollut tilaa toistaa samoja projekteja riittävän usein.”

Palkkasotureista kasatun tiimin on haastavaa toimia tehokkaasti valmistuotteiden kanssa, kun kaikilla on hyvin erilaiset taustat, ja tiimin yhteistoiminnan kanssa on paljon muitakin haasteita. On yksinkertaisesti todella paljon helpompaa löytää yhteinen tekemisen sävel tekemällä räätälöityä toteutusta.

Tämä lienee käytännössä suurin syy siihen miksi in-house-tiimit lähes poikkeuksetta rakentavat kokonaisuuksia täysin pitkästä tavarasta, vaikka asiakkaiden alkuperäiset tavoitteet olisivat saattaneetkin viitata toiseen suuntaan. Asiakkaiden kannattaisi tämä tiedostaa hyvin aikaisessa vaiheessa, kun miettivät toteutusmallinsa valintaa.

Osittain tätä ilmiötä voi toki taklata tekemällä mahdollisimman paljon teknologiavalintoja osana hankkeen valmistelua, ja ottamalla juurikin tuote- ja teknologiavalinnat vahvemmin osaksi asiakkaan päätöksentekoa. Valitettavasti tämäkään ei täysin poista sitä haastetta, että palkkasotureista kasattu tiimi ei välttämättä ole tehokkaimmillaan tuoteratkaisujen käyttöönotossa.

Mikä on sitten Heikniemen esittämä ratkaisu tähän kaikkeen?

”IT-projektimaailma hakee vieläkin täydellistä toimintamallia, koska edelleen niin iso osa hankkeista epäonnistuu. Agilen ydinviesti on aivan oikea. Ihmisläheinen, nopea iterointi on lähes aina parempi kuin byrokraattinen suunnittelun ja toteutuksen kireä vaiheistus. Mutta ketteryydenkin kanssa tärkeimmäksi haasteeksi nousee vastuunkanto: Kuka on valmis tekemään sen raskaan ajatustyön, jota uuden järjestelmäkokonaisuuden vaatimusten kunnollinen määrittely vaatii? Kenen tehtävä on miettiä, miten vaadittu järjestelmä toimii kahden, viiden tai kymmenen vuoden päästä, kun muut järjestelmät ja liiketoiminta ympärillä muuttuvat? Onko paikalla aina joku, jolla riittää rohkeus puhaltaa pilliin, kun vaikuttaa siltä, että toteutus etenee väärillä raiteilla?

Ajatus siitä, että jokainen asiakas tekisi tämän työn sataprosenttisesti talon sisällä, omilla palkatuilla ihmisillään, on epärealistinen. Tekijöitä ei yksinkertaisesti riitä kaikille, ja vaikka niitä jotenkin maagisesti saisikin, vain harvalla suomalaisella organisaatiolla riittää resursseja ja projekteja myös ylläpitää osaamista tilanteessa, jossa pilvipalvelut, valmiskirjastot ja verkon käyttötavat uusiutuvat jatkuvasti.”

Heikniemi peräänkuuluttaa vastuunkantoa lopputulosten laadusta, joka ei ole välttämättä kiinni mistään yksittäisestä prosessimallista, vaan enemmänkin siitä miten koko hankkeeseen suhtaudutaan, ja ollaanko valmiita tekemään myös niitä epämukavia vaiheita, kuten jonkinlaista vaatimusten määrittelyä ennen koodaamiseen ryntäämistä.

Heikniemen kirjoituksesta myös huokuu se viesti, että asiakkaiden tulisi valmistella hankkeitaan paremmin ja tehdä tietoisempia päätöksiä siitä millä mallilla mitäkin järjestelmähanketta lähdetään tekemään. Erityisesti jos haaveillaan tiimeistä omassa työnjohdossa, pitäisi ensin varmistaa, että omassa organisaatiossa on riittävän kokenutta ja osaavaa henkilöstöä työn johtamiseen, ja valittuun tekemisen malliin ollaan sitouduttu useiksi vuosiksi.

Tosin osansa vallitsevasta tilanteesta Heikniemi kaataa myös toimittajille, jotka ovat ainakin olleet välinpitämättömiä alan laadullisen kehityksen suunnalle. Henkilöstövuokraukseen ryntääminen on ollut vain liian houkuttelevaa toimittajille ja tämä on luonut alalle vääristyneen tilanteen. Asiakkaat kyllä haluaisivat – ja todellakin tarvitsisivat – enemmän toimitusvastuullista tekemistä, kuin mitä markkina tällä hetkellä tarjoaa.

Jos IT-ala haluaa pitää kiinni laatumielikuvasta tekemisessään, on toimittajien kannettava vastuuta laadun ja tehokkuuden kehityksestä projektista toiseen.

”Lopulta olennaista on toki tehdä laatua. IT-alan suurin vihollinen on huono IT ja siihen liittyvät dramaattiset epäonnistumiset. Useimmissa asiakasorganisaatioissa hankejohtaminen ja arkkitehtuuriajattelu hyötyvät ulkopuolisesta näkökulmasta ja toimittajan lisäkysymyksistä, riskiarvioista ja kyseenalaistuksista. Ennen sopimusmallin valintaa kannattaa huolella puntaroida, mihin omat rahkeet riittävät – sekä projektivaiheessa että elinkaaren myöhempinä vuosina.”

—

Lue lisää: Ketterät menetelmät olivat pieni askel oikeaan suuntaan

PS. Jos kaipaat riippumatonta asiantuntijan näkemystä mobiili- tai verkkopalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee web- ja mobiilikehityksen teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja erilaisten digipalveluiden jatkokehityksen suunnittelussa.