前段时间，很多公司开始实施“996工作制”，引起了业内很广泛的讨论。这种粗暴的通过延长工作时间来得到更多产出的做法，被很多人吐槽。那为了达到高产出的目的，是否还有更好的办法呢？回答显而易见，那就是提高单位时间的产出比，也就是「效率」。
那作为产品经理，在实际工作中，我们可以从哪些方面来提高自己的工作效率呢，作为一名对低效率“深恶痛绝”的产品汪，以下是我一点不成熟的思考。
什么是生产力工具？简单来说，就是专门帮助用户更快、更高效完成工作的软件，比如文字编辑、图片处理、视频剪辑等等。作为产品经理，也有一堆工作中常用的软件需要掌握。
PRD输出：最常用的就是word，在mac平台对应则是page，还有一些人会用OmniOutliner等文字处理软件，同时mou等markdowm工具也深受推崇；原型设计：产品必备axure，更轻便灵活的mockplus，同时还有深受好评的sketch能够快速产生高保真原型；流程图：微软老牌软件Office Visio ，还有mac平台上功能强大的OmniGraffle，还有ProcessOn等在线制图平台也十几受欢迎；思维整理：常见的有mindmanager、xmind等，还有mac平台非常美观的mindnode；除了生产力软件，还可以收集一些常用的资源库，在我们需要用的时候能够帮助我们快速找到想要的素材，比如以下网址：
图片：https://pixabay.com/、https://unsplash.com/图标：https://unsplash.com/、https://www.iconfinder.com/PPT模板：http://www.officeplus.cn/Template/Home.shtml、http://www.docer.com/软件的很多高级功能我们或许很少用到，但是对于那些常用的操作一定要熟练掌握，因为只有这样我们才能将精力专注于产品设计等核心工作，而不是浪费在工具的调试。同时也要注意工具是用来帮助我们更好的思考和表达，不要一味追求酷炫的表现形式，也不要局限于形式。
另外，我们也要明白软件的强大并不是在于功能丰富，而是它在既定的设计逻辑下支持多样的使用场景。所以当我们判读一个软件是否足够优秀，是否得心应手时，要先找到自己清晰的使用逻辑和场景，然后持之以恒的用下去，才会逐渐发现这些生产力工具对我们工作效率带来的提升。
二、学会提炼通用的模块或内容产品经理是一个创意型的工作岗位，所以那些重复性的机型动作基本上大部分都是在降低我们的工作效率，在工作中，我们要学会将那些通用的模块提炼出来，从而可以通过不断快速的复用来提高工作效率。
我们最常用到的就是各种模板，比如RPD的Word模板，统一确定好文档包含的各项内容，以及各级标题等样式，这样在我们下次写文档时直接填充主干内容即可；再比如Xmind思维导图或Visio流程图等，设计出一套或多套自己喜欢的风格样式，以后每次需要时直接套用即可。这样做不仅仅提高自己的效率，当团队成员相互之间磨合完成之后，也会降低理解成本和沟通成本。
还有原型设计软件中非常好用的母版/组件功能（axure中称为母版，sketch中称为组件），将多个地方经常会用到的模块提炼成组件，不仅仅在创建时能直接复用节省了很多工作量，尤其在涉及修改的时候，你会发现只要修改一处，全局同步调整完成，那种快速带来的痛快感非常明显。我之前的一篇文章 如何用Axure快速制作APP交互原型就是利用了母版的功能。
除此之外，在产品设计上也经常会有很多通用的功能点。如果在每个运用到的地方都赘述一遍必定是个繁琐的过程，只要某个功能点被应用了3次及以上，我们都可以将其剥离出来，对这个功能单独阐述，凡是应用到此功能的地方，一句话引述过去即可。比如不同页面选择商品的逻辑是相通的，所有banner位置跳转配置逻辑是相通的，不同活动的启用停用管理是相通的……其实不仅仅是在产品设计上，在开发实现上也是类似的思路，这些功能点都是以全局形式实现出来的。
三、体会深入思考的重要性一个效率低下的常规表象就是处在不断的返工修改中，造成这个局面的原因，一部分可能是外界不可抗因素所引起，比如业务方临时需求变更，但同样也有大部分情况是由于自己没有思考清楚就草率的开始了下一步骤。没有思考的足够透彻，就冒然做事，很容易出现方向不对、细节疏忽等异常情况，这些都会导致效率变低。
产品新人最常见的一个坏习惯就是整理好需求之后马上开始写文档画原型，其实在需求和原型之间还存在一堵墙，我们只有通过深入的思考将这堵墙拆解之后，才能顺利的过渡到到写文档的阶段，否者就很容易出现反复修改的过程。当我们想清楚之后，再去产出文档或原型，你会发现是水到渠成的一件事情，效率自然就会提高，并且质量也会有所保障。这个思考的过程可以称为设计规划，包含“组织信息架构”和“设定任务流程”两个步骤，具体可参考之前的一篇文章 产品设计：需求和原型中间隔着一堵墙
在产品经理的实际工作中，经常会有很多问题冒出来需要处理解决，同样的问题，有的人能很快找到有效的解决方案，而有些人可能花很久却摸不到眉目，这也就体现出了效率的高低。在我之前的一篇文章 产品经理在解决问题时是否有套路可言？，也着重强调了将问题思考透彻的重要性，当我们拿到一个问题后，先不要急着从问题表象出发来寻找解决方案，这样很可能治标不治本，当我们通过思考探寻到问题的本质逻辑后，再结合业务背景才能高效准确的寻找到最理想的解决方案。
无独有偶，在前些天的项目周会上，开发leader也表达了同样的观点，他强调真正写代码的时间其实很短，要多花时间在思考上，把需求理解清楚，把开发逻辑思考透彻，然后在开始写代码，效率和质量都会有所提高。
四、对不同认知类型的工作分层处理心理学家发现，当从任务A转换到任务B后，执行任务B的绩效明显要比非任务转换条件下执行B的绩效差，这个差异称为“转换损耗”。形成原因主要有两种，一是任务A留下来的认知习惯对任务B造成的干扰；二是做B的时候需要对B进行认知重构。同时还有个重要的事实不容忽视：在非常投入的和忘我的思考时被打断，损失非常大；相反，如果只是在机械性动作，频繁被中断也会有太大影响。
在《精进》一书中，采铜提出了一般任务分解的“三明治模型”。中间的部分称为“核心思考区”，这个部分需要集中精力、非常专注地进行思考，要尽量用可保证的相对完整的时间来处理，减少被中断的可能，才能高效地将其破解；余下的就是一些支持性的、补充性的工作（即“支持性思考区间”和“操作性动作区间”），这部分相对来说则是可以“允许中断”的。
在《精进》一书中同样提出了要学会对不同认知类型的工作分层处理。什么是认知类型呢？指的是我们头脑加工信息的不同方式，比如处理语言文字时是一种类型，处理视觉图片是一种类型。当不同认知类型进行切换时，人需要重新进行调整，这样任务的转换损耗会比较大。
比如对这篇文章来说，大家看到的顺序是从上到下，可是在我创造的过程，可能会分成这样几个步骤
通过思维导图MindNode梳理出主要想表达的观点和文章结构；然后再通过文字处理软件Ulysses填充每个章节内容的细节描述；接下来利用Sketch或PS等软件处理文章需要用到的图片素材；最终再从文章全局角度来调整排版布局等样式细节；同样在写文档或画原型图时，我们也可以尝试将任务分解并找到核心思考区间集中精力攻破，并找到同认知类型的工作分层处理。比如，PRD文档我一般都习惯先梳理出整体的框架，然后逐渐填充细节；在画原型时，先完成主干流程的交互，再逐渐补充细节末节的逻辑；在做PPT时，同样如此。
五、优先确定影响进程的关键因素很多项目的正常推进，依赖的是各个重要环节能够按照顺序依次发生，比如只有完成了步骤A，才能达到步骤B，或者同时满足了A1、A2和A3才能到达步骤B。换个角度看，某些关键因素决定着整体的进程，如果关键因素突然无法满足，那其后相关流程的工作都成为了无用功，因此要学会优先确认那些影响进程的关键因素，保障各个环节按照正常节奏顺序展开，避免出现无效工作。
比如在做产品设计时，千万不要在自己假想出来的技术方案上来搭建产品方案，甚至将完整的文档、高保真原型图都一并输出完成，才被告知技术方案不可行，此时付出的心血大多都将付之东流。所以，在设计产品方案时，如果遇到不确定的技术问题，一定要跟重要的开发人员及早进行沟通，一方面确定技术的可行性与否，另外开发有时候也能提供出更好的实现思路。总之，学会尽早确定技术实现这个关键因素，切忌闭门造车，才能使我们的方案更好的落地。
作为产品汪，还经常需要牵头组织各种会议，包含需求评审等等。每个会议中都会有一些关键性人物，决定着会议结果的走向，所以对于某些不太确定的问题点，完全可以在会议前先跟关键人物沟通确定好，这样不仅仅提高会议效率，并且项目也会更加正向推进；另外，对于会议的重要内容，也可以通过邮件等形式提早发出来，让与会人员尽早了解到问题点所在，这样在会议上能更有针对性的对问题进行讨论，而不是花费时间在问题的了解上；还有，灵活把握大会与小会的议题内容，人数众多的大会更适合一些全局问题和整体进展的讨论；而三五成群的小讨论更适合产品方案细节的沟通，叫上相关人员随时发起，极大提高沟通的效率。
产品经理一般都是依托团队来发挥力量，除了以上提到的技术方案和会议沟通，在其它方面都会存在一些关键因素，比如涉及到多部门资源协调等等。作为项目的主导角色之一，我们要能够找到那些关键因素优先确认，提高的不仅仅是自己的工作效率，还有团队整体的协作效率。从这个层面看，产品一人效率的提高还能带动团队效率的提升。
总结以上，尝试从五个维度来说明了如果提高产品的工作效率，希望能对大家有所启发。更重要的是自己在实际工作要不断的总结领悟，才能找到自己的高效率思维路径。但在追求效率的同时，也千万不要忽略对质量的要求。
本文由人人都是产品经理专栏作家 @刘鹏（pengideas ） 原创发布于人人都是产品经理 。未经许可，禁止转载。
