极客时间已完结课程限时免费阅读

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

10 | P8提升攻略:怎么成为有影响力的“领域专家”?-极客时间

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

讲述:安晓辉

时长17:33大小16.04M

你好,我是华仔。
第 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 的核心能力要求是指挥多个团队达成目标,主要提升目标是成为有影响力的领域专家。
技术维度上,P8 需要精通领域相关的技术,重点提升领域技术宽度,可以通过研究开源项目和参加技术大会来拓宽自己的技术宽度,也可以在技术大会上做主题演讲来提升自己的影响力。
业务维度上,P8 需要熟悉多个业务,并且开始需要掌握战略规划相关的技能,以帮助自己理解业务整体规划,可以采取“宝洁战略模型”的方法快速提升自己的业务理解力。
管理维度上,P8 需要负责指挥多个团队,提升自己管理技能的核心是学会抓住三个管理重点:搭建团队梯队,参与目标制定,关注技术演进。

思考题

这就是今天的全部内容,留一道课后思考题给你吧。
对于你现在负责的业务和指挥的团队来说,晋升 P8 的机会可能在哪里?如果要把握这样的机会,你会怎么规划接下来的行动?(就算你目前不是处在 P7 晋升 P8 的阶段,也不妨假设自己是团队里的 P7,来分析一下这个问题。)
欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。
分享给需要的人,Ta购买本课程,你将得20
生成海报并分享

赞 21

提建议

上一篇
09 | P7提升攻略:怎么成为让人信服的“团队专家”?
下一篇
11 | P9提升攻略:怎么成为跨域整合的“业务导演”?
unpreview
 写留言

精选留言(21)

  • sugar
    置顶
    2020-12-29
    华仔,我想问 作为一些比较基础型 infra团队,做的东西很底层 确实有技术难度有挑战性,但是实际触达业务的点相对会少很多,在这种类型的团队呢,从7升8的角度上来说,感觉除了技术能力之外,业务和管理方面很难积累足够的晋升材料(相比一线的一些业务部门),特别是组内如果停在7这一级的同学较多的话,晋升8感觉竞争会非常激烈。您觉得这种情况下,不打算换部门的前提下 都有哪些破局思路呢? 一门心思钻技术深度 憋大招出来? 还是说多发些提升自己影响力的文章 演讲之类的?
    展开

    作者回复: 我在07那讲讲P5的时候对业务有详细的说明,专栏的业务定义是广义上的业务,即:“你负责的系统或产品为目标对象提供的功能和服务”。 因此,你做基础系统或者框架,你如果要晋升8的话,“业务”范围就是你的这个基础系统所在领域,例如你做存储系统的话,那么MySQL、Redis、Hadoop都是“存储领域”相关的业务,你做的就是“存储产品”,只是这个存储产品只给内部用,没有像阿里云对外出售而已。 这类岗位晋升8有两种方式:一种是复杂的单一产品,例如类似Innodb这种存储引擎的产品;一种是横向多产品,例如你做了3个存储系统,虽然单个复杂度不一定高,但是横向需要技术宽度和多种技术。 事实上大部分人走的是第二种方式,毕竟第一种方式机会太难得,而且对个人技术深度能力要求很高。 7升8在哪里都比较激烈,核心是要有机会,在机会来临之前可以通过写文章做演讲来提升自己的影响力,让自己有更大可能得到机会;但如果没有机会,只提升自己的影响力是晋升不了8的。这就是这一讲里面重点讲的“运气”的部分。

    共 5 条评论
    29
  • 周平
    2020-12-19
    这样来说,P8有两种模式(技术中心 和 业务闭环) 技术中心: 如 基础技术部,大测试部(公司级别测试部,非事业部自己内部的测试组,负责公司各种产品的测试),大数据组(非事业部内部的数据组),大运维(支撑整个公司的运维),大DBA(支撑整个公司的) 小一点的不到技术中心级别的组,也可能有P8参与其中,如架构组(虚拟团队,技术高工组成,解决疑难杂症,产出事业部内部的技术杂志等等,内部高工培训等等) 业务闭环: 业务闭环的基础技术依赖技术中心,业务闭环中的技术是主要还是搭逻辑,CURD,支撑业务发展和变化,这是App主业务。 还有专门的业务领域:推荐业务,广告系统,支付业务,用户/账号体系,黄反风控部门。 感觉,上面这些都是事情,要做的事儿。做大了就会级别升上去了。事情小的时候,就是刚起步, 复杂度还没有那么高,级别低的也能hold住。 随着时间推演,历史进程。坚持做一个领域,做大了,就起来了。在这个领域变大的过程中,自己跟着成长。 我觉得业务领域,技术领域 并不关键。关键的是大,是复杂。
    展开

    作者回复: 是的,最后这句话是关键,COMD的核心思想就是复杂度,通过你做的事情的复杂度来判断能力高低

    共 2 条评论
    13
  • Leo
    2021-04-05
    大头兵怎么升到8?感觉自己演讲和写ppt能力不行,又很少有机会写ppt和做规划,很难将文字抽象文ppt

    作者回复: 多写,多看别人怎么写,例如技术大会上的PPT

    8
  • 剑八
    2020-12-18
    P8要求: 1.管理 多个团队 2. 技术 领域级别影响力 通过技能图谱,多参加类似QCON大会 3.业务 参与业务目标制定,讨论 制定战略规划 精力上: 技术50,业务20,管理30
    展开
    8
  • Hesher
    2021-03-24
    目前所在团队是横向模式,坑位较满,突破8的机会可能在于团队规模扩张,承担更多业务,然后拆分团队。对个人来说,技术深度和宽度都要继续挖掘和拓展,增加积累,同时提升架构能力。

    作者回复: 横向模式还有一种突破方式就是拉出去做创新业务,不过这个是风险和收益都有很大不确定性的选择,看个人运气。

    7
  • Jason
    2020-12-24
    华哥,我是银行it岗,工作已经2年了。业余时间学会了看公司财报,怎么利用这个技能帮助更快晋升?

    作者回复: 在银行除了学会看财报外,学会账务相关的清算、核算,这样可以去做支付,目前这方面的人才很缺

    5
  • Gོodfrey
    2021-02-23
    老师职能类的领域技能图谱怎么画?对应不来

    作者回复: 职能类的更好画,而且基本上领域变化不大,你可以对照一本教材或者经典书籍来画,书的一二级目录就是领域分类,再细的目录以及里面的内容就是技巧。

    共 2 条评论
    4
  • CC
    2021-01-27
    所有人都认为我能力很强,各总监和cto也这么认为,但自己不能喝酒,比较困惑。现在担任前端leader,大前端技术委员会主席。但喝酒过敏,一点都不能喝,晋升p8有问题吗,晋升p9要贴近业务,我们pm总监是很能喝的,一起团建是有点尴尬,这会有影响吗? 怎么样才能弥补不能喝酒的短板。

    作者回复: 不用担心,我也不喝酒的,晋升的时候也不会考察是否会喝酒,平时聚餐的时候说明自己喝酒过敏就可以了。 再说了,晋升时的评委你大概率是不认识的,不是你的直接上级和合作的人来做你的评委的。

    共 4 条评论
    4
  • Geek_cb70ee
    2021-11-25
    请教大佬2个问题: 一、P7,P8,P9的技术复杂度和业务复杂度的大概标准怎么判断,是用并发量去衡量么。 管理这块看你提到了P8一般是2~5个团队,那么一般也就是20~50人之间了;不知道这么理解对不。 二,如果是纵向模式的P8,但他只是IOS这个领域的专家,如何管理前后端,测试等相关的团队。
    展开

    作者回复: 1. 复杂度统一都是按照COMD模型来判断,更多的是比较两件事的复杂度,而不是有一个客观的标准来量化。评委判断你做的事情的复杂度的时候,也是将你做的事情和他或者他团队做过的事情对比的; 2. 拓宽自己技术广度,培养各个领域专项的P7专家

    共 4 条评论
    3
  • 天猪
    2020-12-18
    来了来了,终于等到这篇了

    作者回复: 你要看下一篇 :)

    共 3 条评论
    3
  • 盲夜
    2021-02-20
    如何提升对业务领域的理解,需要从哪些方面可以下功夫? 我可以想到的方面如下: 1、针对公司内负责的业务,要充分理解产品的业务规划 2、参考竞品的业务发展,去理解,并找到可以帮助公司业务发展的点 针对第二点,感觉不太好做到,有什么建议吗?
    展开

    作者回复: 看33和34两讲,专门讲业务和战略的

    2
  • 青见
    2021-01-18
    一下子感觉自己 茅塞顿开了

    作者回复: 可以详细聊聊具体是哪些地方让你茅塞顿开了,你以前的理解是什么,为什么自己觉得没想通……等等

    2
  • 2021-01-17
    业务复杂度上去了,但晋升时评委很多都是对这块业务不太了解,很难在30分钟左右的时间把复杂的东西给讲清楚,想讲清楚至少得1小时,怎么精简,既能突出复杂度,又能把事讲清楚?

    作者回复: 讲业务核心流程,以及如何赚钱这两点,后面在讲如何写PPT和讲PPT的时候给了案例。

    2
  • 学要有所用
    2020-12-20
    看来充分吸收本专栏,进阶高阶打工仔,问题不大😝

    作者回复: P8也需要一定的运气,但是相对P9来说还是更有机会 :)

    2
  • Geek_ljt
    2022-03-10
    华仔,你好,请教下大头兵没有机会管理实线团队,是不是没有机会升P8? 管理多个实线团队是P8的必要条件吗?

    作者回复: 除非你在某个领域的深度已经能够做到公司级别,否则真的非常难有机会

    1
  • Sam.张朝
    2022-02-26
    P7 还没达到,算是中级,感觉还比较遥远,争取35岁时候,达到P8

    作者回复: 加油 :)

    1
  • 2021-07-23
    建设团队梯队的时候,一般会考虑人力成本,有的时候,产品设计是一个大的板块一个人负责
  • 2021-07-23
    请问下,B端产品经理的技能图谱怎么画

    作者回复: 自己尝试去画,然后找你的leader或者其他高级别的人帮你完善

    1
  • 罗小喇叭
    2021-07-20
    您好,你说的通过降低 App 包大小提升下载成功率这个技术问题是我目前遇到的,能介绍相关的课程或者方向具体说一下嘛?盼回复

    作者回复: 看看专栏《android开发高手课》,或者直接上网搜“app包大小优化”

    1
  • Geek_5788be
    2021-01-12
    大佬 有个疑问 望指教 文章中说“很多人把领域理解成“整个专业领域”,以为懂得越多越好。所以有的 Android 开发人员会去学习 MySQL 或者 Redis,这样的做法在 P8 级别是不合适的。” 但是后面又说 “学习的方式之一 就是看主流框架,比如后端的MySql和Redis ” 请问如何理解?
    展开

    作者回复: 这两个不冲突,P8以下的Android学Mysql和redis 作用不大,但是后端业务开发从P5就要学习mysql和redis了

    共 2 条评论
    1