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

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

09 | P7提升攻略：怎么成为让人信服的“团队专家”？-极客时间

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

2020-12-16 李运华 来自北京
《大厂晋升指南》
课程介绍

讲述：安晓辉

时长19:30大小17.81M

你好，我是华仔。
上一讲我们学到了，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 需要负责指挥单个团队。对于担任 Team Leader 的 P7 来说，需要系统化地掌握管理的基本技能，避免事必躬亲或者做甩手掌柜；对于不是 Team Leader 的 P7 来说，要学会做一个靠谱的项目负责人。

思考题

这就是今天的全部内容，最后留一道课后思考题给你吧。虽然说 P7 是“永恒钻石”，晋升到 P8 很难，但实际上从 P6 晋升到 P7 也是一项很大的挑战，很多人经历过 3 次以上失败才晋升成功。你觉得最主要的原因可能是什么？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 26

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
08 | P6提升攻略：怎么成为独立自主的“项目能手”？
下一篇
10 | P8提升攻略：怎么成为有影响力的“领域专家”？
unpreview
 写留言

精选留言(36)

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

    作者回复: 1. 可以的话，当面跟前领导表示感谢 2. 虚拟团队一般是TL安排的，工作实在安排不下，可以借助TL的力量，但一般不要轻易用这个方法，最好是自己的专业技巧足够影响别人 3. 这就是晋升也有运气成分的一个表现 4. 发出声音给团队成员，其它TL、项目经理等听，这样别人就知道你的水平，不然你就蒙头干活，除了跟你紧密合作的几个同事知道你的水平外，其他人一无所知，你可以看看在晋升流程中的预审环节、评审环节中涉及的人，这些人都不是你团队内的，而是部门甚至公司内的。 发声音很多种方式：写文章、培训、担任虚拟团队负责人、做演讲、开会的时候提出自己的看法、评审的时候发表自己的意见……都可以

    共 4 条评论
    68
  • Geek_3239fe
    2020-12-22
    老师继续咨询下，想提高编码能力和水平的话。多刷leetcode？或者有一些比较好的建议不？

    作者回复: 研究牛逼的开源项目核心代码，例如Nginx、netty的reactor模型、Disruptor的cache line、无锁设计；netty的pipeline处理模型等，kafka如何使用磁盘来保证消息队列高性能等 leetcode并不一定能提升你实际工作中的编码能力

    共 2 条评论
    49
  • Geek_3239fe
    2020-12-22
    老师，关于职级的问题，请教下，如果出现这种情况，一般怎么抉择属于最优方案？ 面试1：回流老东家，只能给到个6+的职级，薪资可以和7对标，面试2：去其他一二线大厂能直接给个7的职级。

    作者回复: 只要钱给到位，选P6+当然更好啊，因为你入职后可以很快就有晋升机会，晋升成功了又可以升职加薪；如果直接就P7了，下一次晋级P8可能就不知道什么时候了。

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

    作者回复: 能够把阿里抽象的描述理解到位，一看就是老阿里人了 ：）

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

    作者回复: 晋升和读书不一样，读书是考学过的内容是否掌握，掌握了就读下一年级；晋升是先看能否做下一级别的事情，会做了再晋升。 当你明白了P7的具体要求后，就可以对照我说的技巧来做了，争取下次顺利晋升。

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

    作者回复: 这里要分情况： 1. 团队有机会，你没机会：这个需要自我评估一下，是确实不如其它P7，还是和主管关系不好，最好找主管聊聊 2. 部门有机会，团队没机会：这个一般是因为团队主管自己就拿不到机会，如果感觉一段时间内不会有很大改善，可以考虑转岗 3. 部门本身就没什么机会：这个说明业务发展出问题了，如果持续时间比较长了，转岗或者换工作可能是更好的选择

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

    作者回复: 1. 没时间这个问题，后面的“海绵学习法”教你怎么找时间 2. 学到什么程度，怎么学，后面的“链式学习法、比较学习法”就是教你如何更有效率的提升技术。 每天1小时已经很不错了，够你提升了 ：）

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

    作者回复: 你这样相当于90%做管理了，因为业务部分对技术人员来说主要也是参加讨论，不会自己亲自去用户调研，写需求，想方向，所以这部分也算管理工作。 按照这个比例投入是不可能晋升的，你看看P8的那一讲就知道了

    6
  • Geek_59b133
    2020-12-17
    最主要原因是不清楚晋升侧重点，通过多次人肉测试，总结经验

    作者回复: 人肉测试那就要承受多次暴击😂😂

    6
  • 右耳朵猫咪
    2020-12-16
    最主要的原因就是面试官没让过

    作者回复: 那面试官为什么没让人过呢 ？

    5
  • 青见
    2021-01-19
    读完这个 对标下 P7的事情做了3年 P8的事情做了2年 结果组织架构的变动发现现在又做回P7的事情 ；收获颇多。

    作者回复: 这是辛辛苦苦忙3年，一朝回到解放前么 ：） 不过不用担心，能力准备好了，就是等待合适的时机了，组织架构还会再变的，也许下一次你就有机会了。

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

    作者回复: 不太清楚是你主要是做这些事情还是兼任着做，如果主要做这些事情都能升上P7，这种发展路径一般都是机缘巧合，且有人提拔，不然是很难升到P7的。 如果只是兼任做着，那你应该在P5、P6阶段是有时间打基础的。 当然，也可能是你对“基础”的理解有误，误以为要把整个计算机技术的基础都掌握，这是不可能的。

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

    作者回复: 我只能说概率上来说很难，你能毕业定级P6，说明你在毕业生这个群体里面已经是非常优秀了，接下来2年你要证明自己配得上P6的定级，想1年内立刻升P7几乎不可能。

    4
  • 哄哄
    2021-01-07
    现在阿里职级膨胀，P7巨多且基本不带人了，P8又比较少，僧多粥少，新晋升的P7如何才能快速发展😑

    作者回复: 你需要看P8这篇😂

    3
  • Geek_9a1779
    2021-12-24
    华仔，问一个职业规划问题：当前在类似P7的岗位上一年半左右时间，带10个人左右的团队，但是现在所在的业务比较边缘，前段时间业务项目空窗期了2、3个月，团队都在做技术项目；现在有另外一个机会去其他核心团队，但是从0开始，刚开始可能就带1、2个人。有什么建议么？

    作者回复: 你的团队是你的资本，可以找你的老大安排新任务； 所谓的核心团队还是从0开始的话，大部分都是忽悠的 ：）

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

    作者回复: 不要跨级对标，可以对标你将要晋升的级别的人员。

    2
  • 好奇分析
    2021-03-28
    1. P6升P7，从准备晋升开始就是一道坎。P6做的事情很多时候都是很小的一块。这块内容可能做的很出色，但是达不到P7的系统性思考的目的。也确实可能缺乏系统性思考。 2. 本人作为一个运营同学，还会有另一个难点。在一个技术团队，本身存在一个运营同学就比较奇怪。可能因为是新的无人竞争的领域，会导致结果还行。但是从晋升的角度看，做的内容不成体系。即使是一个体系性的东西可能受众也不广。 3. 如何证明自己的能力已经达到了跃迁的地步也是比较难的。很多时候你做的事情可能其他P6的同学也在做。或者你做的事情更多的是苦劳，你可以说你是担当，但是这并不构成能力层次的提升。 4. 如何将当前手上的任务包装成一套体系或者方法论？ 在竞争的时候才开始去准备 ，就会发现远远来不及。原因是一开始你做的事情，就不是体系化的。
    展开

    作者回复: 你们团队的组织结构有点奇怪呀，正常来说不应该这样组建团队。 如果只有你一个运营的话，要学习运营方法论，或者自己整理方法论，其实还是有一定挑战的，P6这个级别最好直接学习已有的方法论和体系，而不要自己摸索。

    共 2 条评论
    2
  • bai
    2021-03-18
    有个小疑惑点，开发的方案设计讨论属于技术部分吗

    作者回复: 属于技术部分，但通常情况下P6的能力就覆盖了，除非这个方案设计规模和复杂度达到P7的要求。

    1
  • Monday
    2021-01-11
    提升业务理解力的四种方法让我异常兴奋。拿走了。谢谢

    作者回复: 后面还会有详细的介绍AARRR

    2
  • Jake
    2020-12-22
    晋升失败个人总结主要是三种:11.没有好的项目，在公司价值上吃亏，效益不能量化；2.评委风格和个人不匹配；3.个人总结抽象不够，没有把自己个团队贡献阐述出来

    作者回复: 1. 不能量化可能是你没掌握量化技巧，在后面的晋升技巧部分会讲； 2. 评委风格和个人风格不匹配这个说法有点含糊其辞，我理解是不是你的想法和做法不太符合团队的共识；当然，也可能就是运气原因 3. 这部分是常见的错误，技术人员比较实诚，不太会讲虚的，不太会提炼总结抽象

    1