• de hoeveelheid. Hoeveel collega's zijn er die allemaal een stukje taart lusten?
• de keuzes die je moet maken. Neem je één of meerdere taarten mee? Welke smaak of smaken?
• levering. Is de keukentafel vrij? Is er voldoende ruimte? Kan iedereen er gemakkelijk bij?
• veiligheid. Kan de taart veilig door iedereen worden gegeten? Heb je rekening gehouden met mensen die geen gluten of zuivel mogen?
• testen en meten. Hoeveel collega's zijn er op kantoor de dagen voor je verjaardag? Is de keukentafel groot genoeg om het gewicht van de taart(en) te dragen?
• kennisoverdracht. Hoe laat jij je collega's weten dat je taart hebt gekocht?

Met alles rekening gehouden? Dan is je product gereed om te lanceren. Jij blij en je klant hopelijk ook. Proces voltooid!

De uitrol maakt bij de lancering van het project echter alleen deel uit van de oplevering. Het project moet nadat het is uitgerold immers ook nog worden ondersteund. Dit betekent dat het project moet worden overgedragen aan het supportteam en dat kan ... in sommige gevallen lastig zijn. We geven je in deze blog 5 tips om je voor te bereiden op een succesvolle go-live en je project verantwoord over te dragen aan je supportteam. Gegarandeerd minder stress en minimale impact op het bedrijf.

1. Goede afspraken, goede vrienden

In tegenstelling tot wat mensen wellicht denken, begin je al bij de eerste bijeenkomst met het voorbereiden van de projectoplevering voor je supportteam. Het is dan ook slim om het hele projectteam uit te nodigen voor die kick-offbijeenkomst. De aanwezigheid van bepaalde teamleden is vereist, zoals de bedrijfseigenaar, financier, product owner, projectmanager, customer proxy, architect / lead developer, DevOps lead en support lead. Anderen zijn ook welkom, zoals het ontwikkelingsteam en testers, zolang de groep maar overzichtelijk blijft en het totaal aantal deelnemers geen invloed heeft op waar de bijeenkomst om draait.

Tijdens deze bijeenkomst moeten 5 belangrijke onderwerpen aan bod komen:

1. Stel het team voor. Neem twijfels en stress weg door iedereen bij aanvang van de bijeenkomst eerst duidelijk voor te stellen. Doe alsof jullie elkaar voor het eerst ontmoeten. Maak er een spel van of probeer te vertellen wie degene is die naast je zit.
2. Bepaal de toon. Zorg voor een sfeer die voor iedereen prettig aanvoelt. Dit lijkt heel eenvoudig, maar door basisafspraken te maken verloopt de communicatie soepeler en transparanter en ontstaat er meer vertrouwen.
   
3. Bepaal de bestuursstructuur. Wie is waarvoor verantwoordelijk? Hoe verloopt de communicatie? Wie moet wanneer handelen? Wat zijn de reactietijden? Wie moet waarover op de hoogte worden gehouden?
   
   
4. Beperk risico's. Bedenk welke problemen er kunnen ontstaan. Aarzel niet om je zorgen en twijfels te delen! Zorg dat iedereen alert is en creëer een gevoel van gedeelde verantwoordelijkheid door aan het begin van het project mogelijke risico's aan te kaarten.
   
   
5. Bepaal een tijdlijn. Wanneer en waarvoor moet het team in actie komen? Zorg voor een overkoepelende planning met strakke deadlines.

Niet alle vragen moeten of kunnen aan het begin van het project tot in detail worden beantwoord en niets is in steen gebeiteld. Door bovenstaande zaken vast te leggen en een projectoverzicht op te stellen, creëer je richtlijnen die je tijdens het gehele project kunt hanteren. Zorg dat alle deelnemers toegang hebben tot dit projectoverzicht. Zorg dat het document wordt bijgewerkt als er nieuwe informatie beschikbaar is en neem de meest actuele versie tijdens de bijeenkomst door met de aanwezige deelnemers. Maar wat heeft dit te maken met een succesvolle levering aan je ondersteuningsteam? Het is je wellicht opgevallen dat de aanwezigheid van de support lead verplicht is tijdens de eerste bijeenkomst. Door de support lead vanaf het begin bij het project te betrekken en op de hoogte te houden, kan het supportteam:

• SLA's en ondersteuningsafspraken opstellen en
• tijdig hulpmiddelen vrijmaken. Dit helpt om niet alleen de officiële go-live maar ook de daaropvolgende benodigde activiteiten te ondersteunen
• en het levert tijdens het project inzichten op die van invloed kunnen zijn op ondersteunende taken.

2. Uiterst solide en enorm flexibel

Het is een goed idee om voorafgaand aan de start van het project prestatieaanvaardingscriteria voor een aanvraag te verzamelen. Deze vereisten kunnen van invloed zijn op de inrichting van het systeem en de keuze voor bepaalde technologie. Het is echter niet altijd even eenvoudig om haalbare en meetbare vereisten te definiëren. Voorspellingen zijn vaak gebaseerd op veronderstellingen en soms zelfs op wensen. Er zijn gelukkig enkele trucs en tips om je te helpen bij het bepalen van realistische vereisten. Het kan bijvoorbeeld helpen om te kijken naar bestaande gegevens of vergelijkbare applicaties. Verwachtingen moeten meetbare vereisten worden om tijdens het project testen uit te kunnen voeren en zaken te kunnen wijzigen. Gebruik prestatietesten om tijdens de ontwikkeling van het systeem prestatiedoelen te volgen en te bepalen of het in gebruik kan worden genomen. Maar ook

• om de stabiliteit van het systeem te testen,
• het afstemmen van individuele componenten te vereenvoudigen,
• de vereiste systeemcapaciteit te plannen,
• en de schaalbare beperkingen van het systeem te bepalen.

3. Verdeel en heers

Het testen van software is niet eenvoudig, maar het oplossen van problemen of fouten is vaak nog veel lastiger. Het is algemeen bekend dat de complexiteit van een fout in de software vrijwel exponentieel toeneemt naarmate het langer duurt om de fout op te sporen. Het is dus belangrijk om fouten in een zo vroeg mogelijk stadium te identificeren. Maar hoe doe je dat? Heel eenvoudig: hele korte feedbacklijnen.

Voordat de code van een ontwikkelaar wordt samengevoegd, wordt de geleverde functionaliteit eerst beoordeeld door een bedrijfsanalist of een functioneel analist. Het zal je verbazen hoe snel mensen met een 'frisse blik' foutjes in de software spotten. Zodra de code is gecontroleerd, kan het 'continuous delivery'-proces van start. Tijdens dit proces wordt elke dag de nieuwste versie van de software in de testomgeving geïmplementeerd zodat de tester die kan valideren. Tijdens deze stap wordt niet alleen het kleine toegevoegde component getest, maar ook hoe dat component samenwerkt met de al eerder toegevoegde delen.

Dankzij deze kwaliteitscontroles kunnen softwarefouten soms al in een vroeg stadium worden ontdekt, zelfs voordat de software acceptatietesten ondergaat. Tijdens een iteratief ontwikkelingsproces (bijv. sprints van 2-3 weken), worden fouten die niet zijn gespot gedurende een sprint alsnog ontdekt. De functionaliteit die de fout heeft veroorzaakt ligt nog vers in het geheugen bij de ontwikkelaar, zodat er snel en efficiënt een oplossing kan worden bedacht. Die oplossing kan opnieuw in de testomgeving worden getest dankzij het 'continuous delivery'-proces. De acceptatiecriteria van een 'story' (een klein en onafhankelijk stukje functionaliteit) wordt ook als input gebruikt voor de testdocumentatie van die functionaliteit en voor de supporttechnici die productondersteuning leveren.

4. Elke regel met code moet een waar kunstwerkje zijn

Het schrijven van hoogwaardige code is absoluut iets om persoonlijk trots op te zijn, maar levert op de langere termijn ook andere opmerkelijke voordelen op. Om een lastige functie te kunnen vertalen naar hoogwaardige code, moeten de functionele aspecten van die functie worden overwogen. Dit betekent dat je hoogstwaarschijnlijk alternatieve of bijzondere scenario's bedenkt die anders wellicht niet zouden worden benut. Fouten kunnen ook eenvoudiger en sneller worden opgespoord. Op den duur zal het langer nadenken over de code die wordt geschreven uiteindelijk juist veel tijd besparen.

Code die net zo fraai leest als de penseelstreken van de Mona Lisa is een genot om mee te werken. Jij en je supportteam moeten de codebasis van je product heel vaak doorlezen! Het is dus fijner als dit een aangename ervaring is, zodat er minder wordt gevloekt en meer wordt gelachen. Mensen die zich niet door een vervelende, onleesbare brij met code hoeven te worstelen maar die jouw code lezen, kunnen zich concentreren op het onderhavige probleem. Fouten worden sneller opgespoord en opgelost, en hotfixes zijn gemakkelijker toe te voegen. De code blijft ondanks deze ondersteunende taken overzichtelijk, want hoogwaardige code is flexibel en er kunnen eenvoudig aanvullingen aan de bestaande codebasis worden toegevoegd. Geen idee hoe je moet beginnen? Robert C. Martins boek Clean Code  biedt geweldige richtlijnen om superieure code te leren schrijven.

Kort samengevat en wellicht vanzelfsprekend: hoe minder fouten je project bevat, hoe minder moeite je supportteam hoeft te steken in de ondersteuning van het project. Natuurlijk weten we dat een applicatie zonder fouten eigenlijk niet bestaat. Daarom moeten we zorgen dat de kennisoverdracht naar het supportteam solide verloopt. En dat brengt ons bij het volgende punt.

5. Streef naar succes, maar bereid je voor op het ergste

Wanneer begin je met het uitleggen van alle ins en outs aan je supportteam? Als je aan het einde van het project alle informatie moet verzamelen dan sla je gegarandeerd bepaalde 'speciale gevallen' over die je aan het begin van het project hebt opgelost. Die speciale gevallen worden uiteraard wel ergens vermeld in een story ... of was het een fout, aangekaart in een story met de toelichting dat het systeem afwijkend reageerde op reële gegevens, waardoor er een nieuwe story ontstond?

Als je vanaf het begin van het project een kennisbasis opbouwt samen met de codebasis, dan wordt de kennisoverdracht naar het supportteam kinderspel. Zorg dat documentatie deel uitmaakt van het ontwikkelings-en validatieproces. Zo wordt het niet alleen steen voor steen opgebouwd, maar alles wordt ook gevalideerd en bijgewerkt bij elke volgende functionaliteit die wordt gebouwd. Alle belanghebbenden van het project profiteren tijdens het gehele project van deze kennisbasis.

Maar al die belanghebbenden zijn ook verantwoordelijk voor het actualiseren ervan. Van analisten en ontwikkelaars tot testers, ze maken allemaal gebruik van de gegevens die ze indien nodig bijwerken of afronden. Ook het supportteam moet hier een bijdrage aan leveren. Stel dat je een oud project wilt uitbreiden en dat het supportteam net zoals het projectteam tijdens de eerste ontwikkelingsfase alle informatie voortdurend heeft bijgewerkt. Dan wordt het toch veel eenvoudiger om aan de nieuwe toepassing te beginnen?

Zorg er ook voor dat je documentatie procesgericht is. De details van bepaalde functionaliteiten zijn te vinden in een story of in de code en de processen verduidelijken in welke story je informatie kunt vinden. En nee, het is niet nodig om een complete roman te schrijven. Je documentatie moet voldoende context bieden om een jaar na dato de draad weer probleemloos op te kunnen pakken. Uitgebreidere informatie kan verouderen of onjuist worden. En laten we wel wezen: foutieve documentatie is erger dan geen documentatie.

Het is belangrijk om al in een vroeg stadium uit te leggen welke procedure er wordt doorlopen, welke SLA’s er zijn afgesproken en wat er van de verschillende partijen wordt verwacht. Als je tijdens de ontwikkelingsfase begint met het opstellen van deze 'regels' en verwachtingen dan kunnen ze ook al getest worden tijdens de gebruikerstestfases. Gebruikers komen gegarandeerd met talloze vragen, problemen en (vermeende) fouten die tijdens de acceptatiefase niet relevant zijn. Het supportproces verloopt soepeler als die vragen op vergelijkbare wijze zoals tijdens de supportfase worden afgehandeld. Het maakt het leven van het supportteam bovendien een stuk eenvoudiger, omdat gebruikers al gewend zijn aan de 'regels'.

🚀 Takeaway

Dit zijn tot besluit in het kort onze 5 tips voor een succesvolle levering aan je projectteam:

1. Betrek het supportteam vanaf de start bij het project.
2. Stel haalbare prestatievereisten vast.
3. Zorg voor korte feedbacklijnen.
4. Zorg dat de kwaliteit van je code van topklasse is.
5. Begin direct vanaf dag één met het opbouwen van een kennisbasis.

We hopen dat deze tips je op weg zullen helpen. Aarzel niet ons te contacteren bij aanvullende opmerkingen en/of vragen!