Weet jij wanneer je welke requirements moet weigeren?

Weet jij wanneer je welke requirements moet weigeren?

Ken je hem nog, Sjors de Manager uit het reclamefilmpje? ‘The inspirator’ die een medewerker die hem om 4 uur ’s middags met een vraag stoort afblaft met “NU! EVEN! NIET!”. En die vervolgens na het nuttigen van zijn Cup-a-Soup middenin de kantoortuin op een stoel gaat staan en zich verontschuldigd met: “Jongens, het spijt me van daarnet. Zeg het maar: Sjors, je bent een eikel …. Kóóóm maar, kom maar, kom maar, kom maar.”

Als Product Owner, Business Analist of Functioneel Beheerder in ICT-projecten zul je ook over beide vaardigheden van manager Sjors moeten beschikken, zij het uiteraard stukken subtieler uitgevoerd.

Aan de ene kant zul je in gesprekken en (brainstorm) workshops zoveel mogelijk ideeën, wensen en eisen van stakeholders moeten zien te achterhalen.

Aan de andere kant kun je niet al deze wensen en eisen accepteren, alleen maar omdat iemand het een goed idee vindt. Je moet ‘Nee’ kunnen zeggen. Of op z’n minst ‘Niet nu’ of ‘Niet in deze oplevering’ in wat meer politiek gevoelige omgevingen.

En niet alleen zo af en toe, maar juist heel vaak en keer op keer. Want op alle requirements van stakeholders klakkeloos ‘Ja.’ zeggen leidt niet alleen tot een lange lijst aan wensen en eisen. Zo’n lange lijst werkt namelijk precies hetzelfde als voor elke rij. Of je nu in de rij staat voor de kassa, het toilet of in de file, hoe langer de rij voor je hoe langer je moet wachten. En daar wordt niemand over het algemeen vrolijk van.

En daar komt nog eens bij dat het verleden ons ook heeft geleerd dat geen ‘Nee’ durven zeggen leidt tot goudgerande, complexere en duurdere software oplossingen waarvan zo’n 65% van de gewenste functionaliteit helemaal niet of nauwelijks wordt gebruikt (Chaos rapport Standish Group). Dus moet je eigenlijk ook nog eens onnodig lang wachten op de functionaliteit die je altijd of vaak wilt gebruiken.

Kortom, het niet accepteren van alle requirements zorgt ervoor dat de stakeholders sneller krijgen wat ze ook daadwerkelijk nodig hebben.

Maar ‘Nee’ zeggen tegen stakeholders is niet altijd makkelijk. Je wilt hen immers niet teleurstellen. En als je wel ‘Nee’ zegt wil je niet beschuldigd worden van willekeur, vriendjespolitiek of ‘wie het hardst schreeuwt krijgt zijn of haar zin.”

En toch is dat goed te doen. In de praktijk zie je namelijk dat mensen en ontwikkelteams die wel snel, onderbouwd en effectief ‘Nee’ kunnen zeggen tegen bepaalde ideeën en requirements van stakeholders juist heel goed weten wanneer ze ‘Nee’ moeten zeggen.

Maar hoe komt het dan dat zij dit zo goed weten? En dat stakeholders dit weigeren van requirements vervolgens ook zonder morren accepteren?

Vaak zie je dat zij over de volgende hulpmiddelen beschikken om het zichzelf makkelijk te maken om ‘Nee’ te zeggen:

  1. Een heldere productvisie
    Ten eerste hebben zij voor hun product een scherp beeld van de belangrijkste behoeften van de gebruikers en/of klanten, de belangrijkste kenmerken waar het aan moet voldoen én welke waarde het moet opleveren voor de organisatie. Vaak hebben zij deze visie voor iedereen zichtbaar opgehangen, bijvoorbeeld in de vorm van een ‘vision board’.
    .
  2. Een hiërarchische indeling van de requirements
    Daarnaast leggen zij hun requirements niet vast in een platte lijst of spreadsheet, maar brengen zij de onderlinge samenhang tussen de requirements overzichtelijk in kaart, bijvoorbeeld in de vorm van een ‘user story map’. Dit geeft hun de mogelijkheid om onderscheid te maken tussen requirements die essentieel zijn voor de 1e of huidige release (‘now’ – requirements) en requirements die kunnen wachten tot een volgende release (‘not now’- requirements).
    .
  3. Een helder besluitvormingsproces…
    Ze hebben een proces ingericht waarbij het voor stakeholders en development team klip en klaar is welke stappen er genomen (moeten) worden en door wie om te beslissen over de prioriteit en plaatsing van de requirements op de lijst of kaart.
    .
  4.  … met duidelijke beslisregels
    En ze maken daarbij gebruik van duidelijke regels. Bijvoorbeeld het verzoek heeft een bepaalde prioriteit gekregen én is binnen x maanden te realiseren.Maar óók regels om op gezette tijden geplaatste requirements weer van de lijst of kaart te verwijderen. Bijvoorbeeld wanneer de requirement er langer dan x maanden op staat of wanneer deze in de tussentijd geen of nauwelijks waarde meer heeft voor de organisatie.

Tot slot, hou jezelf en de stakeholders niet voor de gek. Het is onrealistisch om alle wensen en eisen van stakeholders te realiseren. Zeg dus zo vaak mogelijk ‘Nee’ of ‘Niet nu’. Veel vaker dan je nu waarschijnlijk doet. Dan kun je eerder ‘Ja’ zeggen tegen die wensen en eisen die werkelijk essentieel zijn voor de stakeholders en het product.

Welke ervaringen heb jij met ‘Nee’ zeggen tegen stakeholders? En welke middelen en technieken zet je daarbij in om het jezelf makkelijk(er) te maken? Ik ben erg benieuwd. Je reactie is hieronder van harte welkom.

Vind je dit artikel waardevol? Deel het dan met anderen voor wie het ook interessant kan zijn, bijvoorbeeld via Facebook, Twitter, LinkedIn of Google+. Alvast hartelijk dank daarvoor!

, , , ,

No comments yet.

Leave a Reply