Mitä yhteistä on Farmville-verkkopelin pelaajilla ja projektiryhmän jäsenillä? Ensi silmäyksellä ei paljon – toinen rakentaa virtuaalista maatilaa, toinen kehittää tuotetta. Mutta jos tarkastellaan tarkemmin, yksi yhteinen piirre on se, että molemmat panostavat aikaa ja vaivaa tavoitteiden saavuttamiseen.
Uponneet kustannukset – Uponneet kustannukset
Mitä tapahtuu, kun Farmville-pelaaja ei jossain vaiheessa enää halua pelata? Kovalla työllä saavutettu edistyminen pelissä katoaa jälleen. Ja tästä ongelma alkaa: päätöstä pelaamisen jatkamisesta ei tehdä rationaalisesti. Sen sijaan, että pohdittaisiin tulevia kustannuksia ja hyötyjä, mietitään, kuinka paljon aikaa peliin on jo sijoitettu. Tätä sijoitettua aikaa ei voi saada takaisin. Jotta siitä ei kuitenkaan tulisi "menetettyä aikaa", pelaaja päättää käyttää lisää resursseja.
Vaikka järkevästi ajateltuna olisi ollut oikea päätös lopettaa peli, koska ajan käyttämisestä eri tavalla olisi ollut enemmän hyötyä, sinä jatkat pelaamista. Hyvä konsepti, jonka Farmvillen kehittäjät ovat keksineet.
Esimerkki "uponneista kustannuksista
Seuraava esimerkki osoittaa, miten tämä liittyy projektiryhmään: Pitkän tuotekehitysvaiheen jälkeen valmis tuote on vihdoin valmis. Tiimi on tyytyväinen; onhan se panostanut kehitystyöhön paljon resursseja (sekä ajallisesti että tiedollisesti ja taloudellisesti). Seuraava vaihe on esittely asiakkaalle.
Tiimi lähtee optimistisena mukaan, mutta tulee järkyttyneenä ulos: asiakas on kuvitellut lopputuotteen toisin, vaatimukset ovat muuttuneet. Nyt tiimi on päätöksen edessä: joko he aloittavat alusta ja kehittävät uuden tuotteen tai he pitävät jo kehitetyn tuotteen (joka ei kuitenkaan vastaa asiakkaan tarpeita) ja muuttavat muutamia pieniä asioita.
Rationaalisesti tiimin pitäisi päättää kehittää uusi tuote, joka vastaa asiakkaan vaatimuksia ja toiveita. Kunpa ei olisi kaikkia niitä resursseja, joita se on jo sijoittanut kehitykseen – noita typeriä uponneita kustannuksia.
Miksi emme voi päästää irti?
The Sunkkakustannusten harhaluulo kuvaa juuri tätä tapausta, jossa lisäresursseja investoidaan johonkin, joka on osoittautunut ei-kohderyhmälähtöiseksi tai jopa vääräksi (Arkes & Blumer, 1985). Ihmisillä tai tiimeillä, joihin tämä päätöksentekovirhe kohdistuu, on yleensä kolme yhteistä asiaa (Brockner, 1992):
- He ovat jo investoineet paljon aikaa, rahaa, työtä jne.
- Sijoitetut resurssit eivät johtaneet menestykseen.
- He voivat päättää, mitä tehdä nyt: investoida hankkeeseen lisää resursseja vai peruuttaa hanke.
Kysymys kuuluu, miksi yritämme pelastaa laivan, joka on jo uponnut. Psykologi ja taloustieteen Nobel-palkinnon saaja Daniel Kahneman pitää hänen Prospektiteoria on selitys valmiina: Ihmiset pelkäävät tappioita (Kahneman & Tversky, 1979). Tämä pelko menee niin pitkälle, että he mieluummin investoivat epätodennäköiseen mahdollisuuteen saada tuhoon tuomittu hanke onnistuneesti päätökseen kuin hyväksyvät varman epäonnistumisen.
Uponneet kustannukset vs. asiakaslähtöisyys – Scrum ratkaisuna?
On selvää, että epäonnistuneista hankkeista kiinni pitäminen on vastoin asiakkaiden saamaa hyötyä. Mutta mitä tiimit voivat tehdä välttääkseen joutumasta Sunk Cost Fallacy antautua? Yksi vastaus on ketterä työskentely. Asiakaslähtöisyys on siinä yksi tärkeimmistä periaatteista. Kun asiakasarvo asetetaan etusijalle, voidaan estää entistä suurempien resurssien sijoittaminen.
Scrum-tiimien työskentelyssä asiakas on mukana koko kehitysprosessissa, joten asiakkaan muuttuviin tarpeisiin voidaan reagoida nopeasti. Jatkuva tiedonvaihto varmistaa, ettei kehitysvaiheen lopussa tule shokkihetkeä, kun käy ilmi, että asiakas odotti toisenlaista tuotetta.
Olemme valmiita hylkäämään jo tehdyn työn, jos uudet oivallukset asiakkaiden tarpeista sitä vaativat. (Echometer-kohde)
Konkreettisesti tämä tarkoittaa sitä, että ryhmien on työskenneltävä lyhyissä Sprintit työtä. Alussa määritetään, mitä lähiviikkoina työstetään. Sprintin lopussa tarkistetaan, onko asetetut tavoitteet saavutettu. Käyttäjätarinat ovat tärkeä työkalu, jota Scrum-tiimien tulisi käyttää. Niissä asiakkaan vaatimukset käännetään käyttäjäkeskeiseksi lausunnoksi tuotteesta formaatin mukaisesti:
Kuten Rulla
Kun käyttäjätarinat on luotu, ne siirretään tuotetietokantaan, ja ne muodostavat sisällöllisen perustan kehitystiimin työlle. Kuten monet Scrumin käsitteet, käyttäjätarinat eivät ole staattisia: jos asiakkaan vaatimukset muuttuvat, myös käyttäjätarina muuttuu.
Tämä mahdollistaa erittäin korkean asiakaslähtöisyyden tason. Koska Scrum-tiimit työskentelevät itseorganisoituneesti, on tärkeää analysoida edellisen sprintin käyttäjätarinat sprinttiretrossa. Jatkuvan parantamisen varmistamiseksi voidaan esimerkiksi kerätä syitä siihen, miksi jokin tietty tarina meni hyvin tai huonosti.
Haluatko kehittyä tiiminä? Ja ottaa huomioon uusimmat psykologiset tutkimustulokset? Sitten suosittelemme tiimityöpajamme Retro Toolia. Tässä Holgerin kokemuksia siitä:
Pähkinänkuoressa...
Scrum-tiimien iteratiivinen lähestymistapa ja asiakkaiden tarpeiden jatkuva tarkastelu auttavat välttämään uponneita kustannuksia. Sprinttien aikana kehitettävien tuote-inkrementtien ei tulisi optimaalisesti olla liian resurssi-intensiivisiä. Tämä johtaa siihen, että tiimi sitoutuu uusiin tavoitteisiin, kun vaatimukset muuttuvat. Oletko jo kokenut tiimissäsi uponneita kustannuksia koskevan ongelman? Kokeile käsitellä ongelmaa retrospektiivissä ja kehitä ratkaisuja yhdessä!
Ja jos olet kiinnostunut vielä useammista menetelmistä, joilla voit lisätä suorituskykyäsi tiimissä, voit esimerkiksi lukea meidän Artikkeli hämmästyttävästä totuudesta ketterän ajattelutavan takana katso.
Lähteet
Arkes, H. R. & Blumer, C. (1985). Uponneiden kustannusten psykologia. Organisaatiokäyttäytyminen ja inhimilliset päätöksentekoprosessit, 35, 124–140.
Brockner, J. (1992). Epäonnistuneeseen toimintatapaan sitoutumisen eskaloituminen: kohti teoreettista edistystä. Academy of management Review, 17(1), 39-61.
Kahneman, D. & Tversky, A. (1979). Prospect theory: An analysis of decision under risk. Econometrica, 47, 262–291.
