Å lede byggingen av en portal på nettet (med Rebecca Germond fra FCV Interactive)

Les transkripsjonen:

Vi prøver ut transkribering av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Ben Aston:

Velkommen til DPM-podkasten, der vi går lenger enn teori for å gi ekspertråd til prosjektledere som vil lede bedre digitale prosjekter. Takk for at du lytter. Jeg er Ben Aston, grunnlegger av Digital Project Manager.

Kundebehovene blir stadig mer modne, og rollen til digitale byråer endrer og utvikler seg også. Etter hvert som prosessen for design og bygging av nettsteder har blitt mer standardisert, har behovet økt for byråer som kan være mer enn bare en nettstedspartner, men også en strategisk og teknisk partner som kan bygge mer enn nettsteder, kampanjer og landingssider. I dagens podkast skal vi fordype oss litt i portalbygging: hva portaler er, hvordan man bygger dem, og noen erfaringer og lærdommer dersom du skal starte et slikt prosjekt. Fortsett å lytte hvis du vil lære mer om utviklingen av digitale byråer og en produktutviklingstilnærming til kundeengasjement.

I dag har jeg med meg Rebecca Germond. Rebecca er direktør for kundetjenester hos FCV. Hun har et solid grunnlag innen prosjektledelse og mediekommunikasjon. Rebecca er faktisk en person jeg ansatte for noen år siden. Jeg husker intervjuet ditt, da jeg hentet deg inn i rommet og tenkte: «Ja, klart, jeg ansetter denne jenta.» Jeg husker egentlig ikke hva jeg spurte deg om, men jeg tenkte: «Jeg trenger ikke å intervjue deg engang. Du er ansatt.» Husker du intervjuet?

Rebecca Germond:

Jeg husker intervjuet. Jeg følte at jeg ble grillet. Nei, jeg bare tuller. Jeg husker det veldig godt fordi jeg husker utsikten fra kontoret, og det var det som overbeviste meg om FCV, tror jeg – i tillegg til samtalen vår.

Ben Aston:

Det var ikke meg. Det var utsikten.

Rebecca Germond:

Ja.

Ben Aston:

Rebecca, for dem som lurer på hva du gjør hver dag: Hva innebærer rollen som direktør for kundetjenester? Er det prosjektledelse? Er det kundeansvar? Hva betyr det for deg akkurat nå?

Rebecca Germond:

Ja, det er litt av begge deler, i tillegg til å lede selve prosjektlederteamet, noe som er spennende. Det er en ny rolle for meg det siste året eller så. Jeg er ikke like tett på prosjektene lenger. Det er noen jeg ikke vil gi slipp på, men stort sett får jeg jobbe direkte med prosjektlederne og sørge for at de kan levere og får støtten de trenger. Jeg følger også opp de fleste kundene våre, så jeg har en ganske god relasjon til dem som kundeansvarlig. Jeg begynte faktisk innen kundeoppfølging før jeg ble produsent og prosjektleder, så det er litt som å vende tilbake til røttene mine, noe som er fint.

Ben Aston:

For dem som er interessert i rollen med å lede et team av prosjektledere: Hvordan ser en vanlig dag ut? Hvordan følger du dem opp? Du kan jo ikke være inne i detaljene i alle prosjektene deres hele tiden. Når du sjekker inn med dem, hva gjør du egentlig?

Rebecca Germond:

For det meste går jeg gjennom mye av arbeidet eller leveransene de ønsker å sende fra seg. Jeg kan for eksempel gi tilbakemeldinger på en arbeidsbeskrivelse eller en tidsplan. Hvis noe eskalerer, involverer jeg meg, eller hjelper prosjektlederne med å finne ut hvordan de skal håndtere vanskelige situasjoner. Jeg har individuelle møter med dem hver uke, og så holder jeg kontakt gjennom Slack for å sørge for at alle føler seg støttet i hverdagen. Av og til deltar jeg også i de viktigste kundemøtene deres. Det er litt av det.

Jeg er også sterkt involvert i forretningsutviklingsprosessen vår hos FCV. Jeg jobber dessuten med det daglige rundt hvor mye vi faktisk skal fakturere kundene, og om vi følger godt nok opp prosessen for endringshåndtering. Det er mange andre ting også, i det daglige arbeidet med prosjektlederne.

Ben Aston:

Fortell oss litt om historien din. Bakgrunnen din var innen kundeoppfølging. Jeg vet faktisk at du begynte karrieren din i Arbeidsdepartementet. Hvordan gikk du derfra til et digitalt byrå og kundeoppfølging og prosjektledelse? Hvordan så det ut for deg?

Rebecca Germond:

Da jeg gikk på skole, hadde tanten min et vikarbyrå. Hun skaffet meg jobber mens jeg prøvde å finne ut hva som passet. Jeg visste at jeg ville jobbe i et byrå. Jeg fikk en plassering i Arbeidsdepartementet. Det var mer en administrativ jobb for staten, men det var ganske interessant. Jeg lærte mye om hvordan staten fungerer, noe som faktisk har hjulpet meg senere i karrieren, fordi de fleste prosjektene jeg jobbet med i mitt første byrå, og mange av prosjektene jeg jobber med nå hos FCV, er knyttet til offentlig sektor.

En gang fikk hun meg utplassert hos et byrå, Manifest Communications i Toronto. Jeg skulle bare jobbe i resepsjonen i to uker mens noen var på ferie, men de ba meg bli som praktikant, noe jeg uansett prøvde å få til. Jeg gjorde det i tre måneder, og så ansatte de meg. Jeg jobbet der i fire år. Da jeg begynte, var jeg kundeansvarlig, så jeg fulgte opp kunder og jobbet mindre med digitale prosjekter. Etter hvert beveget vi oss mer inn på det. Etter det første året ble jeg produsent, og omtrent 60 prosent av arbeidet var digitalt. Jeg fikk også jobbe med radio, kringkasting og noe trykt materiell, noe som var veldig interessant.

Ben Aston:

Fortell meg om målene dine. Vi er fortsatt i første kvartal av året. Når det gjelder karriere- eller utviklingsperspektivet ditt, snakker vi i dag om portaler og hvordan dette er en utvikling. Har du satt deg noen mål for året?

Rebecca Germond:

Det er egentlig litt morsomt. Jeg ønsker meg ikke noen konkrete karrieremål i år. Det høres kanskje rart ut. Jeg er inne i det siste året av tjueårene, så jeg vil egentlig bare leve som en millennial. Jeg har noen reisemål. Det er det som står på planen. Når det gjelder karrieren, har jeg likt veldig godt å jobbe med dette portalprosjektet. Vi har gjort det om til et produkt, og vi lanserer stadig nye versjoner og prøver å bygge videre på det. Jeg synes det er veldig bra, og jeg vil gjerne gjøre mer av den typen arbeid.

Ben Aston:

Vi har snakket litt om rollen din og hva du gjør, men hvilke utfordringer håndterer du akkurat nå? Hva er den største hodepinen du prøver å løse i hverdagen, enten generelt eller i forbindelse med et bestemt prosjekt?

Rebecca Germond:

I hverdagen er jeg vant til å passe på et prosjektteam, hvis du skjønner hva jeg mener. Som prosjektledere må vi håndtere mange egoer og ulike personlighetstyper. Nå er utfordringen større, fordi det ikke bare gjelder prosjekter, men alle i organisasjonen har forskjellige behov og prioriteringer. Jeg prøver å balansere dette samtidig som jeg sørger for at prosjektlederne har det de trenger, fordi det er svært viktig. Det kan være vanskelig. Man blir også dratt inn i ting man kanskje ikke synes er så store, som administrative oppgaver. Jeg vet ikke. Det er vanskelig å holde oversikt over min egen oppgaveliste for tiden.

Ben Aston:

Hvordan holder du oversikt? Hvordan ser oppgavelisten din ut? Har du et system?

Rebecca Germond:

Jeg bruker stort sett Evernote til oppgavelisten min, men vi har nettopp lagt til en ny Slack-integrasjon som heter Workast. Der kan du ha oppgavelisten din i en Slack-kanal og tildele oppgaver ved behov. Du kan også skrive et notat til deg selv i Slack, og oppgavelisten er der. Den minner deg på når ting skal være ferdige. Vi har nettopp begynt å bruke det, men så langt er det ganske bra.

Ben Aston:

Det heter Workast?

Rebecca Germond:

Workast, W-O-R-K-A-S-T.

Ben Aston:

Workast, ok. Litt morsomt navn.

Rebecca Germond:

Absolutt. Så langt fungerer det bra. Problemet er at du ikke kommer til oppgavelisten før enten før klokken ni eller etter klokken fem. Slik føles det, fordi 70 prosent av dagen min enten består av møter på telefonen eller av å svare på e-post og meldinger i Slack. Det gjør det vanskelig å være produktiv.

Ben Aston:

Hva annet har du i verktøykassen som prosjektleder? Du har systemet for oppgavelisten, som hjelper deg med å prioritere det viktigste. Hva annet har du i verktøykassen? Hvordan leder du prosjekter?

Rebecca Germond:

Jeg har ganske mange verktøy. Vi har byttet frem og tilbake mellom noen av dem de siste par årene, men nå er jeg ganske fornøyd med det vi har. Som sagt bruker jeg Evernote. Vi bruker Jira ganske aktivt nå. Alle, inkludert UX- og designteamet og alle kundene våre, er i Jira. Det gjør ting enklere fordi alt i det minste finnes på ett sted, og vi kan holde oversikt over saker. Vi bruker Slack, og jeg bruker det svært mye.

Vi tester Microsoft Teams i stedet for Skype for Business. Foreløpig bruker vi det som konferanseløsning for møter med kunder. Det fungerer ganske bra. Jeg bruker Merlin til prosjektplanlegging. Vi brukte MS Project tidligere, men jeg synes vi bare brukte 15 prosent av funksjonaliteten. Vi har fortsatt noen MS Project-lisenser tilgjengelig i tilfelle kunden trenger dem. Spotify er definitivt også i verktøykassen min. Det trenger jeg. Og Outlook, antar jeg, selv om e-post er banneordet i tilværelsen min.

Ben Aston:

Bortsett fra Workast, har du kommet over andre verktøy nylig, eller noe som har revolusjonert måten du leder prosjekter på?

Rebecca Germond:

Egentlig ikke. Jeg synes måten vi bruker Jira på nå, og integrasjonene vi har i Slack-kanalen, har vært nyttig. Hvis en sak blir oppdatert, endres statusen. Hvis en kunde kommenterer, sender Jira vanligvis ut 40 e-poster i minuttet når noe oppdateres. Nå sendes bare de viktigste tingene til Slack-kanalen, slik at du vet om noen har kommentert en sak. Det har gjort ting enklere, fordi ingen leser Jira-e-postene. MS Teams er også ganske bra. De fleste kundene våre ville ikke bruke video tidligere, men mange har begynt å bruke det etter at vi gikk over til MS Teams.

Ben Aston:

La oss snakke om innlegget ditt, casestudien – den første casestudien du noen gang har publisert. Gratulerer, Rebecca.

Rebecca Germond:

Takk.

Ben Aston:

La oss snakke om en portal. Er en portal bare et nettsted, eller er den annerledes? Hvis den er annerledes, hvorfor og hvordan?

Rebecca Germond:

Jeg synes portaler er ganske komplekse fordi de vanligvis er tilpasset mange forskjellige brukere, og disse brukerne kan ha mange ulike handlinger, funksjoner og brukerreiser. For denne portalen hadde vi tre forskjellige brukernivåer å ta hensyn til, og hvordan de påvirket hverandre, var noe vi undervurderte i begynnelsen. Portaler kan generelt bli ganske komplekse på grunn av alle de forskjellige sidene ved dem som du ikke nødvendigvis får på et vanlig nettsted der du bare besøker hjemmesiden.

Ben Aston:

Det vi snakker om, er altså noe med rikere interaktivitet og rollebasert funksjonalitet som enten er aktivert eller deaktivert, avhengig av hva du gjør i portalen.

Rebecca Germond:

Nettopp. For vår portal får du ikke mye ut av hjemmesiden med mindre du har en innlogging. Det finnes noen barrierer, og det er ikke nødvendigvis enkelt å få nye kunder inn i portalen. Det er mye å ta hensyn til som ikke gjelder for et vanlig nettsted.

Ben Aston:

Interessant. Så la oss ikke snakke abstrakt. Kan du gi oss en kort oversikt over funksjonaliteten i denne portalen?

Rebecca Germond:

Kunden vår er en elektronikkforhandler med bedriftskunder som bestiller produkter i større mengder. Før portalen ble laget, ringte kundene i praksis kundeansvarlig og la inn bestillinger manuelt. Det ga alle hodepine. Kundene ønsket ikke å ringe lenger. De ønsket en portal der brukerne kunne logge inn, se en produktkatalog som var tildelt dem, og bare handle fra disse produktene. Det var også en komplisert rabattmekanisme. Siden kundene kjøper i store mengder, får de tilpassede rabatter basert på hvor mye de kjøper og hva de kjøper.

Vi har også en utsjekkingsløsning og et dashbord der brukerne kan se produktene de bestiller oftest, åpne bestillinger og alt som er lagt inn de siste 30 dagene. Dashbordet har flere nyttige verktøy som hjelper dem å forstå hva som skjer i portalen.

Det finnes også flere brukernivåer. De fleste kundene kan legge inn en bestilling, men en kundeadministrator må godkjenne den, avhengig av organisasjonen. Før en bestilling går gjennom, må noen kunne godkjenne den eller informere brukeren om at beløpsgrensen overskrides. Det er mange detaljer å håndtere.

Ben Aston:

Så hvis jeg er en stor organisasjon og vil bestille 2 000 nye skjermer, logger jeg inn, kjøper skjermene, og så finnes det en godkjenningsprosess i utsjekkingen. Deretter kan jeg følge bestillingen.

Rebecca Germond:

Ja, nettopp.

Ben Aston:

Netthandel i stor skala.

Rebecca Germond:

Ja, nettopp.

Ben Aston:

I innlegget snakket du om interessant teknologi. Kan du gi oss en kort oversikt over teknologistakken, arkitekturen og løsningen – altså hvordan dere faktisk bygget dette?

Rebecca Germond:

Utviklerne våre kunne nok forklart det bedre, men jeg kan gi en overordnet beskrivelse.

Ben Aston:

Prosjektlederversjonen.

Rebecca Germond:

Vi bruker .NET Core til å drive mikrotjenester, og React på frontend for å levere grensesnittene til disse mikrotjenestene. Mikrotjenestene er i praksis endepunkter som kan gjenbrukes på den måten man ønsker. Hvis vi for eksempel henter data om ordrevolum, kan vi vise den på dashbordet eller bearbeide dataene på mange forskjellige måter. React er også spennende for frontend-utviklerne våre. Da vi brukte React, laget vi et komponentbibliotek som kunne gjenbrukes i ulike deler av nettstedet, slik at vi ikke måtte bygge de samme komponentene på nytt hele tiden. Vi ønsket også et konsekvent visuelt uttrykk gjennom hele nettstedet, samtidig som løsningen skulle være i tråd med merkevaren og ikke føles for ulik forbrukernettstedet.

Ben Aston:

Det finnes altså ikke noe CMS. Hvordan fungerte den prosessen? Har dere laget funksjonalitet i .NET som gjør at forhandleren kan legge til og redigere produkter? Finnes det et CMS for den delen?

Rebecca Germond:

Nei. Det fine er at all produktinformasjon kommer fra et API kunden har levert, og som de bruker på forbrukernettstedene sine. Produktinformasjonen oppdateres hele tiden. Vi har et skript som kjører én gang om dagen for å sikre at vi får de nyeste prisene og den nyeste informasjonen om produkter og spesifikasjoner. Prosessen med å legge til nye produkter er derfor fullstendig automatisert.

Ben Aston:

Dette var produktutvikling og bygging av en portal, altså noe nytt. Hvordan planla dere prosjektet eller produktutviklingen?

Rebecca Germond:

Vi brukte en MVP-tilnærming, altså et minimumsprodukt, noe som både fungerte og ikke fungerte. Etter hvert som prosjektet utviklet seg, vokste det som ble definert som MVP. I starten, da vi planla tidslinjen og estimatet, hjalp MVP-tilnærmingen oss mye. Vi hadde en ganske tydelig oppgaveliste og gikk direkte inn i utviklingssprinter. Vi brukte ikke lang tid på kravinnsamling. I stedet tok vi kravene i et sprintplanleggingsmøte for funksjonene vi skulle forsøke å fullføre i den aktuelle sprinten.

Ben Aston:

Hadde dere et budsjett og en tidsfrist for MVP-en? Dere hadde en oppgaveliste med ting som skulle bygges. Hvordan fant dere ut hva som var innenfor budsjettet? Når definerte dere budsjettet?

Rebecca Germond:

Det var vanskelig, fordi kunder i et byrå gjerne vil vite prisen på alt. Ekte smidig utvikling kan være en pris per sprint. Ved slutten av en sprint har du kanskje ikke en komplett funksjon. Vi måtte derfor estimere mer som enkeltfunksjoner, slik at kunden visste nøyaktig hva hver funksjon ville koste og kunne prioritere selv. Noen funksjoner var avhengige av andre. Da vi hadde definert hva som skulle inngå i MVP-en, kunne vi fastsette kostnaden og arbeidet som måtte gjøres for å håndtere avhengighetene. Vi hadde fem måneder på å fullføre prosjektet, med en måned med brukergodkjenning på slutten. Vi brukte omtrent to uker på miljøoppsett og tilsvarende arbeid, og hadde totalt seks eller sju sprinter.

Ben Aston:

En av tingene du nevnte i casestudien, var at dere undervurderte noen obligatoriske funksjoner kraftig, men at det også gjorde prosjektet morsomt. Hvordan og hvorfor tror du de ble undervurdert?

Rebecca Germond:

Det største vi undervurderte, var selve byggingen av katalogen og hvordan rabatten skulle legges oppå. Vi tenkte at vi bare skulle legge en rabatt på bestemte produkter. Da vi gikk inn i detaljene i API-et og alle produktkategoriene, viste det seg at det var mange ulike egenskaper og regler. Den logikken, kombinert med en rabatt, ble svært komplisert. Kunden ønsket også å utelate enkelte produkter, for eksempel Apple-produkter. Vi måtte sørge for at når kunden ba om å utelate Apple, skulle bare produkter med de riktige egenskapene vises, og rabatten skulle beregnes korrekt. Det ble svært forvirrende og komplisert.

Engasjementet var i større grad basert på fastpris. Vi kunne hente inn tid gjennom mange endringsforespørsler som kunden la til underveis, også endringer i funksjoner som var inkludert i enkeltprisene. Vi gjorde vårt beste for å følge opp prosessen for endringshåndtering. Når vi selv undervurderer arbeidet, er det vanskelig å gå tilbake til kunden og si at vi ikke gjorde jobben vår riktig.

Ben Aston:

Noe av dette skyldes vel at kravene og kompleksiteten rundt rabattberegningen ikke var tydelige fra starten?

Rebecca Germond:

Akkurat. Da vi først definerte kravene, skulle rabattmotoren vi bygget være mye mindre omfattende. Den ble mer komplisert da vi begynte å undersøke den nærmere.

Ben Aston:

Det er ofte slik i mer smidige prosjekter. Poenget med å drive smidig er nettopp at det passer når ting ikke er helt svart-hvitt, men da må kostnadsmodellen gjenspeile det. Her jobbet dere med fastpris og uklare krav. Hvordan ville du planlagt annerledes neste gang?

Rebecca Germond:

Jeg synes vi gjorde en god jobb med kravene vi hadde. Kunden og vi har nå et veldig godt samarbeid. Vi prøver å selge arbeid etter en modell med kostnad per sprint. Vi er ikke helt der ennå, men vi har stor fleksibilitet med tidslinjen, og kunden er veldig forståelsesfull. Hvis vi skulle startet på nytt, ville jeg gitt et grovt prisintervall i begynnelsen, fordi kunden trenger et tall som kan godkjennes. Deretter kunne vi estimert mer nøyaktig hva vi skulle ta tak i i hver sprint, og gitt en pris per sprint basert på antall teammedlemmer og hva vi ønsket å oppnå.

Jeg ville ellers ikke endret mye ved måten teamet jobbet på. Jeg likte at vi var få og smidige. Det blir vanskelig når mange personer er involvert på kundesiden. Her var det i praksis kunden og den relevante interessenten som måtte involveres i funksjonen vi jobbet med i sprinten.

Ben Aston:

Du snakker om et lite team, og det var en av tingene som fungerte godt. I innlegget ditt skrev du om en hybrid smidig tilnærming til utvikling og design. Hvem var med i teamet, og hvordan fikk dere design og utvikling til å fungere sammen?

Rebecca Germond:

Det er vanskelig. I et byrå er det generelt svært vanskelig å jobbe fullstendig smidig. Kundene ønsker ikke nødvendigvis å betale for et helt team i fem måneder. De vil vite hva en funksjon koster. Hvis man jobber internt med et eget produkt og har personer som kan være involvert åtte timer om dagen, fem dager i uken, er det annerledes. Når teamet er fordelt på flere prosjekter, er det svært vanskelig å jobbe smidig.

Teamet besto av to backendutviklere, to frontendutviklere, en UX-person på halv tid, en designer som kom innimellom for å kvalitetssikre designet og funksjonene, og én person innen kvalitetssikring, som vanligvis også jobbet halv tid i sprinten. Vi brukte ikke en forretningsanalytiker. Jeg synes fortsatt det var greit, fordi vi visste hva vi bygget. En forretningsanalytiker ville neppe kunnet forklare detaljene i API-et eller hjulpet oss med estimeringen. Vi hadde heller ingen strateg involvert, fordi produktet var tydelig og kunden hadde en godt definert visjon for MVP-en.

Siden vi startet fra grunnen, hadde vi ingen ferdige komponenter. Vi hadde i praksis bare merkevareretningslinjene og funksjonene som skulle bygges. Design og UX jobbet én sprint foran utviklingsteamet. I en helt smidig prosess ville man kanskje levert funksjonen sammen, men kunden hadde aldri sett noe vi hadde laget tidligere. Derfor trengte vi et forsprang for å sikre at vi var på riktig spor med uttrykk og brukeropplevelse.

Vi brukte den første sprinten til miljøoppsett, en ny distribusjonsprosess og andre prosjektoppgaver utviklerne måtte håndtere. Kunden jobbet også smidig internt, eller forsøkte å gjøre det, så arbeidsformen var ikke vanskelig for dem å forstå. De likte den godt. Vi gjennomførte seremonier som daglige møter, gjennomganger midt i sprinten, demonstrasjoner og etterevalueringer, og kunden deltok i alle eller de fleste.

Ben Aston:

La oss snakke om kunden. Det fine var at kunden også var produkteier. Dere hadde ikke mange interessenter, men én hovedinteressent. Samtidig fant kunden opp nye funksjoner og oppgaver underveis. Hvordan håndterte dere det med et fast budsjett og en smidig tilnærming?

Rebecca Germond:

Det var vanskelig, men hver gang han fant på en ny funksjon, forsto han at det var en endringsforespørsel som måtte prises. Utfordringen var at vi måtte stoppe opp i sprintarbeidet for å lage et estimat, og estimatet måtte godkjennes før funksjonen kunne bygges. Kunden fungerte i praksis som produkteier og hadde full selvstendighet i hvordan prosjektet skulle drives. Det var bra at de hentet oss inn da de gjorde det, fordi vi kunne bidra med tilbakemeldinger og ideer til funksjoner de ikke hadde vurdert.

Et eksempel var at de først planla å registrere kundene manuelt og sende dem PDF-filer med informasjon. Etter den tredje sprinten bestemte vi oss for å lage en oppsettsveiviser. Brukerne kunne få brukernavn og passord på e-post, logge inn, tilbakestille passordet, laste ned skjemaene de måtte fylle ut og laste dem opp igjen i systemet. Det gjorde arbeidet enklere for kundens team og gjorde produktet bedre enn vi opprinnelig hadde planlagt.

Ben Aston:

Du nevnte flere lærdommer. Én var å holde teamet engasjert og kunden involvert. Kunden var tydeligvis svært involvert. Hvilke råd har du for å skape og opprettholde dette engasjementet?

Rebecca Germond:

Arbeidsformen var ny for FCV, fordi mange av kundene våre er tradisjonelle eller offentlige kunder som har jobbet med oss i mange år og er vant til bestemte arbeidsmåter. Måten vi involverte kunden på, fungerte svært godt. Vi oppdaget at kunder faktisk ønsker å være involvert på dette nivået. Vi ønsket også å holde kunden engasjert fordi vi ville ha en fase to. Dette var ikke bare et nettsted som avsluttes etter lansering, men et levende produkt som skulle utvikles videre.

Teamet ønsket å jobbe med prosjektet fordi de fikk velge teknologistakk og verktøy og gjøre noe nytt. De likte også å ha en plattform for dialog med kunden. Kunden var med i Slack og kunne diskutere ideer direkte med frontendutvikleren eller andre som måtte involveres. Teamet var engasjert fordi de bygget noe de virkelig brydde seg om.

Ben Aston:

Du snakket også om å fjerne prosesser man ikke trenger, men ta vare på dem man trenger. Hvilke prosesser fjernet dere?

Rebecca Germond:

Etter den andre sprintgjennomgangen bestemte vi oss for å slutte med dem. Vi visste hva som fungerte og ikke fungerte, og tiden vi brukte på gjennomgangen, hjalp oss ikke. Den tok bare tid fra utviklingen. Kunden var dessuten så involvert at han kunne gi oss tilbakemeldinger underveis. Dette var en prosess vi avsluttet ganske tidlig.

Det var også vanskelig å ha faste daglige møter fordi halve teamet var i Toronto og halve i Vancouver. Vi prøvde derfor å hoppe inn i et kort møte når det var nødvendig for å fjerne blokkeringer, i stedet for å bruke en time på Slack.

Ben Aston:

Så dere hadde tilfeldige møter og ikke et fast møte klokken ni hver dag?

Rebecca Germond:

Vi prøvde først klokken 9.30. Vi holdt på i tre sprinter, men da vi kom inn i en god rytme, gikk vi over til møter annenhver dag eller dialog i Slack.

Ben Aston:

Var det noen prosesser dere fjernet, men senere tok tilbake fordi dere innså at det var en dårlig idé?

Rebecca Germond:

Ikke egentlig. En prosess vi skulle ønske vi hadde startet tidligere, var kvalitetssikring. Vi hadde egentlig ikke noe klart for kvalitetssikring før den tredje sprinten, og burde ha startet tidligere. Ved noen demonstrasjoner jobbet vi helt frem til fem minutter før møtet, sendte inn kode og håpet at den fungerte. Vi jobbet som cowboyer mot slutten, men det var veldig morsomt.

Ben Aston:

Rebecca, tusen takk for at du ble med. Det har vært flott å ha deg her.

Rebecca Germond:

Takk. Når som helst.

Ben Aston:

Hvis du er interessert i portalbygging, kan du lese casestudien Rebecca har skrevet. Der finnes mye informasjon som kan være nyttig. Hvis du vil diskutere portalbygging, kan du også besøke Slack-teamet vårt. Gå til digitalprojectmanager.com/slack, så finner du mange interessante samtaler om alt som gjelder digital prosjektledelse. Hvis du likte dagens program, kan du gå til Apple Podcasts, tidligere kjent som iTunes, og legge igjen en anmeldelse. Vi setter stor pris på tilbakemeldinger, og vurderinger og anmeldelser hjelper oss virkelig. Takk for at du lyttet, så høres vi neste gang.