Hoe je van complexe softwareprojecten superprojecten maakt

In dit artikel neem ik je mee in wat ik geleerd heb over wat complexe bedrijfssoftware-projecten echt laat slagen.

Techniek is zelden het echte probleem

De belangrijkste les uit mijn carrière als architect: software is een middel, geen doel op zich. Een klant waar we software voor maken, is altijd op zoek naar een oplossing van een probleem. Zodra je dat probleem goed in kaart hebt, is de onderliggende techniek meestal niet het probleem.

Neem een project dat we deden voor een internationale telecomprovider. Hun strategische doel was simpel: snel groeien door kleinere Europese partijen op te kopen en razendsnel te integreren in hun backend-systeem. Het technische vraagstuk? De IT-systemen van die overgenomen bedrijven inkoppelen, migreren, een tijdje in de lucht houden totdat alle producten zijn overgebracht, en dan uitfaseren. En dat voor meerdere bedrijven tegelijkertijd.

Klinkt complex? Technisch gezien viel het mee.

Het échte probleem bij deze telecomprovider was niet de technische integratie. Het was de snelheid waarmee ze wilden groeien, gecombineerd met de noodzaak om elke overname met minimale inspanning en maximale slagingskans te laten verlopen. Dat vroeg om een heel ander soort denken: procesinrichting, prioritering, en vooral duidelijkheid over wat nu echt moest versus wat later kon.

In B2B gaat alles om de juiste prioriteiten

In consumer-apps kun je features incrementeel uitrollen. Gebruikers leren ze langzaam kennen, geven feedback, en je itereert. Maar in bedrijfssoftware lijkt álles kritiek. Hoe bepaal je dan wat je MVP moet bevatten?

Bij een grote glasvezelnetwerk-provider hebben we dit aan den lijve ondervonden. Er was heel veel glas in de grond gelegd met projecten die tegelijkertijd liepen. Ontzettend dure projecten die goed gemanaged moesten worden, waarbij het verschil tussen slagen en falen behoorlijk dun was. Hun bestaande projectmanagementsysteem kon de capaciteit en hoeveelheid vragen niet meer aan.

We hebben dat systeem in korte tijd volledig herbouwd. Maar wat moest er nou écht direct live? We gingen terug naar de basis: die mensen moeten hun rollen met glasvezel krijgen, de kaarten moeten kloppen, en huizen moeten aangesloten kunnen worden. Dat was de absolute must-have.

Alles daarnaast – de administratie, het beheren van ploegen voor ploegendiensten, rapportages aan het management, alarmeringen, vakanties, weersinvloeden – was allemaal belangrijk, maar stond niet vooraan in de rij. We zorgden ervoor dat de data er wel was, maar alle functies die nodig waren om dat door te geven aan andere systemen kwamen later.

Het mooie is: door zo te prioriteren konden we heel goed schakelen met de klant. "Wat heb je nu nodig? Oké, dan hebben we deze maand zoveel mensen nodig. Daarna schalen we terug afhankelijk van hoeveel druk je krijgt vanuit de organisatie om die andere functies toe te voegen."

Samen dansen zonder op elkaars tenen te staan

Elke klant zoekt hetzelfde: maximale zekerheid voor minimale kosten, zo snel mogelijk. Dat is nooit anders geweest en dat is ook prima. Het punt is: dat vraagt om een dynamisch evenwicht. Je moet leren samen een dansje te doen zonder op elkaars tenen te staan. Soms zegt een klant: "Jongens, luister, deze maand is dit mijn budget, geef me het maximum wat je daarvoor kunt leveren." Andere keren is het: "Ik moet in ieder geval dit hebben, koste wat het kost, voor die tijd." We hoeven daar niet van tevoren keiharde afspraken over te maken. Wat we wel moeten hebben is begrip voor elkaar.

Je kunt erop vertrouwen dat wij, binnen de mogelijkheden, geven wat we kunnen geven. Wij halen altijd het maximale uit het budget wat we van je krijgen. Maar die dans werkt alleen als er vertrouwen is. En vertrouwen betekent dat je open kunt communiceren over waar je zwakke punten liggen, waar je je onzeker over voelt. Dat wij durven zeggen: "Dit hebben we nog nooit eerder gedaan" of "Deze schaal is nieuw voor ons." En dat de klant dan antwoordt: "Nou, ik heb er vertrouwen in dat het goed komt."

Het komt ook altijd goed. Maar alleen als we het samen doen.

“Techniek is zelden het echte probleem. Het gaat om vertrouwen.”

Van intensief naar routine

Een project begint altijd intensief. Je moet elkaar leren kennen, vertrouwen opbouwen, het technische landschap begrijpen. Je kunt niet verwachten dat dit zomaar geregeld is. In het begin communiceer je dagelijks, soms meerdere keren per dag.

Maar als mensen elkaar kennen, het systeem bekend is en het project, zeg, drie maanden loopt, kom je in een vaste cadans. Elke twee weken spreken we elkaar en laten we zien wat we in die twee weken hebben gepresteerd en wat de volgende twee weken zullen opleveren. Soms is een half uurtje genoeg, zolang het maar genoeg is om ervoor te zorgen dat die backlog gevuld blijft met precies die dingen die de klant dan echt nodig heeft.

En dan, na het MVP, gebeurt er iets interessants. Je valt vaak in een soort gat. De klant denkt: "Poeh, nou..." En wij denken: "Dat staat mooi, we willen graag door naar versie 1." Maar de organisatie van de klant wil graag eerst even evalueren: wat heb ik allemaal geleerd? Ga ik nog zo door? Want met deze MVP heb ik zoveel bijgeleerd, of is de wereld zo veranderd, dat ik even moet heroriënteren.

Zes maanden later gaat de telefoon. Nu zijn we mentaal weer klaar voor versie 1. En dan komt er een versie 1, en een versie 2, en een versie 3. Het wordt eigenlijk steeds makkelijker, als je meebeweegt met elkaars tempo.

Het maakt uit wie je kiest

We maken systemen voor behoorlijk grote partijen – systemen waar ze echt afhankelijk van zijn, waar het echt moet kloppen. Dat is niet een trucje dat we zomaar geleerd hebben. Daar hebben we echt leergeld voor betaald. Bij sommige grote, gerenommeerde softwarepartijen krijg je, omdat je een eenmalige klant bent, een junior team. Ze proberen gewoon wat dingen op je uit en zetten er mensen neer die net van de universiteit komen. Daarmee ga je dus gegarandeerd de bietenbrug op.

Bij Infodation krijg je ervaren senior developers die weten wat ze doen. Die weten wat voor impact het heeft als bepaalde getallen niet kloppen of als dingen niet op elkaar aansluiten. Die gewoon met de voeten in de klei staan elke dag en die weten wat jou proces voor jou betekent.

Uiteindelijk gaat het om software als enabler voor jouw doelen, niet als doel op zich. Raad en daad zijn belangrijker dan technische trucjes. En partnership – dat samen dansen – maakt het verschil tussen een project dat slaagt en een project dat je alleen maar geld en tijd kost.

Want techniek? Daar komen we wel uit. Het gaat om vertrouwen.