|
|
# 14 | 怎样展示你在项目中的重要性？
|
|
|
|
|
|
你好，我是白海飞。今天我想和你聊聊面试中，怎样介绍你的项目，以及怎样突出你的重要性。
|
|
|
|
|
|
面试中除了专项技术问答，另一个重头戏是“盘问”应聘者做过的项目。面试官通过了解你的项目工作，可以看到你和团队的协作过程、工作成果，以及你起到的作用，从而更准确地判断你的经验、技能、潜力和动机。
|
|
|
|
|
|
面试官的问题往往是这样开始问的：
|
|
|
|
|
|
* “看你做的项目不少，请介绍一个你认为最能表现你能力的项目吧。”
|
|
|
|
|
|
* “XX项目看起来挺复杂的，能否详细介绍下复杂在哪里，你的贡献又是什么？”
|
|
|
|
|
|
* “XX项目你做的时间很长，说说你都有哪些收获吧。”
|
|
|
|
|
|
|
|
|
这些都是开放性问题，应聘者的回答，常常有两个主要毛病。
|
|
|
|
|
|
1. **做事浮于表面：**做的工作不少，都想提一下，没有详略，不能在某个价值点上讲出深度。这种表现会让面试官觉得，你仅仅在浅层或者在外围干活儿，而很少或者没有深入解决过核心的项目问题。
|
|
|
|
|
|
2. **能力单薄：**细讲某一项目环节时，你只专注在项目问题的某一部分上，不能以完整的视角复盘解决方案，只具有任务级别的工作能力。比如，只清楚自己的模块实现，至于上下游过来的数据含义都不了解，也不知道自己写的代码是服务于什么业务问题。这会让面试官觉得，虽然你能编写代码，但没有协作意识，你很大程度上依赖别人完成分析调研，甚至连测试数据都要给你准备好，你才能完成任务级别的工作，这样表现出来的能力很单一。
|
|
|
|
|
|
|
|
|
总地来看，浮于表层的粗粒度表述，或者仅限于工作切片的表述，会让面试官“看不全”你在项目中的作用和价值，也就是看不到你在项目中的**重要性**。
|
|
|
|
|
|
那么，**怎么才能表达出对项目的重要性呢？你需要既展示项目级别的贡献和能力，又展示对项目关键问题的推动作用。**我从以下三个层面来讨论：
|
|
|
|
|
|
* 首先，前提是你要全面深入地了解项目，尤其是你负责的部分。这很好理解，因为如果你发挥了重要作用的话，你肯定对这部分了如指掌，甚至明察秋毫。
|
|
|
|
|
|
* 其次，你做出了项目结果。这是体现项目完成度的重要部分，是你重要性的最好证明，这是显性的。
|
|
|
|
|
|
* 最后，你推动了项目进展，这是隐性的。
|
|
|
|
|
|
|
|
|
## 项目结构
|
|
|
|
|
|
**当被要求讲述某个项目时，很多应聘者上来就直接讲复杂的项目方案，这是不可取的。**因为面试官在不了解项目背景和问题的情况下，很容易听糊涂，而且也不容易领悟到设计方案的精妙，除非面试官指明只听方案部分。
|
|
|
|
|
|
那么，要介绍一个完整的项目，应该包含几个部分呢？我总结为目标、方案、团队和过程。
|
|
|
|
|
|
* **目标，解释为什么要做这个项目，为了什么人，解决什么问题。**这包含从用户角度和全局角度来看项目的价值，例如“为了解决医院挂号排队太久的问题，我们做了手机挂号项目，使医院挂号流程和人力投入得到了巨大优化。” 能把这些解释清楚，说明你遵循结果导向，而且有全局观，做事动机明确，知道自己不只是在“搬砖”，而是在“盖教堂”。
|
|
|
|
|
|
* **方案，包括业务功能设计方案和技术设计方案。**前者是从用户交互角度解释产品功能，偏业务；后者是从技术实现角度讲产品设计，偏技术。一般，我会让应聘者在白板上画图，来展示功能模块、技术模块、数据流向等。
|
|
|
这是展现专业能力的重要环节，既要讲清全局脉络，又要讲出细节，显示你的跨角色视野和专业实力。这里要重点挑你负责的复杂性高的模块来讲，其中复杂性包括业务复杂性（比如“8种用户各有20种不同的处理情况”）、技术复杂性（比如“高可用性高并发的解决方案”）和管理复杂性（比如“9个国家50个城市的信息员，每天都要保持状态同步”）。 这里能展示你能力突出的两个点是：如何进行方案选型，以及如何控制风险。
|
|
|
|
|
|
* **团队，包括团队层级和角色。**讲清这块内容，能反映出你的协作意识，对于项目经理，这块是一定要介绍清楚的，因为这里包含着项目沟通复杂度和大量的管理风险。而对于业务角色和技术角色，你能讲清直接合作的角色和自己的关系，就基本可以了。
|
|
|
|
|
|
* **过程，即软件开发过程，是适**用**于产品方案的复杂过程。**即使你对产品方案很了解，但是做出来可能很难，这就是为什么即使拿到了芯片的图纸，依然做不出芯片的原因。从软件过程的描述中，面试官可以看到你的学习能力、协作意识和领导力。所以，即使是个开发人员，我作为面试官，也要问他项目开发用的是瀑布模型还是敏捷模型，团队角色在什么时候、用什么工具和资源、做什么动作，以及是如何协作的。
|
|
|
|
|
|
|
|
|
不知道你发现没有，团队的划分、产品的架构，以及项目的过程，是互相依赖、整体一致的。这部分的认知深度对于体现管理角色的管理能力，相当重要。
|
|
|
|
|
|
## 项目结果
|
|
|
|
|
|
**项目结果，是指项目做到的产出，以及这些产出的质量和意义，其中属于你贡献的部分要着重讲。**
|
|
|
|
|
|
你心目中的项目结果都有什么呢？代码、文档？这里我大致把项目结果分为两类。
|
|
|
|
|
|
* **可见的部分**。
|
|
|
（1）产品、服务、产品说明文档等；
|
|
|
（2）代码、运行环境、生产线（CI/CD pipeline）；
|
|
|
（3）各种过程说明性和控制性文档（需求分析、设计、代码规范、团队契约等）等实物。
|
|
|
|
|
|
* **不可见的部分**。比如，投入产出情况、项目完成质量、在线系统运行状况、各种业务数据监控指标、过程控制指标，等等。想一想，你平时关注哪些指标呢？
|
|
|
|
|
|
|
|
|
对项目结果的展示，有两个角度是面试官最关注的：做得好的和做得不好的。做得好的部分，要把做法和提高之间的因果关系说出来，以明确哪些做法要继续保持，适合在什么样情况下应用；做得不好的部分，重点展现你如何思考，有什么方法可以避免或改进。这是种反省能力，是你持续提高的动力，是面试官关注的一个重点（我会在“[30 | 怎么体现你能把工作越做越好](https://time.geekbang.org/column/article/88690)”一文细讲）。
|
|
|
|
|
|
把可见产出和不可见的项目指标讲清楚，可以体现出你“结果导向”的做事思想。结果导向，能够让团队更明确、更高效地达成项目目标，提高项目生产力，做更有价值的产出。
|
|
|
|
|
|
> **小提示：**
|
|
|
> 结果导向，是指先明确目标，再以目标为导向，指定合适的过程去实现目标，并且随时监控环境的变化和目标的完成情况，及时作出调整。
|
|
|
|
|
|
## 项目推进
|
|
|
|
|
|
讲好项目结构和项目结果，面试官就已经清楚了项目的基本情况，以及你的主要工作和产出。但是面试官可能还有个疑问：你在项目中是领头羊呢，还是拖后腿的呢？这对于判断你在项目中的重要性，是最关键的一问。
|
|
|
|
|
|
**虽然你的项目角色是相对固定的，但是你对项目的推进作用却是可以超越角色的。**
|
|
|
|
|
|
* 哪怕你只是个“小角色”，但是你的一句话，却给团队点破了一层很重要的窗户纸，项目困境一下就解开了，此时你起到的是**推进**作用；
|
|
|
|
|
|
* 你可能是个架构师，但其实你只是在平庸地做些常规的设计，你的设计并不能让产品更出色，此时你没有创新和引领，只是在发挥**执行**作用；
|
|
|
|
|
|
* 甚至你在工作中敷衍、拖延和不配合，使得项目延期、产品出错、团队士气下降，此时你在“**拖后腿**”。诚然，面试中你绝不会把自己描述成拖后腿的角色，但是面试官步步紧逼的问题，还是会让你后悔当初该多做点项目工作。
|
|
|
|
|
|
|
|
|
从哪里体现自己对项目的推进作用呢？想想在项目遭遇危机和挑战的时候，大家一筹莫展，你做过什么：有没有提出过缓解或解决困难的建议，主动采取过什么行动。这些建议和行动，有可能是改善技术方面的，也可能是改善流程和团队沟通的，甚至可能是增强客户关系或争取到领导支持的。总之，如果有，即使只是一点点，也是对推进项目有意义的贡献。把这点讲出来，让面试官意识到你的影响力，判断你对项目的重要性，从而推测你在新职位、新环境里的表现。
|
|
|
|
|
|
以下两种情况，不是面试官希望看到的。如果你有以下情况中的任一种，都需要好好反省一下，想一想如何改善。
|
|
|
|
|
|
* **你太重要了，重要到团队完全离不开你的程度**，你掌握了独特的资源或者技能，没有人做得了你做的事，你一天不上班，很多人的事情都没法顺利进行，那么说明你成了单一故障点（Single Point of Failure），这种情况会对项目工作造成很大的瓶颈，这不是面试官想要的。因为他可能会认为这是由于你不擅长分享知识和培养别人，注重自我保护，所以招你时会有顾虑。
|
|
|
|
|
|
* **自己的工作还没做好，就去影响或者帮助别人。**事实上，如果你没有能力做好本职工作，并且因此让跟你合作的同事有怨言，他们也不会非常期待你的帮助。
|
|
|
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
展示你在项目中的重要性，首先，需要讲明白项目结构，包括项目目标、方案、团队和过程，这表明你对项目总体有把握，对细节有掌控；其次，要讲清项目结果，重点放在你所做的提高和不足上，提高展示你的能力和贡献，不足展现你积极思考、持续进步；再次，从项目危机和挑战中展示自己的影响力。
|
|
|
|
|
|
以上内容涉及很多项目方面，不要误会，你在讲项目的时候，没必要都讲出来，时间不允许。你的讲述可以按照面试官的面试逻辑来：先概略讲表层事实，看面试官对哪部分更感兴趣，然后再展示深度细节，最后升华成观点感受。
|
|
|
|
|
|
有些人可能进项目组没几个月，就觉得已经掌握了开发技能，没什么可以学的了，进而感到厌烦，甚至想换工作。其实，这很可能是只看到了工作表面，此时不妨问自己几个问题：
|
|
|
|
|
|
* 有没有意识到背后的用户、业务、方案、团队、过程？
|
|
|
|
|
|
* 有没有想过当前方案的合理性和不合理性？
|
|
|
|
|
|
* 为了做得更好，在技术上如何改进？过程上呢？团队角色分工上呢？甚至组织结构上呢？
|
|
|
|
|
|
|
|
|
以上问题，可以帮助你更深层地了解工作，发掘工作的意义，给自己一个把工作做出彩儿的机会。
|
|
|
|
|
|
有些朋友可能会问，已经仔细想过上述的方面和问题了，但是依然找不出能显示自己重要性的点，该怎么办呢？那就聚焦你负责的那个小模块，把它当一个小项目看待，用上文的思路去挖掘各方面信息。如果发现还是挖不出深刻的内容，那可能是工作做得不太够了。
|
|
|
|
|
|
从现在做起吧，把手头的工作做扎实，超出领导的期待，**在做好本职工作的同时**，关注项目全局的业务、团队和管理活动，尝试从总体上思考如何做好工作。随着时间与经验的积累，你会发现自己的话语权会变得越来越重，甚至逐渐成了领路人。
|
|
|
|
|
|
## 思考时间
|
|
|
|
|
|
请你考虑最近项目中发生的一个问题或者挑战，都有什么人先后做了些什么，把问题扛下来了？这个过程你参与了么？你可以做得更好么？欢迎你在留言区和我分享你的想法，一同探讨提高。
|
|
|
|
|
|
最后，感谢你学习今天的内容，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。
|
|
|
|