Tag Archives: project management
项目实施之鬼见愁@需求变更@
不经意间听到的让我深思的一段对话。 甲：咦，这个功能是什么时候加的？ 乙：哦，我也不知道还有这个功能 丙：那是我加的 甲：需求是谁提的？ 丙：他们那天给我打了一个电话说需要这个功能 都说ITSM项目是非常难实施的项目，成功率低；特别是CMDB项目，实施难度大，失败案例比比皆是。首先我觉得ITSM项目的实施有它的特殊性，特殊在于实施顾问对客户需求的理解，在于实施顾问对ITIL最佳实践的经验，在于对产品工具的把握。其中任何一个环节拿捏不准都会到导致需求的泛滥、需求混乱、需求的飘忽不定。 可见需求管理是项目实施和执行的灵魂，失去了对灵魂的掌控，需求讨论会就将可能进入走火入魔的地步，需求各方争执不下，整个会议室炸开了锅，每个人都争抢着发言，我的脑也几乎要眩晕；我说的这一点也不夸张，没见过只能是你的幸运。 需求管理包括需求的分析和整理，应该是有层次的，在不同的层次里讲不同的语言，达成共识的讨论结果。层次可以分为这样三层 业务需求 用户需求 功能需求 所谓业务需求是说站在公司的高度，从最high level角度描述需求之所在。它的语言像是项目使命的宣言，指出为什么要做这个项目，项目的价值点落在哪里。最概况的项目范围。业务需求告诉我们：为什么会有这些需求。 用户需求是指从项目利益相关人的角度出发。逐一描述各个业务操作环节，这些业务操作由每个可独立执行的条目为单位，每个业务操作中说明业务规则、输入和结果。切忌在这一阶段就进入详细的功能界面或者功能操作上细节的任何讨论。原因很简单：我们在这里还没有进入技术实现环节，依然在以客户或者系统使用者的角度来描述它的需求。系统用户和客户是不需要理解每一个页面跳转和鼠标点击的意义的。在我的经验看来客户在这里最容易陷入技术细节讨论的泥沼，反而可能浪费需求讨论的时间，可能导致项目的延期，需求点难以确定。用户需求告诉我们：用户的需要什么。 功能需求则需要告诉我们：为了能满足用户需求，我们的系统是怎么做的。这里将用技术的语言，进入系统层面说明系统应该怎么做。功能需求最终将导出概要设计和详细设计。 业务需求的满足=用户需求的满足+功能需求的满足；用户需求是能推倒出功能需求的，用户需求和功能需求可以是一对一、一对多和多对多的关系。 以上三个需求是有层次的并与客户递进沟通的产物，既然是沟通，那么在每个层次上都伴随着矛盾、争论、妥协。在任一层次上理不出头绪时，一定要追溯到上一层，通过上一层来指导解决。但是这往往也是很难把握和执行的，最终最可能的结果是在以上三个沟通层次中都伴随着需求的变化、需求的扩大、需求的混乱。甚至于进入了测试阶段还能产生出新的需求和理解的偏差，谁人能不说“需求变更”是项目实施的鬼见愁呢？ 如何解决这个“鬼见愁”？一方面需要时刻对项目预算和时间资源保持清醒的头脑，项目实施比较是那时间和金钱换需求。还有就是通过项目变更委员会来控制需求变更。
掀起CMDB的盖头来
今天是项目计划提交后的第二天，客户方项目经理对项目的推迟表示感到非常吃惊，期望能让我们给出一个合理的解释。其实这也同样的超出了我的预料，难道软件项目管理和运作都是所谓的人月神话么？ 在我看来CMDB项目的实施和运作有是有可能分阶段、逐步地交付项目成果的。简单的来说首先交付的当然是CMDB和配套发现工具系统本身，丑媳妇不要怕见公婆，把这个不加粉饰的原型系统拿出来，让项目各方包括最终用户来试用和评估。接着按照CMDB配置数据的来源的不同，把数据顺序的导入CMDB，并且开展数据的调和工作，完成基础数据的初始化。在基础数据的基础上，需要对CMDB服务模型加以验证，选取重点的系统来验证，让系统经理和CMDB相关用户也参与进来，用事实和数据讲话，对模型和工具做最终的确认。这个其实是一个小范围内的推广，它的经验可以直接应用于下一个阶段。接下来是对其他所有被采集对象的普遍扫描和CI数据同步，在这个阶段里还需要实现CMDB和所有ITIL流程的集成，ITIL流程是CMDB的主要消费者 ，这个集成往往是两家不同的产品，这种情况下，如果集成的效果欠佳，CMDB的实施成果也会打折扣。最后结尾的交付物可以是CMDB的审核和报表等产品。 正如ITIL的实施一样，没有两个国内公司的ITSM实施是相似的，就像国内不存在两片相同的树叶一样。那么国外的树叶又如何呢？从ITSM实施方面来看，相同的树叶在国外还是非常多的。相同的原因在于，往往用户选择了相同的产品如Remedy ITSM套件，往往由于定制化的人力成本很多用户也在尽量避免对产品的定制，如果通过配置可以实现的需求，绝不定制或者开发。我们也应该多走工业化标准生产的道路，少以中国特色为借口来实施个性化二次开发。