Projektin rajojen värittäminen (Maik Stettner EA Gamesilta)

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmistolla. Pyydämme anteeksi mahdollisia kirjoitusvirheitä, sillä botti ei ole sataprosenttisen tarkka.

Ben Aston

Tervetuloa DPM-podcastiin, jossa menemme teoriaa pidemmälle ja tarjoamme asiantuntevia projektipäällikön neuvoja parempien digitaalisten projektien johtamiseen. Kiitos, että kuuntelet. Olen Ben Aston, Digital Project Managerin perustaja. Ollaanpa rehellisiä: pystytkö toimittamaan projektisi budjetin mukaisesti? Entä aikataulussa? Pystytkö toimittamaan myös luvatun laajuuden? Etkö ole varma? Miten siis tiedät sen ja miten teet sen? Siitä tämän päivän podcastissa on oikeastaan kyse: projektinhallintakeinoista.

Ne ovat yksinkertaisesti niitä rajoja, joita piirrämme projektiemme ympärille, jotta ymmärrämme projektin parametrit: missä meidän pitäisi pysyä rajojen sisällä. Niiden avulla tiedämme myös, milloin projektimme ylittää nämä rajat.

Tämän jakson sponsorina on Resource Guru, resurssien aikataulutustyökalu, jota käyttävät esimerkiksi Applen, Ogilvyn, Deloitten ja Publicisin tiimit. DPM:n kuuntelijat saavat 20 % alennuksen tilinsä koko käyttöajaksi koodilla DPM2018.

Lue lisää Resource Gurusta

Tänään keskustelen Maik Stettnerin kanssa. Maik on äskettäin nimitetty EA Gamesin kehitysjohtajaksi, aiemmin hän työskenteli FCV:llä ja johti siellä tiimiä. Hän on myös yksi Digital Project Manager -koulun vakituisista DPM-asiantuntijoista. Kun johdat projektipäälliköiden tiimiä, yksi erityisen tärkeä asia ovat projektinhallintakeinot. Maikilla on niistä paljon kokemusta. Haluat todella tiimisi toimittavan projektit budjetin mukaisesti ja osuvan määräaikoihin ja virstanpylväisiin, sillä muuten asiat alkavat purkautua ja sinun täytyy puuttua niihin. Tänään puhumme siis siitä, miten voimme hallita projektejamme paremmin ja millaisia keinoja voimme ottaa käyttöön. Ensinnäkin ne auttavat meitä tietämään, että olemme oikealla kurssilla. Toiseksi ne antavat meille vaihtoehtoja, kun alamme poiketa kurssilta.

Toivottavasti tämä kuulostaa hyvältä. Maik, hei ja tervetuloa ohjelmaan.

Maik Stettner:

Hei Ben. Kiitos kutsusta.

Ben Aston:

Mukavaa saada sinut takaisin. Maik, kerro hieman… Olet siis siirtymässä tai vaihtamassa tehtävääsi FCV:ltä, jossa johdit projektipäälliköiden tiimiä, EA Gamesin kehitysjohtajaksi. Tiedätkö vielä, mitä se tarkoittaa?

Maik Stettner:

Selviän siitä pian. Painopiste on edelleen projektinhallinnassa. Siirtyminen toimistotaustasta pelialalle Electronic Artsille ei ole minulle täysin uutta, sillä olen urani aikana työskennellyt eri toimialoilla. Odotan innolla, että pääsen jälleen perehtymään siihen. Se on projektinhallinnan näkökulmasta melko monimutkaista, joten työ on haastavaa ja dynaamista. Todennäköisesti käytän siihen myös tätä koko projektinhallintakeinojen kokonaisuutta.

Ben Aston:

Hienoa. Kun ajattelet uuteen tehtävään siirtymistä ja uusien työkalujen ja työtapojen oppimista, oletko viime aikoina löytänyt tai käyttänyt jotain sellaista, jonka ajattelet: ”Kyllä, haluan ehdottomasti ottaa tämän mukaan uuteen tehtävääni”? Onko käytössäsi ollut uusia työkaluja tai lähestymistapoja?

Maik Stettner:

Minusta olen oppinut jokaisessa tehtävässäni uusia näkökulmia ja tapoja lähestyä ongelmia. Erityisesti ohjelmisto- tai digitaalisen projektinhallinnan parissa kohdataan samankaltaisia ongelmia, mutta niiden ratkaisemiseen voi olla vaihtoehtoisia tapoja. Se voi tapahtua esimerkiksi ongelmanseurantatyökaluilla, jotka kehittyvät jatkuvasti, tai työkaluilla, jotka tuottavat analytiikkaa, jota tarvitaan nopeiden päätösten tekemiseen. En usko, että voin nimetä yhtä tiettyä työkalua tavallisten tuttujen työkalujen lisäksi. On kuitenkin kiinnostavaa huomata, että monet ongelmat ovat hyvin samanlaisia riippumatta siitä, rakennatko sovellusta, työpöytäohjelmistoa, verkkosivustoa, peliä tai jotain muuta. Myös lähestymistavat niiden ratkaisemiseen ovat hyvin vertailukelpoisia.

Ben Aston:

Niin. Yksi kiinnostavista asioista, joita olen huomannut aloitettuani konsultointityön, on se, että vaikka luulet tietäväsi, miten asiat tehdään, esimerkiksi resursoinnissa, ja voit käyttää Resource Gurun kaltaista työkalua tai muita saatavilla olevia työkaluja, kuten Harvestin Forecastia, huomaatkin uuden työkalun pariin siirtyessäsi tai käyttäessäsi sitä toisen toimiston tavalla, että kyseessä on aivan eri asia. Sama työkaluja voidaan käyttää niin monella tavalla, mikä tekee tilanteesta joskus varsin hankalan.

Mutta se, mitä sanoit datasta ja analytiikasta, on erittäin tärkeää. Se johdattaa myös kirjoittamaasi projektinhallintakeinoja käsittelevään artikkeliin. Kun johdamme projektipäälliköiden tiimiä tai työskentelemme projektipäälliköiden kanssa, haluamme varmistaa, ettemme luota koko ajan vain intuitioomme tai siihen, tuntuuko jokin olevan oikealla kurssilla tai projekti sujuvan oikein. Data on todella kriittistä, eikö niin?

Maik Stettner:

Ehdottomasti. Projektipäälliköiden johtajana minulla ei aina ole yhtä yksityiskohtaista näkyvyyttä kuin projektin parissa työskentelevällä projektipäälliköllä. Olen siis melko riippuvainen siitä, että tarkastelen datapisteitä ja näen, miten budjetti kehittyy, millainen kulutusvauhti on ja niin edelleen. Sen perusteella voin yleensä tehdä päätöksiä yhteistyössä esimerkiksi projektipäälliköiden tai projektin parissa työskentelevän tiimin kanssa.

Ben Aston:

Nämä ovat siis pohjimmiltaan projektinhallintakeinojamme. Kun ajattelemme ohjelmahallintaa tai projektipäälliköiden tiimin johtamista, tarkastelemme tätä dataa. Nämä ovat niitä tuotoksia, joita tiimimme projektipäälliköt tuottavat. Kerro meille projektinhallintakeinoista. Miten määrittelisit tai ymmärtäisit ne? Ne ovat asioita, joiden avulla hallitsemme projektejamme, mutta mitä ne oikeastaan ovat tai voisivat olla?

Maik Stettner:

Termi voi kuulostaa hieman pelottavalta. Minulle projektinhallintakeinot tarkoittavat kaikkia niitä työkaluja, joita tarvitset saadaksesi oikean tiedon perusteltujen päätösten tekemistä varten. Niihin kuuluvat kaikki datapisteet, joita voit kerätä kustannuksia, aikaa, laajuutta ja muita asioita koskevien päätösten tekemiseksi. Ne liittyvät suoraan asiakasvuorovaikutukseen ja kaikkiin projektin aikana tehtäviin dynaamisiin päätöksiin: Onko tiimi riittävän suuri? Tarvitsenko jonkun muun? Olemmeko aikataulussa? Olemmeko budjetissa? Kyseessä on siis korkean tason viitekehys projektien hallintaan ja perusteltujen päätösten tekemiseen.

Ben Aston:

Mitkä asiakirjat ovat mielestäsi hyödyllisimpiä tähän? Tuotettavia asiakirjoja on valtava määrä. Jos pelkistämme asian olennaiseen, mitkä ovat mielestäsi hyödyllisimmät asiakirjat tai mitä sinä pidät hyödyllisimpänä projektipäällikkönä itse projektia johtaessasi ja ehkä ohjelmapäällikkönä tai toimitusjohtajana projektipäälliköiden tiimejä johtaessasi?

Maik Stettner:

Tavallisin asia, jota suosittelen kaikille, on rehellisen tilanneraportin laatiminen. Se on raportti projektista ja sisältää kaikki käynnissä olevan projektin olennaiset mittarit: projektin kokonaiskustannukset, jäljellä olevan budjetin, kulutusvauhdin, aiempien kuukausien saavutukset sekä korkean tason toimenpiteet, riskit, esteet ja päätökset. Aiemmissa projekteissa, joiden parissa olen työskennellyt, ja tiimien kanssa, joita olen johtanut, laadimme tilanneraportit yleensä viikoittain. Varmistimme myös, että asiakas näki ne aina. Näin asiakas pystyi tekemään päätöksiä avoimen tilannekuvan perusteella. Se on projektipäällikölle erittäin olennainen ja helppo työkalu.

Se toimii myös eräänlaisena itsehillintänä. Viikon alussa laaditaan tilanneraportti, tarkistetaan mittarit, budjetin tilanne ja paikka aikajanalla ja kootaan nämä korkean tason tiedot yhteen. Sen jälkeen raportti käydään läpi asiakkaan kanssa, esimerkiksi säännöllisissä kokouksissa, joiden ei usein tarvitse kestää puolta tuntia pidempään. Ne toimivat säännöllisinä tarkistuspisteinä ja auttavat rakentamaan suhdetta asiakkaaseen. Tapaamisten ei tarvitse olla etäkokouksia, vaan ne voidaan järjestää myös kasvotusten. Se on itse asiassa usein hyvä tapa luoda suhdetta asiakkaaseen. Näin rakennetaan luottamusta ja avoimuutta, jotta mahdollisuuksista, ongelmista ja esteistä voidaan keskustella säännöllisissä tapaamisissa.

Ben Aston:

Laaditte siis asiakirjat ja pidätte säännöllisiä tarkistustapaamisia asiakkaan kanssa. Tilannetapaamisissa tuotetaan tilanneraportit. Mitä muuta jaatte? On yksi asia yrittää hallita projektit sisäisesti, mutta toinen asia on jakaa data asiakkaalle. Mitkä ovat sinulle tilanneraporttien lisäksi perusasioita projektien hallinnassa ja ohjaamisessa asiakkaan kanssa?

Maik Stettner:

Yksi olennainen työkalu projektin kokonaisohjauksen säilyttämiseen on muutospyyntö tai oikeastaan muutospyyntöprosessi muutospyyntölomakkeineen. Aina kun määritelty laajuus muuttuu ja joudut esimerkiksi tekemään lisätyötä tai projektitiimi joutuu muuttamaan suuntaa aikatauluodotusten täyttämiseksi, asia pitäisi dokumentoida. Usein muutospyyntö on projekteissa kielletty termi, jota hieman pelätään käyttää, koska asiakkaan pelätään suuttuvan. Se on kuitenkin täysin normaali käytäntö.

Muutospyynnöllä ei välttämättä tarvitse olla mitään vaikutusta. Se voidaan tehdä vain dokumentointia varten, eikä se välttämättä vaikuta budjettiin tai aikatauluun. Se kannattaa silti dokumentoida ja totuttaa asiakas siihen, että muutospyyntöprosessi on olemassa. Jos projektissa tehdään myöhemmin päätös, joka vaikuttaa budjettiin, asia voidaan käsitellä perusteellisesti ja dokumentoida niin, että kaikki hyväksyvät ja allekirjoittavat muutospyynnön.

Ben Aston:

Puhut myös toisesta asiakirjasta eli toisesta projektinhallintakeinosta: RAID-lokista. Se on jälleen tärkeä projektin ohjauksen osa. Jos saisit valita vain yhden asiakirjan projektien hallintaan, mikä se olisi?

Maik Stettner:

Ensimmäinen asia on hyvä, vakaa tilanneraportti. RAID-loki menee yksityiskohtiin, joita et projektin monimutkaisuudesta riippuen ehkä tarvitse. Tilanneraportin pitäisi kuitenkin sisältää sen elementit. Jos sinulla on riskejä, esteitä tai muita vastaavia asioita, varmista, että tilanneraportissa on niille tilaa, jotta kaikki seuraavat niitä. Säännölliset asiakastapaamiset, keskeisten suorituskykymittareiden ja mittareiden näyttäminen asiakkaalle sekä nykyisen prosessin ja edistymisen läpikäynti ovat minulle tärkein mittari.

Ben Aston:

Kyse on siis eräänlaisesta tasapainosta siinä, kuinka paljon hallintaa voimme luoda dokumentaatiolla. Tämä liittyy jossain määrin ketteryyttä koskevaan keskusteluun ja siihen, miten jotkut ihmiset asian näkevät. Emme halua sitoa itseämme vaatimuksia tai hallintakeinoja koskevaan dokumentaatioon, koska se voi rajoittaa projektia. Miten löydät tasapainon, kun budjetin seuraamiseen, tilanneraportin päivittämiseen ja kokouksiin voi kulua koko aika? Kuinka paljon on liikaa ja kuinka paljon juuri riittävästi, jotta projekti pysyy hallinnassa ja asiakas ajan tasalla?

Maik Stettner:

Kun aloitan uuden projektin, lähestyn sitä oikeastaan melko itsekkäästi siinä mielessä, että aloitan projektin tilannepäivityksestä tai miksi sitä halutaankaan kutsua. Sen täytyy olla helppo tuottaa. Voin luultavasti käyttää olemassa olevia ohjelmistoja, kuten Resource Gurun kaltaista resursointiohjelmistoa, työajanseurantaohjelmistoa tai mitä tahansa yrityksen käyttämää työkalua. Näin saan perusmittarit koottua. Se voi olla jo riittävä lähtökohta. Jotkut asiakkaat saattavat tarvita enemmän ja odottaa yksityiskohtaisempaa tietoa. Projektipäällikölle sisäisten mittareiden seuraamiseen ja jotain asiakkaalle esitettävää varten tämä on kuitenkin erittäin hyvä aloitus. Tietojen kokoaminen säännöllisesti ei vie kovin paljon aikaa.

Et loppujen lopuksi halua luoda itsellesi liikaa työtä, sillä silloin saatat vain jättää sen tekemättä. Se voi unohtua kiireessä tai kun projekti vaatii kaiken huomiosi, jolloin taustaraportointi ei enää ole keskipisteessäsi.

Ben Aston:

Tuo on hyvä huomio: projektin hallintaan tarvitaan vain riittävästi tekemistä. Vielä tärkeämpää on ehkä se, kuinka säännöllisesti teemme sen. On hienoa laatia kaikkien aikojen tilanneraportti ja rakentaa mahtavat projektinhallintakeinot heti projektin alussa. Mallien laatiminen ja datan esitystavan päättäminen ovat ensimmäisiä asioita. Jos tietojen kokoaminen ja kaikkien laatimiesi projektinhallinta-asiakirjojen kohtien täyttäminen vie kuitenkin tunteja, se koituu kohtaloksesi. Asiakirjojen tuottaminen kestää liian kauan, et tee sitä etkä pysy projektiesi tasalla.

Maik Stettner:

Aivan. On myös muistettava, että asia toimii kahteen suuntaan. Projektipäällikön täytyy tietää, mitä tapahtuu, jotta hän voi tehdä perusteltuja päätöksiä. Asiakas haluaa tietää, mitä tapahtuu, mutta myös sisäisellä tiimillä on oikeus tietää. Projektipäällikkönä tehtäväsi on päättää, miten kerrot asiat tiimille. En usko, että olen koskaan käynyt tiimini kanssa läpi kuivaa tilanneraporttia. Olen aina löytänyt muita tapoja kertoa budjettirajoista, aikatauluista ja muista asioista. On kuitenkin tärkeää, että sinulla on riittävästi tietoa ja mittareita kaikkien pitämiseksi ajan tasalla, jotta kaikki työskentelevät saman projektin parissa.

Ben Aston:

Tuo on hyvä näkökulma. Tämä ei koske vain asiakkaita, vaan myös tiimejämme. Tiimien on ymmärrettävä projektien rajoitteet. Jos projekti käy kuumana ja meidän on yhdistettävä voimamme löytääksemme tehokkaamman tavan toimia, datan avulla voidaan sanoa: ”Meidän täytyy ehkä muuttaa suuntaa hieman. Emme ehkä pysty viimeistelemään asioita siinä laajuudessa kuin toivoimme. Kootaan siis voimamme ja sopeudutaan.”

Data ei tarkoita sitä, että projektipäällikkö olisi hankala ihminen. Se kertoo tiimille: ”Katsokaa, tämä on tilanneraportti ja sen mukaan kulutamme resursseja nopeasti. Käytimme jälleen liikaa aikaa käyttäjäkokemukseen ja suunnitteluun. Budjetti ei riitä laadunvarmistukseen kunnolla, jos emme saa tätä päätökseen.” Se on todella hyödyllistä.

Puhuit artikkelissasi projektinhallintakeinojen käyttöönotosta ja siitä, miten niitä käytetään projektien ohjaamiseen. Puhuit arvioinnista, suunnittelusta, reagoinnista ja yhteydenpidosta. Voisitko käydä tämän prosessin läpi ja kertoa, miten saat sen toimimaan?

Maik Stettner:

Totta kai. Projektipäällikön täytyy aina tietää, missä mennään, jotta hän voi tehdä perusteltuja päätöksiä. Nämä vaiheet perustuvat siihen. Ensin arvioidaan. On tiedettävä, missä projekti on, missä vaiheessa se on projektisuunnitelmassa, ollaanko matkalla kohti odotettua lopputulosta ja saavutetaanko tavoite. Kyse ei ole vain suorituskykymittareista. Projektipäällikön täytyy perehtyä yksityiskohtiin, esittää kysymyksiä ja ymmärtää, mitä tiimi tekee. Hänestä tulee korkean tason asiantuntija kaikkien niiden henkilöiden työstä, joiden kanssa hän työskentelee: käyttäjäkokemuksesta, suunnittelusta, kehityksestä ja laadunvarmistuksesta. Näin voi arvioida, voidaanko projektissa oikaista tietyissä kohdissa vai ei. Sen voi selvittää vain perehtymällä asiaan, keskustelemalla ihmisten kanssa ja ymmärtämällä yksityiskohdat. Sen jälkeen tehdään päätöksiä.

Toinen vaihe on suunnittelu. Usein asioita täytyy sovittaa yhteen ja muuttaa: aikataulu muuttuu, laajuus muuttuu ja niin edelleen. Seuraavat askeleet suunnitellaan tiimin kanssa käytettävissä olevan tiedon perusteella. Projektipäällikkö näkee molemmat puolet: asiakkaan näkökulman ja tiimin sisäisen tiedon. Näiden perusteella laaditaan kokonais­suunnitelma projektin viemiseksi maaliin.

Seuraava vaihe on reagointi. Suunnitelman mukaiset muutokset toteutetaan. Asiakkaalle kerrotaan asiasta, prosessia muutetaan tarvittaessa ja dokumentointi sekä ongelmanseurantajärjestelmät, kuten Jira, päivitetään. Myös aikatauluja päivitetään ja varmistetaan, että kaikki mukautukset on tehty.

Viimeinen vaihe on yhteydenpito. Projektipäällikkö on liima, joka pitää tiimin koossa. Ihannetapauksessa kaikkien pitäisi tietää korkean tason asiat, jotka sinä tiedät. Jaa siis tietosi tiimille, jotta kaikki näkevät kokonaisuuden. Asiakkaan ja tiimin täytyy pysyä ajan tasalla. Muutoksia on hallittava niin, että ne voidaan myös todella toteuttaa.

Ben Aston:

Kuulen tässä oikeastaan kaksi eri osa-aluetta. Projektinhallinnan näkökulmasta data on erittäin tärkeää. Datapisteiden avulla voimme arvioida projektien tilanteen. Korkean tason tiedot antavat meille nopeasti mahdollisuuden hallita projekteja: miten priorisoimme resursseja ja projekteja, jotta ne saadaan toimitettua? Data tarjoaa meille korkean tason näkymän.

Pidän kuitenkin siitä, mitä sanoit projektinhallintakeinojen muista puolista. Kyse ei ole vain datasta tai tiedon keräämisestä. Tarkoitus on aloittaa keskustelu ja ottaa tiimit mukaan projektiin liittyvään keskusteluun ja väittelyyn: mikä on paras tapa toimittaa asiat, miten projekteja voidaan toimittaa ketterämmin ja miten niitä voidaan mukauttaa työn edetessä. Emme vain lukitse asioita paikoilleen, laadi tilanneraporttia, huomaa budjetin ylittyneen ja jätä asiaa siihen. Pidän siitä, että teet tästä keskustelun.

Jos joku ei ole koskaan laatinut asianmukaisia tilanneraportteja asiakkailleen tai projekteilleen, mistä projektien hallintaan saaminen pitäisi aloittaa? Vaikka ei vielä päästäisi tilanneraportin tai projektinhallintakeinojen laatimiseen asti, mikä on ensimmäinen asia, jota projektipäälliköiden pitäisi ajatella, kun he yrittävät saada toimituksen järjestykseen ja projektit hallintaan? Onko sinulla suositeltavaa hyvää lähtökohtaa?

Maik Stettner:

Minulle tärkeintä on muodostaa hyvä kuva siitä, mitä tarvitaan toimituksen onnistumiseksi, sekä asiakkaan että sisäisen tiimin näkökulmasta. Osa tästä voi olla hyvin suoraviivaista logistiikkaa. Mitä asiakas odottaa? Onko olemassa ajureita? Onko projektin oltava valmis tiettynä päivänä esimerkiksi kampanjan tai johtoryhmän esityksen vuoksi? Lisäksi on muodostettava selkeä kuva tarvittavasta tiimistä ja sen työskentelystä. Korkealla tasolla täytyy ymmärtää, miten kaikki liittyy yhteen. Kokemuksen karttuessa tämä auttaa arvioimaan projektin suunnitelmaa ja prosessin keskeisiä tarkistuspisteitä.

Tilanneraportti auttaa ennen kaikkea pysymään itse oikealla kurssilla ja muistamaan tarkistuspisteet. Se on mielestäni olennaista. Kyse on suorituskykymittareiden, pehmeiden taitojen ja selkeän kokonaiskuvan yhdistelmästä. On ymmärrettävä tarkasti, missä mennään, vaikka projekti olisi monimutkainen, ja löydettävä työkalut, jotka auttavat tekemään perusteltuja päätöksiä.

Ben Aston:

Pidän siitä, mitä sanoit. Data ei tarkoita mitään, ellemme voi verrata sitä johonkin. Tilanneraportteja voi laatia, mutta jos meillä ei ole projektisuunnitelmaa, johon niitä verrataan, data on melko merkityksetöntä. On siis varmistettava, että meillä on kunnollinen suunnitelma, jota vasten voimme mitata etenemistä.

Olen keskustellut muiden toimistojen projektipäälliköiden kanssa ja huomannut, että usein työajanseuranta puuttuu. Eri tehtäviin käytettyä aikaa ei seurata tarkasti. Vaikka työajan kirjaaminen on yksi tuskallisimmista asioista, joita voi pyytää ihmistä tekemään, sen käyttöönotto on hyödyllistä, jos sitä ei vielä ole. Kun projektisuunnitelma on olemassa, aikaa voidaan verrata projektiin, mikä antaa projektin ympärille jonkin verran hallintaa. Se on todella hyvää neuvoa. Kiitos, Maik. Mukavaa, että olit kanssamme.

Maik Stettner:

Kiitos, Ben.

Ben Aston:

Yhtenä DPM-asiantuntijoistamme Maik esiintyy myös syyskuussa alkavalla kurssillamme. Sen nimi on Digitaalisen projektinhallinnan hallitseminen. Kyseessä on seitsemän viikon tiiviskurssi digitaalisesta projektinhallinnasta. Opit hallitsemaan digitaalisia ja monimutkaisia digitaalisia projekteja tehokkaasti. Kurssi sisältää videotunteja, tehtäviä, ryhmäkeskusteluja ja mahdollisuuden valmennustapaamisiin. Siirry siis osoitteeseen thedpmschool.com ja ilmoittaudu. Paikkoja on vielä muutama. Kurssi alkaa 10. syyskuuta.

Jos haluat osallistua projektinhallintakeinoja koskevaan keskusteluun ja kertoa, miten voisimme hallita projektejamme paremmin tai millaista dokumentaatiota käytät, siirry thedigitalprojectmanager.comin resurssiosioon ja liity Slack-tiimiimme. Siellä käydään monia kiinnostavia keskusteluja. Kommentoi siis artikkelia, keskustele aiheesta Slackissa ja selvitetään yhdessä, miten voimme hallita projektejamme paremmin.

Kiitos kuuntelemisesta seuraavaan kertaan asti.