摄影：杨亚东
在航天项目技术风险辨识与控制过程中，尽管已形成较为系统的理论框架和实践方法，但仍存在一些现实中的“尴尬”或挑战。这些挑战既涉及技术本身的复杂性，也与管理机制、资源分配及动态变化等因素相关。
以下是结合实际项目研制过程梳理出来的主要问题及应对思路：
1) 新技术应用的不确定性
航天项目常涉及大量新技术（如新材料、新工艺），其风险线索可能因缺乏历史数据而难以量化。例如，某首次应用的新技术需通过“14条线索”逐一排查，但实际操作中可能因技术成熟度不足导致隐性风险未被识别。所谓风险识别的线索中，对于新技术只能停留在表面/表层，不能深入和细分纬度，所以也就难以辨识出新技术/新产品构成要素引入的风险。如某国产芯片流片工艺的不完备导致芯片合格率极低，以至于难以交付出足够数量的芯片，其根本原因就在于最初期望值太高，提出了国内最先进的技术指标，而忽略了产品设计的工艺实现环节风险。
尴尬点：传统方法（如故障树分析）对新兴技术风险的预测能力有限，过度依赖专家经验、承研承制主体的不切实际的承诺会极大可能地引入主观偏差，并造成诸多现实的困难，极有可能迟滞整个项目的研制进度。
反思：
①新技术也应该以“够用”为主，切不可盲目乐观，忽视现有技术和生产制造基础水平和能力，即技术/产品的成熟度一定要得到关注，要刻意控制项目研发中新技术/新产品的占比。
②针对新技术/新产品的构成要素，要从基础级维度进行分险的分析和辨识，更多地从设计到产品的转换〔生产制造可实现性〕、地试的覆盖性、边界工况测试等层面开展深入的分析，形成针对性措施落实到过程。
业内有一个通用的说法，辨识到的风险不发生（问题），发生的（问题）未辨识到（风险），这在以前是一个普适性的存在，近几年来也出现了辨识为风险的环节依旧会衍生出问题，表征为风险控制的不有效，其根本却是相关细分环节未被充分辩识到，没有在过程中进行有效的控制。例如挑战者号航天飞机爆炸问题，对于低温条件下o型圈功能的丧失未得到充分辨识，或者说忽视了此环节，没有采取新措施或者等待天气条件变好后发射，最终酿成人间悲剧，造成了重大损失。例如业内外因产品而引入的成败型问题不在少数，原因就是忽视了返修的流程和工艺控制，导致返修后质量水平不升反降---引入其他问题和不确定性。
尴尬点：对于复杂的系统工程而言，构成的环节众多，绝大多数环节的失效将直接带来成败型风险，整体为串联模型的大系统会频繁地出现各种问题，也包括成败型问题。
反思：很多环节我们没有辨识为风险，但作为特殊过程、关键环节进行了控制，包括I、II类单点，有识别，但控制手段没有跟上，所以更多的是在类似环节出现问题，造成一个器件影响一发火箭成败的现状。
PS：诸多环节不可能都识别为风险，投入的关注度和精力有所差异是正常的，标准有所区分，但在应该关注的节点需要不打折扣地开展工作，否则一旦工作不充分或遗漏，则就容易埋下隐患。
航天项目周期长，风险随研制阶段动态变化（如方案阶段侧重设计风险，试样阶段需兼顾操作风险）。日常研制过程中强调需建立“月度/双周/周闭环管控机制”，但实际执行中可能因流程繁琐导致风险更新不及时，难以适应突发变化。
随着项目研制的进展，风险是在变化中的，关注到的，采取了有效的措施，就会有效地被消减，措施不具针对性，则风险会演变为问题并激发其他问题，引入全新的风险；同时，由于各分系统风险管控进程的不同步，会造成一些风险得不到实质上的消减，比如战术导弹武器的突防风险，无论是单弹突防还是多弹突防，始终是一个多系统协作配合的过程，都需要将风险评价等级降至可接受的范围内。
尴尬点：
①左右不一致：相同或相近项目/产品风险辨识即控制措施的不一致；源于项目之间缺少沟通，组织作用发挥的缺失。一个极致的例子就是所遇到的一到风险辨识时项目与专业吵得一塌糊涂，一方认为是风险的，另一方从来就不认为是，令质量部门在中间煎熬。
②上下不一致：即研制单位把控的风险和上报系统/总体的风险不一致；这源于研制单位有所保留，不想让系统和总体投入太多的关注和精力，以便自身集中精力去有效消减风险【初衷是好的】。
③前后不一致：研制初期和产品出厂前的风险不一致，体现为前后风险项目的不一致，此处的不一致不在于风险项目数量增多，而在于一些风险项目被轻易舍弃，不再关注。
反思：
① 风险的滞后性一定程度上源自于上下不一致，即风险辨识、控制的滞后性，以及上下层级的不透明以及有所保留；
② 另外就是效率问题，正如前面所言，一个是流程较为繁琐，需要各层级的确认，无论是线下还是线上，注定是一个较为缓慢的进程，尤其是在决定整个项目关键环节风险控制成效的节点上，拍板的确需要慎重。
1) 接口管理的复杂性
航天项目涉及多层级系统（总体、分系统、单机）和外部供应商，接口设计错误或时序不匹配可能引发连锁风险。例如我们需通过“极性控制”“软件需求传递规范”等措施强化接口管理，但实际操作中常因沟通不畅导致技术状态失控。 实际上，接口和技术状态变化环节，是问题多发地，一贯如此。特别是在技术状态变化层面，总会引发各种类型的问题，一个著名的例子已经用了无数遍，就是在已有平台上横空出世的波音737max，更改的不合理、不彻底、验证不充分而导致数起空难。再有就是接口处的确认不完备导致的各类型问题，包括电气接口、机械接口的确认。
尴尬点：技术状态变更若未遵循“论证充分、试验验证、各方认可、审批完备、落实到位”五项原则，可能因部门间/单位间权责不清导致风险扩散。
反思：
①对于接口以及变化，需要站在系统甚至于总体角度去审视和分析确认，而实际上当前一些系统和总体的作用发挥不够。
②技术以及行政leader对于系统和总体的把握度也好，权威也好，调遣能力也罢，切实需要提升，需要各层级行政领导的大力支撑，并且需要把握的是系统工程研制永远是一个总分总的过程，而最为关键的是最终系统集成测试与确认。
航天项目依赖复杂的供应链，某一环节的元器件或原材料质量问题可能引发系统性失效，供应商的透明度和响应速度仍是管控难点。在之前统计的质量问题之中，供应商的问题在80%以上，这比较正常，说明了系统集成工作的纯粹和有效，也说明了当前绝大多数项目都是大协作。
尴尬点：
① 随着工作的深入，你会发现供应商在过程中隐藏了大量的问题和技术状态变化，有些让你后怕；更有甚者，在对问题的查摆和处置过程中，你会发现竟然是“这么烂”，以至于对后续所有其配套的产品都不放心。
② 体系、体制和质量文化的碰撞，导致自身很多的要求无法贯穿下去，也就是无法贯任务提出方的标准，这会让任务提出方颜面尽失，尤其是自己认为很有效的方式方法和手段，在供应商眼里不值一提 小题大做，浪费金钱和时间。
③体制内作为同一母公司的子公司间进行配套时，大哥说话永远不好使了，而母公司又经常性地不亮明态度，期望于大哥管小弟，而使得兄弟睨于墙。
反思：
①最初的“约法三章”至关重要，甚至于要写进合同条款中，同时，要教会供应商按照自身的技术、管理、质量要求来开展工作，要有流程指导，要有模板，更要有手把手。
②文化以及质量管理层面的沟通至关重要，要有正规的约束和要求传递的渠道，要进行定期的沟通和交流 ，尤其是针对那些承担复杂产品研制的外部单位，要将自身的质量管理经验甚至于技术层面需要规避的大坑告诉对方，不管其是多么地自负。
风险分析需结合定量方法（如概率风险评估PRA）与定性分析，但实际中常因数据不足（如小样本试验数据）导致评估结果可信度低。例如，我国CZ-2F火箭曾通过改进风险量化模型提升管控效果，但这一过程需要大量资源支持。 这样一来，我们更多的是依赖于定性定量化的风险评估，导致风险综合评价等级存在可以地降低，不能客观地反应项目风险现状，导致组织层级的不重视和支撑不够。
尴尬点：风险评分与等级划分（“风险评估矩阵”）可能因数据缺失流于形式，难以指导优先级决策。风险等级评判存在一定的随意性。
反思：
①风险的辨识和控制自项目研制伊始，此时的风险项目等级的判定反而是相对客观的，因为全员对未来充满了敬意〔实际经验缺失〕，此时需要组织专家的介入，共同研判、确定风险的项目和等级；
②对于风险后果的严重程度相对比较客观，而对于发生的可能性等级不太客观，此时不要忽视一个现状，也就是小概率事件经常性发生；对于器件，可以以其失效率来判定，而对于某项技术或产品，问题发生的概率会呈级数级倍数增加，一般最低也只能是“很少”，对应的失效概率在〔0.01,0.1〕，不要盲目乐观认定为极少。
航天项目常通过冗余设计降低单点故障风险，但过度冗余可能导致成本超支。我们之所以提出“伪冗余分析”要求，需针对性的测试项目验证冗余措施的有效性，但实际设计中可能因进度压力而简化验证流程，埋下隐患。当然历史上也出现过多次因为“伪冗余”而导致的重大质量问题，著名的737max问题也有伪冗余的成分在，明明多个攻角传感器，却选择相信其中一个而导致悲剧发生。
尴尬点：
① 一提到冗余，一般沿用的还是高可靠性的模块/器件/单机，导致成本双倍或三倍增加〔双路冗余或“三取二”冗余〕，而不是采用可靠性较低的进行冗余备份设计，所以冗余与成本控制矛盾凸显。
② 如果不采用冗余措施，单点较多，就会对各单点环节提出极高的要求，反而在无形之中增加了更多的成本。
反思：
① 设计理念的转变是首当其冲的，要有成本意识，要进行限价下的适宜的可靠性设计，满足够用原则〔这是大部分项目所采用的原则〕，研制经验表明，所谓可靠性极高的器件、产品，一样会出现问题，所以此时就必须要有自己的底线，不要提过高不切实际的要求。
② 冗余环节的测试务必关注，必须以最小的代价进行测试覆盖，确保使用前每一路都是好的。
③ 一些项目要向马斯克学习，以低成本、中可靠的产品及部件叠加/集成高可靠性的系统。
航天器控制系统软件复杂度高，我们一直强调需通过FMEA、第三方测试等方法确保健壮性，但实际中可能存在测试用例覆盖不全、异常处理逻辑未充分验证等问题。我们所倡导的A、B级软件的第三方测评要求，但执行时可能因时间限制而压缩测试周期，导致测试的不充分。 毋庸讳言，因为测试用例设计和测试周期短、经费投入少等原因，一些软件评测不见底，不充分。
尴尬点：
① 软件技术状态变更后的回归测试不彻底，可能引发未被识别的时序或通信接口故障，延伸开来就是数据流和数据交换问题，包括整个数据流的拥堵、冲突、竞争等现实性问题。
② 一般项目，独立评测完成以后，进入系统甚至于在后续使用过程中出现问题，包括低层次代码实现问题，重复性质量问题。
反思：
① 测试用例的制定和相关方〔任务提出方、代码实现、软件评测〕完备的评审；
② 以问题为导向的测试用例制定，规避之前发生过的问题成为首要任务；
③ 系统级测试平台〔软硬平台的构建，平台的等效性提升〕的引入，尝试进入真正系统的边界测试和强度测试，专门的测试用例、边界模拟和故障注入。
地面试验条件难以完全模拟太空环境（如微重力、辐射、低温/高温交变、光污染、运载器多余物影响等）。我们现在已经尝试在提出“试验边界条件分析”要求，但试验数据与真实飞行数据的偏差仍可能导致风险误判，也因此出现了诸多成败型的质量问题。一个例子就是美国火星车车轮的磨损问题，因为地面试验环境不能覆盖真实的火星环境，导致车轮磨损严重，进一步限制了火星车的活动范围。
尴尬点：
① 地面试验足够多，一上天就废；
② 单机测试完美，一接入系统就问题多发；
反思：
① 天地的差异性辨识和分析至关重要，到底有哪一些不同一定搞清楚，之于系统和产品的影响安排特定的试验进行验证；
② 试验策划之初，要关注贮存环境、使用环境、使用工况的差异性，针对这些差异，策划专项补充试验，并且要将一些试验项目进行人为地整合，以覆盖更多的环节；
③ 仿真试验的重要性提升，前提是模型的逼近和多次迭代，以及海量的仿真验证。
5、文化与制度层面的深层挑战
1) 风险文化的缺失
部分团队可能因“零失败”压力而回避风险上报，导致风险信息传递滞后。我们经常性地提及“航天发射只有0分和100分”，这种文化可能抑制风险透明化和讨论、交流，其实后果更为可怕。
尴尬点：
① 明明是疑点重重，明明是处处不放心，却根本没有风险项目，更不会有针对性的措施；
② 风险项目被轻描淡写，措施的针对性不佳，感觉总有难言之隐让我们背后发凉
反思：
① 建立非惩罚性风险报告机制，鼓励开放沟通，运用好独立评估和独立的复核复算。
② 风险项目清单建立，强化“十大风险”识别与控制。
尽管已形成多种风险管控标准，但基层执行中可能因流程僵化或资源不足而简化步骤。例如，“月度/双周/单周闭环管控”机制需要持续投入人力，长期执行易流于形式。这里面还有另外一层意思，即有章不循，这是比较可怕的事情，说明组织内部违章成本极低。
尴尬点：
① 标准规范思路清晰，实际风险管控工作开展光怪陆离，主观性较强，甚至于寄期望于头脑风暴；
② 有章不循时有发生，更有甚者重复性发生。
反思：
① 风险管控的闭环迭代机制必须得到坚持，简化监管的模式和提交物规模，以表单和条目化的陈述刻画进度和进一步的需求。
② 强化规程、规范、规矩意识，首先是规矩、规范和合理性和适用性得到保证。
结合人工智能技术（如机器学习）构建动态风险评估模型，整合历史数据与实时监测信息，提升预测精度〔其实风险预测较难〕，其实最关键的就是数据的把握和掌控，以此判定风险辨识的全面性和管控的有效性。
建立供应商风险共担机制，通过区块链技术、全级次的供应商管理实现关键物资/产品的全生命周期追溯，而全级次管理的内在就是贯标，贯我们的标准和要求，最好形成重点突出的供方管理实质性要求，要针对重点单位进行针对性的细致检查，及时纠正、纠偏。
在传统流程中嵌入敏捷管理方法，例如采用“风险冲刺”（Risk Sprint）快速迭代风险应对措施，这个迭代依托于项目，更在于组织的有效牵引。
① 特别在风险识别环节：团队成员参与，鼓励所有团队成员积极参与风险识别。由于敏捷项目的特性，每个团队成员都有可能发现项目中的风险。
② 团队协作层面：风险共识环节，确保团队成员对风险识别、评估和应对策略有共识，避免因意见分歧而延误处理。风险透明环节：保持团队内部和与利益相关者之间的风险透明，及时沟通风险情况。
通过案例培训和模拟演练强化全员风险意识，同时优化绩效考核机制，将风险管控成效纳入项目评价体系。
综上，航天项目技术风险管理的“尴尬”本质上是复杂性与有限资源间的矛盾，只有通过技术创新、制度优化与文化重塑的多维协同，才能在高风险环境中实现“零缺陷”目标，有效控制风险，确保项目研制。
