Projektiryhmät ilman projektipäälliköitä: projektipäällikködilemman tarkastelu

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmistolla. Anna anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.

Galen Low: Itseohjautuvat projektiryhmät. Jo tämä ilmaus riittää aiheuttamaan eksistentiaalisen kriisin kenelle tahansa projektipäällikölle. Mutta uhkaako se olemassaoloamme? Vai onko se avain projektipäällikön nostamiseen selvästi strategisempaan rooliin?

Jos olet pohtinut projektinhallinnan tulevaisuutta ja sitä, ovatko digitaaliset projektipäälliköt jatkossakin merkityksellisiä, jatka kuuntelemista. Avaamme, miten yksi organisaatio rakentaa menestyksekkäästi monimutkaisia ohjelmistoratkaisuja hajautettujen, itseohjautuvien ryhmien avulla ja mitä tämä merkitsee digitaaliselle projektinhallinnalle yleisesti.

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

Hei kaikille — kiitos, että vietätte aikaa kanssamme DPM-podcastissa.

Vieraani on tänään Kiovassa työskentelevä IT-ammattilainen, joka on vienyt liiketoimintaprosessien hallintaa ja digitaalisten tuotteiden hallintaa eteenpäin yli 15 vuoden ajan. Hän on toiminut liiketoiminta-analyytikkona, PMO-johtajana, tuotejohtajana ja asiakaskokemusjohtajana sekä työskennellyt Heinzille, Yandexille, Adidakselle ja Zyxelille yritysjärjestelmien toteuttamisessa suuressa mittakaavassa.

Nykyään hän on Railswaren tuotepäällikkö ja työskentelee Coupler.io-tiimissä, jossa hän valvoo etätyötä tekeviä, itseohjautuvia ketterien tiimien ryhmiä. Nämä ryhmät luovat laajasti omaksuttuja tuotteita, joista on tullut tuttuja nimiä, kuten Calendly.

Työnsä ulkopuolella hän opettaa liiketoimintaprosessien ja projektinhallinnan perusteita Lviv Business Schoolissa ja kasvattaa vauvaansa seuraavan teknologia-alan naissukupolven edustajaksi.

Tervetuloa, Julia Ryzhkova. Hei, Julia!

Julia Ryzhkova: Hei! Hei kaikille!

Galen Low: Kiitos, että liityit seuraamme tänään. Viimeaikaiset keskustelumme ovat olleet antoisia, ja olen todella innoissani tästä jaksosta, koska käsittelemme asiaa, joka tekee meidät projektipäälliköt hieman epävarmoiksi: ovatko projektipäälliköt olemassa vielä tulevaisuudessa?

Palaamme tähän, mutta haluaisin ensin kysyä: miten elämä sujuu? Mikä on inspiroinut sinua viime aikoina?

Julia Ryzhkova: Ne ovat oikeastaan kaksi eri asiaa. Jos puhumme Railswareen liittyvistä asioista, kyse on BRIDGeS-kehyksestä. Julkaisimme sen hiljattain. Se on päätöksentekokehys, jonka avulla ongelman voi kuvata korkealla tasolla ja muuttaa sen sitten ratkaisuksi.

Otimme sen äskettäin käyttöön, ja olen parhaillani mukana levittämässä siitä tietoa suusanallisesti. Se on todella hieno asia, ja olen siitä erittäin innoissani. Olemme kehittäneet sitä yli 15 vuoden ajan. Nyt olemme vasta avaamassa sitä yleisölle, ja se inspiroi minua todella paljon.

Henkilökohtaisesta näkökulmasta olen myös mukana siinä, minkä mainitsit: työskentelen Lviv Business Schoolin kanssa. Järjestämme parhaillaan julkista verkkokoulutusta liiketoimintaprosesseista, ja toivon, että se parantaa Ukrainan liiketoimintaprosessikulttuurin yleistä kypsyyttä.

Se inspiroi myös.

Galen Low: Pidän siitä. Molemmat ovat erittäin hienoja asioita ja merkittäviä saavutuksia. Onnittelut!

Jos ihmiset haluavat oppia lisää BRIDGeS-kehyksestä, mistä he voivat löytää lisätietoa?

Julia Ryzhkova: Railswaren verkkosivustolta. Sillä on oma aliverkkotunnuksensa.

Galen Low: Mahtavaa. Todella hienoa. Kun tätä nauhoitetaan, on joulukuu. Olemme päättämässä vuotta 2021 ja aloittamassa vuotta 2022. Mietin, mitä odotat eniten vuodelta 2022?

Julia Ryzhkova: Kaikki puhuvat tällä hetkellä tekoälystä ja koneoppimisesta. Meillä oli hiljattain tapaaminen, jossa keskustelimme tuotteidemme visioista, ja syntyi ajatus tekoälyn käyttämisestä Coupler.io-tuotteessani. Olen todella kiinnostunut kokeilemaan sitä ja näkemään, miten se toimii.

Galen Low: Hienoa.

Siirrytään asiaan. Puhumme tänään siitä, miten pienet etätyötä tekevien ketterien tiimien ryhmät voivat hallita toimintaansa ja järjestäytyä itse parviksi luodakseen monimutkaisia ohjelmistoratkaisuja ilman projektipäällikköä missään vaiheessa. Onko tämä uhka meille projektipäälliköille? Onko se mahdollisuus projektipäälliköille olla strategisempia? Nostaako se esiin kaikkien kuuntelijoidemme eksistentiaalisen ahdistuksen?

Tutkimme kaikkea tätä yksityiskohtaisesti ja pureudumme aiheeseen kunnolla.

Mutta ensin haluaisin kuulla hieman urapolustasi. Mikä on roolisi nykyään ja miten päädyit siihen?

Julia Ryzhkova: Olen nykyään tuotepäällikkö, mikä tarkoittaa, että vastaan tuotteiden kehityksestä, markkinoinnista, hinnoittelustrategiasta ja myyntiorganisaatiosta.

Minulla on tekninen koulutus, tietojenkäsittelytiede, josta on ollut minulle paljon hyötyä. En kuitenkaan oikeastaan pitänyt ohjelmoinnista. Kun etsin uramahdollisuuksia, halusin jotakin, jossa voisin luoda algoritmin ja antaa jonkun muun koodata sen. Näin minusta tuli liiketoiminta-analyytikko. Sen jälkeen kehittin johtamistaitojani, ja minusta tuli liiketoiminta-analyytikkotiimin vetäjä, projektipäällikkö ja liiketoiminta-analytiikan osaston johtaja.

Huomasin kuitenkin, että työni tulokset riippuivat suuresti tuotteesta, jonka parissa työskentelin. Siksi päätin siirtyä tutkimukseen ja tuotekehitykseen tuotteen omistajaksi ja osaksi tuotetta. Se oli ensimmäinen kerta, kun tunsin olevani oikeassa paikassa. Tuotteemme ja tiimimme kasvoivat, saimme lisää tuotteen omistajia ja minusta tuli tuotantojohtajan sijainen, joka vastasi puolesta Scrum-tiimeistä. Halusin kuitenkin edetä vielä pidemmälle.

Koska meillä oli jo tuotantojohtaja ja halusin edelleen siirtyä johtoryhmään, minusta tuli asiakaskokemusjohtaja. Vastasin tuesta ja kaikesta palveluihin, tukipalveluihin, akatemiaan ja muuhun vastaavaan liittyvästä. Onnistuin rakentamaan hienot prosessit ja saavuttamaan hyviä tuloksia.

Siksi päätimme hyödyntää näitä taitoja ja rakentaa vastaavia prosesseja myös muissa osastoissa, ja minusta tuli PMO-johtaja. Sitten alkoi äitiyslomani. Kun olin päättänyt tämän tärkeän elämänvaiheen, halusin palata tuotepäälliköksi.

Se oli tärkeä päätös. Saatat miettiä, miksi valitsin tuotepäällikön enkä projektipäällikön roolia. Halusin keskittyä asiakkaiden saamiin hyötyihin ja jättää prosessien hallinnan taka-alalle. Minulle tuotteiden ja projektien hallinnan välillä on paljon yhtäläisyyksiä.

Tuotepäälliköt voivat kuitenkin keskittyä enemmän tuotteeseen ja asiakkaaseen, kun taas projektipäälliköt keskittyvät prosessiin ja sen tuloksiin. Tässä itseohjautuvat tiimit ovat ratkaisevan tärkeitä. Kun löysin Railswaren ja kuulin siitä sekä luin siitä lisää, tiesin sen sopivan minulle täydellisesti.

Galen Low: Pidän tästä kehityskaaresta. Tekninen taustasi, asiakaskokemuksen tuntemuksesi ja PM-tiimien johtaminen ovat kaikki hienoja asioita. Se on varmasti inspiroivaa monille alamme ihmisille.

Voisitko kertoa hieman Railswaresta ja valvomasi tiimin rakenteesta? Ehkä myös siitä, millaisia projekteja Railsware toteuttaa?

Julia Ryzhkova: Aloitetaan projekteista, koska tiimin rakenne riippuu siitä, millaisten projektien parissa työskentelemme. Olemme tuote studio, mikä tarkoittaa, että luomme tuotteita itsellemme ja muille yrityksille. Railswarella haluamme automatisoida kaiken, emmekä joskus löydä markkinoilta työkalua, joka tekisi tarvitsemamme asian.

Silloin päätämme kehittää jotakin omiin tarkoituksiimme. Käytämme sitä itse ja julkaisemme sen myöhemmin avoimesti markkinoille, koska tiedämme, ettemme ole ainoita, jotka tarvitsevat sitä. Siksi aloitamme yleensä pienenä tiiminä, koska etsimme markkinoilta tiimille sopivaa tuotetta.

Joskus mukana on esimerkiksi osa-aikainen kehittäjä. Yksi tuotteistamme, Smart Checklist for Jira, kehitettiin aluksi yhden kehittäjän osa-aikatyönä. Vasta kun kuukausittainen toistuva liikevaihto saavutti 50 000 dollaria, päätimme sijoittaa siihen kokoaikaisia kehittäjiä.

Pienissä tuotteissa, kuten Coupler.io:ssa, meillä on yksi kehitysryhmä, jossa on neljä tai viisi kehittäjää, sekä yksi markkinointiryhmä, jossa on myös neljä tai viisi erilaista asiantuntijaa.

Kaikki muut työskentelevät osa-aikaisesti, esimerkiksi data-analyytikko ja tukipäällikkö. Myös minä tuotepäällikkönä työskentelen tämän tuotteen ja asiakkaiden tuotteiden parissa. Kun tuote kasvoi, kuten Calendlyn tapauksessa, laajensimme kehitystiimiä ja jaoimme sen useisiin ryhmiin, koska uskomme pienen ryhmän olevan tehokkain työskentelytapa.

Calendlylla on tällä hetkellä kolme tiimiä meidän puolellamme ja paljon kehittäjiä heidän puolellaan. Näin se toimii.

Galen Low: Todella kiinnostavaa. Haluan perehtyä ryhmien ja parvien ajatukseen. Pidän siitä, että markkinointi on yksi ryhmä. Mainitsin aiemmin ketterät tiimit, mutta ketteryys ei tarkoita automaattisesti tekniikkaa tai kehitystä.

Se voi tarkoittaa monia eri asioita, joihin pääsemme varmasti. Haluaisin kysyä, mikä on nykyisessä roolissasi suurin haaste tuotteen kehityksen näkökulmasta?

Julia Ryzhkova: Luulen, ettei vastaus yllätä. Jokaisella tuotepäälliköllä on startup-tuotteessa samat tavalliset haasteet: oman kultakaivoksen löytäminen markkinoilta.

Ratkaisemme yleensä jonkin asiakkaan ongelman. Siksi asiakaskuntamme ja suorituskykymittarimme kasvavat. Haluamme kuitenkin säilyttää vauhdin ja kaksinkertaistaa sen. Meidän on siis löydettävä toinen ongelma, jonka poistamisesta asiakkaat ovat valmiita maksamaan kaksinkertaisen hinnan.

Galen Low: Olette ongelmanratkaisijoita. Pidän siitä, että kuulostaa siltä kuin ratkoisitte ensin ongelmia itsellenne ja veisitte sitten ratkaisun muille, joilla on sama ongelma. Sisäisestä tuotteesta tulee ulospäin suunnattu tuote. Olette myös palveluorganisaatio, joka auttaa muita organisaatioita rakentamaan unelmiensa tuotteita ja poistamaan ongelmia, joita ne eivät enää kestä.

Se on todella hienoa.

Antakaamme kuuntelijoillemme hieman taustaa. Omissa verkostoissani itseohjautuvien tiimien käsite on kaksiteräinen miekka. Useimmat projektipäälliköt haluavat tiimiensä olevan itsenäisiä, jotta työ edistyy ilman, että projektipäälliköstä tulee pullonkaula. Toisaalta useimmat projektipäälliköt haluavat myös pysyä merkityksellisinä ja säilyttää työpaikkansa.

Ajatus projektiryhmistä ilman projektipäälliköitä ei kuitenkaan ole uusi. Esimerkiksi Scrum-ketterässä tiimissä ei oikeastaan mainita projektipäällikön roolia. Siinä ovat tuotteen omistaja, Scrum-mestari ja kehitystiimi. Tavallaan merkit ovat siis olleet näkyvissä jo jonkin aikaa, mutta yritämme yhä selvittää, mitä ne tarkoittavat ja keitä ne koskevat.

Joiltakin osin kyse on uhasta: kuka tarvitsee projektipäälliköitä, jos projektiryhmät pystyvät hallitsemaan itseään? Toisaalta kyse voi olla projektinhallinnan paratiisista. Monet projektipäälliköt haluavat olla strategisempia, lähempänä tuotetta ja asiakasta ja vähemmän tekemisen yksityiskohtien hallinnassa.

Onko siis löydettävissä tasapaino? Voisitko aloittaa kertomalla, miten itseohjautuvat ryhmät toimivat Railswarella ja Coupler.io-tiimissä?

Julia Ryzhkova: Vastaus liittyy kehittäjän tuotemielikuvaan.

Järjestimme tästä käsitteestä hiljattain erillisen webinaarin. Etsimme kokeneita, T-mallisia kehittäjiä. Tarkoitan ihmisiä, joilla on paljon erilaisia kokemuksia. He voivat työskennellä asiakkaan kanssa kehittäjänä, tuotteen kehityspäällikkönä ja projektipäällikkönä vähimmäistoimivan tuotteen aikana.

Olemme kehittäneet rekrytointiprosessiamme pitkään löytääksemme tällaisia ihmisiä, koska se ei tietenkään ole helppoa. Perehdytämme osaajat ensin sisäisiin tuotteisiimme. Ennen kuin kehittäjä siirtyy asiakkaan tuotteeseen, hän työskentelee jonkin aikaa sisäisen tuotteemme parissa, oppii toimintatapamme ja pystyy kehittämään tätä tuotemielikuvaa.

Sen jälkeen hän voi työskennellä asiakkaan kanssa kuin yhden hengen orkesteri. Sama pätee kuitenkin myös muihin rooleihin. Ei vain kehittäjiin, vaan jokaiseen Railswarianiin, kuten kutsumme toisiamme, täällä. Useimmilla meistä on johtamiskokemusta, ja jotkut ovat johtaneet omia yrityksiään. Tämä koskee henkilöstöhallintoa, suunnittelijoita, tuotepäälliköitä ja muita rooleja.

Kukaan meistä ei kuitenkaan ole tiimin suora esihenkilö. Auktoriteetti ansaitaan esimerkillä johtamisen periaatteen kautta. Johdat tuotetta ja osoitat siten tiimille, että olet johtamisen arvoinen. Et voi vain kertoa, mitä pitäisi tehdä. Teet parhaasi vaikuttaaksesi tuotteeseen ja kokonaistulokseen. Näin tiimi alkaa luottaa sinuun ja toimia samalla tavalla.

Galen Low: Pidän tästä todella paljon. Tiimin rakentaminen T-mallisten ihmisten ympärille, joilla on monipuolista kokemusta, on hieno ajatus. Haluaisin kuulla myöhemmin lisää rekrytoinnista ja perehdytyksestä.

Rekrytointiprosessi ei siis keskity vain teknisiin taitoihin, vaan myös johtamiskokemukseen ja siihen, ovatko ihmiset johtaneet omaa yritystään tai tiimejään. Kokemus on arvokasta ja tärkeää, vaikka rooli tiimissä onkin hyvin tasavertainen. Se on todella kiinnostavaa.

Kerroin aiemmin, että sinulla on projektinhallinnan tausta ja että johdit ennen PMO:ta. Tuntuiko itseohjautuvien tiimien ajatus koskaan vieraalta tai jopa hieman uhkaavalta?

Julia Ryzhkova: Kyllä, ja on hauskaa, että kysyit. Koin niin Railswaren koeajan aikana. Kun olet tiimin sankari ja ilman sinua kaikki karkaa käsistä, oman tarpeellisuuden arviointi on helppoa. Jokainen työpäiväsi osoittaa, että olet tärkeä.

Kun asiat toimivat hyvin ilman sinuakin, et enää tunne vaikutustasi samalla tavalla. Teet muutoksia, otat käyttöön uuden prosessin ja parannat toimintaa. Asiat muuttuvat, mutta vain vähän. Läsnäolosi parantaa asioita, mutta voit ottaa kahden viikon loman eikä mikään romahda. Silloin voi kysyä: miksi he tarvitsevat minua?

Jossakin vaiheessa kuitenkin lakkaat yrittämästä hallita kaikkea. Vapautuvan ajan avulla löydät uusia tapoja vaikuttaa. Keskityt tuotteeseen, asiakkaaseen ja strategiaan ja voit saada vielä suuremman vaikutuksen aikaan.

Kun annat tiimille enemmän tilaa, se voi luoda jotakin uskomatonta killassa. Meillä on ryhmä, jossa on neljä insinööriä ja yksi laadunvarmistaja. Lisäksi meillä on insinöörikilta, laadunvarmistuskilta ja tuotepäällikkökilta.

Tuotepäällikkökilta rakensi esimerkiksi alussa mainitsemani BRIDGeS-kehyksen. Tällaista on mahdotonta rakentaa, jos ihmisillä ei ole tilaa tehdä asioita, joita he kokevat tarpeellisiksi, ja kehittää toimintaa.

Galen Low: Pidän tästä. Jokaisella, jonka kanssa olen puhunut hyvistä tiimikokemuksista, parhaat projektit ovat olleet jollakin tavalla itsenäisten tai itseohjautuvien tiimien toteuttamia. Projektipäällikköä ei ole välttämättä poistettu, vaan tiimille on annettu riittävästi valtaa ottaa suunta ja edetä sen mukaan.

Projektipäälliköt kuvailevat usein mikromanageeraavia tehtäviä: kissojen paimentamista ja sen varmistamista, että asiat toimitetaan. Todellisuudessa kyse on ohjauksesta, suunnasta, tiimin inspiroimisesta ja sen valtuuttamisesta tekemään parhaansa.

Se ei tarkoita, ettemme enää tarvitse Juliaa. Voimme nostaa Julian tai projektipäällikön strategisempaan rooliin. Tiimi voi olla itsenäinen, ja projektipäällikkö voi pitää lomaa. Se on merkittävää.

Mietin rooliasi nyt. Et ole projektipäällikkö vaan tuotepäällikkö. Olet tavallaan orkesterin kapellimestari.

Julia Ryzhkova: Niin voi sanoa.

Galen Low: Käytätkö edelleen projektinhallintataitojasi? Oletko hyötynyt projektinhallinnan taustastasi tuotepäällikkönä?

Julia Ryzhkova: Kyllä. En voi kuvitella, että joku voisi olla tuotepäällikkö ilman projektinhallinnan taustaa. Se on olennaista. Tekninen tausta on hyödyllinen, mutta projektinhallintataidot ovat tuotepäällikölle ratkaisevia.

Railswaren taitomatriisissa kaikilla ylemmän tason rooleilla on projektinhallintataitoja. Viestintä on meille esimerkiksi tärkeää. Olemme havainneet nämä taidot hyödyllisiksi kokonaistuloksen kannalta.

Jos puhumme erityistaidoista, projektinhallinnan osa-alueista ovat edelleen mukana laajuus, kustannukset, aikataulu ja ehdottomasti sidosryhmien hallinta. Integraation ja viestinnän hallintaa teen tuskin lainkaan, koska se kuuluu itsehallintaan. Muuten sitä ei kutsuttaisi itsehallinnaksi.

Laatu kuuluu laadunvarmistajille ja insinööreille. Riskienhallinta jakautuu kaikille tiimin jäsenille, samoin hankinnat. Jos tarvitset jotakin työhön, teet hankintapyynnön ja perustelit, miksi tarvitset sen.

On hienoa, ettei minun tarvitse ymmärtää, miksi markkinointi tarvitsee tiettyä yhteydenottotyökalua tai kehitys tiettyä kirjastoa.

Galen Low: Pidän siitä, että kaikki ylemmän tason roolit sisältävät projektinhallintataitoja. Otamme joskus laajuuden, kustannukset, aikataulun ja sidosryhmien hallinnan itsestäänselvyyksinä, koska ne kuuluvat luonnostaan rooliin. Todellisuudessa ne ovat osa liiketoimintaa ja asioiden kestävää ja vastuullista toteuttamista.

Ovatko nämä taidot osa rekrytointiprosessia? Saako ylemmän tason rooliin tuleva projektinhallintakoulutusta?

Julia Ryzhkova: Kun puhun ylemmän tason rooleista, tarkoitan myös insinöörejä ja laadunvarmistajia, en vain toimistopäälliköitä. Kaikkien tuotteisiin ja projekteihin osallistuvien on pystyttävä hallitsemaan vähintään itsensä: oma laajuutensa, aikataulunsa, kustannuksensa ja hankintansa. Sitä odotamme ihmisiltä.

Emme kuitenkaan edellytä erillistä projektinhallintakoulutusta tai taustaa. Ihmiset tekevät jo monia näistä asioista huomaamattaan. Voimme vahvistaa heidän taitojaan, mutta emme opeta niitä alusta asti.

Galen Low: Pidän tästä. Digitaalisten tuotteiden ja projektien päälliköinä meidän on opittava paljon ympärillämme olevien tiimien työstä. Meidän pitäisi myös jakaa omaa osaamistamme heidän kanssaan: miten asiat saadaan tehdyiksi, miten itseämme hallitaan, miten yhteistyötä tehdään ja miten liiketoiminnan näkökulma ymmärretään.

Emme rakenna asioita vain huvin vuoksi. Rakennamme niitä käyttäjille ja asiakkaille, rajoitteiden puitteissa ja vastuullisesti. Pidän tästä paljon.

Keskitytään nyt siihen, miten kaikki toimii käytännössä. Jos organisaatio tai tiimi harkitsee tällaista mallia, mitä sen pitäisi ottaa huomioon?

Minusta näyttää siltä, että pienten itseohjautuvien tiimien ryhmät tarvitsevat paljon selkeästi määriteltyjä prosesseja ja perusteellisen perehdytyksen. Miten ryhmät viestivät ja pysyvät linjassa keskenään?

Julia Ryzhkova: Se on todennäköisesti osa kulttuuria. Kun Railswarella oli alussa vain kaksi perustajaa, he määrittelivät prosesseja ja hallitsivat niitä yksinkertaisina tehtävälistoina. Heillä oli jäsennelty lähestymistapa ja he dokumentoivat kaiken.

He etsivät pieniä yrityksiä varten ihmisiä, jotka jakoivat saman kulttuurin. Pienissä yrityksissä tämä ei ole tavallista. Yleensä prosesseja aletaan ajatella vasta, kun asiat hajoavat. Meillä prosessit otettiin käyttöön perustamisesta lähtien, ja siksi niistä tuli osa kulttuuria.

Meillä on hyvä perehdytysprosessi ja periaate "dokumentoi samalla kun etenet". Jokaisesta kokouksesta voidaan tehdä yhteinen dokumentti tai Figma-taulu. Kaikki kokoukseen osallistuvat tekevät muistiinpanoja ennen kokousta tai sen aikana, eivät vasta sen jälkeen.

Näin kahden viikon loman jälkeen voin avata muutaman dokumentin, lukea ne ja ymmärtää, mitä on tapahtunut ja missä olemme nyt ilman erillistä selostusta.

Tämä liittyy läpinäkyvään kulttuuriin. Viestintä tapahtuu julkisissa Slack-kanavissa. Niitä on yli 300, ja yksityisiä työkeskusteluja on hyvin vähän. Kaikki tuodaan julkisesti esiin, joten kuka tahansa voi lukea keskustelun ja vastata joskus nopeammin kuin henkilö, jolle kysymys alun perin esitettiin.

Galen Low: Se on hienoa. Monet ryhmät yrittävät hallita juuri tällaista asynkronista viestintää. Keskusteluihin voi palata myöhemmin, koska ne ovat kaikki tallessa.

Railsware vaikutti edistykselliseltä alusta lähtien. Yksinkertaiset tehtävälistat riittävät, kun asiat kirjataan jonnekin tavalla, jonka muut voivat ymmärtää.

Julia Ryzhkova: Ihailen tätä. Opetin aiemmin liiketoimintaprosessien koulutuksissa, että prosesseja tarvitaan jossakin vaiheessa, mutta ei välttämättä heti alussa. Jos yrityksessä on yksi ihminen, joka tietää, miten asiat tehdään, prosesseja ei välttämättä tarvita.

Railswaren historiaan tutustuttuani muutin mielipidettäni. Nyt sanon, että se pitäisi tehdä alusta lähtien. Se voi olla hyvin yksinkertaista, vaikka tarkistuslista. Se on tarpeen.

Kun teet jotakin henkilökohtaista, kuten etsit uutta työtä, luot listan yrityksistä ja seuraat, missä vaiheessa olet kunkin yrityksen prosessissa. Sinun on kirjattava seuraava askel. Se on tehtävälista, jota tarvitset, jotta toiminta pysyy hallittavana.

Galen Low: Pidän tästä. Haluaisin kysyä myös tiimin mittareista. Mitkä suorituskykymittarit ovat tässä mallissa tärkeimpiä, jotta tiedetään asioiden olevan oikealla tolalla?

Julia Ryzhkova: En seuraa suorituskykymittareita lainkaan. Seuraan sen sijaan tuotemittareita: kasvua, SaaS-mittareita, konversiota, liikevaihtoa ja niin edelleen.

Seuraan tiimin nopeutta, mutta en suorituskykymittarina. Tarvitsen sitä ennustaakseni, mitä voimme tehdä julkaisun aikana ja seuraavien kolmen kuukauden kuluessa. Nopeus auttaa aikataulun hallinnassa.

Kun toimitamme tuotantoon joka päivä tai vähintään kahden viikon välein, kahden viikon viivästyminen ei ole katastrofi. Tiimi voi saada enemmän tilaa. Ryhmät hallitsevat itse omaa suorituskykyään esimerkiksi työpariohjelmoinnilla, uusien työntekijöiden ristiintestauksella ja koodikatselmoinneilla.

He seuraavat omaa suoriutumistaan ja kertovat toisilleen selvästi, mitä pitäisi parantaa. Palautekulttuuri on korkealla tasolla. Uusi työntekijä saa palautetta kaikilta tiimin jäseniltä, ja kuka tahansa voi tuoda esiin suorituskykyyn tai laatuun liittyvän ongelman. Myös uusi työntekijä voi antaa palautetta prosesseistamme, yrityksestä tai minusta tuotepäällikkönä.

Vaihtoehtoja on lopulta kaksi: henkilö ei läpäise koeaikaa tai suoriutuu hyvin, jolloin suorituskykyä ei tarvitse enää tarkistaa.

Galen Low: Mielenkiintoista. Voiko tilanne muuttua joskus intensiiviseksi?

Julia Ryzhkova: Voi, mutta yleensä kaikki ovat samalla sivulla. Jos joku näkee ongelman, muutkin näkevät sen, ja käsittelemme palautteen yhdessä.

Galen Low: Se on siis juurtunut kulttuuriin ja siihen, miten rekrytoitte. Valitsette ihmisiä, jotka ajattelevat jo valmiiksi näin ja ovat valmiita keskustelemaan, kasvamaan tiiminä sekä antamaan ja vastaanottamaan palautetta.

Julia Ryzhkova: Kyllä. Tarkistamme tämän rekrytointiprosessissa. Käytämme siihen paljon aikaa ja resursseja.

Tuotepäällikköehdokkaalle varataan esimerkiksi kokonainen päivä. Ratkaisemme yhdessä ongelmaa kahdeksan tunnin ajan ja annamme palautetta nähdäksemme, miten ehdokas reagoi siihen. Se on yritykselle suuri investointi, koska yksi johtoryhmän jäsen ja yksi tuotepäällikkö käyttävät koko päivän tähän.

Ehdokas ei saa tarjousta ennen kuin hän on käyttänyt tähän prosessiin kokonaisen päivän. Tulokset ovat kuitenkin hyviä. Näemme, sopiiko henkilö kulttuuriimme, emmekä arvioi ainoastaan teknistä osaamista vaan myös sitä, miten palautetta annetaan ja vastaanotetaan sekä löytyykö yhteinen huumorintaju.

Galen Low: Se on hienoa, koska nykyisissä rekrytointikäytännöissä on paljon mielivaltaisia testejä. Se, että tuotepäällikkö ja johtoryhmän jäsen käyttävät päivän tai kaksi työskentelemällä ehdokkaan kanssa, osoittaa, että oikean henkilön ja kulttuurisen lisän löytämiseen todella sitoudutaan.

Julia Ryzhkova: Selitämme ehdokkaalle, että tämä on investointi myös hänen puoleltaan. Hän ei käytä kolmea kuukautta koeajalla huomatakseen, ettei yritys sovikaan hänelle. Emme tee tätä samalla tavalla kaikille rooleille. Yhteistyö voi kestää kaksi tai neljä tuntia roolista riippuen, mutta tarvitsemme aikaa tutustuaksemme toisiimme.

Galen Low: Se on järkevää. Mainitsit aiemmin, että jos toimitus siirtyy kahdella viikolla, kukaan ei välttämättä kuole. Tuotepäällikkönä hallitset kuitenkin tuotteen tiekarttaa ja teet asiakkaille lupauksia ominaisuuksista. Mitä tapahtuu, kun asiat muuttuvat?

Julia Ryzhkova: Todennäköisesti yllätyt, mutta oikeastaan mitään erityistä ei tapahdu. Voin poistaa tehtävän sprintistä tai tuoda siihen toisen tehtävän ja selittää miksi. Voin muuttaa työlistaa jopa sprintin keskellä. Jos kyse on vain yhdestä tai kahdesta tehtävästä, emme keskeytä sprinttiä.

Järjestämme suunnittelutapaamisen, keskustelemme tarvittavasta työstä, arvioimme sen ja synkronoimme tilanteen. Tiekarttaa en muuta kovin usein. Tarkistan sen yleensä kerran kuukaudessa uusien havaintojen ja mittareiden perusteella.

Tiimi tuntee tuotteen vision ja osallistuu strategiasynkronointeihin johtoryhmän kanssa. He voivat kertoa teknisestä näkökulmasta, pitääkö jotakin ajatella uudelleen tai prioriteetteja muuttaa.

Kun muutimme hinnoittelumallia, yksi insinööreistämme kertoi toisen järjestelmän muuttaneen omaa hinnoittelumalliaan. Nyt meidän hinnoittelumme eivät olleet yhteensopivia. Hän ehdotti rajojemme uudelleenarviointia. Keskustelimme hinnoittelumallista ja saimme arvokkaan näkemyksen insinööriltä. Se oli hienoa.

Tiimini hyväksyy muutokset. Ensimmäisten kuuden työkuukauteni aikana vaihdoin projektinhallintatyökalua kolme kertaa: Trellosta Codaan, Codasta Pivotal Trackeriin ja lopulta JIRAan. Tiimi kysyi vain, tarvitsemmeko apua tai riittääkö 15 minuutin koulutus uudesta työkalusta.

Galen Low: Se kuulostaa hämmästyttävältä. Projektinhallintaohjelmiston vaihtaminen on monille vaikeaa. Ihmiset takertuvat tutun työkalun vakauteen.

Se korostaa ajatusta tuotemielikuvasta myös tekniikan, suunnittelun ja markkinoinnin tasolla. Kun ihmisille selitetään, miksi hinnoittelumallia tai työkalua muutetaan ja miksi jokin ominaisuus on toista tärkeämpi, he ymmärtävät, mikä on asiakkaan, loppukäyttäjän tai tuotteen kokonaisedun mukaista.

Tuote on muutosta. Projekteissa ja projektinhallinnassa on joskus taipumus tavoitella vakaata täydellisyyttä, vaikka työn ydin on muutoksiin vastaaminen ja tulevaisuuteen katsominen.

Julia Ryzhkova: Yksi asia vielä. Muistin hiljattain keskustelun kehittäjän kanssa. Hän sanoi kokevansa vakautta siksi, että meillä on työlista seuraaville sprintteille. Hän ei kuitenkaan välitä, vaikka se muuttuisi kokonaan. Hän tietää, että meillä on suunnitelma ja visio.

JIRAssa meillä on neljä tulevaa sprinttiä täynnä tehtäviä. Kehittäjät eivät välitä tarkalleen siitä, mitä tehtävät ovat. He katsovat tiekarttaa ja tuntevat vision. Heidän tarvitsee tietää, että mekin tunnemme vision ja että kerromme korkealla tasolla, mitä teemme ensi vuonna ja seuraavina vuosina.

Tarkalla etenemistavalla ei ole yhtä suurta merkitystä. Tehtävät tarkennetaan juuri ennen sprintin alkua, mutta työlistan olemassaolo antaa vakautta ja turvallisuuden tunnetta.

Galen Low: Se on luottamusta läpinäkyvyyden kautta. Tiimille on kerrottu visio ja suunnitelma. Heidät on otettu mukaan, eikä heitä kohdella vain käsiparina. He ovat osa tuotetiimiä, joka ohjaa kokonaisuutta.

Olemme puhuneet työlistasta ja sprintin aikana tapahtuvista muutoksista. Toimiiko tämä mielestäsi vain ketterässä ohjelmistokehityksessä, vai voisivatko kaikenlaiset monialaiset tuoteryhmät käyttää samaa mallia?

Julia Ryzhkova: Ketteryys on välttämätöntä, mutta ketterän manifestin ketteryys ei tarkoita, että pitäisi rakentaa ohjelmistoja.

Kaikki ryhmämme käyttävät samankaltaisia lähestymistapoja. Markkinointi-, talous- ja operatiiviset ryhmät arvioivat työtä, tekevät tarkennuksia, hallitsevat tiekarttaa, käyttävät tarinapisteitä ja seuraavat nopeutta. Kaikki voivat hyödyntää tätä.

Galen Low: Tästä voisi tehdä kokonaan uuden podcast-jakson. Monet kuuntelijat toivovat markkinointitiiminsä työskentelevän ketterästi työlistojen ja sprinttien avulla. Kehitys on käynnissä, mutta ei-kehitys- ja ei-suunnittelutiimit vastustavat sitä joskus.

Ketteryyttä kannattaa kuitenkin kokeilla kaikissa organisaatioissa, koska kyse on ketteryydestä ja kyvystä reagoida muutoksiin. Siitä voi hyötyä mikä tahansa osasto tai tiimi.

Julia Ryzhkova: Esimerkiksi insinööritiimi työskentelee Scrumilla, samoin suunnittelutiimi. Markkinointi käyttää Kanbania, jolla on oma tiekarttansa ja taulunsa. Kaikki ovat kuitenkin ketteriä lähestymistapoja.

Galen Low: Juuri niin. Se on järkevää, koska toiminta on jatkuvaa ja operatiivista.

Siirrytään kiinnostavaan osuuteen. Projektipäälliköiden johtamia projekteja ja itseohjautuvia tiimejä verrataan usein toisiinsa, mutta kumpikaan malli ei ole täydellinen.

Jos joku harkitsee tähän malliin siirtymistä ja kuvittelee sen olevan helppo utopia, mitä ongelmia voi syntyä?

Julia Ryzhkova: Vaikea kysymys. Meillä on korkean tason ongelmia. Yksi ryhmä ei aina tiedä, mitä toisessa ryhmässä tapahtuu.

Meillä on esimerkiksi tuotteet Mailtrap ja Coupler.io. Coupler.io:n kehitystiimi rakensi paljon uusia ominaisuuksia, joita pieni markkinointitiimimme ei pystynyt tukemaan sisällöllä ja laskeutumissivuilla. Mailtrapissa tilanne oli päinvastainen.

Johto päätti siirtää osan Mailtrapin markkinointitiimistä Coupler.io:lle ja osan Coupler.io:n insinööritiimistä Mailtrapille. Tällaisia päätöksiä ei voi tehdä yhden ryhmän sisällä, koska se ei näe kokonaiskuvaa. Yritystason päätöksiä tarvitaan edelleen.

Galen Low: Se on ymmärrettävää. Tarvitaan ryhmän ulkopuolinen näkökulma, jotta resursseja voidaan kohdentaa uudelleen. Kuuluuko tämä yleensä sinun rooliisi vai operatiiviselle johdolle?

Julia Ryzhkova: Se on mielestäni johtoryhmän tehtävä. Tiedän oman tuotteeni tilanteen ja kerron strategiasynkronoinneissa, että kehitys on edellä ja tarvitsemme lisää markkinointiresursseja. Mailtrapin tuotepäällikkö tekee samoin, koska heidän markkinointinsa on kehitystä edellä.

Johtoryhmä ei osallistu mikromanageeraukseen. Kerran kuukaudessa he voivat tehdä tällaisia päätöksiä ilman yksityiskohtien kuormaa: vaihtakaa tiimejä.

Galen Low: Oliko muutos pysyvä vai jaettiinko ihmisiä väliaikaisesti kapasiteetin tasaamiseksi?

Julia Ryzhkova: Se on väliaikainen ratkaisu. Vaihtoehtoja on kaksi: rekrytoida uusia kehittäjiä ja markkinoinnin työntekijöitä tai vaihtaa tiimit takaisin.

Teemme tällä hetkellä näiden yhdistelmää. Olemme edelleen muutoksessa, mutta suhtaudumme siihen rauhallisesti. Jos tiimi hyväksyy kolmen työkalun vaihtamisen puolessa vuodessa, se hyväksyy myös siirtymisen toiseen tuotteeseen puoleksi vuodeksi tai vuodeksi.

Galen Low: Pohjimmiltaan kyse on ryhmien yhteensovittamisesta. Markkinointi ei saa valmistella ominaisuuksien markkinointia, jotka eivät valmistu, eikä kehitys tuottaa enemmän ominaisuuksia kuin markkinointi pystyy tukemaan.

Miten esimerkiksi Coupler.io:n markkinointi- ja kehitysryhmät viestivät keskenään?

Julia Ryzhkova: Se riippuu tilanteesta. Meillä on esittely, jossa kehitystiimi näyttää, mitä edellisessä iteraatiossa tehtiin ja mitä julkaistaan. Lisäksi meillä on viikoittainen synkronointi, jossa kerron, mitä työskentelemme ja mitä julkaistaan seuraavassa iteraatiossa.

Jos tarvitsemme uusia laskeutumissivuja tai julkaisutiedotteita, markkinointitiimi lisää ne omalle listalleen. Heillä on globaali tiekartta ja omat markkinointiprojektinsa.

Käytämme syötteiden hallintaprosessia. Kuka tahansa voi luoda syötteen toisen tiimin työlistalle, ja tarkistamme ne kerran viikossa. Jos ne eivät sovi visioon, ne siirretään odottamaan. Jos ne ovat tärkeitä, ne lisätään tiekartaan tai seuraavaan sprinttiin.

Markkinointi voi esimerkiksi ehdottaa verkkosivuston ulkoasun muuttamista tai laskeutumissivumallien parantamista. Kehitystiimi voi puolestaan pyytää sähköpostimallia sovellukseen. Näin tiimit pysyvät linjassa.

Galen Low: Emme ole puhuneet paljon maantieteestä ja aikavyöhykkeistä. Tiimin jäsenet ovat eri puolilla maailmaa. Onko hajautetussa työssä tehottomuutta, joka pitää kompensoida, vai onko se mielestäsi lähes merkityksetön asia?

Julia Ryzhkova: Sanoisin päinvastoin. Etätyö antaa mahdollisuuden käyttää enemmän aikaa ja olla tehokkaampi. Jos kehittäjä on Argentiinassa ja tuotepäällikkö Thaimaassa, yhteisen puhelun järjestäminen voi olla vaikeaa. Työaikatauluja on sovitettava yhteen.

Se on ehkä ainoa ongelma, jonka pystyn nimeämään. Yli 80 prosenttia tiimistämme työskentelee etänä, yli 15 maasta. Jaetut dokumentit ja julkiset kanavat auttavat organisoimaan työn hyvin.

Asynkronisen viestinnän ansiosta kansainvälisiä verkkokokouksia ei tarvitse suunnitella jatkuvasti.

Galen Low: Pidän tästä. Asynkroninen työ ei tarkoita, ettei koskaan tavata. Kokouksen voi silti järjestää, vaikka aikataulun pitäisi olla joustava. Se voi tarkoittaa myös työskentelyä tavallisten työaikojen ulkopuolella, mikä varmistaa, että kokous on todella tarpeellinen.

Etätyö ja kotoa työskentely eivät myöskään ole sama asia. Etätiimi voi työskennellä toimistossa. Dokumentointi ja läpinäkyvyyden kulttuuri vähentävät kokousten tarvetta ja jättävät viestinnästä jäljen, johon kaikki pääsevät käsiksi.

Onko projektinhallinta itseohjautuvissa tiimeissä jonkinlainen tabu? Vastustetaanko projektipäällikön ajatusta, koska tiimi ei tarvitse johtamista?

Julia Ryzhkova: En usko, että kyse on tabusta. Rakastamme kokeiluja, eikä mitään ole pakko tehdä. Kaikkien ei tarvitse käydä kattavaa projektinhallintakoulutusta. Jaamme tärkeää tietoa killan tapaamisissa osana osaamisen kehittämistä.

Operatiiviselle tiimille voi opettaa esimerkiksi arviointia, tarinapisteitä, Kanbania tai Scrumia. Jos joku kokee tarvitsevansa peruskurssin, hän voi käyttää koulutusbudjettia siihen. On kuitenkin tehokkaampaa jakaa tieto silloin, kun sitä tarvitaan.

Galen Low: Pidän tästä. Jaetaan osaamista ilman, että yritetään tehdä kaikista projektipäälliköitä tai insinöörejä. Keskitytään taitoihin, jotka auttavat työskentelemään yhdessä ja tuottamaan hyvää työtä.

Haluaisin päättää suureen kysymykseen. Olet ollut projektipäällikkö ja johtanut PMO:ta, mutta nyt voit toimia paljon strategisemmassa roolissa tuotepäällikkönä. Näetkö itseohjautuvat ryhmät projektinhallinnan tulevaisuutena yleisesti?

Julia Ryzhkova: Uskon niiden olevan menestyvien tuoteyritysten tulevaisuutta.

Itseohjautuvat tiimit antavat projektipäälliköille mahdollisuuden keskittyä strategiaan, tuotteeseen ja asiakkaaseen. Silloin voi vihdoin työskennellä tärkeiden mutta ei kiireellisten asioiden parissa.

Tiimi huolehtii kiireellisistä mutta ei tärkeistä asioista, jotka vievät projektipäälliköiltä yleensä paljon aikaa. Kaikkien ei kuitenkaan voi odottaa olevan itseohjautuvia heti valmistumisen jälkeen tai uran alussa.

Nuoret asiantuntijat tarvitsevat mentorointia, valmennusta ja aluksi suoraa, perinteistä johtamista. On myös ihmisiä, jotka eivät pysty asettamaan itselleen määräaikoja ja joiden tehokkuus kärsii ilman niitä. Tämä voi koskea jopa kokeneita teknisiä asiantuntijoita.

Klassiselle projektinhallinnalle on siis aina tilaa.

Uskon silti, että yrityksen tai tiimin, joka haluaa saavuttaa poikkeuksellisia tuotetuloksia, pitäisi päästä tilanteeseen, jossa itsehallinta korvaa suoran projektinhallinnan. Näin projektipäällikön aikaa vapautuu strategiaan ja prosessien yleiseen parantamiseen yksittäisten ongelmien korjaamisen sijaan.

Galen Low: Pidän tästä. Kiireellinen vastaan tärkeä on juuri se valitus, jonka kuulen projektipäälliköiltä, jotka työskentelevät perinteisessä roolissa. He tuntevat olevansa yksityiskohtien kuormittamia ja haluavat olla strategisempia.

Ratkaisu ovat tiimin ihmiset, kulttuuri ja prosessit, jotka valtuuttavat tiimin. Se ei tarkoita työpaikan menettämistä, vaan mahdollisuutta tehdä strategisempaa ja tärkeämpää työtä.

Julia Ryzhkova: Projektinhallinta on myös tärkeää työtä. Voin toimia vähemmän projektipäällikkönä kuin ennen, koska työskentelen itseohjautuvan tiimin kanssa. Muiden tiimien kohdalla projektipäällikön päätehtävä on saada asiat tehdyiksi ja varmistaa, että projekti valmistuu aikataulussa ja budjetissa.

Ilman itseohjautuvaa tiimiä tätä ei voi saavuttaa. Kun tiimi on itseohjautuva, asiat saadaan tehdyiksi ilman syvää osallistumista, ja voit keskittyä siihen, mitä pitäisi tehdä, sen sijaan että selvität, miten se tehdään.

Galen Low: Pidän siitä. Nostetaan katse ylemmäs ja toimitaan ennakoivasti.

Julia, nämä näkemykset ovat erittäin arvokkaita. Erityisesti tuotemielikuvan käsite jäi mieleeni. Se ei tarkoita vain tuotteen elinkaaren ja julkaisujen ymmärtämistä, vaan sopeutumiskykyä ja avoimuutta muutokselle.

Tuotetta ei enää luoda kerran ja jätetä muuttumattomaksi. Sitä ohjaavat loppukäyttäjät, asiakkaat ja markkinat, jotka muuttuvat jatkuvasti. Tuotemielikuva tarkoittaa kykyä vastata muutokseen, toimia ketterästi ja ymmärtää miksi asioita muutetaan.

Tiekartta muuttuu, työlista muuttuu, julkaisuaikataulu muuttuu ja projektinhallintatyökalut voivat vaihtua kolme kertaa vuodessa. Tämä on tuotemielikuva: itseohjautuvan tiimin on pystyttävä mukautumaan muutoksiin ja kehittämään tuotteita dynaamisesti.

Vielä yksi kysymys. Mitä neuvoja antaisit organisaatiolle, joka haluaa siirtyä pieniin itseohjautuviin tiimeihin?

Julia Ryzhkova: Älä vain yritä — tee se. Aloita yhdestä pienestä tiimistä. Älä yritä toteuttaa lähestymistapaa koko suuressa organisaatiossa kerralla.

Kokoa parhaat ihmiset, anna heille tarvittava päätösvalta ja varmista tulokset. Kun näet hyödyt, tee kaikkesi siirtääksesi lähestymistavan koko yritykseen. Menestys vaatii kokeilemista ja ihmisiä, jotka sopivat tähän malliin.

Galen Low: Hienoa. Julia, kiitos paljon, että liityit seuraamme. Keskustelu oli todella kiinnostava. Oli kiehtovaa kuulla, miten organisaationne on ratkaissut tämän haasteen, miten itseohjautuvat ryhmät toimivat ja miten ketterä prosessi toimii tuotteiden kehittämisessä tuotestudiossa.

Toivon, että kuuntelijamme saivat paljon ajateltavaa ja ideoita siihen, miten heidän tiiminsä voisivat siirtyä kohti itseohjautuvaa kulttuuria ilman taustalla olevaa uhkaa siitä, että projektipäälliköt katoaisivat tulevaisuudessa.

Haluaisimme sinut takaisin kertomaan, miten nämä asiat kehittyvät. Olisi myös hienoa kuulla lisää siitä, miten tekoäly tulee osaksi Coupler.io-tuotetta.

Julia Ryzhkova: Toivon, että pystyn jakamaan kanssasi kaikki nämä näkemykset.

Galen Low: Todella hienoa. Kiitos vielä kerran.

Julia Ryzhkova: Kiitos. Oli mukavaa keskustella ja jakaa ajatuksia. Nämä asiat inspiroivat minua paljon, ja toivon niiden inspiroivan muitakin kokeilemaan samaa ja nauttimaan tuloksista.

Galen Low: Mahtavaa. Kiitos vielä kerran.

Julia Ryzhkova: Kiitos.

Galen Low: Mitä mieltä olet? Ovatko itseohjautuvat tiimit tulevaisuuden toimintatapa, vai onko niillä rajoituksia, joiden vuoksi ne eivät sovi tietyille organisaatioille tai toimialoille?

Kerro meille tarina. Mikä on itseohjautuvin projektiryhmä, jonka kanssa olet työskennellyt, ja miten kaikki sujui? Entä mikä on ollut turhauttavin kokemuksesi tilanteessa, jossa olet joutunut paimentamaan kissoja strategisen työn tekemisen sijaan? Kerro ajatuksesi alla olevissa kommenteissa.

Jos haluat kehittää taitojasi strategisena projektijohtajana, liity yhteisöömme!

Siirry osoitteeseen thedigitalprojectmanager.com/membership saadaksesi käyttöoikeuden kannustavaan yhteisöön, joka jakaa tietoa, ratkaisee monimutkaisia haasteita ja muovaa ammattimme tulevaisuutta yhdessä.

Vankat mallipohjat ja kuukausittaiset koulutukset säästävät aikaa ja energiaa. Keskustelufoorumin vertaistuki, yhteisötapahtumat ja mastermind-ryhmät auttavat sinua urallasi digitaalisten projektien parissa. Yhteisömme jäsenenä yli tuhat ihmistä on tukenasi.

Jos pidit kuulemastasi, tilaa podcast ja pysy yhteydessä osoitteessa thedigitalprojectmanager.com

Kuulemisiin, ja kiitos kuuntelemisesta.