项目启动之前,往往有一段较长的时间用作来讨论和评审需求。

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