Softwareontwikkeling met vaste aandacht en ruimte om bij te sturen
Software moet kunnen meegroeien met de manier waarop je werkt. Met Developer as a Service werken we doorlopend aan nieuwe functies, verbeteringen en technische kwaliteit.
We maken vooraf duidelijk wat prioriteit heeft en leveren in stappen op, zodat gebruik en feedback de volgende keuze kunnen beïnvloeden.
Doorlopende softwareontwikkeling met DaaS
Met Developer as a Service werken we doorlopend aan jouw software. Je neemt afgesproken ontwikkelinzet af. Samen bepalen we welke onderdelen prioriteit krijgen en wat de volgende stap is.
DaaS levert geen onbeperkte hoeveelheid software en geen vaste hoeveelheid nieuwe functies per maand. De voortgang hangt samen met de afgesproken inzet, de complexiteit van het werk, afhankelijkheden en de keuzes die we samen maken. We werken met drie niveaus: de richting op de roadmap, de geprioriteerde werklijst voor de komende periode en een concreet oplevermoment voor een afgebakend onderdeel.
Bij een nieuwe toepassing beginnen we bij de taak die ondersteund moet worden. Bij bestaande software beginnen we bij een beoordeling van code, architectuur, gegevens, afhankelijkheden, gebruikers, toegang en belangrijke risico's. We beloven geen volledige overname voordat die staat is onderzocht.
Die beoordeling bepaalt ook hoe snel er iets zichtbaars kan worden opgeleverd. Bij een goed gedocumenteerde toepassing kan een eerste verbetering sneller worden doorgevoerd dan bij een systeem waarvan de opbouw eerst moet worden uitgezocht.
Een ontwikkelcyclus in de praktijk
- 1.Prioriteit kiezen. De klant bepaalt samen met ons welk onderdeel als eerste aandacht krijgt.
- 2.Acceptatiecriteria vastleggen. Vooraf staat vast waaraan het resultaat moet voldoen.
- 3.Bouwen en testen. Het onderdeel wordt ontwikkeld en gecontroleerd voordat het naar de gebruiker gaat.
- 4.Beoordelen met de gebruiker. De persoon die ermee werkt, geeft aan of het de taak ondersteunt.
- 5.Gecontroleerd opleveren. Het onderdeel gaat live binnen de afgesproken omgeving.
- 6.Vervolg bepalen. De volgende prioriteit wordt gekozen op basis van wat er is geleerd.
De frequentie van deze cyclus verschilt per samenwerking. Bij de ene organisatie past een korte cyclus van een paar weken beter, bij de andere past een langere cyclus met meer voorbereidingstijd per stap. Dat wordt per situatie afgesproken, niet standaard vastgelegd.
De rol van de klant
Een extern ontwikkelteam vervangt niet automatisch intern eigenaarschap. Iemand binnen de organisatie moet prioriteiten kunnen kiezen, toegang organiseren, vragen beantwoorden en beoordelen of een toepassing de taak daadwerkelijk ondersteunt.
Wat 'klaar' betekent voor een klein onderdeel, leggen we ook vast: het afgesproken gebruik werkt, relevante rechten zijn gecontroleerd, gevonden fouten zijn besproken en de gebruiker weet hoe ermee te werken.
Zonder een aanspreekpunt aan klantzijde ontstaat het risico dat prioriteiten wisselen zonder duidelijke reden, of dat feedback pas laat bij het ontwikkelteam terechtkomt. Beide vertragen het werk meer dan een korte wekelijkse afstemming zou kosten.
Een ingevulde werklijst
- 1.Nieuwe functie: automatisch een dossier aanmaken bij een nieuwe aanvraag. Reden: aanvragen worden nu los bijgehouden. Acceptatiecriterium: elke binnenkomende aanvraag krijgt een dossier met de juiste basisgegevens.
- 2.Verbetering voor gebruikers: duidelijker overzicht van openstaande taken. Reden: medewerkers missen soms een openstaande stap. Acceptatiecriterium: elke gebruiker ziet zijn eigen openstaande taken op één scherm.
- 3.Technisch onderhoud: verouderde koppeling vervangen. Reden: de huidige koppeling geeft af en toe een foutmelding. Acceptatiecriterium: gegevens worden zonder foutmelding overgezet gedurende een afgesproken testperiode.
Deze drie soorten werk staan bewust naast elkaar. Alleen nieuwe functies bouwen zonder aandacht voor onderhoud leidt op termijn tot meer fouten en een grotere kans op vertraging bij toekomstig werk.
Klein beginnen, volledig werkend
Een eerste versie ondersteunt bij voorkeur één volledige kleine taak, in plaats van meerdere functies die half werken.
Een veelgemaakte fout is het tegelijk starten van meerdere grote functies, waardoor niets op tijd volledig af is. Een kleinere, werkende eerste versie geeft eerder bruikbare feedback dan een half werkend geheel.
Duidelijk over inzet en afspraken
In het voorstel staat welke ontwikkelcapaciteit en welke aanvullende rollen onderdeel zijn van de samenwerking. Daarin maken we ook duidelijk welke afspraken gelden voor ontwerp, projectleiding, testen, documentatie, onderhoud en beheer.
Hosting, licenties, AI-gebruik en andere externe diensten vragen eigen afspraken. Ga er niet van uit dat iedere voorziening automatisch in de ontwikkelprijs is inbegrepen.
De investering hangt af van de opdracht en de afgesproken inzet. In het voorstel staat wat inbegrepen is en welke externe kosten afzonderlijk worden berekend.
Onze algemene voorwaarden gaan uit van een gebruikslicentie. Afwijkend eigendom moet schriftelijk zijn afgesproken. Leg ook vast welke toegang, documentatie en overdracht zijn inbegrepen.
Deze afspraken worden per samenwerking op papier gezet, zodat ze niet afhankelijk zijn van losse toezeggingen tijdens een gesprek.
Wanneer deze werkwijze minder past
Heb je behoefte aan een volledig vastomlijnd project met een vaste prijs en een vaste opleverdatum voor een eenmalige toepassing, dan is DaaS niet de vorm die daarbij aansluit. Bespreek in dat geval eerst welke samenwerkingsvorm wél passend is.
Meer over de bredere technologiekeuzes vind je op de pagina over technologie. Zie ook automatisering, AI-toepassingen en de case Kitchen Studio.