Een proces dat over vijf afdelingen loopt, drie systemen die elkaar tegenspreken en een wensenlijst die bij elk overleg groeit. Zo ziet een complex vraagstuk er in de praktijk uit. De verleiding is om daar een even complex antwoord tegenover te zetten: één systeem dat alles doet. Onze ervaring sinds 2001 wijst de andere kant op. De beste oplossing is bijna altijd eenvoudiger dan het vraagstuk deed vermoeden.
Die eenvoud ontstaat niet door een slim idee op het juiste moment. Ze ontstaat door een manier van werken: ordenen, afwegen en durven weglaten.
Eerst de vraag ontwarren, dan ontwikkelen
Wie bij ons komt met een softwarevraag, heeft die meestal intern al uitgebreid besproken. Er is een wensenlijst, opgebouwd uit eigen ervaring en uit wat je elders hebt gezien. Die lijst is waardevol, maar nog geen ontwerp. Wensen die eenvoudig klinken, blijken soms lastig om te ontwikkelen; wensen die ingewikkeld lijken, zijn soms verrassend snel te maken. Daarom beginnen we niet met bouwen, maar met ordenen: welk doel dient elke wens, wie gebruikt die elke dag en wat gebeurt er als hij vervalt? Zodra de vraag achter de vraag op tafel ligt, verdwijnt een groot deel van de complexiteit.
Complexiteit zit vaak tussen systemen, niet erin
Opvallend vaak zit de kern van een complex vraagstuk niet in een systeem, maar in de ruimte tussen systemen. Data wordt van het ene pakket in het andere overgetypt, rapporten spreken elkaar tegen en medewerkers vullen met de hand aan wat de systemen laten liggen. Het vraagstuk voelt dan als “we hebben nieuwe software nodig”, terwijl het eenvoudige antwoord een integratie is die bestaande systemen laat samenwerken. We schreven eerder over wat er misgaat als systemen niet met elkaar communiceren; hier werkt dezelfde logica andersom: een goede integratie kan een web van handmatig werk vervangen.
Iets haalbaar maken betekent keuzes maken
Alles binnen een vast budget bouwen werkt zelden, en dat hoeft ook niet. Wat wel helder moet zijn: wat elke keuze kost en wat die oplevert. Die afweging kun je als klant niet alleen maken: daarvoor moet je inschatten wat iets kost om te ontwikkelen, en dat is precies ons vak. Voorafgaand aan een project zetten we per onderdeel op een rij wat het vraagt, wat het oplevert en of het eenvoudiger kan zonder het doel te verliezen. Vragen die onderweg op tafel komen:
- Van welk deel van het vraagstuk is aantoonbaar dat het je organisatie nu tijd of geld kost?
- Wat moet vanaf dag één werken, en wat kan wachten tot een latere fase?
- Welke bestaande systemen blijven staan, en waarmee moet de oplossing koppelen?
- Waar doet een eenvoudigere versie wat nodig is, terwijl die dicht blijft bij wat je eigenlijk wilt?
Het resultaat is een functioneel ontwerp met een planning en een budget: een blauwdruk die voor de klant en het ontwikkelteam hetzelfde betekent. Pas daarna beginnen we met ontwikkelen.
Nieuw inzicht onderweg hoort bij het proces
Zodra de eerste schermen werken, komen er vaak nieuwe ideeën boven. Dat is geen teken van slechte voorbereiding, maar een teken dat het goed gaat: pas als een applicatie vorm krijgt, kan een klant het geheel overzien. Intussen bewaken we de scope en wegen we elk nieuw inzicht tegen het grotere geheel. Soms is een aanpassing het extra budget waard, soms past die beter in een latere fase. Zolang dat gesprek open blijft, zijn er geen verrassingen, en zonder verrassingen blijft ook een groot project beheersbaar.
Twijfel je of je vraagstuk vraagt om nieuwe software of om betere samenwerking tussen de systemen die je al hebt? Leg het aan ons voor. Op de dienstenpagina lees je hoe we data-integraties aanpakken; in een eerste gesprek ontwarren we waar de complexiteit in je organisatie vandaan komt.