Goeiedag, ik ben Tom.

Al meer dan 20 jaar ben ik met softwareontwikkeling bezig. Ik durf te zeggen dat ik intussen ongeveer wel weet hoe je dat moet aanpakken. Voor veel andere mensen is dat veel minder vanzelfsprekend. Daarom stel ik mijn kennis en ervaring tegenwoordig ter beschikking van bedrijfsleiders die minder ervaring hebben met het ontwikkelen van software, maar toch beslist hebben om daarop in te zetten.

Zoals elke marketeer je kan vertellen: om je diensten gericht te kunnen aanbieden is het belangrijk te weten met welke problemen je je klanten kan helpen. Om dat beter te begrijpen, vroeg ik aan een aantal bedrijfsleiders welke uitdagingen zij vooral ervaren in het bouwen van softwareproducten.

Een veertigtal mensen waren zo vriendelijk mij een antwoord te geven. Ik deel graag met jou wat ik van hen geleerd heb.

Ik stelde hen vier vragen over het bouwen van software:

Wat is jouw rol in je bedrijf?

Deze vraag was vooral bedoeld om te zien of ik het goede publiek bereikt had. Dat lijkt mij goed gelukt: meer dan 80% van degenen die antwoordden kunnen beslissingen nemen over softwareontwikkeling. Een goeie twee derde waren zelfs bedrijfsleiders. Dat vond ik goed nieuws: als een bedrijfsleider de tijd neemt om een vragenlijst in te vullen, spreekt het onderwerp haar echt wel aan.

Waarom ben je een softwareproduct aan het bouwen?

Anders gezegd: met welk doel bouw je software? Welk probleem wil je oplossen, of welke opportuniteit heb je gezien?

Deze vraag is al interessanter. Het doet me deugd dat niemand antwoordde met "Wij hadden een beter boekhoudprogramma nodig" - in dat geval zou ik iedereen aanraden éérst eens naar de bestaande pakketten te kijken.

• Het grootste deel van de bedrijfsleiders bouwt een product waarmee ze een bestaand aanbod willen aanvullen. Ze willen meer waarde leveren aan hun klanten en zich onderscheiden van hun concurrenten.

• Een achttal mensen geven aan dat ze geen oplossing voor hun probleem vonden in de markt, hoewel de software een kritisch business proces moet ondersteunen. Uit hun antwoorden kan ik afleiden dat die kritische processen allemaal rechtstreeks te maken hebben met het bedienen van hun klanten.

• Een goed deel zegt dat ze geen softwarebedrijf zijn, maar wel een nieuw, stand-alone product op de markt willen brengen, naast hun al bestaande aanbod.

• Tenslotte zijn er de bedrijven die een softwareproduct bedrijf zijn. Hun core business is het bouwen en vermarkten van hun softwareproduct.

Deze vier groepen samen maken driekwart uit van degenen die antwoordden. Wat wil dit zeggen voor mij?

Het draait allemaal om de klant

Wat me opvalt, is dat in elk van deze gevallen de klant centraal staat. Niemand bouwt een softwareproduct enkel en alleen om een intern proces efficiënter te maken - iedereen wil op één of andere manier meer waarde leveren aan haar klant. Het is dus voor iedereen belangrijk om die klant goed te begrijpen.

Als jij als bedrijfsleider een softwareproduct wil bouwen, luister je dus best goed naar je klanten. Maar vergeet niet om wat je van hen leert, ook door te geven aan je software ontwikkelingsteam. Zij gaan het immers moeten doén.

Tegen welke uitdaging loop je het hardst aan bij het bouwen van een softwareproduct?

Met deze vraag wou ik leren wat de voornaamste problemen zijn waar bedrijfsleiders mee te maken hebben wanneer ze software bouwen. Hopelijk zit er iets bij waar ik hen mee kan helpen!

1. Samenwerking

Met stip op één: samenwerking tussen de business en het software team. Voor mij is dit geen verrassing; het is één van de moeilijkste uitdagingen om aan te pakken. Jij vertelt iets op een manier waarvan jij denkt dat het voor iedereen duidelijk is. Je vergeet daarbij waarschijnlijk een paar details te vertellen, want "dat weet toch iedereen". Je softwareteam gaat aan de slag – stelt je tussendoor een paar vragen waarvan je denkt "waar hébben ze het in godsnaam over?" – en komt terug met iets dat helemaal niet lijkt op hetgeen in jouw hoofd zat. Blijkt dat toch niet iedereen weet wat jij weet.

2. Legacy

De tweede belangrijkste uitdaging is hoe om te gaan met legacy. "Legacy" is een verzamelnaam die slaat op "de software die je tot nu toe gebouwd hebt." Het bevat alle beslissingen, goede én foute, die je software gemaakt heeft tot wat het nu is.

Vaak kom je tot de vaststelling dat een aantal van die beslissingen, achteraf gezien, niet de beste waren. Hoe pak je dat aan? Hoe herstel je die beslissingen? Maar vooral: hoe voorkom je om de verkeerde beslissingen te nemen in de toekomst? (Zou het kunnen helpen als je programmeurs mee de beslissingen kunnen nemen? Wat moet er daarvoor gebeuren?)

3. Timing en budget

Eén bedrijfsleider omschreef het heel sappig: "Mensen deadlines laten halen is quasi onmogelijk!" Dit is inderdaad een ongelooflijke uitdaging. Ik heb wel eens de uitspraak gedaan

Development tijd gedraagt zich als een gas: alles neemt zoveel tijd in als het kan.

Als een deadline artificieel is, weten developers dat vaak heel snel, en nemen ze de extra tijd óók gewoon in.

Ik ben ervan overtuigd dat een deel van de oplossing zit in het laten meedenken van je developers over wat ze aan het bouwen zijn. Daarvoor moeten ze heel goed begrijpen wat de waarde is voor de klant. En daarvoor moet jij dat heel goed aan hen uitleggen, op een manier die zij begrijpen.

Het draait allemaal om begrijpen wat de klant wil

Deze drie uitdagingen - samenwerking, omgaan met legacy, en timing - draaien allemaal om hetzelfde: het hele team moet weten wat ze moeten maken, en daarvoor moeten ze heel goed begrijpen wat de klant wil. Het is jouw rol, als bedrijfsleider of product manager, om dat aan hen te communiceren en te laten verstaan. Het is ook de taak van je softwareteam om dat te leren verstaan. Een ontwikkelingsteam dat je business niet kan of wil (leren) begrijpen, zal nooit het product maken dat jij (of je klant!) voor ogen hebt.

Wat heeft momenteel de hoogste prioriteit in de ontwikkeling van je software?

Verbaast het je dat "communicatie" op één staat, op de voet gevolgd door "snelheid en voorspelbaarheid"? Dit reflecteert de uitdagingen van hierboven.

Communicatie werkt in twee richtingen. Het gaat er niet alleen om dat jij uitlegt wat je wil dat er gemaakt wordt. Een aantal bedrijfsleiders vertelden me ook “Het is voor mij heel moeilijk om te weten waar ze op dit moment staan. Wat is er al gebouwd, en wat moet er nog gebeuren? Ik krijg daar maar geen vat op.”

Op die manier hebben “snelheid en voorspelbaarheid” rechtstreeks te maken met communicatie. Hoe kan je voortgang voorspellen als je zelfs niet weet waar je product staat?

Communicatie, communicatie, communicatie

Dàt blijkt de belangrijkste uitdaging bij het bouwen van software: communicatie. Communicatie met je programmeurs: snappen zij wat ze moeten bouwen? Weten ze wat echt belangrijk is? Maar ook omgekeerd: begrijp jij tegen welke problemen ze aanlopen? Kan jij hun vragen beantwoorden? Kan je hen richting geven?

Er gaapt een kloof tussen de business wereld en de software wereld. Je mag er niet vanuit gaan dat je programmeurs die kloof moeten overbruggen - ook jij moet inspanningen doen om tot bij hen te geraken.

Hoe doe je dat?

Probeer een manier van samenwerken te vinden die voor allebei werkt. Iets dat je kan helpen, is bijvoorbeeld op geregelde tijdstippen een demo te organiseren. Je softwareteam laat je, op vooraf afgesproken tijdstippen, zien hoe het product op dat moment in elkaar zit. Dit brengt een aantal zaken teweeg:

• Je team heeft een doel om naartoe te werken. “Op die dag moeten we laten zien dat een gebruiker een document kan afprinten. Dan moeten we nu misschien even niet bezig zijn met het reorganiseren van de databank."

• Je team heeft een moment om naartoe te werken. “Hoeveel tijd heb ik hiervoor? Oei, de demo is overmorgen al, dan ga ik een tandje bijsteken.”

• Je weet beter waar je product staat. “Afprinten heb ik nu gezien; dat werkt dus. Het verwijderen van een document heb ik nog niet gezien; dat werkt dus nog niet.”

• Je blijft op de hoogte van de beslissingen die je team genomen heeft. “Ah, ik dacht dat de gebruiker op de print knop van de browser zou moeten drukken. Het blijkt een andere print knop te zijn. Ook goed voor mij.”

Kortom, de communicatie tussen jou en je softwareteam gaat met sprongen vooruit.

Hoe kom je zo’n tips te weten?

Zo zijn er honderden zaken die je kan verbeteren aan de manier waarop jij en je team software ontwikkelen. Ik ga je regelmatig tips geven op mijn blog en via mijn nieuwsbrief. Aan jou om uit te maken of een tip nuttig is in jouw specifieke geval.

Als dat te traag vooruit gaat voor jou, of je wilt éérst de tips horen die voor jou van toepassing zijn, kan je met mij samenwerken. Ik werk met vaste prijzen en duidelijke afspraken - laat ons praten.

Wat heb ik hieruit geleerd?

Ik heb geleerd hoe ik mezelf het best kan voorstellen.

Goeiedag, ik ben Tom. Ik help bedrijfsleiders winstgevende en schaalbare digitale producten te bouwen door de samenwerking tussen business en softwareontwikkeling te verbeteren.