Was ik het of het team? Zo beschrijf je eerlijk je eigen bijdrage in een portfolio

De meeste waardevolle producten, campagnes, implementaties en processen ontstaan in teamverband.

Alleen het eindresultaat tonen vertelt nog niet welke rol een specifieke specialist werkelijk heeft gespeeld.

Voor iemand die een portfolio beoordeelt, is het verschil groot:

"Ik werkte aan het herontwerp van het afrekenproces"

is niet hetzelfde als:

"Ik leidde het onderzoek, ontwierp het nieuwe afrekenverloop, maakte het prototype en voerde gebruikerstests uit. Een apart frontendteam verzorgde de implementatie."

De tweede beschrijving maakt echte competenties zichtbaar zonder het werk van anderen kleiner te maken.

Dit probleem komt niet alleen voor in professionele portfolio's.

In wetenschappelijke publicaties bestaat onder andere CRediT - Contributor Role Taxonomy. Deze standaard beschrijft 14 soorten bijdragen en is ontwikkeld om transparanter te maken wie werkelijk verantwoordelijk was voor verschillende onderdelen van een werk. CRediT staat toe dat één persoon meerdere rollen heeft en dat één rol aan meerdere personen wordt toegewezen. Ook wordt aanbevolen dat bijdragers de aan hen toegewezen rollen kunnen controleren en bevestigen. [1]

CRediT is vooral bedoeld voor onderzoek en wetenschappelijke publicaties. Het is geen standaard voor professionele portfolio's. Het laat wel een belangrijk principe zien dat breder toepasbaar is: in plaats van de vage uitspraak "ik maakte deel uit van het project" kun je beter duidelijk aangeven wat je werkelijke bijdrage was.

Een goede beschrijving van een teamproject kan rond zes informatiepunten worden opgebouwd:

1. Projectcontext
2. Samenstelling en omvang van het team
3. Je eigen verantwoordelijkheid
4. Concrete acties en beslissingen
5. Werkproducten of bewijs
6. Het resultaat en de manier waarop het wordt toegeschreven

Het gaat niet om een lang rapport. Het gaat om het wegnemen van de belangrijkste onduidelijkheden.

Leg eerst uit waar het team werkelijk aan werkte.

Een korte beschrijving is voldoende:

• het probleem of doel,
• het type product of dienst,
• de globale schaal,
• belangrijke beperkingen,
• de uitvoeringsperiode, als die relevant is.

Voorbeeld:

Het doel van het project was om het aankoopproces in een B2B-applicatie te verkorten. Het product was actief in meerdere Europese markten en bediende zakelijke klanten.

Zo begrijpt de lezer de context voordat de individuele bijdrage wordt beoordeeld.

Je hoeft niet iedere persoon met naam te noemen.

In veel gevallen is een eenvoudige structuur voldoende:

Team: productmanager, ontwerper van gebruikerservaring, 2 frontendontwikkelaars, 2 backendontwikkelaars en een kwaliteitsspecialist.

Deze ene informatie verandert hoe de hele projectbeschrijving wordt geïnterpreteerd.

De lezer ziet dat het resultaat niet op zichzelf is ontstaan en dat de specialist binnen een duidelijke verdeling van verantwoordelijkheden werkte.

Dit is het belangrijkste onderdeel.

In plaats van het algemene:

"ik werkte aan de frontend"

schrijf je concreet:

"ik was verantwoordelijk voor de architectuur van de betaalmodule, de implementatie van het afrekenproces, de integratie met de betaal-API en de codecontrole van wijzigingen in dit gebied."

Het kan ook nuttig zijn om te zeggen wat je niet hebt gedaan als dat anders onduidelijk zou zijn:

"de serverlaag en de serverintegratie met de betaalprovider werden door een apart team uitgevoerd."

Dat maakt je portfolio niet zwakker. Het maakt het geloofwaardiger.

Een functietitel is nog geen beschrijving van je bijdrage.

Een senior ontwerper van gebruikerservaring kan in het ene project het hele onderzoeksproces leiden en in een ander project alleen de uiteindelijke schermen maken.

Laat daarom acties zien die aan concrete competenties gekoppeld kunnen worden:

• ik ontwierp de oplossingsarchitectuur,
• ik voerde onderzoek uit,
• ik ontwierp het procesverloop,
• ik analyseerde gegevens,
• ik schreef een belangrijk deel van de implementatie,
• ik ontwikkelde de campagnestrategie,
• ik leidde onderhandelingen,
• ik coördineerde afhankelijkheden tussen teams,
• ik controleerde de oplossing vóór de uitrol.

De waardevolste voorbeelden zijn die waarin je ook kunt uitleggen waarom een bepaalde beslissing is genomen.

Als het project getoond mag worden, helpt een werkproduct om de beschreven bijdrage aan echt werk te koppelen.

Bijvoorbeeld:

• een productscherm,
• een deel van de interface,
• een prototype,
• een codefragment,
• een openbare repository,
• een rapport,
• een diagram,
• een publicatie,
• campagnemateriaal,
• een foto,
• een document of een veilig te tonen fragment.

Een werkproduct hoeft niet alles te bewijzen. Het moet de lezer helpen begrijpen wat er werkelijk is gemaakt en hoe dat samenhangt met de beschreven bijdrage.

Het grootste risico op overschatting van je eigen bijdrage ontstaat bij het beschrijven van resultaten.

Als de conversie van een bedrijf na een project met 25% stijgt, betekent dat niet automatisch dat één persoon de conversie met 25% heeft verhoogd.

In dezelfde periode kunnen ook andere zaken zijn veranderd:

• prijzen,
• het aanbod,
• marketing,
• gebruikerservaring,
• infrastructuur,
• seizoenseffecten,
• verkeersbronnen,
• het werk van andere teamleden.

Beschrijf het resultaat alleen met het niveau van zekerheid dat je werkelijk kunt onderbouwen.

1. Directe verantwoordelijkheid
"Ik verkortte de doorlooptijd van dit proces van 12 naar 4 minuten door de stappen waarvoor ik verantwoordelijk was te automatiseren."

Gebruik dit wanneer het verband tussen je eigen actie en het resultaat direct en onderbouwbaar is.

2. Gezamenlijk resultaat
"Samen met het team hebben we het gebruikersintroductieproces opnieuw ontworpen. Na de uitrol steeg het voltooiingspercentage met 18%."

Gebruik dit wanneer het resultaat door het werk van meerdere mensen tot stand kwam.

3. Bijdrage aan een bredere verandering
"Ik was verantwoordelijk voor het herontwerp van het afrekenproces als onderdeel van een bredere optimalisatie van het aankoopproces. Na de uitrol van het hele programma zag het bedrijf een hogere conversie."

Gebruik dit wanneer jouw gebied slechts één van meerdere factoren was.

4. Resultaat als projectcontext
"Het project eindigde met 40% omzetgroei. Mijn werk omvatte de clientarchitectuur en de implementatie van het afrekenproces."

Gebruik dit wanneer je het totale projectresultaat kent, maar geen goede basis hebt om vast te stellen welk deel daarvan door jouw werk kwam.

Wanneer een project meerdere personen toont, moet de beste beschrijving twee vragen tegelijk beantwoorden:

Wat heeft het team opgeleverd?

en

Waarvoor was iedere persoon verantwoordelijk?

Voorbeeld:

Project: eerste versie van een logistieke applicatie
Team: ontwerper van gebruikerservaring, frontendontwikkelaar, backendontwikkelaar
Gezamenlijk resultaat: werkende eerste productversie klaar voor een proefproject
Ontwerper van gebruikerservaring: onderzoek, gebruikersreis, prototype, interfaceontwerp
Frontendontwikkelaar: clientarchitectuur, implementatie van de webapplicatie
Backendontwikkelaar: API, gegevensmodel, integraties

Zo'n projectbeschrijving versterkt zowel het team als de individuele specialisten.

In sommige projecten zijn eenvoudige aanduidingen voor de mate van betrokkenheid nuttig:

Leidende rol - ik leidde het gebied en was verantwoordelijk voor belangrijke beslissingen.
Gedeelde verantwoordelijkheid - ik deelde de verantwoordelijkheid met één of meer andere personen.
Ondersteunende rol - ik ondersteunde het gebied, maar was niet de hoofdverantwoordelijke.

CRediT gebruikt een vergelijkbaar onderscheid voor bijdragerrollen. [1]

Het belangrijkste principe is eenvoudig: het niveau van verantwoordelijkheid moet begrijpelijk zijn.

Bij belangrijke gezamenlijke projecten is het verstandig om te controleren of je beschrijving van je eigen bijdrage niet duidelijk botst met hoe andere deelnemers de rollen begrijpen.

CRediT raadt aan dat bijdragers de aan hen toegewezen rollen kunnen beoordelen en bevestigen. [1]

In een professioneel portfolio hoeft dit geen formeel goedkeuringsproces voor iedere zin te zijn. De praktische regel is eenvoudiger: claim geen verantwoordelijkheid voor werk dat in werkelijkheid door iemand anders werd geleid.

Het beschrijven van je eigen bijdrage mag niet worden verward met het bepalen van auteursrechten.

Volgens het Poolse auteursrecht behoort het auteursrecht in beginsel toe aan de maker en wordt het door medemakers gezamenlijk gehouden. Bij werken die in dienstverband zijn gemaakt, kan de werkgever economische auteursrechten verwerven binnen de grenzen die door de wet en de arbeidsverhouding worden bepaald. [2]

Behandel in de praktijk drie vragen afzonderlijk:

Heb ik meegewerkt aan het creëren van het project?
Ben ik maker of medemaker van een specifiek onderdeel?
Heb ik het recht om het materiaal in mijn portfolio te publiceren?

Een "ja" op de eerste vraag bepaalt niet automatisch de antwoorden op de andere twee.

Niet ieder project mag worden getoond of in detail worden beschreven.

Het Poolse recht inzake oneerlijke concurrentie beschermt informatie die een bedrijfsgeheim vormt, waaronder bepaalde technische, technologische, organisatorische en andere informatie met economische waarde die vertrouwelijk wordt gehouden. [3]

Bij een vertrouwelijk project is alleen de naam van de klant verwijderen daarom mogelijk onvoldoende. Andere details kunnen nog steeds beschermde informatie onthullen.

Een veiligere regel is:

beschrijf alleen wat je op grond van het toepasselijke recht, contracten, toestemmingen en andere rechten waarover je beschikt werkelijk mag bekendmaken.

Een projectbeschrijving heeft meestal geen privégegevens van het hele team nodig.

De AVG vereist onder meer rechtmatigheid, doelbinding en minimale gegevensverwerking. Persoonsgegevens moeten dus beperkt blijven tot wat voor het betreffende doel noodzakelijk is. [4]

Als deze beschrijving voldoende is:

1 ontwerper van gebruikerservaring, 2 frontendontwikkelaars, een backendontwikkelaar en een kwaliteitsspecialist

is er geen automatische reden om namen, foto's, e-mailadressen of andere persoonsgegevens van collega's te publiceren.

Als je een aanbeveling, verklaring, afbeelding of andere gegevens van een specifieke persoon wilt publiceren, controleer dan de juiste rechtsgrond en de toegestane omvang van het gebruik.

Als de voorwaarden van de samenwerking een algemene beschrijving van de ervaring toestaan, kun je overwegen om het volgende te tonen:

• het soort probleem zonder de klant te identificeren,
• je eigen rol,
• categorieën van gebruikte competenties,
• het type verantwoordelijkheid,
• het besluitvormingsproces op een passend algemeen niveau,
• het resultaat alleen voor zover dat bekendgemaakt mag worden.

Verzin geen schermafbeeldingen, gegevens of resultaten om vertrouwelijk materiaal te vervangen.

Als je niet zeker weet of bepaalde informatie openbaar mag worden gemaakt, is het veiliger die niet te publiceren totdat dit is opgehelderd.

Kleine verschillen in formulering kunnen het verantwoordelijkheidsniveau heel duidelijk maken.

Ik was verantwoordelijk voor... - wijst je eigen gebied duidelijk toe.
Ik leidde... - duidt verantwoordelijkheid voor richting of uitvoering van een bepaald gebied aan.
Ik werkte mee aan... - laat zien dat het resultaat meerdere makers had.
Ik ondersteunde... - beschrijft eerlijk een ondersteunende bijdrage.
Ik maakte deel uit van het team dat... - scheidt individuele deelname van het totale teamresultaat.
Na de uitrol van het project registreerde het bedrijf... - toont het resultaat als context zonder automatisch het hele effect te claimen.

Vermijd automatisch "ik heb het gedaan" wanneer de werkelijke omvang gedeeld was.

1. Je gebruikt de enkelvoudsvorm voor een project dat door veel mensen is uitgevoerd.

2. Je toont een bedrijfsresultaat zonder je eigen omvang uit te leggen.

3. Je noemt technologieën van het hele product als je eigen competenties terwijl je niet met alle technologieën hebt gewerkt.

4. Je toont het uiteindelijke visuele ontwerp, code of strategie zonder aan te geven welke delen je werkelijk hebt gemaakt.

5. Je laat belangrijke bijdragers weg terwijl hun deelname nodig is om het project te begrijpen.

6. Je suggereert een oorzakelijk verband tussen je werk en een resultaat dat je niet kunt onderbouwen.

Project
Wat werd er gemaakt en welk probleem moest worden opgelost?

Team
Welke rollen namen deel aan het project?

Mijn verantwoordelijkheid
Voor welk gebied was ik persoonlijk verantwoordelijk?

Mijn acties en beslissingen
Wat heb ik concreet gedaan of geleid?

Samenwerking
Welke onderdelen zijn samen met anderen gemaakt?

Werkproducten
Wat mag ik juridisch tonen?

Resultaat
Wat heeft het project bereikt en hoe hield mijn bijdrage verband met dat resultaat?

Beperkingen
Zijn er onderdelen die ik vanwege vertrouwelijkheid of rechten van anderen niet mag bekendmaken?

Stel jezelf zeven vragen:

1. Weet de lezer hoe groot het team was?

2. Is precies duidelijk waarvoor ik verantwoordelijk was?

3. Heb ik vermeden om werk van anderen aan mezelf toe te schrijven?

4. Is het resultaat met voldoende voorzichtigheid beschreven?

5. Mag ik de gebruikte materialen juridisch publiceren?

6. Vermijd ik onnodige bekendmaking van persoonsgegevens of vertrouwelijke informatie?

7. Kan een buitenstaander uit deze beschrijving afleiden welke competenties ik werkelijk heb gebruikt?

Als de antwoorden duidelijk zijn, wordt de projectbeschrijving bewijs van competentie in plaats van alleen een aantrekkelijk verhaal.

De beste projectbeschrijving hoeft niet te kiezen tussen:

"ik heb dit gedaan"

en

"het team heeft dit gedaan."

Ze kan beide waarheden tegelijk laten zien:

het team leverde een concreet resultaat en ik was verantwoordelijk voor een specifiek onderdeel, beslissingen en uitvoering.

Dat niveau van precisie maakt het mogelijk een specialist te beoordelen zonder anderen hun verdienste af te nemen.

Een portfolio moet geen wedstrijd zijn om de grootst mogelijke claim.

De waarde ervan groeit wanneer de lezer kan begrijpen:

wat er is gemaakt, wie eraan heeft gewerkt, waarvoor je verantwoordelijk was, wat je persoonlijk hebt gedaan en welk resultaat redelijkerwijs aan je bijdrage kan worden gekoppeld.

Een precieze beschrijving maakt een prestatie niet kleiner.

Integendeel. Ze laat zien dat je je eigen verantwoordelijkheid begrijpt, met anderen kunt samenwerken en de resultaten van je werk eerlijk kunt presenteren.

[1] CRediT - Contributor Role Taxonomy, NISO
Bron openen

[2] Poolse wet op auteursrecht en naburige rechten - art. 8-12, ELI
Bron openen

[3] Poolse wet ter bestrijding van oneerlijke concurrentie - art. 11, geconsolideerde tekst gepubliceerd in 2026
Bron openen

[4] Verordening (EU) 2016/679 - AVG, art. 5, EUR-Lex
Bron openen

Methodologische toelichting: CRediT is een standaard voor bijdragerrollen in onderzoek en wetenschappelijke publicaties. Dit artikel gebruikt het als voorbeeld van transparante toeschrijving van bijdragen, maar presenteert het niet als standaard voor professionele portfolio's. De zes elementen van een projectbeschrijving en de vier manieren om de relatie met resultaten te beschrijven vormen een redactioneel model dat in dit materiaal wordt voorgesteld.