组织建信息系统，目的不是把纸质表格搬到线上，而是固化业务流程，实现信息化、数字化管理。那么，一个实施GJB5000B的组织，其软件项目管理平台应该固化什么？是GJB5000B的各个实践域流程，还是组织实际的软件开发业务流程？
答案应该是：以固化软件开发业务流程为主，以符合GJB5000B要求为辅。
为什么？因为GJB5000B是标准，是能力成熟度模型，它告诉我们“应该做什么”，但不规定“具体怎么做”。组织的软件开发业务流程，才是价值创造的实际路径。实施GJB5000B，是为了让这条路径更可控、更高效、更高质量，而不是用标准流程取代业务流。
如果本末倒置，会怎样？
假设某组织按GJB5000B实践域建平台：需求管理一个模块，项目策划一个模块，项目监控一个模块，风险管理一个模块，配置管理一个模块……每个模块都有表单、记录、审批。开发人员每天要登录多个模块，填写大量记录。需求人员填需求跟踪矩阵，项目经理填策划表，开发人员填代码提交记录，测试人员填测试报告。平台看起来“很GJB5000B”，但员工觉得是额外负担。业务在别处跑，平台成了“电子台账”。这就是“两张皮”。
反过来，如果平台固化实际软件开发业务流程：从需求收集、分析、评审，到迭代计划、任务分配、每日站会、代码提交、持续集成、测试、缺陷修复、版本发布、维护。员工在这个平台上完成日常工作。GJB5000B的要求，作为规则、检查项、模板嵌入到这些活动中。比如：
-
需求评审时，自动生成需求管理需要的记录； -
迭代计划时，自然满足项目策划的要求； -
看板和站会数据，成为项目监控的证据； -
代码提交关联需求、任务，形成配置管理和需求跟踪； -
测试用例、缺陷记录，满足验证和确认要求。
这样，员工不是在“做GJB5000B”，而是在“做软件开发”。合规数据是业务活动的副产品，不是额外工作。平台成为“研发工作台”，而不是“合规填表系统”。
有人会问：那GJB5000B实践域还要不要？当然要。但它是“魂”，业务流程是“体”。魂要附体。平台设计应以业务流程为主线，以实践域为标签或映射。比如，一个“需求变更”流程，可以同时映射到需求管理、配置管理、项目监控等实践域。用户看到的是一个变更流程，体系看到的是多个实践域的满足。这才是融合。
再举个实例。某软件组织实际开发流程是：产品经理提需求→需求分析→评审→排期→开发→测试→发布。如果平台按这个流程建，每个环节嵌入GJB5000B要求：需求分析时填写需求规格并关联跟踪矩阵；评审时记录评审意见和处置结果；排期时形成项目计划；开发时通过任务看板监控进度；测试时记录测试用例和缺陷；发布时进行配置基线管理。员工觉得平台好用，因为它就是工作本身。审核时，所有证据都在平台里，不需要临时补材料。这就是“业务驱动，标准融合”。
反之，如果平台按实践域建，需求管理模块只放需求表单，项目策划模块只放计划模板，项目监控模块只放监控记录。员工做完需求，还要去另一个模块填计划，再去另一个模块填监控。重复劳动，数据割裂，最后大家应付了事。GJB5000B推行多年，最怕的就是这种“体系业务两张皮”。
实施GJB5000B的最终目的，是提升组织软件开发能力，更好实现业务目标。业务目标是交付高质量软件、满足客户需求、获得市场成功。GJB5000B是手段，不是目的。平台固化业务流程，就是让手段服务于目的。如果平台固化实践域流程，就是让目的服务于手段，本末倒置。
所以，建平台前先问：我们组织实际的软件开发流程是什么？关键活动有哪些？角色怎么协作？输入输出是什么？决策点在哪里？然后，把GJB5000B要求作为约束条件嵌入。考核时，看业务结果，也看过程证据。过程证据来自业务活动，而不是额外补录。
总结：实施GJB5000B，项目管理平台应固化软件开发业务流程为主，符合GJB5000B要求为辅。业务是主线，标准是辅助；流程是体，标准是魂；交付是目的，合规是保障。
最后，四句诗总结：
建平台为业务通，莫让标准反成笼。
流程作体规作魂，交付价值是真功。
参考书目：有效需求分析 ，作者： 徐锋，出版社： 电子工业出版社
