17 KiB
你好，我是华仔。
上一讲我跟你提到，P8级别是技术能力的顶峰。而这一讲介绍的P9级别，则可以说是绝大部分人的职业发展巅峰。因为就算你很厉害，如果没有合适的机遇和运气，也很难晋升到P9，至于从P9继续往上晋升就更难了。
P9级别对应的工作年限一般是10年以上。在BAT级别的大厂，P9是管理层级分水岭，从这个级别开始就属于中层管理者了。
很多公司P9的Title仍然带着“技术”或者“工程师”这样的词，比如阿里的P9是“资深技术专家”，腾讯旧职级T4是“专家工程师”。但实际上，对于P9这个级别来说，业务和管理工作已经占据了核心地位，尤其是业务目标管理，比如分析业务情况，讨论业务方向、规划业务突破点或新业务等。
P9的核心能力要求可以用一句话来概括，导演成熟的作品。它的核心职责和电影导演类似，都包括制定目标（要拍一部什么样的电影）、整合资源（投资方、演员、编剧等）、做出决策（钱花在什么地方、找谁来主演等）以及完成作品（拍出最后上映的电影，并且拿到一定的票房，至少要赚钱）。
导演的表演水平可能比不上主演，写作水平可能比不上编剧，更不用说服装、道具、摄影这些专业技能了。但导演一定是跨领域专家，对每个领域都有一定的理解，能够结合自己的作品目标来整合行业资源。
P9也是这样，不一定精通每一个专业领域，但一定是跨领域整合的高手。虽然在某些职级体系中，P9和P8的Title看起来只是半斤和八两的差别（比如P9是“资深技术专家”，P8是“高级技术专家”），但实际上它们的能力要求已经发生了质的变化，就像拍电影的总导演和道具组组长的差别。
总的来说，P9的主要提升目标是跨域整合的业务导演。接下来，我就从技术、业务和管理三个维度一一展开讲解。
技术：跨领域整合能力
首先是技术维度。
我想你心里也许有这样的疑问：如果说P8就已经是技术能力的顶峰了，那么P9及以上级别的技术水平还能提升吗？业界有很多P9/P10的技术专家，比如人工智能专家、算法资深专家，他们不是一直都是在技术领域发展么？
其实如果单论具体的某个领域的技术，P9除了自己原来在P8时深耕的那个领域外，其它领域可能还真不如对应领域的P8那么精通。
你可以这么理解，P9及以上级别在技术维度上的提升，并不是体现在单个领域技术能力本身，而是体现在整合跨领域的技术方案来打造成熟落地的作品上。
案例：面向业务的立体化高可用架构设计
就拿我自己晋升P9时展示的一个作品来说吧。我在2015年左右负责阿里游戏高可用项目，这个项目涵盖客户端（Android）、运维、后端架构重构和异地多活架构设计，整体结构如下：
这个作品有三个特别的亮点：
- 我们将“4个9”这种不直观的高可用指标拆解为“3分钟定位问题、5分钟恢复业务、平均最多2个月发生一次问题”。这是我在讨论的时候提出的一个创意，后来我看到很多公司都在用类似的表述。
- 这个高可用方案是面向业务的立体化方案。通常说到高可用，大家首先想到的就是运维的各种保障，而我当时的核心理念是“高可用的系统是设计出来的，不是靠运维保障出来的”，所以设计了如上图展示的多个方案组合起来的立体化方案。
- 这是整个游戏业务线，甚至是整个UC，第一个真正实现异地多活架构的业务。并且我还提炼出了一套完整的异地多活设计方法论，后来指导了几个其他的业务顺利实现了异地多活。
这3个点的要求是我作为“导演”提出的，但整个“作品”是由多个团队的多个P7/P8协作完成的，客户端、运维和后端都有领域负责人参与。
我基于整体的架构思路给客户端和运维提出具体的要求，由各领域提出可选方案，然后我们一起讨论。能达成共识当然最好，如果达不成共识，那就主要由我来拍板，我自己参与的重点是在架构解耦（2014年的时候我们还没有用微服务的概念，其实就是微服务拆分）和异地多活这部分的设计。
看完了我的晋升案例，相信你已经能够初步体会到，所谓的“整合跨领域的技术打造成熟作品”到底是什么意思了。它的核心要求就是具备一定的技术广度，能够结合作品来整合不同领域的技术，这也是P9阶段提升技术能力的关键。
技术广度：跨领域的技术视野
那么，什么是技术广度呢？我们不妨把它跟技术深度和技术宽度放在一起，对比理解。
比如说你是前端工程师：
- 一开始，你努力钻研React技术直到熟练掌握，这是技术深度的提升；
- 接着，你又全面掌握前端领域的所有技术，包括vue、Js和小程序技术等，这是技术宽度的提升；
- 然后，你开始了解后端和AI等领域，拥有了跨领域整合的能力，这就是技术广度的提升。
P9级别的技术详细要求，我总结在了这张表格里：
既然技术广度在P9阶段这么重要，我们应该怎么提升呢？
首先，你不要陷入到太细的技术细节中，比如某个工具的使用、API如何调用等，因为这样做花费的时间太多，而且对于做关键技术决策并没有什么帮助。相反，你需要从宏观层面熟悉多个领域的技术，包括技术原理、优缺点、适应场景和业界应用等。
环式学习法就是一个利器，它能通过闭环的思维大大提高技术广度的提升效率，我会在学习方法部分详细介绍。
另外一个提升重点就是关注和学习新技术，比如人工智能、区块链和VR/AR等，因为新技术可能会给业务带来新的突破。
但是因为新技术和业务的结合点并不是一目了然的，需要在目标不明确的情况下持续跟进1～2年时间，所以我不建议一开始就大张旗鼓地投入，也不建议直接安排别人去跟进。
最好的办法还是P9自己保持一定的关注度，等到时机成熟，再专门安排手下的P7/P8去深入研究。
业务：从理解规划到亲自导演
在业务维度上，公司也对P9提出了更高的要求。
按照规模和组织形式来区分，P9负责的业务范围一般可以分为三类：
- 独立的一个或者一类产品
比如阿里云上的云数据库Redis版，或者云数据库Redis版 + 云数据库MongoDB版。
- 某个行业中的一个或者一类业务
比如美团App是一个覆盖“本地生活”行业的App，里面会划分外卖、美食、酒店、电影等几十个具体的业务，一般P9会负责其中一个或者一类业务。
- 某个中台的一个或者一类业务域
比如电商中台可以分为支付域、订单域、商品域和用户域等几十个业务域，一般P9会负责其中一个或者一类业务域。
至于P9到底是负责一个还是一类产品、业务、业务域，这跟产品、业务、业务域的复杂度、规模、公司的组织结构以及自己的能力（P9-还是P9+）都有关系。
规划和突破
但是，不管负责哪一种业务范围，对P9级别的考核来说，业务结果所占的比重都大大增加了，甚至已经超过了对技术的要求。
我在第6讲提到过，P9要导演出成熟的业务作品，就像合格的电影导演要拍出7分以上的电影作品。
也就是说，P9需要规划业务目标（可以独立规划，也可以跟其他人一起规划），协调整合资源来落地规划（可能是成立新团队，也可能是成立新项目），并且落地后还要拿到比较好的结果。
通常情况下，P9要能够拿到有突破的业务结果才能得到认可，如果只是将已有的业务数据提升一些是作用不大的，例如我的阿里游戏高可用方案，落地后真正实现了“3分钟发现问题，5分钟恢复业务”的目标，而在做这个方案前，我们的业务曾经1个月出了4次大故障，最长故障时长6小时。
从理解业务规划到做出业务规划并拿到有突破性的结果，这是P9相对P8的核心提升点之一，也是P8晋升P9很难的一个因素。
首先，好的业务机会本身就非常稀缺，毕竟行业的风口并不是经常有的，业务上大的发展和突破也不是年年都有。而如果业务本身没有大的发展或者突破，相关的各种机会就会比较少。例如我前面举例的阿里游戏高可用项目，核心原因是业务发展很快，用户量大增，原有技术架构存在严重缺陷。
我曾经跟朋友说过，如果让我现在以P7的身份加入大厂，我再干6年也不一定还能晋升到P9，因为机会是可遇不可求的。
其次，内部竞争激烈，做业务规划的机会不一定能落到自己头上。
虽然P8+的总体数量不是很多，但因为业务机会更加稀缺，结果还是僧多粥少。可能同一个业务机会抛出来，有好几个P8+都想抓住，但最后只有一个能够得到高层的认可和支持。
当然，P8+自己也可以提一些创新的业务突破方向。但是这些想法能不能得到高层的支持，有很大的不确定性，因为高层会面对各种创新的想法，不可能每个都采纳。
第三，业务能不能实现突破，运气成分很大。
即使你一路过关斩将，得到了高层的认可和授权，开始负责将业务规划落地，但是业务结果怎么样，还是有很大的运气因素。比如你负责的是微信支付的香港本地钱包业务，碰上这两年的政治事件和新冠疫情，业务开展肯定会受到很大的负面影响，更不用谈有什么突破性发展了。
P9级别对业务的详细要求，我总结在了这张表格里：
P9是业务规划和执行的核心人员，需要从战略的高度来思考业务方向。关于业务战略的理论和方法论很多，如果你想快速入门，我建议学习宝洁战略模型。
在P8的提升攻略中，我也提到了可以借助宝洁战略模型来提升自己对业务规划的理解能力。不过到了P9级别，你就不只是用它来理解业务规划了，你还要通过这个模型塑造自己的战略思维，指导自己规划业务方向和目标。
另外，业务战略和行业是强相关的，你必须在行业内经过一定时间的摸爬滚打，才能积累相关经验和理解。所以，不能光靠理论学习来提升业务战略，而要做到知行合一。
当你是P8+的时候，会有很多机会参与业务规划和分析的相关会议和讨论，你可以结合宝洁战略模型，学习P9/P10或等高级别的人在分析和规划业务时的思路和逻辑。
管理：授权但不要放羊
P9级别的管理要求整体来说和P8类似，核心工作也是团队梯度、业务目标和技术演进三大块。
P9级别对管理的详细要求，我总结在了这张表格里：
P9带团队的挑战在于，因为管理范围覆盖的领域比较多，你已经不可能在每一个具体领域都达到精通的水平了。
所以，你在管理P8的时候，需要尽量采用授权式管理。不过一定要注意，不要把授权式管理变成了放羊式管理。
有些P9因为自己曾经不是从某个专业领域升上来的，对这个领域不太熟悉，就干脆把这个领域的事情完全丢给一个P8了事。
但是这可能会导致在做关键的技术决策的时候出现脱节：P9懂业务，但是对某个专业领域不熟悉，而P8虽然在专业领域上很精通，但是对业务的理解一般，无论谁来做决策，都存在很大风险。
案例：小游戏App项目
举个例子吧，我在P9级别负责过一个小游戏的项目，简单来说，就是做一个小游戏的App，用户在里面可以玩各种小游戏。
这个项目App要采用什么技术方案呢？当时我们内部有两种不同的意见：
- Android和iOS团队都建议完全用原生的技术来实现，因为对于大部分玩小游戏的用户来说，手机性能都一般，用原生的技术他们的体验会更好。
- 前端团队建议用App + H5包壳的方式快速上线，因为这是一个快速尝试的创新项目，H5的方式能够让业务快速迭代。
在讨论决策的时候，我的老板们（在业务线上带我的P9和P10）也倾向于用原生的技术方案，因为他们觉得用户体验是小游戏成功的关键。
但是经过分析，我认为App + H5包壳的方式更适合业务，因为小游戏体验的好坏关键在于小游戏本身。App的交互并不复杂，原生技术不会带来体验上的优势；相比之下，用H5实现既能够支撑业务快速迭代，又能够满足用户体验的需求。
最后，我顶着老板们的压力立下了军令状，确定了用App+H5包壳的方式来实现。而后续业务的发展，也印证了这个技术方案的先见之明。
一方面，我们内部测试的时候发现，小游戏本身的设计是用户体验的关键。很多游戏在上线之后都要经过不断调优才能够达到用户体验的要求，而小游戏App本身没有成为体验的瓶颈。
另一方面，小游戏App上线之后，推广很困难，让用户独立下载一个小游戏App的成本很高。于是我们很快就在业务方向上进行调整，从独立的App改为嵌入到集团内成熟的App。因为采用的是H5包壳的技术方案，所以迁移的成本比较小。
这个故事说明什么呢？虽然P9下面会有几个不同领域的P8专家支撑，但是这并不意味着你可以直接把技术工作全都交给他们。比方说小游戏App的技术方案，你不能甩给Android、iOS和H5三个领域的P8来进行辩论和PK，谁赢了就听谁的。
在做业务相关的关键技术决策时，P9必须根据对业务和技术的理解，自己拿主意。因为只有到了P9级别的人，才拥有跨领域的技术理解，并且能够结合业务的发展来做出判断。
跟P8相比，P9因为要负责业务目标的制定和实现，所以需要在业务和管理投入更多的精力，而技术上投入的精力则稍微少一点。
总的来说，P9在技术、管理和业务上的精力分配没有固定的标准。
如果业务稳步发展，你可以参考433的标准，也就是40%业务、30%管理、30%技术；而如果你作为空降的P9接手了一个原来表现不太好的团队，就得在业务和管理上面投入更多，按照40%业务、40%管理、20%技术来分配；而如果你负责的业务面临发展的天花板，那么按照631的比例也是可以的，也就是业务60%、管理30%、技术10%。
小结
这一讲我基于COMD能力模型，给你详细解读了P9级别的具体要求以及对应的提升技巧。现在，我们回顾一下这一讲的重点：
- P9的核心能力要求是导演成熟作品，主要提升目标是成为跨领域整合的业务导演。
- 技术维度上，P9需要具备跨领域整合的能力，重点提升领域技术广度，可以通过环式学习法来提升自己的技术广度，通过关注和跟进新技术来提升自己的创新能力。
- 业务维度上，P9需要规划业务目标，并且需要掌握战略规划相关的技能，指导自己做出好的业务规划，可以采取“宝洁战略模型”的方法快速提升自己的业务规划能力。
- 管理维度上，P9需要负责指挥多个不同领域的团队，除了抓住三个管理重点（搭建团队梯队、参与目标制定、关注技术演进）外，还可以采用授权的方式管理团队，但必须注意，不要把授权变成放羊。
思考题
这就是今天的全部内容，留一道课后思考题给你吧。既然P9级别管理和业务的能力比重大大上升，是否可以由技术出身的P9来管理产品运营团队，或者由产品运营出身的P9来管理技术团队？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
