在这里谈下从甲方立场的IT类项目的研发管控。首先对于开发厂商的研发过程，给出一个最简单的基于CMMI思路的一个研发过程图如下： 那么站在甲方的思路，要加强开发过程和质量管控的最好的方式就是加强对需求方案和验收发布两端的强管控能力，对于研发过程中加强里程碑评审的能力。对于项目管理而言则加强PMO对项目群管理的能力。在支撑域中最基本的配置管理和变更管理是必须的，要注意到甲方对配置管理的层面往往高于单个应用，往往涉及到的是更加全局跨系统的配置和变更管理能力，端到端的需求全程跟踪和闭环管理能力。 对于甲方驱动的研发过程管控能力，可以总结为三大类，具体如下：

• 可固化：主要是指规范，流程和相关工具的制定和采用。
• 可管控：主要是项目管控过程中的评审，决策，沟通汇报，问题风险管理和监控预警机制。
• 可量化：主要是指研发管理中的基础度量和KPI指标体系的建立

可以讲做好上面三个方面的内容是甲方逐步深入研发过程管控的一个基础。甲方的研发质量和过程管控不是要替代单个应用开发商的研发项目管理和质量管理，而更多的目的是类似CMMI三级一样形成一个适合甲方管理的组织级的过程和管控机制，从单个应用厂商本身的成熟还不足够，更加重要的是组织级的基线和成熟度。 对开发厂商的管控逐步打开内部的黑盒，但是要注意不是完全接管，而是加强关键点的里程碑评审和结构化决策机制。基于这个思路，另外再提下研发过程管控的一些关键点。 对于需求层面，我们要注意往往不是简单的统一需求方案，特别是涉及到跨多个应用系统的方案制定的时候，需要的不仅仅是需求方案，同时包括了技术方案。这个方案会约束高层的的一些总体架构设计和实现思路方面的内容，以防止后续各个应用在实现过程中走偏。 加强对两端的管理，包括需求方案和验收发布两端的管理，而弱化对厂商开发内部的管理，对于开发厂商内部的过程管控只需要加强里程碑监控和评审即可。以做到最基本的闭环管理。对于开发商内部的研发过程重点是制定相应的标准规范和约束，加强QA管控。 配置管理要形成企业级的配置管理库，各个厂商最终的研发过程资产都必须入库，要加强各种配置审计工作，同时源代码配置管理也需要逐步深入管理，方便后续的统一发布和部署流程的对接。而取代原因的开发厂商在验收的时候才一并提交验收资产的模式。 在纵向团队的基础上，可以考虑形成各种横向的联合性质的虚拟团队。包括易用性团队，性能优化团队，技术专家团队，业务专家团队等，以专家团队的方式来解决各个应用可能存在的共享问题，并且在解决后逐步上升到企业知识库中。形成组织级的度量和KPI体系，切实用数据说话，通过数据分析形成持续改进机制。这一点往往是最难的，但是又必须执行，至少需要做到定性+定量的开发商考核和评估机制。