|
‐ 产品经理转自项目管理者联盟
‐ 用户代表项目经理圈子
‐ 合作伙伴代表项目管理者联盟
‐ 项目经理PgMp.mypm.net
‐ 主要开发工程师项目管理论坛
‐ 主要测试工程师
‐ QAtraining.mypm.net
‐ CM项目管理者联盟
CCB委员会可以分成不同的等级：根据变更影响范围、严重等程度的不同，决策是否变更的CCB等级也不同。例如：对于只影响产品内部，且产品经理可以搞定的事，由产品经理和相关研发人员组成的产品级别的CCB决策据可以了。对于可能还影响到其他产品的变更，需要有公司高层参与的公司级CCB来决策。对于还用影响到合作公司的变更，如研发物料的变更，会影响到物料制造商和生产制造商等等，那就是要几个公司的代表参与的CCB来决策，所以CCB也是要分级别来处理的。bbs.mypm.net
一般CCB都设立CCB主席，他主要是在决策争执不下的情况下，挺身而出，给出决策的。blog.mypm.net
是不是要做变更，基线库是否可以变化都是由CCB授权配置管理人员和研发人员等进行执行的。项目管理者联盟
变更影响分析：在变更评审会召开之前要进行变更影响分析，这里是个技术难点。例如：需求变更会影响设计、编码、测试用例等的变更，那具体影响哪个文档或哪些类，这时前面说到的需求跟踪矩阵就派上大用场了。根据需求跟踪矩阵可以知道哪条需求变化，会影响哪个设计文档的哪个章节，会修改哪些对应的测试用例等等。项目管理者联盟
其实不要说变更影响对成本、进度影响分析的准确度了，即使影响范围的分析也是很难全面的。比如：一个芯片的变更，有可能影响：采购周期、芯片供应商的生产、PCB板的设计、生产导入技术、软件研发、库存处理、工程安装规范、现场成品处理、维修备件等等环节。看看吧，改个东西会搞死人的。而且关键是，你搞个芯片变更，会请研发、生产、物流、采购、工程、维修等等的各环节人来评审吗?一不留神就死无葬身之地了。bbs.mypm.net
变更评审会配置管理人员要根据变更评审会中分析出的影响配置项进行通知各相关的受影响人(还是上面那个头疼的问题)，并跟踪各变更配置项的状态，一直到这些变更配置项重新进入基线库。再发布基线报告，通知变更完成。项目管理者联盟
SP 2.2 管理配置项项目管理者联盟
对工作产品基线的整个配置持续管理。这种管理包括对每个配置项情况的跟踪、对新配置项的批准和对基线的更新。项目经理博客
这个是讲：配置管理人员要对每个配置项在三个库中的状态进行跟踪、审核、控制。项目管理者联盟
定期审核三库中的配置项是否合规，三库的安全性，变更是否完整、准确等。www.mypm.net
SG 3建立完整性项目管理者联盟
建立并维护基线的完整性。项目管理者联盟
SP 3.1 建立配置管理记录PgMp.mypm.net
这里实际上是对各配置项和基线做管理。通过对产品整体主干和分支版本、配置项的状态、基线间的差异以及变更流程的记录、备份等工作从而达到管理的目的。bbs.mypm.net
比如：项目经理博客
1、配置管理人员应定期将产品整体版本树导出并展示，明确产品的主干版本和各分支版本以及所有版本的用途。项目管理者联盟
2、记录并发布基线的状态、该基线所包含各配置项的版本、此基线版本与上一个版本的区别等等来管理这个基线的内容和状态。pmp.mypm.net
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
