第七期项目经理资质认证(高级)_曾建蜀_项目经验总结.doc

浅析项目实施过程中“自顶向下”方法论的运用项目经验总结-曾建蜀对于任何公司或组织来说，一个全新的项目在实施时通常会有以下几个方面的制约因素：1、 工程实施文档严重不全甚至没有；2、 文档质量不高，对工程施工人员几乎无任何指导作用；3、由于开发团队迫于公司考核压力或客户方的进度压力，盲目采用快速跟进的方法，导致产品测试不充分，质量低劣；4、对于应用软件依赖的第三方软硬件产品不熟悉，且无法获得第三方软硬件厂商足够的技术支持。针对这样一些情景，我们无法通过历史资料或组织内部培训来提高项目实施能力，这个时候既需要一种勇往直前的勇气，也需要有一种合理的方法。根据我近一年多来遇到的类似项目处理方式，本文提出用“自顶向下”方法论来在进行工作方法的指引，并就该方法论的应用经验进行总结和分析，以期帮助项目经理或项目实施工程师合理地选择该方法、有效地利用该方法提高工作效率。本文将从方法论概念、与自底向上的区别、使用场景、方法论优缺点、采用该方法需要具备的能力、自顶向下方法论遵循的基本步骤和相关注意事项几个方面进行分析和阐释。本文视图从理论上对“自顶向下”方法论的运用进行全面剖析，而对具体方法只进行简单陈述，需要各项目经理和项目实施工程师仔细阅读、用心揣摩。为便于理解，本文在文章的结尾以贵州移动的两个案例来帮助大家理解。n 项目实施过程中“自顶向下”方法论概念在项目管理过程中，有很多管理领域都含有“自顶向下”方法的应用，本文中的“自顶向下”方法论主要是指自有或第三方软件安装、调测过程中的方法论，与项目管理中的时间、成本、范围管理等没有必然的关联。实施过程中的“自顶向下”方法论主要是在实施过程中将业务目标进行拆分，按正常工作的顺序逐点逆序进行，渗透到软件安装、功能查找、功能该验证、调试过程中。这里要强调的是在工作顺序上把功能查找（功能使用）、功能验证作为优先顺序按逆序的方式提前到调试工作之前。这是本文“自顶向下”方法论的一个关键点。n 自顶向下与自底向上的区别与“自顶向下”相对的方法论主要是“自底向上”方法论。只要在应用软件调试过程中遵循“先分析客户需求，然后根据客户需求去查找、验证，调试和再验证”这个流程的，都是采用了“自顶向下”的方法，而“自底向上”遵从先调试后验证的顺序。“自顶向下”总体上是按细分的需求范围纵向切块来实施，对已完成的功能点能清晰的界定和判断，“自底向上”总体上是按软件组织架构横向切块来实施，对需求目标的界定和判断不是很清晰。比如移动话务网管四期产品中的“主动监控”模块，按自顶向下来实施的话，能很清晰地说明完成了什么厂家的什么指标处理（包括底层采集、中层算法调试、上层展现网元设置、历史曲线查询），而按自底向上方法处理，描述的则是厂家底层采集包安装情况介绍、中层算法设置情况介绍。【说明：正确的理解这个例子需要假设你完全不清楚主动监控如何实施，不清楚主动监控有底层采集、中层处理和上层展现这些环节】n 自顶向下方法的应用场景自顶向下方法论采用主要是在项目实施方法的探索阶段，它不适用于项目的全过程，因为在探索出方法以后就会有更优化的办法来取代。自顶向下使用的场景首先一定是要基于项目组织对工程实施顺序、安装部署细节、工程实施的详细目标不清楚（甚至连业务范围也不是很清楚）的情况下采用的，其目的是让工作从“无从下手”的状态转变到可以正常开展的地步。一旦探索出方法以后，我们就可以考虑更优化的办法，比如采用自底向上的方式来批量展开工作。从工作组织过程来讲，自顶向下方法的运用往往是由于项目采用快速跟进的方式，忽略或不具备条件进行全方位的准备工作造成的。比如没有进行充分的需求调研、没有合理的进行需求范围的细分（细分到功能点）、没有充分进行产品测试并编写正确的施工文档。n 自顶向下与自底向上优缺点比较特性自顶向下自底向上对历史经验依赖在项目实施组织没有一套完整的实施办法或历史经验可借鉴的情况下，它可以围绕最终业务目标快速的展开相关工作在没有完整的指导文档或历史经验情况下，无从下手，工作无法展开单点问题对项目的影响把复杂的完整的实施过程进行了分解或纵向切片，将无法解决的问题暴露在单个点上，遵循由点到面的问题解决方法探索问题成片出现，单个问题可能影响到整体环节工作进度描述便于准确描述工作的进度不便于准确描述工作进度冗余工作工作效率相对偏低，增加了一个工作的冗余环节即在调试完成之前已经有功能使用和功能验证的过程，真正完成工作还有一个调试和再验证的过程减少了冗余工作，避免了返工批量作业无法进行批量作业，在项目并行执行方面受到一定的限制可以进行批量作业，加快了进度n 采用自顶向下方法需要具备的能力和素质采用自顶向下方法需要施工人员具备一定的业务应用推广能力和意识；需要具备项目管理对于WBS分解的基本能力和意识；需要具备软件开发经验和逻辑思维能力。根据前述对于应用场景的分析，由于这种方法的采用往往是因为在分析、测试、组织施工环节采用快速跟进方式从而造成阶段性交付物质量不合格而导致的，因此需要在正式实施阶段来对项目的需求目标进行工作细分，对交付物的特性进行细化的描述。n 自顶向下方法运用的基本步骤该方法运用基本遵循以下几个步骤：1、 阅读合同技术建议书，了解项目背景及大致范围；2、 收集需求说明书，了解细分的需求范围；3、 对产品交付物（或产品功能）进行细分的描述和定义；4、 查找相关的产品（看看在哪个菜单下），进行产品功能验证（输入必要的参数和条件，看看是否得到相应的结果）；5、 对无法提供的产品功能进行尝试性调试，或咨询相关人员（如产品开发人员）后进行调试。6、 对第5步处理的过程记录下来，看看其他功能是否适合类似的处理方式；7、 重复16步探寻更多新的方式或按第6步的方式进行实施并优化。n 自顶向下法使用的注意事项“自顶向下”方法论不仅适宜于一个全新的项目，对一个已经有丰富的实施文档指导项目的某些功能仍可使用，因为实施指导文档对不同的环境不同的实施人员，其作用是有区别的，比如对于项目组织中一个刚加入的成员。由于采用该方法存在冗余工作，因此不可僵化运用，全程照搬。由于很多工作是渐进明细的，因此在完成工作方法的探索后，可以转向其他更优化的方法，但是当遇到新的问题时，我们仍可在局部采用该方法对实施文档进行补充和完善。n 实施案例09年，我在带领贵州团队进行项目实施时，有两个项目即贵州移动综合接入项目和贵州移动门户项目都采用了这种“自顶向下”方法论来进行团队工作指导，从而顺利地推动了两个项目的上线。案例一：贵州移动门户项目实施背景：贵州移动门户项目从09年4月份开始启动7月份达到上线使用条件。整个产品涉及需求调研、产品开发、项目实施、项目优化几个过程。该项目采用IBM WebsPhere Portal框架进行开发，由于用户要求6月30号上线，因此产品几乎没有设计环节就直接进行了开发；由于是我公司第一次涉足类似项目，因此在项目实施过程中几乎没有任何针对性的实施指导文档也无法提供提供实施培训，项目实施工作举步维艰。本地项目经理和实施成员与北京研发之间产生了冲突，认为研发未提供安装配置文档，无法开展工作；北京研发认为由于时间紧、况且他们本身也是在摸索过程中，需要现场人员共同思考如何进行项目实施。鉴于此，临时由我本人充当项目经理，按如下方法进行项目工作开展：1、 阅读了合同技术建议书和项目范围说明书（excel版的项目范围说明文档）；2、 找客户方项目经理刘阳交流他们心目中的门户项目，并采用纸质描画项目界面的方式对个人工作主页、短信彩信发送、页面内容裁剪、ESB数据流交互等功能进行了比较详细的描述；3、 针对个人主页、页面内容裁剪、ESB和短信彩信发送功能，登录到已经部署好的框架中去查看是否有该功能；4、 对于功能不具备的，立即电话咨询项目经理（毛伟昌），了解原因并跟毛伟昌一起制定后续解决计划；5、 对于已经具备的功能进行测试，记录测试过程中发现的问题并咨询研发人员；6、 根据研发人员的提示更改部署环节中的配置、或通过前台设置权限；7、 记录和整理权限设置的具体步骤；记录各配置文件分布的目录；询问相关模块的开发人员关于配置文件分布目录规则和配置文件的命名规则，抽象出其他类似功能的配置文件分布和命名规则。8、 对其他功能按照类似的操作步骤进行尝试。并证明了前述过程的普遍适用性。9、 通知项目组另外2个成员按照相关方法进行尝试。10、 三天后，2个项目成员均能按照相关方法完成相关的实施任务。目前该项目已经通过了上线使用演示和培训，得到了网管中心副总和支撑室经理的认可，并在网管中心副总带领下到贵阳市公司进行了一次推广。该案例中体现“自上而下”思想的核心步骤为4、5、7。案例二：贵州移动综合接入citrix虚拟发布实施背景：由于09年3月份贵州移动网管中心将进行办公地址搬迁，但搬迁的前提条件是需要综合接入的citrix虚拟发布工程完成所有网管中心70余套软件的集中部署和发布，而且citrix必须安装在VMware虚拟主机上，不再实体主机上。这次项目的难点是：一、公司没有人员实施过citrix应用集中发布；二、citrix产品从未在VMware虚拟机上进行过稳定性测试，而且由于与VMware的商业竞争关系，citrix不计划提供任何VMware上的技术支持；三、项目施工时间短（40天）、虚拟发布设备不足；四、不同软件部署在相同主机上可能存在应用冲突；聘请公司对该产品有一定了解并熟悉项目规划的人员作为临时项目经理进行工作指导，该项目经理进行了大量的需求分析和风险分析，制定了如下的工作步骤：1）、针对每套应用制定了60余项调研任务；2）、调研完成后首先完VMware主机的安装；3）、安装CPS服务器；4）、安装NBH客户端；5）、安装CPS；6）、在CPS上安装应用，冲突应用的冲突监测；7）、CPS上的应用发布；8）、测试应用。计划完成后抽调了本地40%的服务人员进行培训和工程突击，要求所有项目组员详尽地完成调查表格中各要素的调研，并在调研评审结束后进行工程部署。但是在加班加点工作了20天后，没有一份调研合格，没有一套应用被成功发布，团队成员与项目经理相互指责、并在公开场合争吵。鉴于此，临时由我本人充当项目经理，按如下方法进行项目工作开展：1、 阅读了技术方案建议书中关于citrix虚拟发布的原理，通过电话联系citrix关于虚拟发布的基本过程；2、 重新组织项目成员到网管中心监控室、维护室、技术支援室和支撑室进行业务软件的收集，将调研表格要素简化到6项（软件名称、依赖的第三方软件、使用该软件的人员、该软件在同一主机上最大可能并行开启的个数、该软件在不同主机上开启的个数、通常判断该软件正常运行的方法）；3、 选取2个有一定项目管理意识的人员针对6要素调研表格进行3种分类：1）、不考虑冲突的；2）、同一主机内冲突的；3、不同主机间冲突的。4、 按第3步骤的分类进行纵向切块，分成3个小组，参照第三步中的类型各自选取一套或2套应用进行完整的发布过程尝试；将原来8过程的部署顺序按如下方式进行调整：、个成员完应用测试的最少量VMware主机安装；、在两台虚拟服务器（P1、P2）上安装相同应用；、在P2上安装CPS软件；、在P2上发布应用；、在任一NBH客户端上启动应用，按应用正常运行标准进行测试；、对于第步测试不成功的，到P1上进行测试，如果在P1测试成功，按后面的第5步处理即：咨询，寻求问题解决办法；对P1测试不成功的，找软件提供商咨询。5、 对于每一环节中出现的问题进行及时咨询、研究或讨论；将原来批量进行时批量暴露的问题纵向切为单点问题，逐个攻关；6、 将操作的过程进行及时记录，并将暴露的问题及时完善到FAQ中，对由于操作过程考虑不周的地方，根据最新咨询的结果和研究的结果进行操作步骤的完善；7、 根据第6步的操作，让项目成员参照第3步的分类分组并行展开原有工作。14天后，整个项目工作全部成功完成，比原定计划提前