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