3、电台设计保证系统：设计保证手册（DOH）的编写要点，组织架构与职责划分
各位同行，咱们今天聊聊设计保证手册（DOH）。
这东西，说白了就是电台设计团队的“宪法”。
我见过不少团队，技术牛得很，但一到适航审查就抓瞎。为什么？因为你的设计过程没有“规矩”。DO-178C也好，DO-254也罢，都要求你有一套成文的设计保证系统。而DOH，就是这个系统的说明书。
3.1 DOH到底是个什么文件？
我个人习惯把DOH看作三样东西的合体：
- 承诺书：向局方承诺，我们按规矩办事。
- 路线图：告诉所有人，设计流程怎么走。
- 责任状：出了事，谁拍板，谁背锅。
嗯，这里要注意。DOH不是写出来给审查员看的摆设。它是给你自己团队用的。我见过有的公司，DOH写得天花乱坠，实际干活完全两码事。结果审查时被揪出来，那叫一个惨。
我曾经见过一个项目，DOH里写着“所有设计变更需经CCB评审”。结果项目赶进度，工程师自己改了代码就提交。审查员一问，全傻眼。最后被开了不符合项，整个版本回退，损失两周工期。
记住：DOH里写的每一条，你都得能做到。做不到的，别往上写。
3.2 编写DOH的五个核心要点
写DOH，不是写小说。我总结了五个要点，你照着来，基本不会跑偏。
3.2.1 明确适用范围
你得先说清楚：这本手册管哪些项目？管哪些产品？是只管电台硬件，还是连软件、结构件一起管？
我建议你写得具体点。比如：“本手册适用于XX系列航空电台的硬件设计、FPGA设计及嵌入式软件开发活动。” 别写“适用于所有产品”，那等于没写。
3.2.2 定义生命周期模型
电台设计不是一锤子买卖。你得告诉团队：我们走什么流程？
举个例子，我常用的模型是这样的：
| 阶段 | 活动 | 输出物 |
|---|---|---|
| 概念阶段 | 需求捕获、可行性分析 | 系统需求规格书 |
| 设计阶段 | 架构设计、详细设计 | 设计文档、原理图 |
| 实现阶段 | 编码、制板、调试 | 源代码、PCB文件 |
| 验证阶段 | 测试、评审、分析 | 测试报告、评审记录 |
| 适航阶段 | 符合性声明、资料提交 | 适航包 |
你想想看，如果没有这个表，新人来了都不知道下一步该干嘛。
3.2.3 定义关键过程
哪些过程是“关键”的？我个人认为，至少包括：
- 需求管理过程：需求怎么来？怎么改？怎么追溯？
- 设计评审过程：什么级别要评审？谁参加？怎么记录？
- 配置管理过程：代码、文档怎么管？版本怎么控制？
- 问题报告与纠正过程：发现bug怎么报？怎么修？怎么验证？
- 供应商管理过程：外购的模块、芯片，怎么保证质量？
嗯，这里我多说一句。供应商管理这块，很多公司容易忽略。电台里用的很多芯片是商业货架产品，但适航审查要求你证明这些芯片是可靠的。你怎么办？DOH里得写清楚。
3.2.4 定义组织架构与职责
这是DOH里最“政治”的部分，但也是最关键的。
你得画一张组织架构图，然后说清楚：
- 谁对设计质量负总责？ 通常是总工程师或项目负责人。
- 谁负责独立验证？ 测试团队必须独立于开发团队。
- 谁负责适航联络？ 得有一个人专门跟局方对接。
- 谁负责配置管理？ 这个角色不能兼职太多，容易乱。
💡 我的经验：
我在项目中遇到过一种情况：质量经理同时兼任配置管理员。结果项目忙起来，他先顾质量，配置管理就落下了。审查时发现版本混乱，被要求整改。
所以我建议：关键角色之间要有“防火墙”。比如，设计人员不能自己验证自己的代码，测试人员不能自己管理自己的测试用例版本。
3.2.5 定义独立性与审批权限
适航审查特别看重“独立性”。
什么叫独立性？说白了，就是做决策的人不能是干活的人。
举个例子：
- 设计师画了原理图，不能自己签字说“这个图没问题”。得由另一个资深工程师评审。
- 软件工程师写了代码，不能自己测试。得由测试团队测。
- 适航资料提交前，得有适航工程师签字放行。
这些权限，DOH里必须白纸黑字写清楚。谁有权批准什么？谁有权否决什么？
3.3 组织架构的常见模式
我见过几种典型的组织架构，各有优劣。
| 模式 | 特点 | 适用场景 |
|---|---|---|
| 职能型 | 按专业分组（硬件、软件、测试） | 团队大，产品线多 |
| 项目型 | 按项目分组，每个项目有完整团队 | 项目独立，周期紧 |
| 矩阵型 | 既有专业组，又有项目组 | 大公司，资源复用 |
我个人比较推荐矩阵型。为什么呢？因为电台设计需要跨专业协作。硬件和软件经常要联调，如果分属不同部门，沟通成本很高。矩阵型可以让工程师既属于专业组（保证技术深度），又属于项目组（保证沟通效率）。
📌 小技巧：
写DOH的组织架构部分时，别光画图。你得把每个角色的职责写清楚。我习惯用“角色-职责-权限-能力要求”四列来写。比如：
- 角色：设计评审员
- 职责：审查设计文档，提出修改意见
- 权限：有权否决不符合要求的设计
- 能力要求：5年以上电台设计经验，通过适航培训
这样写，审查员一看就明白。团队内部也不会扯皮。
3.4 编写DOH的常见误区
最后，我给大家泼点冷水。写DOH时，这几个坑千万别踩：
- 照搬模板：网上找个DO-178C的模板，改个公司名就交差。审查员一眼就能看出来。因为你的流程跟你的产品根本不匹配。
- 过于理想化：写了一大堆“应该”、“必须”，实际根本做不到。比如要求“所有代码行必须经过同行评审”，你想想看，一个电台项目几十万行代码，每行都评审？不现实。
- 忽略版本管理：DOH本身也是要受控的。我见过一个公司，DOH写了三年没更新过。技术都迭代好几轮了，手册还是老一套。审查时被问得哑口无言。
- 职责重叠或空白：比如“设计变更”这件事，配置管理员说归我管，项目经理也说归我管。结果出了事，谁都不认。或者反过来，没人管。
嗯，今天就聊到这儿。DOH这东西，说难不难，说简单也不简单。关键是你得把它当回事，而不是当成应付审查的作业。下一章咱们聊聊具体的符合性方法，到时候见。