需求分析需要会什么 如何做需求分析？

需求分析人员应具备哪些技能？

1、公文写作能力，包括word、ppt等。

2.我将使用建模工具来绘制相应的UML图。

3.逻辑分析能力

4、必须非常熟悉相关业务。

如何做需求分析？

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

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

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

如何做需求分析？

1:抓住了核心点，不是所有的用户需求都是需求。

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

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

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

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

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

不管是to C的产品还是to B的产品，都要考虑用户 的使用场景。PM需要把自己当成用户，充分考虑用户 在各种情况下思考，设计出满足用户需求的产品。;的需求。在这里，我们并不是一味的迎合用户。互联网用户都知道，一个业务不规范，很难用产品满足用户，所以我们有必要制定规则，或者说优化不完善，很复杂。

规则。

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

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

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

做数据统计的时候，发现业务部门的一个同事要导出所有的新增用户 号码，订单号，餐厅金额，订单金额等数据每天调查配送员和用户的满意度。但是她每天导出的数据，其实也是另外两个同事在用，只是目的不同，但都很死板。他们三个每天导出一个完整的数据，然后筛选条件和分组。其实没必要去合成我们想要的数据。我们可以向他们的部门发送每日订单报告，并标记新用户。

又如，财务部门在结算后勤人员工资时，很多计算公式是相互关联的。比如A=B C，D=A*E B-C，但是计算出来是D =(B C)* E B-C . L:离散需求整合

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

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

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

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

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

需求 用户 产品 流程 数据

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