很多时候对于新到手的需求，很多人都是被客户或者二领导牵着鼻子走，全盘接受，尤其是当快速迭代的时候，需求太多，完全没有时间来进行全部认真分析，这个时候就需要有个标准能让自己快熟决定这个需求是刚需还是优化项，或者是没必要改。

需求分析的好处省事高效率有利于团队合作有利于判断产品真正的方向，作出成功的产品不会被动接受，而是主动出击需求填坑注意事项   很多时候，对于新需求，大多是经过评审后直接就开始落实了，这样其实是不正确的。评审过程中参与者的角度都是各自不同的，比如客服说，为了方便客服统计数据，需要把用户主页上加一些详细信息，这个时候他其实是在考虑他自己方便的角度说的，但其实这些详细信息对于用户来说只是冗数据，没有加的必要，还要增加开发人员的工作量，造成开发人员不满，得不偿失考虑需求的时候要分清楚类型，是优化？改版？还是新产品。对于不同类型的需求需要采取不同的分析方法，下面再重点说对于对接人一定要明确。所谓对接人，就是需要确认你细化需求的人，只有对接人确认过了，这个功能才能开始交给开发来做，其实需求分析师本身并没有那么大的权利。这个对接人有可能是产品经理，有可能是客户甲方的人，这个要提前确认到底是谁说了算，一定要对接人签字确认才可以设计开发，不然后患无穷客户加需求，不能全盘肯定。如果是有必要，而且很容易实现就加上；如果不容易实现或者实现起来很复杂容易乱套，就言明说需要讨论确认后再给出反馈，是改还是不改，还是作为下一期的优化这种项目填坑的事情很多，总是说不过来的，日后有想到的再给大家补充需求分析方法分类阐述新项目／改版需求分析

1.接到需求后需要了解第一手信息

包括这个项目是做什么的？相关资料都有什么？是改版还是行业类的新产品？有哪些竞品？是否进行过竞品分析？了解到的数据资料都有什么？这个项目的需求，开发，管理各个方面的对接人都是谁？用户群有哪些？预算有哪些？产品目标是怎样的？这些一系列问题都是需要在做需求分析前就要掌握的

包括这个项目是做什么的？相关资料都有什么？是改版还是行业类的新产品？有哪些竞品？是否进行过竞品分析？了解到的数据资料都有什么？这个项目的需求，开发，管理各个方面的对接人都是谁？用户群有哪些？预算有哪些？产品目标是怎样的？这些一系列问题都是需要在做需求分析前就要掌握的

2. 分析用户角色

考虑产品的使用者都有哪些受众，产品需要针对那一类人作为定位，产品定位是判断需求是否要做的重要依据

3. 分析产品目标和用户目标都有哪些

产品目标和用户目标往往是会或多或少有冲突的。用户考虑便利，产品考虑盈利。我个人角度还是觉得要以产品目标为重，用户目标可以用别的方法去弥补

4. 当二者发生冲突时，优先并依次考虑产品定位，利益项，及成本

比如说用户喜欢一个功能，如果这个功能做了，用户会很喜欢用，但是这个功能与产品定位无关甚至会偏离产品定位，或者预算不允许，加了用户喜欢用，但是不加也不会造成什么不好的影响，那就不要加，不要盲目考虑用户

5. 然后是用户角色，围绕用户角色考虑功能设计，分别针对某一类用户，围绕场景考虑功能设计

场景是一定要考虑全面的，这样可以排除很多不必要的想象

6. 穿线，模拟整个流程，跑通流程的基础上细化一部分功能

在穿线的过程中会出现很多问题，连起来就会发现哪些功能并没有实现闭环，需要调整的

7. 再细化，考虑原型时，针对某一细节和特殊情况进行考虑

特殊情况一定要做考虑，做好了会赢得口碑，没考虑到，有可能会直接损失用户

8. 基本流程和特殊情况都考虑好了之后，考虑是否解决了根本问题，再考虑用户体验的优化，如何去优化

最后考虑用户体验优化。标准就是，“先要可用，再要易用”这才是精髓，而不是盲目追求美观

9. 考虑方案的时候不要只考虑一种，比如说一个需求，也要考虑两到三种解决方案，这样才不会先入为主，影响判断

先入为主的思想会影响很大一部分的需求分析师，比如说一个功能，只考虑了一种方案，那么当开会研讨的时候，大家的发言就会让你觉得你的狭隘，但是你因为脑子里已经先入了这种方案，考虑别的方案时就会欠缺考虑，建议跳出这个圈子再看

优化需求分析

1.开会探讨时不要急着确定需求

要确认以下几个方面：

这个需求目的是什么，为什么要提出这个需求有没有必要做这个需求要解决用户什么样的问题，有没有别的办法能更好的解决这个问题衡量方案怎么实现会更加合适

2. 反馈给需求对接人，要改还是不要改，为什么

3. 改的方案细化的时候要做多份方案，然后考虑各自的优缺点，给对接人确认

4. 确认好了就可以交给开发来实现了

总结方法有可能不是适合每一个人，但是思想方向是对的，找到真正适合自己的方法才最重要对于界面美观的问题，建议不要最后一起做改版，会出现很多流程上的大问题，建议做细化的时候就带着美工来调整页面，最后发版上线的时候只做风格和细节的微调交互设计的本质，是解决问题一定要考虑好需求和功能的关系，需求不是功能，不能全盘接受坚持目标导向的方式才能做出好产品

文章作者系 @雨夜听风 未经许可，禁止转载。

本文章地址http://www.vzeo.com/news/xuetang/800257.html 由   友站网 编辑整理，转载请注明出处