...

Voor het project heb ik de rol kwaliteitsmanager op me genomen. Zoals omschreven in het plan van aanpak "Eindverantwoordelijke voor de kwaliteit van het project. Belangrijke rol bij de code reviews.". In de functie-omschrijving van een kwaliteitsmanager (https://nl.indeed.com/personeel/functiebeschrijving/kwaliteitsmanager) staat dat de kwaliteitsmanager de bedrijfsprocessen gaat monitoren die invloed hebben op de kwaliteit van een product. Hierbij hoort het uivoeren uitvoeren van kwaliteitsanalyses en het voorzien van kwaliteitsverbeteringen aan de implementatie. Ik wil er tijdens dit project erachter achter komen hoe de rol als kwaliteitsmanger betrekking tot mijn rol is

Wat beter kon bij het uitvoeren van de rol als kwaliteitsmanager

Opstellen van API documentatie STARR formulier, heeft effect want er staat vast hoe een endpoint is opgebouwd en hoe deze gebruikt kan worden. Wat kwaliteitsmanager invloed heeft op de uiteindelijke implementatie. Om dit doel te behalen heb ik het leerdoel dat te lezen is in §6.2 opgesteld. De situatiebeschrijving ... beschrijft hoe ik aan mijn leerdoel heb gewerkt en tevens komt hier mijn rol als kwaliteitsmanager naar voor. Het opstellen van deze documentatie heeft een positief effect op de verdere werkzaamheden. Wat verbeterd kan worden is dat de API documentatie niet mee is genomen tijdens het reviewen. Met als gevolg dat er van enkele endpoints geen documentatie beschikbaar is. Wat ik de volgende keer anders ga doen is ervoor zorgen dat de documentatie onderdeel wordt van de taak. Door het als verplicht onderdeel op te nemen is het nodig dat er een review komt. Door ervoor te zorgen dat er een review komt vinden de groepsleden mogelijke fouten en of gebrekken in de documentatie.

STARR Opstellen van API documentatie

Tijdens het coderen van de verlof aanvragen kwam ik erachter dat de gegevens die de backend nodig heeft anders zijn dan de gegevens uit de wireframes. Hierdoor is het nodig om een van de implemtaties aan te passen. Na overleg is besloten om de backend aan te passen zodat het overeenkomt met de gegevens uit de wireframes. Om te voorkomen dat er zulke misverstanden zich voordoen ben ik een voorbeeld API documentatie gaan uitwerken. Zodat er vooraf afspraken worden vastgelegd over de nodige data om misverstanden te voorkomen en dus tijd te besparen. Na het toelichten van de documentatie waren de groepsgenoten het ermee eens om het op deze manier aan te pakken. Dit heeft gewerkt omdat er nu voor alle endpoints documentatie beschikbaar is en er misverstanden zijn voorkomen. Ik ga bij volgende projecten waarin een API nodig is ook deze documentatie opstellen met ook de reden dat er zo overzicht blijft en er geen misverstanden ontstaan.

Onderdeel is niet af voor het TT verslag

Onderdeel 5) Project rollen

A) ideaal vs. praktijk

B) Leerproces omschrijven rondom de rol; Wat kan beter; Wat wil je leren in je rol

C) Situatiebeschrijving STARRT; Overal waar situatie staat. maak een STARRT formulier, dus volgens Sjir worden het er wel ongeveer 6 bij het eindverslag

Tijdens dit project heb ik geleerd dat, een kwaliteitsmanager stevig in zijn schoenen moet staan. Want het is nodig om aan te geven dat onderdelen niet voldoen aan de eisen, daarnaast is het ook nodig om daarop te anticiperen en daardoor een ander teleur moet stellen omdat er werk aangepast moet worden of extra werkzaamheden toewijzen om aan de eisen te voldoen. Ik merk dat een kwaliteitsmanager de conflicthanteringsstijlen (https://www.icm.nl/extra/5-conflictstijlen-thomas-kilmann-omgaan-conflicten/) doordrukken, samenwerken en compromis sluiten toe moet passen. Doordrukken omdat het nodig is om met deze rol op te komen voor de kwaliteit en daarom andere erop aan spreken, ook als er andere groepsgenoten het er niet mee eens zijn. De stijl compromis sluiten en samenwerken hangen sterk samen met doordrukken omdat het beter werkt om als team tot een oplossing te komen, in plaats van een oplossing door te drukken. Uit de volgende bron (https://www.ag5.com/nl/samenwerken-binnen-een-team-tips/) blijkt dat het nodig is om met elkaar in overleg te gaan over de kwaliteit en elkaar daarop aanspreken, want als dit niet wordt gedaan lever je zelden het best mogelijke resultaat.

STARR Opstellen van API documentatie

Tijdens het coderen van de verlof aanvragen kwam ik erachter dat de gegevens die de backend nodig heeft anders zijn dan de gegevens uit de wireframes. Hierdoor is het nodig om een van de implemtaties aan te passen. Na overleg is besloten om de backend aan te passen zodat het overeenkomt met de gegevens uit de wireframes. Om te voorkomen dat er zulke misverstanden zich voordoen ben ik een voorbeeld API documentatie gaan uitwerken. Zodat er vooraf afspraken worden vastgelegd over de nodige data om misverstanden te voorkomen en dus tijd te besparen. Na het toelichten van de documentatie waren de groepsgenoten het ermee eens om het op deze manier aan te pakken. Dit werkt omdat er nu API documentatie beschikbaar is en er misverstanden zijn voorkomen. Ik ga bij volgende projecten waarin een API nodig is ook deze documentatie opstellen met ook de reden dat er zo overzicht blijft en er geen misverstanden ontstaanStarrt mag in tabelvorm maar de voorkeur gaat uit naar een lopend verhaal.

Competenties

Onderdeel niet af voor het TT verslag

...