18 KiB
你好，我是华仔。
上一讲我们学到了，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点要求，并且要能够量化到具体的数据：
- 知道行业总的用户规模，自己的业务总的用户量，用户的特征分布。
- 熟悉行业的竞品，包括行业的排名、竞品的数据以及竞品间的差异和对比。
- 熟悉常见的获客手段和效果指标（ROI、转换率和留存率等），知道对自己的业务来说效果最好的3～5个获客手段以及原因。
- 熟悉常见的获利手段和效果指标（数值和比例等），知道对自己的业务来说最核心的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级别的具体要求以及对应的提升技巧。现在，我们回顾一下这一讲的重点：
- P7的核心能力要求是指挥单个团队达成目标，主要提升目标是成为让人信服的团队专家。
- 技术维度上，P7需要精通团队相关的技术，重点提升技术宽度，主要提升方法是“比较学习法”。在这个阶段，你既要避免因为管理而丢掉技术，也要避免“生搬硬套”新技术。
- 业务维度上，P7需要掌握业务整体情况，从用户特征、用户价值、获客方式和获利方式4个方面理解业务6～12个月的规划。对于2C业务，AARRR漏斗模型是必须掌握的；对于2B业务，还应该了解行业强相关的手段和措施。
思考题
这就是今天的全部内容，最后留一道课后思考题给你吧。虽然说P7是“永恒钻石”，晋升到P8很难，但实际上从P6晋升到P7也是一项很大的挑战，很多人经历过3次以上失败才晋升成功。你觉得最主要的原因可能是什么？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
