Siirtyminen vesiputousmallista kesto- ja hintasopimuksiin (Crema-yhtiön Tucker Sauer-Pivonkan kanssa)

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmiston avulla. Pahoittelemme kirjoitusvirheitä, sillä automaattinen litterointi ei ole sataprosenttisen tarkka.

Ben Aston:

Tervetuloa DPM-podcastiin, jossa menemme teoriaa pidemmälle ja annamme käytännössä toimivia neuvoja parempien digitaalisten projektien johtamiseen. Kiitos, että kuuntelet. Olen Ben Aston, Digital Project Managerin perustaja. Projektit harvoin etenevät suunnitelmien mukaan, ja suunnitelmien muuttuessa se aiheuttaa usein paljon stressiä. On tehtävä päätöksiä, aikataulutettava kokouksia, päivitettävä suunnitelmia, laskettava arviot uudelleen ja yleensä laadittava muutosilmoituksia. Mutta entä jos projektien muutosten hallintaan olisi toinenkin tapa? Tässä podcastissa tarkastelemme asiaa eri näkökulmasta ja käsittelemme muutosten hallintaa ketterien sopimusten avulla. Kuuntele siis, niin opit, kuinka ketterät sopimukset saadaan toimimaan hyödyksesi sekä millaisia hyötyjä ja haasteita tähän lähestymistapaan liittyy.

Tänään seurassani on Tucker Sauer-Pivonka. Hän toimii tuotehallinnan johtajana ja auttaa tuotehallinnan ammattilaisia kasvamaan ja kehittymään. Lisäksi hän vastaa parhaiden käytäntöjen kehittämisestä. Hei, Tucker.

Tucker Sauer-Pivonka:

Hei Ben, mukava kuulla sinusta tänään.

Ben Aston:

Samoin. Haluan aloittaa kysymällä yhdestä tehtäväsi osa-alueesta. Tiedän, että osa roolistasi liittyy tiimin kehittämiseen. Voisitko jakaa näkemyksiäsi siitä, mikä on todella auttanut tiimiäsi kehittymään ja kasvamaan? Ehkä myös niistä sopimuksista, joiden parissa työskentelet tai joita kokeilette. Kuinka tuet tiimiä ja autat sitä kasvamaan? Mikä on toiminut sinulle?

Tucker Sauer-Pivonka:

Mielestäni ensimmäinen asia, joka on ymmärrettävä varhain, on se, että kaikki oppivat hieman eri tavoin ja tarvitsevat erilaista valmennusta. Siksi istun ensimmäiseksi jokaisen tiimin jäsenen kanssa ja selvitän, miten hän oppii, millaista palautetta hän haluaa saada ja miten hän haluaa vastaanottaa kiitosta. Pidän kaikesta tästä kirjaa, jotta voin mukauttaa lähestymistapaani tavalla, johon jokainen reagoi paremmin. Vietän paljon aikaa kahdenkeskisissä tapaamisissa ja käyn yksilöllisesti läpi erilaisia aiheita sekä kehittymisalueita. Valmennan heitä asioissa, joiden kanssa heillä sillä hetkellä on vaikeuksia. Ne tulevat vastaan aikanaan, ja sitten tartumme niihin. Lisäksi Cremassa on parhaillaan käynnissä kirjakerho, jossa käsittelemme Multipliers-nimistä kirjaa.

Se on tärkeä osa tiimimme kasvua. Lisäksi osallistumme tietenkin konferensseihin. Meillä on mielestäni syyskuun lopulla konferenssi, johon osallistumme. Se liittyy myös tuotehallintaan. Menemme sinne tiiminä paitsi rakentamaan tiimihenkeä myös oppimaan uusista aiheista.

Ben Aston:

Kuulostaa hyvältä. Tiedätkö konferenssin nimen?

Tucker Sauer-Pivonka:

Sen nimi on Industry: The Product Conference, ja se järjestetään Cincinnatissa, jos muistan oikein.

Ben Aston:

Juhlat Cincinnatissa, jos haluat liittyä Tuckerin ja tiimin seuraan. Haluaisin kuitenkin palata mainitsemiisi tiimin erilaisiin aiheisiin. Voisitko kertoa joistakin aiheista tai alueista, joissa autat tiimiä eteenpäin? Millaisia haasteita tiimi kohtaa, joiden voittamisessa autat?

Tucker Sauer-Pivonka:

Se näyttää jälleen hieman erilaiselta jokaisen kohdalla, koska tiimimme jäsenten taitotasot vaihtelevat. Jotkin asiat liittyvät kuitenkin usein asiakkuuksien hallintaan. Esimerkiksi: ”Asiakkaani sanoi näin” tai ”Asiakas pyytää meitä tekemään tämän, mutta emme ole oikeastaan keskustelleet siitä. Miten minun pitäisi toimia?” Puhun nyt yleisellä tasolla, koska en juuri nyt keksi täydellistä esimerkkiä. Kyse on jotakuinkin tällaisesta.

Asiakkuuksien hallintaan liittyvät asiat ovat yleensä vaikeimpia opetettavia. Siksi kyse on enemmän keskustelusta: ”Tämä tuntui minusta oudolta. En tiedä, toiminko oikein. Toiminko oikein vai pitäisikö minun toimia ensi kerralla eri tavalla?” Tällaisiin suuntiin keskustelumme yleensä etenevät.

Ben Aston:

Aivan. Asiakkuuksien ja tiimin hallintaan liittyy paljon pehmeitä taitoja, eikö vain? Yhtä ainoaa oikeaa vastausta ei yleensä ole, vaan kaikki riippuu tilanteesta. Näillä alueilla voi silti aina kasvaa ja kehittyä. Mainitsit myös konferenssiin osallistumisen tiiminä, mikä on mielestäni hienoa. Haluaisin tietää hieman enemmän siitä, mistä haet inspiraatiota ja kuinka pysyt ajan tasalla kaikesta tapahtuvasta. Kuinka seuraat alan kehitystä ja saat inspiraatiota?

Tucker Sauer-Pivonka:

Saan inspiraatiota monista eri lähteistä. Yksi niistä ovat lukemani kirjat. Luen paljon artikkeleita, ja Medium on paikka, josta haen melko usein inspiraatiota erityisesti tuotehallintaan, tiimien johtamiseen ja siihen, miltä niiden pitäisi näyttää. Minun on kuitenkin muistutettava itseäni siitä, että Medium on hyvä resurssi, mutta asioihin pitää suhtautua varauksella, koska kuka tahansa voi julkaista siellä artikkelin. Se, että joku voi julkaista jotain internetissä, ei tee hänestä asiantuntijaa. Jos kuitenkin suhtaudut asiaan näin, se voi ainakin antaa kontekstia tiettyjen tilanteiden käsittelyyn.

Käytän sitä melko paljon. Nämä ovat oikeastaan kaksi tärkeintä lähdettäni. Lisäksi seuraan koko toimialaan liittyviä asioita. Pidän Wired-lehdestä ja luen yleensä jokaisen numeron useimmat artikkelit. Se auttaa minua pysymään ajan tasalla erilaisista trendeistä, joita tapahtuu projektinhallinnan ulkopuolella, erityisesti teknologiassa yleisesti.

Ben Aston:

Hienoa. Teknologiasta puheen ollen: oletko sellainen ihminen, joka pysyttelee teknologian eturintamassa? Mikä on uusin hankkimasi laite?

Tucker Sauer-Pivonka:

Hyvä kysymys. Toivoisin, että minulla olisi jotain todella jännittävää kerrottavaa. En kuitenkaan sanoisi olevani teknologian eturintamassa. Pidän itseäni aikaisena omaksujana, mutta en sitä aikaisempana. Yritän yleensä hankkia uusia tuotteita niiden ilmestyessä, jos mahdollista. Kuolaan parhaillaan uuden iPadin perään. Minulla on iPad Pro, joka on hyvä, mutta haluaisin uuden version enkä pysty perustelemaan sen hankintaa. Työni kannalta se toimii edelleen hyvin, ja se onkin Applen tuotteiden hieno puoli: niitä ei oikeastaan tarvitse vaihtaa.

Olen kuitenkin viime aikoina käyttänyt uusinta iOS- ja iPadOS-versiota sekä kaikkea WWDC:ssä julkaistua. Ne olivat minusta erittäin kiinnostavia. Olen pohtinut paljon niiden vaikutuksia koko toimialaan ja ehkä myös joihinkin kehittämiini tuotteisiin. Se on viime aikoina ollut suurin kiinnostuksenkohteeni. Lisäksi olen hieman Zelda-fani, ja uusimman Breath of the Wild -jatko-osan julkistaminen sai minut innostumaan siitäkin.

Ben Aston:

Hienoa. Minä olen tällä hetkellä kiinnostunut DJI Roverista. En tiedä, kutsutaanko sitä Roveriksi tai joksikin muuksi, mutta kyseessä on pieni kamera pienellä tankilla, jonka rakentaa itse. Se näyttää mahtavalta ja on seuraavana ostoslistallani.

Tucker Sauer-Pivonka:

Kuulostaa hauskalta.

Ben Aston:

Niinpä. Jälleen yksi niistä asioista, joiden kohdalla miettii: ”Tarvitsenko tätä oikeasti?” En oikeastaan tarvitse, mutta se olisi hyvä lapsille ja he nauttisivat siitä. Olen kuitenkin utelias iPad Pro -laitteesi suhteen. Onko laitteistossa tai ohjelmistossa jotain muuta, jonka olet hiljattain havainnut tekevän elämästäsi hienompaa ja josta kaikkien pitäisi tietää?

Tucker Sauer-Pivonka:

Olen vuosien mittaan yrittänyt löytää tasapainon käsin kirjoitettujen muistiinpanojen, kirjoitettujen muistiinpanojen ja tehtävien seurannan välillä. Tietoa on paljon siitä, että kun kirjoittaa jotain muistiin, sen ymmärtää hieman eri tavalla kuin kirjoittaessa sen näppäimistöllä. Se kiinnostaa minua. Olen siis aina yrittänyt löytää sopivaa tasapainoa. Jonkin aikaa tein muistiinpanoja iPadillani Apple Pencilillä, ja se toimi melko hyvin. Viime aikoina olen kuitenkin siirtynyt jonkinlaiseen välimuotoon.

Pidän iPadia tai tietokonetta lopullisena työasioiden säilytyspaikkana, mutta viime aikoina olen kantanut mukanani myös pientä muistikirjaa. Teen siihen päivittäiset muistiinpanoni, kirjaan tehtäviä niiden tullessa mieleen ja teen kaiken muun fyysisessä muistikirjassa. Päivän päätteeksi siirrän asiat Todoist-nimiseen sovellukseen, jossa seuraan tehtäviäni. Lisäksi siirrän muistiinpanoni sinne ja käsittelen ne päivän lopussa.

Olen vasta vähitellen ottamassa tämän käytännön käyttöön, mutta se on ollut suurin muutos työnkulussani pitkään aikaan ja todella hyödyllinen. Huomaan ymmärtäväni tekemiseni hieman paremmin. Lisäksi tehtävieni seuraaminen on helpompaa, enkä ryhdy niihin heti. Siksi se on ollut hyödyllistä myös ajanhallinnan näkökulmasta.

Ben Aston:

Mielenkiintoista. Käytät siis fyysistä muistikirjaa muistiinpanoihin ja olet palannut tässä suhteessa analogiseen työskentelyyn. Näinkö se toimii?

Tucker Sauer-Pivonka:

Kyllä, mutta lopulta asiat siirtyvät digitaaliseen paikkaan. Mikään ei nimittäin korvaa sitä, että avaa muistikirjan, napsauttaa kynän auki ja alkaa kirjoittaa. Suurin vaikeuteni iPadilla ja Apple Pencilillä muistiinpanoja tehdessä oli se, että oikean sovelluksen avaaminen, oikean muistikirjan etsiminen ja Apple Pencilin latauksen tarkistaminen vievät aikaa. Ne vaikuttavat pieniltä asioilta, mutta muodostavat esteitä muistiinpanon kirjoittamiselle.

Huomasin kantavani iPadia ja valtavaa määrää muistilappuja. Jos piti aloittaa jokin asia, kirjoitin sen muistilapulle. Ajattelin, ettei se ole kestävää eikä ole järkevää kantaa kaikkia niitä lappuja mukana. Siksi siirryin muistikirjaan.

Ben Aston:

Mielenkiintoista. Painin saman ongelman kanssa. Viimeisin lähestymistapani on Evernoten käyttäminen. Minulla on yksi muistikirja tehtävälistaa varten ja toinen, jota kutsun luonnoslehtiöksi. Se toimii kaikenlaisten muistiinpanojen kaatopaikkana. Jos yritän järjestellä tehtävälistani liian tarkasti ja pitää sen siistinä, sotken sen aina.

Nyt käytän luonnoslehtiötä, johon kaikki raaka materiaali menee, ja siirrän asiat myöhemmin tehtävälistalle. Se kuulostaa melko samanlaiselta järjestelmältä kuin sinun. Lisäksi minulla on pieni lehtiö, joka on tarkoituksella niin pieni, etten voi kirjoittaa siihen varsinaisia muistiinpanoja. Voin kirjoittaa siihen muistutuksia, mutta se on liian pieni muistiinpanoihin. Näin järjestelmä pakottaa minut käyttämään sitä. Muuten alkaisin luoda erilaisia listoja eri paikkoihin ja lopputulos olisi suuri sekasotku.

Mutta puhutaan artikkelista. Kirjoitit meille mielenkiintoisen tapaustutkimuksen siirtymisestä vesiputoustyylisistä sopimuksista kesto- ja hintasopimuksiin. Olemme aiemmin puhuneet ketteristä sopimuksista, ja tällä viikolla joku kysyi DPM-koulussa: ”Anna esimerkki ketterästä sopimuksesta.” Lähetin hänelle linkin. Alexa kirjoitti aiemmin hienon artikkelin ketteristä sopimuksista. Jos ketterät sopimukset eivät ole kuulijalle tuttuja, voisitko lyhyesti selittää, mikä kesto- ja hintasopimus on ja miten se toimii?

Tucker Sauer-Pivonka:

Voin selittää, miten se toimii Creman näkökulmasta. Se ei tarkoita, että kaikkien pitäisi käyttää täsmälleen samaa kaavaa, mutta tämä on malli, jonka tunnen parhaiten. Kesto- ja hintasopimuksessa projekti rakennetaan omistautuneen tiimin ympärille. Tiimiin voi kuulua esimerkiksi kaksi kokoaikaista kehittäjää, puolipäiväinen testausinsinööri, neljännes- tai puolipäiväinen suunnittelija sekä tuotehallinnan ammattilainen ja mahdollisesti strategisti, molemmat neljännes- tai puolipäiväisesti.

Huomio keskittyy siis enemmän itse tiimiin ja tavoitteisiin, joita kohti pyritään, kuin esimerkiksi tarkkaan luetteloon toimitettavista ominaisuuksista ja niiden viereen merkittyihin täsmällisiin tuntiarvioihin. Olemme havainneet, että ohjelmisto on liian monimutkainen kokonaisuus, jotta sen kaiken voisi arvioida etukäteen ja olettaa kaiken etenevän suunnitelman mukaan. Olisi hienoa, jos voisimme vain suunnitella kaiken ja kaikki tapahtuisi juuri niin kuin tarkoitimme. Rehellisesti sanottuna niin ei kuitenkaan koskaan käy.

Siksi nämä sopimukset mahdollistavat meille ja asiakkaillemme siirtymisen aina siihen työhön, jolla on korkein prioriteetti. Näin toimitamme keston päättyessä ja myös iteratiivisten syklien aikana liiketoiminnalle kulloinkin suurimman arvon tuottavaa työtä. Kiinteähintaisessa sopimuksessa prioriteetit voivat muuttua ajan myötä. Kuvitellaan esimerkiksi kuuden kuukauden sopimus, jonka lopussa toimitetaan ominaisuuksia, jotka eivät enää ole liiketoiminnalle relevantteja. Kesto- ja hintamalli antaa meille mahdollisuuden muuttaa suuntaa asiakkaan tarpeiden mukaan.

Ben Aston:

Hyvä. Olet puhunut ketterille sopimuksille sopivista projekteista ja ohjelmistokehityksestä. Tuotekehitys on hyvä esimerkki, koska projektin aikana pitää voida muuttaa suuntaa. Oletko kohdannut projekteja, joissa olet yrittänyt käyttää tällaista sopimusta, mutta ketterä kesto- ja hintasopimus ei ole toiminut yhtä hyvin?

Tucker Sauer-Pivonka:

On muutamia tilanteita, ehkä enemmän muiden kuin meidän kohdallamme. Työn tyyppi täytyy arvioida. Kuten sanoit, tämä toimii meillä, koska kehitämme tuotteita, joiden jokaista yksityiskohtaa on vaikea määritellä etukäteen ja joihin liittyy jonkin verran laskennallista riskiä. Jos kyseessä on toistettava työ, esimerkiksi tietynlaiset vakiomuotoiset verkkosivustot, voidaan riski laskea ja käyttää kiinteähintaisempaa mallia. Me emme tee sellaista työtä, mutta siinä kiinteähintainen sopimus voisi toimia paremmin. Kyse on ennustettavuudesta ja ennakoimattomuudesta.

Ben Aston:

Toinen esiin nouseva keskustelu liittyy arvoperusteiseen hinnoitteluun. Se eroaa selvästi arvoperusteisesta hinnoittelusta. Kun kyseessä on ennakoitavampi projekti, voidaan sanoa asiakkaalle: ”Tämän työn arvo liiketoiminnallesi on 50 000.” Sitten veloitetaan 50 000, vaikka työn tuottamiseen kuluisi vähemmän. Myydään siis arvoa tuntien sijaan.

Miten tällainen arvoperusteinen hinnoittelu sopii yhteen suoraviivaisten ja rehellisten kesto- ja hintasopimusten kanssa, joissa asiakas maksaa käytettävissä olevasta työajasta? Miten se vaikuttaa kannattavuuteen? Ovatko asiat yksinkertaisempia ja kannattavampia, koska tuntien hinnassa on sisäänrakennettu kate? Vai oletteko joutuneet tilanteisiin, joissa olette joutuneet kantamaan kustannukset itse?

Tucker Sauer-Pivonka:

Mielestäni kyse on lähtökohtaisesti kahdesta eri asiasta. Kun rakennamme ohjelmistoa kesto- ja hintamallilla, emme välttämättä tiedä, millainen lopputulos tulee olemaan. Siksi lopullista hintaa on vaikea määrittää alussa. Lopputulos voi muuttua, koska asiakas voi muuttaa mieltään. Arvoperusteinen hinnoittelu toimii hyvin tilanteissa, joissa voidaan sanoa: ”Toimitamme tämän asian, joka tuottaa liiketoiminnallesi tämän arvon.” Se voi olla esimerkiksi suunnittelusprintti. Suuren tuotteen rakentamisessa sitä on vaikeampi soveltaa.

Kannattavuuden kannalta kesto- ja hintamallin hienous on siinä, että kaikki on sisäänrakennettu toteutustapaan. Asiakas saa tietyn tiimin tietyn ajanjakson ajaksi. Tiimin kapasiteetti on se, mitä hän saa. Jos projektissa on esimerkiksi kaksi kokoaikaista kehittäjää, kyse ei ole siitä, että ylitetään tietty tuntimäärä. Asiakas saa tiimin kapasiteetin, joka tuottaa arvoa sprintti toisensa jälkeen. Siksi ei tarvitse huolehtia samalla tavalla kannattavuudesta tai ali- ja ylityksistä. Hinnoittelu ei perustu tunti tunnilta laskemiseen.

Ben Aston:

Asiakas siis ostaa tiimin tietyksi ajaksi. Oletko koskaan kohdannut tilannetta, jossa asiakas muutaman sprintin jälkeen sanoo: ”Olette työskennelleet tämän parissa kolme sprinttiä, enkä usko saaneeni siitä arvoa”? Kaikki tekevät virheitä, eikä kehitystyö aina etene suunnitelmien mukaan. Miten toimit tällaisessa tilanteessa?

Tucker Sauer-Pivonka:

Sitä tapahtuu melko harvoin, koska työskentelemme ahkerasti varmistaaksemme yhteisymmärryksen asiakkaidemme kanssa. Emme tee tätä vain sprinttien aloituksissa, vaan koko sprinttien ajan ja pidämme asiakkaat ajan tasalla muutoksista. Paras tapa hallita tällaista tilannetta on hyvä viestintä ja asiakkuuksien hallinta.

Kuten aiemmin sanoin, tästä puhutaan tuotehallintatiimissämme paljon. On tärkeää pystyä sanomaan nöyrästi: ”Ajattelimme tämän kestävän kaksi sprinttiä, mutta näyttää siltä, että siihen kuluu kolme tai neljä, koska havaitsimme tämän asian. Tässä on, mitä löysimme ja miksi arvioimme työn kestävän näin pitkään. Voimme myös keskeyttää tämän ja siirtyä johonkin muuhun, jos haluat.” Kun kaikki tosiasiat tuodaan näkyviin, päätöksistä tulee helpompia ja niiden tunnepuoli vähenee.

Lisäksi kohdistamme jokaisen sprintin sisällön yhdessä asiakkaan kanssa ennen sen alkamista. Varmistamme, että tiimi kokee pystyvänsä toimittamaan sovitut asiat. Sprintin lopussa esittelemme saavutetun tuloksen. Jos jotain siirtyy eteenpäin tai löydämme jotain uutta, keskustelemme siitä ja varmistamme, että asiakas ymmärtää tilanteen. Näin hän ei myöhemmin ihmettele, miksi lopputulos ei vastannut odotuksia.

Ben Aston:

Haluan palata hieman tapaustutkimukseen ja aikatauluun. Kerroit, että tiesitte työtä olevan ainakin seitsemän kuukauden ajan. Kuinka päädyitte tähän arvioon, jos ette olleet täysin varmoja siitä, mitä rakennatte? Seitsemän kuukauden aikataulu ei ole pieni projekti tai tuotekehityshanke. Teittekö arvion ennen prototyyppivaihetta vai sen jälkeen?

Tucker Sauer-Pivonka:

Tässä tapauksessa, kuten useimmissa projekteissamme, arvio tehtiin jonkinlaisen prototyyppi- tai testaustoimeksiannon jälkeen. Kyseessä oli yleensä lyhyempi, kuuden viikon toimeksianto, johon tässä tapauksessa sisältyi myös asiakkaan nykyisen järjestelmän tekninen auditointi. Se auttoi meitä arvioimaan, kuinka paljon aikaa tarvittaisiin heidän tavoitteidensa saavuttamiseen. Arviointiin liittyy kokemusta: mitä useampia projekteja teet, sitä paremmin opit hahmottamaan, kuinka kauan tietynlainen työ kestää ja kuinka monimutkaista se on.

Tuotantotiimin näkökulma on tässä tärkeä. Prototyyppi- ja testaustoimeksiannon jälkeen tuotantotiimi kokoontui ja totesi, ettei kaikkia yksittäisiä käyttäjätarinoita kannata määritellä etukäteen, koska asiat muuttuvat. Sen sijaan tarkastelimme tavoitteita ja kokonaisuuden eri osia, arvioimme niiden monimutkaisuutta ja annoimme niille suuntaa-antavat T-paitakoot. Näiden perusteella muodostimme suosituksen tiimin koosta: kuinka monta kehittäjää tarvitaan, kuinka paljon testausinsinöörin kapasiteettia tarvitaan ja niin edelleen.

Kesto ei perustu yksittäisiin toimitettaviin asioihin, koska sopimus ei keskity toimituksiin. Se keskittyy liiketoimintatavoitteisiin. Tiesimme, että työtä olisi seitsemäksi kuukaudeksi, mutta uskoimme tiimin pystyvän pysymään keskittyneenä ja saavuttamaan tavoitteet tuona aikana. Arvioon vaikuttivat myös asiakkaan budjetti ja halu jatkaa. Ohjelmisto ei nimittäin koskaan ole täysin valmis. Aina tulee uusia asioita.

Seitsemän kuukautta oli vähimmäisaika, joka tarvittaisiin asiakkaan tavoitteiden saavuttamiseen. Saattoi olla, että sen jälkeen tarvittaisiin lisää aikaa. Saavuttaaksemme sen, mitä asiakas pyysi, keskityimme liiketoimintatavoitteisiin, asiakkaan budjettiin ja ajatukseen, että ohjelmistoa kehitetään jatkuvasti. Uskomme pystyvämme toimittamaan nämä asiat tässä aikataulussa, ja työskentelemme jokaisessa sprintissä yhdessä asiakkaan kanssa varmistaaksemme, että keskitymme tärkeimpään.

Ben Aston:

Osa arvioinnista liittyi varmasti siihen, pystyikö asiakas maksamaan vain seitsemästä kuukaudesta vai oliko hänellä mahdollisuus jatkaa sen jälkeen. Ohjelmistoprojekti ylittää todennäköisesti seitsemän kuukautta, joten asiakkaan budjetti ja halu jatkaa ovat tärkeitä.

Tucker Sauer-Pivonka:

Jos asiakas haluaa vain kolmen kuukauden sopimuksen, sekin käy. Varmistamme silloin, että työskentelemme kolmen kuukauden ajan tärkeimpien asioiden parissa. Kolmen kuukauden lopussa tärkeimmät asiat ovat edenneet mahdollisimman pitkälle.

Ajattele asiaa niin, että asiakas vuokraa tiimin. Hän saa sen, mitä tiimi pystyy tuottamaan kolmessa kuukaudessa, kuudessa kuukaudessa, vuodessa tai kahdessa vuodessa. Aikataulu mukautetaan asiakkaan tarpeeseen, ja keskitymme jatkuvasti tärkeimpiin asioihin.

Ben Aston:

Mainitsit, että ensin tehdään prototyyppi- ja validointitoimeksianto. Oliko se kiinteähintainen? Mainitsit kuusi viikkoa. Perustuiko se kolmeen kahden viikon sprinttiin? Kuinka tarkasti toimitukset määriteltiin kuuden viikon lopussa?

Tucker Sauer-Pivonka:

Teknisesti se kuuluu edelleen kesto- ja hintamalliin, mutta se on hieman kiinteähintaisempi kuin tavallinen sopimuksemme. Toimeksiantoon liittyy tiettyjä toimituksia. Voimme luvata korkealaatuisen prototyypin, luonnostiedostot, käyttäjähaastattelut, muistiinpanot ja niihin liittyvän tutkimuksen.

Toimitamme siis tiettyjä asioita, joiden tiedämme kuuluvan toimeksiantoon. Teknisesi se perustuu kuitenkin edelleen kestoon. Jos esimerkiksi kolmen viikon jälkeen huomataan, etteivät käyttäjät halua sitä, mistä puhumme, voimme palata lähtöruutuun. Tarkoituksena ei ole toimittaa täsmälleen tiettyä määrää näyttöjä, vaan työ perustuu edelleen kestoon ja hintaan.

Ben Aston:

Tuo on hyvä asia, koska prototyyppivaiheessa asiat voivat usein mennä pieleen. Asiakas saattaa sanoa: ”En usko tämän olevan aivan oikein.” Tämä voi tapahtua jo ennen käyttäjätestausta, kun hän haluaa säätää ja muuttaa asioita. Jos kyseessä on kesto- ja hintamalli, tällaiset muutokset on helpompi ottaa huomioon.

Kun kuusi viikkoa on kulunut, tuotatte prototyypin ja teette käyttäjätestausta. Sitten arvioitte työn kestävän noin seitsemän kuukautta. Teittekö puhtaasti alhaalta ylös tai ylhäältä alas etenevän arvion tuosta puolen miljoonan ja miljoonan välisestä luvusta? Kysyittekö asiakkaalta, kuinka paljon budjettia hänellä on, ja laskitte siitä taaksepäin? Vai miten arvioitte asiakkaan halun investoida tuotekehitykseen?

Tucker Sauer-Pivonka:

Tässä tapauksessa määrittelimme ensin suuntaa-antavat T-paitakoot ja työn monimutkaisuuden sekä teknisen suunnitelman. Niiden avulla pystyimme rakentamaan alustavan etenemissuunnitelman. Kerroimme selvästi, että etenemissuunnitelma voisi muuttua ajan myötä, mutta sen avulla pääsimme alkuperäiseen seitsemän kuukauden arvioon.

Emme välttämättä tienneet asiakkaan budjettia, kun esittelimme ehdotuksen. Kuvasimme, mitä olimme tehneet, minne olimme menossa ja miltä mahdollinen etenemissuunnitelma näyttäisi. Kerroimme myös, mitä eri vaiheisiin todennäköisesti sisältyisi ja mikä olisi tärkeintä, vaikka prioriteetit voisivatkin muuttua.

Teknisen tiimin, minun ja strategistin mukanaolo auttoi määrittelemään, miltä seitsemän kuukautta näyttäisivät. Pystyimme sanomaan esimerkiksi, että tietyn sovelluksen osan rakentamiseen kuluisi noin puolitoista kuukautta. Kokosimme nämä arviot etenemissuunnitelmaksi, ja näin päädyimme seitsemään kuukauteen.

Ben Aston:

Hyvä.

Tucker Sauer-Pivonka:

Ehdotusvaiheessa varmistimme, että asiakas tiesi voivansa muuttaa suunnitelmaa. Jos seitsemän kuukauden malli ei toimisi, voisimme palata lähtöruutuun ja keskustella siitä, mitä kolmen kuukauden aikana pitäisi tehdä. Olimme asiakkaan kanssa jo riittävän lähellä toisiamme ja tiesimme, mitä hän halusi vähimmäisversion sisältävän. Siksi pystyimme rakentamaan siihen sopivan etenemissuunnitelman.

Ben Aston:

Haluaisin puhua seuraavaksi menetelmästä. Kuvailit tapaustutkimuksessa lähestymistapaa ketteräksi ja Scrum-henkiseksi. Mitä otatte mukaan Scrumin ohjekirjasta ja mitä jätätte pois? Miten toimintanne eroaa oppikirjamaisesta Scrumista? Olen erityisen kiinnostunut tuoteomistajan roolista ja siitä, onko tuoteomistaja asiakas vai tiiminne jäsen. Onko teillä Scrum Mastereita? Mainitsit tuotestrategistin, mutta et tuoteomistajaa tai Scrum Masteria.

Tucker Sauer-Pivonka:

Meillä sanotaan usein, että ihmiset ovat prosessia tärkeämpiä. Harjoitamme pienellä s-kirjaimella kirjoitettua scrumia. Tällä tarkoitan sitä, että prosessissa on riittävästi joustavuutta, jotta se ei rajoita ihmisiä. Jos tiimin täytyy muuttaa prosessia voidakseen työskennellä paremmin asiakkaan kanssa, sillä on täysi autonomia tehdä niin.

Toimistomallissa on vaikeampaa järjestää jokaiseen tehtävään oma roolinsa. Ohjelmistoyrityksessä tilanne voi olla erilainen, koska rahoitus ja liiketoimintamalli ovat erilaisia. Toimistossa se ei aina toimi niin. Tuoteomistajan rooli kuuluu yleensä asiakkaan päivittäiselle yhteyshenkilölle.

Jos projektissa on strategisti, hän voi toimia eräänlaisena tuoteomistajan työparina ja valmentaa tätä henkilöä. Jotkut asiakkaat eivät tiedä, mitä ohjelmiston omistaminen tai ohjelmiston rakentaminen tarkoittaa. Strategisti auttaa heitä tekemään päätöksiä tuotteen strategiasta ja suunnasta sekä täyttämään tuoteomistajan tehtäviä.

Joskus tämä tehtävä kuuluu tuotehallinnan ammattilaisille. Joissakin tilanteissa asiakkaan tuoteomistaja ei voi olla kanssamme päivittäin yhteydessä, jolloin tuotehallinnan ammattilainen hoitaa osan tuoteomistajan vastuista ja raportoi niistä asiakkaalle.

Tuotehallinnan puolella yhdistämme tuotehallinnan ammattilaisen ja Scrum Masterin yhdeksi rooliksi. Se on hyvin kaukana perinteisestä oppikirjan mukaisesta Scrumista, mutta se toimii meille. Jos se joskus lakkaa toimimasta, muutamme käytäntöä. Tällä hetkellä toimimme näin, järjestämme kaikki seremoniat ja poistamme esteitä.

Automatisoimme useimmat päivittäiset tilannekatsaukset, mutta määritämme ne, tarkistamme ne päivittäin ja huolehdimme esteiden poistamisesta. Nämä asiat kuuluvat vastuullemme. On myös hyödyllistä, että meillä on kaikki tarvittava konteksti tuotehallintaan liittyvien päätösten tekemiseen.

Poikkeamme siis eniten näissä kahdessa kohdassa. Muilta osin käytäntömme on hyvin samanlainen kuin Scrumissa. Järjestämme sprinttien suunnittelun, arvioinnit, retrospektiivit ja tuote-esittelyt. Yhdistämme ne yleensä keskiviikkoisin järjestettävään aloituskokoukseen.

Ben Aston:

Olet puhunut tilanteista, joissa asiakas on tuoteomistaja, ja tilanteista, joissa tehtävää hoitaa tiimisi tuotehallinnan ammattilainen. Haluaisin puhua muutosten hallinnasta. Tapaustutkimuksessa kerroit ristiriitaisista prioriteeteista: uuden asian rakentamisesta ja vanhan, toiminnan kannalta välttämättömän asian korjaamisesta. Maksujen käsittely lakkasi toimimasta tai oli vaarassa lakata toimimasta.

Asiakas haluaa usein molemmat: uuden rakentamisen ja vanhan korjaamisen. Laajuus kasvaa. Miten hallitsette näitä prioriteettiristiriitoja ja autatte asiakasta ymmärtämään niitä? Scrumissa on työjono, jonka priorisoinnista tuoteomistaja vastaa. Miten toimitte, kun yhdestä projektista tulee käytännössä kaksi? Miten viestittelette asiakkaalle tilanteesta ja työjonon hallinnasta?

Tucker Sauer-Pivonka:

Ensimmäinen asia, joka täytyy ymmärtää, on se, että prioriteettien muuttuessa on oltava empaattinen sitä kohtaan, mikä muutoksia aiheuttaa. Useimmiten asiakas ei edes halua muuttaa prioriteetteja. Hän haluaa meidän keskittyvän alkuperäiseen tavoitteeseen. Muutoksia ei kuitenkaan pyydettäisi, elleivät ne olisi todella tarpeellisia.

Ensimmäiseksi on ymmärrettävä muutoksen syy. Onko asia todella tärkeä? Onko kyse tilanteesta, jossa joku vain vaatii kovaan ääneen huomiota? Onko sidosryhmä pyytänyt asiaa ja yritetäänkö sidosryhmä miellyttää? Kaikki nämä ovat perusteltuja syitä. Kun ymmärtää lähtökohdan, tietää paremmin, miten asiasta kannattaa viestiä.

Toiseksi on varmistettava, että viestintä on erittäin selkeää. Prioriteettien muuttaminen muuttaa koko suunnitelmaa. Jos tiimi on esimerkiksi rakentamassa suurta uutta ominaisuutta ja on työn puolivälissä, mutta asiakkaalle tulee kiireellinen uusi ominaisuus, tiimin on ymmärrettävä syy. Asiakkaan uusi sopimus voi olla arvokas ja uusi ominaisuus välttämätön.

Kun ymmärrän tilanteen, kerron siitä tiimille. Kun ihmiset ymmärtävät, miksi muutos tehdään, tunteet ja turhautuminen vähenevät. Sen jälkeen varmistan jokaisessa tarkistuspisteessä, että asiakas ymmärtää tiimin siirtyvän pois alkuperäisestä työstä. Tämä tarkoittaa, ettei alkuperäinen työ valmistu silloin, kun alun perin ajateltiin. Se on täysin hyväksyttävää, mutta suunnitelma muuttuu hieman. Varmistan, että päätös on kaikille täysin selvä.

Tapaustutkimuksessa emme tienneet tarkasti, milloin työ päättyisi. Siksi meidän täytyi viestiä asiakkaalle jatkuvasti: ”Tämä on mahdollista, mutta huomioithan, että se vie meitä kauemmas alkuperäisestä liiketoimintatavoitteesta.” Se sopi meille, kunhan asiakas ymmärsi seuraukset. Muuten kyse voi olla kalliista virheestä.

Työkalujen osalta kaikki visuaaliset esitykset ovat hyödyllisiä. Myös työkalut, kuten Jira, auttavat näyttämään tilanteen. Joskus sanomme asioita, mutta asiakas ei ymmärrä niitä samalla tavalla ennen kuin näkee ne visuaalisesti.

Ben Aston:

Pääsevätkö asiakkaat siis Jiraanne? Käyttävätkö he sitä?

Tucker Sauer-Pivonka:

Toimintatapamme perustuu täydelliseen läpinäkyvyyteen. Asiakkailla on pääsy työkaluihin, joissa työskentelemme, ja heidät lisätään vierailijoiksi Slack-tiimiimme. He käyttävät myös Jiraa tarkistaakseen prioriteetit, vaatimukset ja suunnan. Näin he pysyvät mukana siinä, mitä teemme.

Ben Aston:

Puhuit tapaustutkimuksessa luottamuksen rakentamisesta. Läpinäkyvyys auttaa tietenkin. Mainitsit myös opituissa asioissa toimitettavien aineistojen tärkeyden, etenemissuunnitelman päivittämisen ja palamiskaavion päivittämisen. Miten estätte asiakasta kuormittumasta, kun viestittävää on niin paljon? Jos asiakas ei ole tekninen ja hänelle näytetään Jira, työjono ja käynnissä oleva työ, miten ylläpidätte luottamusta ja varmistatte, ettei tärkeä asia jää piiloon jonnekin tehtävän kommenttiin?

Tucker Sauer-Pivonka:

Osa vastausta on virheiden myöntäminen ja nöyryys. Jos kerrot asiakkaalle usein avoimesti tekemistäsi virheistä, se voi rakentaa luottamusta nopeasti. Asiakas ymmärtää, ettemme yritä huijata häntä, vaan kerromme virheestä ja sen korjaamisesta. Näin hän näkee, että olemme tosissamme, ja että hänen menestyksensä on myös meidän menestyksemme.

Emme edellytä asiakkaan käyttävän työkaluja. Varmistamme vain, että hänellä on pääsy niihin, jos hän haluaa. Teemme myös henkilökohtaisia ruudunkaappausvideoita, joissa näytämme työkalun käytön, tietojen löytämisen ja asiat, joista ei tarvitse huolehtia. Jos asiakas kokee tilanteen kuormittavaksi, hän voi kertoa siitä meille, jotta voimme korjata tilanteen nopeasti.

Olemme kohdanneet tätä vain muutaman kerran. Useimmiten kuormitus liittyy suunnitelmien tarkistamiseen. Suuressa tuotteessa voi olla 500 näyttöä, jolloin asiakas saattaa yhtäkkiä ajatella, että tarkistettavaa on liikaa.

Siksi asiakkaalle kannattaa antaa pääsy työkaluun ja toimittaa aineistoa pienissä, iteratiivisissa erissä. Kaikkea ei pidä jättää hänen syliinsä kerralla. Tämä ei aina onnistu, koska aineistoa voi kertyä, mutta avoin viestintä auttaa paljon.

Ben Aston:

Haluan kysyä raportoinnista. Asiakas maksaa tiimistä tietyn ajan. Raportoitteko käytetystä ajasta ja toimitatteko tuntikirjauksia, vai sanotteko vain, että hän ostaa tiimin ja luottaa siihen, että työ on tehty?

Tucker Sauer-Pivonka:

Raportointi keskittyy tuloksiin. Seuraamme sprinttikohtaisia mittareita. Sprintin lopussa käymme läpi, mitä saatiin valmiiksi, mitä jäi kesken ja millainen nopeutemme oli. Jos nopeus nousi tai laski, keskustelemme syistä.

Emme raportoi tunteja, koska asiakas ei osta yksittäisiä tunteja tai tiettyyn ominaisuuteen kuluvaa tarkkaa tuntimäärää. Käytämme raportointia varmistaaksemme, että tiimin kapasiteetti on oikein mitoitettu. Jos joku työskentelee projektissa puolipäiväisesti mutta käyttää siihen enemmän aikaa, keskustelemme asiakkaan kanssa tehtävien vähentämisestä tai kapasiteetin lisäämisestä.

Viikoittaisia vaihteluita voi esiintyä. Saatan esimerkiksi työskennellä yhden viikon puolipäiväisesti, vaikka kapasiteettini olisi neljännespäiväinen, ja seuraavalla viikolla tilanne tasoittuu. Seuraamme tällaisia vaihteluita varmistaaksemme mitoituksen, mutta emme raportoi niitä asiakkaalle. Raportoimme valmistuneesta ja valmistumattomasta työstä.

Ben Aston:

Haluan lopuksi kysyä, milloin ja miten kesto- ja hintasopimukset eivät toimi. Onko kaikki koskaan romahtanut täysin? Jos joku harkitsee tämän mallin käyttöönottoa, mitä hänen pitäisi tarkkailla?

Tucker Sauer-Pivonka:

Asiat voivat mennä pieleen, etenkin jos asiakas on tyytymätön edistymiseen. Kun tällaisesta alkaa näkyä merkkejä, niihin pitää tarttua. Jos viestittelet säännöllisesti, tunnet yleensä, että jokin on hieman oudosti tai että jotain jätetään sanomatta. Silloin kannattaa sanoa suoraan: ”Minusta tuntuu, ettemme ole jostain asiasta samalla sivulla. Voimmeko keskustella siitä?” On tärkeää selvittää, mikä aiheuttaa huolen, ja tehdä se varhain. Jos odotat loppuun asti, sopimus ei todennäköisesti jatku eikä luottamusta ehditä palauttaa.

En muista tilannetta, jossa kaikki olisi täysin romahtanut. Eräässä tapauksessa olimme uusimassa sopimusta ja asiakas oli tyytymätön edistymiseen. Keskustelimme asiasta empaattisesti. Selvisi, että olimme prioriteettien muutoksen vuoksi käyttäneet kaksi kuukautta toiseen työhön, jota asiakas liiketoimintansa kannalta tarvitsi. Se siirsi alkuperäisen tavoitteen valmistumista noin kahdella kuukaudella.

Kun selitin tämän, asiakas ymmärsi tilanteen. Aiemmissa keskusteluissa olimme puhuneet prioriteettimuutosten vaikutuksista, joten hän ymmärsi toimintatapamme paremmin. Jokainen tällainen keskustelu rakentaa luottamusta. Asiakas tietää, että tavoitteita voidaan muuttaa, mutta hän on itse kuljettajan paikalla ja voi kertoa, mihin suuntaan meidän pitäisi edetä.

En ole nähnyt tilannetta, jossa kaikki olisi täysin hajonnut. Useimmiten kyse on yhteisen suunnan puutteesta. Jos asiakas ei halua löytää yhteistä suuntaa, meidän on ehkä todettava, ettemme ole toisillemme sopiva kumppani. Se on hyväksyttävää, ja voimme auttaa asiakasta löytämään uuden kumppanin. Pyrimme tunnistamaan tällaiset tilanteet jo myyntiprosessin alussa.

Ben Aston:

Minulle yksi suurimmista opeista tarinasi perusteella on se, että tämän mallin toimiminen edellyttää oikeanlaista asiakasta. Asiakkaalta vaaditaan tiettyä kypsyyttä, jotta hän ymmärtää työn vievän aikaa, prioriteettien muutosten vaikuttavan aikatauluun ja tämän vaikuttavan myös kustannuksiin.

Nämä asiat voivat olla vaikeita, koska asiakkaalla on tarkka budjetti ja määräaika. Kun kilpaillaan toisesta toimistosta tai tiimistä, kaikki haluavat tarjota parhaan mahdollisen kokonaisuuden. Se ei kuitenkaan aina luo oikeita edellytyksiä asiakkaan odotusten hallintaan tai sen kertomiseen, mitä tietyllä hinnalla ja tietyssä ajassa voidaan realistisesti toimittaa.

Suuri osa tästä liittyy uuden liiketoiminnan prosessiin ja asiakkaan kouluttamiseen. Asiakkaan odotuksia hallitaan prototyyppi- ja validointivaiheessa ja kerrotaan, miltä toimeksianto voisi näyttää. Sen jälkeen arvoa toimitetaan jatkuvasti asiakkaan prioriteettien mukaan. Lopputulos on asiakkaalle parempi, koska toimisto ei joudu oikaisemaan tai tekemään priorisointipäätöksiä vain pysyäkseen budjetissa tai aikataulussa.

Kesto- ja hintasopimukset ovat ehdottomasti mielenkiintoinen aihe. Kiitos paljon, Tucker, että liityit seuraamme.

Tucker Sauer-Pivonka:

Tämä oli hieno keskustelu. Kiitos kutsusta.

Ben Aston:

Mitä mieltä sinä olet? Oletko kokeillut ketterää sopimusta? Haluaisin tietää, miten se sujui. Kerro mielipiteesi tämän julkaisun kommenteissa ja siirry osoitteeseen TheDigitalProjectManager.com liittyäksesi Slack-tiimiimme. Siellä käydään kaikenlaisia kiinnostavia keskusteluja projektien toimittamisesta. Meillä on myös ketteryyteen keskittyvä kanava, jossa tästä olisi hienoa keskustella.

Jos pidit kuulemastasi, tilaa podcast ja käytä pari minuuttia rehellisen arvostelun jättämiseen DPM-podcastista Apple Podcastsissa. Arvostelut ovat meille todella hyödyllisiä ja arvostamme niitä suuresti. Ennen seuraavaa kertaa kiitos kuuntelusta.