To zrobiłem ja czy zespół? Jak uczciwie opisać własny wkład w portfolio

Większość wartościowych produktów, kampanii, wdrożeń i procesów powstaje zespołowo.

Dlatego samo pokazanie finalnego rezultatu nie mówi jeszcze, jaką rolę odegrał konkretny specjalista.

Dla osoby oceniającej portfolio różnica jest ogromna:

„Pracowałem przy przeprojektowaniu procesu finalizacji zakupu”

nie znaczy tego samego co:

„Prowadziłem badania, zaprojektowałem nowy przebieg procesu finalizacji zakupu, przygotowałem prototyp i przeprowadziłem testy użyteczności. Implementację wykonywał osobny zespół programistów warstwy klienckiej.”

Drugi opis pozwala ocenić rzeczywiste kompetencje bez umniejszania pracy pozostałych osób.

Problem nie jest charakterystyczny wyłącznie dla portfolio zawodowego.

W świecie publikacji naukowych rozwinięto między innymi CRediT - Contributor Role Taxonomy. Standard opisuje 14 rodzajów wkładu i powstał po to, aby zwiększyć przejrzystość informacji o tym, kto rzeczywiście odpowiadał za poszczególne części pracy. CRediT dopuszcza przypisanie jednej osobie wielu ról, a jednej roli wielu osobom. Zaleca również, aby współtwórcy mieli możliwość sprawdzenia i potwierdzenia przypisanych im ról. [1]

CRediT dotyczy przede wszystkim działalności badawczej i publikacji naukowych. Nie jest standardem portfolio zawodowego. Pokazuje jednak ważną zasadę, którą można zastosować szerzej: zamiast opierać się na nieprecyzyjnym „byłem częścią projektu”, warto jasno wskazać rodzaj rzeczywistego wkładu.

Dobry opis projektu zespołowego można zbudować wokół sześciu informacji:

1. Kontekst projektu
2. Skład i zakres zespołu
3. Własna odpowiedzialność
4. Konkretne działania i decyzje
5. Artefakty lub dowody pracy
6. Rezultat i sposób jego przypisania

Nie chodzi o stworzenie długiego raportu. Chodzi o usunięcie najważniejszych niejasności.

Najpierw pokaż, nad czym właściwie pracował zespół.

Wystarczy krótko określić:

• problem lub cel,
• rodzaj produktu albo usługi,
• przybliżoną skalę,
• istotne ograniczenia,
• okres realizacji, jeżeli ma znaczenie.

Przykład:

Celem projektu było skrócenie procesu zakupowego w aplikacji B2B. Produkt działał na kilku rynkach europejskich i obsługiwał klientów firmowych.

Dzięki temu odbiorca rozumie środowisko, zanim zacznie oceniać indywidualny wkład.

Nie trzeba wymieniać każdej osoby z imienia i nazwiska.

W wielu przypadkach wystarczy struktura:

Zespół: menedżer produktu, projektant doświadczeń użytkownika, 2 programistów warstwy klienckiej, 2 programistów warstwy serwerowej i specjalista ds. jakości.

Ta jedna informacja zmienia sposób interpretacji całego opisu projektu.

Odbiorca widzi, że rezultat nie powstał w próżni, a specjalista działał w określonym układzie odpowiedzialności.

To najważniejsza część.

Zamiast ogólnego:

„pracowałem nad warstwą kliencką”

napisz konkretnie:

„odpowiadałem za architekturę modułu płatności, implementację procesu finalizacji zakupu, integrację z API płatniczym i przegląd kodu zmian w tym obszarze”.

Warto również powiedzieć, czego nie robiłeś, jeżeli mogłoby to być niejasne:

„warstwę serwerową i integrację z operatorem płatności po stronie serwera realizował osobny zespół”.

Takie zdanie nie osłabia portfolio. Zwiększa jego wiarygodność.

Stanowisko nie jest jeszcze opisem wkładu.

Starszy projektant doświadczeń użytkownika może w jednym projekcie prowadzić cały proces badawczy, a w innym przygotować tylko finalne makiety.

Dlatego pokaż działania, które można powiązać z kompetencjami:

• przygotowałem architekturę rozwiązania,
• przeprowadziłem badania,
• zaprojektowałem przebieg procesu,
• wykonałem analizę danych,
• napisałem kluczową część implementacji,
• przygotowałem strategię kampanii,
• prowadziłem negocjacje,
• koordynowałem zależności między zespołami,
• zweryfikowałem rozwiązanie przed wdrożeniem.

Najbardziej wartościowe są takie działania, przy których można wyjaśnić dlaczego podjęto konkretną decyzję.

Jeżeli projekt można pokazać, artefakt pomaga połączyć deklarowany wkład z realną pracą.

Może to być na przykład:

• ekran produktu,
• fragment interfejsu,
• prototyp,
• fragment kodu,
• publiczne repozytorium,
• raport,
• diagram,
• publikacja,
• materiał kampanii,
• fotografia,
• dokument lub jego bezpieczny fragment.

Artefakt nie musi udowadniać wszystkiego. Ma pomóc odbiorcy zrozumieć, co faktycznie powstało i jak wiąże się to z opisanym wkładem.

Największe ryzyko zawyżenia własnego wkładu pojawia się przy wynikach.

Jeżeli firma po projekcie zwiększyła konwersję o 25%, nie oznacza to automatycznie, że jedna osoba zwiększyła konwersję o 25%.

W tym samym okresie mogły zmienić się:

• ceny,
• oferta,
• marketing,
• UX,
• infrastruktura,
• sezonowość,
• źródła ruchu,
• działania innych członków zespołu.

Dlatego rezultat należy opisywać z takim poziomem pewności, jaki rzeczywiście można uzasadnić.

1. Bezpośrednia odpowiedzialność
„Skróciłem czas wykonania tego procesu z 12 do 4 minut poprzez automatyzację kroków, za które odpowiadałem.”

Używaj, gdy związek między własnym działaniem i wynikiem jest bezpośredni oraz możliwy do uzasadnienia.

2. Wspólny rezultat
„Wspólnie z zespołem przeprojektowaliśmy proces wdrożenia użytkownika. Po wdrożeniu współczynnik ukończenia procesu wzrósł o 18%.”

Używaj, gdy wynik powstał dzięki pracy kilku osób.

3. Wkład w szerszą zmianę
„Odpowiadałem za przeprojektowanie procesu finalizacji zakupu będące częścią większej optymalizacji procesu zakupowego. Po wdrożeniu całego programu firma odnotowała wzrost konwersji.”

Używaj, gdy Twój obszar był tylko jednym z czynników.

4. Wynik jako kontekst projektu
„Projekt zakończył się wzrostem sprzedaży o 40%. Mój zakres obejmował architekturę warstwy klienckiej i implementację procesu finalizacji zakupu.”

Używaj, gdy znasz wynik całego projektu, ale nie masz podstaw do określenia, jaka część wynikała z Twojej pracy.

Jeżeli projekt pokazuje kilka osób, najlepszy opis powinien pozwolić odpowiedzieć na dwa pytania jednocześnie:

Co dostarczył zespół?

oraz

Za co odpowiadała każda z osób?

Przykład:

Projekt: pierwsza wersja aplikacji dla logistyki
Zespół: projektant doświadczeń użytkownika, programista warstwy klienckiej, programista warstwy serwerowej
Wspólny rezultat: działająca pierwsza wersja produktu przygotowana do pilotażu
Projektant doświadczeń użytkownika: badania, ścieżka użytkownika, prototyp, projekt interfejsu
Programista warstwy klienckiej: architektura części klienckiej, implementacja aplikacji internetowej
Programista warstwy serwerowej: API, model danych, integracje

Taki opis projektu wzmacnia zarówno zespół, jak i poszczególnych specjalistów.

W niektórych projektach pomocne są proste określenia poziomu udziału:

Rola wiodąca - prowadziłem dany obszar i odpowiadałem za kluczowe decyzje.
Współodpowiedzialność - dzieliłem odpowiedzialność z inną osobą lub osobami.
Rola wspierająca - wspierałem obszar, ale nie byłem jego głównym właścicielem.

Podobne rozróżnienie stosuje CRediT przy rolach współtwórców. [1]

Najważniejsza jest sama zasada: poziom odpowiedzialności powinien być możliwy do zrozumienia.

Przy ważnych wspólnych projektach warto upewnić się, że opis własnego wkładu nie stoi w oczywistej sprzeczności z tym, jak role rozumieją pozostali uczestnicy.

CRediT rekomenduje, aby współtwórcy mieli możliwość przejrzenia i potwierdzenia przypisanych ról. [1]

W portfolio zawodowym nie musi to oznaczać formalnego procesu akceptacji każdego zdania. Dobra praktyka jest prostsza: nie przypisuj sobie odpowiedzialności, którą w rzeczywistości prowadził ktoś inny.

Opis własnego wkładu nie powinien być mylony z ustalaniem praw autorskich.

Polska ustawa o prawie autorskim wskazuje, że co do zasady prawo autorskie przysługuje twórcy, a współtwórcom przysługuje wspólnie. Jednocześnie w przypadku utworów pracowniczych pracodawca może nabyć autorskie prawa majątkowe w zakresie określonym przez ustawę i stosunek pracy. [2]

W praktyce oznacza to, że trzy pytania należy traktować osobno:

Czy brałem udział w stworzeniu projektu?
Czy jestem twórcą lub współtwórcą określonego elementu?
Czy mam prawo opublikować materiał w swoim portfolio?

Odpowiedź „tak” na pierwsze pytanie nie przesądza automatycznie odpowiedzi na dwa pozostałe.

Nie każdy projekt można pokazać ani szczegółowo opisać.

Polskie przepisy o zwalczaniu nieuczciwej konkurencji chronią informacje stanowiące tajemnicę przedsiębiorstwa, w tym określone informacje techniczne, technologiczne, organizacyjne i inne informacje posiadające wartość gospodarczą, które są utrzymywane w poufności. [3]

Dlatego przy projekcie poufnym nie wystarczy automatycznie usunąć nazwy klienta. Pozostałe szczegóły mogą nadal ujawniać chronione informacje.

Bezpieczniejsza zasada brzmi:

opisuj tylko to, co rzeczywiście możesz ujawnić na podstawie prawa, umów i posiadanych zgód lub uprawnień.

Opis projektu zwykle nie potrzebuje prywatnych danych całego zespołu.

RODO wymaga między innymi zgodności z prawem, ograniczenia celu i minimalizacji danych, czyli ograniczenia danych osobowych do tego, co jest niezbędne dla określonego celu. [4]

Jeżeli do opisania zespołu wystarcza:

1 projektant doświadczeń użytkownika, 2 programistów warstwy klienckiej, programista warstwy serwerowej i specjalista ds. jakości

nie ma potrzeby automatycznie publikować nazwisk, zdjęć, adresów e-mail ani innych danych współpracowników.

Jeżeli chcesz opublikować referencję, wypowiedź, wizerunek lub dane konkretnej osoby, sprawdź właściwą podstawę prawną i zakres, w którym materiał może być użyty.

Jeżeli warunki współpracy pozwalają na ogólny opis doświadczenia, można rozważyć pokazanie:

• rodzaju problemu bez identyfikowania klienta,
• własnej roli,
• kategorii wykorzystanych kompetencji,
• rodzaju odpowiedzialności,
• procesu podejmowania decyzji w odpowiednio ogólnej formie,
• rezultatu tylko na takim poziomie, na jakim może zostać ujawniony.

Nie twórz fikcyjnych zrzutów ekranu, danych ani wyników po to, aby zastąpić materiał objęty poufnością.

Jeżeli nie masz pewności, czy określona informacja może zostać ujawniona, bezpieczniej jej nie publikować do czasu wyjaśnienia tej kwestii.

Drobne różnice językowe potrafią bardzo dobrze pokazać poziom odpowiedzialności.

Odpowiadałem za... - jasne przypisanie własnego obszaru.
Prowadziłem... - sugeruje odpowiedzialność za kierunek lub realizację danego zakresu.
Współtworzyłem... - pokazuje, że rezultat miał więcej niż jednego autora.
Wspierałem... - uczciwie opisuje udział pomocniczy.
Byłem częścią zespołu, który... - oddziela indywidualny udział od wyniku całego zespołu.
Po wdrożeniu projektu firma odnotowała... - pokazuje wynik jako kontekst, bez automatycznego przypisania sobie całego efektu.

Unikaj automatycznego „zrobiłem”, jeżeli rzeczywisty zakres był współdzielony.

1. Używasz liczby pojedynczej przy projekcie wykonanym przez wiele osób.

2. Pokazujesz wynik biznesowy, ale nie wyjaśniasz własnego zakresu.

3. Wymieniasz technologie całego produktu jako własne kompetencje, mimo że nie pracowałeś z każdą z nich.

4. Pokazujesz końcowy projekt graficzny, kod lub strategię bez informacji, które części rzeczywiście stworzyłeś.

5. Pomijasz kluczowych współtwórców tam, gdzie ich udział jest niezbędny do zrozumienia projektu.

6. Sugerujesz związek przyczynowy między swoją pracą i wynikiem, którego nie potrafisz uzasadnić.

Projekt
Co było tworzone i jaki problem rozwiązywano?

Zespół
Jakie role uczestniczyły w projekcie?

Moja odpowiedzialność
Za który obszar odpowiadałem osobiście?

Moje działania i decyzje
Co konkretnie wykonałem lub prowadziłem?

Współpraca
Które elementy powstały wspólnie z innymi osobami?

Artefakty
Co mogę legalnie pokazać?

Rezultat
Co osiągnął projekt i jaka była relacja mojego wkładu z tym wynikiem?

Ograniczenia
Czy istnieją elementy, których nie mogę ujawnić ze względu na poufność lub prawa innych osób?

Zadaj sobie siedem pytań:

1. Czy odbiorca wie, jak duży był zespół?

2. Czy dokładnie wiadomo, za co odpowiadałem?

3. Czy nie przypisałem sobie pracy wykonanej przez inne osoby?

4. Czy rezultat jest opisany z odpowiednim poziomem ostrożności?

5. Czy mogę legalnie opublikować użyte materiały?

6. Czy nie ujawniam danych osobowych albo informacji poufnych ponad potrzebę?

7. Czy osoba z zewnątrz potrafiłaby na podstawie tego opisu powiedzieć, jakie kompetencje rzeczywiście wykorzystałem?

Jeżeli odpowiedzi są jasne, opis projektu zaczyna działać jako dowód kompetencji, a nie tylko atrakcyjna historia.

Najlepszy opis projektu nie musi wybierać pomiędzy:

„to zrobiłem ja”

a

„to zrobił zespół”.

Może pokazać obie prawdy jednocześnie:

zespół dostarczył określony rezultat, a ja odpowiadałem za konkretną część, decyzje i wykonanie.

To właśnie taki poziom precyzji pozwala ocenić specjalistę bez odbierania zasług pozostałym osobom.

Portfolio nie powinno być konkursem na największe możliwe sformułowanie.

Jego wartość rośnie wtedy, gdy osoba po drugiej stronie może zrozumieć:

co powstało, kto nad tym pracował, za co odpowiadałeś, co zrobiłeś osobiście i jaki rezultat można rozsądnie powiązać z Twoim wkładem.

Precyzyjny opis nie osłabia osiągnięcia.

Przeciwnie. Pokazuje, że potrafisz rozumieć własną odpowiedzialność, współpracować z innymi i uczciwie przedstawiać efekty swojej pracy.

[1] CRediT - Contributor Role Taxonomy, NISO
Przejdź do źródła

[2] Ustawa o prawie autorskim i prawach pokrewnych - art. 8-12, Internetowy System Aktów Prawnych / ELI
Przejdź do źródła

[3] Ustawa o zwalczaniu nieuczciwej konkurencji - art. 11, tekst jednolity ogłoszony w 2026 r.
Przejdź do źródła

[4] Rozporządzenie (UE) 2016/679 - RODO, art. 5, EUR-Lex
Przejdź do źródła

Informacja metodologiczna: CRediT jest standardem dotyczącym ról współtwórców w działalności badawczej i publikacjach. Artykuł wykorzystuje go jako przykład przejrzystego opisywania wkładu, ale nie przedstawia go jako standardu portfolio zawodowego. Sześć elementów opisu projektu oraz cztery sposoby opisywania relacji z rezultatem są autorskim modelem redakcyjnym opisanym w tym materiale.