从2003年GJB5000标准的发布开始，GJB5000的推广和实施已经进行了十几个年头。从这些年的推广经验来看，具备GJB5000资质的组织，软件开发更加规范，软件开发人员的素质进一步提高，软件开发工具更加完备。而且，一些以装备研制为主的组织里，软件专业也开始有了自己的声音。特别是GJB8000标准的发布，使得软件越来越受到重视。但是，GJB5000的落地仍然不够顺畅，很多业内的优秀实践在推行起来困难重重。
所以如此，是因为硬件研制管理模式中的一些惯性思维对GJB5000落地形成了阻碍。
惯性思维1：更关注顶层方案设计
传统的硬件研制管理模式中，设计师团队对系统/组件的顶层方案设计相对来说更加重视。这类方案的评审一般都会组织正式的技术评审，设计师团队在技术负责人的带领下对方案进行严格的审查，而对于后续的图纸设计都是走审签流程，没有正式的评审，图纸的质量问题和返工多出现在标准化上，而是否满足设计方案少有关注。
这种惯性思维会给GJB5000的落地带来下面的后果： 软件任务书/需求规格说明的厂/所级评审，软件的设计评审、阶段评审等都是软件部门的事情，系统/组件室少有参与。
因为在惯性思维中，关注点都在系统/组件的顶层方案设计上，软件不在这个关注点上。
惯性思维2：组件出了质量问题就是组件设计师的责任
传统的硬件研制管理模式中，按装备研制所涉及的专业方向形成不同的专业科室，组件按其专业由XX科室管理，组件产品的质量也由该科室负责，一旦出现了质量问题，责任就是该组件的设计师、科室的主管领导的，而其他部门没有责任。
这种惯性思维对GJB5000落地的影响就是：软件出了问题就是软件部门的责任，与其他部门没有关系。这种思维极大地削弱了GJB5000中“利益相关方”策划和监控的管理活动，以及关键依赖关系等实践的落地。
惯性思维3：组件产品是产品，没有软件产品的概念
在传统的硬件研制管理模式中，一说产品，指的都是硬件产品，就没有软件产品的概念，软件都是作为硬件的附属品存在着。所以，那些对硬件产品适用的管理条款，到了软件这里，就没人想起来了。或者，不管对于软件适用不适用，一股脑儿地照搬。比如，用于产品测量的测量设备，如果是硬件产品，使用之前都知道查看有没有合格证；而对软件产品，就没人检查软件是否经过测试验证，是否出自受控库？
这种惯性思维对GJB5000落地的影响是：软件过程体系只有软件部门才了解，其他部门不关心软件产品如何管控。
惯性思维4：软件就是编码，分分钟就能搞定
在传统的硬件研制管理模式中，软件都是由组件设计师在完成硬件设计的同时完成的。在管理者眼中，能够看到结构和电路图纸的设计出图，而软件开发由于没有一个可视化环境，管理者不清楚软件开发、调试、验证等需要花费的工作量。在他们看来，硬件出来的时候软件也出来了，就好像软件不需要多少工作量似的。
而实际上，GJB5000落地实施使得软件开发的工程活动、管理活动、支持活动等全部规范起来，它使得软件开发不仅仅是编码，它还有需求的开发和确认，软件的设计和验证等很多任务要完成；从标准来看，GJB5000二级有100多个实践，三级有300多个实践，而要完成好这些任务和实践，就需要投入大量的人力。
“软件开发就是写代码”这种惯性思维对GJB5000落地的影响是巨大的：GJB5000的实施可能会由于缺乏足够的人力资源导致一些过程域一些实践有形无实，比如PPQA、PI。
惯性思维5：管理模式无须改变
传统的硬件研制管理模式相对来说是一种粗旷的、松散的模式，一些研制流程的要求没有那么具体。比如，把系统需求分解到组件乃至软件，一般的做法是先完成系统方案设计，再进行组件方案设计，最后给出软件研制任务书。从系统方案设计到软件研制任务书，它们之间的关系是由GJB9000中“设计输入和输出”要求“设计的输出应满足设计输入”来约束的。而在软件标准要求中，则在后续的文档中就明确了需求追溯，而且还有QA审核需求追溯。所以，软件的研制流程更能确保系统需求得到满足且不容易有遗漏。硬件研制管理模式中，没有明确系统需求分析和设计及其向下分解的要求，而这些相关要求在软件标准GJB2786A中都已经明确。
这种惯性思维对于GJB5000落地的影响是：一些系统层面需求的变更可能传递不到软件，从而使得软件的需求开发和需求管理都有很大隐患。比如系统的通信协议发生变更后，可能仅有组件人员知晓，而受影响的软件人员却一无所知。
总之，GJB5000落地难，是因为传统的硬件研制管理模式并没有对引入的软件过程体系消化、吸收、融合，或者说基于GJB5000标准的软件过程体系的本地化程度还远远不够。
閱讀更多 筆下餘香 的文章
