从“硬件工程师”到“项目经理”

B站影视 日本电影 2025-09-11 23:58 2

摘要:终于变成自己讨厌的样子:我前两天看到同事在画原理图,他已经不只是一个硬件工程师了,我们期望他成长为“项目经理”,管教育无人机的项目。早上安排的任务,要跟一个客户签订一个新合同。

终于变成自己讨厌的样子:我前两天看到同事在画原理图,他已经不只是一个硬件工程师了,我们期望他成长为“项目经理”,管教育无人机的项目。早上安排的任务,要跟一个客户签订一个新合同。

结果这位新项目经理,却在“悠闲”的画着“原理图”。

我跟他说:“你怎么还有闲工夫画原理图?你赶紧把合同做好,跟客户签了啊。”

很多硬件工程师内心其实也很矛盾:即希望能很单纯的做事情,把硬件做好;又想“当官”,做主管,做硬件经理,产品经理,或者项目经理,因为主管才可以掌握更多的资源和更好的职场上升通道。

但是你一旦成为产品经理或者项目经理,就需要离开自己的“舒适区”——硬件设计,画图,测试,调试等等。而需要端到端的思考产品,面对更繁琐稀碎的工作内容,并且需要更多的跟人打交道。不是简单的跟“电路板”打交道。

针对硬件开发/生产中繁杂琐碎的工作(质量、成本、进度),解决的核心思路在于系统化、标准化、数字化和自动化

1、遗留问题跟踪表:从纸面到动态闭环

我个人有两个特点,我早期上班时,喜欢做有挑战的事情,不喜欢做重复性事务;喜欢做创新类工作,不愿意做繁杂琐碎的事情。所以,我一开始不用管项目的时候,我就是一个屌丝工程师。我用不着《遗留问题跟踪表》。第二个特点是,我记忆力超出常人的好,特别是记忆一些琐碎的事情,所以我用不着《遗留问题跟踪表》。我经常开会时是被抨击没有好好使用这个工具的。

但是随着项目的复杂度提高,我管理的员工和项目的增加,不可能记住所有细节,也不可能完全靠我自己的记忆去统一其他人的想法。所以用Excel表格是必然。

我用遗留问题跟踪表用的最好的是,装修和结婚的。这两件事情,就是繁杂而琐碎,非常适合用这个工具。

工具化: 使用专业问题跟踪系统(如Jira, Bugzilla, Redmine,甚至具有自定义功能的Excel/Google Sheets模板,但推荐专业工具)。关键要素: 唯一ID、问题描述(现象、复现步骤)、严重等级/优先级、发现阶段(设计、测试、生产、售后)、责任工程师/团队、状态(新建、分析中、待修复、修复中、待验证、已关闭)、根本原因、解决方案、验证结果、关闭日期、相关附件(日志、图片、测试数据)。流程化:

定义清晰的问题生命周期流程(提交->分配->分析->修复->验证->关闭),规定每个状态转换的条件和责任人。

可视化:

利用看板(Kanban)视图直观展示问题状态分布(新建、进行中、阻塞、已完成)。设定自动邮件提醒(如问题超期未处理)。

定期评审:

固定时间(如每周)进行问题评审会议,聚焦高优先级、长期未关闭、反复出现的问题,推动解决。

根因分析:

强制要求对重大问题(或重复发生问题)进行根因分析(5 Why, Fishbone),并在问题记录中体现,防止治标不治本。

勤跟踪:

既然刚刚说了“管理是,重点在‘理’”,“任务跟踪表是绩效辅导工具”,那么管理者就需要时刻关注执行者的方向和进展。而不是可以坐享其成,等待丰收。需要在研发的进展过程中,去识别能力GAP,技术短板,有的放矢的进行技术辅导,安排讨论,组织培训……管理者的勤勉,才能保证项目的进展,才能帮助员工提升。

要闭环:

所有已经制定的计划,都需要完成闭环。不能随意关闭问题。例如:有一些网上问题,或者一些实验室问题,都需要记录下来,对问题进行复现和分析。而有些低概率事件,往往就不容易复现。如果每个人都可以随意关闭问题,那么很快任务跟踪就变成虚假摆设了。所以整个团队,研发管理者,需要对团队和自己有高标准严要求,才能不轻易放过问题,才能持续改进。

要注意问题跟踪的频度,管理成本:

每十五分钟的奇葩管理方式应该还是很少的,因为大多数管理者还是有常识的。但是我们的管理频度设置为多少才合理呢?

这里呢,我觉得没有一定的标准。但是我给一个建议:平时,每天自动发布日报,每周组织例会。按需求组织技术讨论,员工自发组织讲解。攻关阶段,每天组织晨会,每天下班前汇报进展。

员工自动自发的进行汇报,自行组织讲解,不是一朝一夕能够达成的,这个需要很长时间的磨合和训练。很多很多的动作,形成一个习惯,很多很多的习惯,形成一种传统,很多很多传统,形成一种文化。一个组织的文化,需要领导者带头,全体人员共同努力。

个人建议的普通员工的任务跟踪表的组成部分,如上图所示。

周例会,关注TOP问题。如上图

每天只做重要的事情,如上图。

任务跟踪记录,要符合SMART原则。

2、梳理采购BOM和销售BOM

我让一位硬件工程整理采购BOM和销售BOM并梳理所有采购计划。他问我:这还要我来弄啊?

我的回答是:如果你只想做个画板子的工程师,可以不弄;如果你成为项目负责人、硬件经理,那你不光是得弄这些事情,并且需要从如何保障产品完美交付的角度,倒推自己应该做哪些事情。

设计BOM:

反映产品完整结构和设计选型(含替代料)。由工程师创建和维护。

采购BOM:

基于设计BOM生成,但需考虑,所有物料的采购来源是否靠谱,采购周期是否满足要求,采购价格是否合理。

销售BOM:

基于设计BOM生成,但需考虑:配备给客户的物料是否齐全?是否考虑非标非常规工具和材料的需求影响安装?

替代料策略落地:

明确主选和备选供应商/料号。

最小采购单元:

整合需成套采购的物料(如螺丝螺母垫片组合包)。

供应商信息:

关联主选和备选供应商、采购单价、MOQ/MPQ、采购周期。

配置选项:

清晰定义客户可选的配置项(如内存大小、颜色)及其对应的物料组合。

可售单元:

明确销售的最小单元(整机、套件、可选配件包)。

定价信息:

关联配置项价格(可选)。

BOM管理工具 (PLM是核心):

强烈建议实施产品生命周期管理工具(如PTC Windchill, Siemens Teamcenter, Arena PLM,或更轻量的OpenBOM)。这是解决BOM混乱的根本。

单一数据源: 在PLM中建立设计BOM 作为唯一源头。采购BOM和销售BOM应派生 自设计BOM。BOM层级与视图:变更管理 (ECN): 建立严格的工程变更流程。任何 设计变更必须通过ECN流程审批,PLM系统自动 将批准的变更同步到所有派生的BOM(采购、销售、生产)和受影响的文档(图纸、规格书)。这是保证BOM一致性的生命线!BOM对比工具: 利用PLM或Excel插件进行BOM版本间差异对比(新旧版本、设计vs采购/销售),快速定位变更点。

3、梳理计划的关键路径

定期更新进度:

要求负责人定期(如每天/每周)更新任务实际开始/完成百分比/完成日期。

重算关键路径: 进度更新后,工具自动重新计算关键路径。关键路径是动态变化的! 非关键路径的任务延误也可能变成关键。可视化与预警:

使用甘特图、燃尽图等可视化工具。设置预警(如关键路径任务延误超过X天自动通知)。

专业项目管理软件:

使用MS Project, Smartsheet, Jira (配合插件) 等工具进行项目计划编排。

详细任务分解:

将硬件项目拆解为足够细的、可分配的任务(如原理图设计->评审->PCB布局->仿真->评审->Gerber发布->打样->贴片->测试->整改->小批量...)。

定义依赖关系: 明确任务间的强依赖 (如B必须在A完成后才能开始)和弱依赖/资源依赖 资源分配与工期估算:

为关键任务分配负责人,基于历史数据或专家判断估算合理工期(考虑缓冲)。

关键路径识别: 工具会自动计算最长路径(总浮动时间为0或负的路径)。核心是识别出决定项目最早完成时间的那串任务链。动态更新与监控:聚焦关键路径:

项目经理核心工作之一是确保关键路径任务优先获得资源,解决其阻塞问题,压缩其工期(如并行工作、增加资源、技术优化)。

1、先定目标,做出整体计划,设置里程点

项目开始阶段,硬件项目经理为了统一全团队目标,设定了整体计划,这个计划除了定好项目的起点和终点以外,最重要的是定义我们项目中的里程碑节点。这就好像长跑中我们把20公里的跑步总长度分为几个为几公里长度的小目标,一个个目标跑出来,每跑一个看一下离之前的时间目标差距有多大,再根据体力情况和时间目标进行调整。

在做智能电源盒这个项目的时候,我们就是立项,设计和计划,单板投板,研发验收,客户验收这5个关键节点,每个节点都有一个可考察、可量化的目标。在项目执行的过程中,如果各个节点进度或质量差距很大,那就要对项目亮红灯预警了。

智能电源盒项目整体计划的设置

序号里程碑点里成碑时间阶段性目标1立项通过2月10日项目立项通过,确定项目的交付范围、整体计划、质量目标、资源要求。2总体设计计划细化3月15日1、硬件总体设计完成,确定设计方案2、项目计划细化。3单板回板4月7日硬件详细设计完成,单板加工回板,整机等关键配套回板。4研发验收6月15日产品研发阶段测试验证活动完成,质量问题全部解决。5客户验收7月15日设备小批量交付,在客户现成适用验收,软件功能优化。

2、分层细化项目计划,跟随项目开展逐步明晰项目计划

立项完成后,整体目标已经明确,随着项目总体设计逐步深入,对项目难度、关键风险也更加清楚了,这时候项目经理把硬件、整机、软件三个团队责任人召集在一起,分单板硬件开发计划、整机结构开发计划、产品软件开发计划三个部分,共同讨论,细化项目计划。

例如在硬件开发计划里,电源盒里3块PCB单板的投板回样时间,单元测试完成时间,功能测试完成时间等,硬件改板时间等进行细化。制定的计划是否合理依赖三点,首先是通过参与设计并结合自己的经验深入理解项目难度,接着要掂量团队执行能力是否能达成目标表;另外,对和别的团队依赖关系要琢磨透了,比如这个项目中强电控制板试装和整机验证结果就影响5月中旬单板改板能否投出去,单板硬件责任人就要把什么时间必须完成试装和测试的要求提明确,从整机工程师那里拿一个承诺。

总结一下,对准整体计划制定的目标,项目计划需要通过集体讨论分层或分模块进行细化,并随着项目的开展逐步明晰。

3、找到计划中的关键路径,集中精力管理

硬件项目经理的精力是非常宝贵的,纵使你有三头六臂,也很难把项目计划中的每个细节都关注到,需要把有限的精力投入到最关键的地方。我们在这里推荐的就是在计划中标定出“关键路径”,之所以关键就是这些事务或工作中耦合关系多、执行难度大、延期风险高,对项目达成目标影响较大的,因为关键,值得项目经理集中精力管理。

在智能电源盒项目里,我们标定出两个关键路径。

关键路径①:是整机设计和初样验证的,对这种外观有定制要求,硬件集成度高,还有特殊环境适应性和安规要求的产品,整机设计、打样、试装问题解决一定要先于单板验证完成,把整机的问题先暴露出来。

关键路径②:项目开展各种验证后,要收集全发现的问题,完成单板的“定稿”。越是接近硬件项目的收官阶段,越是要冷静,把问题和风险收集全,判断项目的质量水平,完成整机、单板BOM、单板改板等工作,进入最后的项目冲刺阶段。

这些可能会影响项目成败的关键事务在项目制定计划时就要标定出来,项目执行阶段特别关注,“特事特办”,确保成功。

4、关注依赖关系,关注风险

智能电源盒的项目如火如荼的开展到5月第一周,整机试装已经完成,单板的调试和单元测试已经完成,经过硬件工程师内部对现阶段测试结论的评审,结论是PCB1需要通过改板解决发现硬件问题,PCB2、PC3两块模组单板只要优化BOM就能够解决所有硬件问题,同时,整机试装问题和EMC测试问题都已经在优化解决。现阶段,只要我们能保证PCB1顺利改板完成,落实PCB2和PCB3的单板BOM优化,我们就有信心项目准时顺利交付了,因此改板成为这个阶段最关键的工作,我们把主要的项目成员聚集到一起,再次去对齐计划,确保最后的交付工作万无一失。

序号工作内容完成时间责任人状态1硬件验查漏补缺,如智能电源模块上强电控制板预留的蓝牙模块、语音模块验证。5月10日老付(硬件)Open2软件功能相关测试查漏补缺,分析一下尚未完成集成验证的软件功能,那些和硬件相关,那些和5月12日小美(软件)Open3测试项评审,包括单元测试、整机测试、功能测试、软件相关项测试全部投板前的评审,全部发现的问题都已经解决。5月12日老付(硬件)Open4新物料准备,如变压器需要重新修改,解决已经发生的EMC问题,新变压器的修改要求和首批物料的采购要求5月13日小明(硬件)Open5物料清单优化,要把已经发现的问题上通过BOM修改优化。5月13日小明(硬件)Open6原理图/PCB改板投板:PCB1改板投板前做修改点集中评审,先核对是否所有修改点都已经落入PCB改板,再分析修改点是否对已经完成验证的功能、性能有影响。5月14日小明(硬件)Open7PCB改板投板后,优化钢网,为改板单板汇报试制做准备。5月17日小时(整机)Open

项目计划的执行不会是一帆风顺的,错综复杂的耦合关系会让项目在等待中消耗时间,出乎意料的风险会让延期措手不及,风险管理时项目执行中必要一环,在智能电源盒中通过一张风险管理表格,我们提早就开始预测项目风险,并提前准备应对措施。

智能电源盒中两个风险管理的例子

序号关键风险/依赖规避措施责任人1单板物料缺乏,软件、整机很多活动无法开展1、提前稳定BOM,做好研发阶段芯片备料。2、单板投板后催料PCB加工,联系生产资源,下线后空运送到研发。小明(硬件)2单板上市前要完成准入测试1、预约认证机构资源,完成专业认证。2、联系客户,约定时间进行客户现场验证。小时(整机)

4、变更管理 (EC)

正式流程:

建立书面的工程变更管理流程,明确变更申请、影响评估(BOM、成本、交期、库存、文档、测试等)、审批权限(跨部门)、执行、验证、关闭的步骤。

变更控制委员会:

成立涉及研发、工程、生产、采购、质量的变更控制委员会,负责重大变更的评审和批准。

变更记录与追溯: 在PLM/系统中完整记录每一次变更的原因、内容、批准人、执行情况、生效版本/批次。确保所有变更可追溯。

5、文档与数据管理

集中存储:

使用PLM系统或共享文档管理系统(如SharePoint配置库,带版本控制)统一管理所有设计文档(原理图、PCB、Gerber、3D模型)、规格书、测试报告、工艺文件、认证证书等。

版本控制:

所有文档必须受版本控制。确保任何地方使用的都是最新有效版本。使用"发布"机制而非直接修改共享文件。

关联性:

将文档与其关联的BOM项、项目任务、问题记录等建立链接。

6、风险管理 - 提前识别,主动应对

风险登记册:

建立项目风险登记册(可用共享表格或Jira等工具)。

风险识别:

定期(如在每个阶段开始、发生重大变更后)进行风险识别,涵盖技术风险(新技术、设计挑战)、供应链风险(长周期物料、单一来源)、制程风险(新工艺、高精度要求)、质量风险、进度风险等。

风险评估:

评估风险发生的概率和影响(严重度)。

风险应对: 为高风险项制定预防措施(降低概率)和应急计划(减轻影响),分配负责人。

7、测试管理与跟踪 - 质量保障闭环

测试用例管理工具:

使用TestRail, Xray (for Jira), qTest等工具管理硬件测试用例(DVT, PVT, 产线测试)。

测试计划与执行:

关联测试用例到需求/BOM项/版本,计划测试轮次,记录每次测试的执行结果(通过/失败、截图、日志)。

缺陷关联:

发现的缺陷自动/手动关联回问题跟踪表(Jira Issue)。

测试覆盖率报告: 生成报告,清晰展示对需求/BOM的测试覆盖情况。

8、供应链协调与物料跟踪 - 确保供应顺畅

早期供应商参与:

在选型阶段邀请采购/供应商参与,评估物料可获得性、成本和风险。

物料状态看板:

建立关键物料状态跟踪表/看板(可用共享表格或BI工具),包含料号、描述、供应商、需求日期、承诺交期、实际到货、在途数量、库存水平、风险状态(如缺料预警)。

关键长周期物料: 对Lead Time超长的物料(如专用芯片、定制件),要特别标记 ,在项目计划中尽早下单 (即使有风险),并密切跟踪。缺料风险会议: 定期(如每周)召开由采购、计划、研发、生产参与的缺料风险评审会

9、自动化脚本 - 解放人力,减少错误

报表自动生成:

编写脚本(Python, VBA等)从各系统(问题跟踪、PLM、项目管理)提取数据,自动生成每日/周报(遗留问题状态、关键路径进展、高风险物料清单、BOM变更摘要等)。

BOM/数据校验:

编写脚本检查BOM完整性(必填字段)、一致性(与设计文件)、合规性(禁用/替代料规则)。

工具间数据同步:

在缺乏统一平台时,编写脚本在关键工具间同步必要数据(如在Jira问题和测试用例间同步状态)。

统一平台 (PLM为核心):

这是解决硬件数据(BOM、文档、变更、问题)碎片化的终极方案。前期投入大,但长期收益巨大。

流程制度化:

将前述各项(问题跟踪、BOM管理、计划管理、变更管理、文档管理)都形成明确的书面流程,并培训所有相关人员遵守。

责任到人:

每项任务、每个问题、每个BOM项、每个风险点都必须有明确的责任人。

持续改进:

定期回顾(如每季度),审视哪些流程无效、哪些工具不好用、哪些琐事可以进一步自动化/简化,不断优化。

数据驱动:

利用系统积累的数据进行分析(问题趋势、项目延期原因、供应商表现、测试通过率),指导决策和流程改进。

拥抱(适度)自动化:

对高度重复、规则明确的手工操作(数据录入、报表生成、简单校验),积极寻求自动化脚本或工具内置功能的解决方案。

解决硬件繁杂琐碎工作的本质,是把零散的信息流和工作流,通过工具和规则整合成清晰、可控、可追溯的系统工程。 这需要决心和投入,但能极大提升效率、减少错误、缩短交付周期,并为后续项目提供宝贵经验。从最痛点入手(如遗留问题积压或BOM混乱),逐步推行这些方案,你会感受到显著变化。

来源:硬件十万个为什么

相关推荐