1 核心能力要求
独立负责端到端任务
1.1 独立
P6做的跟P5差不多事，但无需别人带着做。P5、P6都会参加需求评审，只不过P5参加时只是在听，而P6可能针对需求直接提出意见。
1.2 端到端
负责项目中的某部分功能的全流程相关事项。
开发的端到端事项包括需求评审、方案设计、编码、修改bug和上线等
测试的端到端事项包括需求评审、测试方案设计、执行测试和上线等
产品的端到端事项则包括用户分析、需求写作、数据分析和竞品分析等
P6、P7是主要劳动力，占团队60%～80%。P6主要提升目标是成为独立自主的项目能手。
2 技术：掌握团队用到的技术“套路”
P6的技术核心要求：熟练掌握端到端的工作流技术，因为P6是项目主力，需参与项目流程中的某些阶段，完成任务。
2.1 技术详细要求
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步，为何竞品功能设计不一样
业务能力要求
P6级别提升业务能力的核心方法是“5W1H8C1D”分析法。
传统“5W1H”分析法，只关注需求的功能属性，所以我在“5W1H”基础上，增加对需求的质量属性（8C）和上线后效果（1D）的考虑。
做好竞品分析也很重要。通过对比竞品和自己的产品类似功能的差异、优劣，你能够更好理解业务。
4 管理
负责项目中的子任务推进。
4.1 具体的管理要求
4.2 工作量评估：WBS分解法
P6管理职责包括任务的工作量评估、计划制定及分配和跟踪等。
工作量评估是P6核心职责，计划制定以及分配和跟踪，主要是配合项目经理来完成。
工作量评估的准确性是第一步，直接影响后续工作合理性。掌握工作量评估的有效方法，也是P6管理方面核心力。
很多人在评估工作量的时候无依据，心虚，若项目经理或产品经理稍微挑战，易退让，导致工作量压缩。到实际项目执行时，发现工作量评估偏少，为赶项目进度，就996。
工作量评估方面，有的团队做法和WBS相似，列了一个子任务技术难点清单，然后分级，每个级别按照斐波那契数赋予难度系数。分析任务和方案时，开发人员也按照这个清单，评估工作量，避免主观评估了。
评估方法
拍脑袋法
让团队有经验的人直接拍脑袋想一个工作量数字。
扑克牌法
找3～5个人员，每人给一张小纸条，每个人把工作量评估写在纸条上，最后取平均值。
对比法
参考曾经做过的类似的项目，看看之前的项目工作量是多少，然后以此为基础想一个数字。
WBS分解法
把需求拆解为多项小任务，单独评估每个小任务的工作量，然后汇总；评估小任务的工作量的时候可能采取上面这3种方法。
WBS分解法效果最好，评估误差基本不超20%。Work Breakdown Structure，工作分解结构，通过把项目工作按阶段可交付成果分解成更小的、更易管理的组成部分，提升项目管理效率。
朋友圈点赞为例，开发人员采用WBS得到如下任务分解表格：
对分解出来的子任务项，就能用“拍脑袋法”评估。这兼顾效率和效果，因为子任务项已较小，基本凭经验就能够得到较合理结果。就算单任务项有偏差，也是有的偏多有的偏少，最终偏差反而互相抵消。
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都能搜到。
