需求一直做不完，怎么办？
做需求的目的，一句话来说：对用户产生价值，从而促进产品发展。
但是，这个价值有多大？需求本身是不是符合这个价值？
都是需要产品经理思考虑清楚，并能够说明白价值。
一：从哪些方面来思考需求
1. 从下面这些方面来思考需求价值：
- 这个需求是否符合当前产品的发展和规划？
- 这个需求用户群体大么？
- 这个需求用户使用多么？
- 功能上线后，对业务价值提升有多大？
也及是说，你这个需求，是要达成什么目标
2. 怎么衡量需求价值
如果需求做了上线后，从哪些方面看出来，做这个需求有价值？
比如用户点击率，使用频率，在线时长等等。
需要用用户数据来说明这个需求的价值。
3. 需求优先级
这个需求紧急程度，对产品重不重要。跟其他需求相比，这个需求紧急程度是多少？不做，对产品有多少影响？ 能不能放在下个版本来做？
4. 根据版本来做需求
前面说过，这个需求能不能放在下个版本来实现。要考虑的是，在下个版本实现，对用户会产生什么影响？
一开始时，产品经理就需要考虑这个问题。
根据公司目标，来规划版本，在不同版本中实现需求。当然，这个对产品经理规划能力要求很高，对业务了解很深，才能判断公司业务发展趋势，从而制定版本和相应的需求。
5. 需求技术实现任务分解
需求最后讨论下来，还是要实现，那么，把要实现的需求进行分解，分解为一个一个的小技术实现点，然后来规划实现的时间，实现需求开发。
6. 建立需求池
把一些当前没有资源开发的需求，或者不是紧急的需求，或者一些其他需求，都可以放入需求池。然后可以在二期或者后面的版本开发中加入进来进行开发。
二：如果需求不合理，怎么办？
有时候觉得需求不是很合理，那该怎么办，看看下面这几个方法
1. 用上面几点来看需求的价值
用上面几点来看看这个需求的价值有哪些，
对产品，对用户，对业务是否提供价值。
2. 了解一下需求的背景
可以向产品经理详细了解下需求的背景。
为什么要做这个需求？
最起码，产品经理要详细的说明这个需求产生的背景。
让开发了解这个需求，尽量消除彼此之间的误解。
3. 更透彻的理解需求
能不能更透彻深入的思考需求，从而把需求做的更合理。
讲一个故事：
100多年前，福特公司的创始人亨利·福特先生到处跑去问客户：“您需要一个什么样的更好的交通工具？”几乎所有人的答案都是：“我要一匹更快的马”。很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。
福特：“你为什么需要一匹更快的马？”
客户：“因为可以跑得更快！”
福特：“你为什么需要跑得更快？”
客户：“因为这样我就可以更早的到达目的地。”
福特：“所以，你要一匹更快的马的真正用意是？”
客户：“用更短的时间、更快地到达目的地！”
然后福特就发明了汽车，很好的满足了客户的需求。
这个可能是一个很好的满足了这个客户以及一群客户的需求。
**上面的故事不仅说明，一要深入理解用户需求，更重要的是：要有创新精神。这点更难做到**
4.评估和评审需求
按照正常的产品流程，需求评审是一定要的。
但是好多公司，其实是没有做到这点，基本就是产品经理或者领导提需求，技术开发，
评估和评审需求这个流程是略过。
因为一般公司都要求快速开发出来。至于开发出来后，效果怎么样？不清楚。一些用户数据有没有提升？也不知道。事前，这些都没有考虑清楚。事后，也没有用数据验证效果。更不会反思，检讨。
至于开发这些不合理需求所浪费掉的开发时间，开发的人力资源，都没关系；也没有人去检讨，也没有人担责，也很少复盘这些效果不好的需求，原因是什么，去总结经验教训，从而避免后面开发重复做同样的无用功。
他们只会要求你：加班，加班，加班，把需求做完。我想，这也是造成加班多的原因之一。
产品经理(或领导)不去深入思考用户需求，为了项目，提出一大堆自己也搞不清楚价值有多大的需求，然后让研发加班加点去实现这些需求，做出来之后，才会去验证这些需求合不合理。本来是产品经理该做的事情（要去深入思考需求价值点，不轻易让研发开发），转嫁给研发来做，加班加点把需求做完，做出来也不晓得效果咋样，从而导致研发时间浪费，人力资源的浪费，研发效率降低，等等问题。
只关心量，不关心质。明明质量是一个词。
做出来效果不好，接着，产品经理就要改需求，因为他想达到一个好的效果，然后，技术又加班加点开发，恶性循环。
或者竞争对手也做了一个功能，我们也得跟进同样的功能。不去深思这个功能后面的价值，对业务的贡献点在哪儿？
俗话说：++产品经理无能，累死三军(研发)++。
评估和评审
就是用集体的智慧，群策群力，找出价值更大的需求，确定开发优先级。
过滤掉不合理的需求，为开发节省时间。从而让研发能去开发更有价值的需求。提高研发的效率。提高研发贡献价值的效率。
三：硬要做需求怎么办
- 让领导去和对方沟通
- 让产品经理写好相应的需求文档，要完善的文档
- 做好分析，给出排期
- 如果有其他开发需求因此而耽搁，也要用邮件说清楚
【完】
