Software ontwikkelen - of het nu een mobiele applicatie, een website of een groots digitaal platform is - is vaak een langdurig en intensief proces. Als bedrijfsleider of manager heb je niet altijd een goed zicht op waar je in dat proces staat en hoe lang het nog gaat duren. Je kan vaak enkel voortgaan op je software team of agency, dat blijft zeggen “dat het wel goed komt”. Tot op het moment… waarop het niet meer goed komt.

In zo’n geval sta je met je rug tegen de muur. Kostbare budgetten en tijd gingen verloren, de achterstand op de concurrentie is vergroot en de motivatie intern in het bedrijf is geslonken.

In dit artikel ontdek je zeven ‘rode vlaggen’ die je argwaan zouden moeten wekken als je software laat ontwikkelen. Als je één of meerdere van deze vlaggen tegenkomt, is het hoog tijd om de manier van samenwerken met je software team of agency bij te sturen:

1. Geen interesse in je business

Een goede programmeur zal je altijd vragen hoe je business in elkaar zit. Als hij of zij een voorstel doet voor hoe je applicatie zal werken en je gaat daar niet mee akkoord, dan zal de programmeur in kwestie vragen waarom - en niet hoe je het dan wél zag.

Een software team dat die waarom-vragen achterwege laat doet haar werk niet. Het is namelijk ook de job van programmeurs, net zoals die van je marketing team of sales verantwoordelijken, om te begrijpen hoe je business werkt en wat je doelen zijn.

Het programmeren van een software applicatie is namelijk een opeenvolging van duizenden kleine beslissingen. Die kan een programmeur enkel nemen als hij of zij weet waarom je de software laat bouwen.

2. Alles duurt heel lang

Het is OK om geen expert in software ontwikkeling te zijn - je kan niet alles zelf doen. Het nadeel is wel dat je niet altijd kan inschatten hoe lang het zal duren om een bepaalde feature te implementeren. Is een week weinig tijd? Een maand? Als zelfs de simpelste zaken heel lang duren is er wellicht een probleem.

Vaak wijst dit op slechte communicatie: jij hebt iets eenvoudigs voor ogen, maar het software team begint dat te over-engineeren of heeft moeite om uit te maken welke vragen belangrijk zijn en welke niet. Daardoor bouwt het team zeer complexe dingen zonder dat dat nodig is.

3. Deadlines worden niet gehaald

Een goede deadline is een afspraak tussen partijen die zich allemaal engageren om op een bepaald tijdstip op te leveren wat ze beloofd hebben. Als deadlines herhaaldelijk niet gehaald worden, kan dit verschillende oorzaken hebben:

• De deadlines worden opgelegd en niet afgesproken

• Er is geen engagement

• De zaken worden frequent te eenvoudig ingeschat en te ingewikkeld uitgewerkt – zie ook mijn vorige punt

Ik ken weinig software teams die niet geëngageerd zijn. Wat ik wel ken, zijn teams die zeer geëngageerd zijn om hun werk technisch perfect uit te voeren, zonder dat ze rekening moeten houden met de tijdsbeperkingen. Helaas voor hen horen die beperkingen nu eenmaal bij de business, maar ziet niet iedere techneut dat zo.

4. Er is geen duidelijk plan

“Eerst doen we A en dan zien we wel.”

Klinkt bekend? Ik word daar zenuwachtig van. Het is voor iedereen duidelijker als men dit zegt: “Eerst doen we A. Op basis van wat we daar leren, kunnen we dan B of C doen. Daarna volgen D, E en F.” Hoe verder in het alfabet, hoe minder gedetailleerd de dingen omschreven moeten worden. Maar het is wel belangrijk dat ze omschreven zijn. Wil je daar meer over weten? Lees dan zeker mijn posts over hoe je een roadmap bouwt.

5. Er wordt niets getoond

“We kunnen nu niets tonen, want we zijn nog aan de technische onderlaag aan het werken”, is een zin die je misschien al hebt horen vallen in een vergadering. Net als deze: “De aanpassingen die we nu aan het doen zijn, zijn heel technisch. Daardoor heeft het geen zin om iets te laten zien.”

In mijn ervaring zijn dit soort uitspraken het begin van een heel lange periode van wachten, waarin je niets vooruit ziet gaan. Soms is het inderdaad nuttig om technische verbeteringen aan te brengen. Als die verbeteringen echter wekenlang aanslepen, is er veel kans dat er weer veel werk gedaan wordt dat eigenlijk niet nodig is (of dat misschien nodig is wanneer je een miljoen gebruikers hebt, maar nu nog niet)

6. Alles is jargon

Je stelt een vraag in het Nederlands en men antwoordt in het Chinees. Tenminste, zo lijkt het wel. Je krijgt zo’n hoop technisch jargon naar je hoofd geslingerd, dat het je begint te duizelen.

In sommige gevallen is het nuttig om jargon te gebruiken. De term ‘databank’ is nu eenmaal beknopter dan ‘een systeem waarin we efficiënt gegevens kunnen opslaan en opvragen’. Toch kan jargon ook gebruikt worden om de eigen onzekerheid en het eigen falen te verbergen. Te veel jargon verslechtert de communicatie in plaats van haar te verbeteren. Blijf dus vooral doorvragen en vraag aan de technici of ze het ook op een andere manier kunnen omschrijven.

7. Er is één ‘technisch genie’

Elke vraag die je stelt, elk voorstel dat je oppert, wordt beantwoord met “Dat zullen we eerst met Jan afchecken.” Hij is immers de beste developer in huis, ken alle ins en outs van de software en is eigenlijk de enige die weet hoe de software in elkaar zit.

Zie je de risico’s? Jan is een potentiële bottleneck: elke beslissing moet langs hem passeren. En wat gebeurt er als Jan besluit het team te verlaten? Wie weet dan nog hoe je software - jouw investering! - is opgebouwd?

Geen slechte wil

In de meeste teams waar ik zo’n rode vlag zie, vind ik geen slechte wil terug. Development teams stellen zich meestal niet bewust op die manier op. Dat wil niet zeggen dat je niet moet ingrijpen; software projecten die een of meerdere van deze rode vlaggen vertonen, hebben dringend nood aan bijsturing vóór het hele project ontspoort. Maak er werk van.

Herken je een rode vlag in software ontwikkeling waar je mee bezig bent? Kan je wat hulp gebruiken om de situatie recht te trekken? Ik sta voor je klaar.