Een van de gevaarlijkste zinnen aan het begin van een softwareproject is:
"We weten eigenlijk al precies wat we nodig hebben."
Soms klopt dat. Vaak blijkt het probleem net anders in elkaar te zitten zodra je kijkt naar de mensen die ermee werken, de uitzonderingen in het proces en de systemen die eromheen hangen.
Daarom beginnen we bij maatwerksoftware liever niet met code.
We beginnen met begrijpen.
De eerste oplossing is vaak gebaseerd op het huidige proces
Organisaties weten meestal heel goed waar het schuurt.
Een planner heeft geen overzicht. Medewerkers voeren dezelfde gegevens meerdere keren in. Rapportages kosten iedere maand een paar dagen handwerk. Informatie zit verdeeld over Excel, SharePoint, e-mail en een extern pakket.
Logischerwijs ontstaat vervolgens een idee voor een nieuw systeem.
"We hebben een dashboard nodig."
"We willen één nieuw portaal."
"Kunnen jullie deze drie formulieren digitaliseren?"
Dat zijn prima startpunten, maar nog geen ontwerp.
Voordat we bepalen wat we gaan bouwen, willen we weten waarom het nodig is.
Eerst het vraagstuk uit elkaar halen
In de eerste fase kijken we meestal naar een combinatie van processen, mensen en informatie.
Wie gebruikt het systeem? Welke beslissing probeert die persoon te nemen? Waar komt de benodigde data vandaan? Welke uitzonderingen komen in de praktijk voor? Wat gebeurt er wanneer informatie ontbreekt? Welke handelingen worden alleen uitgevoerd omdat het huidige systeem iets niet kan?
Dat levert soms verrassende inzichten op.
Bij een planningsvraagstuk kan het echte probleem bijvoorbeeld niet het planscherm zijn, maar het ontbreken van betrouwbare beschikbaarheidsgegevens.
Bij een integratieproject kan blijken dat drie systemen verschillende definities hanteren voor hetzelfde begrip.
En bij een rapportagevraag kan het meeste werk misschien verdwijnen door de datastroom eerder in het proces anders in te richten.
We zien dat terug in heel verschillende projecten
De projecten waaraan we werken verschillen inhoudelijk sterk, maar het patroon is vaak vergelijkbaar.
Bij SPIE komen planning, uren, documenten en samenwerking rond projecten samen. Dan moet je niet alleen een prettig scherm bouwen, maar begrijpen hoe informatie door verschillende rollen en momenten in het proces loopt.
Bij SGS Food Analytics gaat het om logistiek rond calls, planning, depots en de route van monstername naar laboratorium. Daar bepaalt de praktijk welke informatie op welk moment betrouwbaar beschikbaar moet zijn.
Bij Elvera begint de uitdaging juist aan de andere kant: ruwe gegevens uit sensoren en meters moeten worden samengebracht, gecontroleerd en bruikbaar gemaakt voor dashboards, analyses, meldingen en koppelingen.
Drie totaal verschillende omgevingen. Maar in alle drie geldt: het scherm is maar het zichtbare deel van het systeem.
Van onderzoek snel naar iets tastbaars
Begrijpen betekent bij ons niet dat we maandenlang analyses schrijven voordat er iets gebeurt.
Zodra de kern van het vraagstuk duidelijk genoeg is, willen we juist snel iets maken waar mensen op kunnen reageren.
Dat kan een wireframe zijn, een interactief ontwerp of een klein werkend onderdeel.
Een gebruiker die naar een echt scherm kijkt, ziet vaak dingen die in een gesprek niet naar boven komen.
"Hier kan ik eigenlijk pas verder als collega X dit heeft gecontroleerd."
"Deze waarde weet ik op dit moment helemaal nog niet."
"Dit gebeurt misschien vijf keer per jaar, maar dan is het wel heel belangrijk."
Dat soort opmerkingen zijn waardevol. Ze laten zien waar een theoretisch proces afwijkt van de dagelijkse werkelijkheid.
Niet alles hoeft in versie één
Een ander voordeel van vroeg concreet maken is dat je beter kunt bepalen wat echt nodig is.
Maatwerksoftware wordt snel groot wanneer iedere wens direct onderdeel van de eerste versie wordt.
Wij proberen daarom onderscheid te maken tussen:
- wat nodig is om de kern van het proces te laten werken;
- wat veel handmatig werk wegneemt;
- wat risico's of fouten vermindert;
- en wat vooral prettig zou zijn om ooit toe te voegen.
Dat maakt de eerste versie kleiner en leerzamer.
Je krijgt eerder echte gebruikersfeedback en voorkomt dat maanden worden besteed aan functionaliteit waarvan later blijkt dat ze nauwelijks wordt gebruikt.
De techniek komt daarna, maar is niet onbelangrijk
Pas wanneer het probleem scherp genoeg is, wordt de technische vorm echt interessant.
Welke onderdelen horen in één systeem? Welke data blijft bij een bestaand pakket? Waar zijn koppelingen nodig? Wat moet realtime gebeuren en wat mag asynchroon? Hoe regelen we autorisatie, logging en monitoring? Welke onderdelen moeten schaalbaar of vervangbaar zijn?
Daar maken we bewuste keuzes in.
Niet om de architectuur zo ingewikkeld mogelijk te maken, maar juist om de complexiteit op de goede plek op te lossen.
Software ontstaat in rondes
Een werkend platform is uiteindelijk zelden het resultaat van één perfecte specificatie.
Het ontstaat in rondes:
begrijpen, ontwerpen, bouwen, gebruiken, leren en verbeteren.
De kunst is om iedere ronde klein genoeg te houden om te kunnen bijsturen en stevig genoeg om er echt iets van te leren.
Dat is hoe we het liefst van een vaag idee naar software gaan die uiteindelijk iedere dag wordt gebruikt.