所讲的质量活动是与技术评审、把关活动紧密联系而不可分割的。

当前的研制流程和质量体系约束下，无论是单机还是系统，总会经历论证、方案、设计、生产、试验等大的流程、节点，在大的节点上，序时性一定能够得到保证，即便是所谓的“多边”状态，在系统工程研制的源头和过程层面，也是要严格遵从一定的序时性。

而问题出现更多的是在产品的试验、验收，交付环节，以及大型试验已经开始，相应确认的环节尚未完成应该做的工作，在某些程度上，这会令质量管理人员比较恼火，但其余人也一定不会当成什么大不了的事情，至少是在因序时性而带来质量问题之前。比较典型的就是产品先完成单机的所有试验验收后再交付，还是直接交付各大型试验甚至于总装试验，看起来已经是严重地违背了研制的规律和流程体系，但在实际研制过程中，这已经成为了常态，并由此引入诸多层层闯关的质量问题。

之前我们纠结于先下白图生产，或是基线确认后生产，或是先定购元器件再出图纸，现在看来这些已经都不是事儿了，可能是技术的进步，可能伴随着管理的精进，但无论如何，都要做好一些事情的闭环，并承担一定的技术风险和管理风险，比如成本的增加，计划的延期（这个就比较搞笑，为了快反而更慢），再有就是复查，复核、独立评估到底在什么节点完成更合适，具有更高的效费比。

一、产品研制的最初阶段

一定是先有论证再有方案，这个应该无人会质疑，然后是具体的设计实现生产及试验验证，看起来并行的可能性不大，无论项目处于几边的状态。

对于任务的输入，必定有技术要求在前，必定是在输入/要求的评审/确认后，才可以开展后续的论证以及方案设计，否则一定会在诸多环节上存在理解不清、不一致的地方，一旦在后续过程中确认不充分，就极有可能造成方案的反复和返工。

再向下一层，图纸和生产必定有先后，至少图纸的技术状态要建立一个基线，软件也应该如此，总是先有需求再有代码，如果先有代码再有需求，那么就一定有可以代替需求的环节，那应该是一本事无巨细的任务书了。剩下的就是自下而上、自上而下的双向逐层进行方案的闭合，在这个层面上，并行有没有风险？这值得商榷。

大的串行，小的并行，这也许是一种当前模式下提高工作效率的有效途径，不管是IPT/IPD或是其他什么，我们必须请楚地看到当前单纯、严格的串行已经在一定程度上限制了研制效率，所以必须秉承该并行的就大胆去做的理念（比如总体和分系统的并行设计与确认)，但这并不意味着可以恣意妄为。

简单梳理一下，这个阶段可以并行开展的工作：

在充分考虑产品化的前提下：系统的整体方案，产品借用的适应性分析，软件的整体架构，单机任务书、元器件原材料的备料，软件任务书，仿真系统构建，软件评测硬件平台准备；子系统测试方案、测试大纲；环境力学条件，产品的分技术条件；专项大型试验的策划等。

二、产品试验以及交付阶段

为了赶进度，总会出现未尽事宜解决之前的内部交付，主要看前面未完成工作到底是什么，一般情况下总会是产品的功能和性能指标得到了最大限度地测试和确认，剩下的一般是例行试险尚未完成的情形，这时需要从设计人员那里得到支撑，也就是例行试验是否会引入不确定和风险，一般而言，对于例行试验除非新研设备，不会存在太大的风险。

但如果不是例行试验未完成之外的其他原因，那就不好说了，在当前单机试验的测试覆盖性需要大幅度地提升，也就是在原先验收试验和例行试验的基础上，开展更为深入地可覆盖系统使用的测试，也就是在任务书中提出更为具体的测试要求，如果这些工作未得到充分开展，自然也就是呈现当前大部分型号所面临的困境，单机在系统测试中问题不断，麻烦不断。

眼下针对例外放行，有申请、有放行，但是一般都对闭环确认不太重视，质量活动的延续性和延伸性没有得到较好的贯彻落实。

思考一下验收和交付的底线到底是什么，就是针对于产品的功能、性能指标的确认，在这之前，产品不能交付后续使用，只有在接口、功能/性能指标在得到了一定层级的确认之后，必须经由设计方和生产方的共同确认。

至于测试的层次性落实，不论是四不到四到还是什么，单机层面至少也应该解决掉80%以上的问题，你可以不覆盖系统，但需要确保在后续系统测试中不再出现单机测试可以覆盖的问题。

三、一些典型质量活动的序时性

1、复查

复查应该在各个节点之间，各个适宜的节点，而非最后出厂使用之前，如果工作确信已经按照要求做实了，可以没有复查，更多的只有针对一些个别问题的剥离和举一反三。我们反对全面复查和一遍又一遍针对性不强的复查.

可以有的复查，单机产品交付之前针对生产过程的工艺和检验，测试数据的复查，问题处置和举一反三措施落实情况的复查，单机技术状态和软件版本的确认；系统交付之前复查综合试险、匹配试验和专项试验的测试数据。

2、复核复算

对于单机产品而言，最好的时机应该在产品技术状态固化、生产之前完成。

对于系统软件而言，应该在进行出产前系统验证试验的过程中，结合试验进程中遇到的问题和难题去开展，对于软件，更多的是走查和代码的静态审查，因软件独有的易改性特点，其最终沦为各种更改的重灾区，所以针对软件的复核复算或者说走查/代码静态审查却是唯一可以持续开展的工作。

3、独立评估

主要针对重大技术应用和重要新研产品而开展的第三方的通过业内资深专家进行确认的方式，既然源头很重要，那么独立评估就应该提前策划，在技术和产品的源头就应该介入，但实际上所有的独立评估在此方面是存在问题的，严重滞后，使得周期较长的独立评估没有最大限度地发挥作用。

另外一个就是技术产品经过一定的试验验证后，避免在更后端的节点去做这件事儿。

4、专项评审

经过分祈，元器件专项、可靠性与安全性专项、风险控制等专项可以紧前安排，不能等到最终出厂之前集中开展；软件专项、质量问题处置和举一反三、技术状态更改控制等也需要契合项目研制的进度开展。

具体内容参见本公众号具体链接（出厂评审和出厂专项评审）。

四、序时性的保证

序时性的保证有两层含义：①不逾越流程；②要与大计划节点契合。

1、不逾越流程

不拿敏捷来说事儿（①学习笔记 | 敏捷宣言和敏捷系统工程的理解；②充分交流，拥抱变化，迈向敏捷）。

需要正确理解敏捷开发好而研发的内在是快速选代闭环。

流程的严肃性必须被统一地认识到，在研制过程中必须得到秉承，特别需要关注小的流程层面，很多工作都是有前置程序的，紧前的工作必须完成，否则紧接其后工作的有效性会大打折扣，转段、验收、试验，很多工作因其惯性继续向前，冀期望于之后的某一个大的节点打结儿，但实际上在未严格记录和梳理的前提下，堂而皇之地过去了，产品也就会带着隐患甚至于问题滑入纠结不清的泥潭。

2、与大计划节点契合

在合适的节点做合适的事儿，契合大的研制节点，到什么节点该做那些事情，闭环哪一些质量活动，每一个项目都有计划，都有质量工作策划和计划，需要做好两者的匹配度，更要确保质量计划的严肃性，这个严肃性就是需要适应研制的实际工作进展而进行动态、科学的调整，而不是为了这样而不去那样。

这里面有一个管理活动把关责任落实的问题，我们有很多的资源和力量，在面对当前存在的问题时很多人已经被同化掉了，以至于形成最后无奈和漠视的局面，针对于此，就是一个表格化确认的问题，所有的序时性活动做完其前序节点和工作是什么，紧后的节点又是什么，需要逐项确认。关键是谁而来确认的问题，自然是谁来做谁去确认。

3、需要注意流程的优化和完善

在不违背客观规律的前提下，流程是可以进行优化的，但这与责任又是强相关的，因为流程的更改而引入新的问题，一旦被求全责备或被追责，也就没有人去打流程的主意了，也就造成了当前的一种现象，已然这样了，要求里面还是有堂而皇之的“正规”要求。

比如说验收向题，既然进度紧，那就关注交付后产品试验的状况，有无动单机状态的需求，有就去更改，无非就是确认好、统计好状态，不要有遗漏即可；既然单机测试阶段解决不了所有的问题，那就索性将系统测试的前期归结为验收测试的一部分，真正暴露问题和完结后再组织产品的正式验收，之前就组织出厂（配套厂）的预验收即可。

比如说一个阶段内部的IPD,很多工作可以并行开展，过分地强调输入完备性其实就是一种不担当，针对输入的不完备而引入的困难和问题，只要有人与我们一起去承担、而不会在出现问题之后有苛责就足够了（当然，针对不完各输入再次细化后，当然也还要给承担方留下较为合理的时问去实现、去验证)。

这个责任谁来担，那就是顶层的主管机关，要记得梳理当前研制过程中的种种不合理和怪现状，组织大家一起讨论，邀请用户方代表参加，在不违背体系（体系顶层要求其实没有那么细致，细化是靠一级组织来进行的)和不影响产品实物质量的前提下，不会存在太多因难。

五、结论

我们强调质量活动的序时性，是为了规避类似已经要出厂了还没有验收的极端情况，不是单纯地强调先做什么后做什么，而是为了保证在大的研制阶段，不出现本末倒置的类似于先有软件还是先有需求、先有图纸还是还有产品的类似问题。

IPD和敏捷开发，体现的是整个研制的效率，体现的是针对用户方要求响应的快速、及时，但整体上绝大部分工作特别是在大的节点层面，需要通过序时性去规避风险，最大化减少工作遗漏而引入的问题和拖延。