11 | P9提升攻略：怎么成为跨域整合的“业务导演”？

Dec 21, 2020

11 | P9提升攻略：怎么成为跨域整合的“业务导演”？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

11 | P9提升攻略：怎么成为跨域整合的“业务导演”？

2020-12-21 李运华来自北京

《大厂晋升指南》

课程介绍



讲述：安晓辉

时长18:04大小16.50M



你好，我是华仔。
上一讲我跟你提到，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 来管理技术团队？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 15

提建议

10 | P8提升攻略：怎么成为有影响力的“领域专家”？

12 | PPT框架：标准的晋升PPT长什么样子？

 写留言

精选留言(18)

骨汤鸡蛋面
2020-12-22
大佬，当您提到精力分配433或631这种形式时，有没有什么具体的建议呢？我现在是P7，感觉每天的时间都身不由己，只能周末自己学习一些技术，对精力的管控感很弱，这让我一直有点担忧。
作者回复: 1. 非必要参加的会议不参加，check会议纪要和结论 2. 培养人，搭建团队梯队，不要事必躬亲 3. 学会利用碎片时间，这个在学习技巧部分会讲具体如何做 4. 将非核心非重要的事情安排给更合适的人做，做好辅导和关键点检查，允许犯小错误，不要出大问题
30
金鹏
2020-12-21
要看情况而定，在公司中，会看到这种交叉带很正常，有带的好的也有带不好。那怎么来做衡量标准呢？这里我提供一个新的视角，从产品、业务、技术分成三种不同的类型来看，分别是业务型、中间层和底层。业务型关注点是数据指标。如各种app业务，这个技术带产品问题不大，而且有比较大的概率可能会带的更好；中间型关注点是接入指标。如腾讯云、阿里云，这个比较适合运营BD，因为需求从客户而来；底层型关注点是稳定。如Tensorflow、云原生，这种硬核技术，要技术带更适合。
展开
作者回复: 你的分析方法不错，但是结论跟实际不太相符。中间型和底层型基本都是技术大佬带的，因为这些“作品”最后都是技术作品，没有技术支撑只了解业务需求是很难做出好的作品的。业务型，技术P9可以带产品和运营，产品型的P9也可以带技术团队，但一般都会配置一个强的P8，技术决策几乎完全是由技术P8来负责的
19
流浪地球
2020-12-22
如果做到了这个层次，那么技术深度该如何保持呢，深入度该到什么程度呢？是调一个自己熟悉的放心深入下去，还是需要选主流的技术深入？
作者回复: P9不要求技术深度了，或者说P9的技术深度不是你通常理解的技术细节，而是技术本质的理解，能够做出关键决策。就像我在文章中的前端还是native的案例，我并不会写iOS代码，但对于native和前端的优缺点以及业务的发展会有不一样的理解。同样，异地多活也是一样，异地多活的架构设计需要的技术深度是CAP理论的深入理解，而不是某个源码怎么写。
11
Single
2020-12-21
这个深有体会，产品9带技术团队，对技术的判断更多的是关注落地后对业务直接的收益；对技术的沉淀思考的比较少，各种提倡业务sence，都可以转产品了。后来来了技术9，在支撑业务的同时会更多关注技术能力的沉淀，对遇到的技术难点和亮点判断也很准，工作起来才觉得自己像个技术人，差别还是很大。
作者回复: 是的，差别非常大，而且产品的P9带技术团队，需要安排强力的技术P8或者P9支持，而且技术的决策还是这个P8/P9来做的。
8
new life
2021-01-12
闻道有先后，术业有专攻；不论是技术出身、还是运营出身，都应该是在所出身的领域里深耕多年，在这个领域已经做到很优秀的地步，这样才可以转移一部分精力给其他领域，技术出身的专家多关注一下业务，业务出身的多关注下技术，但是根基还是自己的老本行，如果直接换了工作方向，似乎有点本末倒置，非常有挑战
作者回复: 技术出身的可以学会业务，业务出身的学不会技术😂
共 2 条评论
4
江南Ryan
2020-12-21
技术出身的可以管理产品，但是产品运营出身的不建议管理技术团队原因:没有技术基因的P9大佬很难深刻理解技术在业务领域的应用
作者回复: 为啥没有技术基因就难理解技术的应用；但是没有业务基因的技术大佬可以理解业务呢？：）
3
攻城狮
2021-12-01
大佬，我们在选择offer时，选择什么样的业务对自己的成长会更快。我是做后端开发的。
作者回复: 不断增长的业务，不断变化的业务
2
豆浆油条
2022-03-12
感觉是技术的壁垒比较大，所以如果其他出身的大佬来管技术会有点问题，但是如果技术的大佬，补全了管理业务方面的能力，是可以管理其他团队的，这样来看技术出身的p9比其他出身的p9厉害，是不是p9里面技术出身的比例会少一点，也就是技术比其他岗位更难升p0。
作者回复: 不太好说，升P10都很难，无论什么出身
csoulsi
2022-02-12
数据库DBA方面的晋级，我理解的技术深度：是对某一种数据库，技术宽度: 是多种数据库，技术广度：这个怎么定义呢？从职业发展的角度，进阶路线有几个方向？ DBA 学习用环式学习法，怎么整？
作者回复: 技术广度是跨领域的
攻城狮
2021-11-28
大佬，有没有什么方法可以了解学习，一个业务线下面的所有子领域和系统呢。
作者回复: 看后面的“环式学习法”
共 2 条评论
jetris
2021-11-18
赞
作者回复: 多谢：）
Paualf
2021-08-02
我觉得不是很好，技术出身的可能更加关注技术是否能实现，可能并没有跳出去去看业务场景和运营情况，这样的话带产运团队可能会有些不太融洽。同样，产运带技术团队的话过于关注产品和运营，不关注技术提升和积累，也不是很好。感觉还是术业有专攻，彼此合作才能发展的更好
作者回复: 一般来说，技术人员不懂业务或者对业务理解很浅的话，是很难晋升到P9的，所以你不用担心技术人员只懂技术；但是产品和运营人员不可能学会技术的，除非是技术出身转岗过去的。
1
L·
2021-07-26
这节很重要，我现在就在往这个位置努力，但是苦于没有机会，靠时间等又觉得不靠谱，我确实也比较急躁，别说6年，3年都是个问题
作者回复: 坦白的说，我也没有很好的方法告诉你如何加速这个过程，因为很多因素都不是我们自己能够控制的
Hesher
2021-03-24
运营所需要的能力怕是跟技术团队差别较大，而且自成体系。专业的事交给专业的人吧。
Geek_558387
2021-02-10
怎么看感觉都是终极杀器都是运气
作者回复: 运气必不可少但又不那么容易遇到，所以你会有这种感觉
CC
2021-01-27
所有人都认为我能力很强，各总监和cto也这么认为，现在担任前端leader，大前端技术委员会主席。但自己不能喝酒，喝酒过敏，一点都不能喝，晋升p8有问题吗，晋升p9要贴近业务，我们pm总监是很能喝的，这会有影响吗？怎么样才可以弥补不能喝酒的短板。
共 1 条评论
Johar
2020-12-23
老师，我目前所在的公司的一个细分行业，也是从去年年底担任小组长，但是目前负责的事情包括:定制项目方案评估，定制实现，基线产品，现场问题处理，投标技术确认。基本上这几块就把我目前的工作时间占用完了，这种情况下，怎么来打破目前的局面比较好？
作者回复: 不清楚你的小组长范围有多大，如果你是等同于P8级别；你看看P8级别那一讲里面的管理三个技巧；如果是等同P7级别，那可以参考P7里面的管理技巧
周平
2020-12-22
在看到T7的时候，发现要对技术的全领域样样精通，感觉很厉害了。想像不出T8要多牛，现在明白了。 T8要在全领域精通之后，跨领域去整合资源。不必对另外一个领域，也要全领域精通了。但是，由于曾经对一个全领域精通过，所以，能够在跨领域的时候，能够达到一个高度。这样做出来才是精品，是行业第一。而样样都通，样样稀松。这也不能成为，在自己领域还没精通，就去搞跨领域的借口。还是要有一点耐心，把自己领域的东西搞明白。 ---- 我认为产品带不了技术团队。自负的产品会提出一些技术上无法实现的需求，搞的技术团队很尴尬，最好落不了地。听到的更多例子，是高T带团队，负责产研，实现业务闭环的情况。
展开
作者回复: 是的，技术出身的高P对业务的理解也不会差，但业务出身的高P对技术很难有较强的理解力

