mod

极客时间专栏/大厂晋升指南/职级详解/07 | P5提升攻略：怎么快速从学生转变为“打工人”？.md

@@ -0,0 +1,194 @@
+<audio id="audio" title="07 | P5提升攻略：怎么快速从学生转变为“打工人”？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/22/cc/22f06f863a0625a6cf7b88f004f050cc.mp3"></audio>
+
+你好，我是华仔。
+
+从这一讲开始，我们进入到课程的第二部分，职级详解。
+
+## 职级详解导学
+
+在这个部分，我会基于COMD能力模型，从技术、业务、管理三个维度和规模、时间、环境、创新四种复杂度出发，为你详细解读P5～P9每一个级别的能力要求。同时，我也会结合过往带团队、指导他人和担任评委的经验，给出每个级别的提升建议。
+
+我想强调的是，这里的职级解读和提升技巧绝对不是只针对阿里的职级，而是通用的。不管你是在BAT，还是在TMD，不管你是在互联网大厂，还是在其他公司，都可以参考。你只要把自己当前的职级对标到这门课程定义的级别（P5～P9），然后学习相应的内容就行了。
+
+具体怎么对标呢？你可以参考[第6讲](https://time.geekbang.org/column/article/317813)和[《晋升等级：不同的职级体系如何对标》](https://time.geekbang.org/column/article/318457)这篇加餐。
+
+另外，我还想提醒一点：你的学习重点肯定是自己当前级别和下一级别的内容（比如P5的同学需要重点学习介绍P5和P6的内容），但并不意味着其它级别的内容你就可以直接跳过。
+
+比如你现在是P7，虽然已经顺利越过了P5和P6，但你对这两个级别的理解不一定完全准确，也不一定全面。而你很可能要指导这两个级别的同事、面试这两个级别的应聘者，或者作为Team Leader带这两个级别的下属。所以，认真学习P5和P6的内容，对你同样会有很大的帮助。
+
+换一个角度想，如果你现在是P6，看起来P8和P9好像离你还很遥远，这两个级别的内容你还要不要学呢？我还是建议你了解一下比较好，因为这样可以让你对自己的长远目标有一个大概的认知，有助于你做职业发展规划和晋升路线规划。
+
+<img src="https://static001.geekbang.org/resource/image/01/1e/01c4ba43b2cccef760fd53d80049b41e.jpg" alt="">
+
+## P5：从学生到“打工人”
+
+我们先来看看P5级别。P5对应的工作年限大概是0～3年，本科毕业生的定级一般就是P5，优秀的毕业生会定到P5+，目前进BAT的应届生绝大部分都是P5+。
+
+大部分P5工作2年以后可以晋升P6（无论是内部晋升还是跳槽定级）。如果你工作3年了还没法晋升P6，可能需要考虑一下是否适合当前岗位了，或者反思一下自己有哪些地方做得不好。
+
+P5的核心能力是**在别人的指导下完成任务**，这句话有两个重点：
+
+- **在别人的指导下**：通常是P6或者P7来带P5。
+- **任务**：项目各个阶段的各项活动。以开发为例，任务包括需求评审、方案设计、编码、修改Bug和上线等。
+
+听起来好像要求不高，但这并不意味着你一毕业就自动具备了P5的能力。因为在学校读书跟在公司工作还是有很大区别的，主要体现在以下三个方面：
+
+1. **技术差异**
+
+大学学的技术偏重理论，而工作岗位对深度和实践的要求更高。而且就算你是研究生，你的研究方向和公司岗位的要求也很难完全匹配，更不用说前端、Android、iOS、测试、运维、DBA等各种不同岗位的技能差异了。
+
+1. **业务差异**
+
+大学教育不会针对某个公司的具体业务进行教学，而互联网行业的业务领域多、发展快，近几年比较火的领域有电商、支付、社交、本地生活和出行等。这些业务知识是完成工作的基础，但你在刚毕业的时候，往往没有这方面的积累。
+
+1. **管理差异**
+
+大学学习的管理课程比较理论化，但公司的规章制度和项目流程有很多细化和具体的要求。怎么熟悉和适应工作岗位的管理要求，怎么跟别人协作，怎么推动事情落地，这些也都是完成工作的基础，但刚毕业的大学生往往处理得还不够好。
+
+正是因为校园和职场环境差别这么大，所以P5级别的主要目标就是完成“学生”向“打工人”的角色转换。怎么实现这一层蜕变，是P5首先要考虑的事情。
+
+接下来，我就分技术、业务和管理三个维度一一展开。
+
+## 技术：重点积累基础技术
+
+首先是技术维度。P5是你职业生涯的起步阶段，也是打基础的关键时期。虽然你的技术水平还不高，但是这时候的学习效果最好，技术提升也是最快的。
+
+因为跟学校的单向学习不同，你能把刚学到的东西马上实践应用在具体工作中，能够达到“知行合一”的效果；同时，P5承担的责任不大，等你晋升到更高级别之后，就没有这么多精力和时间用来学习了。
+
+P5的技术要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/74/b6/74973a0c2ce984e578a757528f49d1b6.jpg" alt="">
+
+P5阶段要怎么提升技术呢？最重要的就是**基础技术的积累**。
+
+这里的基础技术不是指大学课程中的基础知识，而是指工作岗位中实际用到的技术，不同的岗位要求不同。
+
+比如，Java业务开发的基础技术包括Java编程语言、MySQL数据库、计算机网络、HTTP协议和Linux操作系统基础知识等，而iOS业务开发的基础知识，就包括Swift/Objective-C编程语言、iOS操作系统基础知识、Xcode、SQLite、计算机网络和HTTP协议等。
+
+虽然它们有一部分相同，但总体来看差异还是比较大的，所以你也要根据自己的岗位有针对性地学习。
+
+### 两个误区：错误理解“基础”与碎片化学习
+
+在P5阶段提升技术时，很容易陷入2个误区。
+
+第1个常见的误区是**错误地理解了“基础”的意思**。
+
+我在[第3讲](https://time.geekbang.org/column/article/314649)介绍价值原则的时候提到过，很多人为了提升自己的基础能力，跑去学编译原理和Linux内核源码分析，或者去背一些算法源码。结果他们到头来发现，投入了大量的时间和精力，却没什么收获。
+
+所以你一定要记住，基础是和工作任务相关的基础，而不是整个计算机行业的基础。关于怎么学习基础技术，我会专门用一期加餐来系统地介绍。
+
+第2个常见的误区是**只通过搜索来进行碎片化学习**。
+
+工作中遇到一个问题或者一个技术点，就上网搜索几篇文章学习一下，很多人都是这么做的。
+
+碎片化学习虽然投入时间少，但是效果难以保证。首先，你不可能在工作中遇到某个技术相关的所有问题；其次，通过这种方式，你只知道一个个零散的技术点，而不知道这些技术点之间的关系。
+
+以HTTP缓存为例，如果只是单纯去搜索“HTTP Cache-Control”，你确实可以知道no-cache和no-store等名词的含义。但是整个HTTP Cache协议、浏览器的处理逻辑和服务器的处理机制这些技术点你就学不到了，而它们在分析HTTP性能相关的问题或者优化Web页面的时候都是必须掌握的。
+
+可能你会觉得碎片化学习是没有办法的事情，因为工作以后就不像在学校那样，有整段的学习时间。
+
+虽然客观条件是这样，但碎片化时间并不意味着只能碎片化学习，正确的做法是**“碎片化时间，系统化学习”。**也就是说，每天都抽出一小段时间有计划地学习某项技术，哪怕每天10分钟都可以，但总体的学习内容是系统化的。
+
+想让学习系统化，最简单的办法就是**对照一本经典的书籍循序渐进地学习**。
+
+虽然你不能把所有的内容都一次性学懂，但至少在学完一遍后，可以对一项技术的完整体系建立整体印象。这样，你后续再深入学习这项技术的时候，效率也会更高。
+
+除了书籍之外，**学习技术类线上课程**也是一种很不错的方式。
+
+线上课程的作者都是在某个领域积累了丰富经验的专家，而且讲解的内容跟实际工作关系紧密，再加上这些作者往往会有自己独到的理解，你学习起来会更有趣，也更有效率。
+
+同时，线上课程往往还配有音频，比书籍更适合上下班通勤的时候学习，让你更高效地利用碎片时间。
+
+## 业务：熟悉业务的处理逻辑
+
+第二个维度是业务。P5对业务的要求主要是熟悉**各项业务的处理逻辑**。
+
+### 广义的业务：提供的功能和服务
+
+什么是业务呢？我需要在这里专门说明一下。
+
+一般情况下，我们听到“业务”这个词的时候，都会理解为“某个行业的相关服务”，比如电商业务、支付业务、社交业务、游戏业务，其实这些都是“狭义”上的业务。
+
+我在这门课程中，按照COMD能力模型拆解级别要求的时候，对“业务”的定义要更宽泛一些，是“广义”上的业务。你可以把它理解为“**你负责的系统或产品为目标对象提供的功能和服务**”。
+
+具体到不同岗位，是这样的：
+
+1. 如果你负责2C或2B的业务系统开发测试，那么业务范围就是**我们通常理解的业务**。
+1. 如果你负责内部IT系统的开发测试，那么业务范围就是**公司内部的各种规章制度和工作流程**。
+1. 如果你负责中间件或平台的开发测试，那么业务范围主要是**中间件或平台的相关功能和服务**。换句话说，你不需要深入理解每个使用你的系统的2C/2B业务（可以适当了解），而要把精力放在熟悉中间件和平台本身提供的功能和服务上。
+1. 如果你是运维或DBA之类的岗位，那么业务范围就是**运维体系相关功能和服务**。换句话说，你不需要深入理解每个你负责维护的业务（可以适当了解），而要把精力放在熟悉运维体系提供的功能和服务上。
+
+### 处理逻辑：实现功能和服务的步骤
+
+那么，什么是业务的处理逻辑呢？它是指实现这项业务提供的功能和服务所需要的步骤。直白点说，就是第一步要做什么，第二步要做什么，依此类推，一直到最后一步做什么。
+
+以微信朋友圈为例，发图片动态的处理逻辑如下：
+
+```
+进入“朋友圈”
+点击右上角的照相机图标，App弹出选择框
+选择“从相册选择”，App展示图片列表
+点击需要发布的图片，最多选择9张
+选择完成后，点击右上角“完成”按钮，App进入“发表”界面
+输入“这一刻的想法”
+点击“所在位置”选择具体的位置
+点击“提醒谁看”选择需要提醒的人员
+点击“谁可以看”选择可见人群
+点击“发布”按钮发布图片动态，App返回朋友圈
+朋友圈展示刚才发的图片动态
+
+```
+
+当然，这只是一个简化后的例子，用来说明这个概念而已。所以，我只描述了整体步骤，你可以自行对照微信朋友圈的功能进行细化。
+
+在实际工作中，处理逻辑越细化越好。比如这个例子中的第9步，点击“谁可以看”，它就具体包括公开、私密、部分可见和不给谁看4个选项，每个选项的含义你都需要详细了解。
+
+P5的业务要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/0b/7d/0b651ace29dcd68c52a56d11699a447d.jpg" alt="">
+
+怎么才能更有效地快速熟悉自己负责的业务功能呢？
+
+对于2C的业务来说，熟悉业务最有效的方法就是**让自己成为产品的深度用户**。
+
+有些技术人员连自己负责的产品都不用，只是机械地按照项目的要求完成任务（例如开发、测试、部署这些任务）。功能上线后，他们既不亲自体验，也不关心用户的反馈。这样做的后果是，连基本的业务现状都很难清晰地了解，更别谈提升业务水平了。
+
+所以，如果你对现在做的业务真的一点兴趣都没有的话，我建议你尽早换一个自己感兴趣的业务，这样更有利于职业发展和晋升。
+
+对于2B的业务来说，熟悉业务最有效的方法可能就是**多跟客户交流**。
+
+你不妨多去跑去客户那里，看看客户实际的使用环境和使用流程，听听客户的真实的需求、痛点和想法。
+
+说到这，你可能担心P5级别不一定有这样的机会。其实，很多公司都鼓励技术人员出去跟客户交流。P5虽然不能独立承担这个任务，但是一般情况下，跟着P6和P7一起去是没有问题的。如果有可能，尽量每个季度都出去见一次客户，这能够大大提升你对业务的理解。
+
+比如我在菊花厂的时候，负责核心网的网管系统设计和开发。公司每年都会给我们安排几次机会去移动、电信和联通的机房里面看看设备，观察他们的维护人员使用我们系统的情况，以及听听他们对我们系统的评价和吐槽。
+
+## 管理：了解公司的管理制度和项目流程
+
+最后是管理维度。P5对管理的要求主要是了解公司的管理制度和项目流程，知道自己在项目流程中的职责和任务，熟悉上下游的依赖以及如何推进项目。
+
+P5的管理要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/a6/8f/a6996737cbce098020f97b739053f08f.jpg" alt="">
+
+如果你是计算机科班出身，应该学过《软件工程》这门课。其实这门课已经涵盖了软件项目管理的内容，比如现在常见的“瀑布开发流程”和“敏捷开发流程”。
+
+但是不同的公司和团队，还会有很多详细规章制度，可能是公司统一规定，也可能是团队历史经验教训的积累。其中有些规则还是“红线规则”，一旦违反就会受到通报处分之类的惩罚。
+
+对于刚入职场的P5来说，虽然承担的职责并不重，但很容易因为不熟悉这些规章制度而犯错。所以你还需要特别注意团队规章制度的学习，不要一不小心就踩了坑。
+
+## 小结
+
+这一讲我基于COMD能力模型，给你详细解读了P5级别的具体要求。现在，我们回顾一下重点内容：
+
+1. P5的核心能力要求是在别人的指导下完成任务，主要提升目标是从学生转变为“打工人”。
+1. 技术方面，P5需要打好基础，学习岗位要求的基础技术。采用“碎片化时间，系统化学习”的方法提高你的技术学习效率。
+1. 业务方面，P5需要熟悉各项业务功能的实现逻辑。对于2C业务，你要成为产品的深度用户；对于2B业务，你就要多跟客户交流。
+<li>管理方面，P5的重点是熟悉项目流程，避免踩坑。你需要注意学习公司的管理制度。<br>
+<img src="https://static001.geekbang.org/resource/image/23/cb/23c0be2ed081295c4025e9a02bba15cb.jpg" alt=""></li>
+
+## 思考题
+
+这就是今天的全部内容，留一道课后思考题给你吧。
+
+你在P5这个级别上停留过或者已经停留了多长时间？如果时间很短，你的技巧是什么；如果时间比较长，你觉得问题在哪里？
+
+欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。<br>
+<img src="https://static001.geekbang.org/resource/image/a6/96/a6005bf0095fc325e4acbed7d22bec96.jpeg" alt="">

极客时间专栏/大厂晋升指南/职级详解/08 | P6提升攻略：怎么成为独立自主的“项目能手”？.md

@@ -0,0 +1,120 @@
+<audio id="audio" title="08 | P6提升攻略：怎么成为独立自主的“项目能手”？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/59/5c/5916c28b07bc80238b188cd50dfa6a5c.mp3"></audio>
+
+你好，我是华仔。
+
+上一讲我们学到了，P5的核心能力要求是**在别人的指导下完成任务**。如果能够从P5晋升到P6，就说明你已经完成了从学生到打工人的角色转变，成长为一名合格的员工了。这一讲我们就来了解一下P6的能力要求和提升建议。
+
+P6对应的工作年限是2～5年，核心能力要求可以用一句话来概括，**独立负责端到端的任务**。这句话有两个关键词：
+
+<li>
+**独立**：P6做的事情跟P5差不多，但已经不需要别人带着做了。P5和P6的开发人员都会参加需求评审，只不过P5参加的时候只是在听，而P6可能就会针对需求直接提出意见。
+</li>
+<li>
+**端到端**：负责项目中的某部分功能的全流程相关事项。开发的端到端事项包括需求评审、方案设计、编码、修改bug和上线等；测试的端到端事项包括需求评审、测试方案设计、执行测试和上线等；而产品的端到端事项则包括用户分析、需求写作、数据分析和竞品分析等。
+</li>
+
+P6和P7是业界主要的劳动力，这两个级别的人数加起来，估计能够占到团队总人数的60%～80%。P6级别的主要提升目标是成为独立自主的项目能手。接下来，我就从技术、业务和管理三个维度一一展开进行讲解。<br>
+<img src="https://static001.geekbang.org/resource/image/05/1d/050d31ef60697972ea06a5f8ed73031d.jpg" alt="">
+
+## 技术：掌握团队用到的技术“套路”
+
+P6在技术方面的核心要求是**熟练掌握端到端的工作流技术**，因为P6是项目主力劳动力，需要参与项目流程中的某些阶段，完成分配的任务。
+
+P6级别的技术详细要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/fc/02/fc9160abecdc9c26b730d3aa2bbe5b02.jpg" alt="">
+
+在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级别的业务能力要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/22/e7/2290b770eb4292c3ceb1dc0c0ac680e7.jpg" alt="">
+
+P6级别提升业务能力的核心方法是我自创的**“5W1H8C1D”分析法**。传统的“5W1H”分析法只关注需求的功能属性，所以我在“5W1H”基础上，又增加了对需求的质量属性（8C）和上线后效果（1D）的考虑。
+
+这个方法不是一两句话能够讲清楚的，我会在课程的**专项提升**部分专门用1讲的篇幅为你详细介绍。
+
+除了这个方法之外，认真做好**竞品分析**也很重要。通过对比竞品和自己的产品类似功能的差异、优劣，你能够更好地理解业务。
+
+## 管理：推进项目中的子任务
+
+P6管理能力的要求主要是能够**负责项目中的子任务推进。**
+
+具体的管理要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/52/b6/52fb8ed841cayy1efd42d41c375238b6.jpg" alt="">
+
+### 工作量评估：WBS分解法
+
+P6的管理职责包括任务的工作量评估、计划制定以及分配和跟踪等。其中工作量评估是P6的核心职责，而计划制定以及分配和跟踪，主要是配合项目经理来完成的。而且，工作量评估的准确性是第一步，会直接影响到后续工作的合理性。
+
+所以，掌握工作量评估的有效方法，也是P6在管理方面的核心能力。
+
+很多人在评估工作量的时候没有依据，所以心里比较虚，如果项目经理或者产品经理稍微挑战一下，就会很容易退让，导致工作量被压缩。到了实际项目执行的时候，他们发现工作量评估偏少了，为了赶上项目进度，就只能加班加点。
+
+我在职业生涯中遇到过四种评估方法：
+
+1. **拍脑袋法**：让团队有经验的人直接拍脑袋想一个工作量数字。
+1. **扑克牌法**：找3～5个人员，每人给一张小纸条，每个人把工作量评估写在纸条上，最后取平均值。
+1. **对比法**：参考曾经做过的类似的项目，看看之前的项目工作量是多少，然后以此为基础想一个数字。
+1. **WBS分解法**：把需求拆解为多项小任务，单独评估每个小任务的工作量，然后汇总；评估小任务的工作量的时候可能采取上面这3种方法。
+
+从实践经验来看，WBS分解法的效果是最好的，评估的误差基本上不会超过20%。
+
+WBS的全称是Work Breakdown Structure，中文翻译是“工作分解结构”。WBS分解法的原理是，通过把项目工作按**阶段可交付成果**分解成更小的、更易于管理的组成部分，来提升项目管理的效率。
+
+我们以朋友圈点赞为例，开发人员采用WBS分解方法，可以得到下面这个任务分解表格：
+
+<img src="https://static001.geekbang.org/resource/image/71/2a/71fa7dec065718a574c04788bayy7d2a.jpg" alt=""><img src="https://static001.geekbang.org/resource/image/2d/a8/2d347f7d1cde0527b61af684f1771ba8.jpg" alt="">
+
+对于分解出来的子任务项，我们就可以用“拍脑袋法”评估工作量了。这样做能够兼顾效率和效果，因为子任务项已经比较小，基本上你凭经验就能够得到比较合理的结果。就算单个任务项有偏差，也是有的偏多有的偏少，最终的偏差反而会互相抵消。
+
+### 避免过于乐观：加Buffer
+
+大部分人在评估工作量的时候都会比较乐观，而且在项目过程中可能有各种意外出现（比如某个开发或者测试人员生病）。在实践中，为了避免过于乐观的评估给后面的项目进度带来风险，我们往往会采取加Buffer（缓冲）的做法，也就是说，将评估的初步结果乘以一个大于1的系数来作为项目的工作量。
+
+还是拿朋友圈点赞功能来说明，如果初步评估的工作量是14人天，Buffer系数取1.2，那么最终做项目计划时，参考工作量就是17人天（14*1.2 = 16.8 ≈ 17）。
+
+这个Buffer系数可以在1.2～1.6之间浮动，一般根据项目的复杂度决定。全新的业务功能Buffer会高一些，在已有业务功能上修改时Buffer会低一些。
+
+## 小结
+
+这一讲我基于COMD能力模型，给你详细解读了P6级别的具体要求以及对应的提升技巧。现在，我们回顾一下这一讲的重点：
+
+1. P6的核心能力要求是独立负责端到端的项目任务，主要提升目标是成为独立自主的“项目能手”。
+1. 技术方面，P6需要掌握团队用到的各种技术的“套路”，重点提升技术深度，学习时要避免贪多求全的心态，优先深入学习跟工作内容强相关的技术。
+1. 业务方面，P6需要掌握某类业务相关的所有功能，并深度理解处理逻辑，主要的提升方法是“5W1H8C1D”分析法和竞品分析。
+1. 管理方面，P6需要负责项目子任务推进，包括工作量评估、计划制定和沟通协调等。评估工作量的时候，建议使用WBS分解法，先拆解成容易评估的小任务，然后独立评估每项任务，最后汇总。
+
+<img src="https://static001.geekbang.org/resource/image/61/dc/6125c35396c1f8742b4bedb6a7ddd2dc.jpg" alt="">
+
+## 思考题
+
+这就是今天的全部内容，留一道课后思考题给你吧。P6的能力要求已经比较全面地覆盖了技术、业务和管理三个维度。假如你是晋升评委，你会怎么分配这三个维度在职级能力中的占比呢，理由是什么？
+
+欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
+
+<img src="https://static001.geekbang.org/resource/image/34/2f/34151e4ae91f1fcce05d781936a3162f.jpeg" alt="">

极客时间专栏/大厂晋升指南/职级详解/09 | P7提升攻略：怎么成为让人信服的“团队专家”？.md

@@ -0,0 +1,208 @@
+<audio id="audio" title="09 |  P7提升攻略：怎么成为让人信服的“团队专家”？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/cc/15/cc52a7a83c02a148b3cd8e57e599d815.mp3"></audio>
+
+你好，我是华仔。
+
+上一讲我们学到了，P6的核心能力要求是独立负责端到端的任务。晋升到P7，就说明你在技术上已经小有所成。
+
+但是P7是一个比较尴尬的级别，业界流传一种说法，P7相当于王者荣耀的“永恒钻石”段位。也就是说，P7是很多人职业发展的天花板，这个级别很难再往上晋升。
+
+那么，P7的能力要求是什么，如果还想继续晋升，应该怎么提升自己呢？这一讲我们就来了解一下。
+
+P7是一线团队的核心，对应的工作年限是4～8年，核心能力要求用一句话概括就是，**指挥单个团队达成目标**。这句话有两个关键词：
+
+**1. 团队**
+
+P7和P6一样都是业界核心劳动力，人数众多。但管理岗位是有限的，结果自然“僧多粥少”。
+
+所以P7可以分为两种。一种是担任Team Leader的P7，一般带3～10人的专业团队，也就是组织结构概念上的团队，核心职责是团队管理。
+
+另一种是作为团队骨干的P7，他们虽然不是Team Leader，但是一般也会负责某个项目或者专项小组（比如Android性能优化小组和前端效能提升小组），带3～5人的虚拟团队。他们不承担团队管理职责，只关注小组目标的实现。<br>
+<img src="https://static001.geekbang.org/resource/image/46/6c/464c35328f8e3f80f459cc41f31af46c.jpg" alt="">
+
+**2. 目标**
+
+担任Team Leader的P7主要是带领团队实现**业务目标**，担任虚拟团队负责人的P7主要是实现小组的**专项目标**。
+
+总的来说，P7的主要提升目标是**成为让人信服的团队专家**。接下来，我就从技术、业务和管理三个维度一一展开讲解。<br>
+<img src="https://static001.geekbang.org/resource/image/e5/b8/e5d46c8c76ef097c39fedecc1c2971b8.jpg" alt="">
+
+## 技术：精通团队相关技术
+
+P7在技术维度上的核心要求是**精通团队相关技术**。
+
+怎么理解呢？一方面，P7要指导团队内的P5和P6，甚至还有其他P7，所以首先自己要精通团队**已经用到的**技术；另一方面，P7已经开始负责团队的技术规划，需要在合适的时机引入新的技术，所以也要熟悉团队**可能用到的**技术。这就是我把P7称为“团队专家”的原因。
+
+P7级别的技术详细要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/68/a6/68f9411577c37a4073f33fe38bb7d9a6.jpg" alt="">
+
+需要注意的是，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框架怎么选。
+
+提升技术深度适合用**链式学习法**，纵向贯穿，自顶向下，挖深挖透；提升技术宽度适合用**比较学习法**，横向拉通，比较差异，分析优劣。这两种方法，我会在**学习方法**部分为你详细介绍。
+
+大公司的业务已经具备了一定的规模，团队也有足够的人力，为了保持高速增长，往往乐于尝试新技术。
+
+所以如果你身处大公司，在提升了技术宽度之后，就有机会使用一条晋升秘诀（或者说潜规则），那就是**多考虑引入新技术**。一方面，新技术在一般情况下确实能够给业务带来更好的结果；另一方面，懂新技术的人不多，早入坑就有先发优势，很容易被认为是专家。
+
+### 拒绝生搬硬套
+
+但是这个秘诀不能乱用。虽然引入新技术能帮助你更快地晋升（尤其是在大厂），但是“多”不等于“盲目”，如果**生搬硬套，**会带来很大的风险。
+
+表面上看起来，你做了很多技术创新。但如果没有认真分析业务和团队当前的需要，没有因地制宜地调整适配，套用过来的技术就发挥不出预期的效果。
+
+具体来说，有两种十分常见的错误做法。第一种是**直接拷贝大厂的技术**。
+
+这种做法在中小公司比较常见。很多人想当然地认为，大厂选择的技术就是好技术，毕竟连月活几亿的业务都在用，解决自己的业务问题还不是绰绰有余。而且因为有大厂背书，在说服上级的时候也比较容易。
+
+可是等到真正落地的时候，你可能就傻眼了，怎么橘生淮南则为橘，生于淮北则为枳呢？
+
+道理很简单，牛刀虽好，杀鸡却不方便。比较典型的就是近两年流行的“中台”这个概念，很多公司对中台背后复杂的驱动因素和依赖条件都没搞清楚，就照猫画虎地要上中台，要把技术架构“中台化”。
+
+结果怎么样呢？不但没能一口吃成胖子，反而消化不良了。你可以读一读[《中台，我信了你的邪》](https://36kr.com/p/1725013082113)等文章，看看业内人士是怎么吐槽的。
+
+第二种常见错误是**盲目追求新技术**。
+
+这种做法在大厂比较常见。很多人对新技术有一种偏爱，认为新的就是好的。但其实任何技术都遵循“**没有银弹**”的理念，没有一劳永逸又包治百病的神药。新技术也会带来新的复杂度，也会有自己的场景限制，也需要考虑成本问题。
+
+比较典型的就是Docker容器化技术，它的核心目的是降低部署成本和提高资源利用率，业务规模越大，效果越明显。但是引入Docker的成本可不小，因为涉及开发、测试和运维等全流程的基础技术迁移，所以在业务没有达到一定规模的时候，很可能得不偿失。
+
+另外，新技术刚出来的时候其实是不成熟的，后续的变化可能很大。如果用得太早，团队就要一直投入大量的人力来跟进技术的发展。
+
+同样以Docker为例，容器化技术在经历了Swarm、Mesos和Kubernetes三国争霸之后，才逐渐走向Kubernetes一统天下的局面。如果你在三国争霸的时候就做了容器化，又恰好没有选Kubernetes，那么之后再换成Kubernetes，需要投入的成本可不小。
+
+所以，无论是在大厂还是中小公司，引入新技术的时候都要求能够想清楚对业务和团队带来的价值，而不是仅仅因为“新”就引入，评委在考察的时候，会特别关注引入新技术背后的逻辑是否合理。
+
+## 业务：关注业务整体
+
+在业务维度，P6更关注业务细节，而P7更关注业务整体。这里的业务范围是**自己团队负责**的业务。
+
+在下面这张示意图中，我对B2C电商领域的业务做了一个简单的总结。可以看到，P7的业务范围是“收藏子系统”“用户子系统”和“活动子系统”这个级别的。
+
+<img src="https://static001.geekbang.org/resource/image/25/76/256f46afaff6edb59ba7b1bf4ee47f76.jpg" alt="">
+
+P7级别对业务的详细要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/28/79/28e3d1f667ab22d373f6ffc8598e8379.jpg" alt="">
+
+### 从4个方面提升业务理解力
+
+从表格中可以看出，跟P6比起来，P7对业务理解的要求又上升了一个档次。很多人问过我一个问题：“怎么提升业务理解能力？”我在这里跟你分享一个适合在P7阶段使用的基础方法论。
+
+想要理解业务，你可以从4个方面出发，分别是用户特征、用户价值、获客方式和获利方式。
+
+**用户特征**回答的问题是，**我们的用户是谁**，换句话说，我们的用户属于哪一类人群。要怎么分类呢？常见的方法有两种，第一种是按照属性来划分，比如学历、收入、年龄和地域等；第二种是按照场景来划分，比如网购、K歌、旅游、外卖和游戏等。
+
+**用户价值**回答的问题是，**用户为什么要用我们的产品**，换句话说，我们产品的好处体现在哪里。它可以体现在能满足用户的某些需求，也体现在跟其他产品比起来有竞争优势。比如电商三巨头淘宝、京东和拼多多，淘宝大而全，京东物流快，拼多多价格便宜。
+
+**获客方式**回答的问题是，**怎么让用户来用我们的产品**。用户并不会无缘无故就自动找上门来，我们必须通过宣传把他们给招揽过来。以2C业务为例，常见的获客方式有品牌广告、社交推荐、事件营销、SEO、线下地推和红包返利等。
+
+**获利方式**回答的问题是，**我们怎么赚钱**。毕竟公司是以赚钱为第一要务的，就算现在不赚钱，也是为了将来能赚更多的钱。常见的获利方式有广告费、会员会费、增值服务、服务费和销售产品等。
+
+从这4个方面进行拆解，P7级别对业务的理解至少要达到以下4点要求，并且要能够量化到具体的数据：
+
+1. 知道行业总的用户规模，自己的业务总的用户量，用户的特征分布。
+1. 熟悉行业的竞品，包括行业的排名、竞品的数据以及竞品间的差异和对比。
+1. 熟悉常见的获客手段和效果指标（ROI、转换率和留存率等），知道对自己的业务来说效果最好的3～5个获客手段以及原因。
+1. 熟悉常见的获利手段和效果指标（数值和比例等），知道对自己的业务来说最核心的3～5个获利来源。如果负责的是用户子系统这种不直接产生收入的业务，则可以了解自己的业务对收入会有什么影响。
+
+不管你负责的是业务2C还是2B，这个方法论都是有效的。
+
+它如果应用在2C业务中，就是有名的**AARRR漏斗模型**。你可以对用户生命周期中每个环节的行为和数据进行分析，来提升自己的业务理解能力。我会在后续的**专项提升**部分教你怎么理解和使用这个模型。
+
+如果你从事的是2B业务，也可以参考AARRR漏斗模型的思路。但是具体的手段和措施是跟行业强相关的，不能照搬2C业务。你可以多跟团队有经验的前辈了解，也可以多跟售前和技术支持等人员请教。
+
+## 管理：指挥10人以内的小团队
+
+P7和P6最本质的区别体现在管理维度上。从P7开始，你就需要指挥团队了，所以管理能力的重要性大大上升。公司对你的要求不再只是完成自己的任务，而是还需要你带领团队一起把事情做好。
+
+P7级别对管理的详细要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/cc/3f/ccff195d78a5cd3dd9ae30dbabf0823f.jpg" alt="">
+
+### 管理要避免走极端
+
+指挥团队确实是一个发展机遇，尤其是对于担任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级别的具体要求以及对应的提升技巧。现在，我们回顾一下这一讲的重点：
+
+1. P7的核心能力要求是指挥单个团队达成目标，主要提升目标是成为让人信服的团队专家。
+1. 技术维度上，P7需要精通团队相关的技术，重点提升技术宽度，主要提升方法是“比较学习法”。在这个阶段，你既要避免因为管理而丢掉技术，也要避免“生搬硬套”新技术。
+1. 业务维度上，P7需要掌握业务整体情况，从用户特征、用户价值、获客方式和获利方式4个方面理解业务6～12个月的规划。对于2C业务，AARRR漏斗模型是必须掌握的；对于2B业务，还应该了解行业强相关的手段和措施。
+<li>管理维度上，P7需要负责指挥单个团队。对于担任Team Leader的P7来说，需要系统化地掌握管理的基本技能，避免事必躬亲或者做甩手掌柜；对于不是Team Leader的P7来说，要学会做一个靠谱的项目负责人。<br>
+<img src="https://static001.geekbang.org/resource/image/66/b1/665669704765b1fcyy16bb1b86dd82b1.jpg" alt=""></li>
+
+## 思考题
+
+这就是今天的全部内容，最后留一道课后思考题给你吧。虽然说P7是“永恒钻石”，晋升到P8很难，但实际上从P6晋升到P7也是一项很大的挑战，很多人经历过3次以上失败才晋升成功。你觉得最主要的原因可能是什么？
+
+欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。<br>
+<img src="https://static001.geekbang.org/resource/image/40/3d/409c13a077aefdb0ab8097fa4132fd3d.jpeg" alt="">

极客时间专栏/大厂晋升指南/职级详解/10 | P8提升攻略：怎么成为有影响力的“领域专家”？.md

@@ -0,0 +1,199 @@
+<audio id="audio" title="10 | P8提升攻略：怎么成为有影响力的“领域专家”？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ef/12/eff5827c43cc36c821b9530ea5455612.mp3"></audio>
+
+你好，我是华仔。
+
+在[第6讲](https://time.geekbang.org/column/article/317813)中我曾经介绍过，P7/P8是同一档次的职级，核心能力都是指挥团队，区别只在于团队数量是一个还是多个（一般是2～5个）。
+
+但是在真实的职场环境中，P7级别就像“永恒钻石”段位，大部分人升到P7就很难再往上晋升了。为什么P7和P8的核心能力一样都是指挥团队，而P7升P8却这么难呢？指挥一个团队和指挥多个团队的区别到底体现在哪？
+
+## 从团队专家到领域专家
+
+我们还是先剖析一下P8的要求。P8对应的工作年限一般是8年以上，核心能力要求可以用一句话来概括，**指挥多个团队达成目标**。
+
+这些团队的构成不是随机的，而是跟业务发展阶段和团队规模大小有关，通常有两种构成模式。
+
+第一种是**横向模式**，指的是P8带领的团队的专业领域相同，横向支撑多个业务。
+
+这种模式常见于业务成熟期或者规模比较大的团队。比如某业务线所有Android开发人员都由1个P8带领，然后拆分为3个Android小组，每个小组支撑不同业务的App开发。团队结构示意图如下：
+
+<img src="https://static001.geekbang.org/resource/image/9e/2c/9ef5e4c647bec38e1bdca97dc7c3fe2c.jpg" alt="">
+
+第二种是**纵向模式**，指的是P8带领的团队的专业领域不同，端到端地纵向负责同一业务。
+
+这种模式常见于新业务初期或者规模不大的团队，很多BAT出身的P8到创业公司担任CTO或者技术总监时，就会采用这种模式带团队。比如1个P8负责带某业务的所有技术团队，包括客户端（含Android和iOS）、前端、后端、运维和测试等。团队结构示意图如下：
+
+<img src="https://static001.geekbang.org/resource/image/35/0c/35859b4e01b09df17a35965d73d3aa0c.jpg" alt="">
+
+现在，我们再对比一下P7和P8的核心能力要求就会发现，虽然看上去只是从“**单**个团队”到“**多**个团队”的一字之差，但是在影响力上却发生了本质的改变，主要体现为两点。
+
+第一，专业影响力范围从团队内提升到领域内。
+
+P7带单个团队，而P8是带单个领域的多个团队。如果P8带的是横向模式的团队，那么负责的就是单个专业领域；如果带的是纵向模式的团队，那么负责的就是单个业务领域。
+
+这就对P8的**技术水平**和**业务理解**提出了更高层次的要求。
+
+第二，组织影响力范围从单个团队提升到跨团队。
+
+P7只需要指挥自己团队内部的人就行了。但P8不同，虽然已经带了2～5个10人以内规模的团队，但是要想实现目标，光靠他们有时还不够，P8还需要指挥这些团队以外的人。比如有的项目涉及产品和运营配合，有的需要客户端、后台、运维一起协作。
+
+这在一方面对P8的**管理手段**提出了更高层次的要求，另一方面也把晋升**跟业务目标绑定**起来，增加了很多不确定和不可控的因素。
+
+总的来说，P8的主要提升目标是**成为有影响力的领域专家**。接下来，我就从技术、业务和管理三个维度一一展开讲解。<br>
+<img src="https://static001.geekbang.org/resource/image/31/05/31528b48db2265649cd2839b34be6705.jpg" alt="">
+
+## 技术：精通领域相关技术
+
+我们先看技术维度。
+
+P8级别是技术能力的顶峰。在P5～P8的晋升过程中，考察核心都是技术能力。业务能力和管理能力只是加分项，只要技术不行，业务能力和管理能力再好都很难晋升。（相比之下，从P9开始，对业务能力、管理能力和业界影响力等维度的考核比重会大大上升。就算你技术很厉害，只要业务能力和管理能力不行，同样很难晋升。）
+
+P8级别的技术详细要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/90/31/9010063f849021bed1db66b9a6231a31.jpg" alt="">
+
+### 技术深度+领域相关的技术宽度
+
+那么P8提升技术能力的关键是什么呢？答案是技术深度和技术宽度齐头并进。
+
+如果只有技术宽度，可能给人一种比较飘的感觉，成为“什么都知道，什么都不懂”的**PPT技术专家**；如果只有技术深度，技术视野太窄，就难以跟上业界技术的发展步伐，无法做出合理的技术判断、选择和规划。
+
+P7虽然也在技术深度的基础上增加了技术宽度的要求，但技术宽度的范围是和**团队相关**的，而P8的技术宽度范围是**领域相关**的，范围要大得多，你要学习和提升的东西也多得多。**这是P7很难晋升P8的第一个原因。**
+
+### 领域的划分和边界
+
+既然我们说P8是“领域专家”，那么这里的“领域”是怎么划分的呢？业界一般有两种方法：
+
+一是按照技术领域划分，比如Android开发、Java业务开发和大数据等。
+
+二是按照业务领域划分，比如推荐业务、广告系统和支付业务等。
+
+通俗地说，“领域专家”就是在自己负责的领域“什么都懂”。不过问题又来了，“领域”的边界要怎么定义呢？
+
+很多人把领域理解成“整个专业领域”，以为懂得越多越好。所以有的Android开发人员会去学习MySQL或者Redis，这样的做法在P8级别是不合适的，往往投入很大而收益却很少（P9反而要这样做，因为要拓展技术广度）。
+
+其实，要界定领域的边界，有一个很简单的方法，那就是画技能图谱。只要画出完整的技能图谱，领域的范围也就基本界定了。
+
+我在下面放了一张前端领域的技能图谱，供你参考。
+
+<img src="https://static001.geekbang.org/resource/image/1d/a0/1d2abfc04ce9f1b6b06925d07179dfa0.png" alt="">
+
+我们可以看到，领域的范围确实很大。想成为领域专家，需要提升的东西可不少。
+
+很多人在晋升P8的时候都遇到这样一个场景：某位评委问了你专业领域里的一项技术，你又刚好不太熟，没有回答好，结果评委团就因此认定你在技术维度上表现得不够好，最终没有让你通过晋升。
+
+也许你觉得很委屈或者运气不好，但是从P8的要求来看，这种考核标准其实是有一定道理的。
+
+可是问题在于，很多尝试晋升P8的技术人员，已经承担了比较重的任务，没有那么多的时间来提升技术。
+
+那么，怎么才能高效地提升自己的技术深度和技术宽度呢？除了前两讲提到过的链式学习法和比较学习法之外，我再介绍两种很管用的方法。
+
+第一种方法是**研究业界的开源项目**。
+
+你可以通过学习和研究开源项目的原理和设计来提升技术宽度，通过研究开源项目的源码来提升技术深度。具体的学习方法，你可以参考[《如何高效地学习开源项目》](https://time.geekbang.org/column/article/10022)这篇文章。
+
+当然，开源项目的数量非常多，每个都深入研究的话时间和精力不允许，可以优先关注本领域成熟的、流行的开源项目。比如Java后端开发领域的MySQL、Redis、Nginx和Netty等，前端开发领域的Vue、React和Node等，Android开发领域的OkHttp、Picasso和EventBus等。
+
+第二种方法是**参加业界的技术大会**，比如QCon技术大会、架构师峰会、GMTC（全球大前端技术大会）、GOPS（全球运维大会）和人工智能峰会等。
+
+你可以通过参加技术大会，快速地掌握本领域相关技术在业界的应用情况。尤其是领头羊企业（BAT和TMD等）的技术积累和经验，具有很好的借鉴意义。同时，你只要关注一下大会上讲得最多的技术是哪些，就能够识别出业界整体的技术发展趋势。
+
+当然，如果你能直接在技术大会上做主题演讲，把自己在技术上的经验整理成优质的内容输出给业界，那就更有利于晋升了。因为这会大大提升你的影响力，而P7升P8的时候，在公司和业界的技术影响力恰恰是评委考察的一个重要方面。
+
+<img src="https://static001.geekbang.org/resource/image/e5/57/e5b7429e543cc090yy9cbd03c759e857.jpg" alt="">
+
+## 业务：熟悉多个业务或精通端到端业务
+
+接着，我们来看业务维度。P8级别对业务的要求和团队构成模式有关。
+
+如果是横向模式，P8需要熟悉团队涉及的每一个业务。而且因为这些业务本质上属于某个大的行业，为了能够更好地理解业务，P8还需要对行业有一定理解。
+
+如果是纵向模式，P8只负责1个业务。跟横向模式相比，虽然需要熟悉的业务数量更少，但是对于理解深度的要求要高得多，除了要熟悉自己负责的业务之外，还要深入理解公司内或者行业内类似的业务。
+
+P8级别对业务的详细要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/99/3d/9917d26149c2c38c64cc9e424e31e03d.jpg" alt="">
+
+P5/P6核心能力的关键词是完成“任务”，而P7/P8核心能力的核心是指挥团队达成“目标”。它们的差别在于：**任务是从过程的角度来衡量的，而目标是从结果的角度来衡量的。**
+
+以最简单的需求开发为例，P5/P6只需要按照项目计划完成各项任务就行了，而P7/P8要对业务最后的结果负责。
+
+P7虽然也要为业务结果负责，但在晋升考核的时候，技术能力还是核心考察项，业务结果是加分项；而对P8来说，能不能拿到好的业务结果，这一点在考核中所占的比重要大得多，基本上和技术能力是平起平坐的地位。**这就是P7很难晋升P8的第二个原因。**
+
+可能很多人会认为这么做不公平，因为业务结果很多时候并不是由技术人员决定的，比如新冠疫情导致旅游、航空的业务量大幅下降，某些地方的政治局势不稳定导致线下消费用户量大幅减少。
+
+虽然这些情况是客观存在的，但是这并不意味着技术人员对业务结果就完全不可控了。其实，我们可以在很多方面对业务结果做出直接贡献。
+
+以互联网2C业务为例，常见的技术手段包括通过降低App包大小提升下载成功率、优化某些功能让用户体验更好、提出更合理的方案来满足用户需求以及设计良好的架构来应对秒杀抢购等特殊场景等。
+
+采取合适手段的前提是，我们对业务足够了解。那么，P8阶段要怎么提升对业务的认知呢？
+
+针对单个业务，P8和P7提升的方式差不多，你可以回顾上一讲的内容；针对行业的业务战略，你可以借助**宝洁战略模型**，从愿景、使命、定位、策略、能力和组织等方面来理解。关于宝洁战略模型，我会在**专项提升**部分详细介绍。
+
+站在公司的角度看，引导员工拿到更好的业务结果是理所当然的，这也在侧面体现了第3讲提到的价值原则。
+
+不过，过于重视业务结果的做法，确实会增加运气因素对晋升的影响，导致结果有时候看起来不那么公平。
+
+比如A和B两个人都是P7，其中A的能力比较强，但是运气不好，所在的业务没有发展，甚至还出现了倒退；而B正好在一个业务快速发展的团队中，拿到了更多的漂亮的结果。如果他们俩同时申请晋升，B通过的可能性反而更大。
+
+这种现象是不可避免的，尤其是到了P8之后，运气很多时候就是晋升的关键，有机会展现能力并且拿到结果的人可以晋升，有能力但是没法通过结果展现出来的人就不能晋升。
+
+如果个人遇到这种情况，认为自己有能力但是没机会展现的话，换个岗位甚至公司可能是更好的选择，找到适合自己发展的岗位比找一个名气很大的团队更重要。
+
+所以说，**晋升当然要靠自我奋斗，但也要考虑历史的进程。**
+
+## 管理：核心是抓重点
+
+最后的管理维度。P8需要指挥一个领域的多个团队。
+
+P8级别对管理的详细要求，我总结在了这张表格里：<br>
+<img src="https://static001.geekbang.org/resource/image/ca/a9/ca0d843e8668b788f8469a661be23fa9.jpg" alt="">
+
+跟P7相比，P8的管理范围更大，可能存在以下困难：
+
+1. 团队人员数量变多，不可能熟悉每个人了。
+1. 项目数量大大增加，不可能参加每个项目了，包括需求评审、方案设计等。
+1. 需要参与的各种管理事项大大增加。
+
+所以，我们不能简单地使用和P7一样的管理方法，而是需要对管理技能进行升级。那么，怎么提升自己的管理能力呢？
+
+核心思路就是要学会**抓重点**。我们必须认识到，P8的管理方式不能再像P7那样偏重细节和执行方面的管理（否则时间和精力根本不够用），而是应该关注重点事项的管理。
+
+我根据自己的实践经验，总结了P8阶段管理的三大重点：
+
+1. **团队管理：搭建梯度**
+
+因为P8无法关注团队的每一个人，很多事情的传达和具体执行效果是靠P7/P6级别的人来把控的，所以P8需要重点关注**搭建合理的团队梯度**，包括核心的TL/P7/P6有哪些，核心人员的状态，核心人员的晋升规划等，都是需要重点考虑的。
+
+什么样的团队梯度就算合理呢？一个简单的判断原则是，**每个核心人员都至少有一个备份人员**。比如P8自己要有1个以上的P8/P7+能够做自己的备份人员，每个TL要有1个潜在的TL备份人员，每个核心业务都至少有2个P7能够支撑，依此类推。
+
+1. **目标管理：参与制定，保证理解**
+
+P8需要指挥多个团队达成业务目标，所以对于业务目标的制定和理解是很关键的。P8级别已经有机会参与业务目标的讨论和制定，不能只是带着耳朵去听一下，而要真正地参与进去。
+
+对于最终确定的业务目标，P8级别的人必须是充分理解和赞同的，因为之后P8还需要向团队（包括自己直接指挥的团队和相关协作团队）解读业务目标。如果不理解或者不赞同，在目标讨论过程中就应该提出来，经过讨论或者PK最终达成共识，这样才能为团队拿到更合理的业务目标。
+
+千万不能在讨论业务目标的时候不认同或者不理解但是却不说，然后跟下面团队沟通的时候来一句“其实我也不怎么认同这个目标”，这样做会大大伤害团队的积极性和稳定性。
+
+1. **技术管理：关注演进**
+
+P8级别负责的是整个领域的技术，需要重点关注领域技术的演进。也只有P8来做这个事情是最合适的，相比P7来说，P8有几个优势：一是技术视野，P8关注的是整个领域的技术，技术宽度比P7更强；二是团队资源，领域技术的演进投入可能会比较大，P8能够协调多个团队共同来完成；三是业务理解能力，P8的业务理解能力更好，而且能够掌握更多的业务信息，所以更容易结合业务来考虑技术演进。
+
+最后，我再分享一下P8级别精力分配的经验。如果带横向模式的团队，可以参考532标准，也就是技术50%、管理30%、业务20%；如果带纵向模式的团队，可以参考433标准。
+
+实际比例可以视情况灵活调整。总的原则是，既不要丢掉技术，也要重视业务，技术比例不要低于30%，业务比例不要低于20%。
+
+## 小结
+
+这一讲我基于COMD能力模型，给你详细解读了P8级别的具体要求以及对应的提升技巧。现在，我们回顾一下这一讲的重点：
+
+1. P8的核心能力要求是指挥多个团队达成目标，主要提升目标是成为有影响力的领域专家。
+1. 技术维度上，P8需要精通领域相关的技术，重点提升领域技术宽度，可以通过研究开源项目和参加技术大会来拓宽自己的技术宽度，也可以在技术大会上做主题演讲来提升自己的影响力。
+1. 业务维度上，P8需要熟悉多个业务，并且开始需要掌握战略规划相关的技能，以帮助自己理解业务整体规划，可以采取“宝洁战略模型”的方法快速提升自己的业务理解力。
+1. 管理维度上，P8需要负责指挥多个团队，提升自己管理技能的核心是学会抓住三个管理重点：搭建团队梯队，参与目标制定，关注技术演进。
+
+## 思考题
+
+这就是今天的全部内容，留一道课后思考题给你吧。
+
+对于你现在负责的业务和指挥的团队来说，晋升P8的机会可能在哪里？如果要把握这样的机会，你会怎么规划接下来的行动？（就算你目前不是处在P7晋升P8的阶段，也不妨假设自己是团队里的P7，来分析一下这个问题。）
+
+欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。<br>
+<img src="https://static001.geekbang.org/resource/image/f2/48/f2d94e0c27c2a628eb0b3f4af7f0df48.jpeg" alt="">

极客时间专栏/大厂晋升指南/职级详解/11 | P9提升攻略：怎么成为跨域整合的“业务导演”？.md

@@ -0,0 +1,195 @@
+<audio id="audio" title="11 | P9提升攻略：怎么成为跨域整合的“业务导演”？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/94/48/94f3baa5e7a0461f077fff21b6d8c748.mp3"></audio>
+
+你好，我是华仔。
+
+上一讲我跟你提到，P8级别是技术能力的顶峰。而这一讲介绍的P9级别，则可以说是绝大部分人的职业发展巅峰。因为就算你很厉害，如果没有合适的机遇和运气，也很难晋升到P9，至于从P9继续往上晋升就更难了。
+
+P9级别对应的工作年限一般是10年以上。在BAT级别的大厂，P9是管理层级分水岭，从这个级别开始就属于**中层管理者**了。
+
+很多公司P9的Title仍然带着“技术”或者“工程师”这样的词，比如阿里的P9是“资深技术专家”，腾讯旧职级T4是“专家工程师”。但实际上，对于P9这个级别来说，业务和管理工作已经占据了核心地位，尤其是业务目标管理，比如分析业务情况，讨论业务方向、规划业务突破点或新业务等。
+
+P9的核心能力要求可以用一句话来概括，**导演成熟的作品**。它的核心职责和电影导演类似，都包括制定目标（要拍一部什么样的电影）、整合资源（投资方、演员、编剧等）、做出决策（钱花在什么地方、找谁来主演等）以及完成作品（拍出最后上映的电影，并且拿到一定的票房，至少要赚钱）。
+
+导演的表演水平可能比不上主演，写作水平可能比不上编剧，更不用说服装、道具、摄影这些专业技能了。但导演一定是跨领域专家，对每个领域都有一定的理解，能够结合自己的作品目标来整合行业资源。
+
+P9也是这样，不一定精通每一个专业领域，但一定是跨领域整合的高手。虽然在某些职级体系中，P9和P8的Title看起来只是半斤和八两的差别（比如P9是“资深技术专家”，P8是“高级技术专家”），但实际上它们的能力要求已经发生了质的变化，就像拍电影的总导演和道具组组长的差别。
+
+总的来说，P9的主要提升目标是**跨域整合的业务导演**。接下来，我就从技术、业务和管理三个维度一一展开讲解。<br>
+<img src="https://static001.geekbang.org/resource/image/23/0b/23de43154585315fe473f0b5fe2c270b.jpg" alt="">
+
+## 技术：跨领域整合能力
+
+首先是技术维度。
+
+我想你心里也许有这样的疑问：如果说P8就已经是技术能力的顶峰了，那么P9及以上级别的技术水平还能提升吗？业界有很多P9/P10的技术专家，比如人工智能专家、算法资深专家，他们不是一直都是在技术领域发展么？
+
+其实如果单论具体的某个领域的技术，P9除了自己原来在P8时深耕的那个领域外，其它领域可能还真不如对应领域的P8那么精通。
+
+你可以这么理解，P9及以上级别在技术维度上的提升，并不是体现在单个领域**技术能力**本身，而是体现在**整合跨领域的技术方案来打造成熟落地的作品**上。
+
+### 案例：面向业务的立体化高可用架构设计
+
+就拿我自己晋升P9时展示的[一个作品](https://blog.csdn.net/yunhua_lee/article/details/49867053)来说吧。我在2015年左右负责阿里游戏高可用项目，这个项目涵盖客户端（Android）、运维、后端架构重构和异地多活架构设计，整体结构如下：
+
+<img src="https://static001.geekbang.org/resource/image/ec/f1/ec4aba63636f29dcdd3d03edfcc39ff1.jpg" alt="">
+
+这个作品有三个特别的亮点：
+
+1. 我们将“4个9”这种**不直观的高可用指标拆解**为“3分钟定位问题、5分钟恢复业务、平均最多2个月发生一次问题”。这是我在讨论的时候提出的一个创意，后来我看到很多公司都在用类似的表述。
+1. 这个高可用方案是**面向业务的立体化方案**。通常说到高可用，大家首先想到的就是运维的各种保障，而我当时的核心理念是“高可用的系统是设计出来的，不是靠运维保障出来的”，所以设计了如上图展示的多个方案组合起来的立体化方案。
+1. 这是整个游戏业务线，甚至是整个UC，第一个真正**实现异地多活架构**的业务。并且我还提炼出了一套完整的异地多活设计方法论，后来指导了几个其他的业务顺利实现了异地多活。
+
+这3个点的要求是我作为“导演”提出的，但整个“作品”是由多个团队的多个P7/P8协作完成的，客户端、运维和后端都有领域负责人参与。
+
+我基于整体的架构思路给客户端和运维提出具体的要求，由各领域提出可选方案，然后我们一起讨论。能达成共识当然最好，如果达不成共识，那就主要由我来拍板，我自己参与的重点是在架构解耦（2014年的时候我们还没有用微服务的概念，其实就是微服务拆分）和异地多活这部分的设计。
+
+看完了我的晋升案例，相信你已经能够初步体会到，所谓的“整合跨领域的技术打造成熟作品”到底是什么意思了。它的核心要求就是具备一定的**技术广度**，能够结合作品来整合不同领域的技术，这也是P9阶段提升技术能力的关键。
+
+### 技术广度：跨领域的技术视野
+
+那么，什么是技术广度呢？我们不妨把它跟技术深度和技术宽度放在一起，对比理解。
+
+比如说你是前端工程师：
+
+- 一开始，你努力钻研React技术直到熟练掌握，这是技术深度的提升；
+- 接着，你又全面掌握前端领域的所有技术，包括vue、Js和小程序技术等，这是技术宽度的提升；
+- 然后，你开始了解后端和AI等领域，拥有了跨领域整合的能力，这就是技术广度的提升。
+
+<img src="https://static001.geekbang.org/resource/image/9e/95/9eb31b87b4c8afc0440af9e1678d8795.jpg" alt="">
+
+P9级别的技术详细要求，我总结在了这张表格里：
+
+<img src="https://static001.geekbang.org/resource/image/9d/e7/9d6c16c1884ed09a508cc993f65e5be7.jpg" alt="">
+
+既然技术广度在P9阶段这么重要，我们应该怎么提升呢？
+
+首先，你不要陷入到太细的技术细节中，比如某个工具的使用、API如何调用等，因为这样做花费的时间太多，而且对于做关键技术决策并没有什么帮助。相反，你需要从宏观层面熟悉多个领域的技术，包括技术原理、优缺点、适应场景和业界应用等。
+
+**环式学习法**就是一个利器，它能通过闭环的思维大大提高技术广度的提升效率，我会在学习方法部分详细介绍。
+
+另外一个提升重点就是**关注和学习新技术**，比如人工智能、区块链和VR/AR等，因为新技术可能会给业务带来新的突破。
+
+但是因为新技术和业务的结合点并不是一目了然的，需要在目标不明确的情况下持续跟进1～2年时间，所以我不建议一开始就大张旗鼓地投入，也不建议直接安排别人去跟进。
+
+最好的办法还是P9自己保持一定的关注度，等到时机成熟，再专门安排手下的P7/P8去深入研究。
+
+## 业务：从理解规划到亲自导演
+
+在业务维度上，公司也对P9提出了更高的要求。
+
+按照规模和组织形式来区分，P9负责的业务范围一般可以分为三类：
+
+1. 独立的一个或者一类产品
+
+比如阿里云上的云数据库Redis版，或者云数据库Redis版 + 云数据库MongoDB版。
+
+1. 某个行业中的一个或者一类业务
+
+比如美团App是一个覆盖“本地生活”行业的App，里面会划分外卖、美食、酒店、电影等几十个具体的业务，一般P9会负责其中一个或者一类业务。
+
+1. 某个中台的一个或者一类业务域
+
+比如电商中台可以分为支付域、订单域、商品域和用户域等几十个业务域，一般P9会负责其中一个或者一类业务域。
+
+至于P9到底是负责一个还是一类产品、业务、业务域，这跟产品、业务、业务域的复杂度、规模、公司的组织结构以及自己的能力（P9-还是P9+）都有关系。
+
+### 规划和突破
+
+但是，不管负责哪一种业务范围，对P9级别的考核来说，业务结果所占的比重都大大增加了，甚至已经超过了对技术的要求。
+
+我在[第6讲](https://time.geekbang.org/column/article/317813)提到过，P9要导演出成熟的业务作品，就像合格的电影导演要拍出7分以上的电影作品。
+
+也就是说，P9需要规划业务目标（可以独立规划，也可以跟其他人一起规划），协调整合资源来落地规划（可能是成立新团队，也可能是成立新项目），并且落地后还要拿到比较好的结果。
+
+通常情况下，P9要能够拿到有突破的业务结果才能得到认可，如果只是将已有的业务数据提升一些是作用不大的，例如我的阿里游戏高可用方案，落地后真正实现了“3分钟发现问题，5分钟恢复业务”的目标，而在做这个方案前，我们的业务曾经1个月出了4次大故障，最长故障时长6小时。
+
+**从理解业务规划到做出业务规划并拿到有突破性的结果，这是P9相对P8的核心提升点之一，也是P8晋升P9很难的一个因素。**
+
+首先，好的业务机会本身就非常稀缺，毕竟行业的风口并不是经常有的，业务上大的发展和突破也不是年年都有。而如果业务本身没有大的发展或者突破，相关的各种机会就会比较少。例如我前面举例的阿里游戏高可用项目，核心原因是业务发展很快，用户量大增，原有技术架构存在严重缺陷。
+
+我曾经跟朋友说过，如果让我现在以P7的身份加入大厂，我再干6年也不一定还能晋升到P9，因为机会是可遇不可求的。
+
+其次，内部竞争激烈，做业务规划的机会不一定能落到自己头上。
+
+虽然P8+的总体数量不是很多，但因为业务机会更加稀缺，结果还是僧多粥少。可能同一个业务机会抛出来，有好几个P8+都想抓住，但最后只有一个能够得到高层的认可和支持。
+
+当然，P8+自己也可以提一些创新的业务突破方向。但是这些想法能不能得到高层的支持，有很大的不确定性，因为高层会面对各种创新的想法，不可能每个都采纳。
+
+第三，业务能不能实现突破，运气成分很大。
+
+即使你一路过关斩将，得到了高层的认可和授权，开始负责将业务规划落地，但是业务结果怎么样，还是有很大的运气因素。比如你负责的是微信支付的香港本地钱包业务，碰上这两年的政治事件和新冠疫情，业务开展肯定会受到很大的负面影响，更不用谈有什么突破性发展了。
+
+P9级别对业务的详细要求，我总结在了这张表格里：
+
+<img src="https://static001.geekbang.org/resource/image/c6/43/c694226af65c80924046c38b25374d43.jpg" alt="">
+
+P9是业务规划和执行的核心人员，需要从战略的高度来思考业务方向。关于业务战略的理论和方法论很多，如果你想快速入门，我建议学习**宝洁战略模型**。
+
+在P8的提升攻略中，我也提到了可以借助宝洁战略模型来提升自己对业务规划的理解能力。不过到了P9级别，你就不只是用它来理解业务规划了，你还要通过这个模型塑造自己的战略思维，指导自己规划业务方向和目标。
+
+另外，业务战略和行业是强相关的，你必须**在行业内经过一定时间的摸爬滚打**，才能积累相关经验和理解。所以，不能光靠理论学习来提升业务战略，而要做到知行合一。
+
+当你是P8+的时候，会有很多机会参与业务规划和分析的相关会议和讨论，你可以结合宝洁战略模型，学习P9/P10或等高级别的人在分析和规划业务时的思路和逻辑。
+
+## 管理：授权但不要放羊
+
+P9级别的管理要求整体来说和P8类似，核心工作也是团队梯度、业务目标和技术演进三大块。
+
+P9级别对管理的详细要求，我总结在了这张表格里：
+
+<img src="https://static001.geekbang.org/resource/image/97/35/9722ded5dd84yyfae35f78c29yy28635.jpg" alt="">
+
+P9带团队的挑战在于，因为管理范围覆盖的领域比较多，你已经不可能在每一个具体领域都达到精通的水平了。
+
+所以，你在管理P8的时候，需要尽量采用授权式管理。不过一定要注意，不要把授权式管理变成了放羊式管理。
+
+有些P9因为自己曾经不是从某个专业领域升上来的，对这个领域不太熟悉，就干脆把这个领域的事情完全丢给一个P8了事。
+
+但是这可能会导致在做关键的技术决策的时候出现脱节：P9懂业务，但是对某个专业领域不熟悉，而P8虽然在专业领域上很精通，但是对业务的理解一般，无论谁来做决策，都存在很大风险。
+
+### 案例：小游戏App项目
+
+举个例子吧，我在P9级别负责过一个小游戏的项目，简单来说，就是做一个小游戏的App，用户在里面可以玩各种小游戏。
+
+这个项目App要采用什么技术方案呢？当时我们内部有两种不同的意见：
+
+1. Android和iOS团队都建议完全用原生的技术来实现，因为对于大部分玩小游戏的用户来说，手机性能都一般，用原生的技术他们的体验会更好。
+1. 前端团队建议用App + H5包壳的方式快速上线，因为这是一个快速尝试的创新项目，H5的方式能够让业务快速迭代。
+
+在讨论决策的时候，我的老板们（在业务线上带我的P9和P10）也倾向于用原生的技术方案，因为他们觉得用户体验是小游戏成功的关键。
+
+但是经过分析，我认为App + H5包壳的方式更适合业务，因为小游戏体验的好坏关键在于小游戏本身。App的交互并不复杂，原生技术不会带来体验上的优势；相比之下，用H5实现既能够支撑业务快速迭代，又能够满足用户体验的需求。
+
+最后，我顶着老板们的压力立下了军令状，确定了用App+H5包壳的方式来实现。而后续业务的发展，也印证了这个技术方案的先见之明。
+
+一方面，我们内部测试的时候发现，小游戏本身的设计是用户体验的关键。很多游戏在上线之后都要经过不断调优才能够达到用户体验的要求，而小游戏App本身没有成为体验的瓶颈。
+
+另一方面，小游戏App上线之后，推广很困难，让用户独立下载一个小游戏App的成本很高。于是我们很快就在业务方向上进行调整，从独立的App改为嵌入到集团内成熟的App。因为采用的是H5包壳的技术方案，所以迁移的成本比较小。
+
+这个故事说明什么呢？虽然P9下面会有几个不同领域的P8专家支撑，但是这并不意味着你可以直接把技术工作全都交给他们。比方说小游戏App的技术方案，你不能甩给Android、iOS和H5三个领域的P8来进行辩论和PK，谁赢了就听谁的。
+
+在做业务相关的关键技术决策时，P9必须根据对业务和技术的理解，自己拿主意。因为只有到了P9级别的人，才拥有**跨领域的技术理解，并且能够结合业务的发展来做出判断。**
+
+跟P8相比，P9因为要负责业务目标的制定和实现，所以需要在业务和管理投入更多的精力，而技术上投入的精力则稍微少一点。
+
+总的来说，P9在技术、管理和业务上的精力分配没有固定的标准。
+
+如果业务稳步发展，你可以参考433的标准，也就是40%业务、30%管理、30%技术；而如果你作为空降的P9接手了一个原来表现不太好的团队，就得在业务和管理上面投入更多，按照40%业务、40%管理、20%技术来分配；而如果你负责的业务面临发展的天花板，那么按照631的比例也是可以的，也就是业务60%、管理30%、技术10%。
+
+## 小结
+
+这一讲我基于COMD能力模型，给你详细解读了P9级别的具体要求以及对应的提升技巧。现在，我们回顾一下这一讲的重点：
+
+1. P9的核心能力要求是导演成熟作品，主要提升目标是成为跨领域整合的业务导演。
+1. 技术维度上，P9需要具备跨领域整合的能力，重点提升领域技术广度，可以通过环式学习法来提升自己的技术广度，通过关注和跟进新技术来提升自己的创新能力。
+1. 业务维度上，P9需要规划业务目标，并且需要掌握战略规划相关的技能，指导自己做出好的业务规划，可以采取“宝洁战略模型”的方法快速提升自己的业务规划能力。
+1. 管理维度上，P9需要负责指挥多个不同领域的团队，除了抓住三个管理重点（搭建团队梯队、参与目标制定、关注技术演进）外，还可以采用授权的方式管理团队，但必须注意，不要把授权变成放羊。
+
+<img src="https://static001.geekbang.org/resource/image/70/a1/701e514a2c5cdc6273b2244ab50b97a1.jpg" alt="">
+
+## 思考题
+
+这就是今天的全部内容，留一道课后思考题给你吧。既然P9级别管理和业务的能力比重大大上升，是否可以由技术出身的P9来管理产品运营团队，或者由产品运营出身的P9来管理技术团队？
+
+欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。<br>
+<img src="https://static001.geekbang.org/resource/image/92/03/9272cdf84a3d5d2d66b6c8fed931f403.jpeg" alt="">