软件产品开发集成项目管理(上).doc

软件产品开发的集成项目管理（上）摘要软件产品的开发比针对一个特定的用户的需求的开发涉及到更多的开发问题。集成的项目（多个子项目）管理的概念在管理具有更高复杂性的产品开发时是很有用的，本文主要讨论集成项目管理在软件产品开发中的应用。本文首先阐述了应用开发和产品开发的区别，简单介绍了产品开发的特殊领域，以及如何将整个产品开发组织成子项目，这些子项目如何组织以效地协作，如何管理解决细节问题的子项目间的接口。关键字产品管理，集成的项目管理 1.介绍 软件开发有两种业务模式。一个是针对特定用户需求的软件开发（应用开发），第二个是面向市场的软件开发（产品开发）。第一种模式，由唯一的客户承担全部开发费用，并提出软件需求。而第二种模式，开发费用来自多个用户（潜在的要购买此产品的用户）。没有特定的用户提出需求。而且产品要安装在不同的地点，所以在开发产品时还要考虑采用通用的解决方案。 2.在本文中区别项目开发和产品开发是很重要的。从管理的观点来看二者的区别主要有以下几点： 2.1软件需求的所有者 在产品开发中，没有特定的用户提出软件需求。软件产品的特征是从不同来源获得，如客户、市场、技术支持组、当前的技术趋势等等。除此以外，还要有一个团队来实现需求，并管理产品开发中的任务。 2.2市场和技术支持 当产品开发工作完成，开始产品销售时，还要有有力的市场活动，这就是需要售前售后的技术支持。 2.3打包和分发 产品打包和准备软件产品分发是产品经理的职责。这在应用开发中是很少关心的，因为应用开发不需要大量分发。 2.4许可证和合法发布 由于软件产品有很多用户，所以软件产品的许可证的管理成为一项重要任务。为此需要设计一种特殊的许可证控制机制。合法性方面如产品命名、整理专利文档、版权等，也是产品管理的职责。2.5产品维护 由于用户和部署软件的站点的多样性，产品维护比应用开发要复杂得多。不同的站点要安装不同版本的软件。 2.6多线程开发 当软件演变成了大型产品时，开发的范围也扩展了，因而不易于在一个线程中管理所有的开发。可以将它分成多个线程，并对每个线程分别管理。这也给集成管理和版本管理增加了复杂性。 以上开发方面不在我们的标准软件开发过程（SDP）的讨论之列，SDP跨越了从需求收集、计划、系统测试和发布的过程。SDP模型不适合软件产品开发附加的需求，这里引进一种新的软件开发过程模型，目标是对整个软件产品的开发进行全局管理。这种模型，可以很实用地帮助将产品开发组织成有着多个子项目的主项目，这是集成项目管理的基础。 图1产品开发过程模型 3.产品开发过程模型 考虑软件产品开发的特殊性，并借用硬件行业的观点，以下方面构成产品开发的过程模型 市场 技术支持 产品策略描述 侯选特性列表和版本计划 体系结构开发 软件开发 集成和配置管理 图1解释了过程接口和逻辑流程。多数活动都是显然的和直观的，在这个案例的解释是合适的。以下部分对上述活动进行了解释。 3.1市场 市场是由促销和与客户联系的部门启动的前导工作。市场部负责从技术的观点和商业的观点识别客户需求。客户的需求形成了产品策略描述。其它的职责还有：为客户使用创建产品描述，报价单、宣传手册以及其它的市场材料。3.2技术支持 支持活动包括产品在客户处的安装，产品部署、咨询和客户培训。支持组还要负责收集并识别客户新的需求，并输入到产品策略决策和特性列表中。 3.3产品策略描述 产品策略描述是产品策略和产品路线过程的输出结果。要形成一个专门的团队来负责从市场、支持组或其它工程组收集信息并正确表示，这些策略决定被写在产品策略文档中。 3.4特性侯选列表&版本计划 特性侯选列表（FCL）是一套在版本中要优先考虑的特性。FCL提供了一个起点，对于一个版本来说可以选择或确定一个更小的子集。特性控制委员会拥有FCL（产品的需求）。3.5体系结构开发 体系结构开发的开始和在软件生命周期中持续的进化都在体系结构开发这个活动中进行。独立的体系结构组确保设计的一致性和所有功能区域的互译性。体系结构组的权限和职责是： 创建产品线的概念和原则 标识层与接口 标识通用机制和服务 定义、原型和通用机制的增强，如错误处理和内部进程通讯协议 与产品线、概念和原则的项目成员的沟通 体系结构组通常都是由有着扩展领域和工程经验的专家组成的全职的小团队。 3.6软件开发 依据版本计划和商业需求，项目经理要分配特定的项目组来开发软件。一个产品开发中不止一个开发组。这些开发项目中的每一个都可以看作一个应用开发（看前面的定义），有它自己的项目经理和项目计划。已存在的产品的维护也应该被看作另外一个开发项目，需要识别团队成员并进行责任分配。 3.7集成和配置管理 集成和配置管理（CM）组的责任是： 增量开发（与体系结构组的协作） 集成并发布经过验证的子系统 客户版本库的配置管理 除单元测试外，开发测试策略、测试计划、测试案例 所有测试运行的协同 确认并标识所有的软件组件 创建软件分发介质软件产品开发的集成项目管理（下）4.集成的项目管理当项目的交付物由多个独立的团队产品化了，就可以应用集成的项目管理（IPM）。集成项目管理的因素有很多，比如： 功能分布的团队 地理位置分散的团队 产品大小 多种技术 软件外包 这些因素使得项目沟通变得分散，以至于产生了需要直接应用于软件产品开发中的集成的需求。集成的需求越大，使用系统的和经过训练的项目管理原则就更重要。 4.1集成项目管理的框架 在第3部分讨论的过程模型形成了集成项目管理（IPM）的框架。在产品开发的启动阶段，许多功能组因许多工作特性而形成。但并不是所有的功能。例如，市场组的形成不同于开发组，但开发组可能会与产品支持组有所重叠。同时，应该有意识地努力来正式将团队组织到已经定义好的框架中。在以上所讨论的模型中，每一个组件是产品开发的一个子项目。每一个子项目都应该有明确定义的范围、进度、资源和成本边界。每一个子项目的项目经理对项目边界负责。下图表示项目体系结构如图2 图2子项目的接口体系结构 产品经理由子项目经理辅助来负责产品管理。对于每个子项目，子项目经理（SPM）负责相应的团队的管理。这并不是新概念，但是这里所指的是，为了有一个成功的产品管理，这个框架并没有清晰地定义和组织，有许多实例都假定使用此结构，但是，团队间在范围、资源甚至成本方面都还实际上很模糊。 4.2高级WBS 创建高级工作分解结构（WBS）是进行一个完整的集成项目的第一步。所选择的结构影响如何管理项目。功能结构增加了接口的数目和复杂性。WBS的级别可以用以下方式来选择： 产品开发中所涉及到的所有活动 可以给每一个活动分配一个或多个组 减少重叠 为每个子项目经理在子项目范围内确定功能留有余地 如图3所示可以给出一个责任分配矩阵 图3责任分配矩阵的例子 4.3管理接口 高级别的工作分解结构定义了子项目的范围，自此，子项目的项目经理具有执行工作分解结构的任务的责任。每一个子项目与其它子项目都有独立的接口。一个子项目中一个任务的输出，形成另一个子项目中一个任务的输入，这就是接口（图4）。例如，错误消息编号模式，是体系结构组的输出，它又是形成更低一级设计的开发组的输入。 图4在子项目间的接口 接口管理是管理这些内部依赖的系统的方法。图5表明了在定义和管理多项目系统中的接口所涉及的步骤。 图5接口管理 5SMCC经验 SlimCIMXXX单元控制器（SMCC）是一个监控软件产品，它借助于表面安装技术SMT行业的通用设备模型，来适应机器，监控机器的制造过程和设备使用，如今，SMCC已经成为XXX通讯企业工厂的标准的工厂过程和设备监控软件系统。 SMCC产品在3年前开始开发。最初的2年，它在新加坡软件中心更象一个应用开发项目在运行。随着产品增长越来越大，有了更多的客户，必须有更多的开发进程，维护问题也大量涌现，将来产品的方向也变得更加复杂。于是需要特定的方法来进行产品开发，这不同于应用开发，它的实现与处理模型已经在3中阐述。看看上面的模型，有四个要增值的组件： 产品策略决策（PSD：ProductStrategyDecision）决定将来产品的路线。 产品特性控制组最终确定软件产品的需求。 独立的体系结构，对所有的开发组都一样，确保设计的完整性。 独立的集成和配置管理组，来负责集成、配置管理、测试、打包。 一旦这个多功能框架工作正常，组与组之间的接口又成了问题。如果不集成进度，密切关注接口，就不能监控进度。这时就引入了集成项目管理的概念。我们感到集成的概念应该早点实施，尤其，将整个产品开发组织成不同的子项目，并且，在产品开发周期一开始就用集成项目管理方法来管理整个开发。否则功能组的僵化变得更加严重，以致于很难形成一个平滑产品管理的框架工作。这种方法的优点没有别的，就是用系统的方法来管理整个产品开发，可以更好地预测在规定的时间、成本下项目的交付成果。根据我们的经验，执行的困难是： 正确地从所涉及到的不同的组购入。 缺少对所有关心的问题的正确的培训。通用的语言和项目词汇在多个项目交互中是重要的。 就可交付物的可预测性而言的组织能力，一个子项目的不确定性也会影响其它的子项目。 根据这些学习经验，产品开发过程可以在SSC上定义，以便将来的软件开发能从一开始就主动遵从系统的方法。 6结论 产品开发的集成项目管理在硬件行业已经广为接受。在应用于软件产品时，就子项目的组织而言略有不同。通过合适的过程建摸，仔细考虑这些特殊的软件开发特性，IPM的原则可以有利地应用于软件产品开发。 7参考 1）XXX数字系统分发（CIG）产品管理过程 2）XXX新加坡软件中心软件开发过程 3）CE-QGate系统生命周期文档-草案-C砺志成功为中兴通讯实施内训（中兴通讯二营）项目管理内训小结客户名称中兴通讯第二营销事业部客户背景中兴通讯是中国最大的通信设备制造业上市公司、中国政府重点扶持的520户重点企业之一。1985年公司成立。1997年，中兴通讯A股在深圳证券交易所上市。2002年实现合同销售额168亿元，销售收入110亿元。 中兴通讯是中国通信设备制造业的开拓者、中国综合性的电信设备及服务提供商，拥有无线产品、网络产品、终端产品（手机）三大产品系列，在向全球用户提供多种通信网综合解决方案的同时，还可以提供专业化、全天候、全方位的优质服务，并逐步涉足国际电信运营业务。最近两年，在全球范围的电信业调整中，中兴通讯通过实施积极的市场策略，发挥多元化产品优势，加强管理，实现了持续增长，销售业绩领先于大多数同行，进一步提升了行业地位。第二营销事业部是负责中兴通讯公司产品的销售、预销售（预先挖掘客户的需求，给予引导，接受本公司的产品）方面的工作。培训期望由于二营在前期进行了初步的培训之后感觉收效不大，此次想再进行深入的培训。前期的培训所涉及的内容包括：1、什么要推行项目管理？2、PM所包含的东西3、项目管理发展的历史，概念，项目干系人等。4、五大过程5、三图六表（自己内部结合所学，根据经验进行总结）6、PS说明文件7、WBS中常见错误8、五个阶段。注重项目要做的东西如上通过前期培训，对项目管理意识方面已具备一些。但在工作中遇到头痛关键：是无法理出自己工作当中的WBS此次培训的目标：1、对于在一个应标的情况下，如何按项目管理的模式来进行业务流程及工作指导。2、制定规范的工作业务流程并结合实际地应用。3、想将以前的粗犷的项目管理行事手法转化为细化的项目管理模式。4、在没有明确实际产品及目标情形下如何利用项目管理的规范流程指导工作。参训学员分别有来自中兴通讯第二营销事业部的全国各省市销售处、渠道、新网、技术处、办公室、电信处的28位参训学员。培训期次本次培训是砺志咨询为中兴通讯提供的第 4 次项目管理培训。 培训主题项目管理实战课程内容以“实战应用”为最大原则。以项目的启动到收尾五大过程横向发展来融合项目管理的九大知识领域的思路进行讲授。本课程在3天的课程时间里对项目管理的九大知识领域作详略安排。将作详细分析、展开讲解的部分是：- 项目总体管理及总体框架- 项目工作范围管理- 项目时间管理- 项目风险管理- 项目沟通管理- 项目费用管理- 项目质量管理将作概要性说明介绍（即介绍到所有的项目管理方法和知识，但不作展开叙述、讨论）的部分是：- 项目人力资源管理- 项目采购管理 培训讲师廖文忠培训时间2004年11月14日2004年 11 月16日，共21个学时培训地点贵阳 客户评价及意见希望能结合Project软件的应用会更好。满意度根据评估内容统计结果如下：总体平均分：9.5分 评价标准：A：很满意； B：满意； C：一般； D：不满意； E：很不满意.教师表现、教学内容评估内容 1、授课内容的逻辑条理性2、课程内容的启发性3、讲师对授课内容熟悉程度及重点把握情况4、讲师对学员学习引导与辅导5、解答疑难问题的耐心程度6、讲师语言表达的清晰度7、讲师对时间分配和把握8、讲师与学员之间的沟通情况9、讲师掌控课堂气氛的程度10、讲师敬业精神与责任心小张是神州数码网络公司的一位交换机研发项目经理，从事这个行业已经有三个年头了。从学校出来到成为一个还算称职的产品经理，在这三年中，深深地体会到网络设备研发的寂寞、辛酸苦辣和项目成功后的欢欣鼓舞。就让我们管中窥豹，一起去了解一下小张典型的一周工作。星期一春节刚过，三月的一个清晨，小张就接到产品总监的一个电话，告诉小张这周务必抓紧这周的工作。按照进程要求，这周要做好研发产品开局之前的最后准备，小张负责的DCS-2000E系列项目要进入最后的关键冲刺阶段了。挂了电话，小张一下子来了劲儿，去年憋了大半年，产品研发终于到了一个快要“沸腾”的临界点，这是从芯片开始就不断研发的产品，已经一年多了，由于国外那家著名芯片设计商的进度一再拖延，小张负责的这个产品也不得不一拖再拖。DCS-2000E是一个功能十分复杂的，偏重与安全和管理的接入层路由交换机产品，是公司的重点研发产品。赶到公司，今天的工作重心是解决DCS-2000E系列交换机产品的认证多元绑定的最后调试，所幸的是这一技术环节公司在最近两年已经有了丰富积累，在DCNOS产品开发平台中，解决这个问题并不难。跟项目组的另外两个同事忙活一上午，对整个环节做了梳理和测试，感觉应该不会有什么问题。DCRS-2000E路由交换机是公司研发的重点产品，它的突出特点是注重网络安全性和可管理性，包括 MAC 绑定 / 过滤、 MAC 地址导入 / 导出、 IEEE802.1q VLAN 、端口 VLAN 、 PVLAN 、 GVRP 动态注册 VLAN 、保护端口、 IEEE802.1x 接入认证、带宽控制、 IEEE802.3ad 端口汇聚、 QoS 、 IGMP 组播、广播风暴抑制、 IEEE802.1d/1w 生成树、端口镜像等，可满足宽带园区网络对接入控制和管理的严格需求。测试完认证功能，不由地浮现出一种成就感。想想对于未来大量的用户将使用我亲手设计的、完美的认证接入交换机，甜美的味道不由的在小张的心中泛起。星期二今天的任务是要测试的产品的VLAN功能设置和801.1X认证的调试。在经过前一阶段工作后，在VLAN的产品功能设计上，目前只剩下了GVRP 动态注册 VLAN 和保护端口。在这上面，小张他们已经花费了不少精力，因为要率先在业界推出一个全新的功能“基于用户的VLAN”，这必须依靠于产品完备的VLAN配置。这是测试环节中最为复杂的部分，技术总监亲自过来给小张他们项目组做些指导，两周前，这部分功能已经做过完整测试，一切顺利，不过今天的测试出现了意想不到的情况：产品出现了性能不稳定的问题，大家很是苦恼，一时摸不着头脑，按照原理和各个环节的设计，都没有问题啊，到底怎么回事呢？一个上午过去了，测试没有丝毫进展。随即总监召集项目组分析问题出现的原因，最后总结了几个方向，大家分头去找。已经晚上11点了，该检查的都检查了，还是没有发现问题所在。项目组所有人都坚持通宵工作，总监买来一些夜宵，与大家一同工作，终于，在临晨4点多，找到了问题所在，在软件环节出了一个非常细节的小错误，是一个循环的判断语句在临界条件上的失误。修改了软件，重新灌到系统里，已经快到上班时间了，赶紧测试，发现问题终于消失了，大家都松了口气。 星期三一夜未眠，问题解决了，大家都放松起来，此时，困意袭来，不过进度不能耽误，大家鼓起精神，来做今天要测试的部分。今天的工作是对组播和风暴抑制的测试，这是比较成熟的地方，大家也都轻车熟路，一个上午就测完了，没有发现什么问题。由于昨天通宵工作，总监特意让大家下午就回家睡觉。星期四测试的工作接近尾声了，心情激动起来，后面的测试都是交换机常用部分的测试，做了这么多交换机，大家都已经很熟悉了，而且剩下的部分都是成熟的，所以，经过周三之后，大家都已经有如释重负的感觉了。上午10点，接到客服中心负责人的电话，客服中心的两位同事生病了，临时要紧急处理用户的一项故障，小张被指派前往，下午1点半的飞机，赶快回家收拾行李，赶去机场，临走前，从总监给小张了一个神州数码D2SMP的材料，让他看一下，回来提出自己的想法。坐了将近3个小时的飞机，在南方的一个城市降落。当地平台的同事已经在等小张了，一起赶往用户现场。在“案发