Een veel voorkomend probleem bij projecten is Feature Creep; de neiging bij een ontwerp of product meer en meer kenmerken of details toe te voegen, i.p.v. eerst een meer fundamentelere versie op te leveren. Dit moet zeker niet verward worden met het actief inzetten van scope wijzigingen d.m.v. voortschrijdend inzicht. Want dat verhoogt juist de business value van een project.
Bij traditionele software ontwikkeling wordt eerst een uitvoerige specificatie opgesteld, vervolgens de implementatie gemaakt, en wanneer het produkt dan nagenoeg klaar is krijgen de beoogde gebruikers het te zien. Een veelvoorkomende reactie is dan “Nou ik dit zie, kan dan ook…” of “Zou het niet mooi zijn als…”. Dit wordt ook wel het ‘Yes But’-syndroom genoemd, wat overigens een volstrekt normale manier van reageren is. Echter vormt dit een groot project risico.
Enerzijds door op een meer Agile manier te werk te gaan, en anderzijds door Requirements Analyse hand in hand te laten verlopen met Interaction Design, kan dit risico beperkt worden.
De Agile manier van werken heeft als kenmerken dat er kort-cyclisch gewerkt wordt, en dat detail specificaties Just In Time opgeleverd worden. Voordelen hiervan is dat er na iedere korte cyclus (ook wel iteratie genoemd) feedback verkregen kan worden van gebruikers. Dit verlegt het “Yes But” risico naar slechts het werk van een iteratie. Daarnaast zijn detail specificaties nog niet vastgelegd, aangezien de kans zeer groot is dat voortschrijdend inzicht invloed gaat hebben op het vervolg van het project.
Door de specificaties hierop aan te passen, door bijvoorbeeld met User Stories o.i.d. te werken, in combinatie met interaction designs, wordt beter aangesloten bij de toekomstige gebruikers. Op deze manier is de “Yes But” reactie al deels bij de gebruiker te ontlokken ten tijde van het specificeren. Het grote voordeel van deze manier van werken is dat het laagdrempelig en visueel is, en daarmee door gebruikers te begrijpen hoe het er straks uit gaat zien en hoe het gaat werken.
Uiteraard is er bij de start van een project een beoogde scope, en op basis daarvan wordt een project gestart. Echter kan na een of twee iteraties al duidelijk worden dat de weg die ingeslagen is o.b.v. de initiële scope, niet gaat leiden tot het meest gewenste resultaat (en dus ook niet de hoogste business value). De specificatie sessies en de eerste iteraties hebben dusdanig inzicht gegeven dat in goed overleg de scope aangepast dient te worden. En dat is iets heel anders dan Feature Creep.
Een belangrijk aspect uit de strijd tegen Feature Creep bestaat dus uit anticiperen op wijzigingen. En aangezien het “Yes But” gedrag volstrekt normaal en zelfs verwacht kan worden, kun je maar beter open staan voor dit gedrag door de aanpak er zo veel mogelijk op in te richten, en daarmee de business value vergroten.
Reageer op dit bericht