Это сделал я или команда? Как честно описать свой вклад в портфолио

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

Поэтому один только конечный результат еще не показывает, какую роль в действительности сыграл конкретный специалист.

Для человека, который оценивает портфолио, разница существенна:

"Я работал над переработкой процесса завершения покупки"

не означает то же самое, что:

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

Второй вариант позволяет оценить реальные компетенции, не умаляя работу других.

Эта проблема характерна не только для профессиональных портфолио.

В научных публикациях, например, используется 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 является стандартом ролей участников в исследованиях и научных публикациях. В этом материале он используется как пример прозрачной атрибуции вклада, но не представляется как стандарт профессионального портфолио. Шесть элементов описания проекта и четыре способа описания связи с результатом являются редакционной моделью, предложенной в этом материале.