作品集应该回答一个问题：这个人实际上能做什么？
但在团队项目中，还会出现第二个问题：
这个人具体做了什么，哪些内容又是整个团队共同工作的结果？
例如：
“我打造了一个拥有 100,000 名用户的平台。”
这句话可能代表完全不同的情况。这个人可能设计了全部架构，也可能只负责其中一个模块；可能只在项目最后两个月加入；也可能是在几十人的团队中工作，而团队共同取得的结果后来却被描述成某一个人的个人成就。
好的作品集不应该让读者靠猜测来理解这些信息。
为什么准确说明个人贡献如此重要？
大多数有价值的产品、营销活动、系统实施和业务流程，都是由团队共同完成的。
因此，只展示最终结果，并不能说明某一位专业人士实际上承担了什么角色。
对于评估作品集的人来说，下面两种说法差别很大：
“我参与了购买完成流程的重新设计。”
和：
“我主导了调研，设计了新的购买完成流程，制作了原型，并进行了可用性测试。实际开发由独立的客户端开发团队负责。”
第二种描述可以让人评估真实能力，同时不会弱化其他成员的工作。
已经存在一些透明说明贡献的良好做法
这个问题并不只存在于职业作品集中。
在学术出版领域，一个例子是 CRediT - Contributor Role Taxonomy。该标准定义了 14 类贡献角色，目的是更透明地说明一项工作中的不同部分实际上由谁负责。CRediT 允许一个人承担多个角色，也允许同一个角色由多个人共同承担。它还建议让贡献者有机会查看并确认分配给自己的角色。 [1]
CRediT 主要用于科研和学术出版。它不是职业作品集标准。 但它体现了一个可以更广泛使用的重要原则：与其笼统地说“我是这个项目的一员”，不如清楚说明自己实际做出了什么贡献。
最常见的错误：把项目整体成功描述成个人成就
诚实说明个人贡献的六个要素
一个好的团队项目说明可以围绕六类信息展开：
1. 项目背景
2. 团队构成和范围
3. 个人责任
4. 具体行动和决策
5. 工作成果物或证据
6. 结果以及结果如何归属
目的不是写一份很长的报告，而是消除最重要的模糊之处。
1. 从项目背景开始
首先说明团队实际在解决什么问题或开展什么工作。
通常简要说明以下内容就足够：
- 问题或目标，
- 产品或服务类型，
- 大致规模，
- 重要限制条件，
- 如果有意义，可以说明实施周期。
示例：
项目目标是缩短一个 B2B 应用中的购买流程。该产品服务于多个欧洲市场，并面向企业客户。
这样，读者在评估个人贡献之前，可以先理解项目背景。
2. 说明团队由哪些角色组成
没有必要列出每一个人的姓名。
很多情况下，下面这种描述已经足够：
团队：产品经理、用户体验设计师、2 名客户端开发人员、2 名服务端开发人员和 1 名质量专家。
仅仅增加这一条信息，就会改变读者理解整个项目描述的方式。
读者能够看出，这个结果并不是一个人独立完成的，而是专业人士在明确的责任分工中开展工作。
3. 把自己的责任与整个团队的工作范围分开
这是最重要的部分。
不要只写：
“我负责客户端部分。”
而应该写得具体：
“我负责支付模块架构、购买完成流程的实现、支付 API 集成，以及该领域相关改动的代码审查。”
如果某些内容容易产生误解，也可以明确说明自己没有负责什么：
“服务端层以及支付服务商在服务端的集成由另一个团队负责。”
这种说明不会削弱作品集，反而会提升可信度。
4. 描述具体行动和决策，而不只是职位名称
职位名称本身不能说明实际贡献。
一名高级用户体验设计师可能在一个项目中主导整个研究过程，而在另一个项目中只负责制作最终界面。
因此，应展示能够与具体能力对应的行动：
- 我设计了解决方案架构，
- 我进行了调研，
- 我设计了流程，
- 我分析了数据，
- 我编写了实现中的关键部分，
- 我制定了营销活动策略，
- 我主导了谈判，
- 我协调了不同团队之间的依赖关系，
- 我在上线前验证了解决方案。
如果还能解释为什么做出某一个具体决策，这样的案例会更有价值。
5. 如果法律允许，展示实际工作成果
如果项目可以公开展示，工作成果可以帮助把描述中的个人贡献与真实工作联系起来。
例如：
- 产品界面，
- 界面的一部分，
- 原型，
- 一段代码，
- 公开代码仓库，
- 报告，
- 图表，
- 公开出版物，
- 营销材料，
- 照片，
- 文档或其中可以安全公开的一部分。
工作成果不需要证明一切。它的作用是帮助读者理解实际产出了什么，以及这些内容与所描述的个人贡献有什么关系。
6. 把项目整体结果与自己工作的结果分开
在描述结果时，最容易出现夸大个人贡献的问题。
如果一个项目上线后公司的转化率提高了 25%，这并不自动意味着某一个人让转化率提高了 25%。
在同一时期，以下因素也可能发生了变化：
- 价格，
- 产品或服务方案，
- 营销，
- 用户体验，
- 基础设施，
- 季节性因素，
- 流量来源，
- 其他团队成员的工作。
只应以自己真正能够证明的确定程度来描述结果。
四种更稳妥的结果归属表达方式
1. 直接责任
“我通过自动化自己负责的步骤，把这个流程的处理时间从 12 分钟缩短到了 4 分钟。”
当自己的行动与结果之间存在直接且能够说明的关系时使用。
2. 共同结果
“我们与团队一起重新设计了用户启用流程。上线后，流程完成率提高了 18%。”
当结果来自多个人共同工作时使用。
3. 对更大范围变化的贡献
“作为整体购买流程优化的一部分，我负责重新设计购买完成流程。整个计划上线后，公司记录到了转化率增长。”
当自己的工作只是多个影响因素之一时使用。
4. 把结果作为项目背景
“项目完成后，销售额增长了 40%。我的工作范围包括客户端架构和购买完成流程的实现。”
当你知道项目整体结果，但没有充分依据判断其中多少由自己的工作直接造成时使用。
示例：客户端开发人员
示例：用户体验设计师
示例：营销
示例：项目经理
一个好的团队项目说明应该是什么样？
如果一个项目涉及多个人，好的说明应该同时回答两个问题：
团队交付了什么？
以及
每个人分别负责什么？
示例：
项目： 物流应用的第一个版本
团队： 用户体验设计师、客户端开发人员、服务端开发人员
共同结果： 可正常运行并准备进入试点的第一个产品版本
用户体验设计师： 调研、用户路径、原型、界面设计
客户端开发人员： 客户端架构、Web 应用实现
服务端开发人员： API、数据模型、系统集成
这样的项目说明既能体现团队价值，也能体现每位专业人士的实际贡献。
不要害怕用简单标签说明参与程度
在一些项目中，用简单标签说明参与程度会很有帮助：
主导角色 - 我主导这个领域，并负责关键决策。
共同责任 - 我与一名或多名其他成员共同承担责任。
支持角色 - 我为这个领域提供支持，但不是主要负责人。
CRediT 对贡献角色也采用类似的区分方式。 [1]
最重要的原则很简单：责任程度应该让读者容易理解。
如果可能，与团队核对自己的贡献描述
对于重要的共同项目，最好确认自己对个人贡献的描述不会明显违背其他参与者对角色分工的理解。
CRediT 建议让贡献者能够查看并确认分配给自己的角色。 [1]
职业作品集不一定需要对每一句话进行正式审批。更实用的规则是：不要把实际上由其他人主导的工作责任归到自己名下。
项目贡献、作者身份和公开权利是不同的问题
描述自己的项目贡献，不应与判断著作权归属混为一谈。
根据波兰著作权法，著作权原则上属于作者；如果存在共同作者，则由共同作者共同享有。对于在劳动关系中创作的作品，雇主可能在法律和劳动关系规定的范围内取得相关财产权利。 [2]
在实际使用中，应把以下三个问题分开：
我是否参与了这个项目的创作？
我是某个具体部分的作者或共同作者吗？
我有权在自己的作品集中公开这些材料吗？
第一个问题回答“是”，并不会自动决定另外两个问题的答案。
NDA 和商业秘密优先于作品集展示
并不是所有项目都可以公开或详细描述。
波兰关于反不正当竞争的法律保护构成商业秘密的信息，其中包括某些技术、工艺、组织以及其他具有经济价值并受到保密管理的信息。 [3]
因此，对于保密项目，仅删除客户名称可能仍然不够，其他细节仍可能泄露受保护的信息。
更安全的原则是：
只描述依据适用法律、合同、已取得的同意以及你拥有的其他权利，确实允许公开的内容。
不要因为同事参与了项目，就直接公开他们的个人数据
项目说明通常不需要整个团队的私人信息。
GDPR 要求遵守合法性、目的限制、数据最小化等原则，也就是说，个人数据应限制在实现相关目的所必需的范围内。 [4]
如果把团队描述为：
1 名用户体验设计师、2 名客户端开发人员、1 名服务端开发人员和 1 名质量专家
就已经足够，那么通常没有必要公开同事的姓名、照片、电子邮箱地址或其他个人信息。
如果你希望公开某个具体人的推荐语、声明、照片或其他数据，应确认适当的法律依据以及允许使用的范围。
项目不能公开时，可以展示什么？
如果合作条件允许以一般方式描述相关经历，可以考虑展示：
- 不识别客户身份的问题类型，
- 自己的角色，
- 使用过的能力类别，
- 承担的责任类型，
- 在适当概括程度下的决策过程，
- 只在允许公开的范围内说明结果。
不要为了替代保密材料而虚构截图、数据或结果。
如果不确定某项信息是否允许披露，在确认之前不公开通常更安全。
有助于保持准确性的表达方式
措辞上的细微差别可以非常清楚地表达责任程度。
我负责... - 明确说明自己的责任范围。
我主导... - 表示自己对某个领域的方向或执行承担责任。
我共同完成... - 表示该结果由不止一个人共同创造。
我支持... - 如实说明支持性质的贡献。
我是完成...的团队成员之一 - 把个人参与与团队整体结果区分开。
项目上线后，公司记录到... - 把结果作为背景说明，而不是自动把全部效果归到自己名下。
如果实际工作范围是多人共同承担的，就不要习惯性地写成“这是我做的”。
六个可能说明你夸大了个人贡献的信号
1. 一个由多人完成的项目，却使用像是一个人独立完成的表述。
2. 展示业务结果，却没有说明自己的具体工作范围。
3. 把整个产品使用的技术都写成自己的能力，尽管自己并没有实际使用其中全部技术。
4. 展示最终视觉设计、代码或策略，却没有说明哪些部分实际上由自己完成。
5. 在理解项目必须知道其他核心贡献者的情况下，却省略他们。
6. 暗示自己的工作与某项结果存在因果关系，却无法提供合理依据。
团队项目说明的简单模板
项目
当时在创建什么，要解决什么问题？
团队
哪些角色参与了项目？
我的责任
我个人具体负责哪个领域？
我的行动和决策
我具体做了什么，或者主导了什么？
协作
哪些内容是与其他人共同完成的？
工作成果
哪些内容可以合法公开？
结果
项目取得了什么结果，我的贡献与这些结果有什么关系？
限制
是否有因为保密义务或他人权利而不能公开的内容？
发布前再读一遍项目说明
问自己七个问题：
1. 读者知道团队规模吗？
2. 我具体负责什么是否清楚？
3. 我是否避免把其他人完成的工作归到自己名下？
4. 我是否以适当谨慎的方式描述结果？
5. 我是否合法有权发布所使用的材料？
6. 我是否避免了不必要地公开个人数据或保密信息？
7. 外部读者能否仅根据这段描述理解我实际使用了哪些能力？
如果这些问题的答案都很清楚，项目说明就会成为能力的证据，而不仅仅是一个好听的故事。
好的作品集不会通过弱化团队来突出个人
最好的项目说明不需要在下面两种说法中二选一：
“这是我做的。”
和：
“这是团队做的。”
它可以同时表达两个事实：
团队交付了一个明确结果，而我负责其中一个具体部分、相关决策和执行。
这种准确程度可以让人评估个人专业能力，同时不会夺走其他参与者应有的功劳。
可信度始于准确
作品集不应该成为谁能提出最大个人功劳主张的比赛。
当阅读者能够理解以下信息时，作品集的价值才会提高：
做出了什么、谁参与了工作、你负责什么、你亲自做了什么，以及哪些结果可以合理地与你的贡献联系起来。
准确的说明不会削弱成就。
恰恰相反，它表明你理解自己的责任，能够与其他人协作，并能够诚实呈现工作的实际结果。