作品集應該回答一個問題：這個人實際上能做什麼？
但在團隊專案中，還會出現第二個問題：
這個人具體做了什麼，哪些內容又是整個團隊共同工作的成果？
例如：
「我打造了一個有 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. 外部讀者能否僅根據這段描述理解我實際使用了哪些能力？
如果這些問題的答案都很清楚，專案說明就會成為能力的證據，而不只是一個好聽的故事。
好的作品集不會透過弱化團隊來突出個人
最好的專案說明不需要在下面兩種說法中二選一：
「這是我做的。」
和：
「這是團隊做的。」
它可以同時表達兩個事實：
團隊交付了一個明確結果，而我負責其中一個具體部分、相關決策與執行。
這種準確程度可以讓人評估個人專業能力，同時不會奪走其他參與者應有的功勞。
可信度始於準確
作品集不應該成為誰能提出最大個人功勞主張的競賽。
當閱讀者能夠理解以下資訊時，作品集的價值才會提高：
做出了什麼、誰參與了工作、你負責什麼、你親自做了什麼，以及哪些結果可以合理地與你的貢獻連結起來。
準確的說明不會削弱成就。
恰恰相反，它表明你理解自己的責任，能夠與其他人協作，並能夠誠實呈現工作的實際結果。