Håndtering af opbygningen af en webportal (med Rebecca Germond fra FCV Interactive)

Læs transskriptionen:

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle slåfejl, da botten ikke er korrekt 100 % af tiden.

Ben Aston:

Velkommen til DPM-podcasten, hvor vi går ud over teorien for at give ekspertråd om projektledelse, så du kan lede bedre digitale projekter. Tak fordi du lytter med. Jeg hedder Ben Aston og er grundlægger af The Digital Project Manager.

Kundernes behov bliver mere modne, og de digitale bureauers rolle ændrer sig og udvikler sig også. I takt med at processen for design og opbygning af websites er blevet mere standardiseret, er der et voksende behov for bureauer, der kan være mere end blot en websitepartner, men også en strategisk og teknisk partner, som kan opbygge mere end bare websites, kampagner og landingssider. I dagens podcast går vi lidt i dybden med portalopbygninger: hvad de er, hvordan man bygger dem, samt nogle erfaringer og lærte erfaringer, hvis du skal i gang med et af disse projekter. Lyt med, hvis du vil høre mere om udviklingen af digitale bureauer og en produktudviklingstilgang til kundeengagement.

I dag har jeg besøg af Rebecca Germond. Rebecca er direktør for kundeservice hos FCV. Hun har et stærkt fundament inden for projektledelse og mediekommunikation. Rebecca er faktisk en, jeg ansatte for nogle år siden. Jeg husker din jobsamtale, hvor jeg hentede dig ind i rummet, og jeg tænkte: ja, selvfølgelig ansætter jeg denne pige. Jeg kan ikke rigtig huske, hvad jeg spurgte dig om, men jeg tænkte: Jeg behøver ikke engang interviewe dig. Du er ansat. Kan du huske jobsamtalen?

Rebecca Germond:

Jeg kan huske jobsamtalen. Jeg følte, at jeg blev grillet. Nej, jeg laver bare sjov. Jeg husker den virkelig godt, fordi jeg husker udsigten fra kontoret, og det var vist det, der solgte FCV til mig, ud over selvfølgelig vores samtale.

Ben Aston:

Det var ikke mig. Det var udsigten.

Rebecca Germond:

Ja.

Ben Aston:

Rebecca, for dem der spekulerer på, hvad du laver hver dag: Hvad indebærer rollen som direktør for kundeservice? Er det projektledelse? Er det account management? Hvad betyder det for dig lige nu?

Rebecca Germond:

Ja, det er lidt af begge dele, plus ledelse af selve projektlederteamet, hvilket er fedt. Det er en ny rolle for mig inden for det seneste års tid. Jeg arbejder ikke længere helt så meget direkte med projekterne. Der er nogle få, jeg ikke vil give slip på, men grundlæggende arbejder jeg direkte sammen med projektlederne og sørger for, at de kan levere og får den støtte, de har brug for. Jeg håndterer også de fleste af vores kunder, så jeg har et ret godt account manager-agtigt forhold til dem. Jeg startede faktisk i kundekonti, før jeg blev producerende projektleder, så det er lidt tilbage til mine rødder, hvilket er fedt.

Ben Aston:

Fint. For dem, der er interesserede i rollen med at lede et team af projektledere: Hvordan ser det ud dag efter dag? Hvordan leder du dem? Du kan jo ikke hele tiden være inde i detaljerne i alle deres projekter. Hvad gør du egentlig, når du følger op med dem?

Rebecca Germond:

Ja, det er et godt spørgsmål. For det meste gennemgår jeg en masse arbejde eller leverancer, som de gerne vil sende ud. For eksempel giver jeg dem feedback på en arbejdsbeskrivelse eller en tidsplan. Hvis der opstår eskaleringer, involverer jeg mig, eller jeg hjælper projektlederne med at finde ud af, hvordan de skal reagere på vanskelige situationer. Jeg mødes med dem individuelt hver uge, men jeg holder også kontakt via Slack og sørger for, at alle føler sig støttet fra dag til dag. En gang imellem deltager jeg i deres vigtigste kundemøder. Det er lidt af det hele.

Jeg er også stærkt involveret i vores forretningsudviklingsproces hos FCV. Jeg arbejder også med den daglige håndtering af, hvor meget vi faktisk skal fakturere vores kunder, og om vi sørger for at følge vores proces for ændringshåndtering godt nok. Der er også mange andre ting i det daglige arbejde med projektlederne.

Ben Aston:

Fortæl os lidt om din historie. Din baggrund var inden for account management. Jeg ved faktisk, at du startede din karriere i Arbejdsministeriet. Hvordan kom du fra Arbejdsministeriet til et digitalt bureau og videre til account management og projektledelse? Hvordan så det ud for dig?

Rebecca Germond:

Helt sikkert. Da jeg gik i skole, havde min tante et vikarbureau. Hun placerede mig i forskellige jobs, mens jeg prøvede at finde det rigtige sted. Jeg vidste, at jeg gerne ville arbejde på et bureau. Jeg fik en plads i Arbejdsministeriet. Det var mere et administrativt job for staten, men det var ret spændende. Det lærte mig meget om, hvordan staten fungerer, og det hjalp mig faktisk senere i min karriere, fordi de fleste af de projekter, jeg arbejdede på i mit første bureau, og mange af de projekter, jeg arbejder på nu hos FCV, er relateret til det offentlige. Det var nyttigt.

På et tidspunkt fik hun mig placeret hos et bureau, Manifest Communications i Toronto. Jeg skulle kun være der i to uger og arbejde i receptionen, mens en var på ferie, men de bad mig blive som praktikant, hvilket jo netop var det, jeg forsøgte at opnå. Jeg var der i tre måneder, hvorefter de ansatte mig, og jeg arbejdede der i fire år. Da jeg startede, var jeg account executive, så jeg håndterede kunder og i mindre grad digitale projekter. Det udviklede sig langsomt. Efter mit første år blev jeg producer, og det var nok omkring 60 % digitalt, men jeg arbejdede også med radio, tv og noget trykt materiale, hvilket var ret fedt.

Ben Aston:

Fint. Fortæl mig: Vi er stadig i årets første kvartal. Set fra et karriere- eller udviklingsperspektiv taler vi i dag om portaler, og hvordan det er en form for udvikling, men har du sat dig nogle mål for året?

Rebecca Germond:

Det er faktisk sjovt. Jeg har ikke rigtig lyst til at have specifikke karrieremål i år. Det lyder mærkeligt. Jeg er i mit sidste år i 20'erne, så jeg vil egentlig bare leve som en millennial. Jeg har nogle rejsemål. Det er det, der fylder for mig. Karrieremæssigt har jeg virkelig elsket at arbejde på dette portalprojekt. Vi har gjort det til et produkt, og vi laver hele tiden udgivelser og forsøger at bygge videre på noget. Jeg synes, det er rigtig godt. Jeg vil gerne lave mere arbejde af den slags.

Ben Aston:

Fedt. Vi talte lidt om, hvad din rolle indebærer, men hvilke udfordringer arbejder du måske med lige nu, eller hvad er den største hovedpine, du forsøger at overvinde i hverdagen eller særligt nu i forbindelse med et bestemt projekt eller noget andet?

Rebecca Germond:

Jeg tror, at jeg i hverdagen er vant til at passe på et projektteam, hvis du forstår, hvad jeg mener. Som projektledere må vi alle håndtere mange egoer eller forskellige personlighedstyper. Nu befinder jeg mig mere på et niveau, hvor det handler om færre projekter, men faktisk om alle i organisationen, som har forskellige behov og prioriteter, og om at forsøge at jonglere det samtidig med, at projektlederne får det, de har brug for, fordi det er meget vigtigt. Det synes jeg kan være lidt svært. Man bliver også trukket ind i ting, som man måske ikke synes er så betydningsfulde, for eksempel administrative opgaver. Jeg ved det ikke. Det er bare svært at holde styr på sin egen opgaveliste i disse dage.

Ben Aston:

Hvordan holder du styr på tingene? Hvordan ser din opgaveliste ud? Har du et system?

Rebecca Germond:

Jeg bruger primært Evernote til min opgaveliste, men vi har lige tilføjet en ny Slack-integration, der hedder Workast, hvor man kan have sin opgaveliste i en faktisk Slack-kanal og tildele opgaver, hvis man har brug for det. Man kan også bare skrive en note til sig selv i Slack, så er opgavelisten der, og den giver dig en påmindelse om, hvornår tingene skal være færdige. Vi er meget tidligt i brugen af den, men indtil videre er den ret smart.

Ben Aston:

Den hedder Workast?

Rebecca Germond:

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

Ben Aston:

Workast, okay. Det er et lidt sjovt navn.

Rebecca Germond:

Helt sikkert. Indtil videre går det godt. Problemet er, at man ikke når sin opgaveliste før enten klokken 9 eller efter klokken 17. Sådan føles det for mig, fordi 70 % af min dag enten går med møder i telefonen eller med at svare på e-mails og beskeder i Slack, hvilket gør det virkelig svært at være produktiv i disse dage.

Ben Aston:

Hvad har du ellers i din værktøjskasse som projektleder? Du har dit system til opgavelisten, som naturligvis hjælper dig med at prioritere det vigtigste. Hvad har du ellers i værktøjskassen? Hvordan håndterer du projekter?

Rebecca Germond:

Jeg har en del værktøjer. Vi har skiftet frem og tilbage mellem nogle forskellige i løbet af de seneste par år, men nu er jeg ret tilfreds med det, vi har. Som sagt bruger jeg Evernote. Vi bruger Jira ret seriøst nu. Alle, inklusive vores UX- og designfolk samt alle vores kunder, er i Jira, hvilket gør det nemmere for os, fordi alt i det mindste er samlet ét sted, og vi kan holde styr på sager. Vi bruger Slack. Det bruger jeg ret konsekvent.

Vi tester Microsoft Teams i stedet for Skype for Business. Vi bruger det i en konferenceindstilling til vores møder med kunder. Det har fungeret ret godt. Jeg bruger Merlin til projektplanlægning. Vi plejede at bruge MS Project, men jeg synes, at vi kun anvender 15 % af funktionerne. Vi har et par MS Project-licenser liggende, hvis kunden får brug for dem. Spotify er helt sikkert også i min værktøjskasse. Det har jeg brug for. Og Outlook, selv om e-mail er min eksistens bane.

Ben Aston:

Ud over Workast, er der så andre værktøjer, du for nylig er stødt på, eller noget, der har revolutioneret den måde, du håndterer projekter på?

Rebecca Germond:

Ikke rigtig. Jeg synes, måden vi nu bruger Jira på, faktisk er blevet bedre, fordi vi integrerer det med vores Slack-kanal. Hvis en sag opdateres, eller status ændres, eller en kunde kommenterer på den, sender Jira naturligvis 40 e-mails i minuttet, når noget opdateres. Kun de vigtigste ting sendes til Slack-kanalen, så man ved, hvis nogen har kommenteret på en sag. Det har virkelig gjort det nemmere, fordi ingen læser Jira-e-mails. MS Teams er faktisk ret smart, fordi de fleste af vores kunder ikke ville bruge video, men nu er der mange, der har taget det til sig, efter vi skiftede til MS Teams.

Ben Aston:

Fint. Lad os tale om dit indlæg og dit casestudie, det første casestudie du nogensinde har udgivet. Tillykke, Rebecca.

Rebecca Germond:

Tak.

Ben Aston:

Lad os tale om en portal. Er en portal bare et website, eller er den anderledes? Hvis den er anderledes, hvorfor og hvordan?

Rebecca Germond:

For mig er portaler ret komplekse, fordi de generelt er skræddersyet til mange forskellige brugere, som hver især kan have mange handlinger, funktioner eller brugerrejser. For denne konkrete portal var der tre forskellige brugerniveauer, vi skulle tage højde for, og hvordan de påvirkede hinanden, var noget, jeg tror, vi undervurderede i begyndelsen. Portaler kan generelt blive ret komplekse på grund af alle de forskellige funktioner og sammenhænge, som man ikke nødvendigvis får på et almindeligt website, hvor man bare besøger forsiden.

Ben Aston:

Det, vi taler om, er altså noget med mere avanceret interaktivitet i form af rollebaseret funktionalitet, der enten er aktiveret eller deaktiveret afhængigt af, hvad man foretager sig i portalen.

Rebecca Germond:

Præcis. For vores portal får du ikke meget ud af forsiden, medmindre du har et login. Der er nogle barrierer på plads, og det er ikke nødvendigvis nemt at onboarde nye kunder i portalen. Der er mange ting at tage højde for, som simpelthen ikke gælder for et almindeligt website.

Ben Aston:

Interessant. Så lad os ikke tale abstrakt. Giv os et kort overblik over, hvilken funktionalitet denne portal har.

Rebecca Germond:

Denne portal ... Grundlæggende er vores kunde en elektronikforhandler, og de har B2B-kunder, altså virksomheder, der gerne vil bestille produkter hos dem i større mængder. Før de havde en portal, ringede de grundlæggende til deres account manager og afgav en ordre på en meget, meget manuel måde. Det gav alle hovedpine. Kunderne havde også problemer med det, fordi ingen længere har lyst til at tage telefonen. De ønskede en portal, hvor man kan logge ind, se et produktkatalog, der er tildelt den enkelte bruger, og kun handle blandt disse produkter. Derudover anvendes en kompliceret rabatmekanisme, fordi kunderne ellers bare kunne gå ind på forbrugerwebsitet og købe det, de havde brug for. Da de køber stort ind, får de skræddersyede rabatter baseret på, hvor meget de køber, og hvad de køber. Det er ét aspekt.

Vi har også en betalingsside. Vi har et kontrolpanel, hvor brugerne kan se de produkter, de bestiller oftest. De kan se åbne ordrer, de har, og alt, der er bestilt inden for de seneste 30 dage. Der er nogle smarte værktøjer i kontrolpanelet, som hjælper dem med at se, hvad der foregår i deres del af portalen.

Der er også flere forskellige brugerniveauer blandt dem, der bare kan handle. De fleste kunder kan gå ind og afgive en ordre, men derefter skal en kundeadministrator godkende den, afhængigt af organisationen. Før en ordre går igennem, skal nogen kunne godkende den eller fortælle dem, at de overskrider vores budget, så vi ikke kan gennemføre ordren. Der er mange detaljer i det.

Ben Aston:

Interessant. Hvis jeg for eksempel er en stor organisation, lad os sige Telus, og jeg vil bestille 2.000 nye skærme, logger jeg bare ind i systemet, køber mine skærme, og derefter er der også en godkendelsesproces ved betalingen, hvorefter jeg kan følge min ordre.

Rebecca Germond:

Ja, præcis.

Ben Aston:

Det er e-handel i stor skala.

Rebecca Germond:

Ja, præcis.

Ben Aston:

Fedt. I indlægget talte du lidt om at bruge noget interessant teknologi. Kan du give os en kort version af teknologistakken, arkitekturen og løsningen, altså hvordan I faktisk byggede det? Hvad gjorde det interessant?

Rebecca Germond:

Vores udviklere kunne helt sikkert forklare det bedre, men jeg kan give et overordnet billede.

Ben Aston:

Projektlederversionen.

Rebecca Germond:

Vi bruger .NET Core til at drive mikrotjenester, og derefter bruger vi React på frontend til at levere grænsefladerne til disse mikrotjenester. Grundlæggende betyder det, at mikrotjenesterne bare er endepunkter, som kan genbruges på den måde, man ønsker. Hvis man for eksempel får data om ordrevolumen, kan man vise dem i kontrolpanelet eller bearbejde dataene på mange forskellige måder. Det er virkelig smart. React er naturligvis spændende for vores frontendudviklere, og de kan godt lide at arbejde med det. Da vi brugte React, oprettede vi et komponentbibliotek, som vi kunne genbruge på forskellige områder af websitet, så vi ikke hele tiden skulle genopbygge de samme komponenter. Vi ville også skabe et ensartet udtryk på hele websitet, som stadig fulgte kundens brand og ikke føltes som et stort brud med deres forbrugerwebsite.

Ben Aston:

Fint. Der er ikke noget CMS. Hvordan foregik den proces? Har I i .NET oprettet funktionaliteten, så forhandleren kan tilføje og redigere produkter? Er der et CMS til den del? Hvordan fungerer det?

Rebecca Germond:

Nej. Det smarte er, at alle produktoplysninger og produktdata kommer fra en API, som kunden har leveret, og som de bruger på deres forbrugerwebsites. Alle produktoplysninger opdateres hele tiden. Vi har et script eller noget tilsvarende, der kører én gang om dagen for at sikre, at vi har de nyeste priser og de mest opdaterede produktoplysninger, specifikationer og den slags. Det er en fuldstændig automatiseret proces, når der skal tilføjes et nyt produkt, hvilket er ret smart.

Ben Aston:

Det er smart. Det var produktudvikling, hvor I byggede en portal. Det var noget nyt. Fortæl mig, hvordan I planlagde projektet eller produktudviklingen. Hvilken proces brugte I til at planlægge opbygningen?

Rebecca Germond:

Vi brugte helt klart en MVP-tilgang, altså et minimumslevedygtigt produkt, hvilket både fungerede og ikke fungerede, fordi det, der blev til MVP'en, voksede undervejs. Det var egentlig slet ikke minimalt. I begyndelsen, da vi planlagde tidsplanen og estimatet, hjalp MVP-tilgangen os en del. Fordi vi havde en ret veldefineret backlog, gik vi direkte i gang med udviklingssprints. Vi brugte ikke lang tid på indsamling af krav. Vi gennemgik kravene på et sprintplanlægningsmøde for de funktioner, vi ville forsøge at færdiggøre under sprintet.

Ben Aston:

Var der et budget og en deadline for MVP'en? I havde en backlog med ting, der skulle bygges. Hvordan fandt I ud af, hvad der var inden for budgettet, og hvad der lå udenfor? Hvornår fastlagde I budgettet? For det er vel en af de store udfordringer her.

Rebecca Germond:

Det var det. Det var det virkelig, fordi det vanskelige ved at arbejde agilt i en bureaukontekst er, at kunderne vil se en pris på alt. Ægte agil udvikling er måske en model med en pris pr. sprint. Ved afslutningen af et sprint har man måske ikke en færdig funktion. For at håndtere estimatet forsøgte vi at give dem en mere à la carte-pris pr. funktion, så de vidste præcis, hvad en bestemt funktion ville koste, og selv kunne prioritere dem efter behov. Nogle funktioner var afhængige af andre. Da vi havde fastlagt præcist, hvad der indgik i MVP'en, bestemte vi omkostningen og præcis, hvad der skulle gøres, for at alle afhængigheder også kunne fungere. På baggrund af à la carte-prisen forsøgte vi at samle arbejdet lidt, så det kunne fungere i en sprintmodel. Vi vidste, at vi havde fem måneder til at færdiggøre projektet og en måned med brugeraccepttest til sidst. Jeg tror, vi brugte to uger på miljøopsætning og den slags. I alt havde vi vist seks eller syv sprints.

Ben Aston:

En af de ting, du nævner i casestudiet, er, at I kraftigt undervurderede nogle af de obligatoriske funktioner, men at det var det, der gjorde det sjovt. Det, jeg læser mellem linjerne, er, at I undervurderede nogle af de à la carte-elementer. Hvordan og hvorfor blev de undervurderet?

Rebecca Germond:

Jeg tror, den største ting, vi undervurderede, var selve opbygningen af kataloget og derefter tilføjelsen af rabatten. Vi tænkte: Nå ja, vi tilføjer bare en rabat til bestemte produkter. Men når man kommer ned i detaljerne i deres API og alle de forskellige produktkategorier, har de alle mulige facetter. Den logik kombineret med en rabat oveni blev meget, meget, meget kompliceret. Der var endnu et lag, fordi de faktisk ønskede at udelukke nogle produkter. Apple havde for eksempel ikke en særlig stor avance, så de ville aldrig give rabat på et Apple-produkt. Vi skulle sikre, at hvis de sagde, at brandet Apple skulle udelukkes, så viste man kun produkter med de ønskede egenskaber og ikke Apple-produkter, hvorefter rabatten skulle lægges oveni. Det blev virkelig forvirrende og kompliceret.

Desværre var det med denne kunde et projekt til fast pris. Vi kunne tjene pengene igen eller få ekstra tid gennem de mange ændringsanmodninger, de tilføjede undervejs, eller ændringsanmodninger til funktioner, der allerede var inkluderet i à la carte-prisen. Vi gjorde vores bedste for at holde styr på processen for ændringshåndtering. Når det bare handler om, at vi selv har undervurderet noget, er det meget svært at gå tilbage til kunden og sige: Undskyld, vi gjorde ikke helt vores arbejde rigtigt.

Ben Aston:

En del af problemet er vel også, at kravene, og især kompleksiteten omkring rabatterne, ikke var tydelige helt fra begyndelsen?

Rebecca Germond:

Præcis. Da vi opstillede de oprindelige krav, skulle rabatmotoren eller hvad det nu var, vi byggede, være langt mindre omfattende. Det blev bare lidt besværligt, da vi gik mere i dybden.

Ben Aston:

Det er ofte sådan med mere agile projekter. Hele pointen med at køre et projekt mere agilt er, at det passer til en situation, hvor tingene ikke er helt sort-hvide, men så skal omkostningsmodellen også afspejle det. Her arbejdede I naturligvis med en fast pris og uklare krav. Ud fra det, du ved nu, hvordan ville du planlægge det anderledes næste gang?

Rebecca Germond:

Jeg synes, vi gjorde et godt stykke arbejde med de krav, vi havde. Det, jeg gerne ville forsøge med denne kunde, er at sælge tingene efter en model med en pris pr. sprint. Vi er ikke helt nået dertil, men vi har stor fleksibilitet i tidsplanen med ham, og han er meget forstående, hvilket er fantastisk. Hvis vi skulle starte forfra næste gang, ville jeg måske give dem et groft estimat i begyndelsen, fordi de har brug for at få et tal godkendt.

Hvis vi gav dem et godt interval og derefter vurderede mere præcist, hvad vi ville tage fat på i hvert sprint, kunne vi give dem en pris pr. sprint afhængigt af, hvor mange teammedlemmer vi havde brug for, og hvad vi håbede at nå. Det ville måske være bedre. Overordnet ville jeg ikke ændre meget ved den måde, vi arbejdede på som team. Jeg kunne godt lide, at vi var et lean team. Det bliver svært, hvis der er mange mennesker involveret på kundesiden. Det var i praksis kun ham og den relevante interessent, som skulle involveres i den funktion, vi arbejdede på i sprintet. Det var også rigtig godt.

Ben Aston:

Fedt. Du taler om et lille team, og det var en af de ting, der fungerede godt. I dit indlæg talte du om en hybrid agil tilgang til udvikling og design. Kan du fortælle, hvordan det så ud med hensyn til, hvem der var på teamet? Det var et lille team. Hvordan fik I design og udvikling til at fungere sammen?

Rebecca Germond:

Ja, det er svært. Jeg synes generelt, at det er virkelig svært at arbejde fuldt agilt i et bureau. Kunderne er ikke altid åbne over for at betale for et team i fem måneder i træk. De vil vide, hvad funktionen kommer til at koste. De køber ikke et helt team, og det er svært at ændre den opfattelse. Hvis man arbejder internt og bygger sit eget produkt med dedikerede medarbejdere, der kan være involveret otte timer om dagen, fem dage om ugen, er det lidt anderledes. Når man har flere projekter i gang, er det virkelig svært at arbejde agilt.

Vores team bestod af to backendudviklere, to frontendudviklere, en UX-person på halv tid, en designer, som nok kom forbi en gang imellem for at gennemgå vores design eller funktioner, samt én tester, som normalt også arbejdede halvtid under sprintet, altså 50 % dedikeret. Vi brugte ikke en forretningsanalytiker, hvilket jeg stadig synes var fint. Det var ikke rigtig til vores ulempe, fordi vi vidste, hvad vi byggede. Jeg tror ikke, at en forretningsanalytiker kunne have fortalt os detaljerne i deres API eller noget i den stil. Det ville ikke have hjulpet os med selve estimeringsprocessen. Vi havde heller ingen strateg involveret, fordi produktet var meget enkelt, og kunden havde en veldefineret vision for MVP'en samt et stærkt anvendelsesscenarie. Det var teamet. Og selvfølgelig mig.

Fordi vi startede fra bunden, havde vi ingen eksisterende komponenter. Vi havde grundlæggende bare brandretningslinjer at bruge og derefter den enkelte funktion. Design og UX arbejdede faktisk et sprint foran udviklingsteamet, hvilket man nok ikke ville få i en ægte agil proces. Her ville man forsøge at levere en funktion sammen, men kunden havde aldrig set noget, vi havde lavet før, så vi havde brug for et forspring for at sikre, at vi var på rette spor med udtryk og den slags.

Vi brugte det første sprint, hvor design og UX arbejdede foran, på miljøopsætning og alt det, vi skulle have på plads, fordi det var en helt ny distributionspipeline. Udviklerne skulle også håndtere alle de andre opsætningsopgaver. Kundens organisation arbejdede selv agilt, eller forsøgte i hvert fald at gøre det internt. Det var derfor ikke svært for dem at forstå, og de kunne virkelig godt lide arbejdsformen. Vi gennemførte stadig alle de agile ceremonier, som daglige møder, midtvejsreviews, demonstrationer og retrospektiver, og kunden deltog i alle eller de fleste af dem.

Ben Aston:

Lad os tale om kunden. Det gode ved dette scenarie var, at kunden var produktansvarlig, ikke? I havde ikke en masse interessenter. I havde én enkelt interessent, hvilket er smart. Du nævnte, at de var gode, men du skrev også i dit indlæg, at kunden fandt på nye funktioner og opgaver undervejs. Hvordan håndterede I det, når I arbejdede med et fast budget og en agil tilgang, hvor det er helt rimeligt, at kunden finder på nye funktioner og opgaver?

Rebecca Germond:

Det var bestemt svært, men hver gang han fandt på en ny funktion, forstod han, at det var en ændringsanmodning, og at vi skulle give et tilbud på den. Problemet var, at det gjorde det vanskeligt at stoppe det arbejde, man var i gang med i sprintet, for at lave et estimat til ham, fordi han skulle bruge estimatet for at kunne godkende funktionen. Det gjorde tingene lidt interessante. Kunden fungerede grundlæggende som produktejer, og hans team gav ham fuld autonomi over, hvordan projektet skulle drives. Jeg tror, de havde planlagt det i et stykke tid, før vi kom med ombord. Det var rigtig godt, at de hentede os ind, da de gjorde, fordi vi kunne give feedback og idéer til nye funktioner og ting, de ikke havde overvejet.

Han havde nogle sjove funktioner med, som han fandt på undervejs, men de var alle meget vigtige. Før opbygningen forventede de for eksempel stadig at onboarde kunderne manuelt, sende dem en PDF med oplysninger om tilmelding og den slags. Efter det tredje sprint besluttede vi, at vi ville lave en opsætningsguide, så folk kunne få et login og en adgangskode fra en e-mail, vi sendte dem. De kunne nulstille deres adgangskode, downloade de formularer, de skulle udfylde, og uploade dem til systemet igen. Det gjorde det nemmere for deres team at håndtere. Selvom vi ikke havde forventet det, gjorde det det samlede produkt virkelig godt.

Ben Aston:

Det er smart. Du talte om nogle af de erfaringer, I havde lært. En af tingene var, at man skal holde teamet engageret og kunden involveret. Det lyder, som om kunden var meget involveret. Hvad er dine råd til at opretholde og skabe det engagement fra starten?

Rebecca Germond:

For os var hele arbejdsformen ny hos FCV, fordi mange af vores kunder er gamle kunder eller offentlige kunder. De har arbejdet sammen med os i mange år, men de sidder fast i deres vaner. Den måde, vi fik vores kunde engageret og involveret på, virkede virkelig godt, fordi vi så, at kunder faktisk gerne vil være involveret på dette niveau. Det var interessant. Vi ville også gerne have ham engageret, fordi vi ønskede en fase to af projektet. Vi ville virkelig gerne fortsætte. Vi kunne se, at det ikke bare var et website, der sluttede ved afslutningen af sin livscyklus. Det var en levende ting. Det var derfor godt at holde ham engageret.

Teamet ville virkelig gerne arbejde på det, fordi de fik lov til at vælge deres teknologistak. De kunne lave noget nyt og vælge deres egne værktøjer. De kunne også godt lide at have en platform, hvor de kunne tale med kunden, selv om nogle måske ikke ville bryde sig om det. Det afhænger af teamet, men vi har kunden i Slack. Han kan bare sparre med vores frontendudvikler eller den, der har brug for at være med, så det fungerer godt. Jeg tror, de er engagerede, fordi de bygger noget, de faktisk interesserer sig meget for.

Ben Aston:

En af de ting, du talte om i forbindelse med jeres lærte erfaringer, var at fjerne processer, I ikke har brug for, men omfavne dem, I har brug for. Du nævnte, at en af fordelene ved projektet var den forbedring, det medførte for bureauets projektproces. Kan du fortælle om nogle processer, I droppede, eller om noget af den forbedring, I kunne integrere i andre projekter?

Rebecca Germond:

Ja, helt sikkert. Efter vores anden sprintretrospektiv besluttede vi at droppe dem. Vi tænkte, at vi vidste, hvad vi gjorde godt, og hvad vi ikke gjorde godt. Det hjalp ikke rigtig at bruge tid på det. Det tog bare tid fra udviklingen, hvilket ikke var det, vi ønskede. Fordi kunden var så involveret, kunne han også give os feedback undervejs, hvis noget ikke fungerede for ham, eller hvis vi skulle tilpasse processen eller tænke over noget til næste sprint. Det var noget, vi droppede ret tidligt.

Det var også svært at holde daglige møder, fordi halvdelen af teamet var i Toronto, og den anden halvdel var i Vancouver. Vi forsøgte at respektere, at det er bedre bare at hoppe på et 15-minutters møde for at fjerne blokeringer end at forsøge at gøre det via Slack i en time.

Ben Aston:

I havde altså tilfældige møder, ikke en daglig ceremoni klokken 9 eller 12. De var bare ad hoc.

Rebecca Germond:

Ja, det var klokken 9.30. Vi forsøgte at få det til at fungere, men da vi kom ind i en god rytme, blev det ad hoc, eller vi hoppede bare ind i Slack og stillede nogle spørgsmål. Vi gjorde det dagligt i omkring tre sprints, men derefter gik vi over til hver anden dag eller til Slack.

Ben Aston:

Fint. Var der en proces, I forsøgte at droppe, fordi I tænkte, at I ikke havde brug for den, men som I senere genindførte, da I indså, at det var en dårlig idé?

Rebecca Germond:

Ikke rigtig, men en af de processer, vi ville ønske, vi havde fået på plads tidligere, var kvalitetssikring. Vi havde faktisk ikke noget klar til kvalitetssikring før det tredje sprint, og vi burde nok have startet lidt tidligere. Jeg husker et par demonstrationer, hvor vi arbejdede indtil fem minutter før, indsendte noget kode og bare håbede, at det holdt og virkede. Vi arbejdede som cowboys til sidst, men det var virkelig sjovt.

Ben Aston:

Godt. Rebecca, mange tak fordi du ville være med. Det har været fantastisk at have dig med.

Rebecca Germond:

Tak. Når som helst.

Ben Aston:

Det var en fornøjelse. Hvis du er interesseret i portalopbygninger, så se casestudiet, som Rebecca har skrevet. Der er masser af oplysninger, du måske kan bruge. Hvis du vil tale om portalopbygninger, kan du også besøge vores Slack-team. Gå til digitalprojectmanager.com/slack, hvor du finder alle mulige interessante samtaler om alt inden for digital projektledelse. Hvis du kunne lide dagens udsendelse, må du også meget gerne gå til Apple Podcasts, tidligere kendt som iTunes, og skrive en anmeldelse. Vi vil meget gerne høre din feedback, og vurderinger og anmeldelser er virkelig nyttige og hjælper os med udsendelsen. Indtil næste gang: Tak fordi du lyttede.