In eerdere opinies in deze reeks ('Requirements: bezint eer ge begint…' en 'Nut en noodzaak business requirements') hebben we het gehad over de rol van stakeholders bij de totstandkoming van requirements en over het belang van business requirements. Dit keer richten we ons op de rol van de it-ontwerper – de persoon die het daadwerkelijke ontwerp van de nieuwe oplossing verzorgt. Wat blijkt: ontwerpers beschikken vaak niet over de juiste skills om een oplossing te ontwikkelen die echt beantwoordt aan de gestelde eisen.
Op dit moment bestaat een te eendimensionaal beeld van wat een ontwerper moet kunnen. Dat geldt bij de ontwerpers zelf, maar ook bij hun werkgevers. De meeste beschikbare opleidingen bevestigen dit beeld. Het gaat vaak om een fragmentarische verzameling modules die vooral is gericht op technische skills. De vigerende gedachte bij deelnemers, werkgevers en aanbieders van opleidingen is dat als ontwerpers de juiste tools kennen en/of weten welke templates ze moeten invullen, het allemaal wel goed komt. Die gedachte doet het vakgebied geen recht.
Een goede ontwerper beseft welke zaken tot ontwerp horen en welke niet . Hij beheerst niet alleen de tools, maar weet ook wat er speelt in de business. Bovendien is hij in staat te communiceren met iedereen die belang heeft bij zijn ontwerp en meebeslist over de scope van zijn opdracht. Daarnaast is een goede ontwerper ook methodisch onderlegd: hij weet welke stappen hij gaat uitvoeren, met welke diepgang en waarom. Het is die combinatie van vaardigheden die centraal moet staan in de opleiding, want het is die combinatie van vaardigheden die een it-ontwerper geschikt maakt voor zijn vak.
Communicatie
Goed communiceren houdt in: de juiste vragen stellen aan de juiste mensen. Maar je moet ook weten hoe je vaststelt en bewaakt dat je gesprekspartner op dezelfde golflengte zit als jij. Een gesprek heeft immers alleen zin als je met elkaar praat en niet langs elkaar heen. Dat houdt onder andere in dat de ontwerper aanvoelt op welk niveau hij welk gesprek moet voeren en wanneer hij van welke persoon input nodig heeft. Met de opdrachtgever praat je niet over details, maar over grote lijnen; met de programmeur ga je de technische diepte in en maak je minder woorden vuil aan de wensen van de business.
Dit klinkt wellicht vanzelfsprekend, maar de praktijk wijst uit dat ontwerpers vaak heel lange interviews houden waarin alle ins & outs op alle niveaus aan bod komen. Of het ontbreekt ze aan de assertiviteit het gesprek te sturen. In beide gevallen blijf je zitten met een enorme hoeveelheid niet altijd even relevante informatie, die het zicht kan ontnemen op waar het eigenlijk om gaat.
Dit gezegd hebbende is wel van belang dat je blijft doorvragen totdat je precies weet wat je gesprekspartner voor ogen heeft en totdat je zeker bent dat er volledig wederzijds begrip bestaat. Een gebrek aan eenduidigheid laat ruimte voor interpretatie – en interpretatie levert oplossingen op waarbij uiteindelijk niemand echt is gebaat.
Eenduidigheid is ook het toverwoord in schriftelijke communicatie. Ook in geschrift moet de it-ontwerper zich altijd bewust zijn voor wie het document bedoeld is. Hij moet dus niet in technisch jargon vervallen in een tekst die bedoeld is voor de opdrachtgever, en dient er bovendien op te letten dat de tekst volstrekt ondubbelzinnig is.
Dergelijke communicatievaardigheden zijn deels aangeboren, maar deels ook aan te leren. Het is van groot belang dat hier in opleidingen aandacht aan wordt besteed. We pleiten ervoor communicatieve vaardigheden niet alleen als aparte training te volgen maar juist geïntegreerd met de vakopleidingen. Op die manier kunnen de skills in praktijkverband worden geoefend en aangescherpt.
Businesskennis
De ontwerper behoort tot het it-domein, dus het is logisch dat hij zijn werk in eerste instantie beschouwt vanuit it-perspectief. Toch is het van belang dat hij de merites van het ontwerp en de requirements ook vanuit business-oogpunt kan bekijken. Om de wensen van de business te doorgronden, de gevolgen ervan voor de business te kunnen inschatten, en proactief de juiste vragen te kunnen stellen, is een goede en adequate hoeveelheid kennis van zaken nodig.
Als een ontwerper bijvoorbeeld meewerkt in een project dat een digitale overheidsdienst realiseert, dan dient hij zich op de hoogte te stellen van de functionele eisen van zo'n systeem waar het de audit-, beveiligings- en juridische consequenties betreft.
De methodische basis
Als een ontwerper geen weet heeft van de methode van systeemontwikkeling, dan loopt hij de kans dat hij ieder keer als hij betrokken wordt bij een ontwikkeltraject, het werk en de producten af laat hangen van de situatie. Inzicht in een van tevoren gekozen ontwikkelmethode voorkomt dat. Op die manier beseft de ontwerper wat er op welk moment van hem verwacht wordt, en welke diepgang van resultaten dat zal gaan opleveren. Het is ook zaak dat de ontwerper snapt dat hij soms met gestandaardiseerde sjablonen, documenten en modellen moet werken, maar soms samen moet werken vanuit een ‘Definition of Done' (Scrum) .
Structureren van resultaten
Of een ontwerper nu bezig is met requirements, tekst of uitvoerbeschrijvingen, hij moet in alle gevallen de kunst verstaan structuur aan te brengen in het resultaat . Hoe vaak zien we ontwerpen en documenten waar moeilijk doorheen te komen is, omdat handvatten, leeswijzers en/of een goede indeling ontbreken? Of ellenlange lijsten met requirements, waarmee het lastig werken is omdat een fatsoenlijke indeling ontbreekt? Of beschrijvingen van reports of XML-berichten waarin wel de inhoud is vermeld, maar waarin structuur, volgorde en sortering ontbreken?
Als je de kunst van structureren en groeperen verstaat kun je verschillende doelgroepen beter bedienen, terwijl de hoeveelheid documentatie toch overzichtelijk blijft.
Conclusie
De it-ontwerper vertaalt de problematiek van de business naar een bruikbare oplossing. Dat dit niet altijd lukt ligt niet aan een gebrek aan technische kennis of beheersing van de juiste tools. Het ligt meer aan een achterhaalde, te krappe definitie van wat een goede it-ontwerper is. Meer dan alleen een technisch expert is een it-ontwerper iemand die goede communicatievaardigheden en gedegen businesskennis weet in te zetten bij het ontwerp van een goede, op maat gemaakte oplossing.
Henk Brouwer, trainer/consultant systeemontwikkeling Capgemini Academy
Leo Kouwenhoven, productmanager requirements-opleidingen Capgemini Academy
Open Group
Het Open Group Certified IT Specialist programma (CITS) ademt dezelfde geest als beschreven in dit artikel. De breedheid van de eisen die aan de it-specialist worden gesteld komt met name in het ‘Core Foundations Skills' naar voren: zowel people-, business-, project management- als architectuurvaardigheden zijn basisvereisten. Naast die skills zijn Client Focus en Technical Focus belangrijke peilers onder de certificeringseisen voor de it-specialist.
Blijkt nu echt dat “ontwerpers” niet over de noodzakelijke skills beschikken? Welke ‘populatie’ van ontwerpers -ik noem ze meestal architecten- is hier het uitgangspunt en waar zijn de getallen, ofwel hoeveel van deze ‘sample’ lijdt aan de door jullie zo betreurde tekortkomingen?
Ik herken de noodzaak van structuur en moedig dit altijd aan. Echter, architecten moeten óók technische documenten kunnen opstellen voor de ontwikkelaars en specialisten. Gelet op dat doel, communicatie met technische specialisten, mogen dergelijke documenten wel degelijk heel technisch zijn. Ze hoeven ze niet direct begrijpelijk te zijn voor de klant zonder IT referentiekader. Een automobilist hoeft immers ook niet het technische design van de boordcomputer in zijn auto te snappen. Hij/zij kan zonder die kennis prima de auto besturen.
Wel mag je verwachten dat de bedoelingen kunnen worden uitgelegd in toegankelijke taal. Bij mijn selectie- en trainingswerk voor (inmiddels aan) Cap (verkochte) Business Units heb ik daar zonder uitzondering véél aandacht aan besteed. Niet alleen bij technici, maar JUIST ook bij managers. Bij elkaar al snel enkele honderden kandidaten en medewerkers. Echter, lang niet al die goede professionals werken nu nog voor Cap.
Binnen de reikwijdte van de auteurs: Wat denken jullie bij Cap te gaan doen aan het probleem dat jullie zelf aanstippen?
Een ontwikkelaar is ook de brug tussen techneuten en managers en zal beide ’talen’ moeten spreken. Vaak is hij/zij ook een van de belangrijkste personen in het politieke spinnenweb. Dat vereist vele kwaliteiten verenigd in een persoon. Die zijn maar beperkt beschikbaar dus is het al een redelijke opgave om die te vinden. Als dat niet lukt probeer het dan aan te vullen met een goede lead developer en/of projectleider die de zwakke plekken kunnen opvangen.