Це зробив я чи команда? Як чесно описати власний внесок у портфоліо

Більшість цінних продуктів, кампаній, впроваджень і процесів створюються командно.

Тому сам фінальний результат ще не показує, яку роль насправді відіграв конкретний фахівець.

Для людини, яка оцінює портфоліо, різниця суттєва:

"Я працював над перепроєктуванням процесу завершення покупки"

не означає те саме, що:

"Я проводив дослідження, спроєктував новий процес завершення покупки, підготував прототип і провів тести зручності. Реалізацією займалася окрема команда розробників клієнтської частини."

Другий опис дозволяє оцінити реальні компетенції, не применшуючи внесок інших людей.

Ця проблема характерна не лише для професійних портфоліо.

У наукових публікаціях, зокрема, використовується CRediT - Contributor Role Taxonomy. Стандарт описує 14 типів внеску й був створений для більшої прозорості щодо того, хто насправді відповідав за окремі частини роботи. CRediT дозволяє призначати одній людині кілька ролей, а одну роль - кільком людям. Також рекомендується, щоб учасники могли переглянути й підтвердити ролі, які їм приписані. [1]

CRediT насамперед стосується дослідницької діяльності та наукових публікацій. Це не стандарт професійного портфоліо. Водночас він демонструє важливий принцип, який можна застосовувати ширше: замість нечіткого "я був частиною проєкту" краще прямо зазначити характер свого реального внеску.

Хороший опис командного проєкту можна побудувати навколо шести елементів:

1. Контекст проєкту
2. Склад і масштаб команди
3. Власна відповідальність
4. Конкретні дії та рішення
5. Артефакти або докази роботи
6. Результат і спосіб його атрибуції

Мета не в тому, щоб створити довгий звіт. Мета - усунути найважливіші неоднозначності.

Спочатку поясніть, над чим насправді працювала команда.

Достатньо коротко вказати:

• проблему або мету,
• тип продукту чи послуги,
• приблизний масштаб,
• важливі обмеження,
• період реалізації, якщо він має значення.

Приклад:

Метою проєкту було скоротити процес покупки в B2B-застосунку. Продукт працював на кількох європейських ринках і обслуговував бізнес-клієнтів.

Так читач розуміє контекст ще до оцінки індивідуального внеску.

Не потрібно називати кожного учасника поіменно.

У багатьох випадках достатньо такої структури:

Команда: менеджер продукту, дизайнер користувацького досвіду, 2 розробники клієнтської частини, 2 розробники серверної частини та фахівець із якості.

Одна ця інформація змінює спосіб сприйняття всього опису проєкту.

Читач бачить, що результат не виник сам по собі, а фахівець працював у чітко визначеній системі відповідальності.

Це найважливіша частина.

Замість загального:

"я працював над клієнтською частиною"

напишіть конкретно:

"я відповідав за архітектуру платіжного модуля, реалізацію процесу завершення покупки, інтеграцію з платіжним API та перевірку коду змін у цій області."

Також корисно зазначити, чого ви не робили, якщо це могло б бути незрозуміло:

"серверну частину та інтеграцію з платіжним провайдером на стороні сервера реалізовувала окрема команда."

Такий опис не послаблює портфоліо. Він робить його переконливішим.

Назва посади ще не є описом внеску.

Старший дизайнер користувацького досвіду в одному проєкті може вести весь дослідницький процес, а в іншому - лише готувати фінальні екрани.

Тому показуйте дії, які можна пов'язати з конкретними компетенціями:

• я підготував архітектуру рішення,
• провів дослідження,
• спроєктував перебіг процесу,
• проаналізував дані,
• написав ключову частину реалізації,
• підготував стратегію кампанії,
• проводив переговори,
• координував залежності між командами,
• перевірив рішення перед запуском.

Найцінніші приклади - ті, де можна пояснити чому було прийнято конкретне рішення.

Якщо проєкт можна показувати, артефакт допомагає пов'язати заявлений внесок із реальною роботою.

Це може бути, наприклад:

• екран продукту,
• частина інтерфейсу,
• прототип,
• фрагмент коду,
• публічний репозиторій,
• звіт,
• діаграма,
• публікація,
• матеріал кампанії,
• фотографія,
• документ або безпечний для показу фрагмент.

Артефакт не повинен доводити все. Його мета - допомогти читачеві зрозуміти що реально було створено і як це пов'язано з описаним внеском.

Найбільший ризик перебільшення власного внеску виникає під час опису результатів.

Якщо після проєкту конверсія компанії зросла на 25%, це не означає автоматично, що одна людина збільшила конверсію на 25%.

У той самий період могли змінитися:

• ціни,
• пропозиція,
• маркетинг,
• користувацький досвід,
• інфраструктура,
• сезонність,
• джерела трафіку,
• робота інших учасників команди.

Описуйте результат лише з таким рівнем упевненості, який можете реально обґрунтувати.

1. Пряма відповідальність
"Я скоротив час виконання цього процесу з 12 до 4 хвилин завдяки автоматизації кроків, за які відповідав."

Використовуйте, коли зв'язок між вашою дією та результатом прямий і його можна обґрунтувати.

2. Спільний результат
"Разом із командою ми перепроєктували процес адаптації користувачів. Після запуску частка завершених проходжень зросла на 18%."

Використовуйте, коли результат виник завдяки роботі кількох людей.

3. Внесок у ширшу зміну
"Я відповідав за перепроєктування процесу завершення покупки як частини ширшої оптимізації процесу придбання. Після запуску всієї програми компанія зафіксувала зростання конверсії."

Використовуйте, коли ваша область була лише одним із кількох чинників.

4. Результат як контекст проєкту
"Проєкт завершився зростанням продажів на 40%. До мого обсягу роботи входили архітектура клієнтської частини та реалізація процесу завершення покупки."

Використовуйте, коли знаєте загальний результат проєкту, але не маєте достатніх підстав визначити, яка частина була спричинена саме вашою роботою.

Якщо в проєкті брало участь кілька людей, найкращий опис має одночасно відповідати на два запитання:

Що створила команда?

і

За що відповідала кожна людина?

Приклад:

Проєкт: перша версія застосунку для логістики
Команда: дизайнер користувацького досвіду, розробник клієнтської частини, розробник серверної частини
Спільний результат: робоча перша версія продукту, підготовлена до пілотного запуску
Дизайнер користувацького досвіду: дослідження, шлях користувача, прототип, дизайн інтерфейсу
Розробник клієнтської частини: клієнтська архітектура, реалізація вебзастосунку
Розробник серверної частини: API, модель даних, інтеграції

Такий опис посилює і команду, і окремих фахівців.

У деяких проєктах корисні прості позначення рівня участі:

Провідна роль - я керував цією областю та відповідав за ключові рішення.
Спільна відповідальність - я ділив відповідальність з однією або кількома людьми.
Допоміжна роль - я підтримував роботу в цій області, але не був головним відповідальним.

CRediT використовує подібне розмежування ролей учасників. [1]

Головний принцип простий: рівень відповідальності має бути зрозумілим.

У важливих спільних проєктах варто переконатися, що опис вашого внеску не суперечить очевидним чином тому, як інші учасники розуміють розподіл ролей.

CRediT рекомендує, щоб учасники могли переглянути та підтвердити приписані їм ролі. [1]

У професійному портфоліо це не обов'язково має бути формальним погодженням кожного речення. Практичне правило простіше: не приписуйте собі відповідальність за роботу, якою насправді керував хтось інший.

Опис власного внеску не слід плутати з визначенням авторських прав.

За польським законодавством про авторське право права, як правило, належать автору, а співавторам - спільно. Для творів, створених у межах трудових відносин, роботодавець може набути майнові авторські права в обсязі, визначеному законом і трудовими відносинами. [2]

На практиці три запитання потрібно розглядати окремо:

Чи брав я участь у створенні проєкту?
Чи є я автором або співавтором конкретного елемента?
Чи маю я право опублікувати матеріал у своєму портфоліо?

Відповідь "так" на перше запитання не визначає автоматично відповіді на два інші.

Не кожен проєкт можна показувати або детально описувати.

Польське законодавство про боротьбу з недобросовісною конкуренцією захищає інформацію, що становить комерційну таємницю, зокрема певні технічні, технологічні, організаційні та інші відомості з економічною цінністю, які зберігаються конфіденційними. [3]

Тому в конфіденційному проєкті простого видалення назви клієнта може бути недостатньо. Інші деталі все одно можуть розкривати захищену інформацію.

Безпечніше правило:

описуйте лише те, що ви справді маєте право розкривати відповідно до застосовного права, договорів, отриманих згод та інших наявних прав.

Опис проєкту зазвичай не потребує приватних даних усієї команди.

GDPR вимагає, серед іншого, законності, обмеження мети та мінімізації даних, тобто персональні дані мають бути обмежені тим, що необхідне для відповідної мети. [4]

Якщо достатньо описати команду так:

1 дизайнер користувацького досвіду, 2 розробники клієнтської частини, розробник серверної частини та фахівець із якості

немає потреби автоматично публікувати імена, фотографії, адреси електронної пошти чи інші персональні дані колег.

Якщо ви хочете опублікувати рекомендацію, висловлювання, зображення або інші дані конкретної особи, перевірте відповідну правову підставу та допустимий обсяг використання матеріалу.

Якщо умови співпраці дозволяють загальний опис досвіду, можна розглянути можливість показати:

• тип проблеми без ідентифікації клієнта,
• власну роль,
• категорії використаних компетенцій,
• тип відповідальності,
• процес прийняття рішень на достатньо загальному рівні,
• результат лише в тому обсязі, у якому його дозволено розкрити.

Не створюйте вигаданих знімків екрана, даних або результатів замість конфіденційних матеріалів.

Якщо ви не впевнені, чи можна розкрити певну інформацію, безпечніше не публікувати її до з'ясування питання.

Невеликі відмінності у формулюваннях можуть дуже добре показати рівень відповідальності.

Я відповідав за... - чітко визначає вашу область.
Я керував... - вказує на відповідальність за напрям або виконання певного обсягу.
Я співстворював... - показує, що результат мав кількох авторів.
Я підтримував... - чесно описує допоміжний внесок.
Я був частиною команди, яка... - відокремлює особисту участь від загального результату команди.
Після запуску проєкту компанія зафіксувала... - показує результат як контекст, не приписуючи автоматично весь ефект собі.

Уникайте автоматичного "я це зробив", якщо реальний обсяг був спільним.

1. Ви використовуєте однину для проєкту, реалізованого багатьма людьми.

2. Показуєте бізнес-результат, але не пояснюєте свій обсяг роботи.

3. Називаєте технології всього продукту власними компетенціями, хоча працювали не з усіма.

4. Показуєте фінальний візуальний дизайн, код або стратегію, не пояснюючи, які частини створили особисто.

5. Не згадуєте ключових учасників там, де їхній внесок необхідний для розуміння проєкту.

6. Натякаєте на причинний зв'язок між своєю роботою та результатом, який не можете обґрунтувати.

Проєкт
Що створювалося і яку проблему потрібно було вирішити?

Команда
Які ролі брали участь у проєкті?

Моя відповідальність
За яку область я відповідав особисто?

Мої дії та рішення
Що саме я зробив або чим керував?

Співпраця
Які елементи були створені разом з іншими людьми?

Артефакти
Що я маю право показати законно?

Результат
Чого досяг проєкт і як мій внесок був пов'язаний із цим результатом?

Обмеження
Чи є елементи, які я не можу розкривати через конфіденційність або права інших осіб?

Поставте собі сім запитань:

1. Чи знає читач, якою великою була команда?

2. Чи зрозуміло, за що саме я відповідав?

3. Чи не приписав я собі роботу, виконану іншими людьми?

4. Чи описаний результат із належним рівнем обережності?

5. Чи маю я законне право публікувати використані матеріали?

6. Чи не розкриваю я зайві персональні або конфіденційні дані?

7. Чи зможе стороння людина за цим описом визначити, які компетенції я справді використовував?

Якщо відповіді чіткі, опис проєкту стає доказом компетенцій, а не лише привабливою історією.

Найкращий опис проєкту не мусить обирати між:

"це зробив я"

і

"це зробила команда."

Він може одночасно показувати обидві правди:

команда досягла конкретного результату, а я відповідав за конкретну частину, рішення та виконання.

Такий рівень точності дозволяє оцінити фахівця, не забираючи заслуги в інших.

Портфоліо не повинно бути змаганням за найгучніше можливе формулювання.

Його цінність зростає, коли людина по інший бік може зрозуміти:

що було створено, хто над цим працював, за що ви відповідали, що зробили особисто та який результат можна обґрунтовано пов'язати з вашим внеском.

Точний опис не послаблює досягнення.

Навпаки. Він показує, що ви розумієте власну відповідальність, умієте працювати з іншими та чесно представляти результати своєї роботи.

[1] CRediT - Contributor Role Taxonomy, NISO
Перейти до джерела

[2] Закон Польщі про авторське право і суміжні права - ст. 8-12, ELI
Перейти до джерела

[3] Закон Польщі про боротьбу з недобросовісною конкуренцією - ст. 11, консолідований текст, опублікований у 2026 році
Перейти до джерела

[4] Регламент (ЄС) 2016/679 - GDPR, ст. 5, EUR-Lex
Перейти до джерела

Методологічна примітка: CRediT є стандартом ролей учасників у дослідженнях і наукових публікаціях. У цьому матеріалі він використовується як приклад прозорого визначення внеску, але не подається як стандарт професійного портфоліо. Шість елементів опису проєкту та чотири способи опису зв'язку з результатом є редакційною моделлю, запропонованою в цьому матеріалі.