Een webportaal bouwen beheren (met Rebecca Germond van FCV Interactive)

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typefouten, want de bot heeft niet altijd voor 100% gelijk.

Ben Aston:

Welkom bij de DPM-podcast, waarin we verder gaan dan theorie om deskundig advies voor projectmanagers te geven over het leiden van betere digitale projecten. Bedankt voor het luisteren. Ik ben Ben Aston, oprichter van The Digital Project Manager.

De behoeften van klanten worden steeds volwassener en de rol van digitale bureaus verandert en ontwikkelt zich eveneens. Nu het proces van websiteontwerp en -bouw steeds meer een standaardproduct is geworden, groeit de behoefte aan bureaus die meer kunnen zijn dan alleen een websitepartner, maar ook een strategische en technische partner kunnen zijn om niet alleen websites, campagnes en landingspagina's te bouwen. In de podcast van vandaag gaan we ons verdiepen in portaalbouw: wat het is, hoe je het bouwt en enkele lessons learned als je aan een van deze projecten begint. Blijf luisteren als je meer wilt weten over de ontwikkeling van digitale bureaus en een productontwikkelingsbenadering voor klantbetrokkenheid.

Vandaag wordt Rebecca Germond mijn gast. Rebecca is directeur klantdiensten bij FCV. Ze heeft een sterke basis in projectmanagement en mediacommunicatie. Rebecca is iemand die ik een paar jaar geleden daadwerkelijk heb aangenomen. Ik herinner me je sollicitatiegesprek nog: ik haalde je de kamer binnen en dacht: ja hoor, ik neem dit meisje aan. Ik weet niet meer precies wat ik je vroeg, maar ik dacht: ik hoef je niet eens te interviewen. Je bent aangenomen. Herinner je je het gesprek?

Rebecca Germond:

Ik herinner me het gesprek. Ik had het gevoel dat ik stevig aan de tand werd gevoeld. Nee, ik maak maar een grapje. Ik herinner het me heel goed, omdat ik me het uitzicht vanuit het kantoor herinner en dat heeft me volgens mij voor FCV gewonnen, naast natuurlijk ons gesprek.

Ben Aston:

Het lag dus niet aan mij. Het was het uitzicht.

Rebecca Germond:

Ja.

Ben Aston:

Rebecca, voor degenen die zich afvragen wat je elke dag doet: waar draait directeur klantdiensten om? Is het projectmanagement? Is het accountmanagement? Wat betekent het momenteel voor jou?

Rebecca Germond:

Ja, het is een beetje van beide, plus het aansturen van het daadwerkelijke PM-team, wat leuk is. Het is sinds ongeveer een jaar een nieuwe rol voor me. Ik zit niet meer zo vaak met mijn handen in de projecten. Er zijn er een paar die ik niet wil loslaten, maar ik werk vooral rechtstreeks met de PM's en zorg ervoor dat ze kunnen leveren en de ondersteuning krijgen die ze nodig hebben. Daarnaast beheer ik de meeste van onze klanten, dus ik heb een behoorlijk goede accountmanagementachtige relatie met hen. Eigenlijk ben ik begonnen in accounts voordat ik producent-projectmanager werd, dus ik keer een beetje terug naar mijn roots, wat leuk is.

Ben Aston:

Mooi. Voor degenen die geïnteresseerd zijn in deze rol van het aansturen van een team projectmanagers: hoe ziet dat er dagelijks uit? Hoe stuur je hen aan? Je kunt niet voortdurend op de details van al hun projecten zitten. Wat doe je precies wanneer je bij hen incheckt?

Rebecca Germond:

Ja, dat is een goede vraag. Meestal beoordeel ik veel werk of opleveringen die ze willen versturen. Ik geef bijvoorbeeld feedback op een SoW of een planning. Als er escalaties zijn, raak ik erbij betrokken of help ik de PM's om te bepalen hoe ze op lastige situaties kunnen reageren. Ik spreek ze wekelijks individueel, maar ik heb ook contact via Slack en zorg er gewoon voor dat iedereen zich dagelijks ondersteund voelt. Af en toe woon ik hun belangrijkere klantvergaderingen bij. Het is vooral een beetje van dat alles.

Daarnaast ben ik nauw betrokken bij ons businessdevelopmentproces bij FCV. Ik werk ook dagelijks aan de vraag hoeveel we onze klanten daadwerkelijk gaan factureren en of we ons veranderingsbeheerproces goed genoeg bijhouden. En er zijn nog veel andere dagelijkse zaken met de PM's.

Ben Aston:

Vertel ons iets over je loopbaan. Je achtergrond lag in accountmanagement. Ik weet dat je je loopbaan bij het ministerie van Arbeid bent begonnen. Hoe ben je van het ministerie van Arbeid naar een digitaal bureau en accountmanagement en projectmanagement gegaan? Hoe zag dat eruit voor jou?

Rebecca Germond:

Zeker. Toen ik op school zat, had mijn tante een uitzendbureau. Ze plaatste me bij verschillende banen terwijl ik op zoek was naar de juiste plek. Ik wist dat ik bij een bureau wilde werken. Ik werd geplaatst bij het ministerie van Arbeid. Het was meer een administratieve baan bij de overheid, maar het was best interessant. Ik leerde er veel over de werking van de overheid, wat me later in mijn loopbaan hielp, omdat de meeste projecten waaraan ik bij mijn eerste bureau werkte, en veel van de projecten waaraan ik nu bij FCV werk, met de overheid te maken hebben. Dat was nuttig.

Op een gegeven moment plaatste ze me bij een bureau, Manifest Communications in Toronto. Ik zou daar slechts twee weken tijdelijk aan de receptie werken terwijl iemand op vakantie was, maar ze vroegen me te blijven voor een stage, precies wat ik toch probeerde te bemachtigen. Ik deed dat drie maanden, waarna ze me in dienst namen en ik er vier jaar werkte. Toen ik begon, was ik account executive: ik beheerde klanten en hield me minder bezig met digitale projecten. Geleidelijk aan verschoven we die richting op. Na mijn eerste jaar werd ik producent. Waarschijnlijk bestond ongeveer 60% van mijn werk uit digitale projecten, maar ik werkte ook aan radio, uitzendingen en drukwerk, wat eveneens erg leuk was.

Ben Aston:

Mooi. Vertel eens. We zitten nog in het eerste kwartaal van het jaar. Vanuit het perspectief van je loopbaan of ontwikkeling: we hebben het vandaag over portalen en hoe dat een soort evolutie is, maar heb je doelen die je jezelf dit jaar hebt gesteld?

Rebecca Germond:

Eigenlijk is het grappig. Ik wil dit jaar geen specifieke carrièredoelen hebben. Het klinkt vreemd. Ik zit in mijn laatste jaar van mijn twintiger jaren, dus ik wil eigenlijk gewoon leven als een millennial. Ik heb enkele reisdoelen. Dat staat er voor mij op de planning. Wat mijn loopbaan betreft, heb ik het geweldig gevonden om aan dit portaalproject te werken. We hebben er een product van gemaakt en brengen voortdurend nieuwe releases uit en proberen erop voort te bouwen. Ik vind dat echt geweldig. Ik zou graag meer van dit soort werk doen.

Ben Aston:

Leuk. We hebben het een beetje gehad over je rol en wat je doet, maar met welke uitdagingen heb je momenteel te maken? Wat is de grootste hoofdpijn die je dagelijks probeert op te lossen, of speelt er nu iets specifieks bij een bepaald project?

Rebecca Germond:

Voor mij ben ik dagelijks gewend om in een projectteamomgeving als een soort oppas op te treden, als je begrijpt wat ik bedoel. Als projectmanagers hebben we allemaal te maken met veel ego's of gewoon verschillende persoonlijkheidstypen. Nu bevind ik me op een schaal waarop het om minder projecten gaat en iedereen in de organisatie andere behoeften en prioriteiten heeft. Ik probeer dat allemaal in balans te houden en er tegelijkertijd voor te zorgen dat de PM's krijgen wat ze nodig hebben, want dat is ontzettend belangrijk. Dat vind ik soms lastig. Je raakt ook betrokken bij dingen waarvan je misschien niet denkt dat ze zo belangrijk zijn, zoals administratieve zaken. Ik weet het niet. Tegenwoordig vind ik het vooral moeilijk om mijn eigen takenlijst bij te houden.

Ben Aston:

Hoe houd je dingen bij? Hoe ziet je takenlijst eruit? Heb je een systeem?

Rebecca Germond:

Ik gebruik Evernote voor het grootste deel van mijn takenlijst, maar we hebben onlangs een nieuwe Slack-integratie toegevoegd die Workast heet. Daarmee kun je je takenlijst in een echt Slack-kanaal bijhouden en indien nodig taken aan anderen toewijzen. Je kunt ook gewoon een notitie voor jezelf in Slack schrijven; je takenlijst staat daar dan en je krijgt een herinnering wanneer iets moet gebeuren. We gebruiken het nog maar net, maar tot nu toe is het behoorlijk handig.

Ben Aston:

Dat heet Workast?

Rebecca Germond:

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

Ben Aston:

Workast, oké. Een beetje een grappige naam, Workast.

Rebecca Germond:

Zeker. Tot nu toe werkt het goed. Het probleem is dat je pas aan je takenlijst toekomt vóór 9.00 uur of na 17.00 uur. Zo voelt het voor mij, want 70% van mijn dag bestaat uit vergaderingen aan de telefoon of het beantwoorden van e-mails in Slack. Daardoor is het tegenwoordig erg moeilijk om productief te zijn.

Ben Aston:

Wat staat er nog meer in je PM-gereedschapskist? Je gebruikt een systeem voor je takenlijst, wat je natuurlijk helpt om de belangrijkste zaken te prioriteren. Wat zit er nog meer in je gereedschapskist? Hoe beheer je projecten?

Rebecca Germond:

Ik gebruik behoorlijk wat hulpmiddelen. De afgelopen paar jaar zijn we bij ons werk een paar keer van hulpmiddel gewisseld, maar nu ben ik redelijk tevreden met wat we hebben. Zoals ik zei, gebruik ik Evernote. We gebruiken Jira nu behoorlijk intensief. Iedereen, inclusief onze UX- en ontwerpteams en al onze klanten, zit in Jira. Dat maakt het makkelijker, omdat alles in ieder geval op één plek staat en we tickets kunnen bijhouden. We gebruiken Slack. Dat gebruik ik zeer consequent.

We testen Microsoft Teams uit als vervanging voor Skype voor Bedrijven. We gebruiken het in een vergaderopstelling voor onze vergaderingen met klanten. Dat werkt behoorlijk goed. Ik gebruik Merlin voor projectplanning. We gebruikten vroeger MS Project, maar ik vind dat we slechts 15% van de mogelijkheden benutten. We houden een paar MS Project-licenties achter de hand voor het geval de klant ze nodig heeft. Spotify hoort zeker bij mijn gereedschapskist. Dat heb ik nodig. En Outlook, denk ik, hoewel e-mail mijn grootste ergernis is.

Ben Aston:

Zijn er, naast Workast, nog andere hulpmiddelen die je onlangs bent tegengekomen of dingen die de manier waarop je projecten beheert ingrijpend hebben veranderd?

Rebecca Germond:

Niet echt. Ik denk dat de manier waarop we Jira nu gebruiken wel veranderd is. We integreren het namelijk met ons Slack-kanaal. Als een ticket wordt bijgewerkt of de status wordt gewijzigd, of als een klant erop reageert, stuurt Jira je natuurlijk veertig e-mails per minuut wanneer er iets wordt aangepast. Alleen de belangrijkste zaken worden naar het Slack-kanaal gestuurd, zodat je weet wanneer iemand een opmerking bij een ticket heeft geplaatst. Dat heeft het echt makkelijker gemaakt, want niemand leest de Jira-e-mails. MS Teams is eigenlijk best handig, omdat de meeste klanten geen video wilden gebruiken, maar nu maken veel meer van hen daar gebruik van sinds we zijn overgestapt op MS Teams.

Ben Aston:

Mooi. Goed. Laten we het hebben over je artikel, je casestudy, de eerste casestudy die je ooit hebt gepubliceerd. Gefeliciteerd, Rebecca.

Rebecca Germond:

Dank je.

Ben Aston:

Laten we het over een portaal hebben. Is een portaal gewoon een website of is het anders? Als het anders is, waarom en hoe verschilt het dan?

Rebecca Germond:

Ik denk dat portalen behoorlijk complex zijn, omdat ze over het algemeen zijn afgestemd op veel verschillende gebruikers. Elk van die gebruikers kan verschillende acties, functies of klantreizen hebben. Voor dit specifieke portaal moesten we rekening houden met drie verschillende gebruikersniveaus. De manier waarop die elkaar zouden beïnvloeden, hadden we aanvankelijk onderschat. Portalen kunnen in het algemeen behoorlijk complex worden door alle verschillende mogelijkheden en uitzonderingen die je niet bij een gewone website zou tegenkomen wanneer je simpelweg de homepage opent.

Ben Aston:

We hebben het dus over iets met rijkere interactiviteit, waarbij functionaliteit op basis van rollen wordt in- of uitgeschakeld afhankelijk van wat je in het portaal doet.

Rebecca Germond:

Precies. Voor ons portaal geldt dat je zonder login niet veel aan de homepage hebt. Er zijn bepaalde drempels ingebouwd en het is niet per se eenvoudig om nieuwe klanten in het portaal te onboarden. Er zijn veel zaken om rekening mee te houden die simpelweg niet van toepassing zijn op een gewone website.

Ben Aston:

Interessant. We praten dus niet abstract; geef ons een kort overzicht van de functionaliteit van dit portaal.

Rebecca Germond:

Prima. Dit portaal … Onze klant is een elektronicaretailer. Ze hebben zakelijke klanten die producten in bulk willen bestellen. Voordat er een portaalomgeving was, belden die klanten in feite hun accountmanager om handmatig een bestelling te plaatsen. Dat bezorgde iedereen hoofdpijn. Ook klanten hadden er genoeg van, want niemand wil tegenwoordig nog de telefoon pakken. Ze zochten een portaal waarop mensen kunnen inloggen en een catalogus zien met producten die aan hen zijn toegewezen, zodat ze alleen die producten kunnen bestellen. Daarnaast wordt er een ingewikkeld kortingsmechanisme toegepast. Zonder het portaal en deze korting zouden mensen gewoon via de consumentenwebsite kunnen winkelen en kopen wat ze nodig hebben. Omdat ze in bulk inkopen, krijgen ze aangepaste kortingen op basis van hoeveel ze kopen en wat ze doen. Dat is één aspect.

We hebben ook een afrekenproces. Er is een dashboard waarop mensen hun meest bestelde producten kunnen zien. Ze kunnen openstaande bestellingen bekijken en alles zien wat in de afgelopen dertig dagen is besteld. Er staan enkele handige hulpmiddelen op het dashboard die helpen om inzicht te krijgen in wat er in hun portaalomgeving gebeurt.

Daarnaast zijn er verschillende gebruikersniveaus voor degenen die kunnen winkelen. De meeste klanten kunnen een bestelling plaatsen, maar afhankelijk van hun organisatie moet een klantbeheerder die mogelijk goedkeuren. Voordat een bestelling wordt verwerkt, moet iemand deze kunnen goedkeuren of kunnen aangeven: sorry, je overschrijdt ons budget, dus we kunnen deze bestelling niet verwerken. Ook daarin zitten veel verschillende mogelijkheden en uitzonderingen.

Ben Aston:

Interessant. Stel dat ik een grote organisatie ben, bijvoorbeeld Telus, en 2.000 nieuwe monitoren wil bestellen. Ik log in op het systeem, koop mijn monitoren, maar vervolgens is er ook een goedkeuringsproces bij het afrekenen en kan ik mijn bestelling volgen.

Rebecca Germond:

Ja, precies.

Ben Aston:

Het is e-commerce op grote schaal.

Rebecca Germond:

Ja, precies.

Ben Aston:

Mooi. In het artikel had je het over interessante technologie. Kun je ons een korte samenvatting geven van de technologiestack, de architectuur en de oplossing, dus hoe je dit daadwerkelijk bouwt? Wat maakte het interessant?

Rebecca Germond:

Onze ontwikkelaars kunnen hier waarschijnlijk beter over vertellen, maar ik kan een algemeen overzicht geven.

Ben Aston:

De PM-versie.

Rebecca Germond:

We gebruiken .NET Core voor microservices en React aan de voorkant om de interfaces van die microservices te leveren. In feite zijn die microservices eindpunten die je op elke gewenste manier opnieuw kunt gebruiken. Stel bijvoorbeeld dat je gegevens over het aantal bestellingen krijgt. Omdat we die informatie hebben, kunnen we die op het dashboard weergeven of op allerlei verschillende manieren bewerken, wat erg handig is. React is natuurlijk erg interessant voor onze front-endontwikkelaars en zij werken er graag mee. Toen we React gebruikten, hebben we een componentenbibliotheek gemaakt die we konden hergebruiken in verschillende delen van de website, zodat we niet steeds dezelfde componenten opnieuw hoefden te bouwen. We wilden ook een zeer consistente uitstraling op de hele website en iets dat bij hun merk bleef passen en niet te sterk afweek van hun consumentenwebsite.

Ben Aston:

Mooi. Er is dus geen CMS. Hoe verliep dat proces? Hebben jullie binnen .NET de functionaliteit gebouwd waarmee de retailer producten kan toevoegen en bewerken? Is daar een CMS voor of hoe werkt dat?

Rebecca Germond:

Nee. Het mooie is dat alle productinformatie en productgegevens afkomstig zijn uit een API die de klant zelf aanlevert en op zijn consumentenwebsites gebruikt. Die productinformatie wordt voortdurend bijgewerkt. We hebben een script of iets dergelijks dat eenmaal per dag draait om ervoor te zorgen dat we de meest actuele prijs en productinformatie, zoals specificaties, ophalen. Het toevoegen van een nieuw product is dus volledig geautomatiseerd, wat behoorlijk handig is.

Ben Aston:

Dat is handig. Dit was productontwikkeling: een portaal bouwen. Dat was iets nieuws. Vertel eens hoe jullie het project of de productontwikkeling hebben gepland. Wat was jullie proces om deze bouw te plannen?

Rebecca Germond:

We hebben zeker gekozen voor een MVP-aanpak, een minimaal levensvatbaar product. Dat werkte wel en niet, want naarmate het project vorderde, bleef groeien wat uiteindelijk de MVP werd. Het was dus helemaal niet zo minimaal. In het begin, toen we de planning en de raming echt opstelden, hielp de MVP-aanpak ons behoorlijk. Omdat we een vrij duidelijk gedefinieerde backlog hadden, begonnen we meteen met ontwikkelsprints. We namen niet overdreven veel tijd voor het verzamelen van vereisten. We behandelden de vereisten tijdens een sprintplanningsvergadering voor de functies die we tijdens die sprint probeerden af te ronden.

Ben Aston:

Was er voor de MVP een budget en een deadline? Jullie hadden een backlog met zaken die gebouwd moesten worden. Hoe bepaalden jullie wat binnen het budget viel en wat erbuiten viel? Wanneer hebben jullie het budget daarvoor vastgesteld? Want ik denk dat dit een van de grootste uitdagingen is.

Rebecca Germond:

Dat was het ook. Het moeilijke aan agile werken in een bureauomgeving is dat klanten voor alles een prijs willen zien. Echte agile is misschien een model met kosten per sprint. Aan het einde van een sprint heb je misschien nog geen volledige functie. Om de raming aan te pakken, moesten we per functie een soort à-la-cartemodel aanbieden, zodat ze precies wisten hoeveel een specifieke functie zou kosten en die indien nodig zelf konden prioriteren. Sommige functies waren afhankelijk van andere. Toen we precies hadden vastgesteld wat in de MVP kwam, bepaalden we daarmee de kosten en wat er precies moest gebeuren om alle afhankelijkheden te laten werken. Op basis van die à-la-carteprijzen probeerden we het werk wat te bundelen, zodat het in een sprintmodel paste. We wisten dat we vijf maanden hadden om het project af te ronden, met aan het einde een maand voor gebruikersacceptatietests. Ik denk dat we twee weken bezig zijn geweest met het opzetten van de omgeving en dergelijke. In totaal hadden we volgens mij zes of zeven sprints.

Ben Aston:

Een van de dingen die je in de casestudy noemde, was dat jullie sommige verplichte functies zwaar hadden onderschat, maar dat je juist daardoor plezier had. Tussen de regels door lees ik dat jullie à la carte werkten, maar sommige van die à-la-carteonderdelen hadden onderschat. Hoe en waarom waren ze volgens jou onderschat?

Rebecca Germond:

Het grootste onderdeel dat we onderschatten, was volgens mij het bouwen van de catalogus en vervolgens het toepassen van de korting. Wij dachten: o ja, we voegen gewoon een korting toe aan specifieke producten. Zodra je in de details van hun API en alle verschillende productcategorieën duikt, ontdek je dat ze allerlei verschillende kenmerken hebben. Die logica, gecombineerd met een korting erbovenop, werd ontzettend ingewikkeld. Er was nog een extra laag: ze wilden bepaalde producten uitsluiten. Apple maakte bijvoorbeeld geen grote marge, dus ze wilden nooit korting geven op een Apple-product. We moesten ervoor zorgen dat wanneer ze zeiden: sluit het merk Apple uit, je alleen producten met deze kenmerken zou tonen, maar geen Apple-producten, en daar vervolgens de korting op zou toepassen. Het werd heel verwarrend en ingewikkeld.

Helaas was dit bij deze klant een opdracht tegen een vaste prijs. We konden ons verlies terugverdienen of extra tijd krijgen via veel wijzigingsverzoeken die ze onderweg toevoegden, of via wijzigingsverzoeken voor functies die al in de à-la-cartelijst stonden. We deden ons best om het veranderingsbeheer goed bij te houden. Wanneer we onszelf gewoon hadden overschat of onderschat, was het erg moeilijk om naar de klant terug te gaan en te zeggen: sorry, we hebben ons werk niet helemaal goed gedaan.

Ben Aston:

Een deel daarvan komt toch doordat de vereisten, en vooral de complexiteit van de kortingen, vanaf het begin misschien niet duidelijk waren?

Rebecca Germond:

Precies. Bij de eerste vereisten was de kortingsengine of wat we ook aan het bouwen waren veel minder uitgebreid. Het werd pas wat ingewikkeld toen we er dieper indoken.

Ben Aston:

Dat is vaak zo bij meer agile projecten. Het hele idee van een project op een meer agile manier uitvoeren is dat het past bij een situatie waarin niet alles volledig zwart-wit is, maar dan moet het kostenmodel daar wel op aansluiten. Hier werkten jullie duidelijk met een vaste prijs en onduidelijke vereisten. Wat zou je, met de kennis van nu, de volgende keer anders plannen?

Rebecca Germond:

Ik denk dat we goed werk hebben geleverd met de vereisten die we hadden. Wat ik met deze klant zou willen proberen … We hebben nu een geweldige werkrelatie. Hij begrijpt het en is eigenlijk een verlengstuk van ons team, wat enorm helpt. We proberen meer te verkopen volgens een model met kosten per sprint. We zijn daar nog niet helemaal, maar we kunnen wel flexibel omgaan met de planning en hij is erg begripvol, wat geweldig is. Als we dit de volgende keer opnieuw zouden beginnen, zouden we misschien aan het begin een grove bandbreedte kunnen geven, omdat zij een bedrag moeten kunnen laten goedkeuren.

Als we een goede bandbreedte geven en vervolgens tijdens elke sprint beter kunnen ramen wat we in die sprint gaan aanpakken, en een prijs per sprint kunnen geven op basis van het aantal teamleden dat we nodig hebben en wat we hopen af te krijgen, zou dat misschien beter zijn. Over het algemeen zou ik weinig veranderen aan onze manier van werken als team. Ik vond het prettig dat we klein waren. Ik vond het prettig dat we met slechts een paar mensen waren. Het wordt moeilijk wanneer er aan klantzijde veel mensen betrokken zijn. Het waren eigenlijk alleen hij en de juiste belanghebbende die betrokken hoefden te zijn bij de functie die we in de sprint aanpakten. Dat werkte ook erg goed.

Ben Aston:

Mooi. Je hebt het over een klein team en dat was een van de dingen die goed werkten. In je artikel schreef je over deze hybride agilebenadering van ontwikkeling en ontwerp. Kun je vertellen hoe dat er concreet uitzag en wie er in het team zaten? Het was een klein team. Hoe lieten jullie ontwerp en ontwikkeling samenwerken?

Rebecca Germond:

Ja, dat is lastig. Ik denk dat het in een bureauomgeving in het algemeen heel moeilijk is om volledig agile te werken. Dat is tenminste mijn ervaring, omdat klanten meestal niet bereid zijn om vijf maanden lang een team te betalen. Ze willen weten wat een functie gaat kosten. Ze kopen geen team in; het is moeilijk om dat perspectief te veranderen. Als je intern werkt, je eigen product bouwt en mensen hebt die acht uur per dag en vijf dagen per week beschikbaar zijn, is het anders. Wanneer mensen aan meerdere projecten werken, is agile werken echt heel moeilijk.

Ons team bestond uit twee back-endontwikkelaars, twee front-endontwikkelaars, een UX'er voor halve dagen en een ontwerper die af en toe kwam kijken om ons ontwerp of onze functies te beoordelen. Daarnaast hadden we één QA'er, die tijdens de sprint doorgaans ook voor de helft van zijn tijd aan het project werkte. We gebruikten geen businessanalist, en ik denk nog steeds dat dat prima was. Ik denk niet dat dit in ons nadeel werkte, omdat we wisten wat we aan het bouwen waren. Ik denk niet dat een businessanalist ons de details van hun API had kunnen uitleggen of iets dergelijks. Dat zou ons niet echt hebben geholpen met het ramen. Ik denk dat dit juist goed werkte. We hadden geen strateeg, omdat het product vrij rechttoe rechtaan was. De klant had een duidelijke visie op de MVP en er zat natuurlijk een sterke gebruikssituatie achter. Dat was het team. En ik natuurlijk.

Hoe pakten we het aan? Omdat we vanaf nul begonnen, hadden we nog geen componenten voor dit project gebouwd. We hadden in feite alleen de merkrichtlijnen om te gebruiken voor alles wat ze wilden, plus de functie zelf. Ontwerp en UX werkten één sprint vooruit, dus vóór het ontwikkelteam. In een echt agileproces zou je dat waarschijnlijk niet zo doen. Je zou proberen een functie gezamenlijk op te leveren, maar de klant had nog nooit iets gezien van wat we eerder hadden gedaan. We moesten dus een kleine voorsprong nemen om zeker te weten dat we met de uitstraling en dergelijke op het juiste spoor zaten.

In die eerste sprint werkten ontwerp en UX vooruit. Wij gebruikten die sprint voor het opzetten van de omgeving en alles wat nodig was, omdat we een volledig nieuwe implementatiepijplijn en allerlei projectinstellingen moesten maken waar de ontwikkelaars aan moesten werken. Aan de andere kant werkt de organisatie van onze klant agile, of ze probeerden dat intern te doen. Het was voor hen dus niet moeilijk om het te begrijpen en ze vonden de manier van werken prettig. Alle agileceremonies, zoals stand-ups, tussentijdse sprintbeoordelingen, demo's en retrospectives, bleven we gewoon uitvoeren. We namen ze serieus en de klant nam aan alle of de meeste ervan deel.

Ben Aston:

Mooi. Laten we het over de klant hebben. Het goede aan dit scenario was dat de klant de productmanager was, toch? Jullie hadden niet een hele groep belanghebbenden, maar één belanghebbende. Je zei dat hij geweldig was, maar ook dat de klant onderweg nieuwe functies en taken bedacht. Hoe beheerden jullie dat wanneer je met een vast budget en een agile aanpak werkt, waarbij het volkomen redelijk is dat ze nieuwe functies en taken bedenken?

Rebecca Germond:

Het was zeker moeilijk, maar telkens wanneer hij een nieuwe functie bedacht, begreep hij dat het om een wijzigingsverzoek ging en dat we er een offerte voor moesten maken. Het probleem was dat het daardoor lastig werd om het werk aan de sprint stil te leggen en een raming te maken, terwijl hij die raming nodig had om de functie goed te keuren. Dat maakte het interessant. In het algemeen trad de klant op als producteigenaar. Zijn team gaf hem volledige autonomie over de manier waarop hij het project wilde uitvoeren. Volgens mij waren ze al enige tijd bezig met de planning voordat wij aan boord kwamen. Het was goed dat ze ons erbij haalden, omdat we feedback en ideeën konden geven over nieuwe functies en zaken waar ze nog niet aan hadden gedacht.

Hij kwam halverwege soms met leuke functies, maar ze waren allemaal ontzettend belangrijk. Voor de bouw verwachtten ze bijvoorbeeld nog steeds dat ze deze klanten handmatig zouden onboarden: ze zouden een pdf sturen met informatie over aanmelden en dergelijke. Waarschijnlijk na de derde sprint besloten we een installatiewizard te maken, zodat mensen konden binnenkomen en een login en wachtwoord konden ontvangen via een e-mail die we hun stuurden. Ze konden hun wachtwoord opnieuw instellen, alle formulieren downloaden die ze moesten invullen en deze weer naar het systeem uploaden. Dat maakte het voor hun team gemakkelijker om te beheren. Hoewel we dit niet echt hadden voorzien, maakte het het uiteindelijke product geweldig.

Ben Aston:

Mooi. Je had het over enkele lessons learned. Een van de dingen die je zei was dat je je team betrokken en je klant actief moest houden. Het klinkt alsof de klant erg betrokken was. Welke tips heb je om die betrokkenheid in de eerste plaats te behouden en te stimuleren?

Rebecca Germond:

Voor ons was deze manier van werken nieuw bij FCV, omdat veel van onze klanten oude of overheidsklanten zijn. Ze werken al jaren met ons, maar zitten vast in hun werkwijze. De manier waarop we onze klant betrokken kregen, heeft uiteindelijk heel goed gewerkt, omdat we zagen dat klanten op dit niveau echt betrokken willen zijn. Dat was interessant. We wilden ook dat hij betrokken bleef omdat we een fase twee van dit project wilden. We wilden dit echt voortzetten. We zagen dat het niet zomaar een website is die aan het einde van haar levenscyclus ophoudt te bestaan. Het is iets levends. Hem op die manier betrokken houden was dus goed.

Het team betrokken houden was ook belangrijk. Ze wilden hieraan werken omdat ze hun technologiestack mochten kiezen. Ze mochten iets nieuws doen en hun eigen hulpmiddelen kiezen. Ze vonden het ook leuk om een platform te hebben om met de klant te praten, hoewel sommige mensen dat misschien niet prettig vinden. Het hangt van je team af, maar we hebben onze klant in Slack. Hij kan ideeën uitwisselen met onze front-endontwikkelaar of met wie er op dat moment nodig is, en dat werkt goed. Ik denk dat ze op die manier betrokken blijven omdat ze iets bouwen waar ze echt om geven.

Ben Aston:

Een van de dingen die je in je lessons learned noemde, was het loslaten van processen die je niet nodig hebt en het omarmen van de processen die je wel nodig hebt. Je zei dat een voordeel van het project was dat het het projectproces binnen het bureau verfijnde. Kun je vertellen over processen die je hebt laten vallen of over verfijningen die je in andere projecten kon integreren?

Rebecca Germond:

Zeker. Na onze tweede sprintretrospective besloten we ermee te stoppen. We dachten: goed, we weten wat goed gaat en wat niet. De tijd die we hier nu aan besteden helpt niet echt. Het haalt alleen tijd weg bij de ontwikkeling, en dat wilden we niet. Omdat onze klant zo betrokken was, kon hij ons tussendoor feedback geven als iets niet voor hem werkte, als we ons proces moesten aanpassen of als we ergens voor de volgende sprint over moesten nadenken. Dat proces hebben we dus al vroeg laten vallen.

Het was voor ons ook erg moeilijk om stand-ups te doen, omdat de helft van ons team in Toronto zat en de andere helft in Vancouver. Dat maakt het lastig. We probeerden er rekening mee te houden dat je mensen beter kunt deblokkeren met een stand-up van vijftien minuten dan door een uur lang via Slack te proberen het probleem op te lossen.

Ben Aston:

Jullie deden dus willekeurige stand-ups, geen dagelijkse ceremonie om 9.00 of 12.00 uur. Ze waren ad hoc.

Rebecca Germond:

Ja, het was om 9.30 uur. We probeerden het te laten werken, maar toen we eenmaal in een ritme kwamen, gebeurde het ad hoc of sprongen we gewoon in Slack om vragen te stellen. Waarschijnlijk hielden we het drie sprints vol met dagelijkse stand-ups, maar daarna gingen we naar om de dag of naar Slack.

Ben Aston:

Mooi. Is er een proces dat je probeerde te schrappen omdat je dacht: dit hebben we niet nodig, maar dat je later weer toevoegde nadat je besefte dat dat geen goed idee was?

Rebecca Germond:

Niet echt, maar een proces waarvan we achteraf wilden dat we het eerder hadden ingevoerd, was QA. We hadden tot de derde sprint eigenlijk niets dat klaar was voor QA en hadden daar waarschijnlijk iets eerder mee moeten beginnen. Ik herinner me dat we bij een paar demo's nog vijf minuten ervoor code aan het schrijven waren, iets committen en vervolgens maar hoopten dat het bleef staan en werkte. Tegen het einde werkten we als cowboys, maar het was wel erg leuk.

Ben Aston:

Goed bezig. Rebecca, ontzettend bedankt dat je bij ons was. Het was geweldig om je erbij te hebben.

Rebecca Germond:

Dank je. Altijd welkom.

Ben Aston:

Graag gedaan. Als je geïnteresseerd bent in portaalbouw, bekijk dan de casestudy die Rebecca heeft geschreven. Daarin staat veel informatie die je misschien nuttig vindt. Als je over portaalbouw wilt praten, ga dan ook naar ons Slack-team. Ga naar digitalprojectmanager.com/slack en je vindt daar allerlei interessante gesprekken over alles wat met digitaal projectmanagement te maken heeft. Ik wil ook nog zeggen: als je de uitzending van vandaag leuk vond, ga dan naar Apple Podcasts, voorheen bekend als iTunes, en laat een beoordeling achter. We horen graag je feedback. Beoordelingen en recensies zijn erg nuttig en helpen ons met de show. Tot de volgende keer, bedankt voor het luisteren.