Tulevaisuus on moniosaajatiimeissä. Moniosaajatiimi ottaa haasteen vastaan ja rakentaa tuotteen/palvelun itsenäisesti ideasta tuotantoon ilman välikäsiä. Toiveunta vai todellisuutta? Lue ja päättele itse.
Moniosaajatiimi on poikkitieteellinen
Tiimin käsite on laajentunut. Kehittäjätiimi, jossa on kehittäjiä, Scrum Master ja Product owner, ei enää riitä.
Moniosaajatiimissä mukana ovat kaikki tarpeelliset henkilöt, jotka tarvitaan lopputuloksen saavuttamiseksi. Kehittäjätiimin lisäksi mukana voi olla jäseniä liiketoiminnasta, muotoilusta, markkinoinnista, myynnistä, taloushallinnosta, robotiikasta, data-analytiikasta, tekoälystä ja muista tavoitteen tai palvelun kannalta oleellisista toiminnoista. Palvelumuotoilu ja liiketoiminnan kehittäjät ovat mukana. Mukana voi olla asiakkaita ja liiketoimintakumppaneita.
Tiimille annetaan visio, tavoite, johon pyrkiä, ja suuri autonomian aste toteutukselle ja päätöksenteolle. Tulokset ratkaisevat.
Miksi moniosaajatiimi on parempi kuin perinteinen malli?
Moniosaajatiimin idea on siinä, että kaikki lopputuloksen kannalta oleelliset henkilöt tekevät tiiminä yhdessä töitä. Tämä tarkoittaa myös yhdessä olemista samassa paikassa, ei erillisten tiimipalavereitten kautta.
Suurin hyöty tulee siitä, että kommunikaatio paranee ja päätökset voidaan tehdä ilman viiveitä. Innovointi ja ratkaisuvaihtoehtojen määrä sekä laatu kasvaa, kun kaikki osapuolet tuovat oman osaamisalueensa tietämyksensä mukaan jo kehitysvaiheessa. Ratkaisuvaihtoehtoja voidaan tuottaa ja kokeilla nopealla palautesyklillä, jolloin saavutetaan haluttu lopputulos nopeammin ja osuvammin verrattuna perinteisiin tapoihin.
Kaikkien osapuolten osaaminen ja kokonaisuuden ymmärrys kasvaa.
- Ratkaisua tulee pohdittua useammasta näkökulmasta
- Ratkaisu on moniulotteinen
- Ratkaisussa on otettu huomioon erilaiset käyttökohteet ja ‑tarpeet
- Ratkaisun tekeminen kasvattaa osaamista
- Ratkaisun innovointi ja nopeus voi yllättää tekijätkin
Törmääkö moniosaajatiimin rakentaminen organisaatiohierarkiaan?
Miksi niin harvoin tapaa moniosaajatiimejä, kun hyödyt ovat näin ilmeiset? Suurin este on todennäköisesti organisaatiorakenne, joka on usein muodostunut liiketoiminta-alueista, osastoista, yksiköistä ja niin edelleen. Jos organisaation eri osilla on omat tavoitteensa, ei haluta ”lainata” osaajia moniosaajatiimiin, koska oman organisaation tulos ohjaa resursointia.
Tämä on johtamiskysymys. Perinteisesti päätökset ja ohjaus tulevat ylhäältä alas, ja johto haluaa pitää prosessin hallussa. Moniosaajatiimi toimii parhaiten autonomisesti ja sillä on päätöksentekovalta omassa tekemisessään.
Tappaako erikoistuminen innovaation?
Monet nykyiset kehitysmallit pohjautuvat vahvasti erikoistuneisiin toimintoihin, joilla ei välttämättä ole aikaisempaa kokemusta yhdessä työskentelystä, vaan toimitaan vesiputousmallin mukaisesti. Kehitystiimi toteuttaa liiketoiminnan tarpeen ja sen jälkeen verifioidaan asiakkailla toteutuksen kelpoisuutta, tehdään muutoksia tuotantoon, kerätään dataa ja mitataan palvelun käytettävyyttä.
Usein huomataan vasta toteutuksen jälkeen, että olisikin pitänyt ottaa huomioon sitä ja tätä. Kuulostaako tutulta?
Miten rakennat moniosaajatiimin?
Tiimi täytyy rakentaa. Rakentamiseen löytyy välineitä. Esimerkiksi Christopher Averyn Powerful teams antaa käytännön ohjeita siihen, miten kuka tahansa voi rakentaa minkä tahansa tiimin milloin tahansa.
Siili Akatemia tarjoaa tähän opastuksen Powerful Teams ‑kurssilla. Kysy lisää ja varaa paikkasi jo tänään!
IBM PC – innovointi ja tuotekehityksen nopeus moniosaajatiimillä
IBM PC:n kehittäminen on malliesimerkki moniosaajatiimin kyvystä tuotekehityksessä. IBM PC:n kehitys alkoi suurkoneiden aikana Boca Ratonin laboratoriossa 12 henkilön moniosaajatiimillä. Ohjeeksi tiimille oli annettu rakentaa yleiskäyttöinen henkilökohtainen tietokone – aikana, jolloin joillekin suuryritysten johtajille oli käsittämätön ajatus, mihin yksittäinen henkilö voisi tarvita tietokonetta.
Tiimi rikkoi kaikkia mahdollisia senhetkisiä IBM:n tuotekehityksen sääntöjä. Loppu on historiaa. Todennäköisesti luet tätä artikkelia tuon tiimin työn johdannaisella.
Lisää IBM:n tiimin historiallisesta työstä voit lukea täällä.
Kirjoittanut
Teemu Torvelainen