Hoe overbrug je de afstand tussen ontwikkelaars en de business? Misschien moet je het eens tekenen.
Er zijn momenten in bepaalde projecten dat je als ontwikkelaars de tranen in de ogen springen van pure frustratie. “Wat wil je nou eigenlijk!?” Dat komt doordat de business-kant niet in staat is onder woorden te brengen hoe toepassingen zouden moeten werken – en dat blijft nog steeds het grootste obstakel voor binnenshuis geproduceerde applicaties.
Dat is ook niet zo gek. Niets is zo vervelend als een requirements-document opstellen voor het ouderwetse watervalmodel, waarin ieder hoekje en gaatje en elke afslag en splitsing en alle uitzonderingen van een applicatie in stomvervelend taalgebruik tot in het laatste detail moeten worden afgetikt. De meeste organisaties gebruiken nu godzijdank agile ontwikkelingsmethoden waarbij er meerdere stadia zijn met prototypes en feedback vanuit de business, en toch lukt het die gasten van de business maar niet om wat ze willen hebben zo uit te leggen dat de ontwikkelaars er wat mee kunnen, waardoor er toch elke keer weer veel te veel tijd wordt verspild.
Een mogelijke nieuwe oplossing voor dit probleem komt uit de hoge hoed van een startup,
iRise is speciaal ontworpen voor niet-technische gebruikers. Het kan vooraf worden voorzien van regels en een voorraad grafische elementen, waarmee voorkomen wordt dat onze zakelijke vrienden hun apps tot in de stratosfeer doorvisualiseren. Binnen die begrenzingen kunnen de betrokkenen die een app willen hebben alle elementen simpelweg in real time plaatsen waar ze ze hebben willen; desnoods in een vergadering via een beamer, waarbij dan direct beslissingen worden genomen. Het model van de applicatie en de bijbehorende opmerkingen vormen dan samen een soort requirements doc in de vorm van een fotoroman.
Ik weet wel wat je denkt: onder de motorkap wordt vast allerlei rare code gegenereerd, toch? Helemaal niet. iRise is een communicatie en documentatie gereedschap. Aan de ene kant lijkt het zonde dat al dat werk aan applicatie design nu slechts resulteert in een schaalmodel en requirements. Aan de andere kant zou dit volgens mij wel eens de beste benadering voor ‘echte’ applicaties kunnen zijn: business analisten kunnen lekker aanmodderen met mashups of simpele web-apps, maar als het project echte ontwikkeling vereist, is het best verstandig het programmeren gewoon aan de programmeurs over te laten.
De CMO van iRise, Mitch Bishop, erkent dat ontwikkelaars in eerste instantie enigszins wantrouwig naar zijn product kijken: “Ze vragen ons voortdurend wat nou precies het voordeel is voor de ontwikkelaars? Om eerlijk te zijn: ontwikkelaars hebben meestal weinig vertrouwen in visualisatie als we ermee aankomen bij een organisatie.” Maar uiteindelijk zijn ze er heel tevreden over, zegt hij, om twee redenen: een werkend model stelt niet alleen de business in staat hun wensen beter tot uitdrukking te brengen, maar het zorgt er ook voor dat iedereen duidelijk voor ogen heeft wat de functionaliteit moet zijn, wat resulteert in minder wijzigingen gedurende het ontwikkeltraject.
Bishop is nogal optimistisch over visualisatie als een enorme nieuwe trend. Ik ben daar wat sceptischer over. Maar ik denk wel dat iedere tool die helpt om de enorme kloof van onbegrip tussen ontwikkelaars en de business te overbruggen bijzonder welkom is.