本文从（中小型）公司管理和产品经理自身能力两个维度出发，探讨如何提高整个产品研发过程中的效量。效量是我自己编造的词汇，意思是效率+质量。

产品研发效量低，都是产品经理的锅？

很多中小型互联网公司的老板可能都在为自家产品发愁，没有BATJ的自有海量流量，没有可视为粪土的雄厚资金，更没有资深的技术储备。唯一的出路仿佛只有让自己公司的产品一鸣惊人，才能在互联网红海中杀出一块立足之地。

这种期望不言而喻，重重地落在产品经理的头上，老板们期望产品经理可以妙手回春，创造奇迹。倘若没有达到这种期望，就都是产品经理的失职，是ta个人能力不足导致的。然而产品不理想，真的跟公司管理无关么？

模糊的岗位定义和权责边界：你的事是我的，我的事是你的，这件事是谁的！？

老板或领导对产品经理岗位和权责没有清晰的定义。很多老板或领导甚至把这个管理的漏洞，看成是筛选员工积极性的一种方法。然而，失去清晰的岗位定义和权责边界，导致的是部分工作冲突不断，部分工作无人问津。

我们从体育比赛中，有时可以找到相似的例子。比如羽毛球的双打，若没有事先规定好各自负责接球的范围，在球进入一个暧昧的区间时，两个队员就会犹豫，是自己接球还是对方接球，倘若是自己接球，若对方也同样的想法，会不会撞到一起，误伤队友？最可能的结果就是，要么相互伤害，要么都撒手不管。

中小型公司中，往往都是老板或领导驱动需求。老板或领导想到一个idea又着急实现的时候，可能会直接抓来设计师，让ta设计产品新界面，又可能会直接抓来研发人员，让ta增加新功能，顺便再出一份功能文档。

久而久之，老板或领导几乎替代了产品经理，设计师和研发人员的权责也逐渐与产品经理的重叠，导致产品经理不确定自己哪些该做，哪些不该做，哪些做了也白费力气。而老板或领导跨过产品经理，直传圣旨，也让产品功能变得七零八碎，需求的跟踪与追溯变得难上加难。

岗位定义和权责边界模糊，等于公司对员工的要求与目标的模糊，这从根本上动摇了员工对自己工作价值的感受，和对自己发展方向的判断。此种环境下，必然无法激发出员工自身真正的价值，导致老板或领导自己总是感觉无法找到优秀的人才。

混乱的项目管理：在追求快的道路上越来越野！

“天下武功，唯快不破“ 这句话放在互联网行业仿佛也通用。快速的敏捷开发，可以让公司迅速收到用户反馈，进而更新产品，以最短时间适应市场环境。对中小型互联网公司来说，迭代产品的频率就是与竞争对手竞赛的步频，步频越高，好像在市场的竞赛中胜出可能就越大。

然而，有些中小型互联网公司过度追求迭代频率，完全忽视构过程中的项目管理，导致整个产品匆忙赶工而成，漏洞百出且无法追溯，一片混乱下员工也备受折磨。

首先，在项目开始之前，没有明确负责人的任务，会造成遇到需要配合时，出现相互推诿的情况。本人亲历过一次官网的改版项目，虽然指派了提供文案的运营人员，但每次找到运营人员，要求提供官网新文案的时候，运营人员都会以产品框架未出，拒绝提供。拖了3天，直到运营总监发现文案迟迟未出，才与该运营人员说明，产品框架需要配合文案的核心方向来做，必须先出文案，此任务才得以推进。

其次，没有明确最终决策人，会造成项目的停滞与拖延。还是举刚才同样的项目为例子，官网设计到公司对外的整体形象，应该是公司老板最后拍板，但老板自己却先推给研发和运营各组负责人，让他们定夺，而后在产品成型后，老板又觉得不符合自己的预期，突然查收要求修改，导致工期前前后后被耽误4、5天。

老板或领导需要明白，在项目开始前，确定好最后拍板的决策人非常重要。也一定要考虑到自己在该项目中的位置。否则就会出现一些鸡毛蒜皮的小问题，会找到老板和领导决策，而一些大问题却因自己撒手不管，而无法把控。

再次，忽视产品开发的科学过程。产品需求的评审在大公司已经是固定流程了，而在中小公司，很多老板或领导觉得评审这一步是浪费时间，还不如快速把产品推到市场，求得市场反馈。然而实际上是，一些荒谬的需求，只要经过不到半天的推理考量就可以剔除不做，整个过程所需的人力成本、时间成本和机会成本要远远小于把需求开发成产品功能，再收集用户反馈，才确定删除该需求的各项成本。匆匆忙忙地投入研发与实现，会远远增加产品的成本与风险。

拒绝暂停，拒绝反思：忙忙忙，看起来越忙越好！

中小型企业可能因为资金的不充裕，导致对员工的评判标准都倾向于过程，而不是结果。老板们希望自己付出的每一分工资，都能在员工的忙碌程度上有所体现。他们希望看到员工8小时中的每一分每一秒都在执行项目，“我不希望看到你们闲着”大概是很多中小型企业员工会听到的一句话。

然而真的是员工越忙越好么？我们在上学的时候，可能对此深有体会，有时候自己花了大量时间，做了成百上千道题，却收效甚微。有时候只是停下来，认真思考了几道典型的题目，却收获颇丰。当公司或领导，过于重视员工肉体的忙碌程度，而不愿意给员工和自己的大脑一些时间用来思考与反思，那么真个团队都会困在项目赶项目，无限的低效忙碌循环上。

通过这几年工作中的观察，我发现，很多忙碌是相当无效的。比如之前提到的，先出成品再判断需求价值的情况，或者渠道上线的版本总是搞错，只能下架，重新等待审批，等等情况。这些无效的劳动，本都应该可以通过规范工作流程避免的。但是因为老板或领导们不愿意自己和员工停下来，花时间反思总结项目的经验，进而优化项目流程与管理，导致今后的每一个项目都陷于毫无价值的问题的泥沼。

提高产品研发效量，产品经理个人又能做什么？

之前翻译的HBR文章提到，产品经理需要找到能让自己发光发热的地方。倘若公司管理一直混乱，没有进步，产品经理们就应该考虑离开了。而不想或无法离开的话，作为项目的一个成员，如何提高自己的效量呢？

不重复造轮子

产品经理要懂得及时把可复用的功能或者布局积累起来，化成Axure部件库也好，化成文档也好。总之，在类似的项目上，有些小的功能组件不需要重复再思考，直接拿来复用就好。虽然汇总的时候会花一些时间，但从长远来看，这是提高效量的好办法。

我在本文最后提供了我自己整理的文件夹、文档和原型模板。当然这些模板并不是最完美的，我自己也在慢慢打磨这个模板，放出来也只是给大家做个参考，整理出适合自己现有业务的模板。

管理好自己的资源池

行业和岗位相关资料的收集管理是任何职位的人都需要做的，并不是新鲜的理念。网上有很多关于资料管理的优秀文章可以借鉴。我在这里只简要提一下自己的经验。随着工作经验的增加，资料几乎会成几何倍增加，这就要求个人定期，至多半个月一次，用tag或文件夹整理自己的资料，否则当你查找文件资料的时候会变得跟在百度上搜索一样艰难，更不要提效率了。

花时间练习写作与口头表达

本人在工作中注意到，沟通上产生的误会，经常会对项目进度造成干扰。而产品经理最重要的工作内容之一就是沟通，跨部门的沟通。为了确保自己的想法能够快速又准确地传达给对方，产品经理应该多在工作之余，看一些写作或演讲的书籍，如《麦肯锡叫我的写作武器》、《结构性思维：让思考和表达像搭积木一样有序省力》等类似的书籍。尤其是一些不善言辞的产品经理，更是必须要克服此问题才行。

以上就是我在产品工作当中，关于提高效量的一些思考。由于经验的局限性，很多观点可能有所偏颇。还希望同行们多多指点。

模板链接：https://pan.baidu.com/s/1i7ajWWl 密码：oi11

作者：Tina Ruan，3年+软件需求分析 3年+产品经理

本文由 @Tina Ruan 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议