Wat maatwerk vraagt van je software development partner Een organisatie kiest voor maatwerk wanneer haar processen niet goed in een standaardpakket passen. Denk aan prijsafspraken die per klant verschillen, een planning die afhangt van realtime voorraad of regelgeving die om specifieke controles vraagt.

Een standaardpakket beoordeel je op de functionaliteiten die er al zijn. Maatwerk ontstaat tijdens het project, wanneer functionele wensen, technische mogelijkheden en nieuwe inzichten samenkomen. De mensen met wie je bouwt zijn daarom minstens zo belangrijk als de technologie die zij gebruiken. Bij Dawn Technology werken we met het Triple Diamond-model, dat bestaat uit drie fases: Discovery, Design en Realisatie. In elke fase werken verschillende specialisten samen met jouw organisatie. Een agile projectmanager begeleidt het hele traject. Net als een scrummaster ondersteunt die het ontwikkelteam, maar bewaakt daarnaast ook de scope, planning en het budget. Zo houd je zicht op de voortgang en de gevolgen van eventuele wijzigingen.

Fase 1: Discovery, de vraag achter je vraag Organisaties komen geregeld met een oplossing in gedachten, bijvoorbeeld een nieuw klantportaal. In Discovery onderzoeken we eerst welk probleem daarachter zit. Met interviews, workshops en een analyse van bestaande eisen brengen we gebruikers, processen, knelpunten en de IT-omgeving in kaart.

Daarbij zijn verschillende specialisten betrokken. De architect of tech lead onderzoekt welke systemen er al draaien, waar de nieuwe software op moet aansluiten en welke technische randvoorwaarden gelden. De service designer en UX-onderzoeker spreken met gebruikers om te achterhalen waar processen vastlopen en wat zij nodig hebben. De businessanalist vertaalt samen met jouw organisatie de processtappen en uitzonderingen naar concrete requirements en user stories.

Customer journeys maken zichtbaar waar gebruikers, processen en systemen elkaar raken. Zo wordt duidelijk welke koppelingen kritisch zijn en welke processen niet verstoord mogen worden. Ook de eisen aan privacy, security, performance en toegankelijkheid komen in deze fase aan bod. Ligt de oplossingsrichting nog open, dan kunnen we verschillende mogelijkheden verkennen, bijvoorbeeld in ons Innovatielab.

Discovery resulteert in een functioneel ontwerp met procesflows, gebruikersrollen, wireframes van de belangrijkste schermen en een afbakening van de scope. Daarnaast ligt er een backlog met user stories. Jouw organisatie beoordeelt en valideert deze resultaten voordat we verdergaan. Zo ontstaat een gedeeld beeld van wat er gebouwd moet worden en waarom. De architect weet bijvoorbeeld niet alleen dát er een koppeling met jouw financiële systeem nodig is, maar ook waarom die cruciaal is voor het bedrijfsproces.

Fase 2: Design, de technische basis bepalen Wanneer het probleem en de context duidelijk zijn, bepalen we hoe de oplossing technisch in elkaar zit. Onze architect werkt de functionele eisen uit tot een technische aanpak en bewaakt de samenhang met bestaande applicaties en koppelingen. Heeft jouw organisatie een eigen architect of IT-manager, dan sluit die aan bij belangrijke afwegingen en beslissingen.

We kiezen de frameworks en platforms die passen bij het vraagstuk en de bestaande IT-omgeving. Ook leggen we vast hoe integraties werken en hoe de eisen uit Discovery technisch worden ingevuld. De gemaakte keuzes en de afwegingen daarachter documenteren we, zodat later te herleiden is waarom de software op een bepaalde manier is gebouwd. Wanneer beslissingen meerdere systemen of de bredere IT-strategie raken, kan aanvullend IT-advies nodig zijn.

Ook de infrastructuur krijgt aandacht. Op basis van het verwachte aantal gebruikers, piekbelasting en de eisen aan performance en beschikbaarheid kiezen we samen een geschikte omgeving: public cloud, private cloud of on-premises. Daarbij houden we rekening met toekomstige groei en beheer. Niet alles wat technisch mogelijk is, is ook de verstandigste oplossing. Soms is nieuwbouw nodig, terwijl hergebruik van een bestaande component in andere gevallen eenvoudiger, goedkoper of beter onderhoudbaar is. Zulke alternatieven bespreken we voordat de bouw begint.

Frank Pinxt, projectmanager bij SURF, omschrijft die samenwerking als volgt: “Ze zijn heel proactief: geen partij die de opdracht afwacht en dan aan de slag gaat. Integendeel, ze denken kritisch en pragmatisch mee en doen zeker niet klakkeloos wat je vraagt. Dat vind ik een meerwaarde.” Bij SURF dacht Dawn Technology bijvoorbeeld mee over de zoektechnologie binnen de databases van de organisatie.

Fase 3: Realisatie, bouwen, testen en bijsturen Een goed ontwerp geeft houvast, maar tijdens de bouw komen onvermijdelijk nieuwe inzichten naar boven. Een integratie gedraagt zich anders dan verwacht of een functionaliteit blijkt complexer. Daarom werken we in sprints van doorgaans twee tot drie weken, waarin bouwen, testen en verbeteren naast elkaar lopen.

De tech lead bouwt mee, bewaakt de technische kwaliteit en stemt waar nodig af met jouw IT-team. Developers ontwikkelen de functionaliteiten en stellen vragen over processen en uitzonderingen rechtstreeks aan jouw product owner en betrokken collega's. Een functioneel tester controleert of de software aan de afgesproken eisen voldoet.

Vooraf leggen we vast wanneer een onderdeel klaar is om te bouwen en aan welke criteria het resultaat moet voldoen. Bij de sprintplanning krijgen taken met de grootste risico's en complexiteit voorrang. Tijdens een dagelijkse stand-up van maximaal vijftien minuten, waarbij ook jouw product owner aansluit, bespreekt het team de voortgang en eventuele knelpunten.

Kwaliteitsbewaking is onderdeel van iedere sprint. Een collega-developer beoordeelt de code, automatische tests controleren of bestaande onderdelen blijven functioneren en de functioneel tester toetst de nieuwe functionaliteit aan de afgesproken criteria. Pas daarna wordt deze beschikbaar gesteld op de acceptatieomgeving.

Aan het einde van iedere sprint laat het team in een demo zien wat er is gebouwd en hoeveel uren daaraan zijn besteed. Ook wordt duidelijk of planning en budget nog op schema liggen. Vervolgens kan jouw organisatie de software zelf testen.

Nieuwe wensen kunnen tijdens de ontwikkeling worden meegenomen, maar niet zonder de gevolgen te bespreken. De projectmanager maakt inzichtelijk wat een wijziging betekent voor de kosten en doorlooptijd. Jij beslist of die wordt doorgevoerd of dat er iets anders voor moet wijken.

Praktijkvoorbeeld: 70 testgebruikers bij The Content Exchange The Content Exchange (TCE) is een B2B-platform waarop redacties, uitgeverijen en freelancers content aanbieden en (her)publiceren. Het platform regelt onder meer rechten, prijzen, voorwaarden en betalingen automatisch.

Dawn Technology ontwikkelde de software in sprints van twee weken. Nadat de eerste versie, het minimum viable product (MVP), was vastgesteld, gingen ongeveer 70 testgebruikers, onder wie redacteuren, met het platform aan de slag. Tijdens de pilot gaven zij iedere sprint feedback op de ontwikkeling. Door gebruikers al tijdens de bouw te betrekken, konden aannames vroeg worden getoetst en functionaliteiten worden bijgesteld op basis van praktijkervaring.

Na de laatste sprint: testen, livegang en beheer Ook na de laatste ontwikkelsprint is het werk nog niet klaar. Jouw testers en domeinexperts controleren samen met ons of de software aan de afspraken voldoet. Daarnaast leveren we rapporten op van een toegankelijkheidsaudit, een onafhankelijke architectuurreview, een performancetest en een security-audit. Bugs lossen we op voordat de software wordt geaccepteerd. Blijkt een bevinding geen fout, maar een nieuwe wens, dan wordt die via het afgesproken wijzigingsproces behandeld.

De livegang bereiden we voor met een draaiboek waarin staat welke stappen op welk moment worden gezet en wie daarvoor verantwoordelijk is. Ook spreken we af hoelang het team na de livegang extra beschikbaar blijft om eventuele opstartproblemen op te lossen.

Al vóór de laatste sprint maken we afspraken over support, hosting en beheer, eventueel vastgelegd in een service level agreement. Binnen Support & Lifecycle Management helpen monitoring en preventief onderhoud om problemen vroegtijdig te signaleren en te voorkomen. Ook kan de software worden aangepast wanneer browsers, wetgeving of gebruikerswensen veranderen. Wil je het beheer liever zelf uitvoeren, dan dragen we de software zorgvuldig over aan jouw team.

Benieuwd hoe we jouw project aanpakken? Leg je case aan ons voor, dan denken we met je mee.

• https://dawn.tech/product-service/software-development
• https://dawn.tech/product-service/ideation-discovery