Contact

Interview

Hoe transparant kunnen wij het maken?

Het is vandaag 18 september 2021, het is de internationale dag van de softwarevrijheid. Consultant Jeroen Akkerman mag voor een van onze opdrachtgevers zelf software inrichten. Maar waar begin je in de zee van softwaremogelijkheden, kennis en specialisatie? Hoe zorg je dat je onderweg niet verdrinkt en dat je tegelijkertijd wel de transparantie kan bieden richting de opdrachtgever? Jeroen neemt jullie graag mee in zijn reis.

“Oké Jeroen we hebben een mooi project waar we jou bij nodig hebben. Jij mag een applicatie gaan modelleren en deze overdragen naar de opdrachtgever door hem hierin op te leiden en zelf te laten beheren.” Dit is mijn eerste kennismaking met het zelf inrichten van software onder de visie van voordoen, samendoen en zelf doen. De eerste teen die ik dip in de zee van softwaremogelijkheden, kennis en specialisatie. Hoe begin je deze tocht zonder onderweg te verdrinken? Hoe geef je daarbij je klant een zo transparant mogelijk beeld van wat je aan het doen bent?

Voor ik begon dacht ik eerst na waar mijn eigen behoefte aan transparantie ligt: “Als ik vlees koop in de winkel, wat wil ik daar dan allemaal van weten? Waar komt het vandaan, hoe heeft het dier geleefd, hoe is het getransporteerd en geslacht en wat voor impact heeft het hele proces gehad op dier en milieu?”. Als ik al zoveel vragen heb bij iets wat eigenlijk zo simpel zou moeten zijn, hoeveel vragen zou mijn opdrachtgever dan wel niet hebben bij iets dat zo vele malen complexer kan zijn, zoals het ontwikkelen van software.

First things first
Als mijn behoefte aan transparantie al zo groot is, hoe groot zou deze behoefte dan zijn bij mijn opdrachtgever? Zij geven mij het vertrouwen om te doen waarvan ik denk dat het beste voor hen is. Dit kan natuurlijk best beangstigend zijn als er geen transparantie is. De eerste richting, stap of taak op mijn roadmap was gevonden. Creëer een omgeving waarin zowel de opdrachtgever als ik zelf vragen, informatie en planning kwijt kunnen. Dit vraagt wat extra toewijding maar het is eigenlijk onmisbaar.

Ik wil openheid creëren over dat wat ik doe, bouw en aflever. Het eerste wat ik deed, was het opzetten van een planboard met daarbij behorende taken. Vervolgens het opzetten van een wiki omgeving waarin zowel ik als de gebruiker kan bijdragen in informatie, vragen en antwoorden. De lijntjes moeten zo kort mogelijk en de deuren zover mogelijk open. Kom kijken in de fabriek naar hoe jouw product wordt gemaakt.

Voordoen, samendoen en zelf doen
De applicatie die ik mocht gaan ontwikkelen was een excasso test omgeving. Dit betekent dat er veel fiscale berekeningen moeten plaatsvinden om een correct eindresultaat te leveren. Zodra je op fiscale wetgeving inzoomt en dit ook nog eens naar een applicatie gaat vertalen raak je veel mensen kwijt. Daarom werk ik ook met het principe van voordoen, samendoen en zelf doen.
Dit houdt in dat je de opdrachtgever direct betrekt bij de ontwikkeling, niet alleen als informatiebron maar op code niveau. Je zet een basis neer, waarna je kennisdragers of specialisten meeneemt om bij te dragen aan de te schrijven rekenregels. Je brengt ze een basisbegrip van de ontwikkeltaal bij en het platform waarin ze werken. Dit breid je stapsgewijs steeds verder uit met eigen ontwikkeltaken waar je via pair programming in ondersteunt. Nu heeft de opdrachtgever niet alleen een live beeld van de voortgang, maar ook informatie over zijn applicatie, én een directe ingang in de ontwikkeling ervan.

Nu is het aan jullie
Mijn doel met voordoen, samendoen en zelf doen is de opdrachtgever zo snel mogelijk zelf de controle te geven over zijn ontwikkeling en innovatie. Niet meer: “we hebben een bug dat moeten we uitzetten bij …..” of “even met de ontwikkelaar mailen of ze een fix kunnen doen”. En niet meer afhankelijk zijn van de planning van een ander om de eigen applicatie draaiende te houden en verder te innoveren.

Tijdens het project heb ik een aantal medewerkers van de opdrachtgever opgeleid zodat zij dat wat ik heb gemaakt kunnen overnemen en verder kunnen uitbreiden. Want waarom zou ik als externe alle kennis over jouw applicatie bij mij houden en verbergen? Tenslotte ben ik niet degene die er dagelijks mee moet werken. De behoefte aan transparantie en openheid tijdens het ontwikkelen van software, ligt niet alleen aan de code kant van software maar ook aan de informatie kant. Deze informatiestroom is ook zeker geen eenrichtingsweg van gebruiker naar mij, maar eigenlijk nog meer van mij naar gebruiker. Dat is voor wie ik het doe. Hoe meer ik de gebruiker kan meenemen, hoe groter de kans op een succesvolle applicatie.

Hoe transparanter en open ik mijn applicaties oplever, hoe groter de positieve gevolgen voor de gebruikers. Het stelt ze in staat om sneller en gemakkelijker zelf aanpassingen te doen, kleine tweaks te kunnen uitvoeren en nieuwe functionaliteiten te kunnen toevoegen in dat wat eigenlijk al van hen zelf is. Als ik dan bij implementatie en overdracht een eindpresentatie gegeven heb en de medewerkers die ik heb opgeleid, enthousiast verhalen hoor vertellen over hoe ver ze al zijn en hoeveel ze al zelf kunnen bijdragen. Nu weet ik voor mijzelf weer waarom transparantie en openheid belangrijk is.