Achter de schermen deel 6: Doorontwikkeling & support

In deel 1 en deel 2 hebben we je het belang van de oriëntatiefase laten zien. Het is in deze fase dat we samen met onze klant helder krijgen wat we precies gaan ontwikkelen.

Pas als de exacte opdracht duidelijk is en zowel het afsprakendocument als het functioneel ontwerp goedgekeurd zijn gaan we door naar de volgende fase die we beschrijven in deel 3: De modelleringsfase. In deze fase bepalen we de software architectuur en visualiseren we het eindresultaat door wireframes op te zetten. Door een visuele representatie van de software te creëren kunnen we het makkelijker begrijpen en beheren. En onze klant kan precies zien wat ze opgeleverd krijgen. Als de wireframes goedgekeurd zijn, starten we pas echt met de daadwerkelijke ontwikkeling.

In deel 4 van onze blogserie vertellen we je hoe ons ontwikkelproces en testproces eruit zien. In deel 5, de afrondingsfase, delen we vervolgens hoe het proces van gegevensmigratie eruitziet en hoe we onze projecten en eigen aanpak evalueren.

Maar we zijn nog niet klaar. Want een software project eindigt vaak niet bij de oplevering. Zoals ieder product heeft software baat bij structureel onderhoud. Maar ook aan doorontwikkeling. Organisaties evolueren continu en hebben software nodig die met de organisatie meebeweegt. Daarom blijven we na de livegang altijd in contact met onze klant. Zijn er veranderingen in de organisatie, de markt of wettelijke regelgeving? Dan kunnen we snel schakelen om de software mee te laten evolueren.

In deze blog vertellen we je waarom doorontwikkeling en support cruciaal zijn voor het up-to-date houden van je software en hoe dit proces er binnen Four Digits uit ziet. Laten we beginnen!

Hoe we doorontwikkelingsprojecten aanpakken

Doorontwikkeling is het verrijken van de software, zodat deze nog beter aansluit bij de processen en visie van de organisatie. Vaak heeft doorontwikkeling als doel om de efficiëntie nog verder te vergroten, of om een organisatie te laten groeien. Soms lopen klanten tegen problemen aan die ze van tevoren niet hadden voorzien. Of omdat ze een kans signaleren die het gebruiksgemak nog verder kan vergroten. Wat de reden ook is, doorontwikkeling is vaak noodzakelijk om software up-to-date te houden.

We adviseren onze klanten altijd om softwareonderhoud in de toekomst mee te nemen. Het is belangrijk dat deze onderhouden wordt en up-to-date blijft op het gebied van techniek en security. Maar ook om ervoor te zorgen dat de software met je organisatie mee kan blijven evolueren. Ook bij doorontwikkeling hanteren we het shift-left-principe, waarbij we in de beginfase al compleet helder willen hebben wat we gaan ontwikkelen. We houden de software dan ook actief bij, zodat een groot upgrade traject voorkomen wordt. Deze zijn namelijk vaak kostbaarder en kosten meer tijd.

Over het algemeen hebben we dezelfde aanpak voor doorontwikkelingsprojecten als gewone projecten. Want ook als het gaat om doorontwikkeling is het van groot belang dat we kritisch zijn op de hulpvraag van de klant. Coen vertelt:

“Als een klant met de vraag komt om X voor ze te maken, dan is mijn eerste vraag: Oké, wat is het probleem dat we willen oplossen? Want vaak willen klanten al een oplossing komen, zonder dat we weten welke probleem we nu precies gaan oplossen.”

Door het probleem achter de hulpvraag helder te krijgen kunnen we een advies uitbrengen die effectiever is en minder ontwikkelingstijd kost. Vooral omdat wij precies weten hoe de software werkt. Coen vertelt:

“De oplossing die de klant aanreikt kost ons misschien wel 80 uur. Terwijl de oplossingen die we met een kleine tweak kunnen aanleveren ons misschien maar 30 uur kost. Dan geven wij de klant liever het advies om voor onze tweak te gaan, zodat we relatief meer waarde toevoegen en ze zelfs nog tijd over hebben voor andere werkzaamheden”

Als wijzelf of onze klant goede ideeën hebben voor doorontwikkeling tijdens een project, dan bespreken we dat vaak tussendoor met onze klant en plaatsen het op de backlog. Als onze klant het hier mee eens is, kunnen de tijdens het project verzamelde ideeën later gebundeld worden in een doorontwikkelingsproject.

Hoe onze supportvormen eruit zien

Als we een opdracht aannemen, zit support altijd op een of andere manier verwerkt in de opdracht. Als klanten ons vragen om software te onderhouden werken we met verschillende vormen:

Service Level Agreement (SLA)

Bij een Service Level Agreement gaan we een doorlopende overeenkomst aan waarin afspraken staan over hoeveel uren wij beschikbaar stellen en welke diensten we daarvoor doen. Ook garanderen we een snelle reactietijd, waarvoor we capaciteit reserveren. Dit is de vorm die het meeste zekerheid biedt. Deze vorm adviseren we dan ook aan onze klanten.

Prepaid

Bij prepaid wordt er van tevoren een bedrag afgesproken met de klant en spreken we af hoeveel ontwikkelingsuren wij kunnen inzetten voor het afgesproken budget. Deze vorm zetten we vooral in om te voorkomen dat we voor elke kleine feature een offertetraject moeten starten. Dit weegt vaak niet op tegen de tijd die we erin stoppen.

Op afroep

Bij support op afroep houden we onze gewerkte uren bij en brengen we deze achteraf in rekening. Deze vorm werkt op basis van best effort, waarbij we altijd tijd proberen vrij te maken voor onze klant. Maar klanten die een SLA met ons hebben afgesproken hebben voorrang.

Vaak zien we dat een SLA vooral afgesloten wordt door klanten die meer zekerheid willen op het gebied van ondersteuning en software onderhoud. Doorontwikkeling vindt vaak plaats op basis van een nieuw offertetraject, terwijl prepaidkaarten gebruikt worden voor verschillende features.

Hoe we onze klanten leren onze software te gebruiken

Als het gaat om een nieuwe website is de klant zelf verantwoordelijk voor de content. Dit wordt gedaan door de klant zelf of werken we met een partner. Op het moment dat een nieuwe website is opgeleverd leggen we aan het redactieteam van de klant uit hoe het CMS werkt. Gaat het om een webapplicatie of API koppeling? Dan geven we voorlichtingen aan de gebruikersgroep, technische afdeling of mede-ontwikkelaars.

Als het gaat om grote hoeveelheden content, verzorgen we een train-de-trainer traject waarbij wij mensen opleiden in de organisatie. Deze mensen worden vervolgens het aanspreekpunt voor andere mensen in de organisatie die met de software werken en kunnen vervolgens zelf trainingen en cursussen verzorgen. Siemen vertelt:

“Bij zowel websites als applicaties wordt er vanaf het begin van een traject al een interne stakeholder aangewezen die de software goed leren kennen.”

Door deze stakeholder strategie toe te passen weten we zeker dat de kennisoverdracht in een vroeg stadium al gebeurt, zodat we niet overspoeld worden met vragen na de oplevering.

Een doorontwikkeling case study: Humanitas

Landelijke vrijwilligersorganisatie Humanitas is een snelgroeiende organisatie die een enorme database aan vrijwilligers en hulpzoekenden beheert. Alle activiteiten, hulpzoekenden en vrijwilligers worden samengebracht in een webapplicatie: Het Humanitas Registratie Systeem (HRS).

Jaren geleden hebben we Humanitas proactief geadviseerd om het verouderde systeem te vervangen door een compleet nieuwe technologie stack, waarbij we het systeem inclusief alle data gemigreerd hebben naar HRS 2.0. De onderliggende techniek van het oude systeem werd namelijk niet meer ondersteund. Ook waren er weinig ontwikkelaars beschikbaar voor de achterliggende techniek. Een groeiend risico. Beveiligingsupdates waren verleden tijd en de software-stack was zo verouderd dat innoveren vrijwel onmogelijk was. Siemen vertelt:

“Humanitas groeit als organisatie gigantisch snel. Wat ze nu doen ten opzichte van wat ze deden toen ze begonnen is echt compleet anders, vooral qua hoeveelheid acties die worden uitgevoerd.”

Door monitoring zagen we dat de limieten van het oude systeem bereikt werden. Wij hebben toen geadviseerd de complete website en database te migreren naar Django, wat we vervolgens ook uitgevoerd hebben. Maar daar bleef het niet bij. Door de constante groei heeft Humanitas regelmatig behoefte aan nieuwe features vertelt Siemen:

“Ze komen tot nieuwe inzichten en nieuwe werkwijzen en ze willen continu kleine aanpassingen aan de webapplicatie die dat mogelijk maken.”

Zo treden we al meer dan 14 jaar op als partner in Humanitas’ constante innovatieproces.

Maatwerk software begint bij de juiste partner

Je hebt nu een directe inkijk gekregen achter de schermen van Four Digits. We hebben je laten zien hoe we een softwaretraject van eerste idee tot aan ontwikkeling & support begeleiden. Een intensief proces, waarbij ieder detail een grote impact kan hebben op het eindresultaat.

Dat is ook de reden dat wij als ontwikkelpartner juist in de oriëntatiefase kritisch zijn. Neemt je hulpvraag de problemen waar je tegenaan loopt ook echt weg? Zoja, is dit de meest effectieve oplossing? Door samen in gesprek te gaan en de complete opdracht in de beginfase helder te krijgen, zorgen we er altijd voor dat het uiteindelijke resultaat precies is wat je ervan verwacht.

Ben je nieuwsgierig naar wat we voor jouw organisatie kunnen betekenen? Of hoe we via software op maat jouw organisatie kunnen laten groeien? Vraag een gratis adviesgesprek aan.

Liever eerst de andere blogs van de achter de schermen serie lezen? Je vindt ze hier:

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
5. De afronding