Tällaisessa tilanteessa syntyy osaamissiiloja ja osaaminen voi henkilöityä voimakkaasti, mikä lisää projektin riskialttiutta henkilöstömuutoksille sekä vaikeuttaa tiimin toimintaa kun projektitiimin kokoa skaalataan alaspäin. Kerron tässä kirjoituksessa toimenpiteitä, joilla siiloja voidaan potensoida niin, että projektitiimin tehokas toimintakyky säilytetään projektin elinkaaren eri vaiheissa ja miten näin osaamisen henkilöitymisestä koituvaa riskiä voidaan pienentää.
Miten siiloja syntyy?
Käytetään esimerkkinä projektitiimiä, jossa kutakin osa-aluetta kehitetään 2-4 henkilön pientiimeissä. Integraatioasiantuntijat vastaavat palveluväylän ja liittymien kehittämisestä, fronttikehittäjät ja käyttökokemusasiantuntijat suunnittelevat näyttökerroksen, backend- ja tietokantakerroksen toteuttajat tekevät tietomallin ja datamigraation, ja vielä yksi tiimi toteuttaa ulkoiset maksulliset palvelut. Projektipäällikkö koordinoi pientiimien toimintaa ja huolehtii että tuotokset ovat keskenään yhteensopivia.
Tiimien koot saattavat elää projektin vaiheen mukana. Kun tuotantokäytön aloittamisen jälkeen projektin kiivain vaihe on ohi, tekeminen vähenee kaikilla osa-alueilla. Tiimiä skaalataan alaspäin tyypillisesti pientiimikohtaisesti, koska palvelutason turvaamiseksi ja jatkokehitystarpeita täyttämään tarvitaan edelleen osaamista ja tietämystä eri osa-alueilta. Esimerkiksi jokaisesta tiimistä voi jäädä projektiin yksi tai kaksi henkilöä.
Nyt projektin jatkokehityksestä ja jatkuvien palveluiden tuottamisesta vastaa tiimi, jonka reagointi- ja ratkaisukyky normaalitilanteessa ovat hyviä, mutta jonka osaaminen on vahvasti siiloutunutta ja henkilöitynyttä.
Mitä haittaa siiloista on?
Nyt tiimistä löytyy osaamista joka alueesta, mikä siis on ongelma? Tilanne on vaikea, kun jatkokehitys- ja tukityöt eivät jakaudukaan tasaisesti. Käyttöliittymäkehittäjä on tyhjäkäynnillä, kun tuotanto pyörii ja uusia ominaisuuksia ei tarvita, kun taas ulkoisten palveluiden toteuttaja on pulassa suurten jatkokehitystarpeiden kanssa, kun tuotantokäytön myötä on tunnistettu uusia liiketoimintamahdollisuuksia. Samaan aikaan resursoinnista kysellään onko työtä vielä jäljellä vai voiko kehittäjiä jo siirtää muihin alkaviin projekteihin, joten on paineita tasata työkuormaa.
Jatkuvien palveluiden tuotanto on turvattava kaikissa tilanteissa. Palvelutaso pitää pystyä takaamaan myös kesälomien, sairauslomien aikaan, kun kaikki kehittäjät eivät ole käytettävissä. Miten toimitaan palveluväylässä ilmenevissä häiriötapauksissa integraatioasiantuntijan lomien aikaan?
Yksilön kannalta pitkäaikainen saman osa-alueen kehittäminen voi käydä monotoniseksi, kun työpäivät koostuvat pienistä muutostöistä ja häiriöselvityksistä.
Yksilön kannalta pitkäaikainen saman osa-alueen kehittäminen voi käydä monotoniseksi, kun työpäivät koostuvat pienistä muutostöistä ja häiriöselvityksistä. Kehitysvauhti, intensiteetti ja innovointimahdollisuudet eivät ole samalla tasolla kuin aktiivisimmassa kehitysvaiheessa, mikä voi aiheuttaa turhautumista ja lopulta halun vaihtaa projektia. Hallitsematon muuttoliike pois projektista halutaan pitää minimissään.
Miten siilojen reunoja madalletaan tai jopa puretaan?
Voi olla suurikin houkutus vain todeta yhdessä, että tästä eteenpäin ”kaikki tekee kaikkea”. Sillähän ne siilot puretaan. Mitenkäs käy tiimin häiriönratkaisukyvykkyyden tai jatkokehityksen budjetin ja aikataulun, kun yhtäkkiä tuleekin lapiohommia osaamiskuopan täyttämiseksi? Toisaalta kehittäjätkään eivät välttämättä halua poistua omalta mukavuus- ja kiinnostusalueeltaan opettelemaan vähemmän kiinnostavaa ja kompleksista osa-aluetta. Konkreettisten keinojen lisäksi tarvitaan siis motivointia.
Viisi vaihetta siilojen poistamiseen
Keinojen implementoinnissa kannattaa lähteä liikkeelle vaiheittain. Tarkastellaan vaiheita tarkemmin yksi kerrallaan.
1. Ongelmanratkaisusta tehdään toistettavaa ja näkyvää
Tyypillisten häiriötilanteiden ratkaisuohje dokumentoidaan ratkaisun yhteydessä ja siitä kerrotaan muille tiimin jäsenille esim. daily- tai weekly-palaverin yhteydessä. Kun seuraava vastaava tapaus tulee, tunnistetaan tilanne ja asiaan perehtymätön henkilö voi katsoa yhteisestä työtilasta ratkaisuohjeet. Kun ratkaisu on valmis, kyseisen osa-alueen asiantuntija katselmoi ratkaisun. Katselmointi on tärkeää regressiovirheiden eli korjaamisesta syntyvien muiden virheiden välttämiseksi.
2. Tehtävien jakaminen ja yhdessä tekeminen
Jatkokehittäminen pitää olla kohtuuhintaista ja -katteellista, joten asiakasta ei voida laskuttaa kaikesta uuden osa-alueen vaatimasta opettelusta. Eikä toisaalta voida tehdä määrättömästi laskuttamatonta työtäkään, koska haluamme tehdä kannattavaa liiketoimintaa. Jakakaa kehitystehtävät niin pieniksi – max 3 HTP toimii – ja täsmällisiksi, että kaksi henkilöä voi toteuttaa saman tehtävän eri osia. Esimerkiksi viikon työ voidaan jakaa kehittäjien kesken 50-50. Jos asiantuntija opastaa aihetta tuntematonta kehittäjää, ei kokonaistyömäärä välttämättä juurikaan kohoa, mutta osaaminen tiimissä lisääntyy.
3. Tehtävälistan läpinäkyvyys
Käyttäkää yhteistä tehtävänäkymää. Huolehdi että aiemmin mahdollisesti käytettyjä tehtävänäkymän filttereitä ja muita työnohjauskeinoja päivitetään niin, että kaikki kehittäjät näkevät kokonaistyökuorman eikä pelkästään oman osa-alueensa tehtäviä. Tehtäviä voi edelleen kategorisoida osa-alueittain työn jäsentämisen takia, mutta kategoriaa ei pidä käyttää niin voimakkaana ohjaavana tekijänä kuin aiemmin. Samalla ohjataan tiimiä kantamaan kokonaisvastuuta palvelusta ja poistamaan ”ei koske minua”-ajatusmaailmaa. Opetelkaa ettei ole olemassa jonkun muun tehtäviä. On vain tiimin yhteisiä tehtäviä, joiden tekeminen palvelee asiakasta.
4. Allokoi henkilöitä projektin tilanteen mukaan
Kun tiimin kokoa skaalataan alaspäin, kannattaa osaajien siirto muihin projekteihin tehdä osa-allokointeina. Jos osa-alueen erityisosaajia on kolme, niin yhden voi siirtää kokonaan pois, yksi jää kokonaan projektiin ja yksi osa-allokoidaan toiseen projektiin. Näin varmistetaan, että erityisosaaminen ei ole yhteen henkilöön henkilöitynyttä, vaan toinen voi tarvittaessa tuurata. Yksittäisen kehittäjän näkökulmasta vanhan projektin hännät eivät aina ole mieluisia, joten napanuora kannattaa katkaista, jos se vaan on liki riskittömästi mahdollista. Osa-allokoidulle kehittäjälle voi ohjata lähinnä tukitehtäviä, jotta hän saa perehdyttyä uuteenkin projektiin riittävästi, ja vakituinen kehittäjä toteuttaa uudet ominaisuudet,
5. Rohkaise henkilöitä oppimaan uutta
No entä motivointi? Onko kehittäjä kiinnostunut tekemään muiden osa-alueiden tehtäviä tai pelkääkö hän rikkovansa jotain, kun perusteellista ymmärrystä aiheesta ei ole? Solitan Developer Manifeston kuvaama arvomaailma tukee siilojen purkamista, ja kokemukseni mukaan oppimishalu on kova, kunhan odotukset ja työskentelytavat on ensin käyty läpi puolin ja toisin. Automaattitestit puolestaan antavat hyvä pohjan tehdä rohkeita muutoksia ilman regressiovirheiden kasaantumista. Kasvanut vastuu kokonaispalvelusta on useimmiten nostanut kehittäjien motivaatiota, ja moni on puhjennut odottamatta kukkaan, kun onkin saanut näyttää monimuotoista osaamistaan oman osaamissiilonsa ulkopuolelta. Luota tiimiisi, kyllä he osaavat!
Jarkko työskentelee Solitalla projektipäällikkönä julkishallinnon hankkeissa. Erityisesti hän on kiinnostunut asiakkaan auttamisesta ja tilanteeseen sopivan parhaan ratkaisun etsimisestä yhdessä asiakkaan ja projektitiimin kanssa. Vapaa-ajalla Jarkon voi löytää jalkapallokentiltä nappikset jalassa tai valmentajan roolissa.Haluaisitko työskennellä Solitalla? Katso avoimet työpaikkamme ja lähetä hakemuksesi. Etsimme jatkuvasti joukkoomme uusia rakastettavia ja osaavia työkavereita.
