Innovatie & Strategie

Software-ontwikkeling
Dappermarkt

Design thinking: maatwerk is helemaal terug

Ontwikkeling van goede software moet 'kneiter human-centered' zijn

Dappermarkt, Amsterdam © CC BY-SA 2.0- Flickr
1 maart 2018

Ontwikkeling van goede software moet 'kneiter human-centered' zijn

Ontwikkelmethoden als agile development en lean startup onderschrijven het belang van de rol van de eindgebruiker, door deze vroeg en vaak te betrekken bij het ontwikkelen van software. Design thinking gaat daarin nog verder: de beoogde gebruikers worden niet alleen betrokken om gemaakte software te testen, maar ook om te bedenken wat voor software nodig is. Of zelfs om te beslissen óf er software nodig is.

One size fits none. Overheden moeten weer meer zelf gaan ontwikkelen. Ze hebben gekke processen,” stelt Maarten Geraets. Hij zette drie jaar geleden op verzoek van de gemeente Amsterdam het Datalab op. Zijn opdracht was om met een innovatief team datagedreven toepassingen te zoeken voor een aantal zeurende problemen in de stad. Geraets ontwikkelde daarvoor samen met zijn zakenpartner Johan Groenen de FIXXX-methode, ofwel Fast Innovation Amsterdam. Inmiddels zijn al verschillende projecten met succes afgerond.

De aanpak heeft veel weg van bekende agile development- en lean startup-projecten. In kortcyclische iteraties wordt binnen enkele weken een werkend programma opgeleverd dat in een concrete behoefte voorziet. Het verschil tussen FIXXX en de voornoemde methoden zit hem in de rol van de eindgebruiker. Geraets: “Het moet kneiter human-centered zijn.”

Daarmee zet hij zich krachtig af tegen de trend bij vooral grote organisaties om zoveel mogelijk over te gaan op standaardsoftware. In elk standaardprogramma zit een proces ingebakken. Eigenlijk sluit dat nooit aan bij de processen van de organisatie. Het idee is dat de organisatie de processen aanpast aan de standaardsoftware. Maar dat gaat altijd wringen. Voor Geraets staan dan ook de werkprocessen centraal. “Je kunt niet aan tafel bedenken wat werkt. Dus ‘get out of the building’.”

Design Thinking

Design thinking is een trend afkomstig uit de praktijk van de industriële vormgeving. IDEO, een in 1991 opgericht bedrijfje, heeft onder leiding van CEO Tim Brown de werkwijze steeds breder in verschillende industrietakken geïntroduceerd. De methode kent vijf fasen:

  • Empathise – het inleven in de problematiek van de gebruiker
  • Define – het scherpstellen van het probleem
  • Ideate – een ronde met eerst een zoektocht naar mogelijke oplossingen (divergent) en vervolgens wordt samen de beste uitgekozen (convergent)
  • Prototype – een eerste werkend exemplaar
  • Test – terugkoppeling op het prototype en verfijning.

Tim Brown hanteert de volgende definitie: “Design thinking kan worden omschreven als een discipline die

  • gebruikmaakt van het gevoel en de methoden van de ontwerper om de behoeften van mensen te koppelen aan wat technisch mogelijk is, en die
  • een levensvatbare bedrijfsstrategie omzet in klantwaarde en marktkansen.”

Een bekend voorbeeld is een experiment met kinderen en een MRI-scanner. Kleine kinderen zijn vaak bang voor een MRI-scanner. De vraag is waarom? Uit het empathise-onderdeel van het design thinking-experiment bleek dat de kinderen vooral bang waren omdat ze het apparaat niet kenden. Dus werd gezocht naar een manier waarop de MRI-scanner beter kon aansluiten bij hun belevingswereld. De hele ruimte met de MRI-scanner werd omgevormd tot een adventure game waarbij het plateau waarop de kinderen moeten liggen werd aangekleed als een kano. De belofte aan de kinderen is dat wanneer ze heel stil blijven liggen in de kano, er vissen over de boot zouden springen. Zo werd het maken van een scan een intrigerende belevenis.

Bekijk Doug Dietz, principle designer van GE in zijn TEDx San Jose CA-voordracht. daarin schetst hij met een aantal voorbeelden hoe hij overtuigd raakte van het gebruik van design thinking:

Meer weten?

Een crash course in Design Thinking van Stanford University

En dat is wat hem betreft ook menens. Dat betekende in het eerste project: programmeren op een marktkraam tussen de schreeuwende marktkooplieden. Er moest een oplossing komen voor een probleem bij de markttoezichthouders die de marktkramen toedelen aan kooplieden. De gemeente vond het niet van deze tijd dat de marktkooplieden elke ochtend bij elkaar moesten komen om te horen of zij een kraam konden krijgen. De reden is dat de indeling op papier plaatsvindt. De vraag aan het Datalab was dus of daar niet een ander systeem voor in de plaats kon komen.

De markt op

Het team van Geraets ging dagenlang met de toezichthouders de markt op om het werkproces te observeren en met de ambtenaren samen naar oplossingen te zoeken. Ze ontdekten dat de aannames van de gemeente over het probleem niet klopten.

Geraets: “Kooplieden zijn er de hele week mee bezig. De indeling is belangrijk voor ze, ook omdat niet elke plek op de markt hetzelfde is. Een plek op de hoek levert meer zichtbaarheid. Een boom achter de kraam is beroerd, want dan kun je de bestelbus met voorraad niet goed kwijt. Bovendien leeft het bijgeloof sterk onder de ondernemers op de markt. Daarom praten en bellen ze voortdurend met elkaar. Ze weten precies: als die komt, hoef ik niet te gaan, want dan maak ik geen kans. Er was nooit iemand die ‘s ochtends vloekend terug naar huis moest.” De conclusie was dus dat het indelen niet het probleem was, en echt het best op papier kon. De markttoezichthouders zijn daar zo efficiënt mee, dat wanneer je daar software voor zou inzetten, het alleen maar vertraging zou introduceren. Dat was al eerder geprobeerd, en op een drama uitgelopen.

Verkeerde aanname

Het échte probleem bleek een slecht werkend administratiesysteem. Dat was het gevolg van een maatregel van de gemeente een aantal jaar geleden, waarbij het toezicht op de markten in de verschillende stadsdelen werd samengevoegd. “We kwamen allemaal gekke situaties tegen. In stadsdeel Zuid maakte we mee dat je de administratie alleen kon inzien op een oude Windows 95-bak. De enige manier die men had om informatie daaruit te krijgen, was door het over te schrijven. In stadsdeel Centrum was er een scansysteem zonder database. De administratie werd daar al jaren niet meer opgeslagen. Alle scanners bliepten netjes bij elke scan, dus niemand die het doorhad. Voor ons was het snel duidelijk wat we moesten doen. We konden een app maken die het scannen en afrekenen mogelijk maakt, en die aan een backend koppelen voor de centrale administratie. Dat hebben we dus met vier man aan een kraampje zitten programmeren.”

In korte tijd was er een werkend prototype voor het maken van een ‘scan’. “De eerste versie was echt alleen een invoerveld.” Daarna zijn incrementeel functies toegevoegd en praktische problemen opgelost terwijl de toezichthouders over de schouders van de programmeurs meekeken. “Hoe het kan weet ik niet, maar de markttoezichthouders hebben heel grote handen. Dus vormen standaardknoppen een probleem. De volgende dag hadden we al een nieuwe versie met grotere knoppen. We vroegen voortdurend feedback of ons werk voldeed aan hun verwachtingen.”

Product owner moet zelf verder kunnen

Nadat de app kon scannen, registreren hoeveel meter de kraam besloeg, berekenen hoeveel reclamegeld er moest worden geïnd en met de app kon worden afgerekend en deze een bon kon produceren, was het project af. Ondertussen werd de product owner meegenomen in de ontwikkeling zodat deze autonoom verder kon om meer functionaliteit toe te voegen, zoals de koppeling met een backendapplicatie. “De doorontwikkeling kan bij het Datalab, maar ook bij een andere softwarebouwer. De software die wij maken is altijd open source.”

De nieuwe visie op het belang van maatwerk betekent dat de gemeente weer mensen moet gaan aannemen die dat kunnen. “Er moet samenhang zijn via het gebruik van standaarden, maar die moeten niet rigide zijn”, concludeert Geraets. Hij pleit ervoor dat de overheden microservices gaan ontwikkelen op basis van application programming interfaces (api’s). Die kunnen dan verschillende applicaties voeden met actuele informatie. “Zo ontwikkelen nieuwe diensten zich net zoals het internet zich ontwikkelde. Dat is ook een bolwerk op basis van standaarden.”

.

Decompositie van het probleem

De ideeën rond design thinking leven al langer dan de term werd geclaimd begin jaren 90. Abraham de Kruijf, adviseur van IDA Innovatie, oud-projectleider bij IBM en interim-hoofd van rekencentra van onder meer bank Pierson, ontwikkelde al begin jaren 80 een methode die door het leven gaat als de ‘per-methode’. De methode dwingt ontwikkelaars complexe problemen steeds verder uit elkaar te rafelen door steeds verder onderverdelingen te maken, bijvoorbeeld per tijdseenheid, per gebruiker, per klant, per aanvraag etc. Zo ontstaat – met voortschrijdend inzicht – al vroeg in een project een lineaire, voor de cliënt/klant herkenbare en lean procesordening die makkelijk schaalbaar en te programmeren is.

Ook De Kruijf begint bij zijn aanpak bij de eindgebruiker en de processen waar deze zich in begeeft. Je richt je op hun leefwereld, hun waarden, processen en data. Daarbij staan de volgende stappen centraal:

  • Stap 1: wat wil je, en ook je stakeholders?
  • Stap 2: hoe gaat het nu?
  • Stap 3: wat moet het worden?

Die laatste stap bestaat uit een feedbackloop van ontwerp, prototype/test, bijsturing en vooruitblik naar productie. De Kruijf: “Voorheen werd eigenlijk alleen naar het nieuwe gekeken. Nu zie je dat veel kan worden geleerd van hoe mensen nu omgaan met een proces. Design thinking is kortcyclisch ontwerpen, denken en prototypen tegelijk.”

Voor het ontrafelen van de processen blijkt Word een handig hulpmiddel. Door steeds de juiste indeling te kiezen, kunnen diepere niveaus naar believen worden open- of ingeklapt om het overzicht te bewaren of juist naar detailniveau af te dalen.

In de ontwerpfase wil hij het gebruik van flowcharts uitbannen. “De pijltjes in de charts staan voor datastromen. Die zijn niet belangrijk. Data komen uit het data lake. De bewerking, daar draait het om. De data gaan dan met een nieuw label terug in het lake.”

Lees meer over Innovatie & Strategie OP AG Intelligence
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.