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

08 | P6提升攻略：怎么成为独立自主的“项目能手”？

08 | P6提升攻略：怎么成为独立自主的“项目能手”？-极客时间

08 | P6提升攻略：怎么成为独立自主的“项目能手”？

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

讲述：安晓辉

时长11:04大小10.10M

你好，我是华仔。
上一讲我们学到了，P5 的核心能力要求是在别人的指导下完成任务。如果能够从 P5 晋升到 P6，就说明你已经完成了从学生到打工人的角色转变，成长为一名合格的员工了。这一讲我们就来了解一下 P6 的能力要求和提升建议。
P6 对应的工作年限是 2～5 年，核心能力要求可以用一句话来概括，独立负责端到端的任务。这句话有两个关键词：
独立：P6 做的事情跟 P5 差不多，但已经不需要别人带着做了。P5 和 P6 的开发人员都会参加需求评审，只不过 P5 参加的时候只是在听，而 P6 可能就会针对需求直接提出意见。
端到端：负责项目中的某部分功能的全流程相关事项。开发的端到端事项包括需求评审、方案设计、编码、修改 bug 和上线等；测试的端到端事项包括需求评审、测试方案设计、执行测试和上线等；而产品的端到端事项则包括用户分析、需求写作、数据分析和竞品分析等。
P6 和 P7 是业界主要的劳动力，这两个级别的人数加起来，估计能够占到团队总人数的 60%～80%。P6 级别的主要提升目标是成为独立自主的项目能手。接下来，我就从技术、业务和管理三个维度一一展开进行讲解。

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

P6 在技术方面的核心要求是熟练掌握端到端的工作流技术，因为 P6 是项目主力劳动力，需要参与项目流程中的某些阶段，完成分配的任务。
P6 级别的技术详细要求，我总结在了这张表格里：
在 P6 阶段，提升技术能力的关键就是掌握团队用到的各种技术的“套路”。以 Android 开发人员为例，套路包括设计模式、SOLID 设计原则、Android 的 MVP 架构和各类工具（比如 Fiddler，Wireshark，tcpdump）等。不同岗位的“套路”不同，你可以自行整理，也可以求助团队中有经验的同事。
在 P5 阶段，你可能只要了解一些单个的技术点就能完成工作；但是到了 P6，你就必须知道怎么整合这些技术套路，来完成端到端的项目开发任务。
以 Java 后端开发为例，P6 需要知道如何将数据库、缓存、面向对象、设计模式、HTTP 等技术点整合起来完成某个功能的开发。

提升技术深度

除了熟练使用套路，P6 还需要深入理解套路背后的技术原理和细节，提升自己的技术深度。
以设计模式为例，P5 可能只知道每个设计模式是什么意思，但是 P6 还要知道什么时候用设计模式，什么时候不用设计模式，具体应该用哪个设计模式。
这也是 P6 能够指导 P5 的原因：P5 只知道 what，P6 还知道 why。
P6 阶段提升技术的时候，很容易掉到一个陷阱里，那就是贪多求全。你可能看了很多技术，其他人说起某个技术点的时候，你都有印象。但其实你只是蜻蜓点水，并没有深入学习。
正确的做法是什么呢？重点抓住跟当前工作内容强相关的技术点和技术套路，深入学习和研究，重点提升技术深度。如果有精力，你再去拓展学习一些暂时用不到、但以后很可能会用到的技术。
千万不要因为短时间内什么流行就去学什么，一会儿学这个一会学那个，结果什么都懂一点，什么都不精通。

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

在业务能力上，P6 相比 P5 的提升主要体现在两方面。
一是 P6 对功能掌握得更全面。P5 只掌握了其中一部分功能，而 P6 基本上要求掌握某类业务的所有功能。
二是 P6 对处理逻辑的理解更深刻。P5 只需要知道具体的需求处理逻辑是什么，而 P6 要求理解需求的“上下文信息”，比如需求给用户 / 客户带来的价值是什么，解决了什么问题，为什么要设计 5 个步骤而不是 3 个步骤，为什么竞品的功能设计跟我们不一样。
P6 级别的业务能力要求，我总结在了这张表格里：
P6 级别提升业务能力的核心方法是我自创的“5W1H8C1D”分析法。传统的“5W1H”分析法只关注需求的功能属性，所以我在“5W1H”基础上，又增加了对需求的质量属性（8C）和上线后效果（1D）的考虑。
这个方法不是一两句话能够讲清楚的，我会在课程的专项提升部分专门用 1 讲的篇幅为你详细介绍。
除了这个方法之外，认真做好竞品分析也很重要。通过对比竞品和自己的产品类似功能的差异、优劣，你能够更好地理解业务。

管理：推进项目中的子任务

P6 管理能力的要求主要是能够负责项目中的子任务推进。
具体的管理要求，我总结在了这张表格里：

工作量评估：WBS 分解法

P6 的管理职责包括任务的工作量评估、计划制定以及分配和跟踪等。其中工作量评估是 P6 的核心职责，而计划制定以及分配和跟踪，主要是配合项目经理来完成的。而且，工作量评估的准确性是第一步，会直接影响到后续工作的合理性。
所以，掌握工作量评估的有效方法，也是 P6 在管理方面的核心能力。
很多人在评估工作量的时候没有依据，所以心里比较虚，如果项目经理或者产品经理稍微挑战一下，就会很容易退让，导致工作量被压缩。到了实际项目执行的时候，他们发现工作量评估偏少了，为了赶上项目进度，就只能加班加点。
我在职业生涯中遇到过四种评估方法：
拍脑袋法：让团队有经验的人直接拍脑袋想一个工作量数字。
扑克牌法：找 3～5 个人员，每人给一张小纸条，每个人把工作量评估写在纸条上，最后取平均值。
对比法：参考曾经做过的类似的项目，看看之前的项目工作量是多少，然后以此为基础想一个数字。
WBS 分解法：把需求拆解为多项小任务，单独评估每个小任务的工作量，然后汇总；评估小任务的工作量的时候可能采取上面这 3 种方法。
从实践经验来看，WBS 分解法的效果是最好的，评估的误差基本上不会超过 20%。
WBS 的全称是 Work Breakdown Structure，中文翻译是“工作分解结构”。WBS 分解法的原理是，通过把项目工作按阶段可交付成果分解成更小的、更易于管理的组成部分，来提升项目管理的效率。
我们以朋友圈点赞为例，开发人员采用 WBS 分解方法，可以得到下面这个任务分解表格：
对于分解出来的子任务项，我们就可以用“拍脑袋法”评估工作量了。这样做能够兼顾效率和效果，因为子任务项已经比较小，基本上你凭经验就能够得到比较合理的结果。就算单个任务项有偏差，也是有的偏多有的偏少，最终的偏差反而会互相抵消。

避免过于乐观：加 Buffer

大部分人在评估工作量的时候都会比较乐观，而且在项目过程中可能有各种意外出现（比如某个开发或者测试人员生病）。在实践中，为了避免过于乐观的评估给后面的项目进度带来风险，我们往往会采取加 Buffer（缓冲）的做法，也就是说，将评估的初步结果乘以一个大于 1 的系数来作为项目的工作量。
还是拿朋友圈点赞功能来说明，如果初步评估的工作量是 14 人天，Buffer 系数取 1.2，那么最终做项目计划时，参考工作量就是 17 人天（14*1.2 = 16.8 ≈ 17）。
这个 Buffer 系数可以在 1.2～1.6 之间浮动，一般根据项目的复杂度决定。全新的业务功能 Buffer 会高一些，在已有业务功能上修改时 Buffer 会低一些。

小结

这一讲我基于 COMD 能力模型，给你详细解读了 P6 级别的具体要求以及对应的提升技巧。现在，我们回顾一下这一讲的重点：
P6 的核心能力要求是独立负责端到端的项目任务，主要提升目标是成为独立自主的“项目能手”。
技术方面，P6 需要掌握团队用到的各种技术的“套路”，重点提升技术深度，学习时要避免贪多求全的心态，优先深入学习跟工作内容强相关的技术。
业务方面，P6 需要掌握某类业务相关的所有功能，并深度理解处理逻辑，主要的提升方法是“5W1H8C1D”分析法和竞品分析。
管理方面，P6 需要负责项目子任务推进，包括工作量评估、计划制定和沟通协调等。评估工作量的时候，建议使用 WBS 分解法，先拆解成容易评估的小任务，然后独立评估每项任务，最后汇总。

思考题

这就是今天的全部内容，留一道课后思考题给你吧。P6 的能力要求已经比较全面地覆盖了技术、业务和管理三个维度。假如你是晋升评委，你会怎么分配这三个维度在职级能力中的占比呢，理由是什么？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 40

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
07 | P5提升攻略：怎么快速从学生转变为“打工人”？
下一篇
09 | P7提升攻略：怎么成为让人信服的“团队专家”？
unpreview
 写留言

精选留言(29)

  • ls
    2020-12-14
    技术6 业务2 管理2。P6 主要还是实现及性能质量保证，而业务和管理需要有这个意识。P7及以上业务管理的占比就要提高了

    作者回复: 你的答案很接近了，一般来说技术占7，管理占1

    共 3 条评论
    40
  • 圈圈gor
    2020-12-17
    工作量评估方面，我们的做法和WBS相似，列了一个子任务技术难点清单，然后分级，每个级别按照斐波那契数赋予难度系数。分析任务和方案时，开发人员也按照这个清单，评估工作量，避免主观评估了。

    作者回复: 斐波那契这个做法牛啊😂😂

    共 2 条评论
    26
  • 南风
    2021-01-17
    所以，p6想晋升，最核心的就是深度啦

    作者回复: 是的，一语中的，但如果只有深度，对业务完全不懂、团队方面也没有任何贡献的话，也可能会吃亏的。

    24
  • 小波Transformers
    2021-03-06
    老师，在中国程序员真的走35岁被退休的说法吗？技术一般的、35岁以后的程序员，应该往哪个方向努力？甚至说往哪个新的职业转型、转业？

    作者回复: 有的，35岁如果还是P7或者更低的话，找工作很难的；但是如果已经有工作了，一般也不会强制辞退，所以如果到了35的话，一般不要轻举妄动。 转型方向目前没有太好的选择，有的去小公司，有的去国企或者事业单位，有的自己开店，这个需要你自己综合评估一下，风险考虑是第一位的。

    共 3 条评论
    18
  • 不工
    2021-01-04
    如果是2B系统中的底层通用能力或者内部使用的系统，比如说审核系统，数据报表系统等，怎么去做竞品分析？看不到竞对的类似功能

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

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

    作者回复: 换个坑最好，你回顾一下晋升三原则的价值原则部分，如果公司就这个规模，你水平高也不能为公司创造额外价值，更何况你连学习的机会都没有。 运维的书籍我知道的都有几本呀，谷歌的SRE、Netflix的混沌工程，还有DevOps的很多书籍 技术大会方面有GOPS等运维技术大会，有很多资料和演讲PPT都可以搜索到的。

    10
  • Hesher
    2021-03-23
    技术业务管理，6:3:1。 技术肯定是这个级别最重要的技能，但考虑到业务领域的复杂度，DDD的逐渐流行，有必要在团队内达成统一领域语言，对业务模型有比较深入的了解，这样才能完成领域建模以应对业务复杂度。任务拆解、工作量评估、code review、组织技术分享等等，就算在管理这项里面，不用花太多精力。
    展开

    作者回复: 正解

    8
  • Jason
    2020-12-21
    华哥，想问下公司的IT开发岗位员工的业绩用什么衡量？ 比如，销售岗位员工有销售额业绩，运营岗位有用户活跃度等，这些都可以作为他们工作业绩或者成果，这样的话他们有明确的目标，可以针对目标情况复盘总结哪里可以做的更好。 而我们开发岗位的人工作似乎主要是编码完成一个个需求功能，对应的工作业绩或者成果是啥呢？这个业绩我不太理解，导致回顾自己的工作时，难以像业务岗人员那样有明确的目标可以得知自己哪里做的好，哪里做的不好。华哥能帮忙解答下吗？
    展开

    作者回复: 1. 红线考核：例如出了P2级别以上的线上问题考评就是3.25 2. 质量考核：看看你的工作质量和效率，例如bug数、版本delay数 3. 群体智慧：有的团队会互相打分，或者主管找产品运营项目经理或者合作团队等配合团队的人来评分 4. 主管凭感觉：主要是各种会议、各种项目、各种事件处理过程中的表现 技术岗位无法量化，因此不能说100%公平公正，但整体上来说，如果按照上面的方式来评，八九不离十。

    共 2 条评论
    6
  • 圈圈gor
    2020-12-17
    我的想法是5技术3业务2管理 作为项目主力，技术能力占大头那是必然的，不过去到7的话会不会高了点？ 一方面，业务的掌握程度会影响方案的设计，再进一步影响交付质量。 另一方面，到了这个级别，如果能指导好p5以及管理好保证项目进度，带来的价值会不会更大一些？

    作者回复: 业务比例高了点，在P6这个级别，业务这部分主要还是理解业务，保证做的功能真正实现了业务需求。 能指导好P5并且能够保证项目进度，肯定会带来更大价值，为后面的晋升积累官人和管事的经验和能力

    4
  • 好奇分析
    2021-03-28
    从一个运营同学的日常事项来看，我感觉P6的分工是 技术：业务：管理 =4：4：2 。运营同学的工作比较杂，做的很多运营动作的出发点是要理解业务，通过管理手段达到目标。对技术的要求反而降低。因此，从运营岗位出发，我觉得业务和管理会更重一点，其中业务甚至达到3：5：2的程度

    作者回复: 点赞，能够结合岗位有自己的思考，我这个专栏整体上还是偏技术岗位的，如果你把技术改为“专业技能”，其实就可以应用到运营产品这些岗位。 运营和产品岗位，业务是专业要求，占比要比技术岗位高

    3
  • 花儿少年
    2020-12-23
    业务开发来说，技术很难体现啊

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

    共 2 条评论
    2
  • young
    2020-12-14
    技术、业务、管理划分的话差不多就是442吧。这个阶段的工程师核心还是努力提升自己的技术深度和对业务的理解程度上。技术深度决定了业务代码的实现质量，业务理解程度决定了你对当前项目的全面掌握情况，理解越深关键时刻越能提出建设性意见和建议被团队认可。这个阶段的管理要求相对不高，能做好自我管理即可。

    作者回复: 你这个比例有点失调，技术占比少了点 ：）

    2
  • 收腹，你咋有肚子
    2021-08-29
    我对6的理解，不知道对不对： []要有一定的前瞻性，能判断短期内所负责的业务走向 []对业务中的技术要有一定的深入，能整合技术服务业务 []同时要有一定的技术广度，特殊情况下要能找到好的技术替代方案或者新的技术方案 []学会需求拆分，将需求才分为小的需求模块 []能主动推动业务需求，能与其他业务组合作开发，并能督促进度 []学会做好mentor,能指导p5工作
    展开

    作者回复: 第1条和第3条要求不高，其它分解挺好的

    1
  • 孔小明先森
    2021-04-11
    如果能说设计职能就更好了。不过整体来说还是相近的

    作者回复: 领域和岗位太多了，没法一一列举 ，很多岗位我也不懂，你可以对照这个标准，基本能平移过去

    1
  • iCoder
    2021-03-16
    请问老师，p6升p7，考察的更多的是您说的p6独当一面的能力，还是更多的是p7对业务对技术选型对管理的能力？或者自己做晋升，应该着重介绍p6的能力，还是您讲的p7的那些能力，毕竟方向是不太一样的

    作者回复: 你可以回去再看看04 晋升逻辑部分的内容，第一条晋升逻辑：在当前级别做下一级别事情的人，才有机会晋升。 p6升p7，肯定是按照P7的要去来考察。

    共 2 条评论
    1
  • Monday
    2021-01-11
    P6：技术>业务>管理。第一个想法是532

    作者回复: 技术占比少了些

    1
  • Geek_36192e
    2021-01-09
    5W1H8C1D分析法在哪里，怎么没有找到？

    作者回复: 后面会讲

    1
  • 周平
    2020-12-14
    好熟悉的工作内容和工作方法啊，原来这就是T6的主要工作，我曾经做这些工作好长时间。 回想做这些工作的时期，我也存在一些问题，比如领导challenge我排期，我会退让一步，最后大部分是自己加班搞起。 在面对产品，运营的需求，在他们描述完对上线后，我也产生了这些产出，这些收益的渴望，我也挺愿意早日上线的。一般，我会主动做出让步，这却使自己陷入长期，频繁的加班之中。 当然，也做了很多事。和上下游各部门合作也愉快。 加班不算什么，重要的是要把时间花在了更重要的地方，使自己成长更快。 而努力的方向不对，则可能成为一个熟练，好用的工具人，一直不得成长。 我的几个导师，都是再升一级做管理去了。我却还想沉下心来搞技术，做到50多岁还写码那种。不知道那个级别的技术高工，工作内容都是什么样子的啊。 好想突破一下。
    展开

    作者回复: 管理和技术不冲突，尤其是你能够带着团队来做技术，那种感觉更爽，毕竟一个人的力量始终有限，发挥团队的力量才能干大事。 后面P7、P8会教你如何平衡技术和管理

    共 3 条评论
    1
  • 怀揣梦想的学渣
    2022-06-22
    工时预估也得看参与者能力，如果有人带外包做事，可以加速完成任务，如果有人个人能力超出预期，也会提前完成，但就怕带的外包集体翻车，疫情原因突然少很多人，或者能力强的那位突然离职跑路了。

    作者回复: 一般是通过加buff来控制，比如说外包多就加40%的预留空间，如果没有外包都是熟手，一般加20%预留空间就够了

  • melon残剑
    2021-10-30
    技术7 业务2 管理1，我觉得更多的应该是倾斜在技术和业务上面，管理工作的占比相对较小

    作者回复: 可以