CMDB需求分析之最佳实践

Reading time ~1 minute

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

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

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

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

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

互联网规模的超融合平台

什么是互联网规模?什么是web scale风格?看下Nutanix的亮点。 阅读全文

2017DevOps采用和趋势现状-信息图

Published on February 11, 2017