Een software product bouwen is zoals navigeren op zee
Goeiedag, ik ben Tom.
Onlangs heb ik mijn vaarbewijs gehaald. Niet omdat ik grote tochten met een boot wil gaan ondernemen, maar het leek me wel leuk om op vakantie eens een dagje de zee op te kunnen gaan.
Eén van de skills die je moet hebben om dat vaarbewijs te halen, is navigatie op open water. Je moet in staat zijn om een doel te bepalen, en een koers uit te zetten die naar dat doel leidt. Dat doel kan vast zijn, zoals een haven, maar kan ook bewegen, zoals een andere boot. Je leert dat je met ontiegelijk veel dingen rekening moet houden, waar ik vroeger nooit aan gedacht had: de wind heeft veel meer invloed op je boot dan op je auto, bijvoorbeeld. De stroming heeft een invloed die je op het zicht niet merkt. Het gebied waar je je bevindt moet je mee in rekening nemen - je wil niet op een zandbank stranden. Ook het weer speelt een rol - als er een storm op komst is, blijf je liever even in de haven wachten, bij goed weer ga je vol gas vooruit.
Het uitzetten van een koers doe je door een aantal tussenpunten te markeren, en te berekenen hoe je daar naartoe gaat. Wanneer je dat voor de eerste keer doet, heb je de illusie dat je dat doet zoals je een autorit plant, maar dan zonder wegen. Je gaat van punt A naar punt B, naar punt C, enzoverder, tot uiteindelijk de haven of de boot die je wil bereiken. Wanneer je dan begint te varen, merk je al gauw dat het allemaal zo simpel niet is. Om te beginnen heb je op zee veel minder herkenningspunten die je aangeven of je nog op de juiste weg zit, en waar op die weg je ergens bent. Je kan wel bepalen waar je bent met bijvoorbeeld een peiling, maar dat neemt toch wel wat tijd in beslag. Daarom ga je zo'n peiling dikwijls maar uitvoeren wanneer je denkt dat je in de buurt bent van een tussendoel, of in de buurt van een mogelijk gevaar (zoals die zandbank).
In 95% van de gevallen stel je op zo'n moment vast dat je niet bent waar je dacht dat je was. In 100% van de gevallen vind je dat niet erg; je wil immers niet naar dat tussendoel, maar je wil naar die boot die je wil gaan helpen. Je bekijkt dan welke tussendoelen nog relevant zijn, welke je gaat negeren, en of er nieuwe tussendoelen moeten gekozen worden. Daarbij probeer je natuurlijk ook te weten te komen waar die andere boot intussen is, en eventueel of er nog anderen zijn die al bij die boot zijn.
"Ja Tom, allemaal tof," hoor ik je denken, "maar dit is een professioneel netwerk en jij bent een software bouwer en geen zeiler. Wat doet dit verhaaltje hier?" Wel: gisteren probeerde ik aan een (niet-software) collega uit te leggen wat een product backlog is, en hoe je daarmee omgaat. Een product backlog is, kort door de bocht, een lijst van features die je nog wil bouwen voor je software product. Die features gaan je helpen om je klant te bedienen (en ervoor te zorgen dat die klant je betaalt). En toen viel me op hoe dit proces gelijkt op het navigeren op zee.
De features op je backlog an sich zouden je niet mogen interesseren; hoe je bij die klant geraakt is wat je interesseert. Wanneer je denkt dat je een feature bereikt hebt, ga je vaststellen dat dat niet 100% de feature is die je in je hoofd had toen je vertrok uit de haven; maar eigenlijk vind je dat niet erg. Wat wel kan, is dat je intussen geleerd hebt dat andere features je niet gaan helpen om bij de klant te geraken; die ga je dus weghalen. Er kunnen andere, nieuwe features bijgekomen zijn; die ga je toevoegen.
De andere boot, dat is je klant. De zandbanken, dat zijn de onzichtbare (maar relatief statische gevaren): zonder cash komen te zitten, te veel technical debt opbouwen, enzovoort. Het weer, dat zijn de minder statische (en soms ook minder voorspelbare) gevaren: een beurscrash, een verandering van regelgeving, ... De andere boten in de buurt zijn natuurlijk je concurrenten.
Wat denk je? Klopt de analogie wat? En vanaf wanneer loopt ze mank?
Photo by Griffin Wooldridge on Unsplash