[singlepic id=4 w=320 h=240 mode=watermark float=right]今天终于移师厦门开发中心，这意味着我所经历的史上最长 CMDB 需求分析基本告一阶段，也意味着 CMDB 的构建、集成、定制和 测试工作也徐徐拉开了大幕。

回忆前三个月所做的的需求分析工作，虽然各项调研和讨论工作进行的缓慢，不过细致的工作最终还是换回了令人满意的成果，起码我是这么认为。

需求分析的过程是对需求的重新整理、重新定义和梳理。项目的立项并不意味着项目目标树立的精准，项目范围控制的合理。实际需求可以在实施的初期阶段来重定义，从新分析，着觉得不是浪费时间。而且这一点对于中国用户至关重要。国内很多项目都是资金或者预算驱动的，先有需求，通过需求推到出项目的价值，在通过项目的投资回报率申报项目预算的过程在国内是很少见得。国内的项目往往是有多少钱需要花，那么大家在来看，如何把需求花到极致，达到最大的产出。这也是很多需求分析做的贪多、贪大、求全的根源，这样做的好处是在一个项目周期内就把需求实现的尽善尽美（愿望是这样），坏处是：可能导致厂商和服务商的服务成本超支，从而造成的项目质量降低，从用户角度来说一次性接受一大堆的系统功能，负担重，接受度低，同时客户满意度低，项目满意度差。

我认为较好的最佳实践还要抓项目的主要目标，抓需要实现的主要价值点，抓重点放弃那些可做可不做的功能。懂得放弃的人才懂得获得。把所有的功能需求做成能够分批、分期上线的成果；确保让系统用户能 buy in 每一个阶段性成果，不要奢望给用户带来革命性的提高，由于那样也意味着，你对他们当前工作方式的影响是巨大的，没有用户愿意接受巨变。

需求分析时，从技术上讲，对会议组织人要求很高。需要此人能非常熟悉 CMDB 项目实施的方法论，需要此人能够非常熟悉产品的各个功能点，需要引导有效的需求分析会议。在白板上尽可能多的画图，用 Visio 或者 ppt 等工具尽量多的讲解各种架构图、功能图、流程图具有事半功倍的效果。不管会议上您可能收到怎样的抱怨、抵制、反对；stakeholder 的反馈将是你最宝贵的收获。没有互动和反馈的需求分析会是相当无聊和浪费时间的。切忌在大型的企业中，要慎重地计划每一次需求分析会，理由也很简单，企业组织越大，沟通的成本也越高。需求分析沟通的效率和成功完全取决于 CMDB 项目执行的方法论，取决于分析引导人的各种项目背景经验，还取决于对客户状况了解和上手的速度。