为什么还是做不好需求分析(如何做需求分析？)

如何做需求分析？

一是用户需求，挖掘用户的真实需求，看用户是想造航母还是渔船；

第二，产品本身的客观需求。目前市场上同类型的产品要进行比较和挖掘。比如市面上的产品都是渔船，那么客户的需求就会减少；

第三，比较用户和消费者是不现实的的时间、进度和预期结果跟自己的需求，比如客户只给了造船的钱，缺乏造航母的。

如何做需求分析？

我们每做一个项目迭代或者一个新项目，都要有一个目的。在需求分析阶段，需求收集渠道中的需求往往是分散的、无重点的、不符合逻辑的，我们需要从这些离散的需求点中抓住核心，梳理出实际使用场景来分析问题。所有的核心点都要面向最终目标，并不是所有的用户需求都是需求。

以我的项目为例。由于历史原因，自营配送员与员工的关系没有录入OA系统，所以配送员的工资结算数据只能做成配送系统，相当于简单的考勤记录。其实之前系统也有这个功能，但是因为之前没有仔细整理需求，这个功能做了也是白做，所以这次我接手了，差点就做了。我以为让一个产品助理先整理需求是比较简单的，但是当我画出原型的时候，发现并不能解决薪资结算的功能。

所以，当时我就跟小哥说，你刚交班，但是交班的目的是结算工资，可以 I don’我不能满足需求。所以我跟他强调，这个要求的目的是考勤，要提供请假、值班、加班小时、休息日加班等数据。其实他的第一个原型并没有完全理解我们为什么要做这个调度功能，所以在理解需求的过程中没有抓住核心点，导致需求不清晰。

2:制定规则，改进复杂的流程。

我上一家公司是做互联网电商的。其实在我看来，电子商务和O2O有一个很大的区别，就是电子商务在盛行的情况下已经变得非常有规律，比如首页、商品列表页、详情页、订购页等等。每个页面显示的信息也大不相同，O2O也不一样。一方面，O2O差不多13年才兴起，至今(15年)还没有一个标杆行业。另一方面，O2O与日常生活联系过于紧密，是一个非常复杂的业务流程。以上是to C产品的规则和流程，流程在to B产品中尤为明显。to B产品最经典的例子就是公司的后台系统。

无论是a to C产品还是a to B产品，都要考虑用户使用场景，PM需要把自己当成用户。只有充分考虑用户 我们能设计出满足用户需求的产品吗？;的需求。在这里，我们并不是一味的迎合用户。互联网用户都知道，一个业务不规范，很难用产品让用户满意，所以我们有必要制定规则或者不完全、流程复杂的优化。

规则。

让 让我们谈谈制定规则。其实统一规则有利有弊。比如滴滴打车订单被抢，优步打车订单被系统自动分配。滴滴可以改善司机 积极性和自主性，司机可以选择高价值订单，但这种做法也会影响用户体验。比如以后没有补贴，我只是一个起步价，有些司机不愿意接单，要等很久；优步打车制定了自动分配的规则，首先分配离乘客最近的闲置司机。如果他不 不接，他会被分配到下一个。我赢了。;不能说这是否能让用户满意。我只说这个规则简化了下单流程。司机和乘客只有两个选择，接还是不接，坐还是不坐。如果司机不 他不接。;我不知道下一个订单什么时候能等到，也不知道订单量有多大。虽然降低了司机之间的积极性和自主性，但是对用户来说体验还是不错的。

制定规则后，让 让我们谈谈改进流程。如我上面所说，这种流程简化在to B产品中尤为明显。很多人有一个观点，后台系统反正是自己人或者其他企业人员用的，没必要做得那么方便细致。其实优秀的PM在这方面总是能从头到尾的做完，因为在他们眼里，一点点的产品优化或者流程优化就能给企业带来很多收益，这点我是有切身体会的。

在我之前做过的很多项目中，有两个是我在做需求的时候，发现业务部门每天都在固定的思考或者重复做他的工作，但是他们没有 我发现它实际上效率很低。在没有人观察到流程有问题的时候，业务部门已经形成了一个规范，但是这个规范不是最优的。PM做需求分析的时候，需要仔细观察他们部门或者个人的工作内容，思考为什么要这样做，有没有其他的解决方案来提高其工作效率。

在做数据统计的时候，发现业务部门的一个同事需要导出所有的新增用户 、订单号、餐厅金额、订单金额等数据，每天考察配送员和用户的满意度。但是她每天导出的数据，其实也是另外两个同事需要的，只是目的不同，但是都很死板。他们三个每天导出一个完整的数据，然后筛选条件组合成自己的数据。这种工作其实没必要。我们可以每天为他们做这件事。

再比如财务在结算后勤人员工资的时候很多计算公式都是相互关联的，比如A=B C，D=A*E B-C，但是都是按照D=(B C)*E B-C来计算的，暂且不管他们的部门管理。如何管理流程，但是PM遇到这样的业务流程，就要考虑能否结合产品设计简化流程，实现产品设计的初衷，同时也简化流程。

3:离散需求整合

在和业务部门打交道的时候，我发现他们的思维逻辑可能有点差。当PM理解了需求，业务人员或者用户就没有了因果，也就是没有了逻辑。此时，如果PM不 不要问问题，很容易被坑。合格的PM在这种情况下应该转过身来，再次说明问题。如果遇到稍微强势一点的PM，要指出刚才的说法是错误的。

也有业务部门的人，在你沟通的时候谈了很多产品改进意见或者新的需求想法。这时候PM要认真听，记录需求点，千万不要给他们这个功能什么时候做，什么时候上线的答案，因为系统永远是不完善的，需求永远是无止境的，资源是有限的，所以你给的答案可以 不要意识到别人 糟糕的观点。一个优秀的PM需要大局观，能够和团队一起评估需求。

4:技术人员参与需求分析阶段。

现在很多互联网公司基本都是产品驱动，所以it 很难说它们是技术驱动的，因为产品团队可以知道用户想要什么。在我参与需求分析的时候，事业部的技术总监喜欢跟着我去了解需求，这是我之前的工作组从来没有遇到过的。现在他参与需求的时候，我发现整个产品需求是混乱的，阻碍了我需求分析的进度，因为他总是从技术角度考虑实现这个的难度。因为他是技术总监，有很强的逻辑思维能力，所以每当听到不需要添加一个条目来维护这个数据的时候，他就会站出来说为什么要这么做，然后说服业务部门这个数据不能提供，那他能不能先不做？

但是从产品的角度来说，既然选择做这个项目，就要从产品的角度来设计。在一个完整的产品方案出来后，对功能进行精简是一个很好的方法。在某些情况下，当一个更好的想法产生时，技术人员会首先考虑它是否能实现以及实现的复杂程度。如果有一定难度或者现场无法给出技术上可行的方案，这个功能就暂时搁置，也许会提出另一个没有错但不是最优的方案，于是技术人员参与需求。综上，我的理解是技术人员暂时不要参与需求分析阶段，技术团队在产品团队内部讨论后再参与评审，可能会达到事半功倍的效果。

需求 用户 产品 流程 PM

版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。