需求管理/方案设计与需求评审，如何将零散的工作整理整理得井井有条？这篇文章给了我们作者的思考，希望对你有所帮助。
高效完成工作，准点回家，能有更多的时间陪伴家人及自我提升，是我向来非常希望实现的工作状态。
无奈长期以来自己的各种无意识的习惯一直起主导作用，自己被推着走，始终没下狠心做出改变。
近来随着工作的越发繁忙，工作、身体、生活趋于恶性循环，对于工作效率提升的紧迫感越发强烈。
这篇文章期望通过梳理回顾自己的产品日常工作，整理出工作流程及重点，找到并优化那些可能有坑的地方，达到高效工作的目的。
产品经理最为日常的工作，可以分为：需求管理、方案设计及原型产出、需求评审、研发及测试跟进。
一、需求管理
1.内容管理
产品主动进行的用户调研及需求采集
产品主动根据线上产品表现（数据分析、用户行为等）提出的优化或新功能
产品被动接受的外部需求
2.优先级和重要性管理
之所以要管理需求的优先级和重要性，最直接的原因是：研发资源是有限的，而需求是无限的。除此之外，无序地堆砌需求，毫无目的和定位，只会导致产品最终臃肿不堪。
基于以上的基本情况，我想到的可以优化的点包括：
1.专门的用户调研及需求采集是比较费时间的。在版本定期紧凑迭代的情况下，产品很可能没有整块、足够的时间用于用户调研，而通过临时拍脑袋、臆想用户可能的场景来设计产品，最终的方案很大可能不能有效解决用户的痛点。
我想到的方案是，用户调研的时间分散到平时，而不是等到需要出需求的时候。比如：
跟进线上问题的时候，除了了解用户出现问题的场景，也可以借机了解用户使用相关功能的场景、心得、评价、痛点.。
线上问题要及时地记录，并定期整理分析，可以集中发现问题及待优化点。
提前一个版本发放下一个版本所需的用户调研问卷，提前收集用户意见。能这样做的前提是产品对下一版本的规划已经有了初步思考。
2.数据分析和用户行为分析，工作也要花在平时。比如每周定时监控和分析线上数据情况。针对发现的问题，可以抽至少一位用户聊一聊，或者观察他对某些功能的实际操作场景，也可以借此验证行为数据是否正确。
3.对于外部对接的需求，比较耗费时间的是需求内容的反复沟通和确认、需求变更的风险把控、技术方案的沟通、双方研发资源及配合时间的协调等等。对接得不好，不单只浪费产品的时间，也浪费研发的时间，甚至影响整个团队的产出。
个人感觉，外部对接需求，更多地要运用到项目管理的智慧。项目管理的核心是把控风险，协调资源，按时按质交付。在外部对接需求上，风险体现在需求内容的变更、研发资源的变更、配合时间的变更。
产品在这几个关键节点上尤其要注意把控：
对方产出明确的原型和需求文档后，才开始分配时间和资源对接，不接受“一句话需求”。
需求内容和细节都对接清楚后，双方通过邮件明确双方配合的时间、对接人、版本等。
人算不如天算，对接得再清楚也有可能有变数，比如上线时间调整、研发资源调整等。
如果是外部的需求方调整，我方的应对策略可以有：
A.注意几个关键时间节点的确认。我方需求评审前、我方技术方案评审前、我方研发开始前，注意跟对方确认可能的变数，减少我方的被动情况。
B.在一开始需求对接时，即跟对方明确，如果对方需求变更，我方的惩戒措施。
如后续的需求优先级自动降级、版本延后处理等，通过明确犯错成本让对方重视对接。
C.万一遇到开发开始后的需求变更：
a.如果只是开发前期，迅速补充其他备用需求，协调研发和测试重新评审和排期。减少研发资源的无端浪费。
b.如果到了开发的中后期，除了启动惩罚措施，似乎只能认栽。
如是我方的研发资源和上线时间有调整，则尽可能提前周知对接方，减少对方的资源浪费，让对方及时调整版本和排期。
外部对接一个总的原则是：细节前期明确，风险前期暴露，节约的是双方的资源和时间。
二、方案设计及原型产出
1.准备工作
方案设计的前提是，用户调研已整体完成、数据分析结果有了明确指向、外部需求内容已经确定。
但在设计方案的时候，依然会涉及到一些不确定因素，比如技术实现可能性、技术实现最优方案等。这个时候，一定要明确自己产品设计的初衷，以及要解决的问题，确保自己是了解用户的使用场景的。然后才在完成产品方案初步框架后，找相应的技术负责人咨询确认可能性，避免走弯路。
这里要注意的是：一定要找对技术全局和细节都足够了解的人，不然一定是更多的弯路。
2.流程梳理
原型产出前，需先进行所有流程细节的梳理，流程的梳理一定是减少返工和遗漏的重要环节。
3.交互参考
对一个功能的实现，可能有很多种交互方案。如何让自己的设计的方案不至于怪异而不符合潮流，可以充分参考市面上已有的交互设计。
如果平时喜欢研究并总结各类产品交互，这个时候就能省下些时间。如果想法不够，找寻对比知名产品的交互方案必不可少。
建议在参考别人前有自己的初步想法，且自己要的效果应该是明确的，不然有可能挑花眼、被带偏，白白浪费时间。
4.模板积累
平时注意积累出自己的一套标准的原型模板，包括框架、图文排布、元素等等，方便快速产出。
从评审听众的分类看，需求审批的种类包括：业务方评审，产品内部评审、需求终审（含产品、研发、测试、UI、UE）、技术方案评审、测试用例评审。
不同的评审，产品的侧重点不同：
产品内部评审，注意将自己的疑惑点、特殊场景抛出来，征求同伴的意见。
需求终审，确保自己对流程、细节已经完全把握，注意记录争议点，会后重新讨论设计，注意把控评审时间、评审节奏和评审氛围。
技术方案评审，研发是主角，其次是测试，最后才是产品。产品注意确认研发伙伴对需求的理解正确，以及对需求有疑问的地方。
测试用例评审，测试是主角，其次是研发，最后才是产品。产品确认测试用例覆盖了产品所有的需求点，还有极限情况和特殊情况。
一轮又一轮的评审，其实是非常占用时间的。评审开始前，产品最好对可能出现的争议点有预估，方便把控评审节奏和评审时间。
别人主导的评审，如技术方案和测试用例评审，产品如果提前拿到了文档，可以提前审阅，对于有疑议的地方记录下来，在会上重点讨论；这样一来，会议期间也可以处理一些其他琐事，不至于完全被占用。
四、研发及测试跟进
研发阶段，主角是研发，产品主要确认需求不明确或有争议的地方。
测试阶段，主角是测试，产品及时处理指向自己的BUG。在第二轮测试完成后介入验收，尽早发现问题。
研发和测试阶段，产品可以花更多时间在下个版本的产品调研、方案设计。
总的来说，提高产品经理工作效率的方法：
产品心中一定要有一个明确的工作主流程。
明确每个阶段（每个版本、项目每个阶段、每月、每周、每天）的工作重点。
在各个阶段见缝插入琐事处理（如线上问题跟进、需求细节等）和常规工作（数据分析、用户调研等）。
减少重复沟通、确认环节，准备充分，风险前置。
注意预估和总结每种工作内容的工作时长，能更好规划自己的工作时间。
平时注意积累产品文档、产品交互、产品方法。
