War ich es oder das Team? So beschreibst du deinen eigenen Beitrag im Portfolio ehrlich

Die meisten wertvollen Produkte, Kampagnen, Einführungen und Prozesse entstehen im Team.

Das Endergebnis allein zeigt noch nicht, welche Rolle eine bestimmte Fachkraft tatsächlich gespielt hat.

Für jemanden, der ein Portfolio bewertet, ist der Unterschied erheblich:

"Ich habe an der Neugestaltung des Kaufabschlusses gearbeitet"

ist nicht dasselbe wie:

"Ich habe die Recherche geleitet, den neuen Ablauf des Kaufabschlusses entworfen, den Prototyp erstellt und Usability-Tests durchgeführt. Die Implementierung übernahm ein separates Frontend-Entwicklungsteam."

Die zweite Beschreibung macht reale Kompetenzen sichtbar, ohne die Arbeit anderer abzuwerten.

Dieses Problem betrifft nicht nur berufliche Portfolios.

Im wissenschaftlichen Publizieren gibt es unter anderem CRediT - Contributor Role Taxonomy. Der Standard beschreibt 14 Arten von Beiträgen und wurde entwickelt, um transparenter zu machen, wer tatsächlich für einzelne Teile einer Arbeit verantwortlich war. CRediT erlaubt, einer Person mehrere Rollen und einer Rolle mehrere Personen zuzuordnen. Außerdem wird empfohlen, Mitwirkenden die Möglichkeit zu geben, die ihnen zugeordneten Rollen zu prüfen und zu bestätigen. [1]

CRediT richtet sich vor allem an Forschung und wissenschaftliche Publikationen. Es ist kein Standard für berufliche Portfolios. Es zeigt jedoch ein wichtiges Prinzip, das sich breiter anwenden lässt: Statt der ungenauen Aussage "Ich war Teil des Projekts" sollte die tatsächliche Art des eigenen Beitrags klar benannt werden.

Eine gute Beschreibung eines Teamprojekts lässt sich um sechs Informationen aufbauen:

1. Projektkontext
2. Zusammensetzung und Umfang des Teams
3. Eigene Verantwortung
4. Konkrete Handlungen und Entscheidungen
5. Arbeitsartefakte oder Nachweise
6. Ergebnis und dessen Zuordnung

Es geht nicht darum, einen langen Bericht zu schreiben. Es geht darum, die wichtigsten Unklarheiten zu beseitigen.

Erkläre zuerst, woran das Team tatsächlich gearbeitet hat.

Eine kurze Beschreibung reicht:

• Problem oder Ziel,
• Art des Produkts oder der Dienstleistung,
• ungefähre Größenordnung,
• wichtige Einschränkungen,
• Zeitraum der Umsetzung, falls relevant.

Beispiel:

Ziel des Projekts war es, den Kaufprozess in einer B2B-Anwendung zu verkürzen. Das Produkt war in mehreren europäischen Märkten aktiv und richtete sich an Geschäftskunden.

So versteht der Leser den Kontext, bevor er den individuellen Beitrag bewertet.

Du musst nicht jede Person namentlich nennen.

In vielen Fällen reicht eine Struktur wie:

Team: Produktmanager, UX-Designer, 2 Frontend-Entwickler, 2 Backend-Entwickler und ein Qualitätsspezialist.

Diese eine Information verändert die Interpretation der gesamten Projektbeschreibung.

Der Leser erkennt, dass das Ergebnis nicht isoliert entstanden ist und dass die Fachkraft in einer klaren Verantwortungsstruktur gearbeitet hat.

Das ist der wichtigste Teil.

Statt des allgemeinen:

"Ich habe am Frontend gearbeitet"

schreibe konkret:

"Ich war für die Architektur des Zahlungsmoduls, die Implementierung des Kaufabschlusses, die Integration mit der Zahlungs-API und die Codeprüfung der Änderungen in diesem Bereich verantwortlich."

Es kann auch sinnvoll sein zu sagen, was du nicht gemacht hast, wenn dies sonst unklar wäre:

"Die serverseitige Schicht und die serverseitige Integration mit dem Zahlungsanbieter wurden von einem separaten Team umgesetzt."

Das schwächt das Portfolio nicht. Es macht es glaubwürdiger.

Eine Stellenbezeichnung ist noch keine Beschreibung des Beitrags.

Ein Senior UX-Designer kann in einem Projekt den gesamten Forschungsprozess leiten und in einem anderen nur die finalen Ansichten vorbereiten.

Zeige daher Tätigkeiten, die sich mit konkreten Kompetenzen verbinden lassen:

• Ich entwarf die Lösungsarchitektur,
• ich führte Untersuchungen durch,
• ich entwarf den Prozessablauf,
• ich analysierte Daten,
• ich schrieb einen zentralen Teil der Implementierung,
• ich entwickelte die Kampagnenstrategie,
• ich führte Verhandlungen,
• ich koordinierte Abhängigkeiten zwischen Teams,
• ich prüfte die Lösung vor der Einführung.

Besonders wertvoll sind Beispiele, bei denen du erklären kannst, warum eine bestimmte Entscheidung getroffen wurde.

Wenn das Projekt gezeigt werden darf, hilft ein Artefakt dabei, den behaupteten Beitrag mit realer Arbeit zu verbinden.

Zum Beispiel:

• ein Produktbildschirm,
• ein Teil der Benutzeroberfläche,
• ein Prototyp,
• ein Codeausschnitt,
• ein öffentliches Repository,
• ein Bericht,
• ein Diagramm,
• eine Veröffentlichung,
• Kampagnenmaterial,
• ein Foto,
• ein Dokument oder ein sicherer Auszug daraus.

Ein Artefakt muss nicht alles beweisen. Es soll dem Leser helfen zu verstehen, was tatsächlich entstanden ist und wie es mit dem beschriebenen Beitrag zusammenhängt.

Das größte Risiko, den eigenen Beitrag zu übertreiben, entsteht bei der Darstellung von Ergebnissen.

Wenn die Konversionsrate eines Unternehmens nach einem Projekt um 25% steigt, bedeutet das nicht automatisch, dass eine einzelne Person die Konversion um 25% gesteigert hat.

Im selben Zeitraum könnten sich auch folgende Faktoren verändert haben:

• Preise,
• Angebot,
• Marketing,
• Nutzererlebnis,
• Infrastruktur,
• Saisonalität,
• Traffic-Quellen,
• Arbeit anderer Teammitglieder.

Beschreibe Ergebnisse nur mit dem Grad an Sicherheit, den du tatsächlich begründen kannst.

1. Direkte Verantwortung
"Ich habe die Dauer dieses Prozesses durch Automatisierung der von mir verantworteten Schritte von 12 auf 4 Minuten reduziert."

Nutze diese Form, wenn der Zusammenhang zwischen deiner eigenen Handlung und dem Ergebnis direkt und begründbar ist.

2. Gemeinsames Ergebnis
"Gemeinsam mit dem Team haben wir den Nutzer-Onboarding-Prozess neu gestaltet. Nach der Einführung stieg die Abschlussquote um 18%."

Nutze diese Form, wenn das Ergebnis durch die Arbeit mehrerer Personen entstanden ist.

3. Beitrag zu einer größeren Veränderung
"Ich war für die Neugestaltung des Kaufabschlusses als Teil einer umfassenderen Optimierung des Kaufprozesses verantwortlich. Nach Einführung des gesamten Programms verzeichnete das Unternehmen eine höhere Konversion."

Nutze diese Form, wenn dein Bereich nur einer von mehreren Einflussfaktoren war.

4. Ergebnis als Projektkontext
"Das Projekt endete mit einem Umsatzanstieg von 40%. Mein Aufgabenbereich umfasste die clientseitige Architektur und die Implementierung des Kaufabschlusses."

Nutze diese Form, wenn du das Gesamtergebnis des Projekts kennst, aber nicht fundiert bestimmen kannst, welcher Anteil auf deine Arbeit zurückzuführen ist.

Wenn ein Projekt mehrere Personen zeigt, sollte die beste Beschreibung zwei Fragen gleichzeitig beantworten:

Was hat das Team geliefert?

und

Wofür war jede Person verantwortlich?

Beispiel:

Projekt: erste Version einer Logistikanwendung
Team: UX-Designer, Frontend-Entwickler, Backend-Entwickler
Gemeinsames Ergebnis: funktionsfähige erste Produktversion für einen Pilotbetrieb
UX-Designer: Forschung, Nutzerweg, Prototyp, Oberflächendesign
Frontend-Entwickler: clientseitige Architektur, Implementierung der Webanwendung
Backend-Entwickler: API, Datenmodell, Integrationen

Eine solche Projektbeschreibung stärkt sowohl das Team als auch die einzelnen Fachkräfte.

In manchen Projekten helfen einfache Bezeichnungen des Beteiligungsgrads:

Führende Rolle - Ich leitete den Bereich und war für zentrale Entscheidungen verantwortlich.
Geteilte Verantwortung - Ich teilte die Verantwortung mit einer oder mehreren anderen Personen.
Unterstützende Rolle - Ich unterstützte den Bereich, war aber nicht hauptverantwortlich.

CRediT verwendet eine ähnliche Unterscheidung bei Mitwirkendenrollen. [1]

Das wichtigste Prinzip lautet: Der Grad der Verantwortung sollte verständlich sein.

Bei wichtigen gemeinsamen Projekten lohnt es sich zu prüfen, ob die Beschreibung deines eigenen Beitrags nicht offensichtlich im Widerspruch dazu steht, wie andere Beteiligte die Rollen verstehen.

CRediT empfiehlt, Mitwirkenden die Möglichkeit zu geben, die ihnen zugeordneten Rollen zu prüfen und zu bestätigen. [1]

In einem beruflichen Portfolio muss das kein formeller Freigabeprozess für jeden Satz sein. Die praktische Regel ist einfacher: Beanspruche keine Verantwortung für Arbeit, die tatsächlich von jemand anderem geführt wurde.

Die Beschreibung des eigenen Beitrags darf nicht mit der Bestimmung urheberrechtlicher Rechte verwechselt werden.

Nach polnischem Urheberrecht steht das Urheberrecht grundsätzlich dem Urheber zu; Miturhebern steht es gemeinsam zu. Bei im Arbeitsverhältnis geschaffenen Werken kann der Arbeitgeber wirtschaftliche Urheberrechte in dem durch Gesetz und Arbeitsverhältnis bestimmten Umfang erwerben. [2]

In der Praxis sollten drei Fragen getrennt behandelt werden:

War ich an der Erstellung des Projekts beteiligt?
Bin ich Urheber oder Miturheber eines bestimmten Elements?
Darf ich das Material in meinem Portfolio veröffentlichen?

Ein "Ja" auf die erste Frage entscheidet nicht automatisch über die beiden anderen.

Nicht jedes Projekt darf gezeigt oder ausführlich beschrieben werden.

Das polnische Gesetz gegen unlauteren Wettbewerb schützt Informationen, die ein Geschäftsgeheimnis darstellen, darunter bestimmte technische, technologische, organisatorische und andere wirtschaftlich wertvolle Informationen, die vertraulich gehalten werden. [3]

Bei einem vertraulichen Projekt reicht es daher nicht unbedingt, nur den Kundennamen zu entfernen. Andere Details können weiterhin geschützte Informationen offenlegen.

Eine sicherere Regel lautet:

Beschreibe nur das, was du aufgrund des anwendbaren Rechts, deiner Verträge, Einwilligungen und sonstigen Berechtigungen tatsächlich offenlegen darfst.

Eine Projektbeschreibung benötigt in der Regel keine privaten Daten des gesamten Teams.

Die DSGVO verlangt unter anderem Rechtmäßigkeit, Zweckbindung und Datenminimierung. Personenbezogene Daten sollen also auf das für den jeweiligen Zweck notwendige Maß beschränkt werden. [4]

Wenn zur Beschreibung des Teams genügt:

1 UX-Designer, 2 Frontend-Entwickler, ein Backend-Entwickler und ein Qualitätsspezialist

besteht kein automatischer Grund, Namen, Fotos, E-Mail-Adressen oder andere personenbezogene Daten der Kollegen zu veröffentlichen.

Wenn du ein Testimonial, eine Aussage, ein Bild oder andere Daten einer bestimmten Person veröffentlichen möchtest, prüfe die passende Rechtsgrundlage und den zulässigen Nutzungsumfang.

Wenn die Bedingungen der Zusammenarbeit eine allgemeine Beschreibung der Erfahrung erlauben, kannst du erwägen, Folgendes zu zeigen:

• die Art des Problems, ohne den Kunden zu identifizieren,
• deine eigene Rolle,
• Kategorien der eingesetzten Kompetenzen,
• die Art der Verantwortung,
• den Entscheidungsprozess in angemessen allgemeiner Form,
• das Ergebnis nur in dem Umfang, in dem es offengelegt werden darf.

Erfinde keine Screenshots, Daten oder Ergebnisse als Ersatz für vertrauliches Material.

Wenn du nicht sicher bist, ob eine bestimmte Information offengelegt werden darf, ist es sicherer, sie bis zur Klärung nicht zu veröffentlichen.

Kleine Unterschiede in der Formulierung können den Grad der Verantwortung sehr gut zeigen.

Ich war verantwortlich für... - ordnet den eigenen Bereich klar zu.
Ich leitete... - zeigt Verantwortung für Richtung oder Umsetzung eines bestimmten Bereichs.
Ich habe mitentwickelt... - zeigt, dass das Ergebnis mehrere Urheber hatte.
Ich unterstützte... - beschreibt einen unterstützenden Beitrag ehrlich.
Ich war Teil des Teams, das... - trennt die individuelle Beteiligung vom Gesamtergebnis des Teams.
Nach Einführung des Projekts verzeichnete das Unternehmen... - stellt das Ergebnis als Kontext dar, ohne den gesamten Effekt automatisch für sich zu beanspruchen.

Vermeide ein pauschales "Ich habe es gemacht", wenn der tatsächliche Umfang geteilt war.

1. Du verwendest die Einzahl für ein Projekt, das von vielen Personen umgesetzt wurde.

2. Du zeigst ein Geschäftsergebnis, erklärst aber deinen eigenen Umfang nicht.

3. Du führst Technologien des gesamten Produkts als eigene Kompetenzen auf, obwohl du nicht mit allen gearbeitet hast.

4. Du zeigst das finale visuelle Design, Code oder Strategie, ohne zu erklären, welche Teile du tatsächlich erstellt hast.

5. Du lässt wichtige Mitwirkende weg, obwohl ihr Beitrag für das Verständnis des Projekts notwendig ist.

6. Du suggerierst einen kausalen Zusammenhang zwischen deiner Arbeit und einem Ergebnis, den du nicht belegen kannst.

Projekt
Was wurde erstellt und welches Problem sollte gelöst werden?

Team
Welche Rollen waren am Projekt beteiligt?

Meine Verantwortung
Für welchen Bereich war ich persönlich verantwortlich?

Meine Handlungen und Entscheidungen
Was habe ich konkret getan oder geleitet?

Zusammenarbeit
Welche Elemente entstanden gemeinsam mit anderen?

Artefakte
Was darf ich rechtmäßig zeigen?

Ergebnis
Was hat das Projekt erreicht und wie hing mein Beitrag mit diesem Ergebnis zusammen?

Einschränkungen
Gibt es Elemente, die ich aus Gründen der Vertraulichkeit oder wegen der Rechte anderer nicht offenlegen darf?

Stelle dir sieben Fragen:

1. Weiß der Leser, wie groß das Team war?

2. Ist klar, wofür ich genau verantwortlich war?

3. Habe ich vermieden, mir die Arbeit anderer zuzuschreiben?

4. Ist das Ergebnis mit angemessener Vorsicht beschrieben?

5. Darf ich die verwendeten Materialien rechtmäßig veröffentlichen?

6. Veröffentliche ich keine unnötigen personenbezogenen oder vertraulichen Informationen?

7. Könnte eine außenstehende Person aus dieser Beschreibung erkennen, welche Kompetenzen ich tatsächlich eingesetzt habe?

Wenn die Antworten klar sind, wird die Projektbeschreibung zu einem Kompetenznachweis und nicht nur zu einer attraktiven Geschichte.

Die beste Projektbeschreibung muss nicht zwischen zwei Aussagen wählen:

"Das habe ich gemacht"

und

"Das hat das Team gemacht."

Sie kann beide Wahrheiten gleichzeitig zeigen:

Das Team hat ein bestimmtes Ergebnis geliefert, und ich war für einen konkreten Teil, Entscheidungen und die Umsetzung verantwortlich.

Diese Präzision ermöglicht es, eine Fachkraft zu beurteilen, ohne anderen Beteiligten ihre Leistung zu nehmen.

Ein Portfolio sollte kein Wettbewerb um die größtmögliche Behauptung sein.

Sein Wert steigt, wenn die andere Seite verstehen kann:

Was wurde geschaffen, wer hat daran gearbeitet, wofür warst du verantwortlich, was hast du persönlich getan und welches Ergebnis lässt sich vernünftig mit deinem Beitrag verbinden?

Eine präzise Beschreibung schwächt eine Leistung nicht.

Im Gegenteil. Sie zeigt, dass du deine eigene Verantwortung verstehst, mit anderen zusammenarbeiten kannst und die Ergebnisse deiner Arbeit ehrlich darstellst.

[1] CRediT - Contributor Role Taxonomy, NISO
Quelle öffnen

[2] Polnisches Gesetz über Urheberrecht und verwandte Schutzrechte - Art. 8-12, ELI
Quelle öffnen

[3] Polnisches Gesetz gegen unlauteren Wettbewerb - Art. 11, konsolidierte Fassung von 2026
Quelle öffnen

[4] Verordnung (EU) 2016/679 - DSGVO, Art. 5, EUR-Lex
Quelle öffnen

Methodischer Hinweis: CRediT ist ein Standard für Mitwirkendenrollen in Forschung und wissenschaftlichem Publizieren. Dieser Artikel nutzt ihn als Beispiel für transparente Beitragszuordnung, stellt ihn jedoch nicht als Standard für berufliche Portfolios dar. Die sechs Elemente einer Projektbeschreibung und die vier Arten, den Bezug zu Ergebnissen zu beschreiben, sind ein in diesem Material vorgeschlagenes redaktionelles Modell.