De functioneel beheerder als lid van het ontwikkelteam

Mijn laatste blog ging over de verschillende petten die een functioneel beheerder in een scrum team kan opzetten. Er zijn namelijk verschillende rollen mogelijk: als lid van het ontwikkelteam, als bewaker van de beheerbaarheid van het resultaat en natuurlijk als product owner, al dan niet gedelegeerd.

In deze blog zal ik de eerste rol, in het ontwikkelteam, nader onder de loep nemen.

Specificeren

Er gaan inmiddels allerlei benamingen rond voor deze activiteit, waarin we beschrijven wat er precies moet worden veranderd aan de informatievoorziening. Die beschrijving noemen we meestal specificatie of requirements. In de Agile aanpak wordt vaak gesproken over user stories. Maar hoe we het beestje ook noemen, het document legt de basis voor de vertaling van de wens van de gebruiker naar aangepaste en werkende software. Daarvoor is begrip van die wens nodig, maar ook goed inzicht in de (huidige) werking van de software en de mogelijkheden om die aan te passen. Laat deze combinatie van kennis nu net het kenmerk van een goede functioneel beheerder zijn.

Niet-geautomatiseerde informatievoorziening

We zijn nog steeds niet zo ver dat alles geautomatiseerd is. Een paspoortaanvraag begint nog altijd met het invullen van een formulier. Een goede aansluiting van dat formulier op het gemeentelijke informatiesysteem is een van de activiteiten in dit proces. Maar ook het opstellen van gebruikershandleidingen en werkinstructies.

Het Agile principe “werkende software boven volledige documentatie” wil er nog wel eens toe leiden dat juist deze activiteit op een laag pitje komt te staan en misschien wel geheel vergeten wordt. Als gebruikers niet kunnen werken met een systeem, omdat ze niet weten hoe dat moet, is alle inspanning voor niets geweest. Functioneel beheer weet dit als geen ander. En functioneel beheer weet hoe het systeem gebruikt moet worden. Opstellen en aanpassen van werkinstructies, formulieren en handleidingen is dan ook beslist een taak voor functioneel beheer.

Toetsen en testen

Voor acceptatietesten geldt hetzelfde als voor specificeren – om de bruikbaarheid van het sprint resultaat te verifiëren, is kennis van de business én kennis van de software nodig. En hoewel bij het uitvoeren van de test zeker “echte” gebruikers nodig zijn, is functioneel beheer bij uitstek degene die kan bepalen wát er door gebruikers getest moet worden. En wat vooral niet, bijvoorbeeld omdat het tot het domein van de ontwikkelaars behoort.

Voorbereiden transitie

Om de aangepaste software te kunnen gebruiken is nog een essentiële activiteit nodig – het opleiden van gebruikers. Juist bij het hoge tempo van sprints dat vaak wordt gehanteerd is het van wezenlijk belang om de gebruikers goed te begeleiden in wat er in een bepaalde sprint op ze af komt. En ook daarvoor is de juiste combinatie van business en IT kennis nodig, die nu juist door functioneel beheer wordt ingebracht.

Conclusie

Een multidisciplinair ontwikkelteam is niet compleet zonder vertegenwoordiging van de gebruikers. Bovenstaande laat zien dat voor de beste vertegenwoordiging nu juist die competenties nodig zijn, waarmee functioneel beheer zich al jarenlang bewijst.

Tips en trucs

Benieuwd naar tips en trucs voor het uitvoeren van deze activiteiten in een scrum team? Blijf dan deze website in de gaten houden, want de komende weken zal ik daar vooral aandacht aan besteden.