一般来说，工作能力跟工作年限和工作经验强相关，同样的岗位，我们普遍会认为一个工作3年的人比工作1年的人厉害。但为什么有的人工作1年能力就很强，有的工作5年好像还在原地踏步？抛开智商、机遇、背景这些因素不谈，从个人能力的提升方面来说，我认为从工作内容中有效地归纳和总结是一个必要条件。
工作内容之间一般都是有关联的，而且更多是重复的。将不同的工作经验进行合并同类项、分类归纳、总结提炼，化繁为简才能举一反三。
下面我以产品经理为例，聊聊我理解的如何从实际工作内容提炼出核心能力。
本文逻辑：
- 高度提炼的重要性 建立职业目标与能力框架 项目复盘总结 建立能力归纳表 有倾向性的思考
项目都是公司的，产品经理只是打工的，但是从项目中学到的东西才是我们自己的财富。不断从大大小小的项目中归纳总结技巧，可以让我们提高效率，更游刃有余地完成后续的工作内容。
在支持公司项目的同时，也要时刻关注项目对自己能力的建设作用，否则容易被具体业务绑架，一旦离开了这家公司，或离开了自己熟悉的项目，就会显得无所适从。
从项目中总结经验技巧是第一步，帮助我们从散乱重复的项目中找到规律、提取经验。但当我们经历的项目越来越多时，这些技巧经验也越来越多，我们的大脑是难以记忆的。
这时就需要将经验技巧再次进行高度提炼，形成高内聚、拓展性和通用性强的能力，你可以称之为能力模型、能力图谱等等都可以，当它足够精简时，可能就只有一张简图、甚至几句话。当再次遇到工作中的问题时，不需要再考虑过于细节的技巧，而是从脑子里高度提炼的能力模型中找到正常的方向。
这样的自下而上的高度提炼方式还可以移植到其他领域，超出产品经理的工作内容，延伸到对生活的理解中，搭建个人的哲学。
02 建立职业目标与能力框架要从工作内容中提炼出能力，首先要自己搞清楚职业目标，以及自己理解的产品经理能力模型是怎样的，否则提炼出来的东西只会散乱无章，无法高度概括。
对于产品经理的能力模型，业界比较有名的是腾讯产品经理能力雷达图，它对每个职级的产品经理需要掌握的能力和程度都有详细列举。
但它的缺点是有些笼统，对能力的维度没有进行很好的区分，比如“心态和情商”、“主人翁精神”这些内容跟能力好像不是一个维度，属于职业素质方面的内容，“知识传承”、“人才培养”又有点超脱于能力模型，偏重职业发展和企业建设层面。
还有网易云音乐王诗沐对产品经理能力模型的概括，对处于不同工作年限的产品经理提出了不同的能力侧重内容。
但这个模型缺点是比较偏重于C端产品，比如对于B端产品来说非常重要的技术理解能力都没有提到，还有将“思维方式”这种偏底层的内容放到3~7年资深产品经理对应的模块显然也不太合理。
网上还有很多能力模型图，我们会发现，每个领域的产品经理的能力侧重是不一样的，套用别人建立的模型是无法通用的。我认为一个合格的产品经理应该充分发挥主观能动性，基于自己所在的产品方向和对产品的理解，搭建自己的能力模型图，并不断的完善。
以下是我自己搭建的金字塔产品能力模型图，底部的思维和素质是偏底层的基础层，中层是核心能力层，顶部是锦上添花的丰富认知层。
不管产品经理的资历高低，这个金字塔都是可以适用的。资历较深经验更丰富的产品经理，他的金字塔就会更高更大，每个层级的内容丰富度也更高。但不管什么阶段，金字塔的结构是不会变的，都是从底层往上搭建。如果把过多精力放在上层，忽略了基础的建设，整个能力模型就会变得根基不稳，花里胡哨。
蓝色的两层都属于能力层，但我把偏重于实际操作的归纳为技能层，把偏重分析决策的归纳为洞察决策层。要提高这两层的能力，除了阅读、与人交流等方式，我认为更多的是靠自己从实际工作中进行总结提炼，也是本文的主要内容。
03 项目复盘总结搭建好了能力模型后，我们需要去实际经历的项目中先提炼技巧经验，而项目复盘的提取技巧经验的必经之路。我将项目复盘总结为以下四点：
1. 复盘的时间节奏较大的项目可以结束后一段时间有数据反馈后开始复盘，小的零散的项目可以季度或半年整体复盘一次。
2. 产品上线是否满足真实需求用户第一，上线的产品是否解决了真实需求是首先需要复盘的。
1）真实用户的反馈
可以直接与用户沟通，或者平台的意见反馈中心找到用户的使用吐槽。我个人做后台产品比较多，一般上线后直接跟使用的业务方收集使用反馈。
2）数据分析的反馈
用户反馈的掺杂了很多主观的因素，而且存在幸存者偏差，因此还需要通过较为客观的数据统计了解功能的使用情况。数据分析的粒度可大可小，C端产品埋点多一些，可以分析用户操作路径的数据，而B端产品数据少一些，主要从功能使用率、工单数等方面评估。
3. 产品设计是否合理由于我主要负责B端产品，以下总结更多适用于B端设计。
1）产品功能是否足够简化，是否过度设计
B端产品主要为了提升效率、满足业务诉求，因此要避免过多花里胡哨的设计，先解决核心需求。
2）是否有遗漏的异常流
规划过程中应该全面考虑异常流，但如果当时确实遗漏没有考虑到，在产品运行过程中会暴露出来，应该及时与业务方、客服寻求反馈，发现这部分遗漏的异常逻辑，及时修复。
3）关联系统的影响
对于平台型产品，调用方较多，每一方的需求也不一样，产品上线后也需要定期确认其他关联系统的影响，比如数据调用、权限区分。
4）系统拓展性设计如何，是否有预留逻辑
系统的拓展性跟过度设计听起来很像，但其实有本质区别。拓展性好的系统可以快速适应相似的需求接入，且预留逻辑一般不会单独消耗过多的开发量。复盘过程中可以结合多版本的迭代内容，仔细审视最初系统的拓展性如何。而过度设计是多做了很多没用的功能，工作量大，价值很低或者后续很难用到。
5）功能迭代的节奏是否合理，是否有重复内容
对一个长期升级迭代的系统，当回顾它的多次迭代时，我们可以回顾自己对每一版迭代内容的决策是否合理，是否将被依赖项的内容先完成后，再进行依赖项的开发？是否存在多次对同一个点进行迭代？为什么没有一次解决？这些问题只有回过头去看的时候才能评价自己当时的决策水平。
4. 项目过程回顾以下针对推进项目开发到上线的过程中可复盘回顾的内容，这个过程可以邀请需求方、开发同学一起参加，也是提高团队合作效率和执行力的好方法。
1）需求方沟通是否明确，有无较大修改，什么原因
项目启动前需求是否足够明确，在项目进行过程中有哪些较大的需求变更，什么原因导致的变更，需求文档是否有记录。
2）需求评审是否一次过，哪些是评审后调整的
需求评审时如果有核心流程考虑不周，或者需要有较大的改动，会被开发同学怼的，产品经理是很没面子的。一般刚开始做产品都会有这个过程，通过回顾自己被怼的过程，总结经验，下次获得开发的肯定，这比看无数篇别人的方法论更有用。
3）开发进度是否delay，具体哪一项导致
过程很重要，但结果更重要。对于提前定好了上线时间的项目，一般是不允许延期的。但对于没有上线要求的项目很容易延期，需求方、产品、设计、开发、测试，5个环节都延期1天的话，项目就会延期一周以上。通过回顾整个项目的时间进度，严肃客观的讨论延期的具体环节和原因，可以提高团队对时间概念的重视程度。
4）外部合作是否顺畅，哪些原因影响进度
当遇到与外部公司合作的项目，变量和不可控因素变得更多，一般这种项目的推进效率会比较低，特别是首次对接的时候。但通过回顾已经对接过的项目，对一些主观可控的内容进行梳理，记住踩过的坑，可以提高我方的项目合作能力。
04 建立能力归纳表项目复盘后，我们会总结出自己的技巧经验。以下是我设计了一个能力归纳表，可以将每一个项目的内容和经验总结填充进能力表，找到对应的位置。也可以先将工作内容先记录到这个表，然后再定期复盘填写后面对应的内容。
这个表格有三个作用。
1. 客观记录工作内容绿色部分用于记录工作内容，客观、有序的整理记录方便回忆和复盘，从而提炼出技巧经验。
2. 总结技巧提炼能力黄色部分用于记录总结的技巧经验，然后思考这些技巧对应了产品能力模型中哪些项，再进行深度思考提炼。
把总结的技巧这一列再进行深度思考和归纳，提炼出高共性高内聚的真理，这个过程并不容易，会受到自身思维方式的影响，我个人也还在不断学习中。我建议可以多阅读关于底层思维模型的工具书和大咖的经验，如《金字塔原理》、《穷查理宝典》。
3. 评估所在业务的价值橙色部分用于思考业务的发展现状和想象力，天花板越高的业务对能力提升越有益。如果业务方向太窄，产品经理的工作内容过于重复，容易沦为一颗螺丝钉，对整个职业发展是很不利的。
这三个作用是有先后递进顺序的，这张表格需要定期进行补充迭代。
05 有倾向性的思考现在产品经理越来越细分，每个人需要将更多精力投入到自己所在的领域中。同时也是为了适应T形人才的发展需求，应该先对自己所在领域挖掘深度，再横向拓展其他方向。
但实际工作中，项目划分的边界没那么清楚，可能会有模糊地带，每个产品经理可能都会涉及到不同类型的项目。因此，在一些实际项目中，可以更有倾向性的向自己的产品方向靠拢。
比如同样是做运营支持的需求，有的人比较专注于拉新转化的用户增长方向，有的人更专注于数据分析方向，还有的人主要是负责后端业务，只是辅助性的在支持运营相关需求，那他可以更多从提炼运营工具及通用性的角度来思考问题。
