咖友提问：接到需求后，应该考虑哪些？思路是怎样？
接到需求后，如果直接画图，就成了画图的了，应该如何考虑才能全面呢？生怕有遗漏的地方。
▍jory 环岛 推车手
各人有各人的工作习惯，各个团队之间也有各个团队的配合习惯，就这个问题我觉得是没有唯一性答案的，只有适用性答案的，适合你的才是最好的。
在这里分享一下我的工作流程，大家一起探讨一下。
第一步，与需求方进行沟通，主要是复述你接收到的需求，确保需求接收正确没有存在理解偏差。
第二步，我把它叫做清洗需求池，把接收到的需求进行清洗，分类出那些是已有替代功能完成了的，哪些是在之后的版本中有规划的了，哪些是与公司战略及产品目标不符合的需求，哪些是可以在这个版本加入的需求，同时评估需求的可行性、优先级、难易度。
第三步，将上述第二步的结果形成文档，并提交需求方，最好是自己亲自讲解，获取需求方的同意。
第四步，需求的具体分析，梳理逻辑关系，业务流程。
第五步，原型设计，输出PRD
第六步，开原型评审会，与UI、RD一同沟通需求及PRD，对会上的东西进行及时的补充和改进。
第七步，跟进UI设计稿，确认设计稿
第八步，协助RD开发，开始编辑测试文档（如果有测试，就协助测试完成，如果没有，就自行完成）
第九步，测试，验收产品
第十步，上线，交付产品
▍建君 味库 产品经理
我个人最怕的就是拿到需求立刻就开始流程和原型设计的，不经过思考的产出都是对产品的不负责任。简单描述我的工作流程：
1、需求确认
需求确认是非常重要的一个环节。这里的确认不是简单的明确或者理解了需求方提出的需求，而是要深入挖掘到他需求背后真正的“诉求”是什么。因为很多时候需求方提需求都是拍脑袋提出的，或者经过了自己的一次转化。
所以，我习惯让需求提出方用最简单粗暴的方式描述需求，不要经过修饰和转换。
2、需求分析
当你了解到需求方真实的需求后，那么轮到你开始对这些需求进行分析了。这些需求的意义、对现有功能的影响、实现的成本、优先级等等。
最后产出一个需求的列表，来作为和需求方沟通的一个指导，最后确定需求。
3、需求转化
确定了所有要做的需求后，才真正开始进入需求转化的阶段。画场景图、画用例图、画流程图、画原型图、写PRD等等，都是为了把需求转化成技术人员可读可理解的内容。然后交付给技术部门去实现。
4、需求实现
这部分的工作更偏向“项目管理”的工作，目的就是确保开发的进度和方向没有偏差，并正确的能够满足业务部门的需求。
前两步“思考层”是我对产品经理们要求最高的地方，后面两步“执行层”反而有制度和流程控制容易一些。所以，产品经理应该把更多的精力和投入放到前两步。个人浅见，供参考。
▍宁白衣 有间道观 观主
说下我对问题的理解吧，lz应该问的是接到需求后，如何高效、优质的从“想”进入到“做”？
我总结了七步：
一、要做什么——确保你理解需求本身，无关对错。
二、做给谁用——确保你理解假象用户，无关对错。
三、会有用吗——自我辨证假想需求和用户到对错。
四、精确需求——根据辨证结果去完善或调整需求。
五、自我否定——否定已确认需求，考虑最坏结果。
六、确定思路——八字真言:“轻重缓急快慢益损”。
（轻重：产品结构上的轻重；缓急：需求层面优先级；快慢：开发耗时长短；益损：烧钱得体验，还是损体验拿钱。要学会去判断这个功能对用户的重要性，才能更好的去设计和定位。我不否定体验和盈利共存，但是要赚钱，体验必然会受损，摸钱出去时，心情总是差的。。。）
七：细化需求——根据确定的思路，细化成功能点。
至于说对行业摸底啊，了解市场这些的，不都是产品经理的日常修养吗？
