Saatat tarkastella virstanpylväitä täysin väärin (TCGenin John Carterin kanssa)

Lue litterointi:

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

Galen Low

Siinä sitä taas tuijotat projektisuunnitelmaasi ja pelkäät niitä virstanpylväitä, joiden luomisessa itse autoit. Ne näyttävät lähestyvän joka kerta, kun katsot niitä, aivan kuin timantinmuotoiset Space Invaders -hahmot. Aluksi ne vaikuttavat harmittomilta: ne olivat vain viivoja hiekassa, joiden avulla suunnittelit kokonaisuutta suurpiirteisesti. Nyt ne ovat painolasti kaulasi ympärillä: raskaita ja liikkumattomia määräaikoja, joiden kanssa ei voi neuvotella. Ne ovat epäilyksen kuiskauksia, jotka uhkaavat vetää sinut vihaisten sidosryhmien lohikäärmeen luolaan kohtalokkaana päivänä. Jos tämä kuulostaa tutulta, minun on ikävä kertoa, että olet yksi niistä projektipäälliköistä, jotka ovat käyttäneet projektin virstanpylväitä täysin väärin. Älä huoli, useimmat meistä ovat samassa veneessä. Mutta jos haluat muuttaa projektin virstanpylväät kauhua herättävästä taakasta tiimin ja sidosryhmien yhteistyötä ohjaavaksi Pohjantähdeksi, jatka kuuntelemista.

Kiitos, että kuuntelet. Nimeni on Galen Low, ja edustan Digital Project Manageria. Olemme digitaalisten ammattilaisten yhteisö, jonka tavoitteena on auttaa toisiamme kehittämään taitoja, kasvattamaan itseluottamusta ja verkostoitumaan, jotta voimme toteuttaa projektit paremmin. Jos haluat kuulla siitä lisää, siirry osoitteeseen thedigitalprojectmanager.com.

Selvä. Hei kaikille, ja kiitos, että vietätte aikaa kanssamme DPM Podcastin parissa. Vieraani on tänään laajasti arvostettu tuotekehityksen asiantuntija, jolle projektinhallintakaan ei ole vierasta. Hän on yksi Bose-yhtiön melua vaimentavien kuulokkeiden sekä Applen uusien tuotteiden kehitysprosessin keskeisistä suunnittelijoista. Nykyään hänen yrityksensä TCGen neuvoo Amazonin, Applen, Ciscon, Hewlett-Packardin, IBM:n, Mozillan, Rochen ja 3M:n kaltaisia suuryrityksiä. Hän palkkasi hiljattain myös opettajan auttamaan musiikin teorian opiskelussa ja säveltää nykyään musiikkia. Toivottakaamme siis tervetulleeksi herra John Carter. Hei, John.

John Carter

Hei Galen. Mukava olla täällä.

Galen Low

Hienoa saada sinut mukaan. Arvostan tätä todella. John, ansioluettelosi on vaikuttava. Kun katsoin sitä, ajattelin, että kaikki ovat varmasti kateellisia sille. Olemme siis tekemisissä Bosen tuoteinnovaatioiden, Applen, oman yrityksen pyörittämisen ja kirjojen kirjoittamisen kanssa. Ajattelin aloittaa kysymällä, mitä halusit isona tehdä?

John Carter

Hauska kysymys. Teen sitä itse asiassa edelleen vapaa-ajallani: haluan olla insinööri. Olen aina halunnut suunnitella asioita, tehdä laskelmia ja ennustaa suorituskykyä. Se on ajanut minua koko elämäni ja ajaa edelleen.

Galen Low

Rakastan tuota! Oliko se suuri innoittaja siirtymisessäsi enemmän innovaatioiden pariin? Kuvittelen, että insinöörimäinen ajattelutapa sopii uusien, elinkelpoisten ja toteuttamiskelpoisten asioiden luomiseen – sellaisten, joita ihmiset todella käyttävät.

John Carter

En ole varma, oliko ajatteluni alussa niin harkittua, mutta olin prototyyppinen pikkupoikatieteilijä. Minulla oli kemiasarja, mikroskooppi ja kaukoputki. Hankin radioamatööriluvan. Tein kaikenlaisia nörttimäisiä asioita. Rakastin sitä, mitä tein. Luulen, että se liittyy siihen, mistä pidän nykyään: rakastin elektroniikkaa ja sitä, että sähköä tai elektroneja ei voinut nähdä, mutta niitä pystyi mittaamaan ja niiden avulla saattoi tehdä jotain. Nykyään sama pätee ääneen. Sitä ei voi nähdä, mutta sillä on valtava vaikutus siihen, miltä sinusta tuntuu ja miten ajattelet. Olen aina nauttinut sellaisten ilmiöiden ymmärtämisestä, joita ei voi nähdä.

Galen Low

Aivan. Oliko elämässäsi jokin inspiroiva hetki, jolloin päätit siirtää tämän pois insinööritieteiden kontekstista ja suunnata sitä enemmän teknologiaan, digitaaliseen maailmaan tai tuotteisiin?

John Carter

Tavallaan se syntyi luonnostaan työskennellessäni tohtori Bosen kanssa Bose Corporationissa, jossa aloitin. Hän oli poikkeuksellinen sekä markkinoinnissa että insinööritieteissä samanaikaisesti – se on hyvin harvinainen kyky. Hän esitti perustavanlaatuisia kysymyksiä siitä, mistä ihmiset välittävät, mitä he haluavat tehdä ja mikä heille on tärkeää. Hänen lähestymistapansa elämään auttoi minua ymmärtämään, kuinka tärkeää on todella ymmärtää asiakkaiden tarpeita ja varmistaa, että toimitamme heille sen, mikä on aidosti tärkeää. Opimme tämän monin tavoin. Vaikka olimme keksijöitä, emme oikeastaan tienneet, mitä asiakkaat arvostaisivat, ennen kuin annoimme tuotteen heidän käsiinsä. Uskon, että tohtori Bosen ja hänen valtavan markkinatuntemuksensa kautta siirryin vähitellen insinööritieteistä innovaatioihin.

Galen Low

Mahtavaa. Olet tehnyt urallasi niin paljon – onko nykyään jotain, missä yrität erityisesti kehittyä?

John Carter

Aina. Aina. Muutama asia tulee mieleen. Yksi todella kiinnostava aihe on ketterän kehityksen ja projektinhallinnan leikkauspiste. Se kiehtoo minua. Toinen on se, mitä kutsuisin digitaalisen tuotteen kehittämisen seurauksiksi. Millaista on työskennellä koneoppimisen parissa verrattuna tavalliseen tuotekehitykseen? Miten innovoidaan tällaisessa digitaalisessa ympäristössä ja uudessa etätyön todellisuudessa? Se, mitä tapahtuu, on kiehtovaa. Yritän siis todella ymmärtää, mikä työntää innovaatioiden rintamaa eteenpäin.

Galen Low

Hienoa. Pidän tuosta.

Halusin myös kysyä, oletko viime aikoina löytänyt jotain muuta, mikä tekee elämästäsi mahtavaa?

John Carter

Uskoni ihmiskuntaan on vahvistunut erityisesti sen vuoksi, että pystymme innovoimaan jatkuvasti. Kun katsot edessämme olevia ongelmia ja sitä, kuinka maailma on joutunut muuttamaan toimintatapojaan esimerkiksi etätyön, koulutuksen ja lääkekehityksen osalta, näet, että tästä kriisistä on syntynyt myönteisiä muutoksia. Se kasvattaa luottamustani kykyymme innovoida itsemme ulos mistä tahansa tilanteesta. Se antaa minulle paljon toivoa.

Galen Low

Pidän tuosta valoisasta näkökulmasta muuten ehkä meille tänä vuonna varsin hankalaan tilanteeseen. Hienoa. Ajattelin, että voisimme puhua äskettäisestä kirjoituksestasi, jonka julkaisit Thedigitalprojectmanager.comissa projektin virstanpylväistä. Ensinnäkin se sai minut tuntemaan, että olin käsitellyt projektin virstanpylväitä täysin väärin. Toiseksi se sai minut ajattelemaan projektin virstanpylväiden ja markkinoilla menestyvän tai epäonnistuvan tuotteen välistä yhteyttä tavalla, jolla en ollut aiemmin tarkastellut asiaa. Aloitetaan kuitenkin alusta. Mitä projektin virstanpylväät mielestäsi ovat, ja miksi niiden pitäisi kiinnostaa ketään?

John Carter

Se on erinomainen kysymys ja hyvä paikka aloittaa, koska ihmisten käsitykset virstanpylväistä ovat digitaalisen projektinhallinnan yhteydessä usein vääriä. Virstanpylväät eivät ole keino mitata edistymistä. On monia paljon parempia tapoja mitata edistymistä ilman, että tiimi uupuu, tuottaa valtavia määriä epäolennaisia raportteja tai joutuu mikromanageerauksen kohteeksi. Yleinen väärinkäsitys on, että virstanpylväitä käytetään seurantaan. Todellisuudessa ne ovat projektin taitekohtia: kriittisiä ajanjaksoja tai päätöspisteitä projektin elinkaaressa, jolloin ollaan esimerkiksi investoimassa lisää, ottamassa suurempaa riskiä tai tekemässä järjestelyjä kumppaneiden kanssa. Näissä tilanteissa kotiläksyjen tekeminen on perusteltua. Lisäksi monimutkaisessa ja toisiinsa kytkeytyneessä digitaalisessa maailmassa projektin ominaisuuksien välillä on paljon riippuvuuksia. Virstanpylväät ovat erinomainen tapa synkronoida riippuvuuksia. Kaksi tiimiä voi työskennellä ketterästi, mutta jossain vaiheessa toisen tiimin työ tarvitsee toisen tiimin tuotoksen. Virstanpylväät ovat hyvä tapa koordinoida tällaista toimintaa.

Galen Low

Pidän tuosta. Kun tätä ajattelee, mainitsit joitakin yleisiä väärinkäsityksiä virstanpylväistä, kuten seurannan ja raportoinnin korostamisen. Millaisia vaikutuksia sillä on projektiin, jos virstanpylväitä lähestytään näin sen sijaan, että ajateltaisiin tiimien välisiä riippuvuuksia?

John Carter

Vaikutuksia on paljon. Ensinnäkin se rapauttaa luottamusta siihen, että johto luottaa tiimiin. Jos projektit ovat täynnä tarkistuksia, johdon katselmuksia ja virstanpylväiden arviointeja, tiimi katsoo jatkuvasti olkansa yli ja miettii, mitä johto ajattelee.

Tämä on kuluttava asenne, koska se ei vahvista tiimin itseluottamusta eikä kykyä toteuttaa erinomaista projektia oma-aloitteisesti, vaikka kaikki tiimin jäsenet uskovat pystyvänsä siihen.

Lisäksi se rasittaa tiimiä, koska se tuottaa jatkuvasti raportteja, joita silmäillään, ei lueta tai tarkastellaan nopeasti, sekä työläitä grafiikoita ja päivityksiä. Mikä niiden tarkoitus on? Tehdä päätös? Viestiä? Jos tarkoitus on viestiä, voidaan käyttää projektin koontinäyttöjä, työjonoja tai monia muita tapoja edistymisen välittämiseen. Jos tarkoitus on tehdä päätös, mikä oikeastaan täytyy siirtää tiimin ulkopuolelle? Silloin tarvitaan suuri virstanpylväs. Niitä on harvoin. Ajatuksena on siis vähentää näiden arviointien määrää ja tiheyttä sekä varmistaa, että ne tuottavat tiimille lisäarvoa.

Se on todella tärkeää, kun mietitään, miten virstanpylväät toteutetaan tehokkaasti.

Galen Low

Pidän tuosta. Kyse on enemmän työn tekemisestä kuin sen pysäyttämisestä arviointia tai raportointia varten.

John Carter

Juuri niin. Silloin johdolle annetaan valitettavasti mahdollisuus lisätä arvoa lainausmerkeissä ja kasata tiimin harteille joukko tyhjiä kaloreita, jotka tiimin on käytettävä uuden raportin tuottamiseen, jotta joku voi nähdä enemmän. Johto heittelee jatkuvasti tuoleja tiimin tielle, vaikka sen pitäisi poistaa esteitä ja pysyä poissa tieltä.

Tämä on toinen tapa, jolla virstanpylväät voivat toimia kahteen suuntaan. Liian monet kannustavat mikromanageeraukseen; oikea määrä kannustaa oikeanlaiseen päätöksentekoon.

Galen Low

Hienoa. Oliko sinulla hetkeä, jolloin pysähdyit johtamasi projektin aikana ja tajusit, että toimit väärällä tavalla? Että kyseessä pitäisi olla enemmän tiimi ja tiimityö kuin raportointi?

John Carter

Kyllä. Pian sen jälkeen, kun minut oli ylennetty Bosen pääinsinööriksi, minulla oli taipumus mikromanageerata, järjestää yhä enemmän katselmuksia ja ripotella projektiin lisää virstanpylväitä. Tajusin yhtäkkiä hukkuvani, koska en löytänyt viikosta tarpeeksi aikaa kaikkien yksityiskohtiin takertuvien katselmusten aikatauluttamiseen. Toinen asia oli, etteivät ne auttaneet tiimejäkään. Minä hukuin ja tiimit hukkuivat. Sitten tajusin – ja tämä oli jopa hieman nöyryyttävää – että jotkut tiiminvetäjistä ja teknisistä asiantuntijoista tiesivät paljon enemmän kuin minä. Paljon enemmän. Minun olisi pitänyt vain poistua tieltä. En tiennyt, mistä puhuin. Eräs kehitysorganisaation insinööri sanoi, että aiheutin vain vääristymiä, viivettä ja melua. Se oli luultavasti hetki, jolloin lopetin niin monien virstanpylväskatsausten tekemisen.

Galen Low

Kun lopetit, huomasitko tiimin toiminnassa välittömän eron?

John Carter

En oikeastaan. Tuottavuus parani vähitellen, ja minä olin työssäni paljon onnellisempi. Huomasin, että tiimi suoriutui yhtä hyvin tai jopa paremmin ilman sekaantumistani. Se ikään kuin nostaa verhon tiimin edestä, tekee jäsenistä tuottavampia ja tyytyväisempiä ja auttaa toimittamaan parempia tuotteita.

Galen Low

On hämmästyttävää, miten raskasta epäluottamus on. Kun asiat lähtevät epäluottamuksesta, se on tiimille raskas taakka verrattuna luottamukseen: työ tulee tehdyksi, kaikki tekevät tehokkaasti yhteistyötä ja hallitsevat toimintaansa.

John Carter

Se on jatkuvasti läsnä oleva kuluttava ilmapiiri. Olen samaa mieltä.

Galen Low

Puhutaan lisää siitä, miten tämä tehdään oikein ja miltä oikea toiminta näyttää projektin virstanpylväiden osalta. Mainitsit, että virstanpylväät ovat enemmän tiimiä kuin projektipäälliköitä tai johtoa varten. Miten tiimi opetetaan näkemään asia niin, jos se ei vielä ajattele näin?

John Carter

Tämä palautuu puhumaasi epäluottamuksen ympäristöön. Olennaista on, että tiimillä on pätevä tuoteomistaja, pätevä Scrum-mestari, digitaalinen projektipäällikkö ja pätevä tekninen vetäjä. Jos nämä kolme asiaa ovat kunnossa, johdon pitäisi luottaa tiimiin ja järjestelmään. Kun tiimi on pätevä, jatkuvalle mikromanageeraukselle ei ole tarvetta. Silloin tiimin kanssa voidaan työskennellä niin, että se ymmärtää keskeiset virstanpylväät ja niiden tärkeyden. Tämä on mielestäni kaikkein tärkeintä. Virstanpylväiden ei myöskään pitäisi koskaan perustua kiinteään aikaväliin.

Viikoittaisia vakituisia kokouksia tai kuukausittaisia arviointikokouksia ei siis pitäisi olla automaattisesti, eikä myöhästyneitä katselmuksia pitäisi jatkuvasti kutsua koolle. Jotkin katselmukset ovat tarpeellisia, mutta eivät yleensä näin yksityiskohtaisella tasolla. Virstanpylväiden pitäisi perustua tapahtumiin.

Ne ovat projektivetoisia. Ne perustuvat muun muassa tiimin nopeuteen, kypsyyteen, kokoon ja riskiin sekä tietenkin haasteeseen ja tehtävään. Jos virstanpylväät osuvat säännöllisesti kalenteripäiville, kyseessä on ongelma.

Galen Low

Se kuulostaa melkein epäluottamukselta: tarkistan tilanteesi kahden viikon välein.

John Carter

Juuri niin.

Galen Low

Varmistan, että kaikki pysyy raiteillaan sen sijaan, että kuuntelisin tässä hetkessä: meidän täytyy tarkastella, missä olemme, koska muut asiat ovat riippuvaisia tästä. Miten suunnittelemme tai teemme yhteistyötä seuraavien vaiheiden osalta?

John Carter

Tai olemme kirjoittamassa, sanotaanko, seitsennumeroista shekkiä. Olemmeko varmoja, että teemme oikean asian? Ehdottomasti.

Galen Low

Kun asian ilmaisee noin, se on todella tärkeää.

John Carter

Shekit voivat olla suuria.

Galen Low

Aivan. Tiimin valmiudesta puheen ollen pidän siitä, että nämä roolit on määritelty ja tiedämme niiden olevan vahvoja. Millaisia toimintatapoja odotat tiimiltä, joka on valmis omistamaan omat virstanpylväänsä ja ymmärtämään niiden merkityksen?

John Carter

Galen, tämä on erinomainen kysymys, ja siihen voi vastata hyvin yksinkertaisesti. Historia. Onko tämä tiimi ollut aiemmin ennakoitava? Osoittavatko sen aiemmat onnistumiset ja saavutukset myönteistä lopputulosta? Luottamus rakentuu ajan myötä. Projektitiimin paras mittari on varmasti sen aiempi historia ja onnistuminen ohjelmassa. Se on ensimmäinen ja tärkein asia. Jokaisessa keskeisessä roolissa tarvitaan henkilö, joka ymmärtää miksi- ja mitä-kysymykset. Hänen täytyy todella hallita ne, ja tiimin täytyy uskoa häntä. Sama pätee tekniseen vetäjään sekä kehitys- ja laadunvarmistustiimeihin: niiden kykyyn tehdä oikeita arkkitehtuuripäätöksiä ja kompromisseja projektin tavoitteiden saavuttamiseksi on voitava luottaa. Digitaalisen projektipäällikön osalta on voitava luottaa siihen, että hän toimii avoimesti ja tuo ongelmat nopeasti esiin eikä piilota niitä.

Näiden kolmen keskeisen roolin toimintatavat yhdessä historian kanssa osoittavat valmiuden.

Galen Low

Pidän siitä. Koko ajatus tiimin kokoonpanosta ja tiimin rakentamisen strategiasta on tärkeä. Kokeneet ihmiset lähestyvät työtä kypsästi ja ymmärtävät tekemisensä kontekstin. Heidän rinnallaan voi hyvin olla nuorempia työntekijöitä. Mutta tarkoitatko oikeiden ihmisten valitsemisella kokeneita tiimin jäseniä, jotka osaavat tarkastella projektia ja luomaansa tuotetta oikealla tavalla, ymmärtää virstanpylvään merkityksen ja auttaa suunnittelemaan projektin virstanpylväät?

John Carter

Ehdottomasti. Nuorempia rooleja voi olla huomattavasti enemmän kuin kokeneita, mutta tarvitaan kokemuksen kierroksia, niin sanottuja oppimissyklejä. Jos niitä on kertynyt useita ja kokemukset ovat olleet hyviä, tiimiin voi ehdottomasti luottaa.

Galen Low

Oppimissyklit.

John Carter

Niin.

Galen Low

Hienoa. Toinen kysymykseni koskee tilannetta, jossa työskentelet johtoryhmän kanssa, joka on tottunut kuukausittaisiin virstanpylväiden tarkistuksiin tai siihen, että lyhyelle ajalle asetetaan kymmeniä virstanpylväitä. He ovat tottuneet tarkistamaan tilanteen ja ehkä jopa luottavat tiimiin, mutta heidät on vain ohjelmoitu tarkistamaan tilanne ja mikromanageeraamaan.

Miten tällainen johto- tai johtoryhmä saadaan ajattelemaan virstanpylväitä eri tavalla, niin että niitä on vähemmän, niiden välillä on enemmän aikaa eikä niitä järjestetä säännöllisessä tahdissa?

John Carter

Se riippuu. Jos organisaatiossa on mekanismi edistymisen mittaamiseen – esimerkiksi työjono, tarinapisteet tai valmistuneet toimitukset – on olemassa kaikenlaisia yksinkertaisia ja objektiivisia mittareita. Niiden keveys ja objektiivisuus ovat tärkeitä. Niitä voidaan käyttää korvaavana näkymänä. Johtajien haasteena on se, että he sekoittavat läpinäkyvyyden ja projektin edistymisen seurannan päätöksentekoon. Ne ovat täysin erilaisia viestinnän muotoja. Edistymistä voidaan seurata koontinäytöillä tai muilla läpinäkyvillä indikaattoreilla. Viime kädessä sen voi tehdä kokouksessa, mutta vain yhden henkilön kanssa ja tarpeen määräämällä tiheydellä.

Johtajien keskuudessa esiintyy siis sekaannusta. Heille täytyy vakuuttaa, että he voivat nähdä edistymisen läpinäkyvästi ja että heille ilmoitetaan, jos jokin menee pieleen. Tiimillä on myös rajat sille, mikä kuuluu sovittuun digitaalisen projektikehityksen piiriin. Jos tiimi ei saavuta sovittuja rajoja, sen velvollisuus on ilmoittaa siitä johdolle. Jos johto pystyy seuraamaan edistymistä läpinäkyvästi ja luottaa siihen, että huonoista uutisista ilmoitetaan nopeasti, tämän pitäisi riittää. Kun lisäksi tiedetään tiimin historia, johdolle voidaan perustella vakuuttavasti, miksi virstanpylväitä tarvitaan vähemmän.

Galen Low

Ehdottomasti. Pidän tuosta erottelusta raportoinnin ja seurannan sekä päätöksenteon välillä. Juuri päätöksentekoon virstanpylväät liittyvät: ne ovat hetki, jolloin kysytään, miten meillä menee. Ei niinkään edistymisen kannalta, vaan siinä kohdassa, kun aiomme siirtyä seuraavaan vaiheeseen tai ottaa mukaan uuden yhteistyötiimin. Olemmeko siihen valmiita? Onko se yhä oikea ratkaisu?

John Carter

Juuri niin. Ovatko he valmiita meitä varten? Se on arvokas tarkistus.

Galen Low

Seuraava kysymykseni koskee virstanpylväiden suunnittelua. Muuttaako tämä näkökulma tapaa, jolla luomme ne alun perin tai kehitämme projektisuunnitelmaa? Jos yleensä tarkistetaan tilanne neljännesvuosittain tai päivitetään ohjausryhmä, muuttaako virstanpylväiden tarkasteleminen projektin ja tiimin näkökulmasta projektien suunnittelua?

John Carter

Ehdottomasti. Muut tilanneraportit ja ohjausryhmän päivitykset vähenisivät tai poistuisivat. Puhumme kevyestä kehyksestä digitaalisen tuotteen kehittämiseen. Kehyksessä pitäisi olla joukko liiketoimintaan sopivia vakiotaitekohtia. Eri organisaatioilla on erilaiset rajoitteet. Jos valmistat tuotteita, sinun täytyy tilata varastoa ja osia. Se on suuri menoerä, joten oikeat osat on tärkeää määritellä. Jos taas käynnistät digitaalista projektia, haluat varmistaa, että tuotteeseen sisältyy oikeanlainen mittaus ja että tiimisi tarvitsemat analytiikkatiedot ovat saatavilla.

Kaikki riippuu liiketoiminnasta. Virstanpylväiden pitäisi kuitenkin yleensä olla standardoituja ja niitä pitäisi olla vähän. Sanon mielelläni, että prosessia pitäisi olla niin vähän kuin mahdollista, mutta ei vähempää. Tee siitä kevyt ja lisää standardoidut virstanpylväät kohtiin, joissa liiketoiminta yleensä tekee suuria päätöksiä. Niitä pitäisi olla pieni määrä, esimerkiksi kolmesta viiteen.

Galen Low

Pidän esimerkistäsi. Jos osia täytyy tilata, riippuvuudet ovat järkeviä: ennen tilausta täytyy varmistaa, että ollaan kohdassa, jossa se on järkevää.

John Carter

Ehdottomasti. Tyypillisessä digitaalisessa kehityksessä on pilvitoimintoja, asiakaspuolen toimintoja ja mahdollisesti työpöytäsovelluksia. Monia erilaisia järjestelmiä täytyy integroida, ja DevOps-toimintaa koordinoida. Jokainen liiketoiminta on erilainen.

Galen Low

Yksi artikkelisi kiehtovimmista asioista oli puhe kolmesta suuresta virstanpylväästä tai taitekohdasta projektin aikana, jotka liittyvät keskeisiin liiketoimintatavoitteisiin. Voitko selittää, mitä ne ovat ja miksi ne ovat tärkeitä?

John Carter

Ensimmäinen on mielestäni erittäin tärkeä, erityisesti innovaatiosta puhuttaessa. Aivan projektin alussa on kysyttävä, onko konsepti todella strategiamme mukainen. Sopii se siihen, mitä olemme brändinä? Onko tämä tuote tai idea sellainen, jonka haluamme tuoda markkinoille? Vaikuttaako se liikevaihtoon tai katteeseen? Aiomme sitoutua tähän toimintaan mahdollisesti 3, 6, 9 tai 18 kuukaudeksi ja ehkä suureen tiimiin. Onko tämä strategiamme mukaista ja muuttaako se tilannetta? Ensimmäinen vaihe on konseptin sopivuuden tarkistaminen.

Kun konsepti on strategian mukainen, toinen tärkeä asia on tuote–markkina-sopivuus. Onko meillä jotain, jonka kuluttajat valitsevat? Onko meillä kuluttajille merkityksellisiä ainutlaatuisia myyntiväitteitä? Onko tuotteella markkinoilla elinvoimaa? Voimmeko saada lisää käyttäjiä tai kasvattaa ostoskorin kokoa? Onko meillä näyttöä hankintakustannuksista? Digitaalisten projektien ja tuotteiden aikana kaikki tämä on mitattavissa. Ennen tiimin laajentamista on tärkeää varmistaa tuote–markkina-sopivuus.

Viimeinen vaihe on kehitys ja markkinoillelanseeraus. Organisaatio tietää, että konsepti sopii strategiaan ja että kuluttajat pitävät tuotteesta. Mitä meidän täytyy kehittää, jotta saamme aikaan ominaisuuksiltaan valmiin julkaisun ja vähimmäisversion? Millaisia kumppaneita tarvitsemme infrastruktuuriin ja eri mobiilialustoille? Miten jaamme työn? Meidän täytyy investoida käyttöliittymään, graafiseen suunnitteluun ja muuhun. Olemmeko valmiita sitoutumaan siihen? Tämä on sitoutuminen kehitykseen ja markkinoillelanseeraukseen.

Nämä kolme keskeistä taitekohtaa ohjaavat useimpia digitaalisia tuotekehitysprojekteja, mutta niitä voidaan mukauttaa. Etupäähän voidaan lisätä ideointivaihe, loppuun erillinen validointivaihe tai mukaan DevOps-vaihe. Yhteinen kehys on kuitenkin tärkeä, koska kasvavassa yrityksessä johtajat tarvitsevat muutaman standardoidun virstanpylvään voidakseen verrata projektien tilanteita. Se auttaa hallitsemaan kulutusta ajan kuluessa ja ymmärtämään, missä projekti todella on asiakkaiden saavuttamisen ja investointien näkökulmasta.

Galen Low

Pidän ajatuksesta vertailla projekteja keskenään. Jos yritys kehittää useita projekteja tai tuotteita samanaikaisesti, täytyy tarkastella kokonaisuutta ja nähdä, missä vaiheessa kukin on – ei niinkään projektin edistymisen terveyttä, vaan tuotteen konseptin ja sen kehittymisen tilaa sekä sitä, milloin tuote lanseerataan ja milloin se tarvitsee tiettyjä resursseja.

John Carter

Kun tarkastelet näitä kolmea virstanpylvästä, mikään niistä ei ole sidottu aikaan. Ne liittyvät siihen, sopiiko tuote strategiaan, onko sillä tuote–markkina-sopivuus ja haluammeko todella investoida sen lanseeraamiseen. Ne ovat kolme tärkeää, aikaan sitomatonta ohjelman osaa, eikä niiden hallinnan pitäisi olla organisaatiolle liian raskasta.

Galen Low

Jos nämä kolme on asetettu projektisuunnitelmaan, ovatko ne muuttumattomia? Monet ajattelevat projektisuunnittelun virstanpylväitä asioina, jotka eivät voi siirtyä. Mitä mieltä olet tästä?

John Carter

Toivon ja todellisuuden välillä on ero. Puhtaassa ketterässä ohjelmistokehityksessä on teoriassa mahdollista olla myöhästymättä virstanpylväästä. Todellisuudessa silloin siirretään sprinttiä, ei virstanpylvästä. Myös ketterässä kehityksessä ominaisuuksiltaan valmiilla tuotteella on tärkeä merkitys. Nämä virstanpylväät ovat yleispäteviä ja soveltuvat tilanteeseen kuin tilanteeseen. Ne auttavat todella nopeuttamaan innovaatioita.

Galen Low

Voisitko antaa esimerkkejä, jotta asia olisi kuulijoillemme konkreettisempi? Millainen voisi olla konseptin sopivuuden virstanpylväs ja millainen sitä seuraava tuote–markkina-sopivuus? Voit käyttää todellista tai kuvitteellista esimerkkiä.

John Carter

Olen äskettäin perustanut järjestelmän, jota kutsuimme yrityshankkeiden johtoryhmäksi. Se oli suureen teknologiayritykseen perustettu pääomasijoitusrakenne. Kävimme läpi tämän peruskehyksen ja saimme siitä konkreettisia opetuksia.

Konseptin sopivuudessa tärkeää on ensinnäkin se, että konsepti on yrityksen todellisen pohjoisen eli strategian mukainen. Loimme usein strategisen kartan projekti-ideoista. Kartan toinen ulottuvuus oli strateginen sopivuus ja toinen taloudellinen vaikutus eli se, kuinka paljon idea muuttaisi tilannetta. Ensin kysyimme, onko kehitettävä idea strategiamme mukainen ja vaikuttaako se tulokseen. Tätä varten voi käyttää tarkistuslistaa ja strategista karttaa.

Tuote–markkina-sopivuus on erilainen, koska siinä tarkastellaan ulkoisia tekijöitä. Hankintakustannus on luultavasti tärkein mittari, mutta täytyy myös ymmärtää ainutlaatuinen myyntiväite ja se, mitä kuluttajat haluavat. Tämä palaa kuulokekokemukseeni. Olin keksijä, ja olimme tohtori Bosen kanssa patentin kaksi ensimmäistä henkilöä. Kehitimme tuotetta paremman äänen vuoksi: sen basso olisi parempi ja tasaisempi eri ihmisten päissä ja eri käyttötilanteissa.

Kun annoimme tuotteen ihmisten käsiin, he eivät välittäneet siitä. He halusivat melun vähentämistä. Meillä ei siis oikeastaan ollut tuote–markkina-sopivuutta, vaikka olimme keksijöitä. Muutimme suuntaa ja keskityimme melun vähentämiseen täydellisen tasapainon ja taajuusvasteen sijasta. Tuote–markkina-sopivuus on erittäin tärkeä, ja ainoa tapa mitata sitä aidosti on olla jollain tavalla yhteydessä asiakkaisiin.

Viimeinen virstanpylväs on liiketoimintaperustelu. Toimiiko matematiikka? Ylittääkö tuotteen kate hankintakustannuksen selvästi? Missä tuote täytyy lanseerata? Jos laskelmat osoittavat, että tuloksena voi olla kannattava ja suuren volyymin digitaalinen tuote, sitä kannattaa tavoitella. Nämä kolme taitekohtaa ovat strateginen sopivuus, hankintakustannus ja tuote–markkina-sopivuus sekä liiketoimintaperustelu.

Galen Low

Pidän siitä, että kuuloke-esimerkissä päätöspistettä ei käytetty epäonnistumisena. Arvioitte tuotetta, ymmärsitte, että suuntaa täytyy muuttaa, ja käytitte jäljellä olevan ajan oikean sopivuuden saavuttamiseen.

John Carter

Aivan. Ja teimme sen aikaisin. Se on avainasia.

Galen Low

Kun kerran puhumme ketterästä kehityksestä, miksi virstanpylväitä yhä tarvitaan? Pitäisikö ketterää menetelmää käyttävän projektipäällikön välittää niistä? Miltä ne näyttävät ketterässä työssä?

John Carter

Yleinen ja huono väärinkäsitys on, etteivät ketterä kehitys ja virstanpylväät sovi yhteen. Tosiasia on, että lähes kaikilla tuntemillani ketterää kehitystä käyttävillä yrityksillä on virstanpylväitä – ei vain yksiä, vaan kymmeniä. Myyttiä levittävät uskonnolliset kiihkoilijat, sanon sen sekä huumorilla että osittain tosissani. Ketterä kehitys ei ole ristiriidassa virstanpylväiden kanssa. Kuten puhuimme, riippuvuuksien hallintaan tarvitaan virstanpylväitä, ja kaikissa riittävän monimutkaisissa ketterissä ohjelmissa on riippuvuuksia. Sprintti nollan aikana laaditaan julkaisusuunnitelma ja määritetään, missä sprinteissä riippuvuudet tulevat vastaan. Ne ovat virstanpylväitä, vaikka niitä kutsuttaisiin jollain muulla nimellä.

Lisäksi jokainen organisaatio, joka aikoo investoida paljon digitaaliseen projektiin, kysyy tiimiltä, onko se valmis käyttämään rahaa ja onko investointi hyvä. Se on virstanpylväs. Ketterä kehitys ja virstanpylväät eivät siis ole vaihtoehtoja toisilleen. Ne toimivat hyvin yhdessä. Parhaissa järjestelmissä käytetään molempia.

Galen Low

Hienoa.

John Carter

Lisäisin vielä, että uskon pieneen a-kirjaimeen kirjoitettuun ketteryyteen: mitkä ketterät käytännöt ovat sinulle arvokkaita ja vievät liiketoimintaa tärkeällä tavalla eteenpäin? Esimerkiksi sprintin suunnittelu, demot ja asiakaspalaute voivat olla tärkeitä. Selvitä, mikä ketteryydessä on olennaista, ja sovella sitä.

Galen Low

John, nämä tuotevirstanpylväitä koskevat vinkit ovat todella arvokkaita. Erityisesti standardoidut virstanpylväät jäivät mieleeni. En ollut ajatellut niitä keinona vertailla projekteja, asettaa odotuksia sidosryhmille ja johdolle sekä ohjata päätöksentekoa, kun ollaan allekirjoittamassa suurta shekkiä seuraavan vaiheen rahoittamiseksi tai tilaamassa kaikkia tarvittavia osia.

Se on suuri oivallukseni tästä keskustelusta.

John Carter

Hienoa.

Galen Low

Mikä olisi ensimmäinen askel ihmisille, jotka haluavat muuttaa tapaansa käyttää virstanpylväitä ja ottaa tämän lähestymistavan käyttöön?

John Carter

Tärkeintä on ymmärtää, mitkä ovat liiketoiminnan keskeiset päätökset. Mitkä ovat ne harvat tärkeät kohdat, joiden kautta jokaisen projektin täytyy kulkea? Mitkä ovat solmukohdat? Sopikaa niistä ja kutsukaa niitä samoilla nimillä. Jokaisen tiimin pitäisi käyttää niitä. Näin aloitimme Applen uuden tuotteen prosessin laajentamisen: sovimme muutamasta virstanpylväästä, päätimme niiden nimet ja määritimme, mitä niihin mennessä täytyy olla tehtynä. Sitten aloimme käyttää samaa kieltä. Se kuulostaa yksinkertaiselta, mutta ensimmäinen askel on sopeutuminen.

Galen Low

Se on järkevää. Kun tätä tapaa käytetään, mikä on tärkein asia muistaa matkan aikana?

John Carter

Puhuimme alussa luottamuksen, päätöksenteon ja seurannan muodostamasta kehästä. Jos rakennamme luottamukseen perustuvan järjestelmän, jossa pätevät ihmiset johtavat projektejaan, ja erotamme päätöksentekoon tarkoitetut virstanpylväät seurannasta, voimme jättää seurannan kevyen ja kitkattoman järjestelmän tehtäväksi. Se tarjoaa johdolle sen tarvitseman tiedon kuormittamatta tiimiä.

Galen Low

Pidän siitä todella paljon.

John, kiitos paljon osallistumisestasi. Arvostan suuresti kaikkia oivalluksiasi. Keskustelu on muuttanut tapaani ajatella, ja toivottavasti sillä on merkittävä vaikutus myös kuulijoihimme.

John Carter

Kiitos mahdollisuudesta puhua tästä. Tunnet aiheen selvästi, ja olet tiivistänyt keskeiset kohdat hyvin. Kiitos tästä mahdollisuudesta, Galen.

Galen Low

Mitä mieltä sinä olet? Mitkä ovat omat vinkkisi ja niksisi projektin virstanpylväisiin? Mikä toimii? Mikä ei? Kerro meille tarina. Milloin projektin virstanpylväät ovat pettäneet sinut? Mitkä parhaat käytännöt ovat johtaneet suuriin onnistumisiin? Kerro kommenteissa alla. Jos haluat oppia lisää ja edetä työssäsi, liity DPM-jäsenyyden kautta yhteisöömme osoitteessa thedigitalprojectmanager.com/membership. Saat käyttöösi asiantuntijafoorumin, mentorointiryhmiä, työpajoja, live-mentorointisessioita, kysy mitä tahansa -sessioita, sähköisiä kirjoja, malleja ja paljon muuta. Jos pidit tämänpäiväisestä jaksosta, tilaa podcast ja pysy yhteydessä osoitteessa thedigitalprojectmanager.com. Ensi kertaan. Kiitos kuuntelusta.