Category Archives: Project Management
21世纪最缺的是什么？
21世纪最缺的是人才，在ITIL项目中更是重要。特别是CMDB项目，项目团队人员构成是呈金字塔型。 最顶端的人是Project Executive Board“项目执行委员会”，简称PEB，它就像是一个公司董事会；它对CMDB项目的目标、预算、工期、项目变更等负责。PEB人员数量应愈少愈好，不过下面的个角色也是缺一不可。首先，要请至少一个C level的人加入，比如数据中心的CIO。其次，关键利益干系人，它们是CMDB的价值的主要承载者，叫好和批评项目成果的都会是它们。然后是CMS/CMDB系统的负责人，它们对CMDB的规划、维护和之后的发展最重要。最后是项目实施资源的主要提供方领导，说白了他就是出人出力的部门，今后项目的执行和实施都靠他们。所以PEB的人数在4人左右。他们是相关部门的领导。我在最近的项目实施中，也遇到了几个问题，需要去找客户的老板来拍，也就是找到PEB的人决策。其实之前也听到其他同事在项目过程中，曾经感慨道“客户的领导还真辛苦，大事小情都需要替下面做决策，他们的脑袋真禁拍！”。国内的管理者的确挺辛苦的，毕竟所带领的团队都还比较的年轻，这也是国内IT管理的成熟度低的一个体现。 金字塔下面的人就是都是我们的天天加班、做牛做马的辛劳工作的实施人员了。没有规矩不能成方圆，实施团队的技术素质和构成、团队沟通等都是至关重要的。对项目的质量，项目工期都有非常重要的影响。金字塔下面的兄弟姐妹都是一条船上的人，大家要互相配合才能完成项目的各项工作；在这个过程中没有一个船老大也是不行的，船老大就是项目经理。对CMDB的项目经理的要求可不低，重要有以下几点： Planning skills IT service management background Previous involvement in building a database ITIL Manager’s certification Ability to make decisions Capabilities to motivate staff Ability to blend a team Strength of character to lead a team Capacity to present results and status of project to sponsors and stakeholders Self-motivation Ability
项目实施之鬼见愁@需求变更@
不经意间听到的让我深思的一段对话。 甲：咦，这个功能是什么时候加的？ 乙：哦，我也不知道还有这个功能 丙：那是我加的 甲：需求是谁提的？ 丙：他们那天给我打了一个电话说需要这个功能 都说ITSM项目是非常难实施的项目，成功率低；特别是CMDB项目，实施难度大，失败案例比比皆是。首先我觉得ITSM项目的实施有它的特殊性，特殊在于实施顾问对客户需求的理解，在于实施顾问对ITIL最佳实践的经验，在于对产品工具的把握。其中任何一个环节拿捏不准都会到导致需求的泛滥、需求混乱、需求的飘忽不定。 可见需求管理是项目实施和执行的灵魂，失去了对灵魂的掌控，需求讨论会就将可能进入走火入魔的地步，需求各方争执不下，整个会议室炸开了锅，每个人都争抢着发言，我的脑也几乎要眩晕；我说的这一点也不夸张，没见过只能是你的幸运。 需求管理包括需求的分析和整理，应该是有层次的，在不同的层次里讲不同的语言，达成共识的讨论结果。层次可以分为这样三层 业务需求 用户需求 功能需求 所谓业务需求是说站在公司的高度，从最high level角度描述需求之所在。它的语言像是项目使命的宣言，指出为什么要做这个项目，项目的价值点落在哪里。最概况的项目范围。业务需求告诉我们：为什么会有这些需求。 用户需求是指从项目利益相关人的角度出发。逐一描述各个业务操作环节，这些业务操作由每个可独立执行的条目为单位，每个业务操作中说明业务规则、输入和结果。切忌在这一阶段就进入详细的功能界面或者功能操作上细节的任何讨论。原因很简单：我们在这里还没有进入技术实现环节，依然在以客户或者系统使用者的角度来描述它的需求。系统用户和客户是不需要理解每一个页面跳转和鼠标点击的意义的。在我的经验看来客户在这里最容易陷入技术细节讨论的泥沼，反而可能浪费需求讨论的时间，可能导致项目的延期，需求点难以确定。用户需求告诉我们：用户的需要什么。 功能需求则需要告诉我们：为了能满足用户需求，我们的系统是怎么做的。这里将用技术的语言，进入系统层面说明系统应该怎么做。功能需求最终将导出概要设计和详细设计。 业务需求的满足=用户需求的满足+功能需求的满足；用户需求是能推倒出功能需求的，用户需求和功能需求可以是一对一、一对多和多对多的关系。 以上三个需求是有层次的并与客户递进沟通的产物，既然是沟通，那么在每个层次上都伴随着矛盾、争论、妥协。在任一层次上理不出头绪时，一定要追溯到上一层，通过上一层来指导解决。但是这往往也是很难把握和执行的，最终最可能的结果是在以上三个沟通层次中都伴随着需求的变化、需求的扩大、需求的混乱。甚至于进入了测试阶段还能产生出新的需求和理解的偏差，谁人能不说“需求变更”是项目实施的鬼见愁呢？ 如何解决这个“鬼见愁”？一方面需要时刻对项目预算和时间资源保持清醒的头脑，项目实施比较是那时间和金钱换需求。还有就是通过项目变更委员会来控制需求变更。