项目经验总结

用户需求就是能帮用户解决实际问题的一套解决方案。

在经历过多年的企业项目之后，发现项目中最大的风险来自于用户需求的变更。需求变更产生风险的最大原因在于未做好需求处理，所以在此希望和大家探讨下企业应用的需求处理。

先给大家举一个未处理好需求的例子：用户说要做一个实时监控的功能，要监控网络中实时发生的问题，等我们做完之后，用户才发现实时监控发生的问题数据量太大太多，根本看不过来，也不知道什么问题是重点，然后用户要求修改为监控统计数据，然后我们就又重新做了一遍。

沉思一下。。。。。。。。

需求处理中遇到的问题：
需求不断：用户往往今天说要这明天说要那，你不知道用户的需求何时是个尽头？也不知道应不应该满足客户提出的需求？
需求总变：你埋怨客户总是变更需求，用户说你是专业人士你应该能分析出我想要的，怎么一个需求搞这么久都搞不定呢？

所以需求处理人员需要具备：
1：对产品的理解以及对对产品功能的熟悉。
2：对项目的理解以及对项目范围和边界的把握。
3：站在比用户更高的层次思考需求，因此你必须具备用户的业务知识。
4：善于引导用户，我们做项目目的是为给客户带来价值，而不是满足客户的需求。
5：分析用户：用户是技术型，管理型还是饭桶型的，技术性的喜欢抓细节，管理型的喜欢抓整体，饭桶型提不出什么需求，都会说界面不好看。

需求处理人员必须得清楚：
1：用户描述需求时表述的那些话不一定是用户需求。
2：用户所说的需求不一定是用户想要的需求，描述和想象始终会存在差距。
3：谁是真正能拍板的用户。
4：需求的满足需要一个过程。
5：用户的需求基本都是拍脑门说出来的，很少是冥思苦想了很久。
6：大多数情况下，需求没有变，而是你没理解用户真正的需求。

需求分析的过程
将用户的所提出的需求，放到用户的业务场景中去分析，分析用户是想解决一个什么问题，是否能为用户带来价值。这个需求到时候是否能真正用起来，这需要考虑用户的组织结构，部门角色，用户的推动力。
此需求是否属于项目和产品范围之内，不是则不做。
确认需求之后，思考该需求是否会存在衍生需求，然后思考下是否能否那我们产品中已有的功能变相的来满足客户的需求。
如果确认需要开发，需要鉴定该需求我们是否能做，做多久，做初步的可行性分析。
需求处理
将分析出来的需求，同用户确认，有界面的最好用原型法，假如用户不和你确认（我遇到的大多数情况是这样的），你可以发一封邮件给用户，并说请您确认下需求，假如没有异议，我们后天就按照这个开始做了。不回你就表示用户默认了。

需求归类：该需求是项目需求还是产品需求，是否能产品化？划分到产品的哪一个版本里？