将初创企业般的速度带入企业级电子设计

关键要点

• 不断壮大的硬件团队，拖慢进度的往往不是原理图设计或布线，而是等待评审、追着确认不清晰的下一步，以及过晚才获得专家意见。要改善这类沟通，需要现代化的异步工具。
• 硬件开发不能直接照搬软件的评审方式，因为电路板需要实际生产和测试，而且许多行业都有各自的开发流程，例如消费电子中的 EVT/DVT/PVT 验证阶段、汽车行业的 APQP（Advanced Product Quality Planning，先期产品质量策划），以及医疗器械的 ISO 13485 设计控制。
• Altium Agile Teams 让管理员能够将自己的流程构建为工作流，其中包括表单、指定评审与审批、生命周期状态变更，以及发布到产品生命周期管理（PLM）系统。这些工作流可以帮助大型团队像小团队一样保持快速和敏捷。

先想清楚，然后全力冲刺

ŌURA 将少量传感器、一块微型电池和一个钛金属外壳，打造成了一门数十亿美元的生意。Oura Ring 如今已发展到第五代，可追踪睡眠、心率和活动等生理指标，然后通过 BLE（Bluetooth Low Energy，低功耗蓝牙）将数据发送到手机应用中。2025 年 10 月， 一轮超过 9 亿美元的融资使公司估值达到约 110 亿美元，总融资额也因此增至大约 15 亿美元。

工程师、创业者和产品设计师看到像 ŌURA 这样的公司，多少都会有些羡慕。我们的产品能不能成为下一个爆款？我们的组织能不能同样成功？而在高速增长且高度受监管的行业中，我们又能否保持这样的节奏？

在播客 Masters of Scale 中，ŌURA 首席执行官 Tom Hale 如此概括公司的工作方式：

“先花一点时间想清楚你要做什么，但一旦确定，就要全速狂奔。”

然而，任何在大公司工作过的人都知道，无论方向多么清晰、目标多么远大，推进速度都取决于团队之间的协同，以及能让工作持续向前推进的精简高效流程。

团队增长与决策速度

不妨试试：转头问问你旁边的硬件工程师，或者在 Teams 上发消息给同事，问一句：“你觉得我们把时间浪费在哪了？设计流程的哪一部分拖慢了我们？”

很可能，大家抱怨的并不是画原理图和 PCB 布线花了多少时间，而是工作本身的安排和管理方式。听起来可能会像这样：

• “我在等别人看我的设计。” 工程工作本身已经准备好了，但那个能够回答具体问题、审查设计或批准变更的人，却正忙于别处（或者至少看起来是这样）。
• “我其实不太确定接下来该做什么。” 关于下一步和待处理任务的信息零散且混乱，因此在多个并行项目中，很难跟踪究竟还有哪些事情要做。
• “为什么我们现在才发现这个问题？” 当我们那位兢兢业业的工程师一直埋头做设计时，团队或公司中其他具备关键专业知识的同事却没有机会真正参与进来。他们的意见很可能来得太晚，最终让所有相关人员都放慢节奏、倍感挫败。

从表面上看，团队产出似乎应当随着贡献者人数线性增长。工程师人数翻倍，完成的工作量也应该翻倍。但如果每个人都需要与其他所有人协调，那么一个由 n 人组成的团队就会有 n(n-1)/2 个两两连接，正如 Frederick P. Brooks Jr. 在 The Mythical Man-Month: Essays on Software Engineering（Addison-Wesley，1995）第 2 章中所指出的那样。5 个人有 10 种可能连接；10 个人则有 45 种。人数翻倍，可能的连接数量却会增长到四倍以上，呈现二次方趋势。

当然，如果这些连接中的每一个都有可能阻塞工作，让我们的待办事项列表里塞满 等待评审、 待澄清后继续，以及 因遗漏需求而需要返工 之类的状态，那我们几乎永远都无法完成任何工作。在 PCB 设计中，即便是一些看似微小的问题——例如同事没有 ECAD 许可证，或者资深工程师审查的是过时的 PDF 打印件——累积起来，也会比本应如此的程度更严重地拖慢项目进度。

来自软件巨头的经验

软件团队并不是最早遇到这个问题的。不过，软件团队有一个明显优势：他们不仅能够制定高效流程，还能用同一套技能自行构建落实这些流程的工具。

代码评审就是一个很好的例子。项目越大、越复杂，参与开发的人越多，所需的代码评审也就越多。然而，尽管这些年来编写的代码量惊人，代码评审的扩展性却表现得相当出色。

Google 在 2014 年到 2016 年间，拥有超过 25,000 名开发者，分布在数十个办公室中，每个工作日进行超过 20,000 次变更，并要求每一项变更在提交前都必须经过评审。当 Caitlin Sadowski 及其同事研究这一流程时，他们发现，开发者对小型变更等待初始反馈的中位时间不到一小时，而任意规模评审的中位完成时间都不到四小时。

即使在十多年前，这些评审也基本不是通过开会、Teams 通话，或把便利贴贴在白板上列待办来完成的。相反，作者先提交一项变更，然后自动化工具会根据代码归属、编程语言技能或基于团队的规则推荐评审者。每位评审者都会针对自己关注的具体代码行发表评论，通常直接在基于 Web 的评审工具中进行。用论文中的话说，这个循环“会持续进行，直到所有人都满意，或者补丁被放弃”。

不断壮大的硬件团队从软件中可以借鉴的，不是减少评审，尤其是在当下还要面对与 容易产生幻觉的 AI agents 协作所带来的挑战。真正的启示在于：当评审流程紧密衔接、异步进行并可迭代推进时，它就能以最优秀、要求最高的工程师所需要的速度运行，而无需等待每周一次的会议。

Altium Agile Teams 让大型团队能够直接围绕设计进行协作、评论和评审。工程师可以在 任何原理图或 PCB 对象上添加评论，并通过 @mention 标记同事，使问题在合适的上下文中传达给他们。随后，任何评论都可以 转换为任务并分配给同事；而且任何人——无论是电子工程师、机械工程师还是采购团队成员——都可以通过 Web 浏览器参与其中，而无需单独的 ECAD 许可证。

周期性评审 vs. 基于设计的评审

硬件开发流程

遗憾的是，硬件行业 不能完全照搬软件的评审习惯。软件测试套件或许可以在 CI 的大型 VM 上几分钟内跑完，但在硬件设计中，即使是简单测试也可能要花掉整整一个下午：配置仪器、在显微镜下返修元件、把 3 个探针稳稳按在微小测试焊盘上，同时冲着同事喊让他按下示波器上的 Single 按钮。与天生具有“无实体性”的软件不同，PCB 只有在完成制造、组装并成功上电调试后，才能得到充分评估。

由于每次构建都很慢，且变更成本高，硬件行业逐渐收敛出几种标准开发流程：

• EVT、DVT 和 PVT，即消费电子中广泛采用的工程验证、设计验证和生产验证阶段：它能工作吗？它是否使用面向量产的器件和工装满足要求？工厂能否规模化生产它？
• Stage-Gate，由 Robert G. Cooper 规范化提出，将从创意到上市的全过程划分为多个阶段，每个阶段都以一次继续/终止决策结束。
• APQP 和 PPAP（Production Part Approval Process，生产件批准程序），广泛用于汽车行业，包含从规划到上市后纠正措施的五个阶段。
• 医疗器械设计控制，现已纳入 FDA 的 Quality Management System Regulation，并自 2026 年 2 月 2 日起整合了 ISO 13485:2016。

这些流程有着共同的要素：明确定义的阶段、每个边界处的评审、严谨的修订记录，以及随着产品逐渐成熟、变更代价不断上升而日益收紧的变更控制。任何用于协作、评审和项目管理的解决方案，都必须支持不同开发流程所要求的灵活性。

让工具适配你的工作流

那么，Altium Agile Teams 如何融入这些开发流程？它并不是要取代这些流程，而是让工程团队和 IT 管理员能够定义与自身行业相匹配的工作流。工作流通过 Process Workflow Editor 构建，管理员可使用熟悉的工具，以图示方式绘制每一个步骤。

对于项目活动，例如 设计评审以及发布到 PLM 时，一个步骤可以：

• 通过自定义表单收集信息。
• 将任务、评审或审批分配给特定人员或某个群组。
• 向用户发送通知。
• 更改生命周期状态。
• 为流程收集项目数据。
• 将已发布的项目数据发布到已连接的 PLM 系统。

工作流还可以根据决策或结果进行分支，等待某个 PLM 操作完成，或者要求所有相关任务在完成前都已解决。

值得庆幸的是，没有人需要从头开始。Altium 提供了多种 标准工作流，例如：

• Ad-Hoc Review： 在没有正式通过/不通过结论的情况下收集反馈。
• Handoff Review： 决定设计是否可以进入下一阶段。
• Milestone Review： 重复执行工作和验证，直到设计被批准或驳回。
• Project Releaser with Publish： 在发布流程中加入 PLM 发布。
• Publish to PLM (User selects)： 选择要发送到 PLM 的已发布输出。

此外， 元件请求使用相同的工作流和表单编辑器来管理新库元件的请求，从而确保工程师和元件库管理员都能获得一致的体验，同时强制执行生命周期策略。元件和已发布设计可以在易于理解的生命周期状态之间流转，例如 Prototype 和 Production；在发布时， Project Releaser可以运行 ERC、DRC 和元件状态检查，并拒绝发布包含未发布元件的电路板。

如果您在 PLM 中管理已发布数据，Agile Teams 可连接到 Duro 和 Arena。Duro 还提供 AI 辅助的变更影响分析。这有助于评审人员在签核之前预测拟议变更可能会如何影响元件、组件、进度和设计。

工作流会替您处理这些流程管理事务。工程师无需在事后填写表单、在会议后更新待办事项列表，或为审计整理记录；每一项请求、评审和审批都会在工作执行的同时自动记录在工作区中。

Agile Teams 不会替您定义开发流程，也不会仅凭自身让您符合 ISO 13485 标准。它的作用是运行并记录由您的团队定义的流程。

初创速度，企业级规范

硬件团队的发展壮大，不应意味着 放弃初创公司式的速度与灵活性。然而，随着团队规模扩大，同样的问题往往会开始出现：设计等待评审会议、下一步不清晰，以及专家意见来得太晚。而在监管要求严格的行业中，例如汽车、航空航天与国防，或受 ISO 13485 设计控制约束的医疗器械行业，草率的工作是不可接受的。

Altium Agile Teams 的设计目标就是将企业级规模与初创公司的灵活性结合起来，让工程师、机械设计师和其他团队成员能够协作、评论并评审设计，同时通过易于配置的工作流让流程顺畅运行。

进一步了解 Altium Agile Teams →

常见问题

为什么硬件工程团队会随着规模扩大而变慢？

主要不是设计工作本身，而是协调问题：工程师要等待评审、追踪不明确的下一步，还常常太晚才获得专家意见。团队成员之间的连接数量会呈平方级增长，因此协调至关重要。

减少工程评审会议的最佳方式是什么？

以异步方式评审设计。Altium Agile Teams 允许工程师直接对原理图和 PCB 对象发表评论、@提及同事，并将评论转化为任务，而无需等待下一次会议。

为什么硬件团队不能使用与软件团队相同的代码评审流程？

因为 PCB 是一种物理对象，只有在完成制造、组装和上电调试之后，才能对其进行完整评估，因此硬件团队会将工作划分为几个阶段，并在各阶段之间设置评审关卡。

Altium Agile Teams 能否强制执行与我们开发阶段相匹配的评审和发布工作流？

可以。管理员可以在 Process Workflow Editor 中绘制自己的流程，并将其同时用于项目和元件。