2-02第2章范围计划.pptVIP

示例：一个建筑工程项目的WBS 2.5任务分解的方法 我们的难点：怎样分解任务？ 基本路线 估算自己的项目的时间、成本、人员 制定自己项目的软件生存周期 建立“面向过程的WBS”（即粗略的阶段划分） 建立“面向产品的WBS”——分解自己项目目标，定义主要工作和目标成果 返回到1，继续。反复检查、细化、调整、再细化。特别注意的是：信息一致性！ 其中，关键线索是：分解出各个规定活动下的特定任务，并按照层次化原则来描述。 解释——再看面向过程的WBS 读图 WBS由工作构成。 工作派生出活动和任务两类细节。 任务与活动，可以分别单独定义，也可以把任务定义在活动之下（对于较大项目）。 如何分解出WBS 1.选择软件过程模型，建立面向过程的WBS（参照模板，设定任务） 2. 建立面向产品的WBS 注意：其实就是目标成果的结构化分解描述，需要采用“先自顶向下，再自底向上，反复修正的方法” 3.编写日程表 说明：教材中将此项工作的最终完成放在进度计划中。这是可以的。但是： 工作分解结构是需要验证的。没有工作日程的排布、没有任务先后/并行次序的设计，是不能定稿WBS的。 4.修改WBS，并在后续的项目管理中作为的范围控制的依据 静态控制——使用面向产品的WBS 动态控制——使用面向过程的WBS 本章案例 面向产品的WBS 任务 完成时间 负责人 资 源 备 注 需求讨论 2003-4-9 韩万江 2开发人员参与 项目规划 2003-4-12 韩万江 全体人员参与 需求确定 2003-4-16 韩万汪 全体人员参与 设计 2003-4-20 姜岳尊 杨炎泰参与 项目实施 20o3-5-30 姜岳尊 杨炎泰参与 有待细化 测试 2003-6-4 郭天奇 开发人员参与 提交 2003-6-5 韩万江 表3-8 项目初期计划 面向过程的WBS 编写日程表：可以使用项目管理软件建立的WBS 示例：采用Project2003的甘特图 * 注意：这是课程设计第二个报告的主要结论 2.6任务分解结果的检验 1.关于目标成果的分解 要实现项目的目标需要完成哪些主要工作？ 面向产品的WBS，其最低层次的细目是否必要和充分？——十分需要重新修正（增加细目、减少细目或修改细目）。 最底层要素是否有重复的？如果存在重复现象就应该重新分解。 2.关于目标成果的结构 组成元素的定义是否符合项目工作组织和完成的实际情况? 目标成果中是否既包括产品，又包括服务？ 每个细目都有明确的、完整的定义吗？如果不是，这种描述需修正或扩充。 3.关于项目资源 是否每个细目可以进行适当的估算？通常，任务分解时至少拆分到一周的工作量（40小时）。 能担负起满意地完成这个项目的任务？如果没有，修正是必要的，否则难以充分管理和控制。 对思想上的检验更为重要！ 1.WBS的分解过程，应该是将项目的产品（含服务）与项目的组织及过程这二者综合到一起的项目分解过程，是这样吗？ 2.项目最底层的工作分解，必须有利于责任分配（不仅个人，还要全体）；工作块的分解，必须清晰定义不同个人或者是组织之间的界面和责任；WBS的构成必须便于项目管理人员对项目进行监督和业绩考核。 3.对于所有的工作块，有没有统一的文字说明？——这需要编成一个项目任务分解结构字典（WBS Dictionary）。 4.任何项目都不可能有唯一正确的任务分解结构，你的分解体现了你作为项目管理者的什么思想？ 细节问题是一切问题的导火索 每一个工作单元的名字只出现一次。不要有重名（包括编号） 每一个WBS条目中的工作内容，应该是该条款以下所有WBS条目之和。 每一个WBS条款都应对应一个责任人，包括直接参与者。 WBS的内容要和工作实际执行安排相一致； 创建WBS应该和项目组成员共同讨论，取得一致意见。 * 有必要把范围管理工作做细、做扎实 建立WBS字典，要把每一个WBS条款都记录在内，确保精确理解条款，范围清晰。 WBS的描述、记录和使用方式，必须适应变更的需要，还要便于实施对范围说明书工作内容的控制。 最后的认识 任务分解结构（WBS）提供了项目范围基线，是范围变更的重要输入。 范围基线由批准的详细项目范围说明书、WBS和WBS字典构成。 范围管理的输出，是范围变更或不变更的决策。 决策该输出的主要依据是：软件需求变更、项目估算和进度变更，以及对整个项目成功的集成和控制需要。 构思计划并保证其成功，能给聪明人以极大的满足感。 追求这种构思和执行的可能性，就叫做创新精神，建议和执行的自主性也属于创新精神。 ——[法]亨利.法约尔 2.7校务通系统案例分析 面向产品的WBS 注意到该WBS的说明 F2.7（聊天室）和F2.8（论坛）采用标准的重用技术， F2.5（资源库系统）、F2.4（教师备课系