如何有效通过试用期、降低被 PIP 的风险?

之前有读者提问加入新公司时，应该注意或准备哪些事情。

我们过去写过 如何快速与团队建立关系、有效合作? 一文，介绍如何撰写 How to Work With Me 文档；也在求职线上课程中谈过找到工作后，如何为新工作做好准备。

除了上述内容外，在刚入职新工作时，还有其他值得留意的面向。

许多公司会设置试用期 (常见的 probation period 或 trial period)，不少人会担心自己无法顺利通过。因此这篇文章会更详细地说明，刚加入新公司或新团队时，应该留意哪些事情、做好哪些准备，协助读者顺利通过试用期。

其实这篇讨论的重点，不只适用于有试用期的公司。许多美式文化的公司虽然没有明确的试用期制度，但常见「快速开除 (fire fast)」或「绩效改善计划 (PIP)」的文化。在这种环境下，即使没有试用期规定，只要入职后的表现没有达到预期，也可能很快被开除。因此，掌握本文的重点，对这类读者同样有帮助。

没有通过试用期的常见原因

刚加入新公司的读者，可能会担心自己无法通过试用期。以下列出几项常见原因，供大家在入职初期自我检视。

最常见导致未通过试用期的原因：

很多人在试用期确实投入大量时间，也完成了不少任务；但即便如此，还是拿不到理想的评价，甚至可能被判定未通过试用期。

要避免这种状况，关键在于先厘清什么是「对的事情」。

要做出判断，就要了解你的绩效如何被衡量。更具体来说，试用期间公司或团队对你的期待是什么？如果你无法明确写下来，就要善用和主管 (工程经理) 的 1:1，主动确认对自己的期待；尤其在前期，建议维持至少一周一次的频率 (等通过试用期，或更熟悉公司与团队后，再拉长间距)。

在辨识应该做什么时，也建议从自己所在的职级切入。我们在工程师的职涯路径概览中谈过，业界通常会对不同职级的工程师有不同期待。

如果没有达到这些期待，即使产出很多，也可能因为方向不对而未能通过试用期。举例来说，许多团队对资深工程师的期待，是展现系统设计能力与团队领导力。如果你以资深职级加入，却始终只做初阶或中阶工程师的工作内容，即使投入再多，也会被认为没有达到预期。

在掌握方向、知道该做什么之后，下一步就是透过行动拿到具体成果。对工程师来说，如果只知道方向却没有产出，绩效评估时仍可能无法通过试用期。

事实上，刚加入团队时，大家不会期待你短时间就有巨大产出；但从小的成果开始，证明自己能把事情做好，对前期来说非常重要。有位前 Meta 工程师分享，自己换工作后第二天就送出第一个 PR，第三天顺利合并，这件事在和主管 1:1 时得到称赞 (链接)。

若想更有效率地产出，建议「主动观察」团队里被认为最重要的人，或表现突出的同事，看看他们如何做事，包括写代码、撰写技术文档、带团队 (例如在会议中的互动方式、给反馈的方式)。

通常被团队认为重要、表现亮眼的人，已经掌握在团队里高效工作的做法；透过观察、复制他们的方法，可以大幅提升自己的产出效率。举例来说，如果想更快熟悉代码库，可以主动提出 pair programming，从旁观察对方如何处理代码。

对许多工程经理来说，打造高效团队不只需要成员个人表现出色，也要确保团队整体运作顺畅。因此，即便你做对事情、产出不错，只要无法和团队顺畅合作，本质上仍可能无法通过试用期。

我们在 如何快速与团队建立关系、有效合作? 一文中写过如何有效建立关系与协作。不过，对刚入职的工程师来说，还有一件事特别值得注意：在推动任何改变之前，先建立他人对你的信任 (build trust)。

尤其是资深工程师入职后，常因为新团队的运作方式与自己过往经验不同，而提出新的观点。提出观点本身是好事，但在没有建立信任前就贸然推动改变，可能带来反效果。

想建立信任，最推荐的方法就是先理解「为什么」团队会这样做，让你提出的改善方案更贴近团队的现实情境。同时因为原本的团队成员有被征询意见，反弹也会较小。

我们曾遇过的真实案例，是一位从知名大厂跳槽来的同事，在加入团队后认为大家处理监控响应的方式不符合业界最佳实践，于是在入职不久就提了新的轮值制度 (on-call rotation)。

提出方案后，团队里待得较久的资深工程师很不开心，觉得这位新人根本没搞清楚状况。事实上，团队并不是没试过这项最佳实践，只是因为产品特性与团队运作方式不同，不适合继续沿用。

由于这位新同事没有先了解背景，就直接以「我的做法比较好」的态度推动改变，引发资深成员的不满。也因为一开始没建立信任，他之后想推动其他事情时，大家都会特别放大检视，导致执行变得困难。

当别人对你产生不信任，要扭转这种印象所需的心力，会比一开始就建立信任多得多。反过来说，如果先建立信任，别人相信你会把事情做好，就会更愿意支持你提出的改变。