近几年我在职场踩过的坑

Posted 2021-07-10 前端开发博客

点击下方“前端开发博客”关注公众号

回复“2”加入前端群

文章转载自：laike9m，文末有原文链接。

正如大家所知，我最近换了一个组。回顾过去几年，被坑的时候实在不少。从中我意识到了一些事情，故用这篇文章记录一下，也算再给自己的想法做个 snapshot^[1]。文章的三部分别讲项目、老板以及组的坑。最后再聊聊换组。

这里的“坑”不单指外界的坑，也包括自己犯过的错误。本文的适用范围还请读者自行判断，毕竟大到公司，小到组和部门，它们的差别都极大。你觉得和你遇到的情况不符，请不要杠，这没意义。虽然这么说，我觉得大部分内容还是通用的。另，有些英文说法没有翻译，但都不难理解。

项目的坑

当需求不是直接来源于用户时一定要谨慎

我转组的原因之一是 2020 年做的大项目失败了。项目实现了规划的功能，架构也清晰合理，但没有达到预期的 impact，而我原本是指望用它来到 L5 的。为什么会这样呢？归根到底，这个项目并非来源于客户的直接需求，而是老板拍脑袋想出来的。我的（前）老板某一次和其它几个老板聊天，发现其它组都有一个工具。他觉得这玩意我们大部门也挺需要的，那就找人做吧。不是说它完全没用，毕竟我们最终还是找到了两个客户，但我们很想推的组没推动，并且未来大概也不会有更多用户。后来我才知道老板先问了我的 TL (Tech Lead)，TL 没有接，然后才找的我。TL 依靠丰富的经验避开了这个坑，但我就没那么好运气了。结论：需求不是直接来源于用户是一个巨大的危险信号。

内部 2c 项目（大概率）好于 2b 项目

这里仅讨论内部工具项目，不适用于面向外部用户的产品。几年下来我有一个很直接的观察，成功的内部工具基本都是 2c，很少有 2b 的。可能有人会好奇，内部工具也有 2b2c 之说吗？有个很简单判断方法：一个工具或系统，如果工程师能自己用起来，那就是 2c；如果需要部门里 >1 人讨论并决定，那就是 2b。举两个例子：一个开箱即用的任务监控面板是 2c 的，而一个需要修改 release 流程才能使用的工具就是 2b 的。当然，我观察到的样本很少，所以结论未必对。但我真心感觉 2b 的东西想推动，要花费几倍于 2c 工具的时间，效果还未必好。总之如果你有的选，请尽量把时间花在 2c 项目上。

警惕那些依赖其它组的项目

OKOK 我明白，世界上就没几个不需要跨部门合作的项目。但合作方式也是多种多样的。假如对方是你的客户，你需要和他们沟通来实现一个需求，又或者大家同属一个大组做同一个产品，这种就没问题。而当对方在你的关键路径上——比如你想做的东西没有对方配合就完不成，且你们又是跨部门，这种就有很大风险。如果你正在参与此类项目，请一定确保：

• 双方（或多方）要 aligned（阿里话的“对齐”），尤其是老板之间。包括对项目的预期、优先级、工期、资源投入，都必须互相知晓并认可，而且要落实到 OKR 层面。不要相信工程师的口头承诺，我被坑过，而且很惨。• 要有定期例会。• Escalate（上升）的渠道一定要通畅。当对方没有按期交付或出现各种问题时，你要能通过自己老板向对方施压。这也是为什么双方老板的支持是必需的。

了解组里其它人在做什么

除了上面提到的那个项目，其实我曾有更好的机会升 5。我们组有个项目，本来由两个人分别负责前后端，结果后端哥们儿写一半离职了。后端是用 C++ 实现的，而我当时是组里唯一有 C++ readability 的人，如果申请接手，老板 100% 会同意。然而我当时埋头于自己的任务，完全不关注组里其它人在做什么（即使我一直帮他们 review 代码）。因为不了解，也没有意识到这个项目的潜力。后来这个项目交由前端哥们儿负责，并且成了组里的重点项目。我就这么错失了好机会。说白了这又是“选择大于努力”的例证。

于是我决定，进新组之后至少和每个人 1:1 一次，即使他们的工作看起来和你毫无关联。同时关注各种新提案和设计文档，了解其它人在做什么。除了寻找可能的机会，这也有助于站在更高视角全面理解当前的工作。

不要对项目产生感情

我当初之所以选择换到现在的组，主要是因为（前）老板答应我可以继续之前的工作——一个我很喜欢并认为有很大潜力的项目。时至今日，这个项目完全兑现了潜力，然而我却因此耽误了两年。如果当时抛弃对项目的感情，我完全可以找个更合适的组。转组的事之后会细聊。

老板的坑

之前和 Phil 做过一期节目^[2]聊了这个话题，不过我们遇到的情况不尽相同，感兴趣的可以去听一下。我只说我遇到的情况。

不要盲目相信老板

我的三任老板都有过很离谱的判断：

• 第一任老板认为写什么语言都不影响换组（我一开始写 Dart。。。）。然而事实就是换组非常看背景。很多组明面上说可以进去再学，实际上都希望申请者会写特定的语言（等着进去再学的人根本拿不到面试：）。• 第二任老板极度厌恶 C++ 并热爱 Java。他要求我把一个 C++ 服务用 Java 重写。这明显是个费力不讨好的活，但又不能不干，于是我和老板说服了另一个人去写。结果如我所料，他花了时间却没拿到任何 impact（真对不起他）。• 现任老板比较短视。他上任后大刀阔斧地砍项目（交给别的组维护），理由是我们要 focus 在几个重点项目上。很多成功或有潜力的项目都上了被砍名单。问题是 EngProd 组的活本来就少，被这么一砍，不少人拿不到足够有 impact 的项目，只能做些小 feature。去年离职了好几个，今年目测还要跑一波。

所以我认为，老板的话要听，但决策一定要自己做（或者说，做自己认可的决策）。这里面有个更本质的原因。自己做决策，即使错了，也可以复盘反思，并取得进步。而让他人做决定，自己将很难进步——对不知道对在哪，错也不知道错在哪。

警惕只想把你当工具人的老板

我换组的另一个原因是发现老板有把我当工具人的倾向。在 Google，好的老板要能平衡组与组员的利益，既保证组的发展，又确保个人能够成长（说白了就是晋升）。前两任老板虽说都给过我坑项目，但至少他们会和你聊个人发展并给出建议。这些我都看在眼里。现老板去年还是工程师，在前老板走后被提拔上来。一开始的感觉是他不太关注我的项目，即不了解也不想去了解。今年 Q1 快结束时，事情开始变糟。如之前所说，老板开始砍项目，并把我调往那个我曾经错过的项目。本以为老板打算让我从现在开始 own 它，然而并不是。老板的意思是让我 Q2 去实现一个比较重要的功能，后续安排再议。从我知道的情况看，这个项目中很有 impact 的一块已经被分给了一个即将到来的 intern——是的你没听错，intern。我问老板：明明这个 feature L3 工程师就能做（简单的 CRUD），并且对他们晋升帮助很大，为什么让我来？老板说你擅长这块，你来做比较快。话说到这份上，继续聊下去已经没太大意义了。

怎么判断老板有没有把你当工具人？我觉得有这么两点：

• 看老板给不给你做职业规划。好的老板会说：我觉得你想晋升，impact/difficulty/leadership 还不够，做XXX任务可能对你有帮助，或者我们一起想想能做什么。把你当工具人的老板不会给你规划。• 看老板对你是否诚实。我曾对现老板说：仅仅加这个功能基本上就是 L3 的活，感觉对我晋升没有帮助。老板说不要紧，只要你做得快，拿 SEE（类比 3.75）是没问题的。在我看来这就是典型的不诚实，或者职场 PUA 话术。你再资深，该花的时间还是得花，收集需求、设计、实现、测试，这其中有的时间是你无法控制的。资深工程师无非是做出来的东西稳定一些，考虑更周全，bug 更少，并不是一定就能做得更快——因为最快的方法永远是糙快猛。

如果是前老板，我觉得他会说：“虽然没法让你到 5，但我们有客户急需这个功能。我们可以规划一下之后的安排，比如让你顺势 own 这个项目，或者找一个更好的项目”。诚实是最重要的。不要骗我们，我们不傻。

当然，现老板也和我聊过晋升。他说如果我想晋升就得自己想一个好项目。于是我想了一个 impact 很大的，写了提案给相关组审阅，他们很满意。然后老板说我们不做这个，要 focus。我：？？？

组的坑

组的坑既是最好聊的又是最不好聊的。相对来说，组的坑比较明确，容易提前识别。但另一方面，组的坑多种多样，且和老板和项目都有关联，难以穷尽。所以这里只说说我知道的那些。

业务/技术/个人兴趣，至少要占一项

有的组业务有前途，有的组技术有挑战，有的组两边都有，有的组两边都没有。两边都没有的基本就是坑，这种组在大公司相当多，比如 Google 的 EngProd。当然，如果某个组做的东西就是你的兴趣所在，那就加入吧，这时候别的都没那么重要了。

Fake infra 和 True infra

EngProd 具体怎么坑，我以后或许会专门写篇文章讲，但最根本的一点在于他们负责的是 fake infra。EngProd 全称 Engineering Productivity（研发效能），现在的 title 虽然是 Software Engineer，但在 2019 年以前是 SETI（software engineer, tools and infrastructure）。有人一看到 "infrastructure" 这个词就被唬住了，以为做的是什么不得了的东西。然而 EngProd 虽不负责业务，做的东西却也跟 infra 不沾边，我称之为 "fake infra"。比如修改一下公司的集成测试框架给某个组用，帮某个组优化 presubmit/postsubmit time，减少 test flakiness，诸如此类的杂活是 EngProd 传统艺能。我理解公司设立这个职位的初衷就是把杂活分出去，让 SWE 们专注于开发。

True infra 和 fake infra 的区别是什么呢？我觉得 true infra 一定是有技术挑战的，且至少要服务于某个大部门（比如 Search/Ads/Cloud），而不是一个或几个组。那些大家耳熟能详的技术都是 true infra，比如 Spanner，F1，Flume，Bigtable 等。有意思的是，做 true infra 的组从来就不属于 EngProd，而 EngProd 也从来不负责 true infra。

不要去 scope 太小和前景莫测的组

记得第一任老板总是强调要了解 big picture，当时不懂，现在才发现说得真对。Scope 指一个组负责的工作或者产品有多大。比如前面说到的 true infra，他们的 scope 就是全公司，而 EngProd 组的 scope 则通常是一个部门（几十到一百人）。面向用户的产品更复杂一些。比如 Gmail 和 YouTube 虽然有几十亿人用，但某个组负责的小功能却未必。这时候你只能依靠经验去判断。很多时候我们看不清，这不要紧，但至少有一些坑是可以避开的，比如 messaging app。

我第一次换组的时候也犯过错误，为了能去搞 AR 花了很多时间^[3]学图形学，导致没怎么认真看其它组。现在想起来觉得自己真蠢：在 Google 做 AR 没前途不是明摆着的么？到今天为止都没有一款面向消费者的成功 AR 产品，更不要说在这方面投入不多的 Google 了。而且说白了我也不是真的有兴趣，只是觉得这个技术很酷而已。当时犯的错误，现在要用几倍时间来还。

换组心得

下面来聊聊换组。虽然和上一节相关，我还是决定单独拿出来说。很多公司不像 Google 有这么多换组机会，还可能面临老板不放人的情况。因此我不打算写换组的流程，而是把重点放到“选组”上，尽可能让内容通用一些。

关注具体的工作内容和大方向

只看产品选组还不够，具体的工作内容和大方向也很重要。比如一个明星产品组招人可能是为了是搞测试，而一个内容平台的年度 OKR 可能是加强审查。要了解一个组的方向，最简单的方法是去看它的年度 OKR。如果找不到，一定要和老板问清楚。

我遇到过这么一个组，他们有 hc 所以打算先招几个人，至于做什么等进去再分配。这也是一个危险信号。通常来说，一个职位的职责越明确，项目的风险和掉坑的概率就越小，也能让你做出更有根据的选择。

Impact 是否好兑现

我实在不知道 impact 怎么翻译比较好，“影响力”这个说法其实不准确，所以我就不翻了。Impact 是否好兑现，我们可以通过举例说明（注意，好兑现和“大小”是两码事）：

•好兑现的：• 实现一个面向用户的新功能• 依赖的 API 要 deprecate 了，使用新 API 重构系统• 优化响应时间• 给覆盖率很低的项目写单元测试•不好兑现的：• 做一套测试框架• 重构系统，但是功能不变• 优化调试或监控工具

好兑现的项目简单明了，只要做完了 impact 就实打实地在那，不需要费劲给人解释。不好兑现的则各有各的问题：

• 做测试框架：做了并不代表有人用，没人用那 impact 就是 0。你得花心思推广。• 重构系统：你觉得老代码写得太烂了难以维护，所以要重构。问题在于证据呢？这时候你就必须得收集数据，比如证明在老代码下加一个功能平均需要三天，而重构以后只需要一天——假设你能拿到这么理想的数据。实际情况往往是拿不到，或者并没有显著差异。• 优化调试或监控工具：这里的困难还是在收集数据，你怎么证明改进后比改进前要好？并不是说证明不了，而是需要花心思。

优先选择 impact 好兑现的组。一般来说，做新东西比较好兑现。

和工程师聊天

和老板聊天往往容易浮于表面，或者大饼满天飞。找到组里的工程师，一般他们都会毫无保留地告诉你真实信息。我会问很多尖锐的问题，比如“你觉得组里有哪些缺点”，“晋升速度如何”等，还会详细了解工作的细节。有个工程师直接告诉我，如果你想晋升，就不要来我们组——老板们断然是不会这么说的。如果你觉得在职员工讲话会有顾虑，也可以找刚转出去的员工。实际聊下来我没发现有太大差别，只要是工程师都会如实说明情况。

什么时候该考虑转组？

这个问题没有标准答案。我现在倾向于认为只要满足条件（Google 的要求是待满一年），就可以开始关注新机会了。我们有个系统可以设置 filter，出现满足条件的内部转岗机会会自动给你发邮件。每周看一次邮件其实花不了几分钟，而且看机会并不意味着一定就要走。别看每天都有很多组在招人，实际上单看某一个组，招人的窗口都只占一年中的很小一段，甚至有的组几年都不招。很多机会错过就是错过了。

有种情况我会建议你立马开始看机会：人事变动。不论是老板离职还是组织架构调整，只要是人事变动，多多少少一定会影响工作。影响可能好可能坏，可能多可能少，你无法预测，所以最好未雨绸缪。尤其如果老板给你提供了很多支持，甚至本身就是项目的发起者，当他离职之后你的工作必然受到冲击。事情变坏往往就是一瞬间的事，如果没有准备可能会措手不及。当然这里还是要强调，看机会不等于一定要换组，只是给自己准备一条后路。如果一切照常甚至变好，那完全没有换组的必要。

总结

相信你现在也感受到了我这几年是怎么被坑过来的。我当然希望一切都一帆风顺，但既然事情已经发生，也必须总结一下引以为戒。祝大家职场之路顺利。

引用链接

[1] snapshot: https://laike9m.com/blog/gong-zuo-san-nian-wo-xue-dao-liao-shi-yao,132/
[2] 一期节目: https://www.pythonhunter.org/episodes/ep14
[3] 花了很多时间: https://laike9m.com/blog/shi-tou-jian-dao-bu-you-xi,129/

❤️ 看完两件事

如果你觉得这篇内容对你挺有启发，我想邀请你帮我两个小忙：

1. 点个「在看」，让更多的人也能看到这篇内容（喜欢不点在看，都是耍流氓 -_-）

2. 关注公众号「前端开发博客」，每周重点攻克一个前端面试重难点，

   公众号后台回复「电子书」即可免费获取 27本 精选的前端电子书！

点个在看支持我吧，转发就更好了