需求相关：需求管理如何管
----王珏原创
项目失败的一个重要因素是“需求没搞好”。但是如何搞好需求，却没有一个简单易行的办法，常见的观点有如下几种：
1、需求不够详尽，导致有大量的岐义，因此项目失败了。
问题是：多少页的需求规格说明书才够详细？需要多少人力，需要多少时间？项目组有足够的人力吗？项目组有称职的需求分析人员吗？有人愿意阅读这几百上千页的文档吗？如果需求发生变化，又需要化多少成本来维护这个“详尽的文档”
2、需求变化太多，需求跟踪没有做好，导致项目失败。
问题是：需求变化是必然的，是项目组必须面对而且不可回避的问题。
3、前期需求分析阶段太过充忙，需求分析不够，导致了...
问题是：需求分析阶段给足够的时间，就一定能够分析透彻吗？不会陷入需求分析泥潭吗（此处泥潭特指：分析进入到一定阶段，很难继续推进，整天无所事事，或者陷入毫无必要的所谓“需求讨论会”中）？
4、需求没有经过评审，或者评审不够严格，导致项目失败
问题是：评审人员一定是专家吗？他们一定能够称职的履行工作吗？如果没有大师级别的专家难道项目就不做了吗？
5、需求分析人员能力不够，导致...
问题是：到什么地方才能找到“合格的需求分析人员”。他们真的如他们吹嘘的那样“真正的合格”吗？
上面的这些问题基本上是所有项目组，以及需求管理人员必须面对的问题。下面我来说说我是如何处理这些问题的，给大家作为参考（教科书上的内容我就不重复了，它们一定说得比我好。我仅仅说说我在现实项目中如何处理这件事情）。
第一，需求必须要“层次化”。任何人很难同时处理超过7件事情（为什么是7，记得好像是那本数上所说，反正表示一个适当的数值而已），一个组织更加如此
（他们需要协调，远比一个个人更加难办。类比：士兵操练的招式非常简单，因为他们要集体作战；而武师的招式就要复杂的多了）。我一般要把需求分成三个层次
（《如何写好用例》一书同样非常强调用例的“层”），顶层需求一般就五个左右，是项目的方向性目标。中层需求大约二、三十个，低层需求不计。这个世上有无
数的需求规格说明书（或者用例文档）把“添加用户”和“统计报表”放到一个层次上。试想“添加用户”的开发可能不需要1人天，而“统计报表”可能半年都完
成不了，这能是一个层次的事情吗？
第二，需求必须要“条目化”。条目化的需求是为了需求跟踪，需求变更等工作。也只有条目化需求才能够跟踪，才谈得上需求变更。其实“用例”概念的引入正是为了解决这个问题。
第三，需求必须划分优先级。实际上2/8原则在需求管理中也是适用的，也就是说，用户大约80％需要，只和需求列表中的20％相关；需求列表中的80%可
能都是不那么重要的。不划分优先级，最后只能是眉毛胡子一把抓，丧失项目重点。在这里需要另外强调的是：只能大约20％的需求能够列为“高优先级”。我常
常看到的需求文档几乎80%的需求都是“高优先级”，这所谓的优先级划分几乎没有什么用。需求优先级非常非常的重要，在项目进度不能满足要求的时候必须要
舍弃低优先级的需求，同样在缺乏人手，缺乏各种资源的时候，首先需要调整的就是需求－－－放弃开发低优先级需求。
第四，需求必须有效区分“有争议需求”和“无争议需求”。在需求讨论过程中，经常会讨论的异常激烈，围绕一个问题讨论讨论就陷入泥潭，最后只能是浪费时间
不了了之。其实，而我在实际工作中发现，在绝大多数时候“无争议需求”才是真正需求，而“有争议需求”多半都是所谓的“影子需求”，表面上看似乎重要，其
实大有商量的余地。在实际处理“有争议需求”和“无争议需求”时候，完全可以采用“搁置争议，继续开发”，对外国际关系时候适用的准则，在这里依然适用。