Zoals iedereen weet: Analisten zijn nutteloos! Iedereen weet dat analisten technische schrijvers zijn en niet nadenken. Ze schrijven alleen wat de klant wil en zeggen overal "ja" op, zelfs als het niet logisch is of niet kan worden geïmplementeerd. Ze schrijven alleen wat het technische team denkt en definieert. Zoals iedereen weet, zijn analisten alleen analisten omdat ze slechte ontwikkelaars zijn of verwant aan iemand die heel belangrijk is in de organisatie, zoals een vader, neef of vriend.
En wat als analisten ook testers zijn? Kan het nog erger? Ze verknoeien het gewoon. Ze weten niet wat het systeem doet en proberen vreemde dingen te maken. Soms denken ze dat er bugs in het systeem zitten, maar, zoals iedereen weet, bugs bestaan niet, alleen features... en waarschijnlijk bestaat de feature alleen omdat de requirements niet compileren. Als ze een feature vinden (het zijn net demonen!), melden de analisten het met minder dan tien woorden, zodat de ontwikkelaars het probleem minstens vijf keer kunnen heropenen, omdat ze het probleem niet begrijpen of het probleem zich niet voordoet op hun machines.
Zoals iedereen weet weten analisten en testers niets van databases, geïntegreerde systemen of architectuur omdat het "te technisch" is. En iedereen weet dat ze nooit en te nimmer toegang mogen hebben tot databases, de broncode mogen raadplegen of zelfs maar mogen debuggen!

Ongeacht al deze feiten erkennen de meesten van ons dat een project iemand nodig heeft om het ontwikkelingsteam te helpen de behoeften van de klant te begrijpen. Nou, en wat als we iemand vinden die echt kan helpen? Iemand die dat kan:
- Leer over het bedrijf van de klant, analyseer de huidige toestand/omgeving om te ontdekken waarom een verandering nodig is (wat hij echt nodig heeft en niet wat hij denkt nodig te hebben).
- Begrijp wat waarde kan opleveren voor het bedrijf en bepaal de manier om aan die bedrijfsbehoefte te voldoen.
- Samen met het technische team business cases bouwen met mogelijke oplossingen.
- De definitie van een mogelijke architectuur voor het systeem ondersteunen.
- Eliceer eisen met de juiste belanghebbenden en bevestig ze vóór de implementatie.
- Definiëren en modelleren van mogelijk te ontwikkelen eisen.
- Evalueer de impact en implicaties van de voorgestelde eisen en ontwerpwijzigingen voordat u het ontwikkelingsteam vraagt ze uit te voeren.
- Het ontwikkelingsteam ondersteunen bij het specificeren van de technische oplossing en hen helpen bij het organiseren van de documentatie.
- Specificeer een oplossing met het juiste detailniveau, zodat zowel het ontwikkelingsteam als de klant de oplossing kan begrijpen.
- Specificeer een oplossing waarin elke functie afzonderlijk en geïntegreerd in het systeem als geheel zinvol is.
- Het ontwikkelingsteam kunnen volgen en ondersteunen.
- Definieer de juiste tests om snel de defecten te vinden die de opleveringswaarde het meest beïnvloeden.
- Rapporteer problemen met voldoende details om het probleem te reproduceren, raadpleeg de database, systeemlogboeken, broncode of zelfs debug, en help het ontwikkelingsteam het probleem te begrijpen.
Als organisaties in elk project iemand met dit profiel zouden hebben, zouden zij meer waarde aan de klant kunnen leveren met minder ontwikkelingsinspanning - zijn zij zich hiervan bewust? Wel, Polarising erkent dat competente analisten en testers essentieel zijn voor het slagen van projecten. Wij zorgen ervoor dat het project de maximale waarde oplevert en tegelijkertijd helpen we klanten om hun ontwikkelingskosten te verlagen. Bij Polarising is het mogelijk om deze competenties intern op te bouwen en te ontwikkelen omdat we de relevantie ervan voor onze klanten erkennen. Dus, iedereen hier weet... Analisten kunnen echt het verschil maken!


Goed gedaan Márcia!
Ik werk elke dag met analisten, ik geloof dat analisten een kritische factor zijn voor een succesvol project.