要描述一个与团队共同完成的项目，既不夸大自己的份额，也不把它压缩为零，关键在于让两个代词在同一条条目里各司其职："我们"用来说明团队共同交付的成果，"我"用来说明你个人负责的那一部分。如果一整条只用"我"来描述其实是多人共同完成的工作，一旦被追问就会显得夸大其词；如果通篇只用"我们"，读者又完全无法知道你具体贡献了什么，这就失去了在简历上写出这个项目的意义。
为什么共同完成的项目仍然需要写出你自己的名字
招聘经理阅读一条团队项目的简历条目时，其实是在尝试回答一个问题：如果我把这个人招进团队，他实际上会做什么？只陈述团队共同取得了什么成果，回答的是另一个问题，即这个团队作为一个整体具备什么能力，却把这份共同努力中哪一部分是你亲自完成的留给读者去猜测。这正是一句具体说明你个人贡献的话所要填补的空白。它不需要，也不应该，为整体成果邀功；它只需要用一个短句，说明共同成果中真正由你构建、决定或修复的那一部分。
在同一条条目里区分"我们"和"我"
在同一条条目里同时容纳这两种真实情况，最清楚的办法是让每个代词承担不同的任务，而不是整句只用一个代词。第一句描述项目及其成果，可以诚实地使用"我们"，因为这个成果确实是团队共同取得的。第二句，或者同一句话的后半部分，再收窄到"我"，说明真正属于你的那部分：你构建的组件、你做出的决定、你发现的问题、团队里没有其他人碰过的那部分系统。读者并不指望一条团队项目条目只描述你脱离团队独立完成的工作；他们期待的是，条目能清楚说明团队的工作止于何处，你个人的工作又从何处开始。
精确说明你的部分，而不是含糊其辞
"参与了"是最容易低估一项真实而具体贡献的说法，因为它对几乎任何程度的参与描述得同样模糊，无论是只写了一个函数，还是主导了整个工作。具体说出实际负责的那部分内容，比如你负责的服务、你搭建的集成、你完成的迁移、你建立的评审流程，能给读者一个具体可评估的信息，而不是一句几乎可以指代任何事情的话。这与在不虚构数字的前提下量化工程影响一文中提到的转变是一致的：把模糊的范围描述变成具体、诚实的描述，精确度读起来比听起来圆满但含糊的说法更可信，而不是相反。
归功于团队，同时不丢掉属于你自己的那一句
诚实地说明一个共同成果，并不要求对自己的贡献只字不提，也不要求把那部分夸大。一条项目条目可以先明确说明某个规模的团队共同完成了这件事，然后再接一两句具体说明你本人的内容，两者互不削弱。先写团队的那句话，并不是让你吃亏的慷慨之举；它是在为读者建立正确评估后面个人贡献那句话所需的规模和背景。不知道一个项目涉及五名工程师、历时六个月的读者，与知道这一点的读者，对同一句关于个人贡献的话会有截然不同的理解。
说明示例：一条点明个人贡献的团队项目条目
说明示例，从模糊到具体。模糊：参与了一个团队，负责搭建新的结账流程。具体：作为四人团队的一员，在一个季度内重构了结账流程；负责支付重试逻辑，也就是流程中处理支付失败且不丢失客户购物车的那一部分。第二个版本先诚实地说明团队规模和时间跨度，再具体说明共同成果中可以明确归属于个人的一部分，让读者既了解团队做了什么，也了解这个人具体在其中做了什么。
几种值得避免的写法
整句用被动语态写成的条目，例如"结账流程被重构了"，把团队和个人都藏在一个没有主语的句子后面，这读起来像是回避，而不是谦虚。把团队的全部成果罗列成一连串不间断的"我"陈述句，一旦被熟悉该项目的人、了解这家公司的面试官或做背景调查的人细看，就会显得夸大其词。两相比较，先诚实地说明团队，再具体说明自己的那部分，既是更准确的描述，实际上也是最经得起推敲的写法。
团队项目在简历中的位置
团队项目通常与个人项目放在同一个板块，可以是一个独立的项目区域，也可以是（如果项目是在某份工作期间完成的）挂在那份工作条目下面。Developer 模板在项目条目中留出了空间，既能写一句简短的团队规模说明，也能在下面写具体贡献的句子，正好适配这种两段式结构，不必把任何一半塞进一行局促的文字里。无论团队项目是某条条目的核心内容，还是像在软件工程师简历上展示个人项目一文所讨论的那种、附加在个人项目旁边的较小补充，同样的排版方式都适用。
把它加进你的简历
诚实描述的团队项目，是简历所能提供的最有力证据之一，因为它表明你既能在团队中工作，又能清楚说明自己在其中的具体贡献。从一个专为这类条目设计的模板开始，在编辑器中加入你自己的项目。