# 研发管理总结 > 源文件见附件[^1][^2] ## 总体框架 ![总体内容](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004212753809.png) ### **故障管理体系** 故障管理是研发过程中质量控制的核心环节，通过标准化流程识别、分析和解决问题，确保产品稳定性。其核心要素包括： **故障描述** - **定义**：对产品或系统异常现象的清晰记录，涵盖故障发生场景、表现形式、触发条件、影响范围等关键信息。 - **作用**：为后续根因分析提供基础数据，通常需附带故障日志、报错截图、测试用例复现步骤等支撑材料。 **故障根因** - **定义**：通过技术分析（如5Why法、鱼骨图）定位故障的根本原因，区分表面现象与深层机制（如硬件设计缺陷、软件逻辑错误、供应链物料问题等）。 - **要求**：需形成结构化分析报告，明确责任模块（硬件/软件/测试）及技术关联路径，避免停留在“现象复现”层面。 **影响结果** - **定义**：评估故障对产品功能、性能、用户体验、交付周期及成本的具体影响。 - **维度**： - **技术影响**：如模块功能失效、系统兼容性下降、性能指标不达标。 - **业务影响**：如研发进度延误、产线停线、客户投诉、市场准入风险。 - **量化指标**：需关联具体数据（如故障修复耗时、返工成本、交付延期天数）。 **更改措施** - **定义**：针对故障根因制定的解决方案，包括技术改进、流程优化、资源调配等。 - **分类**： - **短期措施**：临时修复方案（如补丁程序、硬件替换），快速恢复业务。 - **长期措施**：系统性改进（如设计规范更新、测试用例补充、供应商质量管控升级），避免同类问题复发。 ### **研发管理流程：从概念到计划阶段** 研发流程体现了从需求定义到执行落地的递进关系，核心阶段包括： #### 概念阶段 - **核心目标**：明确产品定义，锁定市场与技术可行性边界。 - **核心任务**： - **多维度需求确定**： - 功能需求：产品需实现的具体功能（如硬件模块的信号处理能力、软件的用户交互逻辑）。 - 性能指标：关键技术参数（如续航时间、运算速度、环境适应性温度范围）。 - 外观设计：工业设计要求（尺寸、材质、人机工程学适配）。 - 成本控制：目标BOM成本分解（芯片/结构件/辅料成本占比）。 - 周期规划：里程碑节点（需求确认、设计冻结、样品试制、量产时间）。 - **方案设计锁定**： - 技术路线论证：对比多种技术方案（如硬件架构选择、软件架构设计），评估性价比与风险。 - 跨部门评审：组织研发、市场、制造、采购团队确认方案可行性，形成《概念阶段评审报告》。 #### 计划阶段 - **核心目标**：将概念方案转化为可执行的研发计划，明确资源分配与过程管控机制。 - **关键管理模块**： - **ODM供方研发管理** - **适用场景**：委托外部供应商进行部分或全部研发任务（如PCB设计、嵌入式软件定制）。 - **管理重点**： - 合同约定：明确技术输出标准（原理图、LAYOUT文件、测试报告）、交付周期、知识产权归属。 - 过程管控：定期同步进度，审核阶段性成果（如原理图评审、样板测试），避免需求偏差。 - **进度管理** - **工具方法**：采用甘特图、关键路径法（CPM）拆解任务，识别依赖关系（如硬件LAYOUT需等待原理图冻结）。 - **风险应对**：预留缓冲时间，建立进度预警机制（如某环节延迟超10%时触发资源协调会议）。 - **研发全要素管理** - **涵盖范围**：贯穿技术、资源、质量的管理，包括： - 人员分工：明确研发团队角色（硬件工程师、软件工程师、测试工程师）及职责。 - 资源调配：设备采购（如示波器、高低温测试箱）、实验室预约、外部技术支持协调。 - 质量标准：制定研发各环节的交付质量要求（如原理图设计规范、代码编写标准）。 ### **文档体系：研发全周期的知识载体** 文档作为研发过程的“显性化成果”，分为**管理文档**与**技术文档**两类，支撑流程规范与知识传承： #### 管理文档：流程管控与决策依据 - **开发文档** - **定义**：记录研发过程的整体规划与阶段性成果，如《产品需求规格说明书》《研发项目计划书》。 - **作用**：作为跨部门协作的“语言标准”，避免需求理解偏差。 - **评审文档** - **类型**：包括概念评审、方案评审、样机评审等各阶段评审报告。 - **核心内容**：评审结论（通过/整改/否决）、问题清单、责任人和整改期限。 - **归档与版本更新** - **归档管理**：对最终生效的文档（如冻结的原理图、量产版BOM）进行受控存储，确保可追溯。 - **版本控制**：采用标准化命名规则（如V1.0、V1.1），记录每次修改的时间、原因及负责人（如“硬件变更：因EMC问题调整电容参数，XXX，2025.05.07”）。 - **基线管理** - **定义**：在关键里程碑节点（如方案冻结、试产通过）建立技术基线，作为后续变更的基准。 - **作用**：控制无序变更，确保各版本迭代的可追溯性（如“硬件基线V2.0包含10处EMC整改项”）。 #### 技术文档：研发执行与生产落地的技术指南 - **原理图与LAYOUT相关** - 原理图：电路设计的核心文件，标注元件参数、信号流向及接口定义。 - LAYOUT读图操作指南：指导PCB布局布线的规则（如阻抗控制、电源层分割），确保硬件设计可制造性。 - **测试方案** - 硬测方案：硬件测试大纲（如功能测试、可靠性测试、EMC测试），明确测试用例与判定标准。 - 产测方案：量产阶段的自动化测试方案（如ICT测试、FCT测试），保障批量生产质量。 - **生产支持文档** - 产线夹治具：用于产品装配与测试的专用工具设计图纸，提升产线效率。 - 硬件变更通知：记录硬件设计变更细节（如物料替换、PCB改版），同步给生产、采购、测试团队。 ### **体系化价值：构建研发管理的“数字孪生”** 上述模块通过“故障闭环管理-流程阶段衔接-文档知识沉淀”形成研发管理的完整链路，核心价值在于： - **质量可控**：故障管理机制提前识别风险，避免“带病量产”。 - **效率提升**：结构化流程与文档体系减少重复沟通，加速从概念到落地的转化。 - **知识传承**：标准化文档为后续项目提供经验参考，降低新人培训成本。 - **风险应对**：基线与版本管理支持问题回溯，便于快速定位历史变更影响。 通过将碎片化信息整合成逻辑化的管理框架，企业可基于此构建适配自身业务的研发管理体系，实现从“经验驱动”向“体系驱动”的升级。 以上是IPD流程的大致内容，涉及的相关人员这里不做赘述。 ## 开发文档 ![开发文档](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004212854942.png) 任何归档的文档必须有编号，方便追溯和更新，同时更新时需要说明更新内容。 归档后开发文档受控，必须进行评审，评审内容需要有风险分析和问题清单。 开发文档涵盖： - 需求文档 - 器件选型，包括器件的PQCT维度分析 - 可行性分析，主要是技术可行性 - 测试方案和测试报告 - 成本分析和降成本策略 - 竞品分析，一般是年底或者竞品上市时进行，需要深入分析到功能和性能 - 仿真分析：结构仿真（跌落、落球）、无线仿真（天线、射频）、热学仿真（温升）、光学仿真（折射、衍射、镀膜等） - 软硬件接口，即芯片管脚定义和用途，时序要求，电源上电和使能，Band通道切换等提供给软件的信息 - 三新器件，逐步被NUDD替代，整合其中 ## 技术文档 ![技术文档](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004212927801.png) 技术文档是生产相关的文档，有工艺文件、原理图、PCB、CAD、固件、配置文件等，也包含产线的SOP和EWI。 最基本的就是原理图和PCB，然后是测试相关（研发测试和产线测试）的文档，接着是夹治具的要求，最后是变更方面的PCN和ECN指令。 ### 读图指南 可以参考各自的checklist，以下只是列举其中较为常见的要求。 ![检查电源框架](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213004899.png) ![检查电源各模块](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213025013.png) ![检查外设接口](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213037468.png) ![检查GPIO口](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213048730.png) ![检查复位电路](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213102776.png) ![检查看门口](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213113115.png) ![检查测试点](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213123414.png) ![检查调试接口](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213135744.png) ## 故障管理 ![故障管理](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213213735.png) 故障管理是个极易忽视的能力，但往往这个地方浪费的人力成本都较高。理论上经过充分测试后，基本没有灾难性问题。上市后也就只是更新、修修补补。其实工程师日常工作80%是在解决问题（即故障），所以科学的去分析故障对于彻底解决问题非常有帮助，以免出现未彻底解决，问题重复出现，屁股擦不干净。 ### 故障描述 ![故障描述](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213223351.png) ![故障描述问题点](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213235930.png) 首先是故障描述，要求是人、事、物必须清楚，时间明了，通过5W2H原则进行整理，并根据时间线进行倒推，确认出现问题的时间线。这些信息看似冗余、繁琐，但是对寻求问题的根源很有帮助。 对于故障信息的描述，如上图所示，尽可能的提供详细信息。 ### 影响分析 ![影响结果](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213307973.png) ![RPN分析](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213325239.png) ![受影响方向分析](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213338593.png) 然后是进行影响分析，因为故障发生时往往还没有分析到原因，此时优先做影响分析，判断是否是紧急优先要解决的。 主要内容是风险分析、综合评估和各领域影响。 风险分析根据RPN进行判断，确定严重程度。 综合评估按照PQCT来分析，确定影响了什么东西。 各领域的影响是确定影响了谁，包括：用户、产线、软硬件、售后、客服、认证、仓库等方向。然后各领域评估影响结果和救火措施。 ### 故障根因 ![故障根因](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213415154.png) ![根因分析](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213425353.png) 接着是最重要的故障分析，需要确定要问题根因，并能彻底解决。即使不能彻底解决，也必须有解决率，比如发生概率降低多少百分比。 故障分析有很多方法，这里推荐先进行5WHY刨根问底，确认问题发生场景，最好能复现出来或者压测出来。 然后是确认问题原因，根据复现过程进行直接推理，交叉验证，快速定位问题点。如果无法复现或者偶发概率很低，此时需要进行前向分析，对所有可能的触发原因进行测试、排除。 ### 更改措施 ![更改措施](https://mythidea.oss-cn-beijing.aliyuncs.com/image-20231004213356831.png) 最后是问题关闭，进行措施导入。 临时措施是救火型措施，也许并不是根本解决措施，但是可以止血，也能快速导入。这种一般是拖字诀，给根因分析争取时间。因为根因分析出结果后，需要进行正常程序的导入验证，包括版本全流程测试、老化、可靠性测试等，往往就是一个月起步。 ## ODM管理 ![ODM供方研发管理](https://mythidea.oss-cn-beijing.aliyuncs.com/ODM%E4%BE%9B%E6%96%B9%E7%A0%94%E5%8F%91%E7%AE%A1%E7%90%86.png) 本阶段产品研发采用多方ODM与自主研发并行模式。以研发主导推进ODM方案设计，同时开展自主维度的方案设计。 工业设计（ID）、结构设计和硬件开发同步进行，各方独立评估。待产品RFI初步确定，所有ODM需统一对齐ID、结构、硬件方案，再进入最终设计阶段。 设计完成后，ODM需出具技术可行性评估报告并参与竞标，由项目组综合评估确定合作厂商。 硬件研发需严格把控概念阶段方案设计质量与器件选型合理性，内部SE需提出专业意见并输出文档，为后续工作提供指导。 ODM会谈及NRE费用和人力评估，必要时进行面试确定合格人选。如果上市成功，收益较高，可以给与适当的奖励，维持双方的友好合作关系。如果上市出现重大问题，也需要进行必要的惩处和反思。 ## Reference [^1]: [研发管理xmind](http://www.ivixivi.com/f/b054948127d6498980cd/?dl=1) [^2]: [研发管理pdf](http://www.ivixivi.com/f/cb3d21b47e224b47b0a7/?dl=1)