全职工作快要 2 年了，想找个机会来复盘一下自己的工作，一直被各种各样的事情耽搁了。在我看来，定期的复盘对于做任何事都是重要的，这可以从一个更加客观的角度审视自己。公司内部的 OKR 复盘可以量化地衡量我们在短期任务上的结果，但是并不能帮助我们在一个更长的时间维度上持续地提高自己，产出更多价值。它更像是对局部最优的探索，我们需要跳脱出棋盘，从全局的角度复盘自己。

在过去一年多的工作中，我的大部分角色是执行者。执行者的角色，最重要的能力是执行力：对待同事或者 Lead 交代的事情，能否在评估好的时间内保质保量地完成。除此之外，企业，或者说 Lead 对执行者的期待，还会包括对于所负责的事情的主动探索，积极地从自身的角度推动工作的持续进行。在过去的工作中，我也曾经遇到过这样的问题：因为与 Lead 对需求或者目标理解上的不一致，导致做了一些不真正产生价值，或者说 Lead 认为不真正产生价值的事情。这就涉及到执行层面的另外一个能力，沟通能力。

当然，沟通并不意味着是简单地理解别人的想法，回到上面提到的问题，我与 Lead 的分歧主要在于对需求理解上的不一致。当你去负责处理某个任务时，在这一任务上，你的理解可能要比你的 Lead 更加深入细致，所以如果必要的话，需要坚持己见，努力说服利益相关方同步到你的认识上来。我认为在一个完美的理想化的公司中，沟通能力是锦上添花的能力。当所有人都是纯粹的理性人时，大家考虑问题都是从理性的角度出发，往往能够得出更好的结论。

但是，实际工作中，这样的公司绝对不存在。人都是感性的动物，在工作中，员工不像是学校里的研究生本科生们，为了学历不得不安心做事。学校里导师和学生的关系，是毫无置疑的上下级。读个研究生需要动辄两三年的时间，而导师基本可以认为掌握了对你的学位授予权，而且是合法的。我认为这在东西方都是普遍存在的问题，只是东方可能更明显一些。过高的退出成本会让研究生无法拒绝一些自己不认可的事情。

但是工作中，相对而言没有这么夸张。因此无论是同事还是 Lead，都需要更加尊重彼此的感受，也更加需要掌握沟通的能力。这一点我深有感触。同样一句话，用不同的方式说出来，会给人不同的感受。人真的不是完全理性的动物，或多或少会受到感情的影响。更何况在实际中，同事之间的目标并不是完全一致的。不同的职能，不同的部门，不同的小组都有着自己不同的目标。虽然这些目标落实到公司层面都是为了公司更好地发展，但是 A 部门关心的事情可能与 B 部门毫无关系，但是它却急需 B 部门的支持。

可能在学校里的很多同学对这一点感触不深，举个例子。去年，我在公司里的部分 OKR 与博客文章有关，需要为市场部供稿一定数量。所以我会花时间设计与构思文章内容，提高文章的质量。而在今年，这一 OKR 并没有落实到我们团队中，因此很明显，我对于投稿文章的动力就会大大降低。而对于市场部来说，他们仍旧希望我们能够积极供稿原创内容，扩大公司的技术影响力。这里就出现了冲突，尽管我们都是为了公司而工作，但是目标的不一致导致我们合作比以前困难了。

所以，在实际工作中，沟通能力比我之前预想的会更加重要。这在开源领域也同样成立。协调各个利益相关方，求同存异地确保大家能共同致力于一件事情，是非常困难的。这要求我们首先要学会换位思考，不能只关注在自己的目标上。其次要能高效而有逻辑地交流，还需要言出法随，尽量不要打破自己的承诺，尤其是对其他相关方的承诺。这样才能在长远的合作中培养信任。

在我看来，掌握了这两个能力，可以被称作是一个不错的执行者。但是，我认为一个好的执行者，还应该注重商业意识，业务知识。这也是我这一年工作中体会很深刻的一点。在学校的时候，我十分排斥直接面向用户的业务，比如 ToC 的业务。因为我在那时认为面向用户的业务，技术并不是重要的。这样的理解现在看来是非常片面的。无论是什么业务，都是与商业密不可分的。技术永远只是手段，盈利才是企业存在的意义。只是在有些业务领域，技术的门槛可能高一些，但是仍旧是为了业务服务的。

放到现实中，这就意味着哪怕你是在做着基础设施这样的底层工作，也要对商业有着基本的了解。要了解自己所在行业的商业模式，理解行业中不同的职业有着怎样不同的职能，他们是如何协同工作的。要了解你的用户/客户，他们为什么要为你们的产品买单。同时最好要了解这一领域中的企业都是如何进行估值的，这可以反映出投资机构是如何看待这一行业，更加看重公司的什么方面。对业务和行业的理解可以帮助你更加理解公司的决策，在日常工作中更合理地划分手里任务的优先级，将自己工作中的目标与公司的目标统一起来。这样你也更能理解，为什么技术债务在相当长的时间里一直得不到偿还，为什么我们的基础设施还停留在低版本等等一系列在刚刚从业时比较难以想象的问题。因为从商业上来讲，在没有成为瓶颈之前，解决这样的问题并不能够带来任何收益。

当然，也不排除一些公司就是技术公司，像以色列的不少公司，就专注于技术，最终的目标是被收购。这从某种意义来说，也是为了盈利，只不过会更加依赖技术。我们看重商业的价值，产品的意义，但是也要明白技术的力量。过度看重或者看淡技术，都是不可取的，技术能力永远是工程师的核心竞争力。

在今年开始，我也慢慢开始承担一些 TL 的角色，帮助团队更好地进行新需求的技术调研，和开源版本的探索。在其中有了一些跟执行者不一样的体悟，两者最大的一个不同在于责任。在理想情况下，TL 应该只需要负责投入方向的把控就好了。TL 结合公司和部门的策略和目标，来确定在技术上我们要往什么方向发展探索。同时协调好跨团队的合作，确保当团队里的同事需要外部支持时能够得到充分的支持。但是现实永远更 dirty。

在跨团队的合作方面，协调其他团队的投入在我们这样体量的公司里不是太困难。前段时间请镜像仓库组的同事帮忙在 Harbor 社区中实现一个特性，尽管他们的负载已经非常非常高了，仍然很轻松地就聊定了。但是可以预想到，在更大规模的公司，这会是一个比较困难的过程。而且跨团队的项目，对时间规划的要求比团队内要高许多。参与的团队越多就越复杂。这样的项目会相当大程度上降低工作的效率。因此对于需要长期合作的项目尽量流程化，对短期合作的项目尽早约定 scope，各自开展。比较麻烦的是具有依赖的合作，下游依赖上游工作的产出，这会让工作变成串行。这时候能做的只有尽可能把工作流水线起来，用流水线来 hide 掉一部分成本。

这一年多的工作，我对商业，对业务有了更清晰的认识。在学校里呆久了，确实对这些的看法有些狭隘了。我们生活在商业世界中，它就像房间里的大象，是我们绕不过的存在。对于在工业界讨饭吃的你我来说，真的需要学习一个。之前我不喜欢跟人谈论估值，谈论商业模式，我觉得与我无关。但现在，我觉得它与每个人都息息相关。

License

• This article is licensed under CC BY-NC-SA 3.0.
• Please contact me for commercial use.