一般来说，工作中能力跟参加工作时间和工作经历强相关，相同的职位，大家广泛会以为一个工作3年的人比工作中1年的人强大。但为什么有的人工作中1年能力就强，有些工作中5年似乎还在一成不变？撇开智力、机会、环境种种因素不说，从个人能力的提高方面来讲，我觉得从工作职责中高效地梳理总结和反思是一个必备条件。
工作职责中间一般都是相关联的，并且更多的是重复。将不一样的工作经历开展合并同类项、归类梳理、汇总提炼，由繁化简才可以举一反三。
下面我就以产品经理为例子，聊一聊我能理解的怎样从具体工作职责提炼出关键能力。
文中逻辑性：
- 高度提炼的必要性
- 创建职业发展目标与能力架构
- 项目复盘总结
- 创建能力梳理表
- 有选择性的探索
01 高度提炼的必要性
项目全是企业的，产品经理仅仅打工，但从项目中学到的东西才算是我们自己资本。持续从大大小小项目中总结归纳方法，能够让我们提高工作效率，更得心应手地做好后面的工作任务。
在支撑企业项目的前提下，也需要密切关注项目对自身能力的建立功效，不然容易被实际业务流程绑票，一旦离开这个公司，或离开自身耳熟能详的项目，也会显得手足无措。
从项目中吸取经验方法是第一步，帮我们从较为散乱重复项目中寻找规律性、获取工作经验。但是当大家经历过的项目愈来愈多时，这些方法工作经验也越来越多了，我们的大脑是很难的记忆。
这个时候就需要将工作经验方法重新进行高度提炼，产生高内聚、扩展性和实用性高的能力，你可以算是能力实体模型、能力图普这些都能够，当它们充足精减时，就真只有一张示意图、乃至两三句。当再一次碰到工作中的问题时，不再需要考虑到过度细节上的方法，而是通过脑中高度提炼的能力实体模型中寻找正常方位。
这种由上而下的高度提炼方法还能够迁移到别的行业，超过产品经理的工作任务，延伸至对生活的理解中，构建个人哲学思想。
02 创建职业发展目标与能力架构
可以从工作职责中提炼出能力，首先自身弄清楚职业发展目标，还有自己接受的产品经理能力实体模型是怎么样的，不然提炼出来的只能较为散乱杂乱，没法高度归纳。
针对产品经理的能力实体模型，业内比较出名的是腾讯官方产品经理能力图表，它对每一个职务级别的产品经理必须掌握的能力和水平都是有详尽例举。
但是它的主要缺点有一些含糊，对能力的层面未进行非常好的区别，例如“心态和情商智商”、“主人翁意识”这部分内容跟能力好像不是一个层面，归属于职业道德方面的知识，“知识传承”、“人才的培养”又有些沧蓝于能力实体模型，侧重职业生涯发展和企业建设方面。
也有网易音乐王诗沐对产品经理能力模型的归纳，对处在不一样参加工作时间的产品经理给出了不同类型的能力偏重于具体内容。
但是这个实体模型主要缺点较为侧重于C端商品，比如说针对B端设备而言至关重要的技术性了解能力也没有提及，也有将“思维模式”这类偏最底层的具体内容放进3~7年杰出产品经理相对应的控制模块显而易见也不是很有效。
在网上还有一些能力模型图，就会发现，每一个领域内的产品经理的能力偏重于是不一样的，套入他人创建的实体模型是很难通用。我觉得一个符合要求的产品经理应当充分运用能动性，根据自身所属的产品方向和对产品了解，构建自已的能力模型图，并不断地健全。
以下属于我自己建的金字塔式商品能力模型图，底部思想和素养是偏最底层的基础梁，中高层是重点能力层，顶端是锦上添花的丰富多彩认知能力层。
无论产品经理的工作经历多少，这一金字塔式都是能够适用。工作经历比较深工作经验丰富多样的产品经理，它的金字塔式就更高一些更高，每一个层次的主题鲜明度也会更高。但无论什么时期，金字塔的构造一般不会变得，也是从最底层往上面构建。如果将太多心思放在顶层，忽视了基本的基本建设，全部能力实体模型也会变得根基不稳，花哨。
蓝色双层都是属于能力层，但是我把侧重于操作过程的概括为专业技能层，把侧重剖析决策的过程概括为洞悉管理层。要提升这2层的能力，除开阅读文章、与人沟通等形式，我觉得更重要的是依靠自己从实践中进行整理提炼，都是文中主要内容。
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形优秀人才的高速发展需求，一定要先对自身在行业发掘深层，再横着扩展别的方向。
但实践中，工程类别的界限没有那么清晰，可能有模糊不清地区，每一个产品经理估计都涉及到不同种类的新项目。因而，在一些具体工程中，可以更加有倾向性的向自己的品牌方向看齐。
例如同是做运营支持的需求，有些人较为专注于引流转换的用户增长方向，有的人更专注于数据统计分析方向，还有的人通常是承担后面业务，仅仅辅助在适用经营有关需求，那么他可以更加多从提炼出运营工具及实用性的视角来独立思考。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
