咖友提问：接到需求后，应该考虑哪些？思路是怎样？

接到需求后，如果直接画图fw排版模板，就成了画图的了，应该如何考虑才能全面呢？生怕有遗漏的地方。

▍jory 环岛 推车手

各人有各人的工作习惯，各个团队之间也有各个团队的配合习惯，就这个问题我觉得是没有唯一性答案的，只有适用性答案的，适合你的才是最好的。

在这里分享一下我的工作流程，大家一起探讨一下。

第一步，与需求方进行沟通，主要是复述你接收到的需求，确保需求接收正确没有存在理解偏差。

第二步，我把它叫做清洗需求池，把接收到的需求进行清洗，分类出那些是已有替代功能完成了的，哪些是在之后的版本中有规划的了fw排版模板，哪些是与公司战略及产品目标不符合的需求，哪些是可以在这个版本加入的需求，同时评估需求的可行性、优先级、难易度。

第三步，将上述第二步的结果形成文档，并提交需求方，最好是自己亲自讲解，获取需求方的同意。

第四步，需求的具体分析，梳理逻辑关系，业务流程。

第五步，原型设计，输出PRD

第六步，开原型评审会，与UI、RD一同沟通需求及PRD，对会上的东西进行及时的补充和改进。

第七步，跟进UI设计稿，确认设计稿

第八步，协助RD开发，开始编辑测试文档（如果有测试，就协助测试完成，如果没有，就自行完成）

第九步，测试，验收产品

第十步，上线，交付产品

▍建君 味库 产品经理

我个人最怕的就是拿到需求立刻就开始流程和原型设计的，不经过思考的产出都是对产品的不负责任。简单描述我的工作流程：

1、需求确认

需求确认是非常重要的一个环节。这里的确认不是简单的明确或者理解了需求方提出的需求，而是要深入挖掘到他需求背后真正的“诉求”是什么。因为很多时候需求方提需求都是拍脑袋提出的，或者经过了自己的一次转化。

所以，我习惯让需求提出方用最简单粗暴的方式描述需求，不要经过修饰和转换。

2、需求分析

当你了解到需求方真实的需求后，那么轮到你开始对这些需求进行分析了。这些需求的意义、对现有功能的影响、实现的成本、优先级等等。

最后产出一个需求的列表，来作为和需求方沟通的一个指导，最后确定需求。

3、需求转化

确定了所有要做的需求后，才真正开始进入需求转化的阶段。画场景图、画用例图、画流程图、画原型图、写PRD等等，都是为了把需求转化成技术人员可读可理解的内容。然后交付给技术部门去实现。

4、需求实现

这部分的工作更偏向“项目管理”的工作，目的就是确保开发的进度和方向没有偏差，并正确的能够满足业务部门的需求。

前两步“思考层”是我对产品经理们要求最高的地方，后面两步“执行层”反而有制度和流程控制容易一些。所以，产品经理应该把更多的精力和投入放到前两步。个人浅见，供参考。

▍宁白衣 有间道观 观主

来源【写作训练营】自媒体，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！