Hantera ett webbportalbygge (med Rebecca Germond från FCV Interactive)

Läs transkriberingen:

Vi testar att transkribera våra poddavsnitt med hjälp av ett datorprogram. Ha överseende med eventuella skrivfel eftersom boten inte är korrekt till 100 procent hela tiden.

Ben Aston:

Välkommen till DPM-podden, där vi går bortom teorin för att ge expertråd till projektledare som vill leda bättre digitala projekt. Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager.

Kundernas behov blir allt mer utvecklade, och de digitala byråernas roll förändras och utvecklas också. I takt med att processen för webbdesign och webbutveckling har blivit allt mer standardiserad finns ett växande behov av byråer som kan vara mer än bara en webbplatspartner, utan även en strategisk och teknisk partner som bygger mer än bara webbplatser, kampanjer och landningssidor. I dagens poddavsnitt ska vi nörda ner oss lite i portalbyggen, vad de är, hur man bygger dem och några lärdomar om du ska ge dig in i ett sådant projekt. Fortsätt lyssna om du vill få en inblick i de digitala byråernas utveckling och ett produktutvecklingsinriktat sätt att samarbeta med kunder.

I dag har jag sällskap av Rebecca Germond. Rebecca är kundservicechef på FCV. Hon har en stark grund inom projektledning och mediekommunikation. Rebecca är faktiskt någon som jag anställde för några år sedan. Jag minns din intervju, när jag tog in dig i rummet och tänkte: ja, visst, jag anställer den här tjejen. Jag minns egentligen inte vad jag frågade dig, men jag tänkte att jag inte ens behövde intervjua dig. Du är anställd. Minns du intervjun?

Rebecca Germond:

Jag minns intervjun. Jag kände mig grillad. Nej, jag skojar bara. Jag minns den väldigt väl eftersom jag minns utsikten från kontoret, och det var nog den som övertygade mig om FCV, tillsammans med vårt samtal.

Ben Aston:

Det var alltså inte jag. Det var utsikten.

Rebecca Germond:

Ja.

Ben Aston:

Rebecca, för dem som undrar vad du gör varje dag: vad innebär rollen som kundservicechef? Är det projektledning? Är det kundansvar? Vad betyder rollen för dig just nu?

Rebecca Germond:

Ja, det är lite av båda delarna, plus att jag leder själva projektledarteamet, vilket är roligt. Det är en ny roll för mig sedan ungefär ett år tillbaka. Jag arbetar inte längre lika mycket med detaljerna i projekten. Det finns några projekt som jag inte vill släppa, men i huvudsak får jag arbeta direkt med projektledarna och se till att de kan leverera och får det stöd de behöver. Jag ansvarar också för de flesta av våra kunder, så jag har en ganska nära kundansvarsrelation med dem. Jag började faktiskt inom kundansvar innan jag blev producent och projektledare, så det är lite som att gå tillbaka till rötterna, vilket är roligt.

Ben Aston:

Trevligt. För dem som är intresserade av rollen att leda ett team av projektledare: hur ser dagarna ut? Hur leder du dem? Du kan ju inte vara insatt i detaljerna i alla deras projekt hela tiden. Vad gör du faktiskt när du följer upp med dem?

Rebecca Germond:

Det jag framför allt gör är att granska mycket av det arbete eller de leveranser som de vill skicka vidare. Jag kan till exempel ge feedback på ett projektomfattningsdokument eller en tidsplan. Om något eskaleras blir jag involverad, eller så hjälper jag projektledarna att hantera hur de ska svara i besvärliga situationer. Jag träffar dem individuellt varje vecka, men har också kontakt via Slack och ser till att alla känner sig stöttade i vardagen. Ibland deltar jag i deras viktigare kundmöten. Det är ungefär det.

Jag är också starkt involverad i vår affärsutvecklingsprocess på FCV. Jag arbetar dessutom dagligen med hur mycket vi faktiskt ska fakturera våra kunder och med att se till att vi följer vår process för förändringshantering. Det finns många andra saker i det dagliga arbetet med projektledarna också.

Ben Aston:

Berätta lite om din bakgrund. Du arbetade med kundansvar. Jag vet att du började din karriär på arbetsmarknadsdepartementet. Hur tog du dig därifrån till en digital byrå och arbete med kundansvar och projektledning? Hur såg det ut för dig?

Rebecca Germond:

När jag gick i skolan hade min moster en bemanningsbyrå. Hon placerade mig på olika jobb när jag försökte hitta rätt plats. Jag visste att jag ville arbeta på en byrå. Jag fick en placering på arbetsmarknadsdepartementet. Det var mer som ett administrativt jobb inom offentlig sektor, men det var ganska intressant. Jag lärde mig mycket om hur myndigheter fungerar, vilket faktiskt hjälpte mig senare i karriären eftersom de flesta projekt jag arbetade med på min första byrå, och många av projekten jag arbetar med nu på FCV, är relaterade till offentlig sektor.

En gång placerade hon mig på en byrå i Toronto som hette Manifest Communications. Jag skulle bara arbeta i receptionen i två veckor medan någon var på semester, men de bad mig stanna som praktikant, vilket var precis det jag försökte få till. Jag gjorde det i tre månader, sedan anställde de mig och jag arbetade där i fyra år. När jag började var jag kundansvarig, så jag hanterade kunder och arbetade mindre med digitala projekt. Så småningom gick vi över till det. Efter mitt första år blev jag producent. Kanske 60 procent av arbetet var digitalt, men jag fick också arbeta med radio, tv-produktion och en del trycksaker, vilket var roligt.

Ben Aston:

Berätta. Vi är fortfarande i årets första kvartal. Om vi ser på din karriär eller utveckling talar vi i dag om portaler och om hur det är en utveckling, men har du satt upp några mål för året?

Rebecca Germond:

Det är faktiskt lite roligt. Jag vill inte ha några särskilda karriärmål i år. Det låter konstigt. Jag är inne på mitt sista år i tjugoårsåldern, så jag vill egentligen bara leva som en millennial. Jag har några resmål jag vill uppleva. Det är det som gäller för mig. När det gäller karriären har jag verkligen tyckt om att arbeta med det här portalprojektet. Vi har omvandlat det till en produkt och gör hela tiden nya lanseringar och försöker bygga vidare på något. Jag tycker att det är fantastiskt och skulle gärna göra mer sådant arbete.

Ben Aston:

Vi har pratat lite om din roll, men vilka utmaningar hanterar du just nu? Vilken är den största huvudvärken som du försöker övervinna i vardagen, särskilt i ett visst projekt?

Rebecca Germond:

I vardagen är jag van vid att behöva hålla ihop ett projektteam, om du förstår vad jag menar. Som projektledare måste vi hantera många egon och olika personlighetstyper. Nu är det mer på organisationsnivå: alla har olika behov och prioriteringar, och jag försöker balansera det samtidigt som jag ser till att projektledarna får det de behöver, eftersom det är oerhört viktigt. Det tycker jag är svårt. Man dras också in i sådant som kanske inte verkar så viktigt, som administrativa uppgifter. Jag vet inte. Att hålla reda på min egen att-göra-lista är helt enkelt en utmaning just nu.

Ben Aston:

Hur håller du reda på saker? Hur ser din att-göra-lista ut? Har du ett system?

Rebecca Germond:

Jag använder Evernote för det mesta på min att-göra-lista, men vi har precis lagt till en ny Slack-integration som heter Workast. Där kan man ha att-göra-listan i en faktisk Slack-kanal och tilldela uppgifter vid behov. Man kan också skriva en anteckning till sig själv i Slack, så finns att-göra-listan där och man får en påminnelse när något ska vara klart. Vi har precis börjat använda det, men hittills är det ganska bra.

Ben Aston:

Det heter Workast?

Rebecca Germond:

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

Ben Aston:

Workast, okej. Ett lite roligt namn.

Rebecca Germond:

Absolut. Hittills fungerar det bra. Problemet är att man inte kommer till sin att-göra-lista förrän före klockan nio eller efter klockan fem. Så känns det för mig, eftersom 70 procent av dagen antingen består av möten i telefon eller av att svara på e-post och meddelanden i Slack, vilket gör det väldigt svårt att vara produktiv.

Ben Aston:

Vad mer finns i din projektledningsverktygslåda? Du har ditt system för att-göra-listan, som naturligtvis hjälper dig att prioritera det viktigaste. Vad mer finns i verktygslådan? Hur hanterar du projekt?

Rebecca Germond:

Jag använder ganska många verktyg. Under de senaste åren har vi växlat mellan några olika, men nu är jag ganska nöjd med det vi har. Som jag nämnde använder jag Evernote. Vi använder Jira ganska seriöst nu. Alla, inklusive våra UX- och designteam och alla våra kunder, finns i Jira. Det gör det enklare eftersom allt åtminstone finns på ett ställe och vi kan hålla reda på ärenden. Vi använder Slack och jag använder det väldigt regelbundet.

Vi testar Microsoft Teams i stället för Skype för företag. Vi använder det som konferenslösning för våra möten med kunder. Det har fungerat ganska bra. Jag använder Merlin för projektplanering. Vi brukade använda MS Project, men jag tycker att vi bara använde 15 procent av funktionerna. Vi har några MS Project-licenser kvar ifall kunden behöver dem. Spotify finns definitivt i min verktygslåda. Jag behöver det. Och Outlook, antar jag, även om e-post är min värsta plåga.

Ben Aston:

Förutom Workast, finns det några andra verktyg som du nyligen har stött på eller något som har förändrat sättet du hanterar projekt på?

Rebecca Germond:

Inte direkt. Jag tycker att sättet vi använder Jira på har förändrats. Vi använder integrationer i vår Slack-kanal. Om ett ärende uppdateras eller statusen ändras, eller om en kund kommenterar, skickar Jira annars mängder av e-postmeddelanden varje minut när något uppdateras. Bara det viktigaste skickas till Slack-kanalen, så att man vet om någon har kommenterat ett ärende. Det har gjort det mycket enklare eftersom ingen läser Jira-meddelandena. MS Teams är faktiskt ganska bra eftersom de flesta kunder inte ville använda video tidigare, men nu har många börjat göra det sedan vi gick över till Teams.

Ben Aston:

Trevligt. Låt oss tala om ditt inlägg, din fallstudie, den första fallstudien du någonsin har publicerat. Grattis, Rebecca.

Rebecca Germond:

Tack.

Ben Aston:

Låt oss prata om en portal. Är en portal bara en webbplats eller är den annorlunda? Om den är annorlunda, varför och på vilket sätt?

Rebecca Germond:

Jag tycker att portaler är ganska komplexa eftersom de vanligtvis är anpassade för många olika användare, och alla dessa användare kan ha många olika åtgärder, funktioner och användarflöden. För just den här portalen fanns det tre olika användarnivåer som vi behövde ta hänsyn till, och hur de skulle påverka varandra var något vi underskattade i början. Portaler kan i allmänhet bli ganska komplexa på grund av alla olika delar som kanske inte finns på en vanlig webbplats där man bara går in och tittar på startsidan.

Ben Aston:

Vi talar alltså om något med mer avancerad interaktivitet och rollbaserad funktionalitet som aktiveras eller inaktiveras beroende på vad man gör i portalen.

Rebecca Germond:

Precis. För vår portal får man inte ut särskilt mycket från startsidan om man inte har en inloggning. Det finns vissa spärrar och det är inte nödvändigtvis enkelt att registrera nya kunder i portalen. Det finns mycket att ta hänsyn till som helt enkelt inte gäller för en vanlig webbplats.

Ben Aston:

Intressant. Vi talar alltså inte abstrakt – ge oss en kort översikt över portalens funktionalitet.

Rebecca Germond:

Absolut. Vår kund är en elektronikåterförsäljare med företagskunder som vill beställa produkter i stora volymer. Innan portalen fanns ringde de i princip sin kundansvariga och lade beställningar manuellt. Det gav alla huvudvärk. Kunderna ville inte längre ringa, så de behövde en portal där man kan logga in, se en produktkatalog som tilldelats den egna organisationen och bara handla från dessa produkter. Det finns också en komplicerad rabattmekanism, eftersom företagskunderna får anpassade rabatter beroende på hur mycket de köper och vad de köper. Det är en del av lösningen.

Vi har också en kassa och en instrumentpanel där användarna kan se sina mest beställda produkter, öppna beställningar och allt som har beställts under de senaste 30 dagarna. Instrumentpanelen innehåller flera verktyg som hjälper dem att förstå vad som händer i deras del av portalen.

Det finns också flera användarnivåer. De flesta kunder kan gå in och lägga en beställning, men beroende på organisationen kan en kundadministratör behöva godkänna den. Innan en beställning går igenom måste någon kunna godkänna den eller meddela att budgeten överskrids och att beställningen därför inte kan genomföras. Det finns många sådana detaljer.

Ben Aston:

Intressant. Om jag är en stor organisation och vill beställa 2 000 nya bildskärmar loggar jag alltså in, köper bildskärmarna, går igenom en godkännandeprocess i kassan och kan sedan följa min beställning.

Rebecca Germond:

Ja, precis.

Ben Aston:

Det är e-handel i stor skala.

Rebecca Germond:

Ja, precis.

Ben Aston:

I inlägget talade du om intressant teknik. Kan du ge oss en kort sammanfattning av teknikstacken, arkitekturen och lösningen – hur byggde ni faktiskt detta?

Rebecca Germond:

Våra utvecklare skulle kunna förklara det bättre, men jag kan ge en översikt.

Ben Aston:

Projektledarversionen.

Rebecca Germond:

Vi använder .NET Core för att driva mikrotjänster och React i frontend för att tillhandahålla gränssnitten till dessa mikrotjänster. Mikrotjänsterna är i princip slutpunkter som kan återanvändas på valfritt sätt. Om vi till exempel hämtar data om ordervolymen kan vi visa den på instrumentpanelen eller bearbeta den på många olika sätt. Vi skapade också ett komponentbibliotek med React som vi kunde återanvända på olika delar av webbplatsen, så att vi inte behövde bygga om samma komponenter hela tiden. Vi ville dessutom skapa ett konsekvent utseende genom hela webbplatsen och samtidigt hålla den inom kundens varumärke.

Ben Aston:

Det finns alltså inget CMS. Hur fungerade den delen? Har ni skapat funktionalitet i .NET som gör att återförsäljaren kan lägga till och redigera produkter?

Rebecca Germond:

Nej. Produktinformationen kommer från ett API som kunden använder på sina konsumentwebbplatser. Informationen uppdateras hela tiden. Vi har ett skript som körs en gång om dagen för att se till att vi får de senaste priserna och den senaste produktinformationen. Processen för att lägga till nya produkter är därför helt automatiserad.

Ben Aston:

Det är intressant. Ni arbetade alltså med produktutveckling och byggde en portal. Hur planerade ni projektet och produktutvecklingen?

Rebecca Germond:

Vi använde definitivt ett MVP-upplägg, alltså en minsta livskraftig produkt. Det fungerade och fungerade inte, eftersom det som blev MVP:n växte under projektets gång. Den var egentligen inte särskilt minimal alls. I början hjälpte MVP-angreppssättet oss mycket. Eftersom vi hade en ganska tydlig backlog gick vi direkt in i utvecklingssprintar. Vi lade inte särskilt lång tid på kravinsamling. I stället hanterade vi kraven under ett sprintplaneringsmöte för de funktioner vi skulle försöka slutföra under sprinten.

Ben Aston:

Fanns det en budget och en deadline för MVP:n? Ni hade en backlog med saker att bygga. Hur avgjorde ni vad som rymdes inom budgeten?

Rebecca Germond:

Det var svårt eftersom kunder i en byråmiljö vill ha ett pris på allt. Äkta agilt arbete kan vara en modell med kostnad per sprint. Vid sprintens slut kanske man inte har en komplett funktion. Vi valde därför att uppskatta varje funktion separat, så att kunden visste exakt vad varje funktion kostade och kunde prioritera själv. När vi hade fastställt vad som skulle ingå i MVP:n kunde vi bestämma kostnaden och vad som krävdes för att alla beroenden skulle fungera. Vi hade fem månader på oss att slutföra projektet och därefter en månad för användaracceptanstestning. Totalt hade vi sex eller sju sprintar.

Ben Aston:

En av sakerna du nämnde i fallstudien var att ni kraftigt underskattade vissa obligatoriska funktioner. Vad var den största underskattningen?

Rebecca Germond:

Det största var själva katalogbygget och att lägga rabatten ovanpå det. Vi trodde att vi bara skulle lägga en rabatt på vissa produkter. När vi gick in i API:et och alla produktkategorier med deras olika egenskaper blev logiken tillsammans med rabatten mycket komplicerad. Kunden ville dessutom utesluta vissa produkter, till exempel Apple-produkter. Vi behövde se till att sådana produkter inte visades när varumärket Apple skulle uteslutas, samtidigt som rabatten tillämpades på rätt sätt. Det blev mycket förvirrande och komplicerat.

Det var ett fastprisuppdrag, så vi kunde kompensera genom de många ändringsbegäranden som kunden lade till under projektets gång. Vi försökte hålla ordning på processen för förändringshantering. När man själv har underskattat något är det svårt att gå tillbaka till kunden och säga att man inte gjorde sitt jobb ordentligt.

Ben Aston:

En del av problemet var alltså att komplexiteten i rabattlogiken inte var tydlig från början.

Rebecca Germond:

Precis. När vi tog fram de första kraven skulle rabattmotorn vara mycket mindre omfattande. Den blev mer komplicerad när vi började gräva i detaljerna.

Ben Aston:

Hur skulle du planera annorlunda nästa gång, utifrån det du vet nu?

Rebecca Germond:

Jag tycker att vi gjorde ett bra jobb med de krav vi hade. Nästa gång skulle jag försöka använda en modell med kostnad per sprint. Vi skulle kunna ge kunden ett ungefärligt intervall i början, och sedan uppskatta vad vi skulle ta oss an i varje sprint och ange ett pris utifrån teamets storlek och det vi ville leverera. Jag skulle inte ändra mycket i hur teamet arbetade. Jag gillade att vi var så slimmade och att rätt personer var involverade. På kundsidan var det i princip bara produktägaren och den relevanta intressenten för den funktion vi arbetade med.

Ben Aston:

Ni hade ett litet team och ett hybridagilt arbetssätt. Hur fungerade samarbetet mellan design och utveckling?

Rebecca Germond:

Det är svårt att arbeta helt agilt i en byråmiljö eftersom kunderna ofta inte vill betala för ett helt team i fem månader. Vårt team bestod av två backendutvecklare, två frontendutvecklare, en UX-specialist på halvtid, en designer som deltog vid behov och en kvalitetssäkrare som normalt arbetade halvtid under sprinten. Vi använde ingen verksamhetsanalytiker, eftersom vi visste vad vi byggde och det inte hade hjälpt oss att förstå API:ets detaljer eller uppskatta arbetet. Vi hade inte heller någon strateg eftersom produkten var tydlig och kunden hade en väl definierad vision.

Eftersom vi började från noll hade vi inga färdiga komponenter. Design och UX arbetade en sprint före utvecklingsteamet. Det var inte helt enligt ett renodlat agilt arbetssätt, men kunden hade aldrig sett något vi gjort och vi behövde säkerställa att vi var på rätt spår med utseende och känsla. Vi använde den första sprinten till miljökonfiguration, distributionspipeline och andra tekniska förberedelser. Kunden arbetade själv agilt och uppskattade därför arbetsformen. Vi genomförde sprintplanering, dagliga avstämningar, granskningar, demonstrationer och återblickar, och kunden deltog i de flesta.

Ben Aston:

Kunden fungerade alltså som produktägare. Hur hanterade ni nya funktioner som dök upp under projektets gång trots en fast budget?

Rebecca Germond:

Varje gång han kom på en ny funktion förstod han att det var en ändringsbegäran som behövde kostnadsberäknas. Utmaningen var att vi behövde avbryta det vi gjorde i sprinten för att ta fram uppskattningen. Han hade fullständigt mandat över hur projektet skulle drivas och arbetade mycket bra tillsammans med oss. Vi kunde ge återkoppling och föreslå funktioner som han inte hade tänkt på. Ett exempel var en installationsguide som gjorde att användarna kunde få inloggningsuppgifter via e-post, återställa lösenord och ladda upp de formulär som behövdes. Det gjorde produkten mycket bättre.

Ben Aston:

Du nämnde att det var viktigt att hålla teamet engagerat och kunden involverad. Vilka råd har du för att skapa det engagemanget?

Rebecca Germond:

Arbetssättet var nytt för FCV, särskilt eftersom många av våra kunder är traditionella eller offentliga organisationer. Kunden blev engagerad eftersom han fick delta på den här nivån. Vi ville också att han skulle vara engagerad eftersom vi ville fortsätta med en fas två. Det här var inte bara en webbplats med ett slutdatum, utan en levande produkt.

Teamet ville arbeta med projektet eftersom de fick välja teknikstack, verktyg och ett nytt arbetssätt. Kunden fanns i Slack och kunde bolla idéer direkt med frontendutvecklaren eller andra i teamet. Det fungerade bra eftersom de byggde något som de verkligen brydde sig om.

Ben Aston:

Du talade också om att ta bort processer man inte behöver och omfamna dem man behöver. Vilka processer tog ni bort?

Rebecca Germond:

Efter vår andra sprintåterblick bestämde vi oss för att sluta med dem. Vi visste vad som fungerade och inte fungerade, och tiden vi lade på återblicken hjälpte oss inte längre. Den tog bara tid från utvecklingen. Eftersom kunden var så involverad kunde han ge oss återkoppling löpande. Det var en process vi tog bort ganska tidigt.

Det var också svårt att ha dagliga avstämningar eftersom halva teamet fanns i Toronto och halva i Vancouver. Vi försökte i stället ha korta avstämningar när det behövdes för att lösa hinder.

Ben Aston:

Så ni hade inte en fast ceremoni varje dag, utan avstämningar vid behov?

Rebecca Germond:

Ja. Vi försökte först få en fast tid att fungera, men när vi kom in i ett bra arbetsflöde blev det mer spontant eller så ställde vi frågor i Slack. Vi hade dagliga avstämningar i ungefär tre sprintar och gick sedan över till varannan dag eller Slack.

Ben Aston:

Fanns det någon process ni tog bort men senare lade tillbaka?

Rebecca Germond:

Inte direkt, men vi önskar att vi hade involverat kvalitetssäkring tidigare. Fram till den tredje sprinten hade vi egentligen inget som var redo för kvalitetssäkring. Under några demonstrationer arbetade vi fortfarande fem minuter före mötet och hoppades att koden skulle fungera. Vi arbetade som cowboys mot slutet, men det var väldigt roligt.

Ben Aston:

Rebecca, stort tack för att du var med. Det har varit fantastiskt att ha dig här.

Rebecca Germond:

Tack. När som helst.

Ben Aston:

Om du är intresserad av portalbyggen kan du läsa fallstudien som Rebecca har skrivit. Där finns mycket information som du kan ha nytta av. Om du vill prata om portalbyggen kan du också gå med i vårt Slack-team. Besök digitalprojectmanager.com/slack, så hittar du intressanta diskussioner om allt som rör digital projektledning. Om du uppskattade dagens program får du gärna gå till Apple Podcasts, tidigare iTunes, och lämna en recension. Vi uppskattar verkligen din feedback. Betyg och recensioner hjälper oss mycket och gör det lättare för fler att hitta programmet. Tack för att du lyssnade och på återhörande.