Työskentele taaksepäin päästäksesi eteenpäin (Jeff Gothelf Gothelf.co:sta)

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmiston avulla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.

Ben Aston:

Rehellisesti sanottuna: tuottavatko projektisi koskaan todella sitä, mitä toivoit niiden tuottavan? Tai mitä ne olisivat voineet tai niiden olisi pitänyt tuottaa? Miksi näin tapahtuu? Johtuuko se ehkä siitä, ettet suunnitellut? Tai siitä, ettet johtanut tiimiäsi hyvin? Ehkä sinulla oli vaikeuksia hallita ja pitää sidosryhmiäsi mukana. Ehkä kaikki edellä mainitut pitävät paikkansa. Ehkä ette olleet täysin yhtä mieltä projektien lopullisesta tavoitteesta ja visiosta. Kuuntele siis tämän päivän podcast, jos haluat oppia, kuinka voit työskennellä taaksepäin edetäksesi varmemmin hyvien projektien kanssa, vähentää epäonnistumisen riskiä ja parantaa projektin onnistumisen mahdollisuuksia.

Kiitos, että kuuntelet. Olen Ben Aston, The Digital Project Managerin perustaja. Tervetuloa DPM-podcastiin. Tehtävämme on auttaa projektipäälliköitä onnistumaan ja auttaa projekteja johtavia ihmisiä toimittamaan parempia tuloksia. Olemme täällä auttaaksemme sinua viemään projektiosaamisesi seuraavalle tasolle.

Tutustu osoitteeseen thedigitalprojectmanager.com saadaksesi tietoa jäsenyytemme kautta tarjoamistamme koulutuksista ja resursseista. Tämän podcastin mahdollistaa Clarizen, yritysten projektien ja projektisalkkujen hallintaohjelmistojen johtava toimittaja. Lisätietoja saat osoitteesta Clarizen.com.

Tänään seurassani on Jeff Gothelf. Jeff opettaa johtajia ja tiimejä etäneuvonnan, valmennustyöpajojen, pääpuheenvuorojen ja kirjojen avulla keskittymään asiakkaisiin, oppimaan virheistä sekä rakentamaan ketterää kulttuuria, joka kehittää jatkuvasti tuotteita, palveluita ja työskentelytapoja.

Hän on ollut mukana kirjoittamassa useita lukemiasi tai ainakin kuulemiasi kirjoja, kuten Sense and Respond ja erityisesti Lean UX. Lisäksi hän on hiljattain perustanut Sense and Respond Press -kustantamon, joka julkaisee nykyaikaisia, liiketoimintaa uudistavia kirjoja. Jeff, kiitos paljon, että liityit seuraamme tänään.

Jeff Gothelf:

Hei Ben, kiitos kutsusta ohjelmaan.

Ben Aston:

Haluan aloittaa puhumalla projekteista. Tiedän, että olet vahvasti tuoteorientoitunut, mutta meille projektipäälliköille, jotka johdamme projekteja, ne voivat olla osa suurempaa työohjelmaa tai tuotteen tiekarttaa.

Olen kiinnostunut kuulemaan, miten ajattelet meidän projektijohtajina voivan suunnata itsemme ja tiimimme kohti iteratiivisempaa lähestymistapaa. Olet juuri kirjoittanut tekstin kymmenestä yleisimmästä vastauksesta väitteeseen ”Ketterä on hienoa, mutta se ei toimi täällä”. Haluaisin keskustella joistakin haasteista, joita digitaalisten projektien johtajina kohtaamme, ja siitä, miksi niitä syntyy.

Pohjimmiltaan uskon, että kaikki asiakkaat ja sidosryhmät, joiden kanssa työskentelemme, pitävät ketterän työskentelyn ajatuksesta. Voimme toki keskustella siitä, mitä ketteryys tarkoittaa: puhummeko toimituskehyksestä vai laajemmin ajattelutavasta? Keskitytään tässä enemmän tähän ketterään ajattelutapaan.

Mielestäni meidän täytyy puhua kolmesta haasteesta. Ensimmäinen on asiakkaan epäluottamus, toinen liian tarkasti määritellyt vaatimukset ja kolmas budjetin ja ajan puute. Asiakkaat haluavat toimia ketterästi, mutta heillä ei aina ole siihen tarvittavaa budjettia tai aikaa.

Asiakkailla on liian tarkasti määritellyt vaatimukset, ja lisäksi he eivät välttämättä luota toimistoon tai tiimiin niin paljon, että voisivat päästää irti ja luottaa prosessiin. Näitä haasteita on siis kolme. Mistä haluat aloittaa?

Jeff Gothelf:

Aloitetaan ajattelutavan muutoksesta, koska se on erityisesti digitaalisten projektipäälliköiden kannalta ratkaisevan tärkeä asia. Jos haluamme onnistua rakentamaan hyviä tiimejä, tuotteita ja palveluita sekä menestyviä yrityksiä, asiakkaita ja käyttäjiä, meidän on ymmärrettävä digitaalisen tuotekehityksen perustavanlaatuinen ero nykyään.

Perustavanlaatuinen ero nykyhetken ja kymmenen tai viidentoista vuoden takaisen ajan välillä on se, että ohjelmisto on nykyään jatkuvaa. Emme enää mene kauppaan ostamaan ohjelmistolaatikkoa. Tilaamme ohjelmiston tai asennamme sen, lataamme päivityksiä ja ohjelmisto kehittyy jatkuvasti.

Se paranee koko ajan. Et mene kauppaan ostamaan Facebookin seuraavaa versiota. Et mene ostamaan Pinterestin tai Amazonin seuraavaa versiota. Tuote paranee ja muuttuu jatkuvasti ajan mittaan. Tämä on projektiajattelun ja tuoteajattelun perustavanlaatuinen ero.

Nykyään rakennamme näitä jatkuvasti kehittyviä järjestelmiä. Jokaisessa syklissä, jota voi kutsua sprintiksi tai iteraatioksi, meillä on mahdollisuus tehdä järjestelmästä parempi. Lisäämmekö siihen jotain? Optimoimmeko siinä jo olevia asioita? Poistammeko siitä jotain?

Mahdollisuuksia on monia, mutta nämä ovat kolme pääluokkaa. Tämä on tärkein asia ymmärtää, sillä nämä tuotteet eivät pääty. Ajatus siitä, että johdan projektin onnistuneeseen julkaisuun, on hyvä, mutta julkaisu on vain keskustelun alku kohdeyleisön kanssa. Se ei ole tuotteen loppu.

Ben Aston:

Ehdottomasti. Yksi haasteista, joita me digitaalisina projektipäälliköinä kohtaamme yrittäessämme puhua asiakkaille ketterämmästä työskentelystä, on se, että ehdotamme heidän maksavan omistautuneesta tiimistä tietyn ajanjakson ajan ja tekevän kanssamme yhteistyötä. Olemme esimerkiksi julkaisseet heidän verkkosivustonsa ja haluamme nyt iteroida sitä.

Kuten sanoit ohjelmistoista, verkkosivustoakin voidaan päivittää jatkuvasti. Tämä kuitenkin edellyttää luottamusta: palvelusta maksavan henkilön täytyy luottaa siihen, että hän saa prosessin lopussa hyvää vastinetta rahalleen. Miten projektipäälliköt voivat auttaa asiakasta ylittämään epäluottamuksen, kun toimitettavat asiat eivät ole ennalta tiedossa?

Jeff Gothelf:

Tässä on paljon purettavaa. Aloitetaan perustavanlaatuisesta kysymyksestä: millä liiketoiminta-alueella toimit? Asiakkaan ja toimittajan tai palveluntarjoajan näkökulmasta on kysyttävä, oletko liiketoiminnassa, jossa autat kumppanina asiakkaitasi saavuttamaan tavoitteita, vai liiketoiminnassa, jossa toimitat tiukan vaatimuskokonaisuuden.

Kuten sanoit, ristiriita syntyy siitä, että vaatimukset ovat tarkat, mutta niiden kanssa pitäisi silti toimia ketterästi. Se ei ole järkevää.

Ystäväni ja kollegani Jeff Pattonilta oppimani jatkumo auttaa selkeyttämään tätä. Toisessa päässä on lääkäri ja toisessa tarjoilija.

Haastan palveluorganisaatiot pohtimaan, missä ne sijaitsevat tällä jatkumolla. Jos olet tarjoilijan päässä, tehtäväsi on tuoda minulle täsmälleen se, mitä pyysin.

Ben Aston:

Aivan.

Jeff Gothelf:

Sillä ei ole merkitystä, syötkö annoksen, pidätkö siitä tai et. Pyysit pihvin salaatilla ja colajuoman, ja minä toin ne sinulle. Monet organisaatiot toimivat näin: anna minulle sata tuhatta, niin rakennan sinulle asian.

Lääkärille et mene sanomaan, että haluat tietyn lääkkeen, rokotteen ja hoidon. Lääkäri ei vain vastaa, että selvä, saat ne. Hän toimii konsulttina ja auttaa sinua parantamaan esimerkiksi suorituskykymittareitasi ja muita tulosmittareita.

Kysymys kuuluu siis, missä kohtaa jatkumoa olet. Ketterästi on huomattavasti helpompi toimia lääkärin kuin tarjoilijan päässä, koska onnistumisen mittarit ovat täysin erilaiset.

Tarjoilijan puolella onnistumista mitataan tuotoksella: toimitettiinko pyytämäni asia ajallaan ja budjetissa? Lääkäriä muistuttavassa mallissa onnistumista mitataan tuloksilla ja käyttäytymisen muutoksilla.

Ketterä työskentely loistaa tilanteissa, joissa epävarmuutta on paljon eikä ole selvää, mikä tarkalleen tuottaa halutun liiketoimintatuloksen. Siksi lääkärimäinen toimintatapa on arvokkaampi. Ketteryyttä ei voida aidosti ottaa käyttöön ennen kuin toimitettavaa asiaa ja toimitustapaa siirretään tarjoilijamallista kohti lääkärimallia.

Ben Aston:

Kyse on siis asiakkaan tai sidosryhmän siirtymisestä kontrollia korostavasta ajattelusta kohti luottamusta. Miten valmennat organisaatioita katsomaan tuntemattoman yli ja kehittämään halua hyväksyä epävarmuus?

Jeff Gothelf:

Keino on kysyä kunnioittavasti ja sitoutumista rajoittamatta ”miksi”. Kun joku sanoo tarvitsevansa kymmenen ominaisuutta perjantaiksi ja kysyy hintaa, sinun pitäisi voida kysyä kunnioittavasti, miksi hän haluaa juuri nämä ominaisuudet.

Sen jälkeen työskentelet asiakkaan kanssa ja muutat kiinteät vaatimukset ongelmalauseeksi. Kun tiimi sanoo tarvitsevansa mobiilisovelluksen perjantaiksi, kysy, miksi sovellusta tarvitaan. Jos vastaus on, että mobiilikaupan luvut ovat laskeneet ja niitä täytyy kasvattaa, ongelma voidaan muotoilla näin: haluamme saada enemmän ihmisiä ostamaan mobiilikanavan kautta. Kuinka paljon enemmän? Viidentoista prosentin kasvu olisi merkittävä.

Näin muutit vaatimuksen ”rakenna mobiilisovellus” tavoitteeksi ”kasvata mobiilikauppaa 15 prosenttia”. Poistit konkreettisen vaatimuksen keskustelusta ja pakotit tiimin kokeilemaan, oppimaan, iteroimaan ja parantamaan ratkaisua ketterästi.

Onnistumista ei mitata sovelluksen julkaisemisella vaan sillä, kasvaako mobiilikauppa 15 prosenttia. Oletuksena on suuri riski, jos uskot ominaisuusjoukkosi saavuttavan halutut tulokset. Useimmiten olet väärässä, vaikka olisit kuinka hyvä tässä työssä.

Hyvä tuotepäällikkö on oikeassa ehkä 30 prosenttia ajasta. Jos olet väärässä 70 prosenttia ajasta, etkö mieluummin käyttäisi prosessia, joka auttaa löytämään tavoitteiden saavuttamiseen tarkimman tavan mahdollisimman nopeasti, kuin sokeasti pyytäisit tiettyä sovellusta tiettyyn päivään mennessä?

Ben Aston:

Tämä on todella viisas näkökulma. Asiakkaan pyynnön muuttaminen ongelmalauseiksi ja miksi-kysymyksen esittäminen muuttaa keskustelun vaatimuslistasta laajuudeksi, jossa voimme tutkia ongelmaa, tunnistaa ratkaisuja, rakentaa niitä, testata, oppia ja iteroida.

Voisiko budjetin ja ajan puute olla syy siihen, ettei ketteryys toimi?

Jeff Gothelf:

Minusta tämä perustuu siihen, että ketterien prosessien tuomaa arvoa ymmärretään väärin. Kyse ei ole budjetista tai ajasta vaan riskien pienentämisestä. Sen sijaan että työskentelisimme kolme kuukautta jonkun käsityksen perusteella siitä, miltä onnistuminen näyttää, alamme selvittää mahdollisimman nopeasti, olemmeko menossa oikeaan suuntaan.

Jos emme ole, muutamme kurssia. Siinä kaikki. Jos tiimi muuttaa kurssia markkinoilta saadun näytön perusteella, se toimii ketterästi. Tällä ei ole mitään tekemistä budjetin tai ajan kanssa.

Vaihtoehto on käyttää esimerkiksi 75 000 dollaria sovelluksen rakentamiseen kuukaudessa ja huomata sen jälkeen, ettei ratkaisu toimi. Se on riski, jonka otat käyttäessäsi digitaaliseen tuotteeseen vesiputousmallia ja ennakoivaa, ylhäältä alaspäin ohjattua lähestymistapaa.

Ben Aston:

Mutta tämä riippuu myös siitä, kuka pyynnön esittää. Jos minulla on 30 dollaria ja haluan pihvin, colajuoman ja salaatin, voin haluta juuri ne, vaikka ne eivät olisi minulle parasta.

Jeff Gothelf:

Silloin menet tarjoilijalle. Jos menet lääkärille ja sanot haluavasi pihvin ja colajuoman, lääkäri ei anna niitä, koska hänen työnsä ei ole antaa sinulle haluamaasi annosta vaan tehdä sinusta terveempi.

Tämä on se, mitä useimmat palveluntarjoajat eivät ketteryydestä ymmärrä. Kyse ei ole yhdestä prosessista toisen sijaan, vaan yhdestä liiketoimintamallista toisen sijaan. Perinteisten palveluntarjoajien on vaikea ymmärtää tätä ja muuttaa toimintaansa sen mukaiseksi.

Ben Aston:

Tämä edellyttää siis kypsyyttä myös työn tilaajalta. Asiakas, joka haluaa vain pihvin, salaatin ja colajuoman ensi torstaiksi, on suuri haaste. Meidän täytyy muotoilla pyyntö uudelleen, ottaa lääkärin rooli ja luopua tarjoilijan asusta.

Olet kirjoittanut hienon tekstin asiakaskeskeisyydestä ja asiakaskeskeisten projektien suunnittelusta käyttäen päivitettyä versiota tulevan lehdistötiedotteen tekniikasta. Se perustuu Amazonin taaksepäin työskentelyn prosessiin ja keskittyy tuloksiin, riskienhallintaan ja yhteistyöhön. Miten tämä lähestymistapa auttaa käytännössä?

Jeff Gothelf:

Ensinnäkin se auttaa kuvittelemaan tulevaisuuden, jossa olet onnistunut, ja pakottaa miettimään, mikä teki sinusta onnistuneen. Sivustolla oleva versio tuo asiakkaan keskelle. Siinä ei vain sanota, että toimitimme hämmästyttävän järjestelmän ja kaikki rakastivat sitä, vaan kuvataan, mitä toimitimme ja millaisen käyttäytymisen muutoksen näimme.

Onnistumisen saavuttamiseksi täytyy ajatella asiakkaan käyttäytymistä, arvon tuottamista koko organisaatiossa ja sitä, millaisia yhteistyöhaasteita täytyy ratkaista.

Kyse on eräänlaisesta ennakkokuoleman analyysistä: kun julkaisemme asian ja se menestyy markkinoilla, mistä tiedämme onnistuneemme? Mitä meidän täytyi voittaa päästäksemme siihen tilanteeseen?

Tällainen keskustelu jää yleensä aloitteen alussa käymättä. Tavallisesti sanotaan, että rakenna tämä ja toimita se ajallaan budjetissa. Tässä mallissa onnistuminen tarkoittaa prosessin rakentamista niin, että voimme vaikuttaa asiakkaisiin myönteisesti ja tehdä heistä menestyneempiä, mikä tekee myös liiketoiminnasta menestyvämmän.

Kun keskustelu käydään alussa, tulevaa lehdistötiedotetta voidaan käyttää suodattimena koko aloitteen ajan. Auttaako tämä saavuttamaan tavoitteen? Jos ei, emme tee sitä vaan valitsemme jotain muuta. Se on erittäin voimakasta.

Ben Aston:

Tässä kuvitellaan tulevaisuuden tila ja tarkastellaan tuotteen ja markkinoiden yhteensopivuutta: haluttavuutta, elinkelpoisuutta ja toteutettavuutta. Onko ongelmalle suuri tarve? Toimiiko liiketoimintamalli? Pystymmekö todella tekemään tämän?

Mutta miten tätä validoidaan, kun käytämme mielikuvitusta? Tuotepäällikkö on oikeassa vain noin 30 prosenttia ajasta. Miten loput 70 prosenttia ja sodan sumu vaikuttavat tämän työkalun tarkkuuteen ja hyödyllisyyteen?

Jeff Gothelf:

Tämä antaa meille tavoitteen. Se on kunnianhimoinen päämäärä, jota tiiminä tavoittelemme. Yrität ennustaa tulevaisuutta, joten olet joissakin yksityiskohdissa väärässä. Kokonaisuutena pyrit kuitenkin kuvaamaan onnistumisen, esteet ja niiden voittamisen.

Sinun täytyy pyrkiä toteuttamaan tämä tarina aloitteen aikana. Jotkin osat eivät väistämättä toteudu, ja se on hyväksyttävää, jos pystyt objektiivisesti kertomaan, miksi jokin osa ei toteudu ja miten tarina muuttuu.

Pidämme tavoitteen ja pyrkimyksen näkyvillä ja suodatamme päätöksemme niiden läpi, kunnes markkinoilta saatu näyttö kertoo, että jokin kriteeri tuottaa jatkuvasti huonomman tuloksen. Silloin muutamme sitä.

Ben Aston:

Siirrämme painopistettä ja opimme, ettei jokin tavoitteen osa ole enää pätevä tai arvokas. Emme siirrä maalitolppia sattumanvaraisesti vaan säädämme tavoitetta todellisuuden perusteella, jota meillä ei projektin alussa ollut.

Onko tällä lähestymistavalla ongelmia? Voiko se estää tiimiä tai rajoittaa luovuutta?

Jeff Gothelf:

Suurin haaste on se, etteivät tiimit ole riittävän luovia tai kunnianhimoisia. Ne tekevät dokumentista liian turvallisen. Amerikanenglannissa tästä käytetään nimitystä ”sandbagging”: asetetaan tavoite, jonka tiedetään varmasti saavutettavan.

Suurin riski on, ettei ennakoida suuria ongelmia eikä aseteta onnistumisen kriteerejä riittävän kunnianhimoisesti.

Amazon on käyttänyt alkuperäistä mallia menestyksekkäästi, mutta alkuperäisestä mallista puuttui keskittyminen tuloksiin eli mitattaviin muutoksiin asiakkaan käyttäytymisessä. Se puhui liiketoimintahyödyistä, kuten rahan ansaitsemisesta tai asiakkaiden säilyttämisestä, mutta ei siitä, mitä asiakkaiden halutaan tekevän.

Toinen puute koskee yhteistyöhaasteita. Mikään ei päädy markkinoille vain tuotetiimin työn seurauksena. Mukaan tarvitaan lakiasiainosasto, talous, markkinointi, operatiiviset toiminnot ja vaatimustenmukaisuus. Miten teemme yhteistyötä koko organisaatiossa, jotta tavoiteltu kokemus voidaan toteuttaa?

Tämä on erityisen tärkeää organisaatioissa, joissa työskentelee yli muutama kymmenen ihmistä. Et ole saari etkä toimita tuotetta yksin. Muut ihmiset ja osastot on otettava mukaan huomattavasti aikaisemmin.

Ben Aston:

Tämä on todella voimakasta. Emme ajattele vain tuloksia vaan myös niiden saavuttamiseen tarvittavaa prosessia. Hyvät tavoitteet ja mittarit voidaan tunnistaa, mutta viestintä ja yhteistyö ovat usein kohtia, joissa asiat kaatuvat.

Siirrytään prosessiin. Olet työskennellyt konsultoinnissa, startup-yrityksissä ja toimistoissa, ja työskentelet nyt itsenäisesti. Miten näet menetelmien ja prosessien kehittyvän? Meillä on ketterä prosessikehitys, lean, ketteryys, muotoiluajattelu ja palvelumuotoilu. Miten näet ketteryyden kypsyvän ja erilaisten tekniikoiden ja viitekehysten kehittyvän?

Jeff Gothelf:

Väistämättä ketteryydestä tulee jossain vaiheessa organisaatioiden oletusarvo kaikkialla maailmassa. Nykyinen pandemia nopeuttaa tätä. Organisaatiot, jotka ovat jo ketteriä ja jotka pystyvät aistimaan, reagoimaan ja oppimaan, selviävät.

Organisaatiot, jotka eivät tähän pysty, kärsivät ja saattavat kuolla. Ketteryydestä on tultava uusi normaali, koska muutoksen nopeus ja markkinoiden sekä maailman epävakaus kasvavat jatkuvasti.

Jos toimit monoliittina, uppoat monoliitin tavoin. Jos pystyt toimimaan puoliautonomisten tiimien kokonaisuutena, jossa aistitaan, reagoidaan, opitaan, jaetaan tietoa ja muutetaan kurssia näytön perusteella, pystyt selviytymään suurista kriiseistä.

En tiedä, puhummeko kahdenkymmenen vuoden päästä sprinteistä, nopeudesta, palamiskaavioista ja työjonoista. Terminologia ja prosessien tuotemerkit voivat muuttua, mutta en voi kuvitella menestyvää maailmaa, jossa asiakaskeskeisyys, jatkuva oppiminen ja jatkuva parantaminen eivät olisi organisaatioiden oletusarvoisia toimintatapoja.

Ben Aston:

Tarvitsemmeko kaikki nämä viitekehykset? Miten lean, ketterä kehitys ja muotoiluajattelu toimivat yhdessä?

Jeff Gothelf:

Kirjoitin lyhyen kirjan Lean vastaan ketterä kehitys vastaan muotoiluajattelu. Sen pääajatus on, että nämä ovat erilaisia tuotemerkkejä hyvin samankaltaisten filosofioiden päällä. Aktiviteetit ja rytmit voivat olla erilaisia, mutta filosofisesti kyse on samoista asioista.

Organisaation täytyy valita yksi, yhdistää niitä tai rakentaa itselleen toimiva kokonaisuus. Tavoite ei ole toteuttaa reseptiä sokeasti vaan lisätä organisaation ketteryyttä.

Ajattele kokkaamista. Aloittelija hankkii keittokirjan ja noudattaa reseptiä sana sanalta. Jonkin ajan kuluttua hän alkaa muokata reseptiä ja lisää asioita, jotka tekevät ruoasta paremman. Lopulta ammattikokki ei tarvitse reseptiä vaan tietää, miten toimia erilaisissa keittiöissä.

Tämä on tiimin tai organisaation korkein kypsyystaso: se osaa toimia ketterästi erilaisissa ympäristöissä ja käyttää erilaisia työkaluja ja menetelmiä. Organisaatiot, jotka sitoutuvat yhteen reseptiin, altistavat itsensä epäonnistumiselle. Matka on ketteryys, ei reseptin toteuttaminen.

Ben Aston:

Tämä on syy siihen, miksi väite ”näin tätä pitää tehdä” herättää huolta. Prosessia voidaan iteroida, eikä tarkoitus ole seurata sitä sokeasti. Meidän pitäisi kysyä, auttaako tämä saavuttamaan tavoitteen, ei tarkistaa oppikirjasta, tehdäänkö asia keskiviikkona vai torstaina.

Kirjasi Sense and Respond käsittelee organisaation kykyä kuunnella asiakkaita ja luoda uusia tuotteita. Mitä muita tekniikoita menestyvät organisaatiot omaksuvat nykyisessä tilanteessa?

Jeff Gothelf:

Yksi viimeisenä muutettavista ja samalla tärkeimmistä asioista on kannustinrakenne ja suorituskyvyn hallinnan kriteerit. Voimme soveltaa kaikkia menetelmiä ja filosofioita, mutta jos minulle maksetaan ominaisuuden julkaisemisesta eikä tuloksen saavuttamisesta, julkaisen ominaisuuden.

Miten mittaamme ihmistemme onnistumista? Miten muutamme mittareita niin, että ne kannustavat uteliaisuuteen, oppimiseen ja parantamiseen? Jos näitä asioita ei kannusteta, ne eivät tapahdu.

Organisaatiot, jotka ymmärtävät tämän, yhdistävät kannustimet ja OKR-tavoitteet. OKR-tavoitteista tulee tiimin onnistumisen mittari, osa suoritusarviointia ja osa kannustimia.

Ben Aston:

Tämä on tärkeää, koska joskus luomme OKR:n tai mittarin ja huomaamme vasta sen saavuttamisen jälkeen, että se oli väärä mittari. Se voi ohjata työtä ja energiaa väärään suuntaan. Tuloksiin keskittyminen on hyödyllistä, mutta mittareiden valitseminen on haastavaa.

Haluan lopuksi puhua Scrum-kurssistasi. Miten UX-tutkimusta ja -suunnittelua tehdään Scrum-kehyksessä? Tämä haastaa toimistoissa työskenteleviä, koska kehitystyö vaikuttaa hyvin ohjaavalta, mutta UX-tutkimuksen lisääminen tekee asioista monimutkaisempia.

Jeff Gothelf:

Professional Scrum with UX -kurssi on suunniteltu ratkaisemaan juuri tämä haaste. Tarkastelemme käytännöllisesti sitä, mitä Scrum on nykyään ja miten sitä täytyy muuttaa, jotta se tukee käytäntöjä, joita ei Scrumin syntyessä huomioitu.

Käsittelemme, mitä työjonoon kuuluu, miten tarinoita kirjoitetaan, kuka tekee työn, mitä tapahtuu työn aikana ja kuinka suuri osa sprintistä on oppimista ja kuinka suuri osa toimitusta.

Lyhyesti kyse on monialaisesta yhteistyöstä. Suunnittelijan täytyy olla tiimin täysipäiväinen jäsen, ja löytämistyö on yhtä tärkeää kuin toimitustyö. Löytämisen ja toimittamisen välillä on vaihtelua, ja joskus suunnittelu- tai tutkimustyötä tekevät myös muut kuin suunnittelijat. Kaikkien tiimin jäsenten on hyväksyttävä tämä.

Ben Aston:

Scrumia kritisoidaan usein siitä, että se on liian ohjaava. Miten suhtaudut ohjaavaan kehykseen, kun tiedät, että sitä täytyy sovittaa eri organisaatioihin?

Jeff Gothelf:

Scrum.org:n kanssa hyvää oli se, että he olivat valmiita muuttamaan kantaansa. Aiemmin keskustelut päättyivät usein siihen, että ”tämä on Scrum, eikä se muutu; muuta oma toimintasi sopivaksi”. Nyt he olivat valmiita mukautumaan.

Tämä on resepti. Jos et tiedä, miten ratkaiset ongelman, aloita tästä reseptistä. Muokkaa sitä ajan mittaan tarpeidesi, olosuhteidesi, organisaatiosi ja tiimisi mukaiseksi. Aloita tästä, kehity ja täydennä reseptiä tarpeen mukaan.

Ben Aston:

Tämä on hyödyllinen ajatus kaikille, jotka harkitsevat ketterämpää lähestymistapaa. Prosessia kuvaavat viitekehykset ovat reseptejä, joita ei tarvitse seurata kirjaimellisesti. Niitä saa soveltaa haluttujen tulosten saavuttamiseksi. Sinua ei arvioida sen perusteella, kuinka tarkasti seuraat kehystä, vaan sen perusteella, kuinka hyvin saavutat tavoitteet.

Jeff, kiitos paljon, että liityit seuraamme.

Jeff Gothelf:

Ilo oli minun puolellani, Ben. Tämä oli hauskaa. Kiitos kutsusta.

Ben Aston:

Mitä keinoja ja vinkkejä sinulla on onnistuneeseen toimittamiseen? Oletko kokeillut lehdistötiedotetekniikkaa? Kerro meille kommenteissa onnistumisistasi ja epäonnistumisistasi.

Jos haluat oppia lisää ja edetä työssäsi, liity yhteisöömme DPM-jäsenyyden kautta osoitteessa thedigitalprojectmanager.com/membership . Saat käyttöösi Slack-tiimimme, mallipohjat, työpajat, kyselytunnit, sähköiset kirjat ja paljon muuta. Jos pidit kuulemastasi, tilaa podcast ja pysy yhteydessä osoitteessa thedigitalprojectmanager.com. Ensi kertaan asti: kiitos kuuntelusta.