大厂P6职级提升攻略

不念不忘少年蓝@ 2024-03-26 14:35 52阅读 0赞

P5核心能力要求：在他人指导下完成任务。若能从P5晋升P6，说明你已完成从学生到打工人，成长为一名合格员工。P6对应工作2～5年

### 1 核心能力要求 ###

独立负责端到端任务

#### 1.1 独立 ####

P6做的跟P5差不多事，但无需别人带着做。P5、P6都会参加需求评审，只不过P5参加时只是在听，而P6可能针对需求直接提出意见。

#### 1.2 端到端 ####

负责项目中的某部分功能的全流程相关事项。

*  开发的端到端事项包括需求评审、方案设计、编码、修改bug和上线等
 *  测试的端到端事项包括需求评审、测试方案设计、执行测试和上线等
 *  产品的端到端事项则包括用户分析、需求写作、数据分析和竞品分析等

P6、P7是主要劳动力，占团队60%～80%。P6主要提升目标是成为独立自主的项目能手。

### 2 技术：掌握团队用到的技术“套路” ###

P6的技术核心要求：熟练掌握端到端的工作流技术，因为P6是项目主力，需参与项目流程中的某些阶段，完成任务。

#### 2.1 技术详细要求 ####

![40ccf873dc8f44ef94123d1a265cf817.png][]

P6提升技术能力的关键：掌握团队用到的各种技术的“套路”。

如Android开发，套路包括设计模式、SOLID设计原则、MVP架构和各类工具（比如Fiddler，Wireshark，tcpdump）等。不同岗位的“套路”不同，也可求助有经验同事。

P5只要了解一些单个技术点；但P6须知怎么**整合**这些技术套路，完成端到端的项目开发任务。P6要知道如何将数据库、缓存、面向对象、设计模式、HTTP等技术点整合起来完成某功能开发。

#### 2.2 提升技术深度 ####

除了熟练使用套路，P6还要深入理解套路背后的技术原理和细节，提升自己的**技术深度**。

设计模式为例，P5只知道每个设计模式啥意思，但P6要知道何时用设计模式，何时不用，具体用哪个。

这也是P6能指导P5的原因：P5只知what，P6还知why。

P6阶段提升技术时，易掉到陷阱：

#### 2.3 贪多求全 ####

你可能看了很多技术，其他人说起某个技术点的时候，你都有印象。但只是蜻蜓点水，无深入学习。

#### 2.4 正确做法 ####

重点抓住跟当前工作内容强相关的技术点和技术套路，深入学习和研究，重点提升技术深度。有精力再拓展学习一些暂时用不到、但以后可能用到的技术。

千万不要因为短时间内什么流行就去学什么，一会儿学这一会学那，结果啥就懂一点，啥都不精。

### 3 业务：掌握所有功能，并深度理解处理逻辑 ###

P6比P5提升主要体现在：

*  P6对功能掌握更全面；P5只掌握部分功能，P6基本要求掌握某类业务所有功能
 *  P6对处理逻辑的理解更深刻；P5只需知道具体需求处理逻辑，而P6要求理解需求的“上下文信息”，如需求给用户/客户带来的价值是什么，解决啥问题，为何要设计5步而非3步，为何竞品功能设计不一样

#### 业务能力要求 ####

![7c5625508aaf42ecad26a172bc1ea110.png][]

P6级别提升业务能力的核心方法是“5W1H8C1D”分析法。

传统“5W1H”分析法，只关注需求的功能属性，所以我在“5W1H”基础上，增加对需求的质量属性（8C）和上线后效果（1D）的考虑。

做好**竞品分析**也很重要。通过对比竞品和自己的产品类似功能的差异、优劣，你能够更好理解业务。

### 4 管理 ###

负责项目中的子任务推进。

#### 4.1 具体的管理要求 ####

![dab7b9503a434d68afa6be013b434be0.png][]

#### 4.2 工作量评估：WBS分解法 ####

P6管理职责包括任务的工作量评估、计划制定及分配和跟踪等。

工作量评估是P6核心职责，计划制定以及分配和跟踪，主要是配合项目经理来完成。

工作量评估的准确性是第一步，直接影响后续工作合理性。掌握工作量评估的有效方法，也是P6管理方面核心力。

很多人在评估工作量的时候无依据，心虚，若项目经理或产品经理稍微挑战，易退让，导致工作量压缩。到实际项目执行时，发现工作量评估偏少，为赶项目进度，就996。

工作量评估方面，有的团队做法和WBS相似，列了一个子任务技术难点清单，然后分级，每个级别按照斐波那契数赋予难度系数。分析任务和方案时，开发人员也按照这个清单，评估工作量，避免主观评估了。

##### 评估方法 #####

###### 拍脑袋法 ######

让团队有经验的人直接拍脑袋想一个工作量数字。

###### 扑克牌法 ######

找3～5个人员，每人给一张小纸条，每个人把工作量评估写在纸条上，最后取平均值。

###### 对比法 ######

参考曾经做过的类似的项目，看看之前的项目工作量是多少，然后以此为基础想一个数字。

###### WBS分解法 ######

把需求拆解为多项小任务，单独评估每个小任务的工作量，然后汇总；评估小任务的工作量的时候可能采取上面这3种方法。

WBS分解法效果最好，评估误差基本不超20%。Work Breakdown Structure，工作分解结构，通过把项目工作按**阶段可交付成果**分解成更小的、更易管理的组成部分，提升项目管理效率。

朋友圈点赞为例，开发人员采用WBS得到如下任务分解表格：

![78b2e6d31ef34bc4a1d3a31877975fb5.png][]

对分解出来的子任务项，就能用“拍脑袋法”评估。这兼顾效率和效果，因为子任务项已较小，基本凭经验就能够得到较合理结果。就算单任务项有偏差，也是有的偏多有的偏少，最终偏差反而互相抵消。

#### 4.3 避免过于乐观：加Buffer ####

大部分人评估都比较乐观，且项目过程中可能各种意外（如某开发或测试人员病了）。在实践中，为避免过于乐观评估给后面项目进度带来风险，往往采取加Buffer（缓冲），即将评估初步结果乘以一个大于1的系数作为项目工作量。

若初评工作量14人天，Buffer系数1.2，最终项目计划时，参考工作量17人天：

14\*1.2 = 16.8 ≈ 17

Buffer系数可在1.2～1.6之间浮动，一般根据项目的复杂度决定。全新的业务功能Buffer会高一些，在已有业务功能上修改时，Buffer较低。

### 5 总结 ###

P6核心能力要求：独立负责端到端项目任务，成为独立自主“项目能手”。

*  技术层，P6需掌握团队用到的各种技术“套路”，重点提升技术深度，学习避免贪多求全，优先深入学习跟工作内容强相关技术
 *  业务层，P6需掌握某类业务相关所有功能，并深度理解处理逻辑，主要提升方法：“5W1H8C1D”分析法和竞品分析
 *  管理层，P6需负责项目子任务推进，包括工作量评估、计划制定和沟通协调等。评估工作量推荐WBS分解法，先拆解成容易评估的小任务，然后独立评估每项任务，最后汇总

### 6 FAQ ###

#### 晋升评委如何分配三维在职级能力的占比 ####

*  技术7
 *  业务2
 *  管理1

P6主要还是实现及性能质量保证，而业务和管理需要有这个意识。P7及以上业务管理的占比就要提高了。

#### 2B系统竞品分析 ####

2B系统的底层通用能力或内部使用系统，如审核系统，数据报表系统等，怎么做竞品分析？看不到竞对的类似功能呀！

2B系统有很多竞品资料可从客户那里获取，竞品的资料和标书在市场部能搞到很多。内部系统确实较难，一般只有技术大会能看到一些分享，但现在也比以前好很多，有很多垂直领域技术大会，如GOPS（运维）、大数据峰会（审核、报表、风控等领域）、人工智能峰会等，可以关注和参与这些技术大会。

#### IT岗业绩衡量标准 ####

如销售岗位员工有销售额业绩，运营岗位有用户活跃度等，这些都可作为工作业绩或成果，他们有明确目标，可以针对目标情况复盘总结哪里可以做的更好。  
而开发岗位似乎主要编码完成一个个需求，对应工作业绩或成果是啥？导致回顾自己的工作时，难以像业务岗人员那样有明确的目标可以得知自己哪里做的好，哪里不好。

*  红线考核：如P2级以上生产问题，考评就是3.25
 *  质量考核：看你工作质量和效率，如bug数、版本delay数
 *  群体智慧（360、环评）：有的团队互相打分，或主管找产品运营项目经理或者合作团队等配合团队的人来评分
 *  主管凭感觉：各种会议、各种项目、各种事件处理过程中的表现

技术岗位无法量化，不可能100%公平公正，但整体上来说，如果按照上面的方式来评，八九不离十。

#### P7、P8如何平衡技术和管理 ####

熟悉的工作内容和工作方法，原来这就是P6主要工作，我也曾做这些工作好长时间。回想做这些工作的时期，也存在一些问题，如领导挑战我的排期，我都退步，最后大部分是自己加班。

在面对产品，运营需求，在他们描述完对上线后，我也产生了这些产出，这些收益的渴望，我也挺愿意早日上线的。一般，我会主动做出让步，这却使自己陷入长期，频繁的加班之中。当然，也做了很多事。和上下游各部门合作也愉快。

加班不算什么，重要的是要把时间花在了更重要的地方，使自己成长更快。而努力的方向不对，则可能成为一个熟练，好用的工具人，一直不得成长。

我的几个导师，都是再升一级做管理了。我却还想沉下心来搞技术，做到50多岁还写码那种。不知道那个级别的技术高工，工作内容都是什么样？

管理和技术不冲突，尤其是你能够带着团队来做技术，那种感觉更爽，毕竟一个人的力量始终有限，发挥团队的力量才能干大事。

#### 业务开发，技术好像很难体现？ ####

怎么会呢？前端可以开发体验好的页面；后端可以设计高性能的索引，这些都是用户在使用业务的时候能直观感受到的。

#### 小公司运维如何破局 ####

小公司运维，就1-2人这种，什么都没有，管理服务器（包括云主机）也就是几十至300这样，上级一般是开发经理，他都不怎么懂运维，只会安排零散工作。连什么是运维项目、完整的运维流程都没接触过？怎么成长？也不知道在哪里找资料、书籍类。

换个坑，回顾晋升三原则的价值原则部分，若公司就这规模，你水平高也不能为公司创造额外价值，更何况你连学习的机会都没有。运维书籍：谷歌的SRE、Netflix的混沌工程，还有DevOps的很多书籍。  
技术大会有GOPS等运维技术大会，有很多资料和演讲PPT都能搜到。

[40ccf873dc8f44ef94123d1a265cf817.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/3b903aa5ca2a44d7997c9d12d6eccfc8.png
[7c5625508aaf42ecad26a172bc1ea110.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/3ec0683c41894068bcde29986147ff03.png
[dab7b9503a434d68afa6be013b434be0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/260a72a7d9c441b88ea0e4728b064b7b.png
[78b2e6d31ef34bc4a1d3a31877975fb5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/5fb4f9cd046841be88ca1e9a02e4af70.png