Software laten maken: hoe een traject verloopt

De meeste vertraging in een maatwerktraject ontstaat niet bij de bouwer, maar bij wat er van de opdrachtgever moet komen: beslissingen, toegang en de uitzonderingen.

De aanvraag

Beschrijf wat er nu misgaat, niet welke oplossing je wilt.

"We willen een portaal waar klanten kunnen inloggen" is een oplossing. "Klanten mailen ons de hele dag om de status van hun order, en we tikken die uit drie systemen bij elkaar" is een probleem — en daar zijn meerdere oplossingen voor, waarvan een portaal de duurste is.

Vijf regels volstaan: wat gaat er nu handmatig, hoe vaak, welke systemen zitten erbij, en hoe ziet "opgelost" eruit.

Scope

Uitzoeken wat er precies gebouwd wordt. Niet in schermen, maar in gedrag: wat er in het normale geval gebeurt, en wat bij de uitzonderingen.

Elke uitzondering die in deze fase boven tafel komt is goedkoop. Dezelfde uitzondering die tijdens het bouwen opduikt, kost een veelvoud, want dan is er al iets gebouwd dat er geen rekening mee hield.

Vraag bij elke stap: gaat dit altijd zo? Het antwoord is vaak nee.

Wat jij levert

• Iemand die beslist. Eén persoon met mandaat. Trajecten lopen zelden uit op techniek en vaak op besluiten die blijven liggen.
• Toegang. Tot de systemen die gekoppeld moeten worden, en tot de mensen die het werk nu doen. Die laatsten weten hoe het echt loopt, inclusief de uitzonderingen.
• Beslissingen over de uitzonderingen. Wat gebeurt er als een klant twee adressen heeft, als een order half geleverd is, als iemand twee keer betaalt. Dat zijn jouw keuzes, geen technische.
• Bestaande gegevens. Wat er nu in spreadsheets en oude systemen zit. Dit is vrijwel altijd meer werk dan begroot.

Bouwen in stukken

Alles in één keer bouwen en aan het eind opleveren gaat vaak mis: je ziet maandenlang niets, en bij de oplevering blijkt een deel anders bedoeld dan gebouwd.

Wat wel werkt: het pijnlijkste stuk eruit halen, dat werkend krijgen, in gebruik nemen, en van daaruit verder. Dat levert onderweg al iets op, en het zorgt dat je stuurt op werkende software in plaats van op een planning.

Reken op weken, niet maanden, voor het eerste bruikbare stuk. Duurt het maanden voordat je iets werkends ziet, dan is er iets mis met de opzet.

Wat er na oplevering gebeurt

Software die aan andere systemen hangt is nooit af, omdat die andere systemen blijven veranderen. Een leverancier faseert een API-versie uit, een portaal wijzigt een formaat, er komt een nieuwe wettelijke eis.

Spreek vooraf af wie dat oppakt en wat het kost. Doe je dat niet, dan valt het een keer stil en is niemand er verantwoordelijk voor.

En zorg dat de code en de data op jouw naam staan, zodat je nooit aan één leverancier vastzit.

Waar het misgaat

1. De huidige werkwijze staat nergens beschreven. Dan is dat het eerste project: eerst op papier uitzoeken is goedkoper dan het tijdens het bouwen ontdekken.
2. De uitzonderingen kwamen laat. Vraag er expliciet naar, per stap.
3. Te veel tegelijk. Zie hierboven.
4. Losgelaten na oplevering. Zie hierboven.

Als je hier hulp bij nodig hebt

Ik bouw dit soort systemen, meestal in Laravel, meestal rond processen die al bestaan. Vaste scope, vaste prijs, en ik zeg het als je beter af bent met een bestaand pakket.

Zie ook: maatwerk software — of maatwerk überhaupt de juiste keuze is.