你好，我是华仔。
在第6讲中我曾经介绍过，P7/P8是同一档次的职级，核心能力都是指挥团队，区别只在于团队数量是一个还是多个（一般是2～5个）。
但是在真实的职场环境中，P7级别就像“永恒钻石”段位，大部分人升到P7就很难再往上晋升了。为什么P7和P8的核心能力一样都是指挥团队，而P7升P8却这么难呢？指挥一个团队和指挥多个团队的区别到底体现在哪？
我们还是先剖析一下P8的要求。P8对应的工作年限一般是8年以上，核心能力要求可以用一句话来概括，指挥多个团队达成目标。
这些团队的构成不是随机的，而是跟业务发展阶段和团队规模大小有关，通常有两种构成模式。
第一种是横向模式，指的是P8带领的团队的专业领域相同，横向支撑多个业务。
这种模式常见于业务成熟期或者规模比较大的团队。比如某业务线所有Android开发人员都由1个P8带领，然后拆分为3个Android小组，每个小组支撑不同业务的App开发。团队结构示意图如下：
第二种是纵向模式，指的是P8带领的团队的专业领域不同，端到端地纵向负责同一业务。
这种模式常见于新业务初期或者规模不大的团队，很多BAT出身的P8到创业公司担任CTO或者技术总监时，就会采用这种模式带团队。比如1个P8负责带某业务的所有技术团队，包括客户端（含Android和iOS）、前端、后端、运维和测试等。团队结构示意图如下：
现在，我们再对比一下P7和P8的核心能力要求就会发现，虽然看上去只是从“单个团队”到“多个团队”的一字之差，但是在影响力上却发生了本质的改变，主要体现为两点。
第一，专业影响力范围从团队内提升到领域内。
P7带单个团队，而P8是带单个领域的多个团队。如果P8带的是横向模式的团队，那么负责的就是单个专业领域；如果带的是纵向模式的团队，那么负责的就是单个业务领域。
这就对P8的技术水平和业务理解提出了更高层次的要求。
第二，组织影响力范围从单个团队提升到跨团队。
P7只需要指挥自己团队内部的人就行了。但P8不同，虽然已经带了2～5个10人以内规模的团队，但是要想实现目标，光靠他们有时还不够，P8还需要指挥这些团队以外的人。比如有的项目涉及产品和运营配合，有的需要客户端、后台、运维一起协作。
这在一方面对P8的管理手段提出了更高层次的要求，另一方面也把晋升跟业务目标绑定起来，增加了很多不确定和不可控的因素。
总的来说，P8的主要提升目标是成为有影响力的领域专家。接下来，我就从技术、业务和管理三个维度一一展开讲解。
我们先看技术维度。
P8级别是技术能力的顶峰。在P5～P8的晋升过程中，考察核心都是技术能力。业务能力和管理能力只是加分项，只要技术不行，业务能力和管理能力再好都很难晋升。（相比之下，从P9开始，对业务能力、管理能力和业界影响力等维度的考核比重会大大上升。就算你技术很厉害，只要业务能力和管理能力不行，同样很难晋升。）
P8级别的技术详细要求，我总结在了这张表格里：
那么P8提升技术能力的关键是什么呢？答案是技术深度和技术宽度齐头并进。
如果只有技术宽度，可能给人一种比较飘的感觉，成为“什么都知道，什么都不懂”的PPT技术专家；如果只有技术深度，技术视野太窄，就难以跟上业界技术的发展步伐，无法做出合理的技术判断、选择和规划。
P7虽然也在技术深度的基础上增加了技术宽度的要求，但技术宽度的范围是和团队相关的，而P8的技术宽度范围是领域相关的，范围要大得多，你要学习和提升的东西也多得多。这是P7很难晋升P8的第一个原因。
既然我们说P8是“领域专家”，那么这里的“领域”是怎么划分的呢？业界一般有两种方法：
一是按照技术领域划分，比如Android开发、Java业务开发和大数据等。
二是按照业务领域划分，比如推荐业务、广告系统和支付业务等。
通俗地说，“领域专家”就是在自己负责的领域“什么都懂”。不过问题又来了，“领域”的边界要怎么定义呢？
很多人把领域理解成“整个专业领域”，以为懂得越多越好。所以有的Android开发人员会去学习MySQL或者Redis，这样的做法在P8级别是不合适的，往往投入很大而收益却很少（P9反而要这样做，因为要拓展技术广度）。
其实，要界定领域的边界，有一个很简单的方法，那就是画技能图谱。只要画出完整的技能图谱，领域的范围也就基本界定了。
我在下面放了一张前端领域的技能图谱，供你参考。
我们可以看到，领域的范围确实很大。想成为领域专家，需要提升的东西可不少。
很多人在晋升P8的时候都遇到这样一个场景：某位评委问了你专业领域里的一项技术，你又刚好不太熟，没有回答好，结果评委团就因此认定你在技术维度上表现得不够好，最终没有让你通过晋升。
也许你觉得很委屈或者运气不好，但是从P8的要求来看，这种考核标准其实是有一定道理的。
可是问题在于，很多尝试晋升P8的技术人员，已经承担了比较重的任务，没有那么多的时间来提升技术。
那么，怎么才能高效地提升自己的技术深度和技术宽度呢？除了前两讲提到过的链式学习法和比较学习法之外，我再介绍两种很管用的方法。
第一种方法是研究业界的开源项目。
你可以通过学习和研究开源项目的原理和设计来提升技术宽度，通过研究开源项目的源码来提升技术深度。具体的学习方法，你可以参考《如何高效地学习开源项目》这篇文章。
当然，开源项目的数量非常多，每个都深入研究的话时间和精力不允许，可以优先关注本领域成熟的、流行的开源项目。比如Java后端开发领域的MySQL、Redis、Nginx和Netty等，前端开发领域的Vue、React和Node等，Android开发领域的OkHttp、Picasso和EventBus等。
第二种方法是参加业界的技术大会，比如QCon技术大会、架构师峰会、GMTC（全球大前端技术大会）、GOPS（全球运维大会）和人工智能峰会等。
你可以通过参加技术大会，快速地掌握本领域相关技术在业界的应用情况。尤其是领头羊企业（BAT和TMD等）的技术积累和经验，具有很好的借鉴意义。同时，你只要关注一下大会上讲得最多的技术是哪些，就能够识别出业界整体的技术发展趋势。
当然，如果你能直接在技术大会上做主题演讲，把自己在技术上的经验整理成优质的内容输出给业界，那就更有利于晋升了。因为这会大大提升你的影响力，而P7升P8的时候，在公司和业界的技术影响力恰恰是评委考察的一个重要方面。
接着，我们来看业务维度。P8级别对业务的要求和团队构成模式有关。
如果是横向模式，P8需要熟悉团队涉及的每一个业务。而且因为这些业务本质上属于某个大的行业，为了能够更好地理解业务，P8还需要对行业有一定理解。
如果是纵向模式，P8只负责1个业务。跟横向模式相比，虽然需要熟悉的业务数量更少，但是对于理解深度的要求要高得多，除了要熟悉自己负责的业务之外，还要深入理解公司内或者行业内类似的业务。
P8级别对业务的详细要求，我总结在了这张表格里：
P5/P6核心能力的关键词是完成“任务”，而P7/P8核心能力的核心是指挥团队达成“目标”。它们的差别在于：任务是从过程的角度来衡量的，而目标是从结果的角度来衡量的。
以最简单的需求开发为例，P5/P6只需要按照项目计划完成各项任务就行了，而P7/P8要对业务最后的结果负责。
P7虽然也要为业务结果负责，但在晋升考核的时候，技术能力还是核心考察项，业务结果是加分项；而对P8来说，能不能拿到好的业务结果，这一点在考核中所占的比重要大得多，基本上和技术能力是平起平坐的地位。这就是P7很难晋升P8的第二个原因。
可能很多人会认为这么做不公平，因为业务结果很多时候并不是由技术人员决定的，比如新冠疫情导致旅游、航空的业务量大幅下降，某些地方的政治局势不稳定导致线下消费用户量大幅减少。
虽然这些情况是客观存在的，但是这并不意味着技术人员对业务结果就完全不可控了。其实，我们可以在很多方面对业务结果做出直接贡献。
以互联网2C业务为例，常见的技术手段包括通过降低App包大小提升下载成功率、优化某些功能让用户体验更好、提出更合理的方案来满足用户需求以及设计良好的架构来应对秒杀抢购等特殊场景等。
采取合适手段的前提是，我们对业务足够了解。那么，P8阶段要怎么提升对业务的认知呢？
针对单个业务，P8和P7提升的方式差不多，你可以回顾上一讲的内容；针对行业的业务战略，你可以借助宝洁战略模型，从愿景、使命、定位、策略、能力和组织等方面来理解。关于宝洁战略模型，我会在专项提升部分详细介绍。
站在公司的角度看，引导员工拿到更好的业务结果是理所当然的，这也在侧面体现了第3讲提到的价值原则。
不过，过于重视业务结果的做法，确实会增加运气因素对晋升的影响，导致结果有时候看起来不那么公平。
比如A和B两个人都是P7，其中A的能力比较强，但是运气不好，所在的业务没有发展，甚至还出现了倒退；而B正好在一个业务快速发展的团队中，拿到了更多的漂亮的结果。如果他们俩同时申请晋升，B通过的可能性反而更大。
这种现象是不可避免的，尤其是到了P8之后，运气很多时候就是晋升的关键，有机会展现能力并且拿到结果的人可以晋升，有能力但是没法通过结果展现出来的人就不能晋升。
如果个人遇到这种情况，认为自己有能力但是没机会展现的话，换个岗位甚至公司可能是更好的选择，找到适合自己发展的岗位比找一个名气很大的团队更重要。
所以说，晋升当然要靠自我奋斗，但也要考虑历史的进程。
最后的管理维度。P8需要指挥一个领域的多个团队。
P8级别对管理的详细要求，我总结在了这张表格里：
跟P7相比，P8的管理范围更大，可能存在以下困难：
所以，我们不能简单地使用和P7一样的管理方法，而是需要对管理技能进行升级。那么，怎么提升自己的管理能力呢？
核心思路就是要学会抓重点。我们必须认识到，P8的管理方式不能再像P7那样偏重细节和执行方面的管理（否则时间和精力根本不够用），而是应该关注重点事项的管理。
我根据自己的实践经验，总结了P8阶段管理的三大重点：
因为P8无法关注团队的每一个人，很多事情的传达和具体执行效果是靠P7/P6级别的人来把控的，所以P8需要重点关注搭建合理的团队梯度，包括核心的TL/P7/P6有哪些，核心人员的状态，核心人员的晋升规划等，都是需要重点考虑的。
什么样的团队梯度就算合理呢？一个简单的判断原则是，每个核心人员都至少有一个备份人员。比如P8自己要有1个以上的P8/P7+能够做自己的备份人员，每个TL要有1个潜在的TL备份人员，每个核心业务都至少有2个P7能够支撑，依此类推。
P8需要指挥多个团队达成业务目标，所以对于业务目标的制定和理解是很关键的。P8级别已经有机会参与业务目标的讨论和制定，不能只是带着耳朵去听一下，而要真正地参与进去。
对于最终确定的业务目标，P8级别的人必须是充分理解和赞同的，因为之后P8还需要向团队（包括自己直接指挥的团队和相关协作团队）解读业务目标。如果不理解或者不赞同，在目标讨论过程中就应该提出来，经过讨论或者PK最终达成共识，这样才能为团队拿到更合理的业务目标。
千万不能在讨论业务目标的时候不认同或者不理解但是却不说，然后跟下面团队沟通的时候来一句“其实我也不怎么认同这个目标”，这样做会大大伤害团队的积极性和稳定性。
P8级别负责的是整个领域的技术，需要重点关注领域技术的演进。也只有P8来做这个事情是最合适的，相比P7来说，P8有几个优势：一是技术视野，P8关注的是整个领域的技术，技术宽度比P7更强；二是团队资源，领域技术的演进投入可能会比较大，P8能够协调多个团队共同来完成；三是业务理解能力，P8的业务理解能力更好，而且能够掌握更多的业务信息，所以更容易结合业务来考虑技术演进。
最后，我再分享一下P8级别精力分配的经验。如果带横向模式的团队，可以参考532标准，也就是技术50%、管理30%、业务20%；如果带纵向模式的团队，可以参考433标准。
实际比例可以视情况灵活调整。总的原则是，既不要丢掉技术，也要重视业务，技术比例不要低于30%，业务比例不要低于20%。
这一讲我基于COMD能力模型，给你详细解读了P8级别的具体要求以及对应的提升技巧。现在，我们回顾一下这一讲的重点：
这就是今天的全部内容，留一道课后思考题给你吧。
对于你现在负责的业务和指挥的团队来说，晋升P8的机会可能在哪里？如果要把握这样的机会，你会怎么规划接下来的行动？（就算你目前不是处在P7晋升P8的阶段，也不妨假设自己是团队里的P7，来分析一下这个问题。）
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
评论