Iedereen beschrijft een voorwerp dat voor hem ligt op een andere manier. Als de ene professional het liefst zijn boodschap overbrengt via Powerpoint en de ander in code, heb je vanaf de start te maken met communicatie-uitdagingen. Er wordt geen zinvolle vooruitgang geboekt totdat beide partijen het eens kunnen worden over: wat ze zien, of ze nu naar het probleem of de oplossing kijken, en dezelfde taal gebruiken om het te beschrijven.
Binnen een team is er vaak een breed spectrum van kennis en expertise aanwezig. Sommige collega’s uit de business zijn technisch onderlegd en begrijpen intuïtief het digitale landschap en hoe software werkt. Anderen zijn op dat gebied net wat minder onderlegd. Voor tech-collega’s geldt hetzelfde. De een begrijpt de markt waarin de organisatie opereert, het bedrijfsconcept en de processen zeer goed. Anderen wagen zich zelden buiten het it-domein.
Als verschillende disciplines elkaars uitdagingen niet begrijpen, ligt communicatie-falen op de loer. Slechte communicatie is een van de belangrijkste oorzaken van het mislukken van it-projecten. Verschillende onderzoeken laten zien dat het leeuwendeel van de softwarebudgetten wordt ingezet om achteraf aanpassingen door te voeren. Communicatieproblemen en onduidelijkheden zijn dikwijls de onderliggende factor voor deze wijzigingen.
Simpel gezegd: hoe beter de communicatie tussen business en it, hoe beter de oplossing. Of het nu een nieuwe manier is om producten en diensten naar de markt te brengen of om aan de veranderende behoeften van de business te voldoen.
Modeltaal
De visuele ontwikkelomgeving van een low-code-platform is speciaal ontworpen om communicatie-uitdagingen op te lossen en de samenwerking tussen teamleden een impuls te geven, ongeacht hun vakgebied of technische kennis.
Met eenvoudige beeldtaal en duidelijke iconen heeft iedereen een duidelijk beeld van het probleem dat moet worden opgelost en de tools en middelen die beschikbaar zijn om deze oplossing te ontwikkelen. Objecten en vormen, diagrammen en afbeeldingen, representaties van onderlinge afhankelijkheden en logica – de visuele taal is de lingua franca van de hele life-cycle, van het definiëren van het probleem en het verkennen van oplossingen tot het bouwen, testen en implementeren van applicaties.
Door met een gemeenschappelijke beeldtaal te werken, kunnen teamleden letterlijk bij elkaar zitten om een functie toe te voegen of een interface aan te passen. Alle partijen begrijpen de nuances en kunnen een zinvolle bijdrage leveren aan de discussie, omdat ze letterlijk voor zich zien wat er wordt ontwikkeld. Het is niet langer nodig om code te interpreteren of de argumenten genoemd op een Powerpoint-slide te vertalen naar de applicatie.
De leercurve voor het begrijpen van de visuele taal is kort. Teamleden zullen zich dus al snel geroepen voelen om een bijdrage te leveren aan het maken van de applicatie, ook als dit buiten hun primaire vaardigheden valt. Een bedrijfsanalist of productingenieur kan bijvoorbeeld zelf een idee voor een applicatie uitwerken of componenten waaruit de applicatie bestaat toevoegen, verwijderen of herschikken. Omgekeerd kan een hardcore ontwikkelaar met een frisse blik kijken naar een bedrijfsproces of programma voor betere klantinteractie en op een eenvoudige manier ideeën aandragen om de gebruikerservaring te optimaliseren en business impact te creëren. En dit kan allemaal in real-time, iedereen kan meekijken. In een open en collaboratieve omgeving gaat geen denkkracht verloren.
Persoonlijke interactie
Je ziet maar al te vaak gebeuren: in de ene hoek staat een whiteboard voor de ideeën van het business-team en in de andere hoek is het it-team aan de slag. Omdat ze niet gezamenlijk naar hetzelfde whiteboard kijken, liggen misverstanden en miscommunicatie op de loer. Het zal niet verbazen dat dit vooral het geval is bij de traditionele, lineaire watervalmethode voor ontwikkeling is. Als collega’s dezelfde taal spreken, is het gemakkelijker om samen te gaan zitten en hun ideeën op één whiteboard of scherm in kaart te brengen. Ze komen samen tot oplossingen, begrijpen elkaars non-verbale communicatie, leren elkaars zorgen kennen en worden aangestoken door elkaars enthousiasme. Maar het belangrijkste is natuurlijk dat ze elkaar nieuwe dingen leren en kennis delen. Hoe nieuwer of minder gebruikt het domein is, hoe belangrijker deze kennisoverdracht is.
Realtime, persoonlijke communicatie tussen collega’s onderling helpt iedereen in het team om maximaal betrokken te zijn en slimmer te werken. Vergaderingen zijn niet langer een moetje, een onderbreking van het werk, maar een waardevol onderdeel waar iedereen bij wil zijn.
Samenwerken op afstand
Samenwerken hoeft niet altijd fysiek plaats te vinden om effectief te zijn. Natuurlijk is het dikwijls prettig en vaak ook nuttig om letterlijk naast elkaar te zitten, maar de afgelopen periode heeft aangetoond dat er veel alternatieven zijn om samen te werken. Een hoogwaardig enterprise-grade low-code-platform heeft geïntegreerde synchronisatie en versiebeheer. Niemand werkt nog in een verouderde versie en samenwerken kan op elk tijdstip en via elk kanaal. Het maakt niet uit of een collega aan het bureau naast jou zit of zijn werkplek aan de andere kant van de wereld is. Tools voor alle beheer- en procesdetails, zoals requirements, user stories, tasks, feedback, revision tracking zijn voor iedereen gemakkelijk na te zoeken.
Bij traditionele ontwikkelingsparadigma’s praten domeinexperts dikwijls langs elkaar heen in talen die de ander niet of nauwelijks begrijpt. Maar in een low-code-platform, wanneer iedereen in dezelfde virtuele ruimte werkt en een dezelfde taal spreekt, is er geen communicatiebarrière die zorgt voor vertraging en onduidelijkheid. Teams kunnen autonoom werken aan een gezamenlijk einddoel.
Zodra business- en it-teams het samenwerken via een low-code-platform onder de knie hebben, ontstaat er soms een bijzondere situatie: het it-team moet wachten op de business. Juist, de ontwikkelaars zijn niet langer de bottleneck, zoals zo vaak gedacht wordt of het geval is. Door de snelle samenwerking gaat iteratie sneller dan ooit en de oplossing is nauwkeurig en relevant. Domeinexperts vanuit de business zullen zich moeten aanleren sneller te reageren om het proces niet te vertragen.
Geen vertaling nodig
Als business en developers in dezelfde taal spreken – zoals in een visueel model – is er geen vertaling nodig, begrijpt iedereen de problemen en oplossingen zoals ze worden gepresenteerd, zijn iteraties snel en blijft iedereen vanaf het begin betrokken in het proces van idee tot implementatie. Door samenwerking is het mogelijk om snel de juiste oplossing te bouwen en wordt nabewerking verminderd.
De afsluitende alinea over business en developers die dezelfde taal spreken tot implementatie geeft precies aan waarom er een business-IT alignment probleem is aangaande de lifecycles. Onderhoudbaarheid van een oplossing bepaalt 3/4 van de kosten maar allerlei service management disciplines worden niet meegenomen omdat er alleen maar naar functionele eisen gekeken wordt. Domeinexperts vanuit beheer kunnen bottlenecks voorkomen zoals een tekort aan resources. Discipline van capaciteitsmanagement zorgt voor een voorspelbaarheid in de kosten als we kijken naar het verschil tussen effectiviteit van iteraties en de klap van efficiëntie door in één keer je doel te raken.
Er zijn aan de ene kant vakspecialisten nodig voor de invulling van een complete projectinrichting. Er zijn grofweg acht lagen in zo’n aanpak:
– Business case (inclusief vraaganalyse en eisen en wensen)
– Organisatieproces (inclusief actoren)
– Functionele analyse (middelen toewijzing, maar dan productonafhankelijk, logisch gegevensmodel, proces- en organisatie (business) logica, toetsing op kaders en richtlijnen (bijvoorbeeld privacy, security, etc… by design eisen en wensen), opstellen functionele acceptatiecriteria en bijbehorende instrumentaria, functioneel testcases, voorbereiding live-gang scenario)
– Technische (implementatie) analyse, middelen toewijzing, maar dan feitelijk, technisch datamodel, desnoods werkinstructieniveau van processen, technische acceptatiecriteria en bijbehorende instrumentaria, technisch testcases, voorbereiding live-gang scenario)
– Bouworderfase, waarin alle technische componenten uit de technische analyse (het ontwerp) worden beschreven in activiteiten, resources, en risico’s, maken planning
– Implementatie, waarin de in de bouworderfase geplande bouwcomponenten worden gemaakt (ontwikkeld) met daarin alle testcycli, dus unit, technische en functionele testst, afsluitend met een ketentest. Zolang het nog niet goed is, blijven we ontwikkelen.
– Livegang (Trainingen en live zetten van de ontwikkelde functionaliteiten)
– Nazorg (Oppakken directe problemen, overdracht naar beheer, evaluatie en decharge)
Nu is dit zwaar waterval, maar dit is prima iteratief te doen. Probleem van dit alles dat je veel disciplines nodig hebt. En een iemand die het geheel in de gaten houdt. Mijn persoonlijk ervaring is dat je in de business niet iemand vindt die het inzicht en overzicht hebt die alle facetten van alle beschikbare data heeft. Het is een illusie om te geloven dat dat vanuit de business komt. De ontwikkelaars zitten vaak op een vierkante postzegel en hebben dat inzicht en overzicht ook niet. Gevolg is point solutions. Je moet met heel veel zaken rekening houden (zie oudlid). Dat vereist echt een andere aanvliegroute. Het idee overigens dat je dat met een low-code platform zou kunnen oplossen is inherent een foute gedachte gang. Low-code is ook een platform en daar izt dan ook gelijk het abstractieprobleem. Is er een organisatie in de wereld die compleet in een low-code platform is gebouwd? Ik gok van niet. Dit is dezelfde discussie als eind jaren 90, met ERP systemen, dat zou stukken goedkoper zijn. Not dus. Met andere woorden, je complete ICT-landschap dient aan de ene kant voldoende flexibiliteit te hebben en aan de andere kant allerlei aspecten mee te nemen in de oplossing.
Ik ben het wel eens dat visualisatie van het compleet organisatielandschap een goede bijdrage levert, maar het idee dat je in een gemiddelde organisatie iedereen die een rol zou moeten spelen daarin kan werken is een behoorlijke uitdaging. Ik zit daar zelf nu midden in en het vergt veel afstemming, uitleg en energie. Vanzelf gaat dat echt niet.
Er is hier nog geen uniforme methodiek voor. Ik zoek dit zeker niet in de techniek.
De hier vermelde beeldtaal doet wel denken aan de eerste grottekeningen van de prehistorische mens.
Gelukkig is hij, ook qua taal, sindsdien verder geëvolueerd.
@Jack
dat gaat weer terug, als je naar de duitse televisie (ZDF) kijkt dan wordt je getrakteerd op een uitleg met tekeningetjes op kleuterklasnivo, nederland ontvang ik hier niet. Ik voel me als kijker beledigd.
Of kunnen de nieuwe (duitse ?!) facebookers geen gescheven taal meer begrijpen?
In Oostenrijk zou dat zinnig zijn omdat ieder gat zijn eigen onverstaanbare dialekt heeft maar daar kiest de overheid voor een gezwollen taalgebruik zodat de burger niet begrijpt hoe hij bedrogen wordt.
Krijgen jullie in NL ook die cartoons op de tv om uit leggen wat bijv. de “corona-app” betekent?
“Maar in een low-code-platform, wanneer iedereen in dezelfde virtuele ruimte werkt en een dezelfde taal spreekt, is er geen communicatiebarrière die zorgt voor vertraging en onduidelijkheid. Teams kunnen autonoom werken aan een gezamenlijk einddoel. ” :
Zo snel mogelijk Vendor Lockin bij Mendix
In het weekend mijn ouwe moeder nog geholpen met de tabpad. Ze weet zich geen raad meer als een icoontje verplaatst is of er net iets anders uitziet. Eigenlijk ben ik ook een soort Mendix consultant.
Hallo Jack,
De prehistorische grottekening is niks anders dan een ‘didactische’ leerplaat toen nog niemand het geschreven woord kon lezen. En beeldtaal is belangrijk voor 2,5 miljoen laaggeletterden in Nederland, arbeidskrachten die de pictogrammen wel begrijpen maar de teksten niet kunnen lezen. De beeldtaal van IKEA om een kast in elkaar te zetten is eigenlijk geniaal want de mens lijkt nauwelijks geëvolueerd in de taal.
Ben benieuwd hoe die autonomie van die teams en die snelle samenwerking in de praktijk verlopen wanneer team A objecten van team B heeft aangepast en andersom.
@oudlid
heb je wel eens een ikeameubel zelf in elkaar gezet? 😉
In de EU is men op weg naar newspeak, er worden steeds meer “ongewenste woorden” gedefinieerd.
Ook geschiedvervalsing wordt op grote schaal bedreven, zonder de russen waren we allemaal duitsers van het derde rijk.
Taal is een machtig instrument, simplificatie schaadt ontwikkeling.
Jan,
Als eerste is de instructie voor het in elkaar zetten van de Björn beeldspraak welke tot een verbeelding spreekt omdat iedereen ervaring heeft met de iteratie van één stap vooruit en twee terug. En ik denk dat velen zich herkennen in het gebruik van onderdelen in stap 7 die je eigenlijk pas in stap 29 nodig had. En betreffende het spreken van dezelfde taal, als je weet waar M5x100 en M5x50 in verschillen dan wordt een uitleg makkelijker. De auteur zwijgt helaas nog in alle talen maar betreffende Europa geef ik nog altijd de voorkeur aan het metrische stelsel om je een idee te geven waar ik met mijn reactie heen wil. Want één woord kan meer zeggen dan duizend plaatjes als dat woord maar één uitleg kent.
Wat ik met mijn vorige opmerking wilde zeggen:
een visuele modeltaal (en dus ook low code) is hooguit 4GL; we moeten toch echt naar een 5GL.
Jan, je reacties maken weer eens duidelijk wat voor complex (en fascinerend!) verschijnsel de menselijke taal is.
Een fraaie bespiegeling over beelden en taal vind ik deze:
https://www.trouw.nl/cultuur-media/hoezo-zegt-een-plaatje-meer-dan-duizend-woorden~b58a1d14/
Op pakjes sigaretten zie je niet hele lappen tekst staan; wel de beelden van verwoeste longen en ander ongemak.
Er zijn tegenwoordig heel veel redenen om geen vlees meer te eten en als de weerzinwekkende beelden uit de bio-industrie hierin kunnen helpen moet dat maar.
Je onderscheid tussen de onverstaanbare dialecten en de taal van de overheid doet wel denken aan de slogan “Think globally, act locally”. Dialecten weerspiegelen veel krachtiger de lokale omstandigheden; de overheid zal zich – in jouw geval – van een algemeen beschaafd Duits bedienen en daarin hoeft de burger natuurlijk niet per se te worden bedrogen.