Print:

De succesles van Tesla en (Het Nieuwe) Microsoft

Jasper Bakker, Freelance ICT & internet-journalist

LinkedIn profiel

Lean development ontgroeit de beginfase van nieuwe, interessante ontwikkeling. Het flexibel en gebruikersgericht ontwikkelen van en met ICT wordt standaard en noodzaak. Waarom? Om te overleven.

Er was eens een land waarin vooraf werd bedacht en vervolgens bepaald wat er de komende tijd geproduceerd moest worden. Het haast heilig geachte meesterplan bepaalde dan wat er aan goederen gemaakt ging worden. De achterliggende filosofie was dat dit een planeconomie zou realiseren waarin alles goed geregeld was.

Aanbod- en vraagzijde

Helaas hield dit communistische gedachtengoed geen (of te weinig) rekening met externe factoren. Een mislukte oogst kan voedselverbouwing fors drukken. Ontbrekende grondstoffen kunnen fabricage frustreren. Uitvallende componenten kunnen productie platleggen. De lijst met plan-verstorende realiteiten is lang en divers.

En vergeet naast deze factoren aan de aanbodzijde niet de reeks onvoorziene zaken aan de vraagzijde. Een onverwacht koude winter zorgt voor onvoorziene grotere behoefte aan bepaalde producten. Het aanbod valt niet goed te plannen en ook de vraag valt niet goed in te schatten.

Sovjet-stijl development

Vanaf het Sovjet-ideaal van vijfjarenplannen valt een vergelijking te trekken met traditionele methoden voor ICT-ontwikkeling. Vroeger werd een stuk software eerst ‘op papier’ ontworpen qua gewenste functionaliteit. Daarna werden eventueel nog de benodigde software-elementen in kaart gebracht en werd de vereiste ontwikkelinspanning ingepland.

Na lang ontwikkelen werd dan uiteindelijk een product opgeleverd. Of niet. Zie als recent voorbeeld het omstreden project Basisregistratie Personen (BRP) van de Nederlandse overheid. De ontwikkeling van het BRP is qua tijd en kosten enorm uitgelopen en nu uiteindelijk door demissionair minister Ronald Plasterk stopgezet.

Waterval-methode

Nu kent de ICT-industrie al sinds de jaren zeventig het idee van de waterval-methode. Dit is een aanpak van ICT-ontwikkeling waarbij een project is opgedeeld in opeenvolgende stukken die als treden in een waterval doorstromen naar het eindpunt. De achterliggende gedachte is dat softwarebedrijven (en hun klanten) hiermee meer duidelijkheid krijgen in de voortgang van softwareprojecten.

De waterval-methode is afgeleid van de traditionele manier van werken voor grote projecten in de bouw. Daarbij is er sprake van een basisontwerp, gevolgd door een technisch ontwerp, gevolgd door de daadwerkelijke bouw, met letterlijk eerst een fundament, enzovoorts. Bij software is het niet altijd zo netjes opeenvolgend. Zeker niet doordat er bij bijvoorbeeld testen – maar ook bij ingebruikname – onvolkomenheden aan het licht kunnen komen. Terug naar de tekentafel dan maar, om een uitdrukking uit de bouw toe te passen.

Extra complicatie is dat er gaandeweg de software-ontwikkeling al veranderingen optreden. Het voorbeeld van onvolkomenheden in softwarecode is eigenlijk één van de factoren aan de aanbodzijde. Net zoals bij de Sovjet-aanpak moet de veeleisende vraagzijde niet vergeten worden. Want die vraag kan snel veranderen.

Megaprojecten versus MVP

Sovjet-planners bleken niet van tevoren te kunnen voorzien in alle facetten en behoeften van de economie. En developers kunnen niet van tevoren perfect voorspellen wat individuele gebruikers en de algemene markt over X tijd precies nodig blijken te hebben. Developers dreigen dan – een enkele toevalstreffer daargelaten – altijd achter de realiteit aan te rennen.

Natuurlijk, een inschatting valt vooraf wel te maken, maar na verloop van ontwikkeltijd kan iets heel anders nodig zijn. Bijvoorbeeld doordat de beoogde klanten iets anders willen. Of doordat ze een product heel anders inzetten. Of doordat een concurrent eerder op de markt is gekomen. En de benodigde bijsteltijd zorgt weer voor achterstand en mogelijke nieuwe mismatch. Kortom, de oude aanpak is niet meer van deze tijd.

Snelheid, feedback en flexibiliteit zijn de toverwoorden, die in een magische cirkel moeten samenwerken. Eerst komt snelle ontwikkeling van een basaal maar bruikbaar product. Dit heeft in start-up terminologie de naam ‘minimum viable product’ (MVP). Kort uitgelegd: niet gelijk een complete, luxe auto met grote actieradius ontwerpen en bouwen als je klanten wil winnen met een nieuwe, elektrische vervoersoptie. Een eenvoudigere auto met kleiner bereik, voor een niche-publiek, kan een beter begin zijn. Het is in ieder geval een begin dat sneller gemaakt is.

Als een start-up

Dan volgen de toverwoorden feedback en flexibiliteit. Luister en kijk naar je klanten, en potentiële klanten. Bevraag ze, observeer ze, meet ze. Wat willen ze, en wat dóen ze? Het eerste kan opvallend veel verschillen van het tweede. Word data-driven en leer ook van de fouten die je maakt.

Koppel de zo opgedane kennis terug naar de snelle ontwikkeling. Want tijdens de eerste uitlevering loopt al de doorontwikkeling en dan volgt de verfijning. In start-up terminologie: itereren. Zo kom je uiteindelijk tot een breder gedragen massaproduct, zoals de Tesla Model 3. Lean development is de overkoepelende term waarmee dit alles valt te realiseren.

Nu is het geval van Tesla een bekend, haast uitgekauwd voorbeeld. Maar laat even bezinken dat het vóór deze maker van elektrische auto’s 111 jaar geleden was dat er in de Amerikaanse auto-industrie een succesvolle start-up opstond. Dat was Ford.

Het lijkt voor veel mensen en organisaties wellicht een ver-van-mijn-bed-show om hun eigen omstandigheden te vergelijken met de automarkt en de start-up sector. Niet alleen zijn die twee laatstgenoemde totaal verschillende werelden, ook is er sprake van onderscheid met andere markten en industrieën. Toch is lean development toepasbaar en waardevol voor een breed bereik. Ook voor organisaties die innovatieve nieuwkomer met flinke financiering zijn. Ook voor organisaties die geen kleine, legacy-loze start-up zijn.

Ongeacht je startpositie

Kijk maar naar het voorbeeld van één van ‘s werelds grootste softwaremakers: Microsoft. Die firma is al vaak vergeleken met een olietanker. Van koers veranderen gebeurt laat en langzaam, soms te langzaam. Maar Microsoft heeft in de afgelopen jaren een fundamentele verandering doorgevoerd. Het is voor achtereenvolgende producten overgeschakeld op agile methodieken en lean development om zo op continue basis te kunnen innoveren. Als een lean start-up dus.

Windows 10 valt in de eerste release als MVP te beschouwen. Sindsdien is het besturingssysteem op regelmatige basis flink bijgewerkt en verfijnd. Daarna heeft Microsoft deze lenige aanpak toegepast op diverse andere producten die het aanbiedt. Recent is aangekondigd dat zelfs het traditionele product van Windows Server aan bod komt. Jawel, de stabiele wereld van servers krijgt op afzienbare tijd ook te maken met lean development.

Elon Musk kan het met Tesla. Creatieve durvers kunnen het met start-ups. Satya Nadella kan het met Microsoft. Developers en growth hackers kunnen het met vele andere bedrijven en organisaties. Wie wordt als volgende lean? Wie overleeft?!

LPD IIR

Wil je weten hoe je een snelle, gestructureerde en doelgerichte manier van productontwikkeling kunt toepassen. Bekijk de training Lean Product Development 2.0

Wij gebruiken cookies om IIR.nl gemakkelijk te maken. Bezoekt u onze website, dan gaat u akkoord met deze cookies meer informatie

De cookie-instellingen op deze website zijn ingesteld op 'toestaan cookies "om u de beste surfervaring mogelijk. Als u doorgaat met deze website te gebruiken zonder het wijzigen van uw cookie-instellingen of u klikt op "Accepteren" hieronder dan bent u akkoord met deze instellingen.

Sluiten