Rakennatko verkkoportaalin? Tässä jaksossa FCV:n asiakaspalvelujohtaja Rebecca Germond perehtyy portaalin rakentamisen hallintaan liittyviin työkaluihin, prosesseihin ja päivittäisiin haasteisiin. Onnistut verkkoportaalin rakentamisessa, kun opit hänen tiiminsä tosielämän virheistä ja menestystarinoista.
Tämän podcastin tarjoaa Clarizen, yritysprojektien ja projektinhallintaohjelmistojen markkinajohtaja.
Aiheeseen liittyvät linkit:
- Clarizen | Projektinhallintaohjelmisto
- Miksi ja miten opit dokumentoidaan (opit sisältävän mallipohjan avulla)
- Työn määrittelyasiakirjan laatiminen helposti (mallipohjan avulla)
- Asiantuntija-arvio: 10 parasta projektinhallintatyökalua
- Projektien kustannusarvioiden laatiminen: täydellinen opas projektin budjetointiin ja kustannusarviointiin
- Näin vedät sprintin suunnittelukokouksen kuin ammattilainen (+ kokouksen esityslista)
- Ketterä vai vesiputousmalli? Kumpaa sinun kannattaa käyttää projektissasi?
- Järjestä sprintin retrospektiivi, joka saa tiimisi innostumaan (näin se onnistuu!)
- Liity projektipäälliköiden Slack-tiimiimme
Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmiston avulla. Anna anteeksi mahdolliset kirjoitusvirheet, 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.
Asiakkaiden tarpeet kehittyvät, ja myös digitaalisten toimistojen rooli muuttuu ja kehittyy. Verkkosivujen suunnittelu- ja rakennusprosessin muuttuessa yhä standardoidummaksi tarvitaan toimistoja, jotka voivat olla enemmän kuin pelkkiä verkkosivukumppaneita: strategisia ja teknisiä kumppaneita, jotka rakentavat verkkosivujen, kampanjoiden ja laskeutumissivujen lisäksi muutakin. Tänään perehdymme hieman portaaliprojekteihin: mitä ne ovat, miten niitä rakennetaan sekä mitä oppeja ja oppeja projektista niistä voi saada, jos aiot aloittaa tällaisen projektin. Jatka kuuntelemista, jos haluat kuulla digitaalisten toimistojen kehityksestä ja tuotekehityslähtöisestä asiakasyhteistyöstä.
Tänään seurassani on Rebecca Germond. Rebecca on FCV:n asiakaspalvelujohtaja. Hänellä on vahva perusta projektinhallinnassa ja mediaviestinnässä. Palkkasin Rebeccan itse asiassa muutama vuosi sitten. Muistan haastattelusi: toin sinut huoneeseen ja ajattelin, että kyllä, palkkaan tämän tytön. En oikeastaan muista, mitä kysyin, mutta ajattelin, ettei minun tarvitse edes haastatella sinua. Sinut on palkattu. Muistatko haastattelun?
Rebecca Germond:
Muistan haastattelun. Tuntui kuin olisin ollut grillattavana. Ei, vitsailen vain. Muistan sen todella hyvin, koska muistan toimiston näkymän, ja luulen, että juuri se sai minut kiinnostumaan FCV:stä — tietysti myös keskustelumme.
Ben Aston:
Se en ollut minä. Se oli näkymä.
Rebecca Germond:
Niinpä.
Ben Aston:
Rebecca, niille jotka miettivät, mitä teet päivittäin: mitä asiakaspalvelujohtajan tehtävä tarkoittaa? Onko se projektinhallintaa? Asiakkuuksien hallintaa? Mitä se tarkoittaa sinulle tällä hetkellä?
Rebecca Germond:
Se on vähän molempia, minkä lisäksi johdan varsinaista projektipäällikkötiimiä, mikä on hienoa. Se on ollut minulle uusi tehtävä noin vuoden ajan. En enää osallistu projekteihin yhtä käytännönläheisesti kuin ennen. Muutamasta projektista en kuitenkaan suostu luopumaan. Pääasiassa työskentelen suoraan projektipäälliköiden kanssa ja varmistan, että he pystyvät toimittamaan työnsä sekä saavat tarvitsemansa tuen. Lisäksi hallinnoin suurinta osaa asiakkaistamme, joten minulla on heidän kanssaan melko vahva asiakkuudenhallintasuhde. Aloitin itse asiakkuuksien parissa ennen kuin minusta tuli tuottaja-projektipäällikkö, joten olen tavallaan palannut juurilleni.
Ben Aston:
Hienoa. Niille, joita kiinnostaa projektipäällikkötiimin johtaminen: miltä arki näyttää? Miten johdat heitä, kun et voi olla jatkuvasti kaikkien projektien yksityiskohdissa? Kun tarkistat heidän tilanteensa, mitä oikeastaan teet?
Rebecca Germond:
Useimmiten tarkistan paljon heidän lähettämiään töitä tai tuotoksia. Annan esimerkiksi palautetta työmäärityksestä tai aikataulusta. Jos tilanteet eskaloituvat, osallistun niihin tai autan projektipäälliköitä päättämään, miten haastaviin tilanteisiin kannattaa vastata. Tapaan heidät viikoittain kahden kesken, mutta olen myös yhteydessä Slackissa ja varmistan päivittäin, että kaikki kokevat saavansa tukea. Joskus osallistun heidän tärkeimpiin asiakastapaamisiinsa. Se on suurin piirtein sitä.
Olen myös vahvasti mukana FCV:n liiketoiminnan kehitysprosessissa. Työskentelen päivittäin sen parissa, kuinka paljon laskutamme asiakkaitamme ja seuraammeko riittävästi muutoksenhallintaprosessiamme. Lisäksi mukana on paljon muuta projektipäälliköiden jokapäiväiseen työhön liittyvää.
Ben Aston:
Kerro hieman tarinastasi. Taustasi oli asiakkuuksien hallinnassa. Tiedän, että aloitit urasi työministeriössä. Miten päädyit työministeriöstä digitaaliseen toimistoon, asiakkuuksien hallintaan ja projektinhallintaan? Miltä se näytti sinulle?
Rebecca Germond:
Kun olin koulussa, tädilläni oli henkilöstövuokrausyritys. Hän välitti minulle töitä, kun yritin löytää oikeaa paikkaa. Tiesin haluavani työskennellä toimistossa. Sain paikan työministeriöstä. Se oli enemmänkin hallinnollinen tehtävä valtiolla, mutta melko kiinnostava. Opin paljon hallinnon toiminnasta, mikä auttoi myöhemmin urallani, sillä ensimmäisessä toimistossani ja nykyään FCV:llä suuri osa projekteistani liittyy julkishallintoon.
Kerran hän järjesti minulle paikan torontolaisesta Manifest Communications -toimistosta. Minun piti tehdä vain kahden viikon määräaikainen vastaanottotyö jonkun ollessa lomalla, mutta he pyysivät minua jäämään harjoittelijaksi, mitä olin joka tapauksessa yrittänyt saada. Olin siellä kolme kuukautta, minkä jälkeen he palkkasivat minut, ja työskentelin siellä neljä vuotta. Aloitin asiakkuusvastaavana, joten hallinnoin asiakkaita enkä niinkään digitaalisia projekteja. Siirryimme vähitellen niihin. Ensimmäisen vuoden jälkeen minusta tuli tuottaja. Työstä ehkä 60 prosenttia oli digitaalista, mutta työskentelin myös radion, lähetysten ja painotuotteiden parissa.
Ben Aston:
Hienoa. Olemme vielä vuoden ensimmäisellä neljänneksellä. Kun puhutaan urastasi tai kehittymisestäsi, keskustelemme tänään portaaleista ja siitä, miten ne edustavat tietynlaista kehitystä. Oletko asettanut itsellesi tavoitteita tälle vuodelle?
Rebecca Germond:
Itse asiassa en halua asettaa tälle vuodelle erityisiä uratavoitteita. Se kuulostaa oudolta. Olen viimeistä vuotta parikymppinen, joten haluan vain elää milleniaalin tavoin. Minulla on matkustamiseen liittyviä tavoitteita. Se on nyt tärkeintä. Uran kannalta olen todella pitänyt tämän portaaliprojektin parissa työskentelystä. Olemme muuttaneet sen tuotteeksi, julkaisemme jatkuvasti uusia versioita ja yritämme kehittää sitä edelleen. Se on mielestäni todella hienoa, ja haluaisin tehdä enemmän vastaavaa työtä.
Ben Aston:
Hienoa. Puhuimme hieman tehtävästäsi ja siitä, mitä teet, mutta mitä haasteita kohtaat tällä hetkellä? Mikä on suurin päivittäinen päänvaivasi tai jokin tiettyyn projektiin liittyvä asia, jota yrität ratkaista?
Rebecca Germond:
Minulle arjen haaste on, että olen tottunut huolehtimaan projektitiimistä lähes kuin lastenhoitaja. Tiedät varmaan, mitä tarkoitan. Projektipäällikköinä joudumme käsittelemään paljon egoja ja erilaisia persoonallisuuksia. Nyt mittakaava on toinen: projekteja on vähemmän, mutta koko organisaation ihmisillä on erilaisia tarpeita ja prioriteetteja. Yritän tasapainottaa niitä ja samalla varmistaa, että projektipäälliköillä on tarvitsemansa asiat, mikä on erittäin tärkeää. Se on hieman vaikeaa. Lisäksi mukaan tulee asioita, joita ei ehkä pidä kovin merkittävinä, kuten hallinnollisia tehtäviä. Oman tehtävälistan seuraaminen on nykyään haastavaa.
Ben Aston:
Miten seuraat asioita? Millainen tehtävälistasi on? Onko sinulla järjestelmää?
Rebecca Germond:
Käytän tehtävälistaani enimmäkseen Evernotessa, mutta otimme juuri käyttöön uuden Slack-integraation nimeltä Workast. Sen avulla tehtävälistan voi pitää varsinaisessa Slack-kanavassa ja tehtäviä voi tarvittaessa määrittää ihmisille. Slackiin voi myös kirjoittaa itselleen muistiinpanon, jolloin tehtävälista on siellä ja palvelu muistuttaa määräajoista. Olemme vasta aloittaneet sen käytön, mutta tähän asti se on vaikuttanut hyvältä.
Ben Aston:
Sen nimi on Workast?
Rebecca Germond:
Workast, W-O-R-K-A-S-T.
Ben Aston:
Workast, selvä. Melko hauska nimi.
Rebecca Germond:
Ehdottomasti. Toistaiseksi kaikki on sujunut hyvin. Ongelma on, että tehtävälistaan pääsee käsiksi vasta ennen kello yhdeksää tai viiden jälkeen. Siltä minusta tuntuu, koska noin 70 prosenttia päivästäni kuluu puhelinpalavereissa tai sähköposteihin ja Slack-viesteihin vastaamisessa. Se tekee tuottavuudesta nykyään todella vaikeaa.
Ben Aston:
Mitä muuta projektipäällikön työkalupakkiisi kuuluu? Tehtävälistajärjestelmäsi auttaa tietysti priorisoimaan tärkeimmät asiat. Mitä muuta työkalupakissasi on? Miten hallinnoit projekteja?
Rebecca Germond:
Minulla on useita työkaluja. Olemme vaihdelleet joidenkin niistä välillä viime vuosina, mutta nyt olen melko tyytyväinen käytössämme olevaan kokonaisuuteen. Kuten sanoin, käytän Evernotea. Käytämme nykyään Jiraa melko perusteellisesti. Kaikki, myös käyttäjäkokemuksen ja suunnittelun parissa työskentelevät sekä asiakkaamme, ovat Jirassa. Se helpottaa työtä, koska kaikki on ainakin yhdessä paikassa ja voimme seurata tikettejä. Käytämme Slackia, ja käytän sitä todella aktiivisesti.
Testaamme Microsoft Teamsia Skypen sijaan. Käytämme sitä neuvottelupuheluihin asiakkaiden kanssa. Se on toiminut melko hyvin. Käytän Merliniä projektien aikatauluttamiseen. Käytimme aiemmin MS Projectia, mutta mielestäni hyödynnämme vain 15 prosenttia sen ominaisuuksista. Pidämme muutaman MS Project -lisenssin varalla siltä varalta, että asiakas tarvitsee sitä. Spotify kuuluu ehdottomasti työkalupakkiini. Tarvitsen sitä. Lisäksi Outlook, vaikka sähköposti onkin olemassaoloni vitsaus.
Ben Aston:
Workastin lisäksi, oletko hiljattain törmännyt muihin työkaluihin tai asioihin, jotka ovat mullistaneet projektien hallintatapasi?
Rebecca Germond:
En oikeastaan. Olemme alkaneet käyttää Jiraa niin, että integroimme sen Slack-kanavaamme. Jos tiketti päivitetään tai sen tila muuttuu, tai jos asiakas kommentoi sitä, Jira lähettää normaalisti valtavan määrän sähköposteja. Slack-kanavaan lähetetään vain tärkeät ilmoitukset, joten tiedämme, jos joku on kommentoinut tikettiä. Se on helpottanut työtä huomattavasti, koska kukaan ei lue Jiran sähköposteja. Microsoft Teams on myös melko hyvä, sillä useimmat asiakkaamme eivät halunneet käyttää videota, mutta Teamsiin siirryttyämme monet ovat ottaneet sen käyttöön.
Ben Aston:
Hienoa. Puhutaan kirjoituksestasi ja tapaustutkimuksestasi, joka on ensimmäinen koskaan julkaisemasi. Onnittelut, Rebecca.
Rebecca Germond:
Kiitos.
Ben Aston:
Puhutaan portaalista. Onko portaali vain verkkosivusto vai onko se erilainen? Jos se on erilainen, miksi ja miten?
Rebecca Germond:
Portaalit ovat mielestäni melko monimutkaisia, koska ne on yleensä räätälöity monille erilaisille käyttäjille, joilla jokaisella voi olla useita toimintoja, ominaisuuksia tai käyttäjäpolkuja. Tässä portaalissa oli pidettävä mielessä kolme erilaista käyttäjätasoa, ja niiden vaikutus toisiinsa oli asia, jonka aliarvioimme aluksi. Portaalit voivat olla yleisesti ottaen monimutkaisia juuri siksi, että niissä on paljon erilaisia toimintoja, joita tavallisella verkkosivustolla ei olisi, kun käyttäjä vain avaa etusivun.
Ben Aston:
Puhumme siis tilanteesta, jossa on paljon vuorovaikutteisuutta ja roolipohjaisia toimintoja, jotka otetaan käyttöön tai poistetaan käytöstä sen mukaan, mitä portaalissa tehdään.
Rebecca Germond:
Juuri niin. Tässä portaalissa et saanut etusivulta juuri mitään irti ilman kirjautumistunnuksia. Käyttäjille on asetettu tiettyjä rajoituksia, eikä uusien asiakkaiden lisääminen portaaliin ole välttämättä helppoa. On paljon asioita, jotka on otettava huomioon ja joita tavallisella verkkosivustolla ei tarvitsisi miettiä.
Ben Aston:
Mielenkiintoista. Emme siis puhu abstraktisti. Voitko antaa lyhyen yleiskatsauksen portaalin toiminnallisuudesta?
Rebecca Germond:
Tämä portaali liittyy elektroniikkakauppiaaseen, jolla on yritysasiakkaita. Nämä yritykset haluavat tilata tuotteita suurissa erissä. Ennen portaalia asiakkaat soittivat asiakkuusvastaavalleen ja tekivät tilauksen erittäin manuaalisesti. Se aiheutti päänvaivaa kaikille, sillä kukaan ei enää halua soittaa tilauksiaan puhelimitse. He tarvitsivat portaalin, johon käyttäjät voivat kirjautua ja jossa he näkevät heille määritetyn tuoteluettelon sekä voivat ostaa vain kyseisiä tuotteita. Lisäksi tuotteisiin sovelletaan monimutkaista alennusmekanismia. Koska asiakkaat ostavat suuria määriä, he saavat räätälöityjä alennuksia ostomääränsä ja toimintansa perusteella.
Portaalissa on myös kassatoiminto ja hallintapaneeli, jossa käyttäjät näkevät useimmin tilaamansa tuotteet sekä avoimet tilaukset ja viimeisten 30 päivän aikana tehdyt tilaukset. Hallintapaneelissa on hyödyllisiä työkaluja, joiden avulla käyttäjät näkevät, mitä heidän portaalimaailmassaan tapahtuu.
Portaalissa on myös erilaisia käyttäjätasoja. Useimmat asiakkaat voivat tehdä tilauksen, mutta organisaation asetuksista riippuen asiakasjärjestelmänvalvojan on hyväksyttävä se. Ennen tilauksen käsittelyä jonkun on voitava hyväksyä se tai ilmoittaa, että käyttäjä ylittää budjetin, joten tilausta ei voida viedä läpi. Tässäkin on paljon yksityiskohtia.
Ben Aston:
Eli jos olen suuri organisaatio, esimerkiksi Telus, ja haluan tilata 2 000 uutta näyttöä, kirjaudun järjestelmään, ostan näytöt, käyn läpi hyväksyntäprosessin ja voin seurata tilaustani.
Rebecca Germond:
Kyllä, juuri niin.
Ben Aston:
Verkkokauppaa suuressa mittakaavassa.
Rebecca Germond:
Aivan.
Ben Aston:
Kirjoitit kiinnostavasta teknologiasta. Voitko antaa meille Coles Notes -version teknologi pinosta, arkkitehtuurista ja ratkaisusta — miten tämä käytännössä rakennettiin? Mikä teki siitä kiinnostavan?
Rebecca Germond:
Kehittäjämme osaisivat varmasti selittää sen paremmin, mutta voin antaa yleiskuvan.
Ben Aston:
Projektipäällikön version.
Rebecca Germond:
Käytämme .NET Corea mikropalvelujen toteuttamiseen ja Reactia käyttöliittymään, joka tarjoaa näiden mikropalvelujen rajapinnat. Mikropalvelut ovat käytännössä päätepisteitä, joita voi käyttää haluamallaan tavalla. Jos esimerkiksi saamme tietoa tilausten määrästä, voimme näyttää sen hallintapaneelissa tai käsitellä sitä monin eri tavoin. Se on todella hyödyllistä. React on tietysti kiinnostava käyttöliittymäkehittäjillemme, ja he pitävät sen parissa työskentelystä. Loimme Reactia käyttäessämme komponenttikirjaston, jota voimme hyödyntää sivuston eri osissa, jotta samoja komponentteja ei tarvitse rakentaa jatkuvasti uudelleen. Halusimme myös varmistaa yhtenäisen ulkoasun koko sivustolla ja säilyttää asiakkaan brändin niin, ettei portaali tuntuisi liian erilaiselta kuin heidän kuluttajasivustonsa.
Ben Aston:
Sisällönhallintajärjestelmää ei siis ole. Miten prosessi toimi? Olette luoneet .NETillä toiminnallisuuden, jonka avulla kauppias voi lisätä ja muokata tuotteita. Onko sitä varten oma sisällönhallintajärjestelmä?
Rebecca Germond:
Ei. Tuotetiedot tulevat asiakkaan tarjoamasta rajapinnasta, jota he käyttävät kuluttajasivustoillaan. Kaikki tuotetiedot päivittyvät jatkuvasti. Meillä on kerran päivässä toimiva komentosarja, joka varmistaa, että käytössämme ovat ajantasaiset hinnat ja tuotetiedot, kuten tekniset tiedot. Uusien tuotteiden lisääminen on täysin automatisoitu prosessi.
Ben Aston:
Se on hienoa. Kyseessä oli tuotekehitysprojekti ja uuden portaalin rakentaminen. Miten suunnittelitte projektin tai tuotekehityksen? Millä tavalla suunnittelitte rakennustyön?
Rebecca Germond:
Käytimme ehdottomasti MVP-lähestymistapaa eli pienimmän toimivan tuotteen mallia. Se toimi ja ei toiminut, koska projektin edetessä MVP:n sisältö kasvoi jatkuvasti. Se ei lopulta ollut lainkaan minimaalinen. Alussa MVP-lähestymistapa auttoi meitä huomattavasti aikataulun ja arvion suunnittelussa. Koska työjonomme oli melko selkeä, siirryimme suoraan kehityssprintteihin. Emme käyttäneet tähän projektiin kovin pitkää vaatimustenkeruuvaihetta. Käsittelimme vaatimukset jokaisen sprintin suunnittelukokouksessa niiden ominaisuuksien osalta, jotka aioimme saada valmiiksi sprintin aikana.
Ben Aston:
Oliko MVP:lle oma budjetti ja määräaika? Teillä oli työjono täynnä rakennettavaa. Miten määrititte, mikä mahtui budjettiin ja mikä ei? Missä vaiheessa budjetti määriteltiin?
Rebecca Germond:
Se oli vaikeaa. Toimistoympäristössä ketterän työskentelyn haaste on se, että asiakkaat haluavat nähdä hinnan kaikelle. Todellinen ketteryys voisi perustua sprinttikohtaiseen hintaan. Sprintin lopussa ominaisuus ei välttämättä ole valmis. Meidän täytyi arvioida työ siten, että annoimme jokaiselle ominaisuudelle erillisen hinnan. Näin asiakas tiesi tarkalleen, mitä tietty ominaisuus maksaisi ja pystyi tarvittaessa priorisoimaan ominaisuudet itse. Jotkin ominaisuudet riippuivat toisista. Kun saimme selville MVP:n tarkan sisällön, määritimme kustannukset ja kaiken, mitä riippuvuuksien toimiminen edellytti. Näiden ominaisuuskohtaisten hintojen perusteella yritimme muodostaa kokonaisuuden, joka sopisi sprinttimalliin. Meillä oli viisi kuukautta aikaa projektin toteuttamiseen ja sen jälkeen kuukausi käyttäjähyväksyntätestausta varten. Käytimme kaksi viikkoa ympäristön ja muiden vastaavien asioiden määrittämiseen. Kaikkiaan meillä oli kuusi tai seitsemän sprinttiä.
Ben Aston:
Mainitsit tapaustutkimuksessa, että aliarvioitte voimakkaasti joidenkin pakollisten ominaisuuksien työmäärän, mutta sanoit sen tehneen projektista hauskan. Ymmärrän rivien välistä, että aliarvioitte myös yksittäisten ominaisuuksien hinnat. Miten ja miksi näin tapahtui?
Rebecca Germond:
Suurin aliarviointimme liittyi varsinaisen tuoteluettelon rakentamiseen ja alennusten soveltamiseen. Ajattelimme, että lisäämme vain alennuksen tietyille tuotteille. Kun perehdyimme rajapinnan yksityiskohtiin ja tuoteryhmien erilaisiin luokitteluihin ja suodattimiin, logiikka yhdistettynä alennuksiin muuttui hyvin monimutkaiseksi. Lisäksi asiakkaan piti voida sulkea joitakin tuotteita pois. Esimerkiksi Apple-tuotteista ei saatu suurta katetta, joten niihin ei haluttu soveltaa alennuksia. Meidän piti varmistaa, että jos asiakas sanoi ”poissulje Apple-brändi”, näytimme vain määritellyt tuotteet emmekä Apple-tuotteita ja sovelsimme alennusta oikein. Tästä tuli todella sekavaa ja monimutkaista.
Asiakkaan kanssa oli kiinteähintainen sopimus. Pystyimme kattamaan kustannuksia tai saamaan lisää aikaa matkan varrella tehtyjen muutospyyntöjen avulla, myös sellaisten ominaisuuksien osalta, jotka kuuluivat alkuperäiseen kokonaisuuteen. Yritimme pitää muutoksenhallintaprosessin ajan tasalla. Kun olemme itse aliarvioineet työn, asiakkaalle on vaikea sanoa, ettemme onnistuneet tekemään työtämme oikein.
Ben Aston:
Osa ongelmaa oli siis se, etteivät alennuksiin liittyvät vaatimukset olleet heti alussa täysin selkeitä?
Rebecca Germond:
Juuri niin. Alkuperäisissä vaatimuksissa alennusmoottorin piti olla paljon yksinkertaisempi. Kun perehdyimme siihen tarkemmin, kokonaisuus muuttuikin melko hankalaksi.
Ben Aston:
Näin käy usein ketterissä projekteissa. Ketterän toimintatavan tarkoitus on sopia tilanteisiin, joissa asiat eivät ole täysin mustavalkoisia, mutta kustannusmallin pitää heijastaa tätä. Tässä työskentelitte kiinteällä hinnalla ja epäselvien vaatimusten kanssa. Mitä tekisit nyt tietämiesi asioiden perusteella seuraavalla kerralla toisin?
Rebecca Germond:
Mielestäni teimme hyvää työtä niiden vaatimusten kanssa, jotka meillä oli. Haluaisin ehkä tämän asiakkaan kanssa siirtyä enemmän sprinttikohtaiseen hinnoitteluun. Emme ole vielä aivan päässeet siihen, mutta voimme joustaa aikataulun kanssa, ja hän suhtautuu asiaan todella ymmärtäväisesti. Jos aloittaisimme alusta, voisimme antaa alussa karkean hinta-arvion. Asiakkaan on saatava jokin summa hyväksytettäväksi. Jos annamme hyvän vaihteluvälin ja arvioimme jokaisen sprintin aikana tarkemmin, mitä aiomme tehdä, voisimme antaa sprinttikohtaisen hinnan tiimin koon ja tavoitteiden perusteella. Se voisi toimia paremmin. Muuten en muuttaisi paljonkaan tiimin toimintatavasta. Pidin siitä, että tiimi oli pieni ja toiminta ketterää. Asiakkaan puolella mukana oli vain hän ja kulloinkin tarvittava sidosryhmän edustaja.
Ben Aston:
Puhut pienestä tiimistä, joka toimi hyvin. Kirjoitit ketterän kehityksen ja suunnittelun yhdistelmämallista. Miltä se näytti käytännössä? Keitä tiimiin kuului ja miten suunnittelu ja kehitys saatiin toimimaan?
Rebecca Germond:
Se on vaikeaa. Toimistoympäristössä on yleisesti hyvin vaikeaa toimia täysin ketterästi, koska asiakkaat eivät yleensä halua maksaa tiimistä viiden kuukauden ajan yhtäjaksoisesti. He haluavat tietää ominaisuuden hinnan. Jos työskentelet oman organisaatiosi sisällä oman tuotteesi parissa ja sinulla on siihen nimetyt ihmiset kahdeksaksi tunniksi päivässä, viideksi päiväksi viikossa, tilanne on erilainen. Kun ihmiset työskentelevät useissa projekteissa, ketterä työskentely on erittäin vaikeaa.
Tiimissämme oli kaksi taustajärjestelmäkehittäjää, kaksi käyttöliittymäkehittäjää, puolipäiväinen käyttäjäkokemussuunnittelija, suunnittelija, joka osallistui silloin tällöin arvioimaan luovaa suunnittelua ja ominaisuuksia, sekä yksi laadunvarmistaja, joka työskenteli yleensä sprintin aikana puolipäiväisesti. Emme käyttäneet liiketoiminta-analyytikkoa, mikä oli mielestäni hyväksyttävää, koska tiesimme, mitä olimme rakentamassa. Hän ei olisi pystynyt kertomaan meille rajapinnan yksityiskohtia eikä olisi välttämättä auttanut arviointiprosessissa. Strategia-asiantuntijaa ei myöskään tarvittu, koska tuote oli selkeä, asiakkaalla oli hyvin määritelty visio MVP:stä ja sen taustalla oli vahva käyttötapaus. Tiimiin kuului tietysti myös minä.
Koska aloitimme tyhjästä, meillä ei ollut valmiita komponentteja. Meillä oli käytettävissämme brändiohjeisto ja ominaisuudet, joita tarvittiin. Suunnittelu ja käyttäjäkokemus työskentelivät sprintin kehitystiimin edellä. Aidossa ketterässä mallissa ominaisuus toimitettaisiin yhdessä, mutta asiakas ei ollut koskaan nähnyt mitään tekemäämme. Meidän piti antaa heille etumatkaa varmistaaksemme, että ulkoasu ja tuntuma olivat oikealla tiellä.
Ensimmäisessä sprintissä suunnittelu ja käyttäjäkokemus työskentelivät etukäteen ympäristön määrittämisen ja projektin perustamisen parissa. Asiakkaan organisaatio työskenteli itsekin ketterästi tai ainakin yritti tehdä niin, joten heidän oli helppo ymmärtää toimintatapa. He pitivät yhteistyömallista. Käytimme ketteriä seremonioita, kuten päivittäisiä tilannekatsauksia, sprintin puolivälin arviointeja, demoja ja retrospektiivejä, ja asiakas osallistui kaikkiin tai useimpiin niistä.
Ben Aston:
Puhutaan asiakkaasta. Tässä tilanteessa hienoa oli se, että asiakas toimi tuotepäällikkönä. Sidosryhmiä ei ollut paljon, vaan yksi pääasiallinen sidosryhmä. Sanoit hänen olleen erinomainen, mutta kirjoitit myös, että hän keksi matkan varrella uusia ominaisuuksia ja tehtäviä. Miten hallitsitte sen, kun budjetti oli kiinteä mutta toimintatapa ketterä?
Rebecca Germond:
Se oli vaikeaa, mutta aina kun hän keksi uuden ominaisuuden, hän ymmärsi, että kyseessä oli muutospyyntö ja että siitä piti tehdä tarjous. Ongelma oli se, että sprintin työ piti keskeyttää arvion tekemiseksi, koska ominaisuuden hyväksymiseen tarvittiin hinta-arvio. Asiakas toimi käytännössä tuotteen omistajana, ja hänen tiiminsä antoi hänelle täyden vastuun projektin johtamisesta. He olivat suunnitelleet sitä jo jonkin aikaa ennen meidän mukaan tuloamme. Oli hyvä, että tulimme mukaan siinä vaiheessa, koska pystyimme antamaan palautetta ja ehdottamaan uusia ominaisuuksia.
Hän toi välillä esiin hauskoja ominaisuuksia, mutta ne olivat kaikki todella tärkeitä. Ennen projektia he olivat esimerkiksi suunnitelleet lisäävänsä asiakkaat järjestelmään manuaalisesti ja lähettävänsä heille PDF-tiedoston rekisteröitymisohjeineen. Kolmannen sprintin jälkeen päätimme rakentaa ohjatun käyttöönottotoiminnon, jonka avulla käyttäjä saa sähköpostitse kirjautumistunnuksen ja salasanan, voi vaihtaa salasanansa, ladata tarvitsemansa lomakkeet ja lähettää ne takaisin järjestelmään. Tämä helpotti asiakkaan tiimin työtä ja teki tuotteesta kokonaisuutena paljon paremman.
Ben Aston:
Puhuit opituista asioista. Yksi niistä oli tiimin pitäminen sitoutuneena ja asiakkaan osallistaminen. Asiakas vaikutti todella osallistuneelta. Millaisia vinkkejä antaisit sitoutumisen ylläpitämiseen ja vahvistamiseen?
Rebecca Germond:
Tällainen työskentelytapa oli FCV:lle uusi, koska monet asiakkaistamme ovat pitkäaikaisia tai julkishallinnon asiakkaita. He ovat työskennelleet kanssamme vuosia, mutta ovat juuttuneet vanhoihin toimintatapoihin. Asiakkaan aktiivinen osallistaminen toimi todella hyvin, koska huomasimme asiakkaiden haluavan osallistua tällä tasolla. Halusimme myös pitää hänet mukana, koska toivoimme projektille jatkoa. Emme rakentaneet vain verkkosivustoa, jolla on elinkaarensa loppu, vaan elävää ja jatkuvasti kehittyvää tuotetta.
Tiimi halusi työskennellä projektissa, koska he saivat valita teknologi pinon, kokeilla jotain uutta ja valita omat työkalunsa. He pitivät myös mahdollisuudesta keskustella asiakkaan kanssa. Asiakas oli mukana Slackissa, joten hän pystyi vaihtamaan ajatuksia käyttöliittymäkehittäjän tai muun tarvittavan henkilön kanssa. Tiimi oli sitoutunut, koska he rakensivat jotakin, josta todella välittivät.
Ben Aston:
Yksi oppisi liittyi tarpeettomien prosessien karsimiseen ja tarpeellisten omaksumiseen. Sanoit projektin parantaneen toimiston projektiprosessia. Mitä prosesseja jätitte pois tai mitä parannuksia pystyitte viemään muihin projekteihin?
Rebecca Germond:
Toisen sprintin retrospektiivin jälkeen päätimme lopettaa retrospektiivit. Tiesimme jo, mikä toimi ja mikä ei, eikä niiden käyttäminen auttanut enää. Se vei vain aikaa kehitystyöltä. Koska asiakas oli niin osallistuva, hän pystyi antamaan palautetta jatkuvasti ja kertomaan, jos jokin ei toiminut tai prosessia pitäisi muuttaa seuraavaa sprinttiä varten. Luovuimme siitä melko varhain.
Tilannekatsauksia oli myös vaikea järjestää, koska puolet tiimistä oli Torontossa ja puolet Vancouverissa. Yritimme kuitenkin pitää kiinni siitä, että ihmisten työn esteet ratkaistaan mieluummin 15 minuutin tilannekatsauksessa kuin tunnin Slack-keskustelulla.
Ben Aston:
Eli piditte satunnaisia tilannekatsauksia, eivätkä ne olleet päivittäin kello yhdeksän tai kahdentoista järjestettäviä seremonioita. Ne olivat tilannekohtaisia.
Rebecca Germond:
Kyllä, kello 9.30. Yritimme saada sen toimimaan, mutta kun pääsimme rytmiin, tilannekatsaukset muuttuivat tilannekohtaisiksi. Saattoimme myös vain mennä Slackiin ja esittää kysymyksiä. Järjestimme päivittäisiä katsauksia ehkä kolmen sprintin ajan, minkä jälkeen siirryimme joka toiseen päivään tai Slackin käyttöön.
Ben Aston:
Onko jokin prosessi, jonka yrititte poistaa, mutta otitte myöhemmin takaisin käyttöön huomattuamme sen olleen huono idea?
Rebecca Germond:
Ei oikeastaan. Yksi asia, jonka olisimme toivoneet aloittaneemme aikaisemmin, oli laadunvarmistus. Meillä ei ollut mitään testattavaa ennen kolmatta sprinttiä, joten se olisi pitänyt aloittaa hieman aikaisemmin. Muutamassa demossa työskentelimme vielä viisi minuuttia ennen esitystä, lähetimme koodia tuotantoon ja vain toivoimme sen toimivan. Työskentelimme lopussa kuin cowboyt, mutta se oli todella hauskaa.
Ben Aston:
Hienoa. Rebecca, kiitos paljon osallistumisestasi. On ollut hienoa saada sinut vieraaksemme.
Rebecca Germond:
Kiitos. Milloin vain.
Ben Aston:
Ole hyvä. Jos portaaliprojektit kiinnostavat, tutustu Rebeccan kirjoittamaan tapaustutkimukseen. Siinä on paljon hyödyllistä tietoa. Jos haluat keskustella portaaliprojekteista, liity Slack-tiimiimme. Mene osoitteeseen digitalprojectmanager.com/slack, niin löydät monenlaisia kiinnostavia keskusteluja kaikesta digitaaliseen projektinhallintaan liittyvästä. Jos pidit tämänpäiväisestä ohjelmasta, käy Apple Podcastsissa, joka tunnettiin aiemmin nimellä iTunes, ja jätä arvostelu. Kuulemme mielellämme palautteesi. Arvostelut ja arviot auttavat meitä todella paljon. Kuullaan seuraavalla kerralla. Kiitos kuuntelusta.
