Kuinka optimoida prosessisi työnkulunhallinnan avulla (Uniton Marc Boscherin kanssa)
Opi maksimoimaan tiimisi ajankäyttö luomalla ja optimoimalla työnkulkuja, jotka auttavat sujuvoittamaan projektiprosessejasi. Vinkkejä antaa Uniton perustaja ja toimitusjohtaja Marc Boscher.
Aiheeseen liittyvät linkit:
- Liity Digital Project Manager -yhteisöön
- Tilaa uutiskirje saadaksesi uusimmat artikkelimme ja podcastimme
- Tutustu Unitoon
- Etsi Marc LinkedInistä
- Seuraa Marcia Twitterissä
Aiheeseen liittyvät artikkelit ja podcastit:
- Tietoa The Digital Project Manager -podcastista
- 10 parasta projektisuunnittelutyökalua vuonna 2023
- 5 tapaa hyödyntää aikaasi yhtä tehokkaasti kuin Beyoncé
- Projektipäällikön opas 44 ketterään menetelmään
- 4 parasta tuottavuusvinkkiä, jotka opimme huippujohtajilta
- Kuinka rakentaa työnkulun hallintajärjestelmä (+esimerkkejä)
- Työnkulun suunnittelu: opi epäonnistuneesta yrityksestäni
Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmistolla. Annathan anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.
Ben Aston:
Käytätkö valtavasti aikaa tarvitsemasi tiedon etsimiseen? Olen varma, että käytät. Ja mikä pahempaa, kun johdat muita ihmisiä, on todella tuskallista nähdä tiimisi käyttävän tuntikausia tiedon etsimiseen. Todellisuudessa ei kuitenkaan ole olemassa yhtä kaikille sopivaa työnkulunhallintajärjestelmää. Käyttökokemus- ja strategiatiimisi saattaa pitää Trellosta tai Asanasta, mutta kehittäjät haluavat lähes varmasti käyttää JIRAa. Kuinka tätä kaaosta siis hallitaan? Kuinka päätetään, mikä työkalu voittaa? McKinseyn raportissa todettiin, että useimmat työntekijät käyttävät noin kahdeksan tuntia viikossa pelkästään tiedon etsimiseen.
Hyvä uutinen on, että ongelmaan on ratkaisu, ja se ratkaisu on työnkulunhallintajärjestelmä. Jos siis haluat säästää omaa ja tiimisi aikaa sekä budjettia, kuuntele tämänpäiväinen podcast. Puhumme työnkulunhallintajärjestelmän luomisesta ja optimoinnista. Kiitos, että kuuntelet. Nimeni on Ben Aston. Olen digitaalinen projektipäällikkö ja thedigitalprojectmanager.com-sivuston perustaja. Tehtävämme on auttaa digitaalisia projektipäälliköitä toimittamaan parempia tuloksia ja auttaa digitaalisessa maailmassa projekteja johtavia ihmisiä menestymään.
Jos siis haluat liittyä yhteisöömme, mene osoitteeseen the digital project manager piste com. Sieltä löydät paljon resursseja, joiden avulla voit kehittää taitojasi, kasvattaa itseluottamustasi ja toimittaa parempia projekteja. Tänään seurassani on Marc Boscher. Marc on verkkokehittäjästä tuotepuolen asiantuntijaksi siirtynyt henkilö, joka on nyt Uniton toimitusjohtaja ja perustaja. Marc, tervetuloa podcastiin.
Marc Boscher:
Kiitos kutsusta.
Ben Aston:
Kerro hieman tarinastasi. Kuinka siirryt verkkokehittäjästä projektipäälliköksi, sitten tuotepuolen asiantuntijaksi ja lopulta oman yrityksesi perustajaksi? Kerro hieman tästä kehityksestä.
Marc Boscher:
Siihen kului muutama vuosi. Aloitin teknologiakuplan aikana, ja asiat etenivät nopeasti. Teknologia veti minut tuotepuolelle, ja olen työskennellyt tuotteiden parissa käytännössä 20 vuotta. Tuotetyössä on hienoa se, että huomaat jatkuvasti ongelmia ja ajattelet: jonkun pitäisi ratkaista tämä. Silti et koskaan oikeastaan tartu niihin. Pidin kuitenkin listaa, ja Unito sai alkunsa yhdestä ongelmasta, jonka näin jatkuvasti.
Ben Aston:
Olet siis työskennellyt tuotteiden parissa 20 vuotta, mutta Unito on suhteellisen uusi tuote. Mistä juuri tämän ongelman ratkaisemiseen liittyvä inspiraatio syntyi?
Marc Boscher:
Tuote- ja jossain määrin myös projektinhallinnassa on työskenneltävä monien eri tiimien, ryhmien ja osaamisalueiden kanssa, eikä sinulla yleensä ole valtaa. Et ole heidän pomonsa, joten sinun on johdettava vaikuttamisen kautta. Et siis voi päättää, mitä työkaluja he käyttävät. Olet usein niiden työkalujen yhdistelmän varassa, joita kunkin tiimin jäsenet käyttävät. Huomasin jatkuvasti hyppiväni Zendeskistä Asanaan, JIRAan, GitHubiin ja muihin työkaluihin sekä maksavani siitä hinnan. Silloin ajattelin jälleen, että jonkun pitäisi ratkaista tämä.
Yleensä ongelma ratkaistaan pakottamalla kaikki käyttämään samaa työkalua. Kun rajapintojen käyttö alkoi kehittyä, ajatus oli kuitenkin seuraava: voisimmeko yhdistää nämä työkalut? Voisivatko ihmiset pysyä omissa työkaluissaan ilman, että projektipäälliköt tuhlaavat aikaansa kiertämällä kysymässä, ovatko ihmiset saaneet työnsä valmiiksi ja missä vaiheessa he ovat, tai kertomassa heille, että joku on myöhässä ja että tämä vaikuttaa heihin? Idea kasvoi siitä, että ratkaisimme oman ongelmamme. Uniton perustaminen oli aina suunnitelmissa, joten päätimme hypätä mukaan, kokeilla ja katsoa, saisimmeko aikaan vetovoimaa. Tässä sitä nyt ollaan.
Ben Aston:
Hienoa. Kerro hieman siitä, miten käytät työkalujasi ja mitä työkaluja yhdistät. Tiedän, että voit yhdistää projektinhallintatyökaluja ja projektinhallintaohjelmistoja, kuten Trellon, Asanan ja JIRAn. Mitkä työkalut sinä yhdistät ja miten se toimii?
Marc Boscher:
Olen itse työkaluharrastaja, joten käytän lähes kaikkia niitä. On todella innostavaa löytää suunnitteluratkaisu, joka sopii ajattelutapaasi ja rooliisi. Tuottavuutesi kasvaa huomattavasti, mutta usein todellinen este on muiden vakuuttaminen vaihtamaan kyseiseen työkaluun.
Uskon, että teknologian käyttöönoton esteet liittyvät nykyään vähemmän teknisiin asioihin, kuten ohjelmiston asentamiseen ja käyttöönottoon. Paljon tärkeämpää on saada ihmiset käyttämään sitä. Meillä on tällä hetkellä noin tusina työkalua. Julkaisimme ClickUp-integraation pari viikkoa sitten, ensi viikolla julkaisemme jälleen uuden ja kolmen tai neljän viikon kuluttua vielä yhden. Rakennamme työkaluja projektityönhallinnan alueelle: Asanaa, Wrikea ja Trelloa varten. Aloitimme myös kehittäjätyökaluista.
GitHub, Bitbucket, GitLab ja JIRA auttavat yhdistämään projektipäälliköt teknisiin tiimeihin tai liiketoimintakäyttäjät teknisiin tiimeihin, jotka eivät yleensä puhu samaa kieltä eivätkä varsinkaan samaa työkalukieltä. Ajan mittaan olemme lisänneet Zendeskin tukijärjestelmiä sekä HubSpotin myynnin, asiakkuudenhallinnan ja markkinoinnin puolelta. Kysymys on siitä, kuinka työtä tarkastellaan: ei vain yhden tiimin sisäisenä asiana tai yhden tiimin prosessina, vaan koko organisaation läpi kulkevana työnä. Tämä on paljon suurempi ja tärkeämpi ongelma, johon käytetään ja hukataan valtavasti aikaa .
Ben Aston:
Olet siis työkaluharrastaja. Oletko viime aikoina löytänyt uusia työkaluja, jotka ovat innostaneet sinua ja joita kaikkien pitäisi mielestäsi käyttää?
Marc Boscher:
Kaikki integroimamme työkalut ovat markkinoiden parhaimmistoa. Haluamme kuitenkin ajatella, ettei ole olemassa yhtä parasta työkalua kaikille. Se riippuu siitä, mitä yrität saavuttaa, kuka olet ja miten työskentelet. Tämä on keskeinen uskomuksemme. En suosittele yhtä työkalua toisen sijaan, vaan kaikki riippuu tilanteesta. Liiketoimintamme perusajatus on, että jokaisella on oma työkalunsa, joka tekee hänestä mahdollisimman tuottavan. Haaste on siinä, ettei sama työkalu sovi kaikille. Uusia työkaluja tulee jatkuvasti. Valitsemme yleensä suosituimpia, kasvavia ja nousevia työkaluja. Niissä on oltava myös rajapinta, jotta ne voidaan integroida, mutta useimmissa nykyisissä työkaluissa tämä ominaisuus on jo olemassa.
Ben Aston:
Marc on kirjoittanut thedigitalprojectmanager.com-sivustolle artikkelin, jonka nimi on Kuinka rakentaa työnkulunhallintajärjestelmä. Siinä on myös esimerkkejä. Voitko selittää tarkemmin, mitä tarkoitat työnkulunhallinnalla? Projektipäällikköinä ymmärrämme prosessit: kuinka jokin viedään pisteestä A pisteeseen B. A on projektin alku ja B sen loppu, ja niiden välillä on erilaisia vaiheita.
Matkalla pisteestä A pisteeseen B tuotamme arvoa. Mitä työnkulunhallinta siis tarkoittaa, ja kuinka se liittyy tähän pisteestä A pisteeseen B etenemiseen projektin rajoitteiden puitteissa niin, että voimme luoda arvoa matkan lopussa?
Marc Boscher:
Se on hyvin samanlaista kuin prosessi, johon olemme tottuneet. Ihmiset käyttävät usein työnkulkuja ja prosesseja toistensa synonyymeina. Ajattelemme prosessien olevan melko lineaarisia, vaihe vaiheelta eteneviä kokonaisuuksia. Kun suunnittelemme projekteja, aloitamme usein näin: ensin tehdään tämä, sitten tämä ja lopuksi tuo. Sitten todellisuus astuu kuvaan.
Kun ihmiset alkavat työskennellä, huomaat uusia asioita. Tiimien välillä on tehtävä yhteistyötä ja jonkun muun on osallistuttava. Digitaalisessa työssä ympäristö on nykyään hyvin dynaaminen. Se ei ole yhtä lineaarinen tai tarkkarajainen, vaan paljon vähemmän ennakoitava. Kun puhumme prosesseista, voimme ajatella ohjelmistokehitysprosessia, markkinointikampanjan hallintaprosessia, tuotteen julkaisemista tai myyntiprosessia. Jokaisen tiimin on määriteltävä omansa, ja tähän on olemassa paljon viitekehyksiä.
Kun yhteistyö ylittää tiimien rajat, toiminta perustuu kuitenkin enemmän kokouksiin, Zoom-puheluihin ja nykyään keskusteluihin kuin työkalujen käyttämiseen työn ja toimituksen hallinnassa. Työnkulunhallinnassa tarkastelemme kerrosta, joka yhdistää kaikki nämä prosessit. Se yhdistää kokonaisuuden ja varmistaa, että asiat toimivat yhteen.
Ben Aston:
Jos työnkulunhallintajärjestelmä ottaa huomioon esimerkiksi tilanteen ”jos tämä tapahtuu, niin tee tuo”, prosessi ei todellisuudessa ole suora viiva pisteestä A pisteeseen B. Se on yleensä sarja silmukoita ja siirtymiä suunnasta toiseen. Tarvitsemme siis tavan hallita näitä tapahtumia. Mitä tapahtuu, kun esitämme käyttöliittymäsuunnitelman asiakkaalle ja kehitämme samalla tyyliruudukkoa?
Entä jos käyttöliittymä hyväksytään mutta tyyliruudukkoa ei? Kuinka palaamme takaisin ja pidämme projektin liikkeessä? Kuinka varmistamme, että oikeat ihmiset ovat yhteydessä ja ajan tasalla, jotta kehitys voi alkaa, vaikka suunnittelun iteraatiot eivät voisi edetä? Monimutkaisempi ja vivahteikkaampi ymmärrys voi auttaa meitä toimittamaan projektit tehokkaammin. Meidän ei enää tarvitse ajatella projektia puhtaasti lineaarisena prosessina, vaan sarjana pieniä jaksoja, jotka vähitellen integroituvat toisiinsa.
Meillä on rinnakkaisia työvirtoja käyttöliittymäsuunnittelua, kehitystä ja laadunvarmistusta varten. Ne voivat toimia sujuvammin ja tehokkaammin, kun yhdistämme ne tiiviimmin. Onko tämä työnkulunhallinnan perusajatus?
Marc Boscher:
Kyllä. Siinä hyödynnetään ketterän kehityksen periaatteita: kaikkea ei pidä yrittää hallita, vaan ihmisille on annettava enemmän vapautta tehdä yhteistyötä, yhteistyön esteet on poistettava ja työtä on tehtävä lyhyissä jaksoissa. Nykyiset työkalut kuitenkin usein vaikeuttavat tätä, koska kaikilla on eri työkalu ja erilainen prosessi. Työnkulunhallinnan ensimmäinen vaihe on mennä sinne, missä työ tapahtuu – hyväksyä, että ihmiset työskentelevät eri paikoissa – ja mennä heidän luokseen.
Integroi siis työkalut, joissa työ tapahtuu. Toinen vaihe on työnkulun kartoittaminen näiden työkalujen välillä. Muotoillaan työn virta: mitkä ovat säännöt ja ohjeet? Näin markkinointi toimii tuotekehityksen kanssa. Kun ominaisuus syntyy, tarvitseeko suunnittelijoiden osallistua, vai tarvitaanko mukaan tuotepäälliköt ja kehittäjät? Tarkoitus ei ole rajoittaa ihmisiä, vaan avata heille tapoja tehdä yhteistyötä omista työkaluistaan poistumatta.
Näin heidän ei tarvitse kiertää kysymässä tilannepäivityksiä. Yksinkertainen esimerkki voisi olla projektisuunnitelma Gantt-kaaviona Wriken, Asanan tai muun aikajanan sisältävän työkalun avulla. Yksi tehtävistä on kehittäjien vastuulla. Tehtävästä tulee automaattisesti JIRA-tehtävä, mutta se pysyy synkronoituna JIRA-tehtävän kanssa. Kun joku osoitetaan tehtävälle, työ alkaa tai tehtävä lisätään sprinttiin, projektipäällikkö näkee kehityksen etenemisen omassa työkalussaan.
Marc Boscher:
Projektipäällikkö näkee myös riippuvuudet muihin osastoihin, tiimeihin ja tehtäviin ilman, että hänen täytyy hypellä työkalusta toiseen. Aloita siis tunnistamalla, missä työ tapahtuu. Yhdistä työkalut ja määrittele säännöt: jos tässä projektissa tapahtuu jotain, haluan nähdä sen esimerkiksi projektisuunnitelmassani. Kun tämä on tehty, ihmisten ei tarvitse luopua omista työkaluistaan. Kaikki tieto on saatavilla siellä, missä ihmiset työskentelevät. Yhtäkkiä yhteistyö on rikkaampaa ja kitkaa on vähemmän. Silloin optimointi ja parantaminen voivat alkaa.
Ben Aston:
Puhut siitä, että eri tiimit haluavat työskennellä eri työkaluilla. Suunnittelu- ja käyttökokemustiimi ei todennäköisesti halua työskennellä JIRAssa, koska se voi olla monimutkainen. Unito mahdollistaa sen, että ihmiset voivat käyttää juuri sitä työkalua, joka sopii heille parhaiten. Työkalujen käyttöönotossa yritetään jatkuvasti löytää yksi työkalu, joka hallitsisi kaikkea.
Todellisuudessa jokaisella työkalulla on oma näkemyksensä projektinhallinnasta ja siitä, kuinka projekteja pitäisi johtaa. Tämä tekee yhteistyöstä organisaation eri tiimien välillä joko vaikeaa tai helppoa. Olen yrittänyt saada suunnittelutiimejä työskentelemään JIRAssa, eikä se yksinkertaisesti toimi. Erityisen hankalaa siitä tulee, kun JIRAan rakennetaan monimutkainen työnkulku.
Kuinka prosessi siis puretaan ja kuinka päätetään, kuinka monimutkainen työnkulunhallintajärjestelmän tulisi olla? Kerro työnkulun suunnitteluprosessista. Tiedämme, että käyttöliittymä- ja suunnittelutyö tapahtuu ja kehityksen on alettava. Kuinka tarkistukset ja tasapainot rakennetaan ja kuinka asioita automatisoidaan tekemättä kokonaisuudesta liian monimutkaista? JIRAn kanssa ongelmana on joskus se, että suunnittelet työnkulun ja jäät sitten sen vangiksi.
Kun rakennat työnkulunhallintajärjestelmää ja automatisoit esimerkiksi sen, että Trelloon luotu tehtävä luo automaattisesti uuden tehtävän toiseen järjestelmään, kuinka monimutkainen on liian monimutkainen? Mistä aloitat?
Marc Boscher:
Tavoitteemme oli alusta asti, että liiketoimintakäyttäjät voisivat määrittää järjestelmän itse. Myös ei-teknisten ihmisten pitää pystyä tekemään se. Tämä on ratkaisevan tärkeää, koska kahden tiimin yhdistämiseksi ei pitäisi tarvita teknisiä taitoja tai kehittäjän odottamista integraation rakentamiseksi. Kaikki perustuu visuaaliseen suunnitteluun ja sääntöjen määrittelyyn luonnollisella kielellä.
Määritellään esimerkiksi: kun tämä tapahtuu, varmista, että tieto päätyy suunnittelutiimille. Samalla on tärkeää kartoittaa prosessit, sillä toinen prosessi voi olla paljon yksityiskohtaisempi kuin toinen. Ohjelmistokehityksessä voi olla laadunvarmistus, vertaisarviointi ja vaiheistus. Kaikki nämä yksittäiset vaiheet voidaan haluta seurata ohjelmistokehitysprosessissa.
Markkinoinnin näkökulmasta voidaan kuitenkin vain tarkastella, onko ominaisuus valmis julkaistavaksi ja kuinka lähellä julkaisua ollaan. Markkinointia ei kiinnosta sama yksityiskohtien taso. Työnkulunhallintajärjestelmän on mahdollistettava se, että markkinointi määrittelee oman prosessinsa ja työnkulkunsa sekä sen, kuinka nämä vaiheet vastaavat teknisen tiimin vaiheita. Niiden ei tarvitse olla yksi yhteen. Kehitystiimin kymmenen yksityiskohtaista vaihetta voi markkinoinnissa tarkoittaa vain sitä, että ominaisuus on kehityksessä.
Kaikki alkaa keskustelusta: kuinka te työskentelette, kuinka me työskentelemme ja kuinka yhdistämme nämä toimintatavat? Tämän jälkeen liiketoimintakäyttäjille annetaan joustavuutta suhteen määrittelyyn ja sen kehittämiseen. Kaikkea ei tarvitse ratkaista kerralla. Voit aloittaa yksinkertaisista säännöistä: kun osoitan tehtävän Benille, sen pitäisi näkyä hänen työkalussaan. Tai kun eskaloin tukipyynnön tekniselle tiimille, sen pitäisi näkyä JIRA-projektissa. Kun näet tiedon virtaavan ja ymmärrät, kuinka ihmiset toimivat, voit siirtyä kehittyneempiin ja enemmän aikaa säästäviin ratkaisuihin.
Ben Aston:
Näen taustallasi jonkinlaisen työnkulun. Tuo näyttää prosessikartalta.
Marc Boscher:
Se on oikeastaan jäänne menneisyydestä. Se on seinälle kiinnitetty asiakaspolku, joka on piirretty lapuilla ja muulla vastaavalla. Sitä ei enää ole. Se on tapetti. Olemme kaikki etätyössä.
Ben Aston:
Kun eri tiimejä yritetään yhdistää, ihmiset työskentelevät eri työkaluilla ja on ymmärrettävä, kuka tarvitsee mitä, milloin ja missä muodossa. Tämä muistuttaa viestintäsuunnitelman laatimista: mitä minun pitää kertoa sinulle, missä muodossa, milloin ja kuinka usein? Kun rakennat tätä kokonaisuutta ja helpotat keskustelua, suunnitteletko kaiken suoraan työkaluun vai hahmotteletko ensin kokonaisuuden valkotaululle?
Marc Boscher:
Näimme asiakkaiden piirtävän prosesseja ja käyttävän valkotauluja. Rakensimme siksi toiminnon suoraan työkaluun. Sen avulla voi kartoittaa visuaalisesti, missä työ tapahtuu, ohjata työn virtausta ja muotoilla sen, kuinka työ siirtyy tiimiltä toiselle.
Kuvaamasi keskustelu on erittäin tärkeä. Asiakkaat tuntevat yleensä oman tiiminsä prosessin hyvin. He ovat selvittäneet sen, ja aiheesta on paljon dokumentaatiota. Kun keskustelu ylittää heidän tiiminsä rajat, he eivät kuitenkaan tiedä juuri mitään siitä, kuinka muut työskentelevät. Projektipäälliköt tietävät tämän parhaiten, koska he toimivat jatkuvasti näillä rajapinnoilla.
Sen sijaan että projektipäälliköt käyttäisivät aikansa tulkkaamiseen, siltojen rakentamiseen, tietojen kopioimiseen ja toistamiseen, työkalut voisivat lakata olemasta esteitä. Viestintä voisi kulkea suoraan, ja projektipäälliköt voisivat keskittyä siihen, missä he ovat parhaimmillaan: ihmisten yhteensovittamiseen, riskien seuraamiseen ja vähentämiseen sekä prioriteettien asettamiseen. Kaikkien ajan tasalla pitäminen ei ole työn arvokkain osa, mutta siihen käytämme valitettavasti paljon aikaa.
Ben Aston:
Suuri osa budjetin ja ajan hallinnasta voi kulua sen varmistamiseen, että ihmiset tietävät asiat, jotka heidän pitäisi tietää, lukevat oikeaan paikkaan saapuneen tehtävän tai näkevät Trellossa tehdyn päivityksen. Kaikki työskentelevät eri tavalla, joten on järkevää mahdollistaa tämä. Jos haluat käyttää Trelloa, käytetään Trelloa. Jos haluat asian JIRA-tehtävänä, toteutetaan se niin. Ihmisten mahdollisuus työskennellä itselleen sopivalla tavalla on tulevaisuutta.
Puhutaan kuitenkin epäonnistumisista. Mitkä ovat tällaisen järjestelmän haasteet? Työnkulusta voi tulla ratkaisu kaikkiin ongelmiin, mutta sen jälkeen asioita tapahtuu monissa paikoissa ja osa asioista voi edelleen pudota halkeamien väliin. Ovatko haasteet siis liiallista riippuvuutta työkaluista? Mitä haasteita olet nähnyt työnkulunhallintajärjestelmissä?
Marc Boscher:
Viestintä on aina ratkaisevan tärkeää, riippumatta siitä, onko käytössä järjestelmää kahden tiimin yhdistämiseen. Kun viestintää helpotetaan, ihmiset voivat käyttää päivittäin käyttämiään työkaluja viestimiseen, yhteistyöhön ja niiden ihmisten päivittämiseen, jotka eivät käytä samaa työkalua. Viestinnän vaatimus ei katoa, mutta siitä tulee helpompaa. Ajattele orkesteria.
Siinä on useita muusikoita, joilla jokaisella on oma soittimensa tai työkalunsa. Viulut ovat Trellossa ja piano JIRAssa. Kapellimestari, tässä tapauksessa usein projektipäällikkö, yrittää pitää kaikki synkronoituna ja samassa rytmissä. Muusikoita ei kuitenkaan pakoteta vaihtamaan samaan soittimeen. Jokaisen vahvuus on juuri oma soitin.
Kapellimestarilla on rajalliset työkalut. Hän yrittää vain ohjata orkesteria prosessin läpi. Muusikot ovat itsenäisiä ja jokaisen on päästävä perille omalla tavallaan, samalla kun he soittavat yhdessä. Nykyaikainen digitaalinen projektinhallinta muistuttaa tätä. Johdat ryhmää, joka toimii itsenäisesti ja osaa käyttää omaa työkaluaan.
Tärkeintä on tuoda kaikki yhteen ja pitää heidät harmoniassa. Ensin on varmistettava, että kaikki näkevät kapellimestarin ja toisensa. Nykyään kaikki ovat omissa pienissä laatikoissaan, ja etätyömaailmassa tilanne on vielä vaikeampi. Orkesteri on hajallaan ympäri maailmaa, yhteyksissä on viivettä ja aikavyöhykkeet vaikeuttavat harmoniaa. Työnkulunhallintaratkaisua voi ajatella kaikkien näiden ihmisten yhteensovittamisena ilman, että heidän työskentelytapaansa tarvitsee muuttaa eri aikavyöhykkeillä ja eri työkaluissa.
Ben Aston:
Kuinka näet tämän kehittyvän, kun tarkastelet työn ja projektien tulevaisuutta sekä omaa työkaluanne? Kuinka projektipäällikön rooli muuttuu?
Marc Boscher:
Toivottavasti projektipäälliköt käyttävät vähemmän aikaa rutiinityöhön ja enemmän aikaa orkesterin johtamiseen. Uskomme, että työkalujen määrän kasvu jatkuu, koska ohjelmistojen rakentaminen on halpaa, niiden jakelu helppoa ja ihmiset omaksuvat niitä nopeasti. Meidän on mentävä sinne, missä ihmiset työskentelevät, ja hyväksyttävä tämä todellisuus sen sijaan, että taistelisimme sitä vastaan.
Kun ihmiset ja tiimit voivat järjestäytyä itsenäisesti, heitä on edelleen yhdistettävä ja pidettävä synkronoituna. Työnkulunhallintakerros toimii liimana ja yhdistää kokonaisuuden. Se antaa paljon paremman näkyvyyden tapahtumiin. Keskustelun alussa kysyit, kuka voittaa. Se kuulostaa siltä, että jonkun on hävittävä ja siirryttävä toiseen työkaluun. Uskomme tulevaisuuteen, jossa kenenkään ei tarvitse hävitä ja jossa työkalut toimivat saumattomasti yhdessä. Haluamme olla tämä alusta, tai ainakin uskomme työnkulunhallinnan olevan alusta, joka mahdollistaa sen.
Ben Aston:
Jos olen uusi prosessi- ja työnkulunhallinnan ajattelussa, mistä aloitan? Monissa toimistoissa ja studioissa on vain viidestä kymmeneen ihmistä, jotka yrittävät saada työn ulos ovesta. Toimitusjohtaja on liiketoiminnan kehittäjä ja samalla projektipäällikkö. Mistä tällaisessa digimaailman villissä lännessä aloitetaan prosessien suunnittelu ja työnkulun optimointi?
Mitä ensimmäisiä vaiheita suosittelet prosessin ymmärtämiseen ja optimaalisen prosessin suunnitteluun? Kuinka päästään siihen pisteeseen, että asioita voidaan automatisoida? Ennen kaikkien pitämistä samalla sivulla on tehtävä jonkin verran työtä. Kuinka prosessisuunnittelussa otetaan ensimmäinen askel?
Marc Boscher:
Helposti hyödynnettäviä mahdollisuuksia on aina. Aloittamisen kynnys on paljon matalampi kuin kuvittelemme. Se ei ole niin monimutkaista, kuten toimistojen ja studioiden esimerkki osoittaa. Jokaisella asiakkaalla on oma tapansa järjestäytyä. Pienemmän toimiston on usein mukauduttava asiakkaan toimintatapaan. Tämä tarkoittaa, että paljon aikaa kuluu asiakkaan käyttämän työkalun opetteluun ja heidän prosessiinsa mukautumiseen.
Aloita yhdestä projektista. Selvitä, mitä asiakas käyttää ja mikä olisi oma ihannetyökalusi. Jos voit käyttää samaa työkalua, voit alkaa toistaa prosessia. Jos toimistosi projektit voidaan toimittaa yhden työkalun avulla, eri työkalua käyttävän uuden asiakkaan kohdalla voit yhdistää työkalut työnkulun avulla. Kokeile niiden integrointia. Mitä jos voisit yhdistää nämä kaksi työkalua toisiinsa? Se olisi paljon vähemmän häiritsevää ja kokeilemisen kynnys olisi hyvin matala.
Sinun ei tarvitse uusia kaikkea. Voit kokeilla yhtä projektia, yhtä pientä tiimiä tai yhtä työnkulkua. Voit aloittaa siitä, kuinka markkinointi pyytää tekniseltä tiimiltä muutosta verkkosivustoon. Tai siitä, kuinka tukipyyntö siirretään tekniselle tiimille. Aloita kohdasta, johon käytät eniten aikaa, ja kehitä toimintaa siitä eteenpäin.
Ben Aston:
Ketterä ajattelutapa perustuu testaamiseen ja oppimiseen, kun prosessia suunnitellaan ja optimoidaan. Ensimmäisellä kerralla emme kuitenkaan saa kaikkea oikein. Helposti hyödynnettävien mahdollisuuksien löytämiseksi voidaan tarkastella edellisen projektin oppeja. Missä meni pieleen? Missä asiat hajosivat ja miksi? Miksi suunnittelu alkoi kaksi viikkoa myöhässä? Miksi kehitys alkoi liian aikaisin?
Näiden oppien avulla voidaan löytää hyvä lähtökohta prosessin suunnittelulle. Rakennamme prosessin, kartoitamme sen, testaamme sen ja opimme, mikä toimii ja mikä ei. Se voi olla hyvä ensimmäinen askel prosessin suunnitteluun ja optimointiin. Marc, kiitos paljon seurastamme.
Marc Boscher:
Kiitos, Ben.
Ben Aston:
Jos haluat oppia lisää ja kehittyä projektinhallinnan prosessisuunnittelussa, siirry osoitteeseen thedigitalprojectmanager.com. Sieltä löydät valtavan määrän hyödyllisiä resursseja. Löydät myös jäsenyytemme ja verkkokoulutuksemme. Ensi kertaan asti – kiitos kuuntelemisesta.
