跳转至

09 P7提升攻略:怎么成为让人信服的“团队专家”?

你好,我是华仔。

上一讲我们学到了,P6的核心能力要求是独立负责端到端的任务。晋升到P7,就说明你在技术上已经小有所成。

但是P7是一个比较尴尬的级别,业界流传一种说法,P7相当于王者荣耀的“永恒钻石”段位。也就是说,P7是很多人职业发展的天花板,这个级别很难再往上晋升。

那么,P7的能力要求是什么,如果还想继续晋升,应该怎么提升自己呢?这一讲我们就来了解一下。

P7是一线团队的核心,对应的工作年限是4~8年,核心能力要求用一句话概括就是,指挥单个团队达成目标。这句话有两个关键词:

1. 团队

P7和P6一样都是业界核心劳动力,人数众多。但管理岗位是有限的,结果自然“僧多粥少”。

所以P7可以分为两种。一种是担任Team Leader的P7,一般带3~10人的专业团队,也就是组织结构概念上的团队,核心职责是团队管理。

另一种是作为团队骨干的P7,他们虽然不是Team Leader,但是一般也会负责某个项目或者专项小组(比如Android性能优化小组和前端效能提升小组),带3~5人的虚拟团队。他们不承担团队管理职责,只关注小组目标的实现。

2. 目标

担任Team Leader的P7主要是带领团队实现业务目标,担任虚拟团队负责人的P7主要是实现小组的专项目标

总的来说,P7的主要提升目标是成为让人信服的团队专家。接下来,我就从技术、业务和管理三个维度一一展开讲解。

技术:精通团队相关技术

P7在技术维度上的核心要求是精通团队相关技术

怎么理解呢?一方面,P7要指导团队内的P5和P6,甚至还有其他P7,所以首先自己要精通团队已经用到的技术;另一方面,P7已经开始负责团队的技术规划,需要在合适的时机引入新的技术,所以也要熟悉团队可能用到的技术。这就是我把P7称为“团队专家”的原因。

P7级别的技术详细要求,我总结在了这张表格里:

需要注意的是,P7虽然是“团队专家”,但并不意味着必须是团队里的技术Top 1。一般来说,如果团队人数在5人以内,P7的确基本上都是Top 1。但如果团队人数是5~10人,那么担任 Team Leader的 P7 只要在Top 3以内就行了。

怎么要求好像变低了?这是因为Team Leader不只看技术,更要考虑综合能力。

不要因为管理而丢掉技术

当然,你的技术也不能太弱,否则不但带团队会吃力,晋升也会受到影响。

在P7阶段有一个很容易踩的坑,那就是当上了Team Leader之后,就把工作重心全部放在管理上

表面上看起来,你为公司做了很多事情,拿到了很多结果。但其实核心工作都是由团队里其他的P7甚至是P6来完成的,你自己的专业技能反而荒废了。这样做的后果是,你面临晋升考核的时候,很容易被评委发现专业技能上的不足,最终晋升失败。

我就曾经遇到过这样的事。一个团队的Team Leader和组员同时参加晋升,他们都是P7,结果Team Leader没有通过,组员却通过了。

为什么呢?因为这两个人讲的项目是一样的,但Team Leader的作用只是规划和讨论,反倒是组员承担了核心的分析、设计和实现工作,他在技术上的表现明显要强于Team Leader。

通常情况下,担任Team Leader的P7本来是比其他P7更容易晋升的,因为他们能够自主规划工作,更容易做出结果。现在如果因为没有平衡好技术和管理的关系,反而错失晋升机会,可就太憋屈了。

那么,我们该怎么做好技术工作和管理工作的平衡呢?别着急,我等会儿讲管理的时候会介绍具体的方法。总之你先记住一点,不要因为管理而丢掉技术

提升技术宽度

如果说P6要重点提升技术深度(不但知道what,还知道why),那么P7还要重点提升技术宽度(不但知道why,还知道which)。

也就是说,P6只要深入理解技术原理和技术细节就行了,而P7还要知道怎么根据业务和团队的情况来选择合适的技术,哪怕现在暂时还用不到。

比如你是Java后端开发,在做缓存选型的时候,你要知道Redis和Memcache怎么选;而如果你是做前端的,那么你就要知道React和vue框架怎么选。

提升技术深度适合用链式学习法,纵向贯穿,自顶向下,挖深挖透;提升技术宽度适合用比较学习法,横向拉通,比较差异,分析优劣。这两种方法,我会在学习方法部分为你详细介绍。

大公司的业务已经具备了一定的规模,团队也有足够的人力,为了保持高速增长,往往乐于尝试新技术。

所以如果你身处大公司,在提升了技术宽度之后,就有机会使用一条晋升秘诀(或者说潜规则),那就是多考虑引入新技术。一方面,新技术在一般情况下确实能够给业务带来更好的结果;另一方面,懂新技术的人不多,早入坑就有先发优势,很容易被认为是专家。

拒绝生搬硬套

但是这个秘诀不能乱用。虽然引入新技术能帮助你更快地晋升(尤其是在大厂),但是“多”不等于“盲目”,如果生搬硬套,会带来很大的风险。

表面上看起来,你做了很多技术创新。但如果没有认真分析业务和团队当前的需要,没有因地制宜地调整适配,套用过来的技术就发挥不出预期的效果。

具体来说,有两种十分常见的错误做法。第一种是直接拷贝大厂的技术

这种做法在中小公司比较常见。很多人想当然地认为,大厂选择的技术就是好技术,毕竟连月活几亿的业务都在用,解决自己的业务问题还不是绰绰有余。而且因为有大厂背书,在说服上级的时候也比较容易。

可是等到真正落地的时候,你可能就傻眼了,怎么橘生淮南则为橘,生于淮北则为枳呢?

道理很简单,牛刀虽好,杀鸡却不方便。比较典型的就是近两年流行的“中台”这个概念,很多公司对中台背后复杂的驱动因素和依赖条件都没搞清楚,就照猫画虎地要上中台,要把技术架构“中台化”。

结果怎么样呢?不但没能一口吃成胖子,反而消化不良了。你可以读一读《中台,我信了你的邪》等文章,看看业内人士是怎么吐槽的。

第二种常见错误是盲目追求新技术

这种做法在大厂比较常见。很多人对新技术有一种偏爱,认为新的就是好的。但其实任何技术都遵循“没有银弹”的理念,没有一劳永逸又包治百病的神药。新技术也会带来新的复杂度,也会有自己的场景限制,也需要考虑成本问题。

比较典型的就是Docker容器化技术,它的核心目的是降低部署成本和提高资源利用率,业务规模越大,效果越明显。但是引入Docker的成本可不小,因为涉及开发、测试和运维等全流程的基础技术迁移,所以在业务没有达到一定规模的时候,很可能得不偿失。

另外,新技术刚出来的时候其实是不成熟的,后续的变化可能很大。如果用得太早,团队就要一直投入大量的人力来跟进技术的发展。

同样以Docker为例,容器化技术在经历了Swarm、Mesos和Kubernetes三国争霸之后,才逐渐走向Kubernetes一统天下的局面。如果你在三国争霸的时候就做了容器化,又恰好没有选Kubernetes,那么之后再换成Kubernetes,需要投入的成本可不小。

所以,无论是在大厂还是中小公司,引入新技术的时候都要求能够想清楚对业务和团队带来的价值,而不是仅仅因为“新”就引入,评委在考察的时候,会特别关注引入新技术背后的逻辑是否合理。

业务:关注业务整体

在业务维度,P6更关注业务细节,而P7更关注业务整体。这里的业务范围是自己团队负责的业务。

在下面这张示意图中,我对B2C电商领域的业务做了一个简单的总结。可以看到,P7的业务范围是“收藏子系统”“用户子系统”和“活动子系统”这个级别的。

P7级别对业务的详细要求,我总结在了这张表格里:

从4个方面提升业务理解力

从表格中可以看出,跟P6比起来,P7对业务理解的要求又上升了一个档次。很多人问过我一个问题:“怎么提升业务理解能力?”我在这里跟你分享一个适合在P7阶段使用的基础方法论。

想要理解业务,你可以从4个方面出发,分别是用户特征、用户价值、获客方式和获利方式。

用户特征回答的问题是,我们的用户是谁,换句话说,我们的用户属于哪一类人群。要怎么分类呢?常见的方法有两种,第一种是按照属性来划分,比如学历、收入、年龄和地域等;第二种是按照场景来划分,比如网购、K歌、旅游、外卖和游戏等。

用户价值回答的问题是,用户为什么要用我们的产品,换句话说,我们产品的好处体现在哪里。它可以体现在能满足用户的某些需求,也体现在跟其他产品比起来有竞争优势。比如电商三巨头淘宝、京东和拼多多,淘宝大而全,京东物流快,拼多多价格便宜。

获客方式回答的问题是,怎么让用户来用我们的产品。用户并不会无缘无故就自动找上门来,我们必须通过宣传把他们给招揽过来。以2C业务为例,常见的获客方式有品牌广告、社交推荐、事件营销、SEO、线下地推和红包返利等。

获利方式回答的问题是,我们怎么赚钱。毕竟公司是以赚钱为第一要务的,就算现在不赚钱,也是为了将来能赚更多的钱。常见的获利方式有广告费、会员会费、增值服务、服务费和销售产品等。

从这4个方面进行拆解,P7级别对业务的理解至少要达到以下4点要求,并且要能够量化到具体的数据:

  1. 知道行业总的用户规模,自己的业务总的用户量,用户的特征分布。
  2. 熟悉行业的竞品,包括行业的排名、竞品的数据以及竞品间的差异和对比。
  3. 熟悉常见的获客手段和效果指标(ROI、转换率和留存率等),知道对自己的业务来说效果最好的3~5个获客手段以及原因。
  4. 熟悉常见的获利手段和效果指标(数值和比例等),知道对自己的业务来说最核心的3~5个获利来源。如果负责的是用户子系统这种不直接产生收入的业务,则可以了解自己的业务对收入会有什么影响。

不管你负责的是业务2C还是2B,这个方法论都是有效的。

它如果应用在2C业务中,就是有名的AARRR漏斗模型。你可以对用户生命周期中每个环节的行为和数据进行分析,来提升自己的业务理解能力。我会在后续的专项提升部分教你怎么理解和使用这个模型。

如果你从事的是2B业务,也可以参考AARRR漏斗模型的思路。但是具体的手段和措施是跟行业强相关的,不能照搬2C业务。你可以多跟团队有经验的前辈了解,也可以多跟售前和技术支持等人员请教。

管理:指挥10人以内的小团队

P7和P6最本质的区别体现在管理维度上。从P7开始,你就需要指挥团队了,所以管理能力的重要性大大上升。公司对你的要求不再只是完成自己的任务,而是还需要你带领团队一起把事情做好。

P7级别对管理的详细要求,我总结在了这张表格里:

管理要避免走极端

指挥团队确实是一个发展机遇,尤其是对于担任Team Leader的P7来说,因为能够自主规划一些有利于晋升的工作。但是反过来说,Team Leader也充满了挑战性,因为大部分人并没有系统地学习和练习过管理技能,所以在实际管理工作中很容易走极端。

第一种走极端的表现就是事必躬亲

什么意思呢?就是仍然按照以前的做事方法来带团队,无论事情大小都亲力亲为。

我不是不能理解这种做法。

有的人一直是通过这种做法拿到好结果的,因为思维惯性,就以为只要坚持这么做,管理团队的时候也能拿到好结果。

有的人特别害怕团队出问题,觉得团队的任何问题,Team Leader都有责任,所以就自己拼命干活,给别人兜底。

还有的人认为团队成员的能力比不上自己,所以什么工作都要手把手带着做才放心,觉得只有这样才能让他们有提升。

但是,事必躬亲的弊端是很明显的。

首先,你自己会觉得非常累。毕竟一个团队的事情很多,以前你只要做好自己的事情,可能还觉得游刃有余;现在如果要做团队所有人的事情,肯定是吃不消的。

很多人尝试管理岗位之后,觉得管理就是打杂,也是因为这个原因,各种会议、讨论和日常事务就已经让你疲于奔命了。

其次,团队成员感受不到你的信任,他们会觉得自己发挥的空间太小,没有提升空间。长此以往,就会人心浮动,非常不稳定。

第二种走极端的表现就是当甩手掌柜

跟事必躬亲正好相反,有些P7在当上Team Leader之后就彻底变成了甩手掌柜,只做管理不做事。来一个任务,他就找一个团队成员负责跟进,只要不出问题他就不管。还有些人,甚至出了问题也不管,而是换另外一个团队成员来处理,还美其名曰“授权式”管理。

这样做的弊端也很明显。首先,Team Leader的专业技能会逐渐退化,后续的晋升基本无望;其次,因为技能的退化,他对团队的影响力也会逐渐减弱,团队越来越难带,很难拿到好的结果。

因为上面说的这些问题,Team Leader的身份反而成了职业发展过程中的一个陷阱。很多人没有被提拔为Team Leader的时候,表现得很好,绩效年年优秀,被提拔之后反而表现不好,绩效也一般。

那么P7要怎么提升管理能力,把握担任Team Leader的机会呢?首要任务就是系统化地掌握管理的基本技能

所谓系统化,就是指从整体上理解管理的手段和范围,我划分了管理的四个象限来为你说明。

所谓基本技能,就是指团队怎么制定决策和执行任务,我总结了管理的六种风格来供你选择。

这部分内容,我会在专项提升部分为你详细展开。

找好管理和技术的平衡点

另外,P7级别的Team Leader还要做好管理工作和技术工作的平衡,既不能事必躬亲,也不要做甩手掌柜。关键就在于找准它们中间的平衡点。

我在这里分享一个简单的方法,三七比例法。也就是说,平均下来管理工作时间占30%,技术工作时间占70%。这个比例可以根据实际情况灵活变化,比如项目紧的时候二八开,年终总结汇报的时候四六开。

对于不是Team Leader的P7来说,管理上的提升目标主要是做一个靠谱的项目负责人。学习PDCA执行法(Plan-Do-Check-Act)能帮助你做到这一点,我会在做事方法部分为你详细解读。

小结

这一讲我基于COMD能力模型,给你详细解读了P7级别的具体要求以及对应的提升技巧。现在,我们回顾一下这一讲的重点:

  1. P7的核心能力要求是指挥单个团队达成目标,主要提升目标是成为让人信服的团队专家。
  2. 技术维度上,P7需要精通团队相关的技术,重点提升技术宽度,主要提升方法是“比较学习法”。在这个阶段,你既要避免因为管理而丢掉技术,也要避免“生搬硬套”新技术。
  3. 业务维度上,P7需要掌握业务整体情况,从用户特征、用户价值、获客方式和获利方式4个方面理解业务6~12个月的规划。对于2C业务,AARRR漏斗模型是必须掌握的;对于2B业务,还应该了解行业强相关的手段和措施。
  4. 管理维度上,P7需要负责指挥单个团队。对于担任Team Leader的P7来说,需要系统化地掌握管理的基本技能,避免事必躬亲或者做甩手掌柜;对于不是Team Leader的P7来说,要学会做一个靠谱的项目负责人。

思考题

这就是今天的全部内容,最后留一道课后思考题给你吧。虽然说P7是“永恒钻石”,晋升到P8很难,但实际上从P6晋升到P7也是一项很大的挑战,很多人经历过3次以上失败才晋升成功。你觉得最主要的原因可能是什么?

欢迎你把答案写到留言区,和我一起讨论。相信经过深度思考的回答,也会让你对知识的理解更加深刻。

精选留言(15)
  • 周平 👍(79) 💬(4)

    1.我确实做过一个专项topic,并且也是带着一堆人在搞,当时并没有意识到是在组织一个虚拟团队做事情,感恩领导给机会,感恩领导的的良苦用心。 2.从课里面提到的三个方面来看: 技术,业务,管理。 我当时主要精力应该是放在技术上了,业务可能也占了一些。管理方面的事情也在做,却是被推着走。 这种带虚拟团队的情况,安排工作靠威望,要是有人不听,貌似并没有太多的管理工具,感觉落地执行的时候,会是个问题。 所幸,当时大家都比较给力,那个topic完成的还可以。我想,这应当是team leader起了很大支持作用吧。 3.后来,团队调整,我去搞别的事情去了。领导也跳槽了。我想,这是晋升失败的一个主要原因,失去了成长的土壤,需要重新来过。 我想,如果再继续下去成长几年,应该还是有机会晋升成功的。 4.领导多次跟我说过,要“多发出自己的声音”,我现在也没弄清楚,为什么要发发出自己的声音,说给谁听?会有什么收益?是群发邮件发表意见,建议那种的声音么? 后来,在创业公司,也存在不爱发出自己声音的问题,觉得扯皮去撕没什么意思,有那个精力不如干点实事儿。

    2020-12-16

  • Geek_3239fe 👍(54) 💬(2)

    老师继续咨询下,想提高编码能力和水平的话。多刷leetcode?或者有一些比较好的建议不?

    2020-12-22

  • Geek_3239fe 👍(53) 💬(5)

    老师,关于职级的问题,请教下,如果出现这种情况,一般怎么抉择属于最优方案? 面试1:回流老东家,只能给到个6+的职级,薪资可以和7对标,面试2:去其他一二线大厂能直接给个7的职级。

    2020-12-22

  • 金鹏 👍(35) 💬(7)

    技术同学一般沉溺于技术,P7要考虑的是多纬度。技术对业务有什么价值?这个技术解决了什么业务问题?这些都需要可量化度量。 阿里讲把“虚事做实,实事做虚”,技术、业务的规划抽象能力,技术对业务的赋能以及形成闭环的能力,都需要P7的同学考虑。

    2020-12-16

  • 银剑 👍(24) 💬(1)

    因为没有了解到晋升P7是需要先具备一定的P7能力,而单纯的认为自己在P6级别得心应手就能晋升了。 所以在评审时,问技术细节可能还能对答如流,但一问技术选型或设计之类就比较迷茫了。业务方面同理,对自己开发的功能如数家珍,一问整体产品的价值以及规划之类就迷茫了。

    2020-12-16

  • lyonger 👍(23) 💬(3)

    华仔,您好。我有个疑惑想请教。 能升到P7的前提是有机会去负责这个级别要求的case。假如在互联网大厂里,所在岗位一直没有机会,给你去做P7这个级别对应的事情(比如成为虚拟团队负责人等)。毕竟僧多粥少,也不知道等到啥时候,这种该如何是好呢?

    2021-01-10

  • hua168 👍(22) 💬(2)

    大神,动不动就要精通,我有疑问 1.官方技术文档和市面上的书,大部分是入门,部分进阶,自己怎么弄成精通?连大门在哪里都不知道😂 2.有老婆孩子,撇开加班不讲,下班要陪老婆孩子,每天就能抽1-1.5小时学习,在累的情况下学习往往效率低,有那么多时间成长成精通?

    2020-12-17

  • Johar 👍(8) 💬(1)

    工作一般分成三种:管团队,管业务,管技术。职位岗位的不同,造成在工作上,三个方面占的比例不同。例如:P5:90%技术+10%业务;P6:80%技术+10%管理+10%业务;P7:60%技术+30%管理+10%业务。目前自己在工作中也是范了类似的错误:1.事必躬亲,芝麻大豆一起抓;2.时间投入比例不对,目前基本上是40%管理+50%业务+10%技术,已经很危险!

    2020-12-23

  • Lovely粉豆蛙 👍(7) 💬(1)

    华哥,今年毕业,参加了阿里星答辩但最后定级P6 A+,一年内有可能升到P7吗?主要是不是就要证明自己能承担起P7的任务?团队做的是Git相关底层技术,规模10个人左右,目前算上我应该4个P6~

    2021-01-17

  • Geek_59b133 👍(7) 💬(1)

    最主要原因是不清楚晋升侧重点,通过多次人肉测试,总结经验

    2020-12-17

  • 青见 👍(5) 💬(1)

    读完这个 对标下 P7的事情做了3年 P8的事情做了2年 结果组织架构的变动发现现在又做回P7的事情 ;收获颇多。

    2021-01-19

  • Geek_5788be 👍(5) 💬(1)

    有个问题困扰许久,望指点。 情况:从实习开始,在团队中一直承担:技术分享安排审核、编码规范编写落地 这些团队事务,一直到现在p7了,影响力确实扩大,软实力也具备了,但是我总觉得自己技术基础还没来得及打扎实。 困扰:这些非技术的事宜会不会太占用技术深度发展的时间呢?不一定非要 什么阶段该干什么,但是自己会不会走偏呢?

    2020-12-24

  • 怀揣梦想的学渣 👍(4) 💬(1)

    这么一对比,我真实能力距离P7还有一段挺大的距离。扎心了

    2022-06-23

  • 李日煌 👍(4) 💬(1)

    不仅需要跟自己比,更需要跟其他人比,不是你不够优秀而是有其他人比你更优秀,这才是晋升最大的根结,所以找到团队中最优秀的那个人去对标,看自己是什么段位,面向晋升学习,工作,努力,结果应该会不会太差。

    2021-04-06

  • 右耳朵猫咪 👍(4) 💬(1)

    最主要的原因就是面试官没让过

    2020-12-16