Het is een veelvoorkomend probleem bij IT-projecten: de kloof tussen klanten en ontwikkelaars. In deze blog vertelt Jan-Jaap Zijlstra, Lead System Architect bij BPM Company, over de beste oplossing om deze kloof te verkleinen.

De business analist en het jargon probleem

De kloof tussen klanten en ontwikkelaars is bij de meeste IT-projecten te groot. Klanten begrijpen te weinig wat ontwikkelaars proberen te bouwen en ontwikkelaars begrijpen te weinig wat hun klanten verwachten. De gevolgen hiervan laten zich raden: onnodige vertragingen en in het ergste geval zelfs mislukte projecten.

Voor het verkleinen van deze kloof worden vaak business analisten ingezet. Aan hen de taak om klantwensen te vertalen in requirements en stories die voor ontwikkelaars begrijpelijk zijn. In theorie klinkt dit heel mooi, maar in de praktijk blijkt dit erg lastig te zijn. Business analisten moeten namelijk vier totaal verschillende jargons beheersen:

  • Klant jargon: de taal waarin de klant zich uitdrukt en hun wensen beschrijft.
  • Platform jargon: de taal van het platform vendor waarin de mogelijkheden van het platform beschreven wordt.
  • Ontwikkelaar jargon: de taal waarin de ontwikkelaars zich uitdrukken.
  • Applicatie jargon: de taal waarmee beschreven wordt hoe de applicatie werkt.

Het correct en duidelijk vertalen van klantwensen in deze vier totaal verschillende jargons is erg lastig, als het al mogelijk is, en kost veel tijd.

De rol van de documentatie cyclus

Een andere reden waarom het voor business analisten zo moeilijk is om deze kloof beheersbaar te houden is de documentatie cyclus. Organisaties organiseren IT-projecten tegenwoordig meestal in iteraties van 2 weken (Sprints). De klant, business analist en ontwikkelaar implementeren bij elke Sprint nieuwe functionaliteiten en werken de documentatie bij. Onderstaande diagram toont een veelvoorkomende documentatie cyclus:

Omschrijving van stappen in een standaard documentatie cyclus

Alle betrokkenen moeten bij elke stap in deze documentatie cyclus de opgeleverde documentatie vertalen, zodat deze in de volgende stap kan worden verwerkt. Van Word naar Confluence naar Stories naar Implementaties en dan weer terug naar Confluence. Als bij deze stappen te veel informatie verloren gaat, dan zal per iteratie de kloven tussen klanten, business analisten en ontwikkelaars toenemen.

Ik zie dit probleem ook terug in mijn eigen werk. Ik werk nu aan een groot Pega project waarbij een ingewikkeld financieel systeem aangepast moet worden vanwege gewijzigde wetgeving. Hier zie ik het probleem van de verschillende jargons ook:

  • De business analist moet honderden codes en begrippen kennen
  • De business analist moet het platform jargon van Pega goed kennen
  • De business analist moet de (Engelstalige) jargon van ontwikkelaars begrijpen om goed met hen te kunnen samenwerken
  • De business analist moet weten hoe alles terug te vinden is in de portalen van het financiële systeem

En zo zet de documentatie cyclus zich voort en nemen de verschillen toe, met als gevolg onnodig veel tijdverlies. Een makkelijke oplossing is er niet. Meer vergaderingen organiseren, betere werkwijzen afspreken of intensievere samenwerking kunnen de kloof wel verkleinen, maar zal de kloof niet dichten. Het probleem van veel verschillende jargons en de documentatie cyclus is dus erg fundamenteel.

De oplossing: low code platformen

De beste oplossing om de kloof te dichten zijn low code platformen. Low code platforms zijn ontwikkelplatformen waarin ontwikkelaars, samen met klanten en business analisten, op een eenvoudige en visuele manier applicaties kunnen bouwen. Het grote voordeel van low code platformen, zoals Pegasystem, is dat de documentatie cyclus is opgenomen in het platform zelf. De klant, de business analist en de ontwikkelaar analyseren, documenteren en bouwen hierdoor gezamenlijk binnen dit platform. Daarnaast zijn low code platformen niet (te) ingewikkeld voor klanten en business analisten, waardoor ze zich goed kunnen uitdrukken in het platform. De keuze om een low code platformen te gebruiken lost dus de twee grootste problemen op: iedereen wordt afgedwongen hetzelfde jargon te gebruiken en de documentatie cyclus blijft beheersbaarder. De kloof tussen klanten, business analisten en ontwikkelaars zal dan ook grotendeels verdwijnen.

Om al deze redenen probeer ik Pegasystems bij mijn projecten steeds meer in te zetten als een low code platform. Pegasystems biedt twee verschillende platformen die beiden tegelijkertijd kunnen worden gebruikt:

  • Dev Studio: de technische variant, in eerste plaats bedoeld voor ontwikkelaars.
  • App Studio: de low code variant, bedoeld voor klanten en business analisten, maar ook voor ontwikkelaars.

Zelf stimuleer ik het gebruik van App Studio meer dan het gebruik van Dev Studio. Hierdoor spreekt iedereen dezelfde jargon en blijft de documentatie cyclus beheersbaar. Op deze manier probeer ik dus als Lead System Architect de kloof tussen klanten, business analisten en ontwikkelaars te verkleinen.

De uitdagingen van Pegasystems

Het gebruik van low code platformen, zoals Pegasystems, betekent niet dat klanten, business analisten en ontwikkelaars niet alert moeten zijn. Het gebruik van Dev Studio en App Studio neemt namelijk ook uitdagingen met zich mee. Zo is niet alles wat ontwikkelaars in Dev Studio bouwen goed te zien in App Studio. Grote hoeveelheden code zullen hierdoor snel onzichtbaar zijn in App Studio als ontwikkelaars hier geen rekening mee houden. De kans bestaat dat de kloof tussen klanten, business analisten en ontwikkelaars dan weer toeneemt. Ontwikkelaars kunnen dit probleem voorkomen door zoveel mogelijk uit te gaan van App Studio voor ontwikkeling en alleen te switchen naar Dev Studio als het echt niet anders kan.

Een andere uitdaging is het maken van duidelijke afspraken m.b.t. de documentatie. Klanten, business analisten en ontwikkelaars moeten afspreken dat de documentatie in App Studio wordt opgevat als de officiële referentie documentatie. De verleiding zal anders te groot zijn om de documentatie in App Studio niet bij te werken. Hierdoor zal het probleem van de verschillende jargons en de documentatie cyclus weer groter gaat worden.

De kloof verkleinen met low code platformen

Verschillende jargons en een ingewikkelde documentatie cyclus vormen dus de basis voor de kloof tussen klanten, business analisten en ontwikkelaars. Toch kunnen onnodige vertragingen en mislukte projecten als het gevolg hiervan verleden tijd zijn. Low code platformen bieden klanten, business analisten en ontwikkelaars de kans om de kloof te verkleinen. Door het gebruik van een low code platform verdwijnen de verschillende jargons en wordt de documentatie cyclus beheersbaar. En de kloof tussen klanten, business analisten en ontwikkelaars die eerder zo groot was, is dan ineens een stuk kleiner.

De afgelopen jaren heeft Jan-Jaap als ervaren Lead System Architect aan diverse IT-projecten gewerkt. Benieuwd naar zijn ervaring bij BPM Company en met Pegasystems door de jaren heen? Lees dan hier het interview met Jan-Jaap ten ere van zijn 10-jarig werkjubileum bij BPM Company.

Benieuwd naar werken bij BPM Company?

Bekijk dan eens de vacatures of neem contact op met Hans Steenwijk: