Wat doe je precies?

Mij wordt vaak de vraag gesteld: Wat doe je nou eigenlijk precies? Iets met software, toch? Bouw je websites? Daarom hieronder een interview met mezelf, over wat ik doe met Pick my Brain.

Ok, dus vraag 1: Wat doe je precies? Bouw je websites?
Ik ben Functioneel Ontwerper, dat wil zeggen dat ik software ontwerp op functioneel niveau. Ik specificeer wat de software doet, niet hoe die er grafisch uit ziet of hoe de database precies is opgebouwd. Ik bouw zelf geen software. Vergelijk het met een huis: degene die bedenkt hoe het huis er uit moet zien (de architect) is niet dezelfde persoon als degene die de steentjes op elkaar zet (de bouwvakker). Daar zitten nog wat stappen tussen. Met software is dat ook zo. Het is mijn taak om te zorgen dat het ‘droomhuis’ van de opdrachtgever gebouwd kan worden. Ik begrijp de business-kant én de IT-kant. Daarbij specialiseer ik me in het ontwerpen voor outsourcing naar het buitenland, waarbij de software gebouwd wordt door programmeurs in een ander land (bekendste voorbeeld is India).

Wat is er specifiek aan ontwerpen voor outsourcing naar het buitenland? De software blijft toch hetzelfde?
Outsourcing naar bijvoorbeeld India heeft de reputatie dat er veel mis gaat, dat de opgeleverde software niet is wat gevraagd werd en dat ze ja zeggen en nee doen. Als een programmeur makkelijk in de auto kan stappen om bij de opdrachtgever aan tafel te komen, kan dit misverstanden voorkomen. Niet alleen de afstand is bij oursourcing een drempel, maar ook de taal en cultuur. Begrijpt de programmeur echt wat je bedoelt, of durft hij niet te zeggen dat hij het niet begrijpt? Ook zijn er veel dingen vanzelfsprekend voor de een, maar niet voor de ander, door taal, cultuur of bijvoorbeeld landelijke wetgeving. Uitleg in documentatie moet explicieter zijn. Ook de communicatie daarbuiten behoeft extra aandacht.

En waarom zou jij wel weten hoe je met ze moet communiceren?
Ik heb een jaar in Thailand gewoond en alles bij elkaar bijna een jaar in China gezeten. Verder heb ik twee jaar gewerkt bij een bedrijf met programmeurs in Bulgarije. Talen en culturen hebben me altijd gefascineerd, dus daar ben ik diep ingedoken. Ik spreek goed Thais en aardig Chinees. Buiten dat hebben deze ervaringen mij geleerd ‘cultureel sensitief’ te zijn. Ik pik het snel op als twee mensen elkaar verkeerd begrijpen.

Wat voor software ontwerp je?
Dat hangt ervan af wat de opdrachtgever wil hebben. Ik heb ervaring met eenvoudige bedrijfswebsites, complexere online platforms en mobiele apps, maar ook met applicaties voor de medische en de energiesector. Ik heb wel de voorkeur voor software waar mensen actief mee interacteren, in tegenstelling tot automatiseringssoftware aan de achterkant van een bedrijf.

Dus jij schrijft van die saaie lijvige documenten die toch niemand leest. Tegenwoordig doet toch iedereen aan Agile development, Scrum bijvoorbeeld. Dan heb je die documentatie helemaal niet meer nodig.
Ik streef naar leesbare documentatie die zowel voor de opdrachtgever als voor de programmeur begrijpelijk, eenduidig en volledig is. Ik maak zo veel mogelijk gebruik van visuele elementen, zoals wireframes, stroomdiagrammen en boomschema’s. Ook bij Scrum development moet bepaald worden wat er gebouwd gaat worden. Mijn rol kan die van de Product Owner zijn, namens de opdrachtgever, voor het uitschrijven van Stories (gebruiksscenario’s) en het bepalen wat er in welke Sprint (ontwikkelstap) gebouwd gaat worden.

Ik heb een beeld. Maar hoe ziet zo’n Functioneel Ontwerp er dan uit?
Download hier een voorbeeld van een Functioneel Ontwerp.

Aha. Dus dat is wat een Functioneel Ontwerper doet
Ja, zo ongeveer. Functienamen zijn in de IT nog steeds niet helemaal uitgekristalliseerd. Een Functioneel Ontwerper kan ook puur gericht zijn op het schrijven van (al dan niet lijvige) documentatie, zonder veel contact met de opdrachtgever of de programmeur. Je kan me ook Informatie-analist noemen, of Business-analist, of Requirements-engineer. Interactie-ontwerpers zitten meestal wat meer aan de kant van het grafisch ontwerp. Software-architecten houden zich meer bezig met hoe de software er aan de achterkant, de constructie, uitziet.

Schrijf je alleen maar specificaties?
Omdat ik door het ontwerp de te bouwen software door en door ken, begeleid ik ook de programmeurs tijdens de bouw bij eventuele onduidelijkheden. Verder train ik bij oplevering de opdrachtgever in het gebruik van de software en/of het onderhouden van de website. Daarnaast geef ik workshops over taal en cultuur, bijvoorbeeld Chinees voor Dummies, waarbij ik in 2,5 uur een introductie geef in het schrift, de uitspraak, conversatie, geschiedenis en culturele verschillen. Een goede en leuke voorbereiding op samenwerking met Chinezen.

Allemaal leuk, maar ik heb een website nodig. Kan ik je inhuren?
Natuurlijk kan ik je helpen om die website gerealiseerd te krijgen. Ik heb genoeg grafisch ontwerpers en softwarebouwers (in het buitenland) in mijn netwerk om die website te maken. Maar meestal zijn de mensen die mij inhuren niet de eindklanten die de software nodig hebben. Die zoeken naar software-ontwikkelbedrijven, niet naar functioneel ontwerpers. Die weten niet dat ze iemand nodig hebben om de businesswensen te vertalen in softwarespecificaties. Maar de software-ontwikkelbedrijven weten wel dat ze iemand nodig hebben om de discussie met de klant aan te gaan over de specificaties. En grafisch-ontwerpbureaus die huisstijlen ontwerpen en regelmatig de bijbehorende website moeten laten bouwen, weten dat het lastig kan zijn om de programmeurs te laten begrijpen wat ze willen. Deze software-ontwikkelbedrijven en grafisch-ontwerpbureaus zijn vaak mijn klanten, omdat zij weten dat ze me nodig hebben. Zij weten dat tijd, geld en frustratie bespaard kan worden als de specificaties aan het begin van het project duidelijk zijn.