聊一下字节跳动的 Tech Owner

字节跳动有个神奇的职责叫“Tech Owner”，直到今天，我仍然不知道这是哪里引入的文化，但总之，有这么一个角色。当业务部门的 PM 提出一个产品需求，走完流程到正式开发前，会正式敲定这么一个角色。

Tech Owner 是随便定的（可以这么说），谁都可以当这个角色，每个项目（需求）都会有一个新的 Tech Owner；Tech Owner 手上也没有什么权利，他既不是你的 +1，也不是你的 PoC 或者小组长，他没有权利去外部要申请什么新的资源，新的支持。

大家约定俗成，会让这个项目中改动最为复杂的开发做这个 Tech Owner，比如，如果这次需求会涉及主要的服务端 A，以及和 A 需要依赖的服务端 B，C，D 等等。主要角色服务端 A 需要频繁和 B，C，D 沟通，梳理梳理上下游依赖啦，统一统一接口规范啦，那毫无质疑，这里的主要的服务端 A 会被指定（or 推举）为 Tech Owner。

Tech Owner 是干杂活的

不要怀疑，上面说了这么多花花绕绕，在字节跳动，Tech Owner 就是一个干杂活的角色，这个角色就像橡皮泥一样，在项目里面去填充空隙，负责帮团队成员去 Cover 那些“空白”。

其实能做到这个，已经非常好了。
据我的观察，大多数人都做不好这个。

我们可以用传统的软件工程手段来实施项目管理，也是做 Tech Owner 最简单的基准线。刚才说了，Tech Owner 是跟着项目走的，项目就是大家一起原地搭伙吃个饭，要有人去捡柴火，有人去批柴，有人要负责生火，还有人要准备食材等等，这里的 Owner 就像是这次野营中带队的小队长。

太厚的项目管理书我没有仔细阅读，不过有一本书叫《极简项目管理》，从里面学到了一些简单的可以实践的项目管理工具。

只要做以下 3 个项目管理工具，就是一个及格的 Tech Owner 了：

• Kick-off 会，这个有时候会被其他会所取代
• 画时间轴，画交付表
• 及时同步风险

但是我上面说，“大多数人都做不好这个”的意思就是：根据我的观察，大部分人对项目管理毫无概念 —— 毕竟是研发，程序员对项目管理工具不够了解，对项目本身的理解不够深刻，也是可以谅解的。

为什么大家都做不好 Tech Owner 这个角色

如果做不好这个角色，第一点是项目管理，就是上面提到的，对项目的认知不够。
还有一个点，我认为大部分的因素要归因到公司的制度上，当你当了 Tech Owner 之后会发现 —— Tech Owner 也是要干活的。

对的，不可思议，莫名其妙的！Tech Owner 也是要写代码的，他写的代码行数不比其他任何团队成员少，在此基础之上，这个人还得去帮忙照顾整个项目团队，因为在 Tech Owner 任命后，实际上 PM 已经成为了甩手掌柜，等着交付就行了。

这个就给当 Tech Owner 的这个倒霉催的带来了最大的挑战 —— 时间被挤压。
写代码的时间是固定不变的，比较 fixed，因为其中大家的一项工作就是计算工时，给到排期，算下来 iOS 是 5PDs，Android 是 5PDs，服务端是 8PDs，当这个倒霉催的 Tech Owner 是 iOS 端时，他并不能获得比 Android 更多的时间，你不可能 Android 排 5 天，iOS 因为要当 Tech Owner 排 7 天，也要在 5 天的时间内垒完相同规模，能达成相同功能的代码。

当 Tech Owner 很累，在相同的时间里，又要自己干活，又要监督别人干活，还要哄着别人干活。
根据《极简项目管理》所说，项目是模糊的，不确定性是团队需要去一个一个 nail 的，这个 Owner 角色从处理“自己的不确定性”开始，延伸成为了处理“团队的不确定性”。

大家没法在相同的时间里做好这么多工作。

Tech Owner 的几个难点

小李和小张是客户端的研发同学，比较资深，小王是新来的校招生服务端同学，经验不是很丰富，这次小李被任命为了 Tech Owner 角色。
虽然我们说小李和小张比较资深，不过其实，对于这么庞大的代码架构，他们也是新来的，当一个新的产品功能丢到面前时，小李和小张也得把 codebase 从头看起。

于是小李按部就班的开始做技术方案设计，小李看了 figma 和 PRD 老半天，又和 PM 聊了几轮，吭哧吭哧的写了一个大概，命名为 TRD v1.0，但是其中必然有有很多的天窗，没法定下来，毕竟这块数据交互逻辑服务端还没给到呢。

小王是新来的同学，连内网平台都没用利索，于是设计数据交互的职责自然而然在小李的头上。

更多的，小李还得回答小王无穷无尽的一系列问题，不过这也是作为资深同学应当的，小李急急忙忙加班开始看客户端代码，从一些似有非无的历史字段，从中寻找蛛丝马迹，拼拼凑凑给到了一个带 API 接口设计的 TRD v1.1，Tech Owner 需要做更多的职责，这是应当的，这块工作 +1。

这个做完以后，小李晚上开始定一系列的会议，推进技术评审，埋点评审等等正常节点。

好不容易熬到开发阶段了，小李也总算可以腾出手来写一点代码。
但是，好景不长，过了两天。小王做着做着发现有一块东西整起来很麻烦，由于客户端的历史逻辑，没法保证回调 A 和回调 B 的先后顺序，于是小李又急急忙忙拉了个会，找小王讨论新方案，并且用大段的文字，罗列比较原先的方案和新方案的优劣点，最后还需要小李自己拍板决定，这块工作 +1。

过了两天，又由于服务端某个字段取不到，又围绕另外几个问题，小李组织会议，换了方案。
这样的方案的变动又来了两三次（很正常，比起测试的时候发现，开发的时候发现已经是足够庆幸）。

你会发现，小李在边开发中，还要牵头讨论，组织大大小小十多个会议，每次会议上需要主要发言人，给出议题，围绕讨论，最后拍板决定，把结论归档记录下来。此时，项目的文档也越来越长了。

在开发阶段完成后，总算到联调测试阶段了，小李发现小王的很多数据都没整完，催又催不动，只好先和小王商量用数据 mock 一下，又过了两天，发现小王还是没整完，showcase 赶不上，小李又只能私下去晓之以情动之以理，去找 QA 调整测试和 showcase 时间。

showcase 总算过了，但是小张又和埋点测试的同学吵起来了，小李又急急忙忙来当“和事佬”，小李听了小张的描述，觉得的确是历史逻辑没办法改，又要安抚 DS 同学（这里还不是埋点测试同学），于是花了两个晚上把线上的问题梳理了完，开始拉会阐述双端的不一致，试图 DS 说服这次别改了。

别忘了，小李在做这件事的时候，头上还挂着 10+ BUG 单子。

说了这么多，我觉得 Tech Owner 应该做到什么？

上面说了这么多，说说我个人对 Tech Owner 的看法，主要分两部分：专业度 + 心理。

最基本的是专业度，必须要有硬实力去 hold 一整块代码，可以不拆的太细，也可以不做非常多的实现，但是对于更为宏观的数据是怎么流动的，一定要心理有数。

其次，还是专业度上，是一个高效的人，能够用一些 Soft Skill 做项目管理，了解基本的项目管理工具，项目周期，和项目本身的意义，懂得如何把握项目的节奏。

以及，需要具备的心理特质是：

• 整理整顿，一定不能讨厌整理，一个自己的房间都无法整理好的人，是无法理清项目的；
• 能排版，能断言，80% 的工作是帮团队做决定；
• 心态要平和，心态不能崩，泰山崩而无惧色，打工而已；
• 有一定的沟通技巧和经验；
• 广结善缘。

我能做到以上我描述的所有吗？可能是不能的。
但是，至少，我期望一个优秀的 Owner 能够把握以上几点，而不是名义上的 Owner。