Van grijs naar helder: een saaie maar noodzakelijke post

Eisen en specificaties respecteren: Ze kunnen bijten

Het zoveelste artikel over projectspecificaties, vrees ik. Ik hoorde deze week van weer een omissie in een specificatie. Alleen waren deze keer de gevreesde aannames de oorzaak van het probleem. Gelukkig is de impact minimaal, dus de oplossing hoeft niet overhaast de deur uit. Het had zo weinig prioriteit dat ik aarzel om het een mislukking te noemen. Frustrerend, dat zeker.

Onthulling. Ik gebruik Generative AI tools om me te helpen bij het schrijven. Van contour suggesties tot onderwerpen of subtiliteiten, die ik nog moest bedenken.

Foto landschap: Verspreid over het landschap liggen bruggen, elk in een andere bouwfase. Sommige bruggen lijken incompleet, andere versleten en een paar beginnen net met zichtbare steunpilaren. De scène is verzadigd met ultrarealistische details, waarbij grijzen en zilveren kleuren aanwezig zijn maar niet overheersen, wat zorgt voor een minder dystopische sfeer, die de strijd maar ook het doorzettingsvermogen in de projectontwikkeling symboliseert. — Van grijs naar helder Gegenereerd door DALL E 3

Bekijk hier meer artikelen, posts en discussies over ondernemen, projectmanagement, Generatieve AI en Creatief Schrijven op Medium. Abonneer je op Medium als je dat nog niet hebt gedaan. Of volg me hier op Substack.

Softwareprojecten mislukken om vele redenen, maar een van de meest voorkomende oorzaken is een gebrek aan precieze vereisten. Zonder een duidelijk begrip van de bedrijfsvereisten en gebruikersbehoeften is het moeilijk voor het projectteam om te begrijpen wat het project moet bereiken en hoe het moet functioneren.

Verkennen voor specificatiescherpte

Wanneer een organisatie een eisenspecificatie voor een nieuwe functie opstelt, zullen ze er natuurlijk voor zorgen dat de specificatie naar hun beste weten volledig, nauwkeurig en ondubbelzinnig is. Ze zijn ervan overtuigd dat ze alle aspecten van de gewenste functie hebben afgedekt.

Helaas worden de uitzonderingen vaak gemist, die ene procent van het proces dat niet de normale logische stroom van het proces volgt of kan volgen. Het zijn altijd deze minderheidsgevallen die verderop in het proces voor de meeste hoofdpijn zorgen, waar ze aan het einde van het project worden opgepikt, meestal tijdens de test- en acceptatiefase.

Maar alles is nog niet verloren; door ervoor te zorgen dat de specificatie van de vereisten nog eens goed wordt bekeken, bij voorkeur voordat het project wordt aanbesteed, zullen de meeste van deze use cases waarschijnlijk worden opgepikt. De meesten, maar niet de besten onder ons, vergeten deze zeldzame voorvallen. Er zullen dus altijd vreemde momenten zijn waarop er eentje ongedocumenteerd doorheen sluipt.

Door de rommel heen snijden

Er bestaan veel technieken en methodologieën om het beste en meest complete Project Requirements document te produceren. Geen van deze technieken is echter een 5-minuten oplossing, waarvoor tijd nodig is om ze correct uit te voeren. De belangrijkste is om vanaf het begin alle belanghebbenden erbij te betrekken. Wie zijn deze belanghebbenden? Je denkt misschien dat je dat al weet, van de sponsors van het project tot het Project Management team en natuurlijk de Developers. Misschien zijn één of twee eindgebruikers wel genoeg.

Het identificeren van je stakeholders klinkt eenvoudig, maar vaak worden de eindgebruikers vergeten of worden een paar symbolische key users opgenomen. Een stakeholder is iedereen die belang heeft bij het product of de dienst die wordt geproduceerd of geleverd. Het kunnen interne stakeholders zijn (werknemers) of externe stakeholders (klanten, regelgevers of leveranciers). Elke stakeholder heeft specifieke behoeften of vereisten die hij vervuld wil zien.

Elk van deze behoeften moet tijdens het project in evenwicht zijn. Vaak hebben belanghebbenden concurrerende behoeften, die de planning, het budget en de omvang van het project kunnen beïnvloeden als ze niet effectief worden gemanaged. Veranderingen zullen een domino-effect hebben op het gebied van prijzen, materialen en ontwerp, wat uiteindelijk het project zal vertragen.

Als een stakeholder toevallig je klant is, moet je ervoor zorgen dat je zijn exacte vereisten achterhaalt om je product of dienst te kunnen leveren. Als je niet de juiste vragen stelt met de juiste methode, voldoe je niet aan de behoeften van de klant en kan het project uiteindelijk mislukken.

Specs aanscherpen via feedback

Er zijn verschillende manieren om requirements te verzamelen die variëren afhankelijk van het type en de complexiteit van het project. Elke methode heeft voor- en nadelen. Het is het beste om deze technieken te combineren en geen kortere weg te nemen bij het verzamelen van projecteisen.

Het succes van het project is direct gerelateerd aan hoe goed de vereisten worden gecommuniceerd, gedocumenteerd en uitgevoerd. Een best practice is om zoveel mogelijk belanghebbenden erbij te betrekken. Er bestaat geen vaste methode of techniek om business requirements te verzamelen; het hangt af van het scenario. Voor sommige projecten kan de interviewtechniek werken, voor andere moet je misschien gezamenlijke sessies of groepsinterviews gebruiken.

We kunnen een kwalitatief hoogwaardig document voor bedrijfsvereisten opstellen en vastleggen met de negen technieken voor het verzamelen van vereisten die hieronder worden beschreven. Elke requirement-verzamelingstechniek heeft zijn voor- en nadelen; daarom moeten we de technieken kiezen die het beste passen bij het project en de situatie.

Dit zijn de negen algemene methoden die gebruikt kunnen worden, gegroepeerd op basis van hun algemene belang tijdens de gehele levenscyclus van projectontwikkeling, hoewel verschillende methoden in elke fase van het project toepasbaar kunnen zijn, afhankelijk van het individuele project:

Eerste analyse

Eén-op-één gesprekken.
Groepsinterviews.
Brainstormen.
Documentanalyse.
Vragenlijsten en enquêtes.

Eerste analyse en tijdens de ontwikkeling

Focusgroepen.
Eisen workshops.
Observatie van gebruiker en systeem.
Prototyping en wire-framing.

De meeste van deze technieken zijn gericht op de initiële analyse van de vereisten en als een constant feedbackmechanisme tijdens het ontwikkelingsproces om ervoor te zorgen dat het eindproduct zo nauwkeurig en volledig functioneel mogelijk is. Workshops zijn bijvoorbeeld uitzonderlijk informatief en beoordelen de verschillende pre-release kandidaten tijdens de ontwikkelingslevenscyclus. Prototyping is ook waardevol voor het verifiëren van geïmplementeerde functionaliteit tijdens de ontwikkeling.

Van mist naar focus

We hebben kort de rol van workshops en prototyping genoemd bij het verduidelijken van projectspecificaties, maar ze zijn even belangrijk tijdens de verschillende fasen van ontwikkeling. Denk bijvoorbeeld aan het houden van workshopsessies naarmate elke mijlpaal van het project wordt bereikt. Ze zijn uiterst nuttig om problemen tijdig op te sporen, waardoor mogelijk kostbaar herstelwerk en vertragingen worden verminderd of geëlimineerd. Laten we twee scenario's bekijken.

De eerste en meest voor de hand liggende is wanneer, hoe grondig de analyse van de vereisten ook was, er soms een omissie door het net sluipt. Het is beter om dit zo vroeg mogelijk op te pikken wanneer er geen impact is op de totale kosten en oplevering van het project.

Ik zou kunnen proberen om dit met een voorbeeld te illustreren, maar dan zou ik me alleen op één bedrijfstak kunnen richten en uiteindelijk veel onbekende lezers in verwarring brengen. Het is voldoende om je een zelden voorkomend scenario voor te stellen dat in het verleden handmatig of met een workaround werd afgehandeld. Het probleem kwam zo zelden voor dat veel gebruikers zich niet bewust waren van de mogelijkheid. Gelukkig is het probleem eindelijk op tijd geïdentificeerd om ervoor te zorgen dat het in het geleverde product kan worden afgehandeld.

Het tweede en meest voorkomende scenario is wanneer een gedocumenteerde functie na implementatie inefficiënt of onwerkbaar blijkt te zijn. De workshops kunnen helpen bij het verfijnen van de gedocumenteerde specificatie naar een oplossing die de vereiste volledig behoudt in een geoptimaliseerd formaat. De belanghebbenden die voor de workshops worden uitgenodigd zijn een diverse selectie van mensen, wat de feedback die uit de sessie wordt gehaald aanzienlijk verbetert. De verschillende gezichtspunten en gebruikersvereisten zijn de meest kritische bron voor elk project.

Laatste gedachten

Misschien niet het meest meeslepende onderwerp ter wereld, maar wel een dat blijft boeien. Het lijkt erop dat sommige organisaties nooit leren en gedoemd zijn om dezelfde fouten steeds weer te herhalen. Het helpt ook niet dat mensen vertrekken naar een nieuwe functie en hun zwaarbevochten ervaring meenemen. "Een keer gebeten, twee keer verlegen" is een prachtige uitdrukking, maar het vereist wel dat je gebeten wordt, helaas - diepe zucht.

Wat wel duidelijk is, is dat procedures en standaarddocumentatie helaas ontbreken, en dat is jammer, want door hier vooraf in te investeren kan op de middellange tot lange termijn een fortuin worden bespaard. Een essentiële investering, zou je denken.

Bekijk hier meer artikelen, posts en discussies over zaken, projectmanagement, de menselijke natuur, Generatieve AI en Creatief Schrijven op Medium. Abonneer je op Medium als je dat nog niet hebt gedaan. Of volg me hier op Substack. De KodifyIT Substack nieuwsbrief is een door lezers ondersteunde publicatie. Als je nieuwe berichten wilt ontvangen en mijn werk wilt steunen, overweeg dan om je gratis of betaald te abonneren. Ik waardeer de steun; je zult er geen spijt van krijgen. 👍

Ik bied mijn lezers mijn verontschuldigingen aan voor sommige spellingen die volgens u onjuist zijn. Ik ben geboren en getogen in het Verenigd Koninkrijk, en dit is de spelling waar ik me prettig bij voel(Grammarly is er in ieder geval blij mee).