Achter de schermen deel 2: Het voorbereiden van een nieuw softwareproject.

Het opdoen van domeinkennis voor projecten

Iedere organisatie is uniek. Twee verschillende organisaties in een identieke sector kunnen totaal verschillende organisatieprocessen hebben. Daarom is het essentieel om de organisatie echt te leren kennen. Want pas als je de problemen achter de hulpvraag begrijpt, kun je een passende oplossing aanbieden. Coen (Lead Developer) vertelt:

“Bij een applicatie waarin processen gedigitaliseerd worden, moeten we eerst weten hoe deze processen in elkaar steken. Tijdens de kick-off meeting vraag ik dan ook altijd naar de irritaties op dit moment. Welke irritaties moeten we gaan oplossen met onze software? En komt dit wel overeen met de oorspronkelijke hulpvraag?”

Om software te ontwikkelen die naadloos aansluit op de organisatieprocessen hebben we domeinkennis nodig van deze processen, maar ook van hoe mensen werken binnen de bestaande software. We zitten liever naast een klant terwijl zij met deze software werken, dan dat we hun exacte hulpvraag opvolgen. Ons doel is namelijk om te ontwikkelen wat de klant nodig heeft. Vaak komen we er bij het opdoen van domeinkennis achter dat er onderdelen gevraagd worden die ze niet echt gebruiken. Of dat er irritaties zijn die niet in de hulpvraag meegenomen zijn. Coen (Lead Developer):

“Dan krijg je uiteindelijk een product waar een klant veel beter mee geholpen is. Maar dat kun je alleen maar opstellen als je weet hoe ze werken, wat ze doen en waar de irritaties precies zitten”.

Hoe we onze projecten beheren en bewaken

In de oriëntatiefase precies helder krijgen wat we gaan ontwikkelen, vergemakkelijkt het beheren van het project enorm. Coen (Lead Developer) vertelt:

“Waar we eerst met een klant gingen zitten en een idee vormden waarop we verder gingen ontwikkelen, hebben we nu een specifiek format ontwikkeld wat we acceptatiedocument noemen. Dit acceptatiedocument bevat 2 delen: Een functioneel ontwerp, waarin alles wat de klant wil komt te staan. En een afspraken document, waarin alle afspraken tussen ons en de klant staan.”

Dit acceptatiedocument bevat alle input die tijdens de meetings in de oriëntatiefase is ontstaan. Het functioneel ontwerp laat precies zien wat de gebruikers uiteindelijk kunnen met de software die we leveren. Op het moment dat daar een wijziging op komt wordt deze in het afsprakendocument vastgelegd. Om dit proces te verduidelijken nemen we onze klant Van Hall Larenstein (HVHL) als voorbeeld:

HVHL leverde zelf een document aan met hun wensen. Maar dit zijn vooral eisen waaraan de website moet voldoen. Geen instructies over welke functionaliteiten de website uiteindelijk moet beschikken. Coen (Lead Developer) vertelt:

“Er stond bijvoorbeeld in dat het CMS de mogelijkheid moet bieden om bestanden te downloaden en uploaden. Maar er staat niet specifiek in hoe de webpagina die deze functionaliteit bezit er uit komt te zien. Dit bepalen we in het functionele ontwerp.”

De oriëntatiefase staat dus vooral in het teken van exact helder krijgen wat we gaan ontwikkelen. Pas als het acceptatiedocument met daarin het functioneel ontwerp en afsprakendocument volledig akkoord zijn, gaan we over tot de daadwerkelijke uitvoering van het project. Het voordeel hiervan is dat je alleen in de laatste fase van het project een discussieronde hebt, want zowel wij als onze klant weten precies wat het resultaat gaat worden. Coen vertelt wat het gevolg hiervan is voor het beheren van het project:

“Als projectleider is de laatste fase voor mij veel minder belangrijk geworden, omdat ik al mijn werk in de beginfase heb geplaatst. Deze methode van projectbeheer bespaart uiteindelijk enorm veel tijd en frustraties.”

Onze aanpak op het gebied van communicatie en samenwerking

De kick-off meeting en de meetings daarna spelen een grote rol in het helder krijgen van het ontwerp. Toch kan het voorkomen dat er zelfs na het ondertekenen van het acceptatiedocument nog wijzigingen zijn. Coen (Lead Developer) vertelt hoe we hier mee om gaan:

“Elke keer als er een addendum is voegen we deze toe in het afsprakendocument. Deze worden altijd met de klant gedeeld, zodat we beiden weten wat de definitieve afspraken tot nu toe zijn.”

Door het continu noteren en delen van iedere wijziging voorkomen we dat er aan het einde van het project discussie ontstaat. Alle toevoegingen in een project plaatsen we in de backlog, om deze vervolgens te bundelen. Voor deze bundel brengen we vervolgens een vervolg offerte uit, zodat we onze klant niet achteraf met extra kosten confronteren.

In de oriëntatiefase van een project hebben we wekelijks of zelfs dagelijks gesprekken met onze klant. Dit om ervoor te zorgen dat we het complete functionele ontwerp en het afsprakendocument zo snel mogelijk concreet en goedgekeurd hebben. Tijdens de daadwerkelijke ontwikkeling plannen we iedere twee weken een update meeting met onze klant om te laten zien wat de voortgang van het project is. 

Doorontwikkeling op basis van prepaid

Niet al onze opdrachten worden van tevoren in een acceptatiedocument vormgegeven en begroot. Bij het doorontwikkelen van bestaande software werken we vaak op basis van prepaid. Siemen (Projectleider) legt uit:

“Bij prepaid wordt er van tevoren een bedrag afgesproken met de klant. Tegelijkertijd spreken we af hoeveel ontwikkelingsuren wij kunnen inzetten voor het budget wat ze bij ons hebben neergelegd.”

Het voordeel voor de klant is dat zij ons direct kunnen inschakelen, zonder dat we eerst een uitgebreide oriëntatiefase en kostenbegroting hoeven te doorlopen. Hiermee maken we het ontwikkelingsproces een stuk sneller. Bij pre-paid kunnen we onze klant op ieder moment op de hoogte houden van de overgebleven hoeveelheid budget. Zo weten ze precies waar ze aan toe zijn.

Hoe we omgaan met veiligheid en privacy

Veiligheid en privacy staan binnen Four Digits hoog in het vaandel. Onze ISO 9001, ISO 27001 en NEN 7510 certificaten bewijzen dat. In de eerste aanvraag van een klant staan vaak de requirements op het gebied van veiligheid al opgesomd. Maar vaak gaan we nog een stuk verder om de veiligheid van onze klanten en hun medewerkers en klanten te garanderen.

Onze software draaien we bijvoorbeeld altijd op meerdere servers. Als er een uitvalt, blijft je software gewoon toegankelijk. Tegelijkertijd voeren we back-ups uit van onze databases bij een gecertificeerde hostingpartner, zodat je data nooit verloren gaat. Dit hostingplatform hebben we samen met onze hostingpartner Exonet ontworpen en ook Exonet is ISO 9001, ISO 27001 en NEN 7510 gecertificeerd.

In ons ontwikkelproces werken we met een OTAP straat. Dat wil zeggen dat we de code schrijven in een afgezonderde omgeving, zonder dat de productieomgeving beïnvloed wordt. Coen (Lead Developer) legt uit:

“Als de code gereed is plaatsen we het ook op de testomgeving, waar we vervolgens interne kwaliteitschecks uitvoeren. Dan verplaatsen we de software naar een acceptatieomgeving, waarbij de klant ernaar kan kijken. Als de klant het goedkeurt, dan deployen we het uiteindelijk naar de productieomgeving.”

In onze deployment strategie zitten meerdere veiligheids -en kwaliteitscontroles en scans ingebouwd. Eventuele privacygevoelige informatie anonimiseren we altijd. Daarnaast spelen we als expert op het gebied van cyberveiligheid altijd een proactieve rol in het adviseren en het ondersteunen van onze klanten.

Opdrachtnemer of partner?

Zoals je hebt gelezen zijn we bij Four Digits niet zomaar opdrachtnemer. Want dit zou betekenen dat we simpelweg opvolgen wat er in de eerste aanvraag staat. Uit onze ervaring blijkt dat dit niet tot het beste resultaat leidt. Integendeel.

Daarom kiezen we ervoor om kritisch te zijn. Om als partner en adviseur op te treden en je in iedere fase van het proces bij te staan in het gezamenlijke doel naar perfect passende software. Veilig en futureproof.

Ben je benieuwd wat we voor jouw organisatie kunnen betekenen? Neem contact op voor een gratis adviesgesprek.