项目管理

浏览我们的资源库，详细了解项目管理在PCB设计。

Articles

View More Articles

敏捷硬件开发博客系列封面

5种硬件开发的不同之处探索在电子硬件开发中实施敏捷方法论的独特挑战和策略。理解硬件和软件开发在敏捷框架内的关键差异。

《工程师PCB设计指南：第1部分》团队

Guide Books 《工程师PCB设计指南：第1部分》团队简介哪些人员参与PCB设计和工程过程？当然，创建PCB布局的所有任务都不是单枪匹马就能完成的。要将愿景变为现实，必须利用和管理许多工程和科学专业领域。作为项目工程师，您的首要任务是确定团队。《工程师PCB设计指南》第1部分：团队《工程师PCB设计指南：第1部分》是免费PCB设计图书系列中的第一本，可作为初学者/学生或电子工程专业人士的手册。该系列将从工程师的角度解读生产印刷电路板（PCB）的方法、阶段和实践。从构思到交付完全装配的PCB，我们使用在线PCB设计软件以及可根据您的特定需求定制的经验证行业实践，以指导您完成基本设计阶段。团队您的员工可以是以下成员（请参阅图1）：图1：基本PCB设计团队组织。设计工程师作为一名PCB工程师，您处于统领地位，既要平衡执行任务，又要管理下面列出的PCB设计团队以创建PCB。而且，您负责最终的PCB产品、最终签收和批准工作。您的责任大概就是这些。产品设计周期的成功取决于您有效管理内部和外部资源的能力，以及您可以用来完成产品开发的许多免费PCB工程师软件工具 ERP/MRP系统企业资源规划（ERP）和物料需求与规划（MRP）是一切的起点。从最初概念到最终产品，您的ERP/MRP系统在流程和规划的设计和开发方面发挥着重要作用。您的团队在设计和开发产品时使用的大多数软件工具都直接与MRP PCB材料系统对接。Altium Designer图书有一个供应商链接系统，该系统可以使用开放式数据库连接性（ODBC）连接直接关联到ERP/MRP系统。通过与外部供应资源的链接以及贵公司零件数据库的链接，您可以将所有这些数据无缝集成到供应链中。 PCB设计师CID+ 该团队成员应精通设计和PCB布局过程的各个方面。事实上，在某些情况下，您可能只需要移交完成的原理图和物料清单，PCB设计师即可完成剩下的工作，包括为您管理整个过程。这使您可以自由地专注于其他与项目相关的任务。PCB设计师应了解电子电路的电气特性以及如何应用和生成制造和装配PCB所需的文档。此外，设计师应精通与PCB制造相关的材料科学，以及与PCB装配相关的过程。非常适合接受过IPC（电子工业联接协会）培训并拥有CID（认证互连设计师，初级）或CID+（高级）头衔的设计师。CID和CID+是整个电子行业公认的珍贵专业资格证书。Altium Designer^®在技艺纯熟的PCB设计师手中化作PCB设计工具，可支持您收获PCB设计图书中呈现的成品结果。（注意：如果没有聘用PCB设计师，您必须听从机械工程师的意见，因为他们能够设计

团队协作与PCB设计

Whitepapers 团队合作与PCB设计曾经有一段时间，一旦电路设计完成，就会交给“PCB设计师”，然后由他们来完成电路板布局。但现在，随着平板电脑、智能手机甚至电子游戏等产品的复杂性增加，PCB的设计不再是单一人员的工作。产品的设计需要专家团队的合作，如果不能有效协作，就会浪费时间并引入错误。曾经有一段时间，一旦概念设计完成，就会交给“PCB设计师”，然后由他们来完成最终的PCB布局。但现在，随着平板电脑、智能手机甚至电子游戏等产品的复杂性增加，团队协作和PCB设计变得至关重要。产品的设计需要专家团队的合作，如果不能有效协作，就会浪费时间并引入错误。这个过程因为团队成员经常不在同一地点而变得更加复杂，因此，协调、记录和团队共享的软件工具对于顺畅的工作流程至关重要。本文探讨了在评估具有强大协作功能的PCB工具时经常被问到的几个问题： - 在没有强大的协作性PCB设计工具的情况下，在团队PCB设计环境中工作有什么缺点吗？ - 具有强大协作工具的PCB设计工具如何使您的团队受益？ - 在考虑PCB设计工具的选项时，您应该寻找哪些协作特性？在协作PCB设计环境中工作的陷阱在没有适当工具的协作氛围中，沟通是第一大挑战。无效的沟通会在设计过程中造成障碍、延误和失败——耗费时间和金钱。以下是四个严重问题，它们显著影响协作设计环境。产品生命周期管理和设计数据不同步：没有协作工具，设计师可能会不经意间更改设计的相同部分，导致致命的数据冲突。团队成员可能不得不面临使用过时版本、重做不必要的工作或尝试解决不一致性的选择。设计团队在使用MCAD和ECAD（电子设计师）之间的交换文件进行印刷电路板PCB设计工作时，采用的是静态文件传输数据库。虽然使用交换文件总比没有好，但极难确定哪些数据发生了变化，变化在哪里以及是谁做的更改。没有这些信息，真正的同步就无法发生，相同的问题就会再次出现。在同一个设计上的团队协作效率低下：能够查看设计中正在进行的所有工作对于高效的工作流程至关重要。所有参与的工程师都需要理解彼此的意图和愿景，这需要全面的沟通。然而，电子邮件线索、笔记和其他笨拙的沟通方法会破坏工作流程中的效率和生产力。这个过程是笨重的，如果有人没有被抄送到消息上——甚至当他们收到电子邮件时，他们可能不会及时阅读——信息就可能丢失。间歇性或罕见的PCB布局交换通常会在最终产品中导致问题，这意味着设计师必须追溯他们的步骤，确定违规的来源并重新设计。团队成员实际上是在做两次工作，以确保整体设计能够达到最终的PCB布局和原理图捕获签名。跨不同设计领域的沟通：虽然PCB设计师的工作重点是作为最终产品的一个元素的电路板，但实际上涉及许多人。电气和机械工程师以及CAD技术人员正在处理印刷电路板的形状，而在制造商方面——有制造专家，以及物流和供应链专家。接触PCB设计软件的每个团队使用不同的设计领域，几乎不可能用相同的“语言”进行沟通，同时在他们自己的原生应用程序中解释数据。多个领域没有集成到单一的、流畅的工作流程中，因此可以访问同一块板的多个设计师可能会影响其他有权访问项目的人的工作——创建冲突，导致成本高昂、耗时的错误。缺乏问责制：在PCB设计过程中，一个团队如果没有在协作氛围中工作，当他们到达项目末尾时会感到沮丧，只因发现了重大冲突。由于缺乏沟通和未能同步设计数据，出现了错误。但因为没有办法跟踪设计的变化并找到错误的来源，在非协作工作环境中，就没有问责制或透明度。更糟糕的是，团队成员可能会犯错误而不自知。因此，错误会继续发生——造成额外的成本和更多的时间，影响生产力。 PCB协作的好处：效率和一致性

关于敏捷硬件开发的常见误区封面照片

大多数敏捷“大师”对硬件开发的误解敏捷方法论，源于软件开发领域，被誉为技术行业的变革力量。然而，当我们进入硬件和电子开发领域时，敏捷原则的看似顺畅适应遇到了一系列挑战和误解。在这三部分探索的第一部分中，我们分析了硬件与软件开发之间差异引起的敏捷挑战。在本文中，我们将检验由敏捷“大师们”传播的神话。在深入探讨电子硬件开发中的敏捷细节之前，重要的是要澄清，我们的目的不是贬低敏捷教练和顾问。我们认识并感激他们帮助客户获得敏捷方法论好处的良好意图和热情。虽然一些批评可能源于对硬件细节的有限理解，但目的不是批评，而是有效地适应敏捷原则，以满足硬件开发的特定需求。我们的重点是调整敏捷策略，以在这一独特背景下发挥其好处，修改方法但保留原则。谬论 #1: 你必须保持灵活并适应敏捷大师正确地颂扬了迭代执行、反馈循环以及在软件的数字领域中蓬勃发展的快速适应能力的优点。然而，这些原则转移到硬件和电子的有形领域时，引入了一层在纯数字领域中未发现的复杂性。与软件相比，物理解决方案需要“完成”，以便订购零件、制造模具和满足严格的制造需求。敏捷对持续变化的呼吁与硬件的无情本质发生冲突，即使是在游戏后期需要进行的轻微更改也会产生连锁反应。作为回应，修改敏捷开发以适应硬件开发需要一种范式转变。这不是关于无休止的修改，而是基于快速学习和执行周期的明智、战略性调整和原型设计。这些旨在在时间、预算和资源的限制条件下最大化价值。敏捷灵活性与物理产品最终需求之间的平衡需要更加谨慎的迭代计划和对整个项目风险降低的深刻承诺。谣言 #2: 每个冲刺都必须开发一个可工作的原型虽然敏捷纯粹主义者经常宣扬每两到三周开发一个完全功能的原型 “冲刺”是实现敏捷的普遍“必须”，但这种方法在面对硬件和电子开发（以及预算）的现实时，其实际可行性就会崩溃。构建某物，展示进度，并使用这个成果来获得宝贵的技术和商业反馈以指导你的下一次迭代的想法是正确的。然而，每个硬件项目都是一个具有自己的目标、依赖关系、领先时间约束、需要创新的领域和风险的独特实体。每个项目都应该有其自己独特的原型制作和学习方法。要真正拥抱敏捷硬件产品开发，团队必须摒弃一刀切的思维模式。相反，他们必须仔细审视项目需求，然后合作制定一个创造性的、学习性的和原型设计策略。重要的是要认识到，“原型”可以是任何可展示的输出，从初步的宣传册到泡沫模型（就像史蒂夫·乔布斯著名的iPod模型，它能“让你口袋里放1000首歌”），甚至包括部分或完全功能的原型。神话#3：向待办事项列表添加故事，然后就开始敏捷方法的一个内在优势在于它们启动项目的速度比传统瀑布式方法要快得多。实际上，对于敏捷硬件电子项目，我们已经看到从概念识别到开发启动的周期显著缩短。这个周期，在传统的分阶段方法下通常需要数月甚至数年的时间，现在通过敏捷方法被压缩到了几周甚至几天。当然，这一戏剧性的结果部分原因是我们如何定义“开发启动”。在软件领域，这是直截了当的。敏捷大师倡导编写用户故事来定义软件功能，将它们优先排序到待办列表中，并启动一个冲刺。然而，在硬件领域，至少需要一些最初的规划来指导项目朝着正确的方向发展，这需要对架构、关键期望属性、约束以及其他因素有所了解。这种最初的努力似乎与敏捷原则“工作中的软件是进度的主要衡量标准”和“欢迎变更需求，即使是在开发后期”相冲突。