[singlepic id=34 w=320 h=240 mode=watermark float=right]不经意间听到的让我深思的一段对话。 甲：咦，这个功能是什么时候加的？ 乙：哦，我也不知道还有这个功能 丙：那是我加的 甲：需求是谁提的？ 丙：他们那天给我打了一个电话说需要这个功能
都说 ITSM 项目是非常难实施的项目，成功率低；特别是 CMDB 项目，实施难度大，失败案例比比皆是。首先我觉得 ITSM 项目的实施有它的特殊性，特殊在于实施顾问对客户需求的理解，在于实施顾问对 ITIL 最佳实践的经验，在于对产品工具的把握。其中任何一个环节拿捏不准都会到导致需求的泛滥、需求混乱、需求的飘忽不定。
可见需求管理是项目实施和执行的灵魂，失去了对灵魂的掌控，需求讨论会就将可能进入走火入魔的地步，需求各方争执不下，整个会议室炸开了锅，每个人都争抢着发言，我的脑也几乎要眩晕；我说的这一点也不夸张，没见过只能是你的幸运。
需求管理包括需求的分析和整理，应该是有层次的，在不同的层次里讲不同的语言，达成共识的讨论结果。层次可以分为这样三层
业务需求
用户需求
功能需求
所谓业务需求是说站在公司的高度，从最 high level 角度描述需求之所在。它的语言像是项目使命的宣言，指出为什么要做这个项目，项目的价值点落在哪里。最概况的项目范围。业务需求告诉我们：为什么会有这些需求。
用户需求是指从项目利益相关人的角度出发。逐一描述各个业务操作环节，这些业务操作由每个可独立执行的条目为单位，每个业务操作中说明业务规则、输入和结果。切忌在这一阶段就进入详细的功能界面或者功能操作上细节的任何讨论。原因很简单：我们在这里还没有进入技术实现环节，依然在以客户或者系统使用者的角度来描述它的需求。系统用户和客户是不需要理解每一个页面跳转和鼠标点击的意义的。在我的经验看来客户在这里最容易陷入技术细节讨论的泥沼，反而可能浪费需求讨论的时间，可能导致项目的延期，需求点难以确定。用户需求告诉我们：用户的需要什么。
功能需求则需要告诉我们：为了能满足用户需求，我们的系统是怎么做的。这里将用技术的语言，进入系统层面说明系统应该怎么做。功能需求最终将导出概要设计和详细设计。
业务需求的满足=用户需求的满足+功能需求的满足；用户需求是能推倒出功能需求的，用户需求和功能需求可以是一对一、一对多和多对多的关系。
以上三个需求是有层次的并与客户递进沟通的产物，既然是沟通，那么在每个层次上都伴随着矛盾、争论、妥协。在任一层次上理不出头绪时，一定要追溯到上一层，通过上一层来指导解决。但是这往往也是很难把握和执行的，最终最可能的结果是在以上三个沟通层次中都伴随着需求的变化、需求的扩大、需求的混乱。甚至于进入了测试阶段还能产生出新的需求和理解的偏差，谁人能不说“需求变更”是项目实施的鬼见愁呢？
如何解决这个“鬼见愁”？一方面需要时刻对项目预算和时间资源保持清醒的头脑，项目实施比较是那时间和金钱换需求。还有就是通过项目变更委员会来控制需求变更。