Need for speed

28 juni 2010

Ik werk inmiddels ruim drie jaar in Silicon Valley, maar nog steeds verbaas ik me regelmatig over de manier waarop bedrijven hier producten en services ontwikkelen. De focus op snelheid, ofwel het minimaliseren van de tijd tussen idee en product of service in de hand van de gebruiker, is enorm. De reden is dat korte ontwikkelcycli met gebruikers die continu feedback geven een competitief voordeel bieden. Daardoor kun je sneller dan je concurrentie uitkomen op de juiste producten en diensten en zo de markt beter bedienen.

Verschillende bedrijven hier hebben ontwikkelbenaderingen gevonden die veel kortere cycli opleveren dan de typisch jaarlijkse cycli waar ik tot nu toe ervaring mee had. Ebay komt bijvoorbeeld elke twee weken naar buiten met code en andere Web 2.0-spelers hebben soortgelijke of vierweekse releasecycli. Sommige starters gaan nog verder en hebben het concept van continue ontwikkeling geadopteerd: alle code die een ontwikkelaar incheckt in het configuratiemanagementsysteem wordt meteen gecompileerd, gelinkt, getest en vrijgegeven. IMVU releaset zijn software gemiddeld vijftig keer per dag en Twitter bouwt en releaset software ieder half uur.

De attitude van deze bedrijven jegens kwaliteitsgarantie is verre van traditioneel. Het principe is dat als een fout de klant weet te bereiken, niet de ontwikkelaar verantwoordelijk is maar de geautomatiseerde testomgeving. Bovendien is handmatig testen taboe. Dit leidt tot een situatie waarin voldoende wordt geïnvesteerd in de test- en deploymentinfrastructuur en de testcases daadwerkelijk worden onderhouden.

Een vraag die Europese bezoekers vaak stellen, is waarom dit zo belangrijk is, met name omdat de kosten voor korte of continue ontwikkelcycli zo hoog lijken. De voornaamste reden is dat deze benadering het toestaat om bijna continue feedback van gebruikers te krijgen. Deze kan via surveys en interviews worden verzameld, maar voor webgebaseerde applicaties wordt met name de zogeheten A/B-testmethode veel toegepast. Hiermee kan voor initieel kleine veranderingen onmiddellijk feedback van gebruikers worden vergaard.

Dit brengt me op een tweede trend in Silicon Valley. Waar traditioneel opinies en organisatiehiërarchieën de besluitvorming rond requirements en ontwerpbeslissingen bepaalden, hebben veel bedrijven hier geleerd dat dit suboptimaal is. Het superieure alternatief is data, heel veel data. Door continue interactie met gebruikers, A/B-tests en andere technieken kan de ontwerpruimte voor een systeem systematisch worden onderzocht en kunnen beslissingen worden genomen op basis van data in plaats van dat de opinie van de CTO of het hoofd ontwikkeling leidend is. Google is een bedrijf dat extreem veel gebruikmaakt van data en bijna iedere interactie tussen een gebruiker en een Google-pagina is door en door getest.

Het standaard argument om deze benadering niet toe te passen is dat het niet werkt voor bijvoorbeeld gecertificeerde embedded systemen, legacyproducten of enterprise-IT-systemen. Ik geloof dat dit excuses zijn en dat ook de Nederlandse industrie zich heel actief moet gaan richten op het adopteren van dit soort technieken, ongeacht het domein en het soort systeem. Binnen Intuit hebben we de productontwikkeling van een twintig jaar oud desktopproduct met miljoenen regels code veranderd en de beschreven benadering toegepast binnen de grenzen van wat mogelijk is, en dit heeft ons enorme voordelen opgeleverd. Ook in uw industrie begint de need for speed steeds belangrijker te worden bij het behalen van concurrentievoordeel.

Jan Bosch

Terug naar overzicht