Arvo ja mittarit – tuoteomistajan paras kaveri

Kuva: U.S. Pacific Fleet, Flickr

Tuoteomistaja voi hallita täydellisesti kehitysjonon, vaatimukset, testauksen ja jopa palautteen oikeilta käyttäjiltä ja silti päätyä projektinsa kanssa seinään. Miksi? Mitä tapahtui?

Jos projektissa syntyvän tuotteen arvosta liiketoiminnalle ei ole yhteistä näkemystä, projekti on vaarassa. Ja jos tälle arvolle ei ole asetettu mittareita, visio ja sen toteutuminen roikkuvat vieläkin ilmassa.

Mikä neuvoksi?

Tässä ehdotuksia arvo- ja mittaustyökaluista keskusteluun liiketoiminta-arvosta sekä sen mittaamiseen:

  • Arvopokeri. Tiedät varmaankin, että kehittäjillä on tapana pelata arvopokeria sprinttien tms. suunnittelukokouksissa. Lainaa kortteja ja vie ne ohjausryhmän kokoukseen. Pelatkaa pokeria esim. epic-tason tarinoiden arvosta liiketoiminnalle. Onko tämän ominaisuuden arvo loppukäyttäjille ja sitä kautta liiketoiminnallemme esim. 1 (pienin) vai 13 (suurin)? Pokerilla saat naulattua keskustelun projektin arvosta konkreettiselle tasolle.
  • Arvopalaute käyttäjiltä. Saatatkin jo saada tilauksia ja käyttöanalytiikkaa tai muuta mitattavissa olevaa palautetta käyttäjiltäsi. Jos kyllä, mahtavaa. Jos et, käyttäjiltä kannattaa kysyä uusien ominaisuuksien arvosta: Minkä arvoinen tämä ominaisuus on sinulle? Estääkö tämä ominaisuus sinua menemästä kilpailijalle?
    Palautteen tyypillinen ongelma nimittäin on että sitä tulee paljon – ohjausryhmältä, kehitystiimiltä ja laajemmalta projektiyhteisöltä. Jos olet onnekas ja organisoitunut, palautetta tulee lisäksi ohjelmistosi (pilotti-)käyttäjiltä. Niinpä tarvitset työkalun sen punnitsemiseen, mitä palautetta painottaa. Raha tai kilpailutilanne ovat hyviä mittareita.
  • Arvokäyrä. Kun olet näin saanut selville, mikä tuotteessa on oikeasti arvokasta, on hyvä ryhtyä mittaamaan edistystä. Arvokäyrä voi olla aseesi tähän. Voit yksinkertaisesti kerätä arvopokerista saamasi pisteet per ominaisuus ja alkaa piirtää käyrää siitä, miten arvopisteiden suhteen edistytään kussakin sprintissä. Tätä käyrää haluat luultavasti esitellä myös ohjausryhmässä.
  • Vaihtoehtopokeri. Nyt olet siis tunnistanut, millaiset ominaisuudet ovat arvokkaita ja miten niiden suhteen edistytään. Mahtavaa! On aika ottaa täyteen käyttöön kehitystiimin ymmärrys siitä, miten valitsemaanne teknologiaa kannattaa käyttää. Yksi keino tähän on suunnittelupokeri, jossa pelataan erilaisista toteutusvaihtoehdoista. Tässä pelisäännöt jokaiselle kehitysjonosta löytyvälle ominaisuudelle:

1. Pyydä kehittäjiä ensin näyttämään pistekortti kevyimmälle toteutusvaihtoehdolle, jonka he keksivät.

2. Pyydä sitten kehittäjiä näyttämään pistekortti huolelliselle, viimeistellylle toteutusvaihtoehdolle.

3. Huomaa mikä ero.

  • Oletusratkaisut pilottikäyttöön. Kun kehittäjät näyttävät vaihtoehtopokerissa matalimpia pistekortteja, he ajattelevat luultavasti esim. pystyttävänsä tietyn moduulin oletusasetuksilla tai käyttävänsä koodia jostain aiemmasta projektista. Mitä jos kysyisit itseltäsi:

“Voisimmeko tähän hätään toteuttaa tämän kevyimmän ratkaisun ja ottaa sen käyttöön pilottikäyttäjien kanssa? Enkö silloin saisi kokemusta siitä miten sitä käytetään, eikä minun tarvitsisi kuvitella? Eikö tämä mahdollistaisi, että se työ jota käytämme jatkojalostamiseen, tukisi varmasti todellisia käyttäjien käyttötapoja?”

  • Avaa tuotekatselmoinnit muille ja pidä käyttäjäpalaute käsillä. Tuotekatselmoinnit, joissa esim. katsotaan mitä viime sprintissä toteutettiin, ovat keinosi saada konkreettista palautetta projektiyhteisöltä. Valmistele katselmointi hyvin, ja hanki apua fasilitointiin jos tuntuu että sinulla on katselmointitilaisuudessa liikaa rooleja. On tärkeää että sinulla on katselmoinnissa käsillä se käyttäjäpalaute, josta edellisessä kohdassa puhuttiin. Tuotevisiosta keskusteltaessa nimittäin välillä karataan henkilökohtaisiin mieltymyksiin sen sijaan että katsottaisiin, mistä käyttäjät oikeasti hyötyvät ja mistä he ovat valmiita maksamaan.

Mitä sitten?

Tämän kirjoituksen pointti lyhyesti: arvo liiketoiminnalle ja sen mittarit ovat paras ystäväsi, kun tähtäät menestykseen ketteränä tuoteomistajana. Niiden avulla nimittäin pystyt todistamaan, että projektisi on menestynyt. Työkaluja arvon mittaamiseen ja seuraamiseen on monia, lista jatkuu edellä esitetystä. Tärkeintä on, että mittaat arvoa jollakin.

Tämä kirjoitus perustuu Karoliina Luodon pitämään esitykseen Agile Lean 2015 –konferenssissa Sofiassa, Bulgariassa 26.8.2015. Esityksen kalvot englanniksi löytyvät alta.

Ohjelmistoarkkitehtuuria kuninkaille – 8 vinkkiä

Kuningas (c) epSos.de

Joskus muinoin, ei niin kovin kauan sitten, tietojärjestelmien suunnittelu ja toteuttaminen oli helppoa. Vaatimukset sai kysymällä tilaajan edustajilta, asiakkailta eli loppukäyttäjiltä ei kovin paljon tarvinnut kysellä. Kun vaatimukset olivat selvillä, oli suoraviivaista suunnitella ne täyttävä ohjelmistoarkkitehtuuri: tietokanta ja sen päälle lomakejärjestelmä käyttöliittymäksi. Käyttäjät käyttivät, koska heillä ei yleensä ollut muuta mahdollisuutta. Järjestelmät olivat näet pääosin työkäytössä, eikä samaan firmaan montaa kilpailevaa järjestelmää hankittu.

Nyt tilanne on toinen. Jokaisella on nykyään käytössä maailman parhaat ja viimestellyimmät käyttöliittymät, jotka toimivat kaikilla eri alustoilla tietokoneesta mobiiliin. Käyttöliittymät ovat helppokäyttöisiä, intuitiivisia, käyttäjään ja hänen toimintaansa mukautuvia. Käyttäjät – me kaikki – oletamme, että kaikki järjestelmät ovat vähintään yhtä hyviä kuin Facebook, Google Mail, Instagram, Spotify, Moves ja niin edelleen. Huonompia emme mukisematta käytä – jos käytämme laisinkaan.

Ohjelmistojen ja erityisesti ohjelmistoarkkitehtuurin suunnittelu on muuttunut yhtäkkiä paljon vaikeammaksi. Vaatimukset ovat niin kovia, verrokkiryhmän käyttöliittymät ja käytettävyys niin hyviä, ettei virheisiin ole varaa. Jos uuden järjestelmän käyttöliittymä ei miellytä tai sen käytettävyydessä on ongelmia ohjelmistoarkkitehtuurista johtuen, käyttäjät katoavat.

Käyttäjä on kuningas

Käyttäjästä on sukeutunut kuningas. Kuninkaana hän odottaa saavansa mitä parhainta palvelua: ilmaista, koska kuninkaat eivät maksa; helppokäyttöistä, koska kuninkaat eivät lue ohjeita; jatkuvasti parantuvaa, koska kuninkaalle ei mikään ole riittävän hyvää. Jos kuninkaan saa maksamaan, hän osoittautuu kitsaaksi. Isot lisenssimaksut liiketoiminnan perustana on syytä unohtaa.

Kuningas on myös kärsimätön. Järjestelmien on toimittava yhtä nopeasti, kuin kuninkaan ajatus. Oikeastaan järjestelmän on pystyttävä ennakoimaan kuninkaan ajatukset ja tarjottava kuninkaalle hänen tarvitsemiaan tietoja ja vaihtoehtoja jo ennen kuin kuningas itsekään tietää niitä haluavansa. Järjestelmän on oltava älykäs, mutta ei liiaksi, koska kuningas ei halua tulla aliarvioiduksi.

Joskus kuningas liikkuu netissä tuntemattomana, anonyyminä. Hän käyttää järjestelmiä aikansa ja jos hän jonkin järjestelmän havaitsee hyväksi ja hyödylliseksi, hän paljastaa identiteettinsä. Kuningas kuitenkin pahastuu, jos hänen anonyyminä ollessaan keräämänsä tieto ja tekemänsä valinnat katoavat. Kuningasta ei ole helppoa palvella. Hän on oikukas.

Ohjelmistoarkkitehtuuria kuninkaille

Miten sitten suunnitella kuninkaille sopivaa ohjelmistoarkkitehtuuria? Mitä asioita on otettava huomioon? Mitä ohjelmistoarkkitehdin on tiedettävä, mitä osattava? Ainakin seuraavat kahdeksan asiaa on syytä ottaa huomioon ohjelmistoarkkitehtiä valittaessa ja ohjelmistoarkkitehtuuria suunniteltaessa.

  1. Ohjelmistoarkkitehdin on tunnettava lukematon joukko moderneja järjestelmiä, ymmärrettävä niiden hyvät ja huonot puolet, erilaiset käyttöliittymäparadigmat ja niistä johtuvat vaatimukset järjestelmän muille osille. Arkkitehdin on siis syytä käyttää paljon aikaa erilaisiin järjestelmiin tutustumiseen. Kännykkää räpläävä ohjelmistoarkkitehti saattaa tehdä töitä, ei surffailla pitkästyneenä.
  2. Ohjelmistoarkkitehdin on pystyttävä tekemään luontevasti töitä käyttöliittymäsuunnittelijoiden ja käytettävyysasiantuntijoiden kanssa. Koska käyttöliittymän käyttäminen on paljon opettavaisempaa, kuin käyttöliittymästä puhuminen, ohjelmistoarkkitehdin on joko itse pystyttävä rakentamaan riittävän todenkaltainen prototyyppi tai oltava sosiaalisesti niin lahjakas, että saa koodaajat protoilemaan hyvinkin epämääräisten ideoiden perusteella.
  3. Ohjelmistoarkkitehdin on ymmärrettävä, mitkä käyttöliittymän ominaisuudet ovat olennaisen tärkeitä järjestelmän back-end monimutkaisuuden kannalta. Hänen on pystyttävä kertomaan tilaajalle/maksajalle, mitä minkäkinlainen käyttöliittymä tarkoittaa hinnan ja/tai aikataulun kannalta.
  4. Ohjelmistoarkkitehdin on oltava tiukkana joidenkin vaatimusten suhteen. Erityisesti vasteaikojen määrittäminen on olennaisen tärkeää. Miten kauan käyttäjä on valmis odottamaan? Vasteaika on hyvin olennainen tekijä järjestelmän hinnan määräytymisessä.
  5. Ohjelmistoarkkitehdin on syytä tajuta, että käyttäjät saattavat käyttää järjestelmää hyvin eri tavalla, kuin järjestelmä on suunniteltu käytettäväksi. Järjestelmää ei pidä mitoittaa tai muutoin rajoittaa.
  6. Ohjelmistoarkkitehdin on valmistauduttava jatkuvaan muutokseen. Järjestelmä on suunniteltava niin, että sitä on helppoa muuttaa käyttäjien käytöksessä havaittavien muutosten myötä. Järjestelmä on myös suunniteltava niin, että sitä voidaan muuttaa vähitellen, muutosten suosio käyttäjillä heidän tietämättään testaten.
  7. Ohjelmistoarkkitehdin on oltava rohkea. Hänen on uskallettava kertoa tilaajalle, jos tilaajan taustajärjestelmien tai muiden nykyjärjestelmien päälle ei voi rakentaa modernia käyttöliittymää. Ei ole järkeä tehdä huonoa käyttöliittymää vain ikivanhojen taustajärjestelmien vuoksi. Joko on korvattava vanhat järjestelmät uusilla tai piilotettava ne jonkin nerokkaan välikerroksen taakse.
  8. Ohjelmistoarkkitehti ei saa rakastua työnsä tuloksiin. Nykyinen kehitysvauhti voi vaatia järjestelmien uudelleen toteuttamisen muutaman vuoden välein. Olennaista on olla suututtamatta kuningasta.

Ohjelmistoarkkitehtuurin merkitys kasvaa koko ajan. On hyvä huomata, että kuningas pitää hyvästä ohjelmistoarkkitehtuurista, vaikkei hän siitä mitään ymmärräkään. Mitä vähemmän kuningas kiinnittää huomiota järjestelmään, sen parempi. Valitettavasti tämä vaatii vuosi vuodelta enemmän työtä ja osaamista ohjelmistoarkkitehdeiltä.

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Kuinka valita avoin lisenssi?

Yhä useampi julkinen organisaatio julkaisee teettämäänsä ohjelmistot avoimena lähdekoodina. Muun muassa Helsingin kaupunki, HSL ja maanmittauslaitos. Erinomaista kehitystä, mutta tässä tulee tietysti käytännön kysymys ratkaistavaksi. Yhtenä isona kysymyksenä pitää miettiä, millä avoimen koodin lisenssillä ohjelmistot julkaistaan. Niitä kun on aika monta ja joka lähtöön.

Pääsin ratkomaan tätä kysymystä yhden julkisen organisaation kanssa. Tuloksena syntyi tämä kalvosarja, jossa hahmotellaan näkökulmia, joita on syytä harkita lisenssiä valitessa.

 

Kalvot eivät anna suoraa vastausta, mikä on oikea lisenssi. Se kun riippuu tilanteesta. Jos kalvot herättävät kysymyksiä, tulen mielelläni keskustelemaan lisenssivalinnasta juuri teidän organisaatiossanne.

Myös kommentit ja kehitysehdoitukset ovat tervetulleita.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Kokonaisarkkitehtuurista ohjelmistoarkkitehtuuriin

Tietohallinnoissa on ollut viime aikoina tapana selvittää ja kehittää kokonaisarkkitehtuuria. Valtiolla tätä vaatii  tietohallintolaki. Selvityksiin on yleensä tapana käyttää TOGAF-menetelmää tai sen suomalaista johdannaista, JHS-179-suositusta. Tulokset ovat olleet vaihtelevia. Joskus selvittelyn tulos on järjestelmäluettelo, joskus enemmän.

TOGAF-tyyppisissä selvityksissä on yksi perustavanlaatuinen vika. Ne eivät lisää ymmärrystä nopeasti eivätkä millään tavalla helpota siirtymää ohjelmistoarkkitehtuurin suunnitteluun, kun on tarpeen toteuttaa uusi ohjelmisto kokonaisuuden osaksi.  Ohjelmistoarkkitehtuurin suunnittelussa on olennaista ymmärtää kokonaisuus helposti ja riittävän yksiselitteisesti.

Tämän kirjoituksen tarkoituksena on hahmotella visuaalinen ja helppokäyttöinen menetelmä ohjelmistoarkkitehtuurityön aloittamiseksi kokonaisarkkitehtuurista lähtien. Aivan aluksi on kuitenkin ymmärrettävä, miksi joskus on tarpeen tehdä tai teettää uusi ohjelmisto.

Miksi uusi ohjelmisto?

Ohjelmisto – tai sovellus – on aina keino täyttää jokin nykyisten tai tulevien asiakkaiden tarve. Ohjelmisto luo asiakkaille arvoa. Asiakkaat ovat valmiit maksamaan arvosta, mikäli heidän ohjelmistosta saamansa hyöty on suurempi kuin ohjelmiston käytöstä syntyvät kustannukset. Kun asiakkaat ovat valmiita maksamaan, saa ohjelmiston tekijä ja omistaja tuloja. Julkishallinnossa arvo voi olla esimerkiksi parempi palvelu tai kulujen väheneminen, joskus jopa kunnan tai valtion tulojen kasvu.

Arvon tuottaminen asiakkaille on siis olennaista. Se onnistuu vain, jos tuntee asiakkaan ja hänen tarpeensa sekä ympäristön, jonka osaksi uusi ohjelmisto on suunniteltu. Jos ei tunne asiakkaan tarpeita, ei niitä voi täyttää eikä asiakas suostu maksamaan. Jos ei tunne ympäristöä, ohjelmiston toteuttaminen on hankalaa ja kallista. Ohjelmistosta voi tulla huono tai liian kallis.

Asiakkaiden tarpeiden löytämiseen ja ymmärtämiseen on olemassa monia tehokkaista menetelmiä: käyttäjäkertomukset (user stories), prototyypit ja vaikkapa lead user -menetelmä. Näistä ja niiden suhteista ohjelmistoarkkitehtuuriin kirjoitan myöhemmässä artikkelissa.

Kun asiakkaan tarpeet ovat tiedossa, seuraavaksi on selvitettävä ja ymmärrettävä, millaiseen liiketoiminnalliseen ja tekniseen ympäristöön uusi ohjelmisto on liittymässä. On ymmärrettävä mitä yritys tekee, miten se tehtävänsä tekee, keiden kanssa se tekee yhteistyötä ja miten. Lisäksi on ymmärrettävä mitä reunaehtoja jo olemassa olevat järjestelmät yhdessä organisaation osaamisen ja perinteiden kanssa asettavat uudelle ohjelmistolle.

Tätä työtä – ympäristöymmärryksen luomista – voisi vaikka kutsua ohjelmistoarkkitehtuurin ylätasoksi tai perustaksi. Työn tuloksen on oltava hyvin selkeä ja kaikkien osapuolten – myös muun kuin ohjelmistoteknisen koulutuksen saaneiden – ymmärrettävissä.

Yritys muuntaa raaka-aineet tuotteiksi

Uusi ohjelmisto on osa yrityksen tietojärjestelmäkokonaisuutta, jonka tarkoituksena on tuottaa asiakkaille arvoa. Siksi ymmärrystä luotaessa on lähdettävä liikkeelle yrityksen toiminnasta. Kullakin yrityksellä – tai isomman yrityksen osalla – on jokin pääasiallinen tehtävä. Jotkut yritykset tuottavat fyysisiä tuotteita, jotkut palveluita, jotkut informaatiota. Ylätasolla yritystä voi siis tarkastella mustana laatikkona, joka muokkaa syötteistä (raaka-aineista) valmiita tuotteita. Yksinkertaistettuna kuvana siis seuraavasti:

Ohjelmistoarkkitehtuuri alkaa tästä

Yritys siis saa syötteitä toimittajilta, tekee syötteille jonkin muunnoksen tai yhdistelyn ja toimittaa tuloksen asiakkaille. Tuotteet siis virtaavat yrityksen läpi kuvassa vasemmalta oikealle.

Tilaukset sen sijaan virtaavat oikealta vasemmalle. Asiakkaat tekevät tilauksia. Niiden perusteella yritys itse tekee tilauksia omille toimittajilleen.

Tuotteita vain tilauksesta. Just in time.
Tuotteita vain tilauksesta. Just in time.

Raha yhdistää osapuolet

Tuotevirran ja tilausvirran lisäksi yrityksen läpi virtaa muutakin. Erityisesti yrityksen läpi virtaa rahaa. Raha jakautuu yrityksen sisällä useaan eri osaan. Näiden mallintamiseksi kuvaan on lisättävä kaksi osapuolta: henkilöstö ja johto sekä valtio. Henkilöstö operoi yritystä, laatii suunnitelmat, valvoo tuotantoa jne. Vastineeksi henkilöstö saa palkkaa. Johto – johon kuuluvaksi ajattelemme myös omistajat –  ja valtio haluavat yrityksestä tietoa ja rahaa, omistajat osinkonsa ja valtio veronsa. Johto haluaa lisäksi erilaista raportointia, jotta johto voisi johtaa yritystä kulloisenkin tilanteen vaatimalla tavalla.

Kuvan muodossa tilanne on nyt tällainen:

 

Raha yhdistää osapuolet
Raha yhdistää osapuolet

Tätä kaaviota käyttäen yrityksen toimintaan on helppoa pureutua yhä syvemmälle. Kaavion avulla on suoraviivaista keskustella eri järjestelmistä ja niiden välisistä tietovirroista, tiedon omistajuudesta sekä järjestelmien muodostamista osakokonaisuuksista.

Tarkastelkaamme kaaviota käyttäen ja täydentäen kuvitteellista konepajayritystä. Yritys tuottaa fyysisiä tuotteita tehtaassaan. Yrityksen tuotantoa – niin valmistusta, tilauksia kuin toimituksia – hallitsee jokin ERP-järjestelmä. ERP saa tuotanto-ohjeet CAD-järjestelmältä ja tilaukset asiakkaan tilausjärjestelmältä.

Toimittajien käytössä on järjestelmä, josta he voivat nähdä tilaukset. Henkilöstön käytössä on työajanseuranta, palkkajärjestelmä ja koko joukko tuotannonsuunnitteluun liittyviä järjestelmiä.

Kuvana tämän voi esittää seuraavalla tavalla:

Ohjelmistojen lisääminen kuvaan lisää ymmärrystä
Ohjelmistojen lisääminen kuvaan lisää ymmärrystä

Miten jatkaa eteenpäin?

Kuvaan voi vähitellen lisätä yhä enemmän järjestelmiä. Kuvan avulla on kenen tahansa mahdollista ymmärtää, mihin kohtaan uusi järjestelmä on tulossa, millaisia tietovirtoja järjestelmän läpi on syytä kulkea ja mihin muuhun uusi järjestelmä vaikuttaa. Mitä keskemmällä kuvaa järjestelmä on, sitä laajempi sen vaikutus yleensä on.

On huomattava, että mikään kuva ei lisää ymmärrystä yhtä paljon kuin kuvan rakentaminen yhdessä keskustellen. Siksi kuva itsenään ei ole arvokas, ainoastaan kuvan kautta keskustelu on. Dokumentaatio ilman yhteistä työtä ja dialogia on arvotonta.

———

*Julkishallinnossa ja suuremmissa yrityksissä uudet järjestelmät voivat jäädä tuotantoon vaikka ne eivät tuottaisikaan asiakasarvoa.

(Tämä on ensimmäinen osa ohjelmistoarkkitehtuuria käsittelevää artikkelisarjaa. Seuraavissa artikkeleissa käsittelen muun muassa käyttöliittymien merkitystä ohjelmistoarkkitehtuuria suunniteltaessa ja ohjelmistoarkkitehtuurin suunnitteluun Codentossa kehitettyä “Lean SW architecture canvas” -työkalua).

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Tulevaisuuden työ à la Buurtzorg

Rollaattorikilpailut ovat Buurtzorgin keksimä ilmainen ja tehokas markkinointikeino, kävi ilmi Future of Work -seminaarissa.

9500 työntekijää, 0 johtajaa ja päällikköä, 15 valmentajaa

Tiistaina 4.8. Hanken kuhisi työelämän uudistusväkeä, kun Jos de Blok, hollantilaisen kotihoitoyritys Buurtzorgin perustaja, oli saatu Hankenille esittelemään johtamismalliaan.

Innostus on hyvistä syistä kovaa ketteryys- ja teal-väen keskuudessa. Buurtzorg on 9500 työntekijän yritys, jossa on 0 päällikköä ja johtajaa eikä yhtään johtoryhmää. Sen sijaan yritys tekee kotihoitoa itseorganisoituvilla tiimeillä, joilla on käytössään 15-päinen valmentajajoukko tiukkoja tilanteita ja oppimista varten.

Tulokset ovat toistaiseksi huikeita:

  • Yritys on kasvanut 4 työntekijästä 9500:aan kahdeksan vuoden aikana
  • Asiakastyytyväisyyden keskiarvo on 9,1
  • 500 000 potilaan joukosta ei ole tullut yhtään valitusta
  • Hallintokustannukset 8 % (alan normi 25 %)

Buurtzorgin malli perustuu kuuteen periaatteeseen:

  • Itsensä johtaminen. Luotetaan siihen, että työntekijät paitsi ymmärtävät parhaiten miten itse työ kannattaa tehdä, selviytyvät keskenään tiiminsä toiminnan järjestämisestä tarkoituksenmukaisella tavalla.
  • Ihmiset kokonaisina. Kun työntekijät saavat tuoda töihin ammattiminänsä lisäksi loputkin persoonastaan, lisääntyy ilo, energia ja intohimo.
  • Kehittymisen tavoite. Tunnustellaan jatkuvasti, mitä asiakkaat tarvitsevat, ja toimitaan sen mukaan. Ei muodollisia budjetteja, suunnitelmia, tavoitteita ja kannustimia.
  • Tarve. Siihen panostetaan, mitä asiakas tarvitsee. Muusta voi karsia.
  • Uudelleen ajattelu. Työntekijöitä rohkaistaan näkemään metsä puilta ja ajattelemaan asioita uudelleen. Johtotähtenä tässä on toisaalta asiakkaiden tarpeet, toisaalta töiden yksinkertaistaminen.
  • Arkijärki. Tehdään työt nykyisellä tavalla, kunnes maailma ympärillä vaatii muutosta tai joku keksii paremman tavan. Sitten muutetaan työtapaa.

Koko lista on tietenkin softa-alalle melko tuttuja asioita, mutta silti muutama pointti esityksessä sai takaraivon helähtämään. Suurin osa IT-alankin asiakkaista ja tekijöistä voisi vielä tsempata näissä Buurtzorg-opeissa:

  1. Tarkkaillaan ensin miten työtä tehdään, ja kehitetään sitten vasta softaa sen tueksi
  2. Mitataan lopputuloksia, ei prosessia
  3. Johdetaan silmiin katsomalla. Se kantaa myös vaikeiden aikojen yli.
  4. Parasta markkinointia on se, jossa asiakkaat päästetään juhlimaan heille tärkeitä asioita. Ja henkilöstö usein tietää, mikä tässä toimii. Vilkaise vaikka Buurtzorgin lanseeraamaa kansallista rollaattorikisaa (Voit luottaa siihen että hollannin kieli ei tässä videossa haittaa 🙂 ).

* * *
Buurtzorgin metodi perustuu teal-ajatteluun jota tunnetuimmin selittää Frederic Laloux’n Reinventing organisations -kirja. Myöhemmin Buurtzorgin omat opit on dokumentoitu otsikolla Integrating Simplification.