标签：设置 很多 分片 nbsp 高质量 平台 进一步 能力 中间
项目群的关键里程碑必须是每个子项目的关键里程碑，每个子项目的里程碑务必不要都设置为和项目整体里程碑同一个时间点，能够提前的尽量提前，这样对于子项目里程碑能够提前的就已经具备了一定的关键链中的缓冲时间。对于最后一个子项目的里程碑到达时间，往往还需要留一定的缓冲余量，没有任何缓存的项目群里程碑往往都是不可完成的任务。
子项目的关键里程碑达成的困难往往并不是取决于子项目本身，而是取决于外在的多个其它子项目的前置依赖，前置依赖越多，子项目里程碑达成的风险越大。子项目的前置依赖本身往往还可能存在对其它子项目的前置依赖从而形成跨项目的前置依赖链，这个依赖链越长，子项目里程碑达成的风险越大。
项目群目标的分解，项目群整体的计划和管控是从上到下的，但是实际各个子项目的任务活动执行，工作量的估算则是从下往上的。大项目不可控来源于子项目本身不可控，子项目本身不可控来源于项目小组不可控，而最终又将体现在项目个人不可控。如果整个大项目群中的每个人都无法给出自己的工作项和工作任务的工期，并按工期交付高质量的中间产物，那么整个大项目群将处于完全不可控状态。我一直强调的就是项目群管理和项目管理往往仅仅是辅助，更加重要的是小组本身的工作质量和能力。就像一个不具备基础能力的团队，要想通过简单的管理，规范和流程来解决问题完全是不现实的。
项目群管控的难度往往还体现在跨项目的协同和高效沟通上面，对于单个项目而言所有沟通都属于团队内部沟通，团队人员本身可能已经有一种沟通默契和早已经形成的团队词汇表，而对于项目群而言各个子项目间较难在短期之间形成一种高效沟通的能力。单个项目可以为自己的子项目的里程碑，目标和任务负责，但是却很难真正能够为整个大项目群的最终目标负责，这一方面是本身的意识和态度问题，一方面是能力问题。对于一个全局性质的大项目，子项目团队成员也很难真正能够掌控全局。对于PMO而言也是困难的事情，PMO可以出清晰严谨的规范流程和项目章程，但是如果不深入各个子项目仍然很难真正统揽全局工作任务和风险。
大项目真正在执行过程中会发现很多地方协同困难，这个首先要追溯到对于整个大项目或项目群的分解，我们就没有意识到各个子项目间所有的依赖关系和具体协同点，没有提早的对这些接口和依赖制定有针对性的风险应对计划。对于完全子项目内部的时候应该是由各个子项目经理来识别和应对风险，而对于跨项目间的协同和依赖，则需要由PMO牵头来共同分析和识别风险，并提早的制定相应的风险应对方法，尽早行动。
对于单个项目而言，某个工作任务可能不是你项目的关键路径，但是往往却是其它多个子项目的关键路径，对于这种工作任务需要提升到PMO层面进行重点跟踪，对于子项目而言他们往往并不会有这个意识，但是这些任务一旦延期将直接影响到整体项目群里程碑的达成。跨项目的依赖关系识别，关键链的识别和管控，将成为大项目群能够按计划完成目标的关键。
对于单个项目而言，如果要求每个项目成员都对项目目标负责，那么对于大项目群而言，则至少需要每个子项目的项目经理对整个项目群目标负责。这些项目经理应该对项目群共性词汇有统一的认识，项目经理间能够高度的协同和合作，高效的沟通，能够更加的关注项目群整体的目标而不是自己单个项目目标的达成。
在产品管理中曾经谈到过组合管理，管道管理和资源管理方面的内容，对于一个大型产品的研发往往涉及到多个研发项目和配套项目，因此往往从一开始就需要考虑资源计划，资源分片和跨项目的资源调配和资源池管理。而对于外部大型项目群，往往涉及到的是不同的合作厂商，那在这种情况下往往很难真正进行跨项目的资源管理，出现的情况往往就是项目有些提前，有些延后，各个项目紧张空闲度完全不同，各个子项目内的资源也很难在项目群级别进行充分利用和最大化。
对于一个大型的项目群，如何保证项目群里面的每个子项目都能够遵循相关的方法，工具，技术，规范和流程是一个相当重要的问题。很多时候回顾这些大项目你会发现，并不是没有组织级的规范和流程约束，而是每个子项目在执行过程中出现偏差，对于组织级不能只制定规范流程而不管最终规范流程的执行和管控。正是基于这个原因，对于大项目群的管理需要采用进一步的矩阵式结构，纵向和横向要完全结合。纵向关注的是项目本身目标，而横向关注的是跨项目共性的阶段和过程统一。对于大型软件项目群而言，类似需求组，UI/UE组，架构组，平台技术组等都是需要考虑横向贯穿和统一的跨项目协同团队。
标签：设置 很多 分片 nbsp 高质量 平台 进一步 能力 中间
原文地址：http://www.cnblogs.com/tiffanygf/p/7520770.html
