Wanneer u een wijziging wilt aanbrengen of iets nieuws wilt introduceren dient u, hoe simpel ook, de requirements te analyseren. Wat moet er veranderen? Wat is het dat u wilt? Wat is het dat u nodig heeft? Hoe past de wijziging in het grotere geheel. IMHO maakt het niet uit of je een nieuw samenwerkingsplatform voor een internationaal bedrijf wilt implementeren, een simpel reserveringssysteem wilt aanpassen of dat je wat extra shaduw in je tuin wilt hebben. Je start altijd met het analyseren van de requirements.

Wanneer je behoefte hebt aan wat extra shaduw in je tuin dan zou je er voor kunnen kiezen om een extra boom te planten. Misschien was het toch beter geweest om vooraf wat onderzoek te doen voordat je die nieuwe general sherman[1] had gepland. Waarschijnlijk de grootste boom ter wereld – ongeveer 80 meter hoog. Aan shaduw geen gebrek. Het is slechts een kwestie van perspectief

Hetzelfde geld natuurlijk voor ons werk: zorg voor het juiste perspectief.

Pug Perspective

Wanneer je alleen naar het voorgeschotelde probleem kijkt, en dan ook nog eens met een technische bril, dan is de oplossing vaak erg simpel. Wanneer je het probleem vanuit het grotere geheel dan kan alles heel snel veel complexer worden.

Voorbeeld: Medewerkers klagen dat het bijhouden van reservering erg omslachtig is. Het blijkt dat ze een Excel document moeten openen, een record toevoegen, Excel opslaan en afsluiten en mailen naar de volgende afdeling enzovoorts.

Op basis van jouw perspectief zou je kunnen voorstellen om een SharePoint list te gebruiken in combinatie met alerts. Je zou kunnen stellen dat dit een goede oplossing is. Je zou ook kunnen stellen dat deze oplossing helemaal niet goed (genoeg) is. Dit ligt waarschijnlijk aan het perspectief.

Perspective-boat-land

Gebaseerd op de geschetste requirements is de oplossing goed (genoeg). Vanuit een applicatie architectuur perspectief, gezien dat er al een dozijn van dergelijke oplossingen gerealiseerd zijn gebruik makend van PowerApps eventueel in combinatie met Microsoft Flow die gebruik maken van een Azure database zou je kunnen stellen dat de oplossing niet (genoeg) is. Vanuit een solution- of enterprise architectuur pespectief zou je misschien zelfs kunnen stellen dat de oplossing verschrikkelijk is….of perfect.

De les die ik wil overbrengen

Geef voldoende aandacht aan het analyseren van alle requirements. Val niet in de quick-and-dirty val: “Dit lossen we wel eventjes op!” Probeer het gestelde probleem vanuit meerdere invalshoeken te bekijken. Van applicatie- tot solution architectuur. Van data- tot bedrijfsarchitectuur. Probeer het ook vanuit het perspectief van de ontvanger te bekijken. De laatste tip: ik zelf vraag altijd,  yep altijd,  een peer-review. Misschien was een parasol wel voldoende geweest 🙂

[1] https://www.nps.gov/seki/learn/nature/sherman.htm

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.