Om meteen maar met de deur in huis te vallen: de techniek die je toepast om requirements te modelleren en te structureren is volstrekt en totaal oninteressant voor eindgebruikers en andere belanghebbenden.
Autsj! Het doet natuurlijk zeer om te lezen dat de techniek die jij gebruikt niet interessant zou zijn. Je gelooft immers in je techniek en je weet dat het werkt. En goed ook! Dus wie is Mirjam om te zeggen dat belanghebbenden niet geïnteresseerd zouden zijn in deze techniek. Want use cases werken! User stories werken! Het piramidemodel werkt! De template werkt! En dat is ook zo.
Maar het gaat er hier niet om of de techniek werkt, het gaat er om wat je erin stopt. En daar gaat het vaak al mis. Je kunt de kwaliteit van requirements vergelijken met de kwaliteit van een bosje geplukte bloemen dat je naar je moeder wilt versturen. Dit kun je laten doen met een auto, een scooter of achter op een fiets. Maar als je geen verse bloemen hebt geplukt komen ze natuurlijk ook nooit vers aan, ook al is je vervoermiddel nog zo goed of nog zo snel.
‘The purpose of analysis is not modeling, but understanding.’ – Sun Tsu
Eindgebruikers en andere belanghebbenden willen goed begrepen worden. Ze willen dat je in gesprekken met hen de goede vragen stelt en goed naar hen luistert. En dat willen ze terugzien in de resultaten die de oplossing levert. Dat je daarvoor hun informatie eerst in model A, B of C vertaalt is voor hun bijzaak.
Staar je dus in gesprekken met belanghebbenden over hun requirements niet blind op het middel of de verpakking, maar focus je vooral op de vaardigheden die nodig zijn om kwalitatief goede informatie te achterhalen: luisteren en doorvragen. Concentreer je op het minimaliseren van mogelijke aannames en misverstanden, want uiteindelijk geldt kwaliteit in = kwaliteit uit! En hoe minder requirements ruimte laten voor interpretatieverschillen hoe minder onnodig en kostbare tijd wordt verloren aan herstelwerkzaamheden.
Je reactie is van harte welkom!
Correct verhaal. Beschrijft echt een groot probleem. Maarrrrr…… De oplossing kan simpel zijn. Uiteraard is het afhankelijk van de situatie. Een beheersituatie geeft requirements die vaak beter / eenvoudiger zijn te omschrijven in een gewenst detail. Gebruikers kennen de huidige situatie, merken wat ze missen en hoeven dan maar kort na te denken over hoe ze dit willen gaan gebruiken. In deze situatie moet naar mijn mening dus niet de analist gaan beschrijven en allerlei technieken en templates gaan gebruiken, maar de gebruiker / klant. Met support van de analist en een simpele techniek en template. Bij een project waarin iets nieuws ontwikkelt gaat worden is dit niet zo eenvoudig, maar kan het zeker gebruikt worden voor de meer essentiële / gevoelige delen i.c.m. materiedeskundigen vanuit de klant / gebruiker. Mijn vraag is dan ook gerelateerd aan dit artikel waarom moet altijd de IT-er “er iets in stoppen”. De klant / gebruiker is eigenaar van dit probleem! Niet de IT-er. Dus laat die klant / gebruiker zijn verantwoording oppakken en laat het niet liggen aan de ondervragingstechnieken van een analist. In de praktijk heb ik dit toegepast en het werkt echt!!!
Het verhaal van Mirjam is volgens mij juist. Ik zie de analist echter (in tegenstelling tot CK) als de brug tussen business-wensen en IT-mogelijkheden. Natuurlijk vergt het de nodige vaardigheden van de analist die het gesprek met de business voert. Het is dan ook een vak waarin eisen gesteld worden aan de professional! Andersom is het ook zo dat een business analist alleen een goede analyse kan maken als deze aansluit bij de IT-mogelijkheden. Niemand zit te wachten op onhaalbare sprookjes, da’s net zo erg als een systeem dat niet doet wat business wenst.
En modellen? Gebruik een model dat te snappen is door users en door IT-ers, welk model is niet van belang.
Het verhaal is wel okay (want het staat vol met open deuren), maar de titel is gewoon vreemd. Om met de vergelijking mee te gaan, zou de titel kunnen zijn: “Auto’s zijn niet interessant voor het vervoer van verse bloemen.” Ook vreemd.
Tekstuele requirements, specificaties en testgevallen: ze schieten over het algemeen tekort als het gaat om volledigheid en eenduidigheid. Maar verhalende teksten zijn wel uitermate geschikt om de idee erachter of gevoel voor de context te schetsen. Daarnaast gebruik je dan tooling om de requirements verder uit te werken. Laatst heb ik de tooling van Usoft gezien: URequire. Dit helpt je echt om requirements goed te specificeren en te controleren. De tool geeft allerlei cross checks en maakt het mogelijk om door te linken naar bestaande definities en beweringen.
De combinatie van tekstuele informative aangevuld met gecontroleerde definities en beweringen geeft wat mij betreft een compleet en met de klant af te stemmen geheel.
Tekst én techniek zijn wat mij betreft beide nodig om een juiste vertaling tussen business en IT te kunnen maken.
Door met een SCRUM team te werken, dus met een product owner erbij, die ook eindverantwoordelijk is voor de product backlog, krijg je voor elkaar wat CK voorstelt. In user stories kunnen dan in mensentaal door deze product owner de requirements worden aangegeven. Naar mijn mening is dan altijd nog een business analist nodig die dit vertaalt naar IT-requirements. Door middel van workshops kan de product owner de user stories uitleggen, en kan er via discussie met de juiste stakeholders (business analist, informatie analist, architect) tot een goede IT-oplossing gekomen worden. Hoe deze oplossing daarna beschreven wordt is voor de product owner inderdaad niet direct interessant, maar voor de developers, beheerorganisatie, etc. natuurlijk wel, en dan is een standaard daarvoor (welke dan ook, al vind ik use cases nog steeds een heel goede, ook omdat dit zeer handig is voor testers) toch wel aan te bevelen, om te voorkomen dat iedereen het op zijn eigen manier doet.
Oude en bekende misvatting.. maar inderdaad, wat interesseert die klant het nou welke techniek of methodiek je hanteert?
Als het maar werkt en op de manier zoals zij het willen.
Het zijn alleen mede-IT-ers die warm lopen voor wat voor techniek of methodiek je toegepast heb.
Het is een oude wijsheid dat de methode maximaal zo goed is als de kwaliteiten van degene die hem hanteert. Alle gereedschap is slechts een hulpmiddel, maar we moeten wel begrijpen dat we niet zonder kunnen. Modelleren is een hulpmiddel om te structuren en te begrijpen en dat is weer ondersteunend om nieuwe vragen te stellen. In die zin kan het een niet zonder het ander.
Tja een oude wijsheid.. reken niet teveel op wat op schrift staat… men kan namelijk toch niet goed schrijven.. en dat geeft weer niets, want lezen kan men ook niet..
Ofwel .. het bevestigd alweer mijn standpunt dat je je dus als bouwer dus goed moet verdiepen in de achterliggende wensen en eisen en vervolgens liefst in een iteratief ontwikkelproces waarbij gebruikers en andere slachtoffers van het systeem worden betrokken om de nuttigheid van het systeem te waarborgen.
Ja je zal iets moeten plannen vooraf, maar niet tot op de diepste details. Gun het resultaat wat iteraties en de gebruikers zullen tevredener met het resultaat werken.