项目启动之前，往往有一段较长的时间用作来讨论和评审需求。
开发、产品、运营等各方都是重要的参与者。
需求的核心人物其实还是产品经理（PD），PD负责需求文档的编写和业务流程的定义，运营人员的需求不能直接提给开发，而是通过PD进行分析和过滤。这样三个不同的利益集团（姑且就用这个词吧），很容易会在需求相关的讨论会议上发生激烈的争执，这样的争执，通常有两种结果：
一是达成共识，二是没有下文。在实际项目中，第一种情况几乎是不会发生的，或者说，需要反反复复讨价还价才可能在一定程度上达到。
开发人员由于不熟悉具体市场和业务场景，常常不能理解PD的需求本身的一些内在的含义，从而会认为需求不合理，而运营以及一些不懂技术的PD，经常又会给开发提很多技术上不可行的需求。
三方人员各自看问题的角度不一样，思考问题的思路也不一样，导致需求评审变成了冗长而拖沓的灾难，往往很多业务流程的分析、功能点的讨论等更加重要内容没有讨论到。大家都在纠结和争执那些热点问题。这是很不好的现象，而且还很危险。项目后期，那些隐藏的业务点可能会突然集中爆发出来，导致项目出现难以把控的风险。
这些问题的一个很重要的根源在于，三方并没有形成一个讨论的基础，大家往往凭自己的经验和喜好来干涉需求的设计，主观因素非常强，缺乏有力的论据来支撑自己的观点，谁也说服不了谁。如果需求搭配有客观公正的数据或者市场调查报告等资料，讨论往往会比较顺利，纠结的地方也会减少。
由此，总结出这样几个规律：
1，需求方的需求，最好是有论据支撑的。没有这些论据，大家是很难找到一个共同的讨论基础。
2，讨论和评审过程中，尽量不要参合过多的主观因素。
3，最好依据需求文档单独整理出一份词汇表，很多时候大家讨论的时候词汇不统一，很容易出现偏差和误会。
4，项目经理在评审前将开发人员的开发功能模块工作分配好，详细的需求由PD和开发进行一对一的确认。毕竟需求讨论会议不可能完全涵盖所有的业务点。此过程中若遇到问题，则应往上抛，抛给项目经理，集中进行处理。当然，这一点对项目经理的要求就比较高了，具体情况具体对待。
