4.集成的项目管理 当项目的交付物由多个独立的团队产品化了，就可以应用集成的项目管理（IPM）。集成项目管理的因素有很多，比如： ● 功能分布的团队 ● 地理位置分散的团队 ● 产品大小 ● 多种技术 ● 软件外包 这些因素使得项目沟通变得分散，以至于产生了需要直接应用于软件产品开发中的集成的需求。集成的需求越大，使用系统的和经过训练的项目管理原则就更重要。 4.1 集成项目管理的框架 在第3部分讨论的过程模型形成了集成项目管理（IPM）的框架。在产品开发的启动阶段，许多功能组因许多工作特性而形成。但并不是所有的功能。例如，市场组的形成不同于开发组，但开发组可能会与产品支持组有所重叠。同时，应该有意识地努力来正式将团队组织到已经定义好的框架中。在以上所讨论的模型中，每一个组件是产品开发的一个子项目。每一个子项目都应该有明确定义的范围、进度、资源和成本边界。每一个子项目的项目经理对项目边界负责。下图表示项目体系结构如图2 图2 子项目的接口体系结构 产品经理由子项目经理辅助来负责产品管理。对于每个子项目，子项目经理（SPM）负责相应的团队的管理。这并不是新概念，但是这里所指的是，为了有一个成功的产品管理，这个框架并没有清晰地定义和组织，有许多实例都假定使用此结构，但是，团队间在范围、资源甚至成本方面都还实际上很模糊。 4.2 高级WBS 创建高级工作分解结构（WBS）是进行一个完整的集成项目的第一步。所选择的结构影响如何管理项目。功能结构增加了接口的数目和复杂性。WBS的级别可以用以下方式来选择： ● 产品开发中所涉及到的所有活动 ● 可以给每一个活动分配一个或多个组 ● 减少重叠 ● 为每个子项目经理在子项目范围内确定功能留有余地 如图3所示可以给出一个责任分配矩阵 图3责任分配矩阵的例子 4.3 管理接口 高级别的工作分解结构定义了子项目的范围，自此，子项目的项目经理具有执行工作分解结构的任务的责任。每一个子项目与其它子项目都有独立的接口。一个子项目中一个任务的输出，形成另一个子项目中一个任务的输入，这就是接口（图4）。例如，错误消息编号模式，是体系结构组的输出，它又是形成更低一级设计的开发组的输入。 图4 在子项目间的接口 接口管理是管理这些内部依赖的系统的方法。图5表明了在定义和管理多项目系统中的接口所涉及的步骤。 图5 接口管理 5．SMCC经验 SlimCIM XXX 单元控制器（SMCC）是一个监控软件产品，它借助于表面安装技术SMT行业的通用设备模型，来适应机器，监控机器的制造过程和设备使用，如今，SMCC已经成为XXX通讯企业工厂的标准的工厂过程和设备监控软件系统。 SMCC产品在3年前开始开发。最初的2年，它在新加坡软件中心更象一个应用开发项目在运行。随着产品增长越来越大，有了更多的客户，必须有更多的开发进程，维护问题也大量涌现，将来产品的方向也变得更加复杂。于是需要特定的方法来进行产品开发，这不同于应用开发，它的实现与处理模型已经在3中阐述。看看上面的模型，有四个要增值的组件： ● 产品策略决策 （PSD：Product Strategy Decision）决定将来产品的路线。 ● 产品特性控制组最终确定软件产品的需求。 ● 独立的体系结构，对所有的开发组都一样，确保设计的完整性。 ● 独立的集成和配置管理组，来负责集成、配置管理、测试、打包。 一旦这个多功能框架工作正常，组与组之间的接口又成了问题。如果不集成进度，密切关注接口，就不能监控进度。这时就引入了集成项目管理的概念。我们感到集成的概念应该早点实施，尤其，将整个产品开发组织成不同的子项目，并且，在产品开发周期一开始就用集成项目管理方法来管理整个开发。否则功能组的僵化变得更加严重，以致于很难形成一个平滑产品管理的框架工作。 这种方法的优点没有别的，就是用系统的方法来管理整个产品开发，可以更好地预测在规定的时间、成本下项目的交付成果。根据我们的经验，执行的困难是： ● 正确地从所涉及到的不同的组购入。 ● 缺少对所有关心的问题的正确的培训。通用的语言和项目词汇在多个项目交互中是重要的。 ● 就可交付物的可预测性而言的组织能力，一个子项目的不确定性也会影响其它的子项目。 根据这些学习经验，产品开发过程可以在SSC上定义，以便将来的软件开发能从一开始就主动遵从系统的方法。 6．结论 产品开发的集成项目管理在硬件行业已经广为接受。在应用于软件产品时，就子项目的组织而言略有不同。通过合适的过程建摸，仔细考虑这些特殊的软件开发特性，IPM的原则可以有利地应用于软件产品开发。 7．参考 1） XXX数字系统分发（CIG）产品管理过程 2） XXX新加坡软件中心软件开发过程 3） CE-Q Gate系统生命周期文档---草案-C
