Achter de schermen deel 5: De afronding

Gegevens migreren van klanten

Een belangrijk onderdeel van de afronding is gegevensmigratie. Op het moment dat ons gevraagd wordt een nieuwe website of applicatie te ontwikkelen, komt het vaak voor dat de huidige content overgezet moet worden naar de nieuwe software. Maar niet altijd. Siemen vertelt:

“Als het gaat om migratie zit er een groot verschil tussen een nieuwe website opzetten, een CMS, of een geheel nieuwe applicatie met organisatieprocessen. Ook zit er een groot verschil in of we iets nieuws bouwen of dat er oude data van een bestaand systeem in een nieuw systeem moet komen.”

In het voorbeeld van een nieuwe website zien we vaak dat onze klanten zelf ook nieuwe content (laten) creëren. Zodat het nieuwe moderne design past bij de content die erop staat. We zorgen er altijd voor dat onze klanten de nieuwe website zelf kunnen vullen met content door een aparte vulomgeving in ons serverplatform te creëren. Als de omgeving geaccepteerd is door ons en de klant en alle checklists zijn doorlopen op kwaliteit, SEO en andere thema’s kunnen we live. Het enige wat wij dan hoeven te doen is samen de DNS wijziging door te voeren. Soms doet een beheerder van de klant dit en soms regelen wij dit. Als er wel data gemigreerd moet worden, dan ziet het proces er anders uit. Siemen vertelt:

“Migratie is het inladen van de oude data op de nieuwe omgeving. Stel dat onze klant een website heeft die boekingen verwerkt, dan hebben we de laatste status vóór de livegang nodig om deze in het nieuwe systeem te integreren. Een onderdeel van ons development werk is dan oude data inlezen in de nieuwe omgeving en vervolgens testen of het naar behoren werkt.”

Een livegang met gegevensmigratie lijkt op een livegang zonder gegevensmigratie. Maar er is één belangrijk verschil. Het is namelijk belangrijk om te zorgen dat er geen mutaties meer kunnen plaatsvinden in het oude systeem. Het is daarom belangrijk om samen met onze klant een content-freeze periode af te spreken.

Op het moment dat de verwerking van nieuwe data is stopgezet voeren we de eerder ontwikkelde import software nog een laatste keer uit, zodat we zeker weten dat we de nieuwste data hebben van de oude omgeving. Zo kunnen we een compleet nieuwe website met alle actuele gegevens dezelfde dag nog live laten gaan.

Het evalueren van het project

Binnen Four Digits proberen we onze aanpak continu te verbeteren. Hoe kunnen we onze software en processen nog gebruiksvriendelijker maken voor onze klant? Hoe zorgen we ervoor dat we altijd binnen het budget blijven? En dat we de deadline halen?

In plaats van achteraf te evalueren proberen we juist tijdens de ontwikkeling continu alert te zijn op mogelijke verbeteringen. Dat is ook de reden dat we zoveel waarde hechten aan de oriëntatiefase. Door juist in deze fase kritisch te zijn en naar de beste oplossing voor onze klanten te streven, voorkomen we negatieve feedback in een later stadium. Coen vertelt:

“We vragen altijd wat de definitie is van een succesvol project aan onze klanten. Wat moeten we opleveren zodat ze aan het einde van de rit zeggen: Top! Dit documenteren we en nemen we bij onze interne kick-off ook mee.”

Als een klant bijvoorbeeld aangeeft dat gebruiksvriendelijkheid de ultieme pijler van succes is, dan gaan we hier tijdens het ontwikkelproces nog meer focus op leggen. We vragen ons dan bij ieder onderdeel af hoe we het nóg gebruiksvriendelijker kunnen maken. Dit testen we vervolgens ook bij onze klant, vertelt Coen:

“Ik ben continu aan het testen wat het met onze klant doet. Is dit iets wat ze enthousiast maakt? Of is het wel prima zo? Door ons werk continu te bespreken krijg je een goed gevoel of de klant tevreden is of niet. Zo ja, dan hebben we ons werk goed gedaan en hebben we de juiste vragen gesteld.”

Is onze klant tijdens de feedbackrondes niet tevreden? Dan gaan we samen aan tafel om helder te krijgen waarom dit het geval is en kijken we samen naar wat we zijn overeengekomen. Want ons doel is een tevreden klant.

Het evalueren van onze eigen aanpak

Naast ieder project te evalueren, zijn we ook continu onze aanpak onder de loep aan het nemen. De afgelopen jaren hebben we veel tijd geïnvesteerd in het concreet maken van opdrachten door middel van een afsprakendocument en functioneel ontwerp. Hierdoor weten zowel wij als onze klant exact wat we gaan opleveren, waardoor er geen verwarring meer ontstaat in een later stadium. We proberen altijd aan te sturen op een heldere “definition of done”, zodat zowel wij als de klant weten wanneer een feature, set van features en het totale project klaar zijn.

Een belangrijke focus in ons werk is het verminderen van rework, oftewel het achteraf moeten wijzigen van onderdelen. Dit is vaak de grootste kostenpost binnen een project, omdat het concreet maken van wat wél gewenst is veel tijd kost. Maar ook omdat ieder onderdeel vaak gerelateerd is aan het geheel, vertelt Coen:

“Binnen softwareontwikkeling kan het soms zo zijn dat een functionaliteit invloed heeft op een andere functionaliteit. Waardoor je niet één functionaliteit aan het herbouwen bent, maar ook nog andere zaken eromheen. Dat alles kost heel veel tijd en gaat ten koste van je efficiëntie.”

Om de tijd die we kwijt zijn aan rework te verminderen zijn we actief bezig met het documenteren van de specifieke wensen van de klant in de oriëntatiefase. We zijn voorstander van het shift-left principe: We proberen zo veel mogelijk duidelijkheid te creëren in het project, voordat we gaan ontwerpen en ontwikkelen. Zo voorkomen we dat onderdelen die we opleveren anders zijn dan verwacht.

Ons beleid met betrekking tot intellectueel eigendom en exits

De broncode van de door ons ontwikkelde software is altijd vrij op te vragen. Onze klanten zijn vrij om de broncode aan te passen en te gebruiken, zolang dit onder de voorwaarden van de GPL licentie valt. Veel software die we leveren, wordt geleverd onder deze licentie, wat ervoor zorgt dat onze klant de enige is die gerechtigd is om de broncode bij ons op te vragen.

De broncode blijft daarmee eigenaar van Four Digits, terwijl onze klanten wel de vrijheid krijgen om de broncode over te nemen en te wijzigen. Mocht deze gewijzigd worden, kan deze echter niet zonder toestemming van Four Digits draaien op het door ons beschikbaar gestelde hosting platform. Natuurlijk zijn uitzonderingen of andere vormen altijd bespreekbaar met de klant. Belangrijker vinden we dat we altijd openstaan richting klanten om te praten over een exit strategie, ook al staan we aan het begin van een project. Het is belangrijk om over na te denken.

We werken alleen met open source software, zoals Python, Django, Wagtail, React en HTMX. Hierdoor bieden we de meest flexibele oplossing aan, zowel voor klanten als voor ons. Siemen vult aan:

“Onze klanten hebben volledig betaald voor hun software, dus zijn vrij om met de code te doen wat ze willen. We willen absoluut geen lock-in, dat onze klanten zich verplicht voelen om bij ons te blijven.”

Misschien is deze vrijheid onder andere de reden dat onze klantrelaties zo langdurig zijn. We hebben klanten die al 15 jaar met ons samenwerken. En als klanten vertrekken, is dit vaak om redenen die we niet in de hand hebben. Zo zijn overheidsorganisaties verplicht om iedere opdracht opnieuw aan te besteden, waardoor er altijd een moment komt dat onze samenwerking stopt.

Bij Four Digits geloven we in langetermijnrelaties met onze klanten. We zien onze software als een middel om de organisatie die we bedienen te ondersteunen in hun groei. Daarom zijn we altijd geïnteresseerd in de bedrijfsvisie en processen, want onze software wordt een verlengstuk hiervan.

Op naar de laatste fase: Doorontwikkeling en support

In deze blog hebben we je laten zien hoe de afronding van een softwareproject in zijn werk gaat. Maar dat wil niet zeggen dat het klaar is! Bij de livegang van onze software start een geheel nieuw hoofdstuk in de software development life cycle. Want zoals ieder product heeft software baat bij structureel onderhoud. Zo garanderen we dat je software goed onderhouden, ondersteund en veilig blijft. Tijdens het ontwikkeltraject nieuwe ideeën opgedaan? Of zie je kansen hoe de software je organisatie nog verder kan helpen? Dan ontwikkelen we gewoon lekker door.

De laatste blog van onze achter de schermen serie gaat dan ook over doorontwikkeling en support. In deze blog laten we je zien hoe we onze software blijvend ondersteunen en hoe doorontwikkeling eruit ziet.

Eerst onze vorige blogs teruglezen? Je vindt ze hier terug:

1. Hoe start een nieuw software project? Getting ready.
2. Het voorbereiden van een nieuwe software project.
3. De modelleringsfase van een software project.
4. Ontwikkelen, testen & reviewen