软硬件管理

"掌握测试与研发全流程，打造高效质量管理体系！" 本分享聚焦软硬件开发核心环节，涵盖设计、测试、管理三大维度。硬件部分详解设计流程、评审要素及常见问题对策；软件侧重点敏捷开发、配置管理及缺陷闭环。测试管理板块包含单元/集成/系统测试全周期模板，提供测试策略制定、风险应对及度量方法，特别解析BETA测试、原型样机准入标准等实战场景。附赠缺陷跟踪矩阵、评审检查表等实用工具模板，助您系统提升质量管控能力。

• 什么是产品经理
  • 什么是产品
    • 产品是价值交换的媒介
  • 第一个产品经理
    • 麦克·艾尔洛埃（日化巨头宝洁公司的一名员工）
  • 产品的快速验证和迭代
    • AB测试
      • 就是用A和B两个不同的版本进行随机对照测试
    • 千人千面
      • 就是根据算法对每个用户都有不同的推荐页面。即使是入行不久的新人，也可以通过这些标准化的测试工具，来逐渐加深对用户的理解，让他们做出及格线以上的产品
  • 如何做好产品
    • 宏观层面
    • 微观产品
  • 俞军
    • “如果不能打破自己的认知天花板，上前一步，那么你的产品经理生涯也就这样了。”
    • “需求与体验碰撞在一起，形成了双击效应。”
    • “用户不是人，而是需求的集合”
• 产品经理需要掌握的知识模型
  • 用户模型
    • 满足用户多场景需求
    • 增加用户使用产品的次数
  • 交易模型
    • 找出各利益相关方
      • 根据影响力收益不同
    • 创造有利可图的用户价值
      • 用户价值是产品为用户提供的效用组合
  • 资源模型
    • 善用资源
    • 先满足哪些用户需求
    • 先创造哪些用户价值
    • 权衡取舍
  • 高阶能力
    • 用户价值和商业价值闭环
    • 考虑成本和收益
    • 用户价值、商业价值、社会价值做到正确取舍
• 产品经理的职业成长路线图
  • 前五年
    • 新人到熟手的成长期
    • 选择新产品
    • 大量迭代
    • 一手认知
    • 验证反思自己的想法
  • 五年后
    • 高阶行列
    • 深挖用户模型和交易模型
    • 选择toC领域去长期耕耘
• 产品经理十二条
  • 1、产品经理首先是用户
  • 2、站在用户角度看待问题
  • 3、用户体验是一个完整的过程
  • 4、追求效果，不做没用的东西
  • 5、发现需求，而不是创造需求
  • 6、决定不做什么，往往比决定做什么更重要
  • 7、用户是很难被教育的，要迎合用户，而不是改变用户
  • 8、关注最大多数用户，在关键点上超越竞争对手，快速上线，在实践中不断改进
  • 9、给用户稳定的体验预期
  • 10、如果不确定该怎么做，就先学别人是怎么做的
  • 11、把用户当作傻瓜，不要让用户思考和选择，替用户预先想好
  • 12、不要给用户不想要的东西，任何没用的东西对用户都是一种伤害



• 1. 研发管理体系简介
  • 1.1. 产品开发的目标
    • 1.1.1. 多
      • 1.1.1.1. 提高产品占有率
    • 1.1.2. 快
      • 1.1.2.1. 提高产品开发效率
      • 1.1.2.2. 缩短产品开发时间
      • 1.1.2.3. 加快上市效率
    • 1.1.3. 好
      • 1.1.3.1. 提高产品质量
      • 1.1.3.2. 提高客户满意度
      • 1.1.3.3. 减少产品后期出现的问题
    • 1.1.4. 省
      • 1.1.4.1. 更低的产品研发成本
      • 1.1.4.2. 减少产品开发浪费
    • 1.1.5. 准
      • 1.1.5.1. 创新，满足细分市场客户需求
      • 1.1.5.2. 提高产品命中率
      • 1.1.5.3. 提高新产品收益
      • 1.1.5.4. 提高组织的研发能力
  • 1.2. 企业研发管理问题概述
    • 1.2.1. 产品开发过程中的问题和对策
      • 1.2.1.1. 不适合市场的需求/没有竞争力
        • 缺乏正确的研发理念
        • 缺乏前瞻性、有效的产品规划，没有系列化，被动响应市场和竞争
        • 没有以市场为导向，缺乏对市场的深入分析，闭门造车式的产品研发
        • 没有设立优先级评估标准，产品和技术开发项目缺乏合理的先后顺序，不能及时开发成功
        • 基于市场的创新，开发团队对产品的市场成功负责
        • 没有做好客户需求调研及市场预测，收集与分析程度不够，设计没有满足需求，需求经常变更导致设计多次修改
        • 产品市场定位不明确，没有特色和卖点，没有市场
        • 在开发实现前没有明确的定义产品概念
        • 充分的市场调研，从客户角度来定义需求，明确产品对客户的差异化价值，在项目任务书中明确产品的目标客户和竞争定位 实施需求管理流程
        • 成本太高，超出预期。缺乏对产品开发项目的费用和盈利分析
          • 开发过程中做好成本管控
          • DFM(Design for manufacture,面向制造的设计)，良好的可生产性是以经济的成本生产为前提
          • 采用标准件，优选件，CBB、归一化，尽量采用已有的标准部件进行组合
          • 信息、资源共享、技术共享与重用，避免重复开发，选用标准的产品平台，模块化设计
      • 1.2.1.2. 产品开发周期长，上市时间太晚
        • 我们公司的季节性产品-风扇/加湿器尤其有这个问题
        • 职能化的组织架构阻碍跨部门协作，没有形成项目团队，协调和沟通困难
        • 部门之间缺乏配合，影响上市后的等客户满意度
        • 建立跨部门的PDT团队，减少沟通和协调工作，提高沟通效率
        • 问题和缺陷没有及时解决，导致不断修改，测试和试产时间超出计划
        • 技术重用差，缺乏CBB(Common Building Block,共用模块)与经验、教训的积累与共享机制
        • 建立CBB库，提高重用，减少产品开发问题和缩短开发时间
        • 技术开发与产品开发没有分开，缺乏技术规划与运作机制
        • 技术难题无法解决，技术上存在障碍，关键技术无法突破
        • 产品开发和技术开发分离
        • 不规范、不一致、随意、接力式/串行的产品开发流程和方法，没有衡量指标，没有文档，依赖英雄
        • 流程不够完整，没有规定各个部门的活动，没有覆盖整个产品生命周期
        • 开发过程中管理有问题，概念和计划未充分考虑就急忙投入详细设计，后期频繁修改
        • 建立可裁剪的产品开发流程体系 实施并行开发工程
        • 关键人员离职，很多工作需要较长时间才能衔接
          • 建立开发规范，完善文档管理
        • 同时投入开发的产品与技术开发项目太多，超出资源许可的范围。项目普遍延期严重，项目质量不理想，重点项目资源得不到保证。
          • 这点跟我们公司的现状相符
        • 项目管理薄弱，效率低，包括进度、质量、成本、风险等计划和任务无法及时完成
        • 建立合理的项目组织、项目计划、监控流程 提高项目管理能力
          • 我们重视项目计划的原因
      • 1.2.1.3. 研发浪费严重、投资产品不赚钱
        • 3D打印验证多，还没能解决问题 产品试产次数多 产品测试样品损耗大 产线急着上线量产后，问题多，组装成本提高，物料损耗大
        • 缺乏产品战略及规划，没有从市场出发建立项目选择标准，选择项目更多的靠领导“拍脑袋”，随意性大
        • 没有明确的产品立项活动
        • 建立产品平台、产品线战略
        • 立项“拍脑袋”，没有完整的分析与评审
        • 在开发过程中缺乏业务决策评审。缺乏项目筛选机制，没有对项目的投资回报进行有效的分析和评估。
        • 缺乏决策评估团队，导致低价值项目占比过高
        • 以投资的观点评审项目里程碑（DCP）,及时取消不应该继续的项目
        • 项目缺乏资源（人力、技术）的保障
          • 我们公司现在也是项目团队刚成立，人手不足，经常缺乏、需要磨合 所以我们在面对这么多项目的时候，尤其需要确定好产品的优先顺序 集中资源，保证重点项目的进度/质量
          • 我们公司现在也是项目团队刚成立，人手不足，经常缺乏、需要磨合 所以我们在面对这么多项目的时候，尤其需要确定好产品的优先顺序 集中资源，保证重点项目的进度/质量
          • 运用产品组合分析方法，确定产品的优先顺序 在项目之间合理分配资源
      • 1.2.1.4. 产品开发质量时好时坏
        • 产品质量不稳定
        • 未建立或实施技术审核制度，技术评审不规范，评审要素缺乏持续完善，甚至没有评审
        • 产品出现大量问题和缺陷
        • 建立技术评审体系，及早发现问题，持续完善评审要素，减少问题的重复发生 保证足够的测试时间，形成经验问题库
        • 大量采用新器件、新模块和新技术
          • 稳定CBB库，提高产品质量
        • 技术不过关，不稳定
          • 有效的技术开发管理、研究、储备可靠先进的技术
      • 1.2.1.5. 产品开发团队士气不高
        • 需要鼓舞士气
        • 项目经理领导能力不足，执行比较随意，长官意识明显
          • 选拔合格的项目经理，发展领导能力
            • 招人/培养人
        • 缺乏对项目组的关注，沟通不足
          • 领导层、中层和执行层，各层面充分沟通
        • 评价不合理，激励不到位，缺乏有效的研发绩效考核和激励机制
          • 我们公司现在也是项目团队刚成立，人手不足，经常缺乏、需要磨合 所以我们在面对这么多项目的时候，尤其需要确定好产品的优先顺序 集中资源，保证重点项目的进度/质量
          • 解决做多做少一个样，做好做坏一个样的问题
        • 人员流动性大
        • 有效的评价和激励机制
        • 团队合作氛围不好
        • 产品开发过程中，各角色之间存在职责不清晰现象
        • 缺乏有效的培养机制，研发人员的职业化素质不足
        • 明确产品开发过程中每个阶段和节点的职责，关键交付物 持续培训和团队建设，形成团队合力
          • 目前培训工作这块有在做安排
    • 1.2.2. 研发各层级人员的问题汇总
      • 1.2.2.1. 高层
        • 研发投入大，但是产品总是不能按时量产
          • 延期
        • 公司资源究竟投到什么地方？重点项目的资源有没有得到有效保障？
          • 重点项目管理
        • 研发人员离职对公司和项目冲击很大，如何固化公司的知识库？
          • 需要加强我司的知识库管理，需要有专人来整理/优化/管理
        • 如何量化评估研发项目和研发人员的绩效
          • 做好绩效管理
        • 如何把研发工作量化管理，缺乏有效的数据支撑
          • 利用TB把工作量化
      • 1.2.2.2. 中层
        • 计划失控，无法按要求完成
        • 人员忙闲不均，工作不透明
        • 任务布置不下去，员工反馈工作很忙，但不知道忙什么？
        • 研发项目信息不透明，布置下去的工作不能天天盯着，无法实时监控
        • 解决方案
          • 利用TB把工作量化,同时监控好项目里程碑，做好项目风险管理
        • 过去犯过的错误重复犯，缺乏经验、教训的积累
        • 缺乏量化数据，绩效考核缺乏客观数据
        • 解决方案
          • 目前通过写日志的形式，还有更新TB上的项目状态
          • 做项目经验分享总结
      • 1.2.2.3. 一线员工
        • 同时承担多个项目的工作，如何安排好自己的工作时间
          • 解决方案
            • 掌握工具，梳理手上工作的轻重缓急
            • 使用好TB工具
        • 做多做少没区别，做得多领导也看不见，很委屈
        • 如何让领导在评价自己的绩效时，有客观的历史数据参考。
        • 解决方案
          • 实行绩效考核
          • 积极主动汇报工作，及时报告项目进度/风险
        • 如何做好每天的工作记录和总结，保证每天进步一小步？
        • 如何继承他人的意见/经验，避免犯同样的错误？
        • 解决方案
          • 目前通过写日志的形式，还有更新TB上的项目状态
          • 做项目经验分享总结
    • 1.2.3. 优秀的研发体系特征
      • 1.2.3.1. 对客户需求理解透彻
      • 1.2.3.2. 恰当的产品定位
      • 1.2.3.3. 集成的、结构化的、并行的产品开发流程
      • 1.2.3.4. 完善的项目管理机制
      • 1.2.3.5. 良好的设计能力和技术储备
      • 1.2.3.6. 全方位的质量保障和监控机制
      • 1.2.3.7. 顺畅的跨部门协同
      • 1.2.3.8. 清晰、明确、有前瞻性、切合实际的产品战略和产品规划
      • 1.2.3.9. 平台化、系列化的产品开发模式（技术预研、平台、技术规划、技术开发与产品开发分离）
      • 1.2.3.10. 产品线与资源线并重，研发经验、教训积累与分享，老中青比例合适的研发团队，有较好的人才梯队建设
  • 1.3. IPD体系介绍
    • 1.3.1. 关注要素
      • 1.3.1.1. 组织管理：职业化的人才梯队
      • 1.3.1.2. 市场管理：基于市场的创新、产品开发，产品开发是投资行为
      • 1.3.1.3. 流程管理：结构化流程、跨部门团队
      • 1.3.1.4. 产品管理：异步开发与重用，技术与产品开发分离
      • 
    • 1.3.2. IPD体系的7个特点
      • 1.3.2.1. 产品开发是一项投资行为，IPMT代表公司进行产品开发项目的投资分析和决策，优化投资组合管理
      • 1.3.2.2. 基于市场的研发，产品开发必须满足客户需求，而不是凭空推出自己认为是好的产品，杜绝“闭门造车”，着眼于一开始就把事情做正确。
      • 1.3.2.3. 平台化开发，所谓产品平台，就是一系列共用技术要素及这些要素组成的产品技术平台。
      • 1.3.2.4. 跨部门协作，产品开发绝不仅是研发部门的事情，需要市场、研发、采购、生产、财务等所有职能领域的跨部门协同。
      • 1.3.2.5. 结构化流程，将产品开发划分为若干阶段，明确各阶段的输入输出准则，关键控制点，统一产品开发的术语。
      • 1.3.2.6. 技术开发和产品开发分离
      • 1.3.2.7. 职业化人才梯队
      • 难点在于非结构化和过于结构化之间取得平衡，同时保证开发流程的效率和指导性。明确哪些角色和部门应当参与产品开发过程，什么时候参与、任务有哪些、输入和输出。进行开发阶段划分，过程中设置评审点（里程碑点），高层和技术专家参与开发过程。
    • 1.3.3. IPD适用的6种条件
      • 1.3.3.1. 产品或项目多，员工按各自的习惯做项目，研发定义的产品不赚钱，甚至亏钱的项目多
      • 1.3.3.2. 企业研发规模相对比较大，人员急速扩张，没有统一的工作方法
      • 1.3.3.3. 行业进入稳定发展期，产品没有太多的新技术，创新
      • 1.3.3.4. 长周期的项目，指产品投入开发到退市的周期，研发周期长、投入大、短则半年，长则数年的项目，上市后的产品存活周期也比较长
      • 1.3.3.5. 产品技术相对成熟，产品比较稳定
      • 1.3.3.6. 平台化开发，在研发“R&D”（研究与试验发展活动）中偏“D”的产品开发
      • 以上6条，我司都非常符合
    • 1.3.4. IPD推行可能存在的14个问题
      • 对于快速成长型企业，产品的战略远比开发流程重要。少而精的核心人员比建立一支“人多不干事”的重型团队重要。 又好又卖座的产品是由热爱产品的天才开发出来的，在人群中，天才是少数，庸才是多数。识别好、选拔对这些产品天才，给他们足够的授权，设计好结果导向的激励措施，远远比搞细致的流程、评审、绩效体系更重要。
      • IPD的一些理念很好，也能对企业的管理水平和产品开发有一定的帮助，但是要清醒地认识到IPD不是灵丹妙药。公司生意不好，靠IPD是很难就变好的。IPD等管理手法适用于企业所处行业发展不错，企业自身发展也比较快的公司。IPD也不能决定企业的产品战略发展方向，只能是用一套规范的方法保证、确定研发的产品按照流程研发出来。另外，IPD也不能替代人，企业管理能力的核心是人。
      • 1.3.4.1. 标准的流程不适用于具体企业，没有根据企业的实际情况进行充分的定制，导致流程没有可操作性
        • 目前我们公司的流程，也是刚刚建立起来，是按公司的实际情况做的。但是需要不断的试行与改善
      • 1.3.4.2. 制定了一套流程，但成为“一堆A4纸”存了起来，没有落实和执行，也没有不断地改进
        • 我们公司现在也是刚建立了一套流程，但是目前却还没有执行起来，还是按之前的方式在做项目，需要结合公司的情况。真的把流程跑起来
      • 1.3.4.3. 只有跨部门流程，却没有跨部门团队和各功能部门组织能力支撑
        • PDT职位职责不清楚，缺乏合理的绩效指标
        • 产品线和资源线之间的关系没有定义清楚，PDT没有充分授权，无法调动资源
        • PDT成员大部分来自研发，市场、采购、财务、生产和服务参与度不够。参与PDT工作前缺乏全面深入的培训，尤其是项目管理、跨部门沟通技能。PDT成员年轻，缺乏流程开发经验。
      • 1.3.4.4. 对企业内部人员提出了新的要求，尤其是产品管理人员。项目经理不具备足够的能力和权威管理跨部门项目组，导致项目运作困难。
      • 1.3.4.5. 流程管理部门制作流程、制度和模板，各专业部门不参与
      • 1.3.4.6. 流程范围仅聚焦在研发部门，绝大部分的企业把产品开发的成败归结于研发部门
      • 1.3.4.7. 没有时间严格执行结构化流程，研发人员认为项目交期太紧，没有时间严格走流程
      • 1.3.4.8. 要写太多文档，研发人员认为大部分时间都花在写模板上，没有时间做开发
      • 1.3.4.9. 没有足够的资源执行流程，每人身兼数职或项目经理负责远超过正常水平数量的项目
      • 1.3.4.10. 没有产品数据管理方案，如物料和BOM管理，产品开发过程中的图纸和文档管理方案，对产品数据管理难以有直接的支持和效果。
      • 1.3.4.11. 决策层、管理层和专家介入不当，要么介入太多，要么介入太少。
        • 介入太多，不能充分调动项目组成员的积极性和责任心，或者因为决策层、管理层的影响力导致决策层、管理层提出的绝大多数建议被采纳。
        • 介入太少，又不能充分发挥决策评审和技术评审的作用，也影响项目质量
      • 1.3.4.12. 过于重视流程，忽略了核心技术对产品和项目的影响，核心技术在关键路径上，应当提前进行技术开发
      • 1.3.4.13. 由于成本和范围的因素，导致顾问公司没有持续跟进，由于公司内部人员变动过快，导致制定的流程没有在新的项目上有效执行。
      • 1.3.4.14. 没有IT工具落地
  • 1.4. 快速成长型企业研发提升方向
    • 1.4.1. 研发能力提升路径图
      • 
      • 1.4.1.1. 综合
        • 朝远期发展
        • 近期
          • 研发组织（跨组织团队）
        • 中期
          • 研发组织（弱矩阵式组织）
          • 业务决策评审
        • 远期
          • 研发组织（强矩阵式组织，技术走向管理）
          • 人才培养机制
          • 研发绩效
        • 朝中期发展
      • 1.4.1.2. 效率
        • 朝中期发展
        • 近期
          • 物料和BOM管理
        • 中期
          • 市场管理
          • 项目管理
          • 产品开发流程（并行工程，跨部门协同，系统工程）
          • 技术预研与平台规划
          • CBB
        • 远期
          • 需求管理
      • 1.4.1.3. 质量
        • 目前这块不好界定，都有做，但是都需要完善，尤其是文档管理跟测试
        • 近期
          • 产品开发流程（概念到发布）
          • 产品文档管理
          • 工程变更管理
        • 中期
          • 技术评审，同行评审
          • 研发流程深化应用
          • 产品开发流程（支撑流程，生命周期管理，设计规范，工艺管理，测试管理）
        • 远期
          • 市场管理
          • 供应商协同
          • 认证和合规管理
          • 测试及问题跟踪
      • 1.4.1.4. 成本
        • 目前这块做的可以
        • 近期
          • 物料和BOM管理
          • 新物料引入流程
        • 中期
          • 产品成本管理
        • 远期
      • 1.4.1.5. 创新
        • 这块需要重点加强，基本从零开始
        • 近期
        • 中期
          • 技术平台管理
          • 需求管理
        • 远期
          • 创新管理
      • 1.4.1.6. IT
        • 处于中期阶段，需要加强工艺管理
        • 近期
          • 物料管理
          • BOM管理
          • 核心流程管理
          • 技术文档管理
          • 工程变更管理
          • 设计工具集成
          • ERP集成
        • 中期
          • 项目管理
          • 需求管理
          • 测试管理
        • 远期
          • 工艺管理
    • 1.4.2. 研发能力提升的方法汇总
      • 1.4.2.1. 降低产品成本
        • 减少产品数量，减少产品开发费用
          • 做好市场调研，决策评审，集中资源开发有价值的产品
        • 加强成本意识，开发过程中关注产品成本
          • 在产品的整个开发过程中，全程关注成本（研发成本/材料成本/生产成本）
        • DFM,良好的可生产性是以经济的成本生产为前提
          • 做好DFM评审
        • 采用标准件、优选件，CBB、归一化，尽量采用已有的标准部件进行组合。
          • 做好CBB，把产品研发标准化，提高研发效率，减少研发风险
        • 信息、资源共享、技术共享与重用，避免重复开发，选用标准的产品平台，模块化设计。
          • 把产品开发平台化，提高开发效率
        • 提高质量，降低质量损失。
        • 降低原料、物料的消耗，考虑全生命周期的成本
        • 提高开发质量，产品生产的时候直通率高。就会大大降低成本
      • 1.4.2.2. 提高产品质量
        • 设计过程中质量保证，严格的技术评审， 规范测试过程，减少产品缺陷
          • 提高研发、设计的质量，把产品的风险控制在前期
        • 从优选器件中选择器件，基于产品平台的研发模式，尽量采用成熟的技术（货架技术）
          • 用好的器件+成熟的技术，减少产品风险
        • 减少制造缺陷，及时记录、跟踪、解决问题
          • 保证生产的质量，并积极生产中的质量问题
      • 1.4.2.3. 提高产品开发效率
        • 把握源头、减少需求变更，提高项目前期（需求、设计）周期与投入
          • 前期加强需求管理与分析，确定好需求
        • 提高项目管理效率，压缩产品开发周期
          • 提高团队项目管理能力，专业技能。与供应商共同分享技术经验，共同成长
        • 并行研发，技术开发与产品开发分离
        • 化解技术风险，研发知识库持续积累，
        • 需要在产品研发的时候，提前把技术与产品分开，做并行，以免影响整个产品周期。同时注意知识库的积累
        • 减少资源瓶颈，转变观念（从改变员工到寻找合适的人），外包也是一个非常不错的选择
          • 不要让人力/物力影响
  • 1.5. 子主题
• 2. 企业及研发组织
  • 2.1. 产品研发各部门的职责内容
    • 2.1.1. 市场与规划
      • 2.1.1.1. 市场分析、竞争分析、需求调研和管理、早期发货、营销策划、上市计划、推广和销售（渠道和直销）、市场领域评审
      • 2.1.1.2. 确保客户的需求能及时满足，对需求建立跟踪机制，并对需求实现进行验证，定期评估执行的绩效，根据市场需求及时调整战略规划
    • 2.1.2. 研发
      • 2.1.2.1. 产品创意与概念设计、项目管理、需求管理、系统和子系统设计、测试、变更、工艺、研发领域技术评审
      • 2.1.2.2. 计划：市场、产品、技术预研和产品规划
      • 2.1.2.3. 开发：技术预研、平台开发、产品开发
      • 2.1.2.4. 测试：制定产品测试标准，测试验证
      • 2.1.2.5. 支持：产品的制造，市场导入
      • 2.1.2.6. 管理：项目管理、评审、人力资源、供应商、专利申报、技术培训
    • 2.1.3. 项目管理
      • 2.1.3.1. 项目管理活动，包括项目计划和控制、干系人管理、资源管理、沟通管理等
    • 2.1.4. 采购
      • 2.1.4.1. 供应商选择、认证和管理、新物料选型、执行采购、质量管理、采购领域评审
    • 2.1.5. 质量
      • 2.1.5.1. 组织进行质量目标设定、质量策划、质量管控
    • 2.1.6. 财务
      • 2.1.6.1. 目标成本管理，研发费用管理、财务分析、盈利分析
    • 2.1.7. 制造
      • 2.1.7.1. 订单预测与计划、制造策略与计划、制造调度控制、试制、新产品导入、订单履行、订单发货货运、制造领域评审
    • 2.1.8. 技术服务/售后
      • 2.1.8.1. 安装、维护、产品维修、问题解决、服务成本预测、客户服务策略与计划、服务领域评审
  • 2.2. 研发组织架构
    • 2.2.1. 职能型组织 （功能型组织）
      • 2.2.1.1. 描述
        • 每个职能部门的成员具有相同的技能和职能，仅对自己的职能经理负责，适合生产和销售标准产品的企业
      • 2.2.1.2. 优点
        • 职能分工，成本高效，专业化，技能提升
      • 2.2.1.3. 缺点
        • 不注重客户和项目，人们强烈忠于自己的部门。跨部门合作困难，效率低
    • 2.2.2. 矩阵型组织
      • 2.2.2.1. 描述
        • 项目经理对项目结构负责，职能经理为项目提供资源，共同为公司和项目的成功贡献力量，适合需要不断推出新产品的公司
      • 2.2.2.2. 优点
        • 资源共享，有助于员工技能的提升，注重客户，并能真正为客户负责
      • 2.2.2.3. 缺点
        • 双层汇报关系，沟通和协调复杂，员工的绩效考核办法比较复杂，资源经理和项目经理的权力平衡
      • 矩阵式架构相对扁平化，能够较好的解决忽视客户满意度，组织臃肿这些问题，同时激发小团队的效率，这也是我们团队，需要发展的方向
        • 弱矩阵的特点：项目局限在研发内部，项目经理类似项目协调员，关键项目决策仍需职能经理做出，部门间容易埋怨和相互责备
        • 强矩阵的特点：项目经理关注整个产品开发过程，对项目的人、财、物有绝对的领导权，项目成员代表职能部门对项目进行承诺，绝大多数的项目经理由资深的工程师兼任
    • 2.2.3. 项目型组织
      • 2.2.3.1. 描述
        • 项目成员在同一时间内全部投入一个项目，仅对自己的项目经理负责，适合以项目为主要业务的企业，如建筑业、咨询业等
      • 2.2.3.2. 优点
        • 项目经理是项目的真正领导人，效率高
      • 2.2.3.3. 缺点
        • 项目间缺乏人员和知识的交流和共享，对项目成员来说，缺乏一种事业的连续性和保障
  • 2.3. 两个跨组织团队
    • 2.3.1. 集成产品管理团队IPMT
      • 2.3.1.1. 职责
        • 负责产品投资决策和业务决策评审，制定企业总的战略和发展方向，对各产品线的运作进行指导和监控，推动产品线、研发、市场、销售、服务和供应链等部门的协作，制定企业的业务计划，对新产品进行业务决策。
      • 2.3.1.2. 主要关注点
        • 我们的战略是否正确？我们的技术是最先进的吗？下一个大规模的商业机会是什么？
        • 我们在每个细分市场上应建立何种竞争优势？我们怎样才能打入新市场？怎样才能使我们的产品系列得到最大的回报？
        • 我们应该怎么把公司合并进来？我们应该与哪些公司发展战略联盟？
        • 现有的项目组合中有哪些项目应当放弃？我们应该把哪些资源由一个项目转到另一个项目中去？
        • 替代产品推向市场时，是否已经制定了旧产品的停产计划？
        • 我们是否确定产品系列可以相互兼容与支撑？
        • 我们是否有合适的技术人员和资源
      • 2.3.1.3. 成员
        • 公司的总经理
        • 副经理级别
        • 技术总监
        • 研发总监
        • 账务总监
        • 市场总监
        • 采购总监
        • 制造总监
    • 2.3.2. 产品开发团队PDT
      • 2.3.2.1. 职责
        • 重点是执行工作，把产品推向市场。IPMT给PDT下发项目任务书，要求交付产品。
      • 2.3.2.2. 主要关注点
        • 在实现产品的进度、质量、成本目标方面，我们还应做什么？
        • 我们需要IPMT做出哪些决策？
        • 我们有无足够的人力和资源，在不降低产品功能的条件下准时完成产品开发？
        • 我们有无能力确保产品支持某种功能
      • 2.3.2.3. 角色
        • 产品经理
          • 建议由掌管职能部门的人承担，不能仅仅是协调工作的一般人员，需要对产品的最终表现承担责任
        • 项目经理
          • 建议由某个专业领域非常擅长的人转岗或者合理分配时间担任
      • 2.3.2.4. 成员
        • 采购
        • 开发
        • 生产
        • 质量
        • 财务
        • 市场
        • 营销
        • 客服
  • 2.4. 部门与职责
    • 2.4.1. 研发管理部设立的目标
      • 2.4.1.1. 结合公司实际情况优化研发流程，规范研发过程，同时提高研发质量与效率，保证各个部门之间有效的协作，确保产品数据作为公司的技术资产有效地保留和传承。提供资料开发和翻译服务，为产品开发的市场推广提供有效支持，负责产品认证工作。
    • 2.4.2. 研发管理部9大职责
      • 2.4.2.1. 研发绩效管理
        • 收集并统计研发绩效管理的基础数据，为研发绩效管理提供量化数据
      • 2.4.2.2. 流程制定与优化
        • 负责产品开发体系涉及的所有流程和PLM系统中所有与研发相关的工作流程的制定和持续优化，包括主流程、各级子流程、文件模板等
      • 2.4.2.3. 流程引导与培训
        • 根据各部门需求开展流程普及培训，项目各阶段引导PDT成员按流程开展各项活动，如果有需要，刚开展正式培训。
      • 2.4.2.4. 标准化
        • 负责维护产品、软件、物料、BOM相关规则，含编码、命名、描述、版本规则及审核发布流程
      • 2.4.2.5. 参与项目管理、过程审计
        • 根据项目状况引导工程师对项目进行关闭、暂停、恢复等操作，并对项目进行该操作的条件进行审核
        • 每周定期对项目计划、交付件、流程执行情况等进行例行审计，输出审计报告
      • 2.4.2.6. 组织并参与TR评审
        • 检查技术评审的准入条件，组织技术评审的过程，并参与技术评审
        • 监督评审过程的流程符合性，跟踪评审的遗留问题的解决情况。
      • 2.4.2.7. 组织研发质量回溯
        • 实时关注项目状况，观察是否存在重大质量隐患，如果发现隐患则及时启动质量回溯
        • 当接到客户/内部质量投诉、发生较大质量问题时组织质量回溯。质量回溯前收集数据、分析问题发生的原因，并给出初步的纠正预防措施，然后召集质量回溯会议。输出质量回溯报告，并跟踪问题解决情况，直到问题关闭
      • 2.4.2.8. 产品资料开发与翻译
        • 负责新产品资料开发，在研发工程师提供的初稿基础上完成中英文用户手册，快速安装指南的优化与翻译，并根据测试意见、客户反馈等进行必要的修改
        • 根据市场部门的需求，在研发工程师协助下，负责用户手册的开发。翻译客户所需的生产工艺、品质、维修手册等资料，整理、维护已有的用户手册
      • 2.4.2.9. PLM系统维护
        • 针对PLM系统进行操作培训，对各个部门提供PLM系统操作中出现的问题进行答疑，并解决用户由于对系统的理解、基本设置造成的问题。发现并收集PLM系统的缺陷（含易用性方面的需求），并提交供应商修改。
    • 2.4.3. 产品/项目管理部4大职责
      • 2.4.3.1. 前期策划
        • 参与前期投资机会研究，参与前期项目策划的方案选择，参与可行性论证和评审
      • 2.4.3.2. 组织新项目立项
        • 根据产品需求，确定待开发研究项目，申请立项、组织立项前的各项准备活动，负责组织项目立项会议并输出《项目任务书》，下达项目任务书，指定项目经理。
      • 2.4.3.3. 项目过程管理
        • 项目质量与进度管理，资金与资源管理，监控与报告，过程中的沟通协商，项目移交、验收、编写总结报告。
      • 2.4.3.4. 技术支持
        • 项目前期研究、试验与可行性分析，与客户进行技术交流并提供技术支持，起草技术协议
    • 2.4.4. 角色间沟通要素
      • 2.4.4.1. IPMT和LPDT、LMT项目经理
        • 项目任务书/合同，可衡量的项目目标，项目组授权，核心组成员，项目资金和资源的批准，DCP交付件的讨论和决策，项目风险计划、项目状态、项目问题（变化）
      • 2.4.4.2. IPMT和功能部门经理
        • 资源计划、能力、可获得性，资源分配
      • 2.4.4.3. 项目经理和功能部门经理
        • 项目计划活动/工作任务、资源需求、资源可获得性与分配，项目、功能部门和资源问题
      • 2.4.4.4. 项目经理和项目组成员
        • 项目任务书/合同，可衡量的项目目标，项目沟通与管理，项目计划内容与资源需求，项目计划活动/工作任务分配及状况，项目风险计划、团队决策，项目、功能部门和资源问题
      • 2.4.4.5. 功能部门经理和项目组成员
        • 授权团队代表功能部门并做出承诺，技能培养与培训，功能部门支持
  • 2.5. 理想的企业组织架构
    • 2.5.1. 单一产品线组织架构
      • 
    • 2.5.2. 单一产品线
      • 2.5.2.1. 特点
        • 专职的产品经理，产品开发和市场合二为一，需要授权产品经理为“小总经理”，否则产品经理可能形同虚设；
        • 专职的项目经理，研发部内部设立项目管理部的原因是很多企业项目经理都是由资深工程师兼任，或者项目助理文员跟进，往“专职”靠近一步。未来可逐步由产品经理负责
        • 研发管理部统筹研发管理、流程执行、资料开发和认证等工作
        • 公司级的PQA，若无法实现，短期可将PQA放在研发管理部下面
    • 2.5.3. 多产品线
      • 2.5.3.1. 特点
        • 可支持多产品体系，产品体系总监实际上就是大产品经理
        • 项目经理和产品经理合二为一
        • 将结构、硬件、软件工程师均划拔给对应的产品体系，使“产品体系总监”更具资源控制权
        • 每个产品体系增加系统设计部门，提高产品系统设计能力
        • 因为多产品体系，所以总体办划归到公司级的研发中心，提高公司级产品重用
        • 市场部转为单纯市场推广、信息收集职能
        • 若产品体系过多，可以在所有产品体系和研发中心上架设一层研发副总
        • 研发人员相对更有积极性，但过于强调研发人员的“单兵”能力，不利于研发人员的成长
    • 2.5.4. 产品经理组织的优缺点
      • 2.5.4.1. 优点
        • 产品营销组合要素得到较好的协调统一
        • 对市场上的问题进行快速反应
        • 弱项产品不会被忽略
        • 培养锻炼了管理人才
      • 2.5.4.2. 缺点
        • 与职能部门容易产生矛盾和摩擦
        • 产品经理的能力要求很强
        • 管理费用提高
        • 产品经理的项目性质导致关注短期效益
        • 产品经理难站在总部的角度考虑问题
          • 缺乏大局观
    • 2.5.5. 产品线职责
      • 2.5.5.1. 承接公司在本产品线的经营目标，对本领域的经营指标、投入产出、持续发展、市场成功负责
        • 范围
      • 2.5.5.2. 整合利用一切内外部资源，自主研发与开放合作相结合，把握市场节奏，最大限度地追求本领域的商业成功，创造商业价值
        • 目标
      • 2.5.5.3. 管理本产品线的客户需求、产品和技术开发，品牌管理、市场策略等产品全流程，包括生命周期、质量、成本等要素。分析竞争对手，捕捉市场机会，负责本领域的解决方案、产品规划和对外合作，市场拓展及产品销售。
        • 过程
      • 2.5.5.4. 管理本产品线预算，提高资源配置效率，支撑并促成IPMT关于产品规划、业务目标及业务策略及时、快速、准确地决策。
        • 资源
      • 2.5.5.5. 针对IPMT关于产品发展规划和业务目标及业务策略的决策，快速有效地运作实施。对本产品线的产品定价提供决策支撑，对本产品线的商务授权和经营利润负责，保证公司业务变革在本产品线的成功
        • 监控
  • 2.6. 技术走向管理
    • 这个需要重点讲，与我们团队的实际情况非常相符
    • 2.6.1. 技术人员的特点
      • 2.6.1.1. 不愿意遵守规则，一旦遵守，又死心塌地
      • 2.6.1.2. 自尊心强，易情绪化，易防守，IQ高，忽略EQ
      • 2.6.1.3. 不愿意求人，怕得罪人，爱单干，相对内向，蔑视权威，人际能力不足
      • 2.6.1.4. 不善于沟通，不愿意表达自己的真实想法
      • 2.6.1.5. 串行处理工作
      • 2.6.1.6. 专注执行
      • 技术转型管理常出现的几点，这是我们的优势，我们需要转变，让它不要成为我们转管理的绊脚石，需要灵活处理项目工作。
      • 2.6.1.7. 喜欢求新，追逐技术前沿，好奇心强，喜欢折腾，技术导向性强，市场、质量、时间意识不足
        • 这个尤其是我们目前在跟进项目进度的时候，存在最大的问题，需要强力扭转过来，把市场、质量、时间意识充分提高。做为我们在开展项目工作的3道红线。
      • 2.6.1.8. 专业素质高，工作严谨，追求精确
      • 2.6.1.9. 喜欢非黑即白
      • 2.6.1.10. 埋头拉车，拘泥于细节，性格比较执着，追求完美，容易忽略全局
      • 2.6.1.11. 流动意向明显
    • 2.6.2. 管理人员的要求
      • 2.6.2.1. 充满使命感
        • 保护持久的工作热情和高度负责的工作态度，自我激励和激励他人，挑战自我，追求卓越，不会“小富即安”
      • 2.6.2.2. 宽广的胸怀
        • 以事业成功为重，做到求大同存小异。包容地处理来自于他人的不同意见甚至冲突。清楚地知道反对自己的人的优点是什么？有哪些值得肯定与学习的地方，自己青睐的人有哪些缺点需要改进
      • 2.6.2.3. 良好的品德
        • 不能以权谋私，生活腐化，对公司发牢骚，讲坏话，必须自律，先管好自己
      • 2.6.2.4. 开阔的视野和结构性思维能力
        • 看到问题的本质并抓住工作的重点，不光要盯住“短木瓜”解决眼前的问题。建立机制以防范问题的能力，避免“头痛医头，脚痛医脚”。看清整体与局部的关系，抓住战略机会与战略制高点
      • 2.6.2.5. 均衡发展的管理能力
        • 善于“救火”，更善于“防火”。不能重业务轻管理，提高综合管理能力。除熟悉业务外，还须具备系统的财务，人力资源、运营管理、组织运作等管理知识与技能及较高的职业素养
      • 2.6.2.6. 善于学习
        • 只有学习型的组织，才能从容地面对高度不确定的商业环境，学会在实战中进行总结与举一反三。人是有记忆的，但是组织没有记忆，采取有效的措施保证个体的经验，在组织内传播与共享。建立一个系统以保证案例中所蕴藏的经验与教训在组织内进行有效的复制
  • 2.7. 人才培养机制
    • 标注
    • 2.7.1. 技术研发人才培养机制框架
      • 2.7.1.1. 开展技术研发人员专业能力素质评估，盘点能力差距
      • 2.7.1.2. 对应能力标准，将部门人员设立三级标准
        • 没有达到要求
        • 基本达到要求
        • 达到或超越目标要求
      • 2.7.1.3. 建立系统的技术研发培训课程体系，根据能力差距制定技术研发人员培训计划，列出月度培训计划，落实培训计划，提升员工能力，定期进行培训效果评估
    • 2.7.2. 专业能力标准示例
      • 2.7.2.1. 市场敏感
        • 对市场变化动态高度关注，对市场趋势敏感感知，按照市场趋势调整工作思路及方向的能力
      • 2.7.2.2. 客户导向
        • 以客户（包括内部客户和外部客户）为所有活动的中心，始终密切关注客户的需求和想法，为客户提供服务并致力于让客户满意，最终建立长期良好的客户关系，从而使集团受益
      • 2.7.2.3. 创新求进
        • 开辟新的学习渠道，获取新信息、新工具、新方法，产生有价值的想法，并使用这些想法来研发新技术能力
      • 2.7.2.4. 整合资源
        • 通过组织和协调，对企业内部分割的资源和企业外部可以利用的资源进行整合和优化，并通过对资源的有效的管理与配置，使资源使用率最大化。
      • 2.7.2.5. 项目管理
        • 能够规划、执行、监控项目全过程，协调和整合资源，在进度、质量与财务等方面实现项目目标的的能力
      • 2.7.2.6. 沟通协调
        • 内部员工之间或外部合作者之间交换信息、分享思想及感情的过程，并影响和产生实质的行动或结果。从整体利益最大化的角度出发，协调处理内、外的人际关系、冲突和矛盾，促成共赢合作
      • 2.7.2.7. 问题解决
        • 针对己发生的问题，采取合理的方法，并克服障碍和阻力，圆满解决问题。
      • 2.7.2.8. 自我管理
        • 准确认识自身能力，不断给自己设定更高、更新的目标，进行自我驱动与激励，时刻保持工作激情与积极心态，成功完成工作任务。
      • 2.7.2.9. PLM知识
        • 熟悉PLM平台的概念，日常操作
      • 2.7.2.10. 产品开发流程
        • 熟悉公司的产品开发流程，了解开发过程中的注意点和难点
    • 2.7.3. 快速培养人才计划
      • 2.7.3.1. 制定培养目标
        • 如半年内，加入培养计划的研发人员80%能够胜任项目经理角色
      • 2.7.3.2. 确定培养对象选择原则
        • 有着强烈的成长愿望
        • 对技术和研发品质执着追求
        • 员工自愿加入
        • 项目导师代表公司对培养对象的发展提供必要的支持，培养对象在遇到项目管理问题时，应首先向项目导师求助
      • 2.7.3.3. 明确能力要求、责任及绩效期望
        • 公司明确提出对项目经理的能力和知识技能的要求
          • 解决问题
          • 项目管理
          • 沟通协调
          • 团队管理等能力要求
          • PLM使用等技能要求
            • TB的使用
        • 公司明确提出对项目经理的职责和绩效期望
          • 项目周期管理
          • 项目质量
          • 项目成本
          • 知识分享等
      • 2.7.3.4. 制定培养计划和定期考核
        • 导师与参与共同研讨制定阶段性的培养计划，定期回顾计划执行情况，并进行阶段性考核和最终考核，考核结果将决定是否成为项目经理
    • 2.7.4. 如何培养产品经理
      • 已经跟团队都有聊过，大家都有意愿朝产品经理方向发展
      • 2.7.4.1. 企业常见的产品管理问题
        • 缺乏合格的产品经理
        • 缺乏有效的组织及流程体系
        • 过于依赖部分好的产品经理
      • 2.7.4.2. 产品经理的能力要求
        • 项目管理（含团队合作）能力占35%
        • 业务能力占20%
        • 技术能力占15%
        • 个人影响能力占15%
        • 沟通及处理冲突能力占15%
      • 2.7.4.3. 培养的方法
        • 周边部门锻炼
          • 市场部
          • 服务部
          • 制造部
          • 提高产品全流程意识和技能
          • 这个可能不太好实现
        • 参加相关知识的技能培训，特别是提高软技能
          • 情绪控制能力
          • 领导力
          • 团队沟通等能力
          • 可以组织培训
        • 通过在产品经理/PDT经理助理等岗位上进行培训，获取经验
        • 与一些资深经理探讨、学习
        • 自我批评总结，不断学习总结、改正错误
        • 敢于压担子，充分授权，明确责权利
        • 在日常过程中执行
    • 2.7.5. 项目经理应该具备的7大能力
      • 2.7.5.1. 项目经理存在的一些常见的问题
        • 事无巨细、事必躬亲、亲力亲为，沉于事务性工作，不能抓住重点，自己太累
        • 缺乏狼性，成功欲望不足，开拓性、侵略性不足，多半扮演了一个保姆、管家的角色。缺乏警察与工头的个性，危机意识与警觉性不够；
        • 管理太软，对下属不敢严加管理，太仁慈，不能做“魔鬼”；
        • 激励和沟通能力差，不善于交流协调，经验不足，对周边部门的推动不够，缺乏号召力，个性上欠缺领袖魅力；
        • 不能提前预测问题和风险
      • 2.7.5.2. 项目经理能力要求
        • 综合能力
          • 综合素质高，不一定是技术专家或管理专家，但知识面要广，思路要开阔。协调和沟通能力强，善于调用资源，包括项目外部资源的利用和内部资源的调配。总是能记住项目的总体目标
        • 业务/技术知识
          • 了解业界相关的技术、公司愿景和核心业务，理解业务决策的含义，了解业务决策的影响。具有沟通价值的能力，能从客户的角度看问题，具有项目管理技能，如计划、风险、问题管理能力
        • 分析/谈判技能
          • 强大的分析能力，能够解决不同业务部门间的分歧，能够建立良好的人际关系
        • 想象力
          • 富有想象力，创造性思维，从客户的角度考虑问题
        • 领导力/个人品质
          • 很强的领导力，具备推行流程的能力，具备一定的幽默感，勇于、乐于接受变革
        • 团队建设能力
          • 组建团队的能力，对整个团队的管理，建立关系的能力
        • 远见、创造性
          • 有远见，创造性思维，有创造能力
    • 2.7.6. 如何培养项目经理
      • 2.7.6.1. 项目经理的评价
        • 合格
          • 一个能弥补和解决问题的项目经理是合格的
        • 优秀
          • 主要是看他能在多大程度上提前识别并消除风险
          • 风险未被及时识别或妥善处理，就会转换成问题
      • 2.7.6.2. 培养方法
        • 体系驱动与牵引
        • 周边部门锻炼，提高全流程意识和技能
        • 参加内外部项目经理知识和技能培训
        • 批评与自我批评，总结，改正错误
        • 资源池集中培养，挑选、培养、考核
        • “师父带徒弟”，通过在项目经理助理等上进行培训，获取经验
        • 与一些胡想学习的项目经理进行探讨
        • 赋予充分的责权，敢于压担子
• 3. 研发物料及BOM管理
  • 3.1. 物料编码管理
    • 3.1.1. 物料编码常见的9个问题
      • 3.1.1.1. 没有物料编码体系，使用图号标识物料。这种情况管理比较少见，但是不少企业确实还停留在这个阶段
      • 3.1.1.2. 编码里体现了过多的非物料本身的信息如版本、供应商等信息
      • 3.1.1.3. 研发不给编码，由生产部门给编码。生产部门给编码最常见的结果就是无论是新物料还是可以重用的物料，都给新编码。这样导致大量的一物多码，同时导致大量的库存
        • 公司现在需要优化这块的工作，把重用的物料，做好标准件库，提高研发效率，降低研发风险，缩短研发周期
      • 3.1.1.4. 按照产品类别分类，每个产品类别下有一套物料分类体系。有多个产品线的企业应该尽可能在公司层面统一给编码
      • 3.1.1.5. 分类标准不统一，标准化程度低
      • 3.1.1.6. 物料名称和规格填写随意性大，不统一
      • 3.1.1.7. 物料分类不清
      • 3.1.1.8. 物料扩展不够用
      • 3.1.1.9. 物料编码规则过多，长度不统一
    • 3.1.2. 物料编码6大原则
      • 3.1.2.1. 唯一性
        • 每个物料只有唯一编码，保持一种分类方法并在系统的各组成部分中保持一致
        • 唯一性是物料编码方案的基本要求，唯一性意味着可能变化的信息不能体现在编码中，如使用公司信息、供应商、客户等信息
      • 3.1.2.2. 简单性
        • 编码结构应尽可能简单，长度尽量短，可节省阅读、填写、抄录的时间和存储空间
        • 应尽量使用数字，不建议使用字母，以提高输入的效率，并减少其中的错误机会，编码里不应该有过多的信息体现
      • 3.1.2.3. 稳定性
        • 在编码时要考虑物料编码变化的可能性，尽量保持编码的稳定性，物料编码所体现出的含义不会发生大的变化
      • 3.1.2.4. 可拓展性
        • 物料编码应有一定的可拓展性，保证编码使用和更改方便
      • 3.1.2.5. 规范性
        • 编码的结构及编码的编写格式应当统一，编码的长度统一
      • 3.1.2.6. 分类性
        • 按照物料的属性、物料的数量合理分类，物料编码承载少量分类信息，分类的目的主要是为了合理分配码段，并不是为查询
    • 3.1.3. 常见的编码做法
      • 3.1.3.1. 流水码
        • 唯一性
          • 可以完全保证“一物一码”
        • 简单性
          • 编码无含义，业务人员理解和使用较困难
        • 稳定性
          • 编码与物料属性不关联，稳定性强
        • 可拓展
          • 编码方法有很强的拓展性
      • 3.1.3.2. 分类码
        • 唯一性
          • 当需编码的新物料过多时，可能出现码段不足的情况
        • 简单性
          • 易出现编码过长的现象，增加使用难度
        • 稳定性
          • 长期使用中稳定度不够，会受到其它因素变更的影响
        • 可拓展
          • 通过流水编码部分保证一定的拓展空间
        • 常见的物料编码分类是采用“大类+中类+小类+流水码”。笔者经历过的企业中大部分企业属于这种编码划分方式，也有部分企业不需要大类，直接采用“中类+小类+流水码”的方式
          • 
      • 3.1.3.3. 编码注意事项
        • 部分企业把结构类和电气类物料划到原材料里，也有部分企业类似目前的建议分类
        • 原材料划分亦有按铜材、铝材和钢材划分（材料价格敏感型建议此类划分）
        • 包装件有放在结构类里的，也有放在原材料里的，也有单独作为一类
        • 不同的企业类型需要调整中类和小类的层次，如以板卡产品为主的企业则侧重电子类物料，结构类为主的企业则侧重结构类物料
        • 成品和半成品的分类由于不同的产品差异过大，不展开描述
        • 规模大、集团化的企业管理要求高，需要更多考虑物料的可拓展性
        • 除标准中规定的，其余特殊符号不准使用，大写罗马字母中的I、Q、O不能使用
      • 3.1.3.4. 物料编码调整的5个风险
        • 需要改变所有相关作业人员的习惯，项目实施难度加大。下游物料采购、物料出入库、生产发货等涉及的单据都需要调整
        • 所有物料数据的期初导入，需要进行新旧物料编码的转换
        • 新系统中，所有关于物料数据的核对需要用到旧系统的数据时，需要人工转换核对
        • 部分物料编号已印制在对应的实物上，需要进行统一规范
        • 旧图纸因物料编码的改变需重新出图
      • 3.1.3.5. 先有图还是先有料
        • 先有图再申请料号
          • 优点
            • 编码申请时，有图纸作为评审参考，提高评审质量
          • 缺点
            • 未进行设计前评审，可能审核时才发现零部件重复设计
          • 建议
            • 建议除复杂的产品自制件采用先画图再申请物料的做法
        • 先申请料号再画图
          • 优点
            • 符合先规划再设计的理念，避免重复设计
            • 产品组件规划比较清晰
            • 减少“一物多码”，保证物料引入的合理性
          • 缺点
            • 设计过程中可能因为方案变化，而导致废喇
            • 复杂的产品实际动作情况下可能会变成一个给号的流程，达不到监管的效果。原因是在没有图纸的阶段，无法发挥审核的作用。
          • 建议
            • 标准件、外购件、电子元器件都应采用先申请料再画图的做法
        • 不管选择哪种做法，都应该在设计之前多查询和搜索，在评审的时候进行审核，保证物料引入的合理性，以减少重复工作
  • 3.2. 物料分类与属性
    • 分类的目的是为了重用
    • 3.2.1. 物料分类6大原则
      • 3.2.1.1. 自制件分类细分程度需要与实际结合，不是越细越好
      • 3.2.1.2. 为便于分类维护和使用，建议分类节点的层级不超过4级，每个分类的子类6～10个左右
      • 3.2.1.3. 相对稳定，在比较长的时期满足业务需求，不需要频繁调整
      • 3.2.1.4. 分类节点名称尽可能保证互不相同，以免产生误解及误放
      • 3.2.1.5. 分类属性数量需适中，应区别于零部件的常规属性，选择若干个最能描述和体现物料特征的属性作为分类属性
      • 3.2.1.6. 对同一物料不同归属分类节点的情况，建议建立特殊物料分类的优先级约束规则，规范物料分类细则的方法，从业务层面（设计单元）规定其归属
    • 3.2.2. 物料属性描述规范
      • 3.2.2.1. 表达式中允许用“空格”或横杠“-”来表示间隔，但一定要保证所有的“空格”或横杠“-”都是英文半角状态
      • 3.2.2.2. 规格描述规范统一，如电容，功率描述规定为1/4W一种写法，而不是0.25W
      • 3.2.2.3. 不得出现全角字符，不能出现冒号、分号、引号、撇号、句号、逗号等特殊字符
      • 3.2.2.4. 一般情况下，英文字母一律采用大写半角（特殊说明的除外）
      • 3.2.2.5. 整数值要求小数点保留到整数位，正确写法是：1u/50V，错误写法是：1.0u/50V
      • 3.2.2.6. 小数值要求小数点保留到有效数字位，正确写法是：0.1，错误写法是：0.10
      • 3.2.2.7. “频率”为Hz，（大写H，小写z）
      • 3.2.2.8. 电流单位“安培”用大写字母“A”表示，“毫安”用“mA”（小写m，大写A）
      • 3.2.2.9. 交流用AC表示，直流用DC表示，均为大写，必须写在数值的前面，如DC220V
      • 3.2.2.10. 乘号“×”用“*”（星号）代替；“*”是英文半角状态，如螺钉GB818M3*8
      • 3.2.2.11. 表示温度的℃符号，用大写英文字母“C”代替；如85℃，可以写成85C
  • 3.3. 物料相关流程及规范
    • 3.3.1. 电子料引入流程示例1
      • 3.3.1.1. 物料申请
        • 针对由于设计优化、新项目及国产化要求，创建新电子物料导入需求，选择分类、填写相关属性
          • 硬件工程师
      • 3.3.1.2. 设计审核
        • 从产品设计层面确认物料规格是否合理
          • 硬件主管
      • 3.3.1.3. 物料审核与选型
        • 确认新规格物料的制造商、技术规格及具体的物料属性
          • 器件工程师
      • 3.3.1.4. 物料商务评估
        • 由商务评估员负责联系供应商，并对供应商进行评估，主要评估因素包括：采购周期、批量投产日期、是否符合认证要求、是否符合RoHS要求、停产风险、供应商可替代性、厂家实力、价格是否有优势，可上传商务评估报告，作为审核通过的依据。备选的供应商提供样品及规格书
          • 采购认证工程师
      • 3.3.1.5. 商务确认
        • 依据上传的商务评估报告，采购经理审核此评估报告是否通过
          • 采购经理
      • 3.3.1.6. 规格审核
        • 对器件工程师选型及采购认证工程师商务确认工作的复审。审核新规格的物料是否符合器件的发展方向及公司的器件选用原则。一般此时给料号
          • 专家委员会
      • 3.3.1.7. 器件库维护
        • 库管理员对已经编码的物料维护器件库
          • 器件工程师
      • 3.3.1.8. 物料测试
        • 测试器件单体，测试人员依据电子件测试规范逐项测试样品，并记录测试数据，完成测试报告。在不具备测试条件的测试情况下，要求供应商提供测试报告，无法进行单体测试的物料，可以不上传测试报告
          • 器件工程师
      • 3.3.1.9. 物料承认
        • 新零部件申请人负责签订物料承认书，器件工程师输出《物料认可书》，关联物料和《物料认可书》《规格书》《测试报告》
          • 硬件工程师
    • 3.3.2. 电子料引入流程示例2
      • 3.3.2.1. 物料申请
        • 针对由于设计优化、新项目及国产化要求，创建新电子物料导入需求
          • 硬件工程师
      • 3.3.2.2. 规范性评估
        • 物料填写是否符合公司要求规范
          • 器件工程师
      • 3.3.2.3. 物料审核
        • 从产品设计层面确认物料规格是否合理
          • 硬件主管
      • 3.3.2.4. 商务评估
        • 确认规格物料的供应商、交期、价格等信息。提供样品及规格书
          • 采购认证工程师
      • 3.3.2.5. 正式编码填写
        • 给申请的物料正式编码
    • 3.3.3. 电子料替代失效流程
      • 3.3.3.1. 物料替代失效申请
        • 供应商发布物料停产通知，研发使用的物料出现故障，器件失效，或归一化等原因发起替代失效申请
          • 硬件工程师
      • 3.3.3.2. 物料替代失效分析
        • 分析物料是否可以替代或失效
          • 硬件工程师
      • 3.3.3.3. 替代测试
        • 替代物料进行测试
          • 测试工程师
      • 3.3.3.4. 修改设计文件
        • 修改BOM和对应的物料状态信息
          • 硬件工程师
      • 3.3.3.5. 库存、计划处理
        • 根据研发工程师的意见处理库存和在制品
          • PMC
    • 3.3.4. 物料选型规范
      • 3.3.4.1. 首先选用物料数据库中已有器件，如物料数据库无满足要求的器件，则可根据实际使用要求在供应商供货清单范围内按优选顺序选择符合要求的器件
      • 3.3.4.2. 如供应商供货清单资源仍不能满足要求，或由于性能、质量、成本、货期等因素，需要引入新的品牌，应按新器件引入流程要求引入，获得批准后，器件工程师将新品牌信息补充维护到供应商供货清单中，方可选用
      • 3.3.4.3. 新产品器件选用应至少2个以上品牌，原则上不能只选一家
      • 3.3.4.4. 尽量选择通用器件，即制造商大规模量产的标准产品或推荐选用产品，且有多家制造商具备的生产能力
      • 3.3.4.5. 不用或少用专用器件，即器件的制造商唯一且无可替换产品或需要按单生产的特殊规格器件，以及需定制的非标准器件
      • 3.3.4.6. 满足适用原则，所选器件满足应用条件即可
      • 3.3.4.7. 满足应用条件的情况下，优先选择国产器件
      • 3.3.4.8. 选择供应渠道多的器件
      • 3.3.4.9. 降额设计要适中
    • 3.3.5. 物料来料检验
      • 3.3.5.1. 尺寸规格
      • 3.3.5.2. 功能
      • 3.3.5.3. 参数测试
      • 3.3.5.4. 外观检查包装情况
      • 3.3.5.5. 产品外形与样品是否一致
      • 3.3.5.6. 损伤（划伤、破损）
      • 3.3.5.7. 安规测试
      • 3.3.5.8. 其它
        • 实配
        • 上锡
          • 子主题
        • 试验（阻燃、耐温等）
        • 异常描述
  • 3.4. 物料BOM管理专题
    • 3.4.1. 物料管理3个关键指标
      • 3.4.1.1. 优选率
        • 对某一个产品BOM中优选物料与所有物料的比率
      • 3.4.1.2. 替代率
        • 具有相同规格并可以完全替代的物料数目占所有物料的比率
      • 3.4.1.3. 复用率
        • 复用物料占所有物料的比例
    • 3.4.2. 物料优选规则6个指标
      • 3.4.2.1. 物料成本
        • 竞争性评估，招标价格比较，成本分析，供应商早期介入
      • 3.4.2.2. 性能规格
        • 器件发展趋势，新技术、新器件引入，器件规格，器件设计开发，技术断裂点
      • 3.4.2.3. 质量可靠性
        • 质量可靠性技术标准，全流程器件可靠性保障体系，单板硬件可靠性设计，高温可靠性解决方案
      • 3.4.2.4. 可采购性
        • 优选、归一化、物料、单板、模块、平台归一化、替代、货期，生命周期导入、成长、成熟、饱和、衰退、退出、物料风险
      • 3.4.2.5. 可制造性
        • 插装器件表贴化，小型化器件引入，器件集成与模块化设计，简洁化设计
      • 3.4.2.6. 社会责任 （节能环保）
        • 器件功耗评估，低能耗器件引入，关键器件低能耗应用方案，无铅环保器件引入
    • 3.4.3. BOM介绍及形成过程
      • 3.4.3.1. 定义
        • 它是描述产品生产加工工序和每个工序所需物料、数量及工艺损耗的重要工艺文件，是研发部门最重要的基础数据。
      • 3.4.3.2. 分类
        • 设计物料清单EBOM
          • EBOM主要是设计部门产生的数据，产品设计人员根据客户订单或者设计要求进行产品设计
          • EBOM是工艺、制造等后续部门的其他应用系统所需产品数据的基础
          • 包含内容
            • 产品名称
            • 产品结构
            • 明细表
            • 汇总表
            • 产品使用说明书
            • 装箱清单
        • 制造物料清单MBOM
          • MBOM是制造部门根据已经生成的EBOM，对工艺装配步骤进行详细设计后得到的
          • 包含内容
            • 产品的装配顺序
            • 工时定额
            • 材料定额
            • 设备
            • 刀具
            • 卡具
            • 模具
            • 反映了零件、装配件和最终产品的制造方法和装配顺序，反映了物料在生产车间之间的合理流动和消失过程。MBOM也是提供给计划部门的关键管理数据之一
      • 3.4.3.3. BOM的形成过程
        • 搭建顶层EBOM
          • 系统工程师在PLM系统中搭建产品顶级EBOM框架
        • 搭建结构EBOM
          • 结构工程师根据前期设计和编码申请情况编制结构BOM，或由3D设计图生成结构EBOM，结构部门经理审核
        • 搭建硬件EBOM
          • 根据前期设计，将PCB和原理图分别从硬件设计工具中导出制成原理图EBOM，制作单板EBOM，或由硬件设计工具集成自动在PLM系统中生成原理图EBOM
          • 审核单板EBOM
          • 修改调整原理图EBOM
          • 将生产资料包改善给工厂、驻厂工程师、采购人员（电子档）
        • 整合产品EBOM
          • 整合电子、结构EBOM、制作产品顶级EBOM、分层（电子、包装、结构、组装），再次确认EBOM的正确性
        • EBOM审核
          • EBOM评审和生产资料发布流程
        • MBOM编辑与审核
          • 如果企业EBOM和MBOM分开，则增加该环节。工艺人员在EBOM的项目上制作并审核MBOM
        • 发布到ERP系统
          • 由PLM系统将EBOM/MBOM自动发送到ERP系统
• 4. 产品开发过程
  • 4.1. 简述
    • 4.1.1. IPD产品开发流程
      • 布式模型
      • 4.1.1.1. 内容
        • 产品开发袖珍卡
        • 阶段流程
        • 结构设计
        • 外观设计
        • 硬件设计
        • 软件设计
        • 操作指导书
        • 工作模板
      • 4.1.1.2. 特点
        • 结构化
        • 并行化
        • 集成化
      • 梳理产品开发流程的目的
        • 水平的人通常不愿意干低水平的事情，而且高水平的人干了低水平的事情对于企业而言投入产出比就低了。建议企业列出不同人员等级负责的活动清单，形成各个级别人员的标准，可以对研发人员进行认证，达到某个级别就大概知道能负责哪些事情。
        • 梳理产品开发流程的目的是企业研发人员可以参考流程进行产品开发，避免遗漏。
        • 是不希望一个人从头干到尾，不是每个活动都需要高水平的研发人员去做
    • 4.1.2. 产品开发流程6个阶段
      • 4.1.2.1. 概念
        • 明确产品需求，关注开发什么
      • 4.1.2.2. 计划
        • 系统设计或者概要设计，关注如何做
      • 4.1.2.3. 开发
        • 详细设计及内部测试
      • 4.1.2.4. 验证
        • 测试部门进入测试，包括客户验证、第三方验证和供应链认证
      • 4.1.2.5. 发布
        • 产品小批量生产、爬坡生产，量产，产品上市
      • 4.1.2.6. 生命周期
        • 产品优化
      • 通常前两个阶段需要确定需求、规格、方案，难度较大，后面四个阶段难度相对较小。很多企业因为前两个阶段水平不够或者投入时间不够导致后面大量的设计更改。
  • 4.2. 流程设计原则
    • 4.2.1. 设计方法：瀑布和迭代
      • 4.2.1.1. 典型生命周期模型
        • 迭代模型和瀑布模型的最大的差别在于风险的暴露时间上，不管开发团队经验有多丰富，都很难预知所有的风险。瀑布模型一般有许多风险直到已准备集成系统时才被发现。而迭代模型能在生命周期中尽早发现和避免风险，计划会更趋精确 
        • 产品开发未来的趋势是敏捷迭代模型。
        • 瀑布模型
          • 该模型通过强制提供文档来确保每个阶段都能完成任务，实际上往往难以做好
          • 瀑布模型在过程能力上有天生的缺陷，问题一般到最后才会暴露出来
        • 迭代模型
          • 迭代模型类似小型的瀑布式项目，所有的阶段都可以细分为迭代
          • 每次迭代产生一个可以发布的产品
          • 在某种程度上，迭代是一次完整地经过所有工作流程的过程，包括需求收集、分析设计、实施和测试等环节
        • 敏捷迭代模型
          • 两个角度实现
            • 一是在TR2～TR4A流程中实现敏捷，引入敏捷思想和实践
            • 二是从一个产品中多个需求的串行开发转变到基于小需求包的并行开发
    • 4.2.2. 流程设计原则
      • 流程不能期望完美，要足够简单，在结构化和非结构化之间需要保持平衡，效率和质量之间也需要保持平衡
      • 4.2.2.1. 互联网时代一切崇尚极致的简单，尤其是快速成长型企业的研发人员变动也非常快，所以建议流程用简单的工具设计，研发人员能一眼看明白，最好零基础的人能一眼看明白。
      • 4.2.2.2. 两个简单的原则是Don'tmake me think, Keep it sample andstupid（KISS）
      • 4.2.2.3. 能够一张图显示整体
      • 4.2.2.4. 流程并不是越全越细越好，能够快速展示重点活动，非重点活动另行展示
      • 4.2.2.5. 不要花里胡哨，也不要密密麻麻
      • 我们公司现在的流程，也需要不断的优化，把项目任务及里程碑节点。按工作的实际情况进行优化调整
  • 4.3. 研发6大阶段流程概述
    • 4.3.1. 流程活动概要介绍
      • 4.3.1.1. 项目任务书
        • 细分目标市场和客户是谁？
        • 细分目标市场的特征，应用场景及客户问题的期望是什么？
        • 技术、标准和产品的支撑能力如何？
        • 主要活动
          • 市场定义、市场细分
          • 组合分析
        • 产品应用场景是什么？
        • 产品初始需求有哪些？
        • 产品的差异化特点、成本、关键竞争力
        • 主要活动
          • 制定和管理业务策略与计划
        • 如何保证实现产品？
        • 营销目标是什么？如何实现？
        • 如何提供产品服务？
        • 产品投资是否会盈利？
        • 关键里程碑？谁负责开发？
        • 主要活动
          • 重点活动：开发项目任务书
          • 立项DCP评审
      • 4.3.1.2. 概念
        • 目标
          • 对产品机会的总体吸引力，及是否符合公司的总体策略做出快速评估
        • 关注
          • 主要关注于分析市场机会，包括估计的财务结果、成功的理由及风险，确定备选方案
        • 主要活动
          • 组建PDT团队
          • 制定概念阶段计划
          • 项目开工会
          • 重点活动：概念和技术方案
          • 重点活动：定义产品需求
          • 制定产品质量目标和计划
          • 重点活动：TR1评审（产品包需求评审）
          • 定义制造，服务策略
          • 重点活动：概念决策评审CDCP
      • 4.3.1.3. 计划
        • 目标
          • 定义产品规格和制定项目计划
        • 关注
          • 清晰定义产品及竞争优势，理解业务计划，制定项目计划及资源计划，开发最终的产品方案
        • 主要活动
          • 制定计划阶段计划
          • 需求分解与分配
          • 系统设计与设计规格定义
          • 制定测试策略、评审
          • 重点活动：TR2评审（设计规格评审）
          • 结构概要设计、评审
          • 硬件概要设计、评审
          • 软件概要设计、评审
          • 制定系统测试与验证计划
          • 制定制造计划、工艺总体方案
          • 重点活动：TR3评审（概要设计方案评审）
          • 整合物料需求计划
          • 前采购
          • 重点活动：计划决策评审PDCP
      • 4.3.1.4. 开发
        • 目标
          • 产品包开发
        • 关注
          • 评审市场及客户需求，设计和集成满足产品规格的产品，准备和构建，确保产品具有可制造性
        • 主要活动
          • 结构开发
          • 硬件开发
          • 软件开发
          • 测试开发
          • 资料开发、翻译
          • 重点活动：TR4评审
          • 制造工艺开发
          • 重点活动：原型样机测试
          • 重点活动：TR4A评审
          • 订购初始物料
          • 重点活动：功能样机测试
          • 重点活动：TR5评审
      • 4.3.1.5. 验证
        • 目标
          • 验证产品，发布最终的产品规格及相关文档
        • 关注
          • 审视市场及客户需求，审视产品发布计划。形成最终的产品规格，确保制造准备就绪，形成最终的发布过程文档，验证供应商，验证制造工艺
        • 主要活动
          • 制造系统验证
          • 下达量产物料计划
          • 生产试制产品
          • 重点活动：date测试
          • 用户资料出版
          • 外部认证
          • 工艺验证与改进
          • 组织产品技术鉴定
          • 重点活动：TR6评审(转生产评审)
          • 测试结果评审
          • 发布准备
          • 可获得性决策评审ADCP
      • 4.3.1.6. 发布
        • 目标
          • 发布产品，具备量产能力
        • 关注
          • 验证供应/制造，服务准备计划，评估市场发布计划并进行必要的修改
        • 主要活动
          • 量产操作切换
          • Ramp up生产
            • 爬坡生产
          • 批产技术服务
          • 重点活动：产品发布
          • 项目结束经验总结
          • 重点活动：GA
            • 批量供货点
      • 4.3.1.7. 生命周期
        • 在产品稳定生产到产品生命终结期间对产品进行管理，制定产品过渡策略
          • 组建LPDT
          • 产品优化
          • 产品发型
          • 生产过程中技术支持
          • 工程更改
          • 生命终止决策评估LDCP
    • 4.3.2. 核心监控要点
      • 4.3.2.1. 项目管理
        • 关注项目优先级清单表
          • 定好优先级
        • 初步列出项目大阶段里程碑时间
          • 定好里程碑节点
        • 列出合理的项目计划，并经过评审
          • 合理的计划
      • 4.3.2.2. 概念阶段
        • 概念和技术方案非常重要，定义关键功能和可选方案
          • 产品的核心功能
        • 关键物料风险评估
          • 关键物料的可制造性
      • 4.3.2.3. 计划阶段
        • 阶段开始时准备系统测试计划，及准备相关测试工具
          • 质量目标的可实现性
        • 原理图设计可能在本阶段或者在详细设计的早期开始
          • 原理设计需要提前进行
      • 4.3.2.4. 开发阶段
        • 确定详细设计说明书/各部门工作负责人及完成时间，以及相互配合的接口要求
          • 做好任务分配及确认责任
        • 编辑物料清单时应该注明哪些物料不能修改或更换，尽量使用已有的物料
          • 加强物料的重用，把常用物料做成CBB
        • 软件建议模块详细设计和模块单元编码由不同的工程师完成，有助于检查详细设计和编码的可读性
          • 软/硬件开发三条线并行
        • 尽早进行测试用例的设计
          • 把产品的测试标准及测试方法尽早确认
      • 4.3.2.5. 验证阶段
        • 制造系统验证需要生产工程师和工艺工程师参与，尽早验证，不要在转量产时才做
          • PE需要提前介入到产品开发
      • 4.3.2.6. 发布阶段
        • 市场发布计划和准备工作需要仔细筹备
  • 4.4. 6大阶段流程
    • 4.4.1. 6大阶段流程-项目任务书阶段
      • 规范和管理研发项目的立项及项目的启动流程，确保研发项目的目标是明确的，满足客户需求，资源配置充分，减少不充分立项导致的损失
      • 4.4.1.1. 市场定义、市场细分
        • 活动描述
          • 获得产品市场信息，包括市场部、研发部通过市场开拓活动主动获得的产品信息，以及公司任何职能部门，或客户，或代理商提供的有价值的信息，提交给市场部进一步的调研和分析
        • 负责岗位
          • 市场部
        • 输出
          • 市场评估
      • 4.4.1.2. 组合分析
        • 活动描述
          • 市场部经过市场判断评估后确定有立项要求，编写《项目可行性分析报告》
          • 市场业务人员获取市场信息后，联系客户获得更多需求、背景信息及技术要求，做好市场调研，判断已有的研发和生产条件是否可以满足，将相关需求汇总给研发部进行研发评估。市场调研还应包含这此内容
            • 客户需求
            • 产品功能需求
            • 市场机会
            • 目标市场分析
            • 竞争对手分析
            • 法律法规
            • 行业要求
            • 客户报价
              • 当客户要求产品报价时，需要同研发部协商后，完成给客户报价
          • 市场调研分析活动非常重要
        • 负责岗位
          • 市场部
        • 输出
          • 项目可行性分析报告
      • 4.4.1.3. 制定和管理业务战略与计划
        • 活动描述
          • 研发部根据市场部提供的信息进行研发能力的评估，主要包括
            • 技术可行性分析
            • 研发资源（人力需求、交期）
            • 研发成本和设备等
          • 初步确定研发项目团队，根据内部项目的优先等级确定项目研发进度，时间表关注大阶段的里程碑时间
          • 研发总监应该维护项目优先级，以及项目大阶段里程碑时间清单表
        • 负责岗位
          • PDT经理
          • 市场部
          • 研发总监
        • 输出
          • 产品业务计划
      • 4.4.1.4. 重点活动：开发项目任务书
        • 活动描述
          • PDT经理编写初步的项目任务书，市场部完善项目任务书
          • 市场部召集相关人员召开立项评审会，包括研发部和市场部项目成员，若有后续生产的项目，还要生产及QA部门项目成员参加
          • 市场部描述项目任务书内容，参与者提出意见，市场部负责记录和汇总评审意见，确定评审结论
          • 如果客户要求产品报价时，根据人力和设备评估起草报价，并提交市场部进行最终报价
        • 负责岗位
          • PDT经理
          • 市场部
          • 研发总监
        • 输出
          • 项目任务书
      • 4.4.1.5. 立项DCP
        • 活动描述
          • 市场总监将完成的项目任务书交IPMT评审，IPMT需要结合公司战略发展要求的市场竞争情况，评审意见决定项目立项。如果同意，签字确认
          • IPMT将项目任务书交给研发总监，由研发总监负责成立项目级并列出详细的研发计划
        • 负责岗位
          • 总经理
        • 输出
          • 立项决策评审报告
    • 4.4.2. 6大阶段流程-概念阶段
      • 目的：规范和管理研发项目在概念阶段的流程，确保对客户的理解是充分的和完整的，为后续的设计和优化阶段确定明确的方向，为项目测试验收提供依据
      • 4.4.2.1. 组建PDT团队
        • 活动描述
          • 研发总监选择和落实完成该产品概念阶段任务所需的PDT成员，主要包括PDT经理和核心组成员，必要的项目外围组成员。确定项目名称和代号
        • 负责岗位
          • 研发总监
          • PDT经理
      • 4.4.2.2. 制定概念阶段计划
        • 活动描述
          • 项目经理根据标准项目计划制定项目详细开发计划，确定各步骤的人员和时间，制定计划时需要保证项目成员有较充足的时间参与。按照模板要求创建项目管理问题跟踪表，开始对项目进行跟踪记录
        • 负责岗位
          • PDT经理
        • 输出
          • 项目计划
          • 项目管理问题跟踪表
            • 就是我们上传TB的项目任务计划表
      • 4.4.2.3. 项目开工会
        • 活动描述
          • 项目经理根据项目任务书中人员配置召集项目成员，召开项目启动会议。启动会议非常重要，需要包括项目成员所在职能部门主管参加
          • 启动会的一般议程有
            • 阐述项目目标
            • 项目任务书宣读和接受仪式
            • 核心团队人员任命和相互介绍
            • 前期工作回顾
            • 阶段交付介绍
            • 项目计划和进度要求
            • 个人和团队激励机制
            • 资源承诺书
          • 根据要求创建项目管理目录
        • 负责岗位
          • PDT经理
      • 4.4.2.4. 重点活动：概念和技术方案
        • 活动描述
          • 进行行业标准及产品应用标准等标准化的调查研究，研究外部的产品、元器件和制造工艺技术，对竞争对手的技术方案进行调研分析。进行技术方案的可行性调查研究，对硬件、软件和系统等进行初步的可行性设计与调研。对关键功能提出不同设计的概念，提出并评估融入概念的产品、元器件、制造工艺等的多种技术选择
          • 整理各类概念，形成产品可选方案列表，该表应该包括概念说明、成本评估、技术瓶颈等。从资源、成本、技术难度等维度评估各个部分的可选方案，进行排列组合组成系统，去掉不可能组合，对剩余组合分别进行评估，选择最优系统组合。
          • 进行知识产权的可行性调查研究，与系统工程师共同检查项目所采用概念、技术涉及的专利和法律知识，并安排对在项目中的新概念、发明、新方案、新造型等进行专利申请
          • 根据项目具体需要，视情况由研发代表与采购代表共同决定是否需要引入关键供应商参与概念形成过程，并参与产品开发
        • 负责岗位
          • 系统工程师
        • 输出
          • 产品概念可选方案
      • 4.4.2.5. 重点活动：定义产品需求
        • 活动描述
          • 根据前期的市场需求，立项材料，可行性分析报告、以前类似产品的经验、教训等对即将开发的新产品的技术需求进行分析，转化为产品研发需求，描述产品功能，定义产品的系统需求，同时提出产品的认证需求和成本需求
          • 产品需求分为内部和外部两个部分的需求，外部需求主要指客户的需求，内部需求为产品开发相关部门对该产品的需求，如产品的可制造、可测试、可安装，可服务，可维护，可使用性等需求，以及结构方向和生产方面的需求等
          • 整合这些技术层面的需求，解决有冲突的需求，去掉冗余的需求，将描述不清楚的需求确定化
            • 我们现在公司的现状就是经常有需求总是在变动，需要按些方式加强需求管理，同时我们需要加强需求方面的分析及决策。确定主要的需求，集中资源办大事
        • 负责岗位
          • 系统工程师
        • 输出
          • 产品需求
      • 4.4.2.6. 制定产品质量目标和计划
        • 活动描述
          • 本阶段流程活动执行时进行质量活动的引导、审计和培训
          • 结合本产品的质量要求，制定本产品要达到的质量目标，按规定的测量和统计方法收集产品质量目标值，并进行评估
          • 进行本阶段的交付件审计，跟踪审计问题并关闭，协调各功能领域的QA活动。完成产品质量月报，组织缺陷分析和质量回溯
        • 负责岗位
          • 质量代表
        • 输出
          • 产品质量目标和计划
      • 4.4.2.7. 重点活动：TR1评审（产品包需求评审）
        • 活动描述
          • TR1重点关注产品需求的完备性及选择的产品概念
          • PDT经理申请召开TR1评审会，研发总监确定项目评审小组并指定项目评审主持
          • PDT经理提前将TR1交付物发给各评审委员进行提前审阅
          • 进行TR1评审：PDT经理进行项目情况简单介绍，展示项目管理问题跟踪表，评审委员对产品需求规格说明书和项目管理问题提出疑问，项目成员进行解答，评审小组根据评审检查表的要求为项目打分，评审小组确定是否通过该阶段评审。评审内容包括
            • 评估产品设计需求是否充分映射产品包需求
            • 确保产品需求的技术可行性及产品概念的有效性
            • 判断本阶段的交付件描述是否明晰而足以指导产品规格的设计
            • 评估部件重用计划
        • 负责岗位
          • PDT经理
        • 输出
          • TR1评审要素表
          • TR1评审报告
      • 4.4.2.8. 定义制造，服务策略
        • 活动描述
          • 制造代表负责组织进行产品生产制造方面的考虑，如生产场所、质量、物流、生产测试、表面贴装、订单履行、库存、制造成本、原材料供应、生产组织方式、是否使用外部单位等，包括初始生产产品、小批量生产和批量生产等环节。
          • 针对产品的特性，分析产品的可行性服务计划，确定售后服务方式
        • 负责岗位
          • 制造工程师
        • 输出
          • 产品制造策略
      • 4.4.2.9. 重点活动：概念决策评审CDCP
        • 活动描述
          • PDT经理介绍评审材料，IPMT成员根据业务决策评审表提出详细问题，PDT成员解答。通过，会签并形成会议纪要，进入下一阶段。不通过，终止活动
          • 落实评审修改意见
        • 负责岗位
          • PDT经理
        • 输出
          • CDCP评审检查表
          • CDCP评审报告
    • 4.4.3. 6大阶段流程-计划阶段
      • 4.4.3.1. 制定计划阶段计划
        • 活动描述
          • 组织PDT成员共同讨论制定项目计划阶段项目计划，为计划阶段工作提供指导
        • 负责岗位
          • PDT经理
        • 输出
          • 项目计划
      • 4.4.3.2. 需求分解与分配
        • 活动描述
          • 在系统架构设计基础上，设计团队分析产品包需求，将需求分解成结构、硬件、软件子系统，需求分解要确定某些特殊需求如何由结构、硬件和软件组合实现。需求分解要清晰地决定需求的哪些部分由结构实现，哪些部分由硬件实现，哪些部分由软件实现，定义清楚它们之间的接口
        • 负责岗位
          • 系统工程师
        • 输出
          • 总体设计方案
      • 4.4.3.3. 系统设计与设计规格定义
        • 活动描述
          • 系统工程师组织需求分析人员编写产品规格书，可重用相似项目的详细客户规格和设计方案。系统工程师整理和审核产品规格书，并进行会议讨论
        • 负责岗位
          • 系统工程师
        • 输出
          • 产品规格书
      • 4.4.3.4. 制定测试策略、评审
        • 活动描述
          • 总体设计方案完成评审后，测试部门进行产品测试策略设计，为新产品的设计开发，制定产品测试的关键技术、测试环境、工具设备、测试方法的一系列策略。一般包括：
            • 测试过程裁剪
            • 样机测试的质量目标
              • 测试进度
              • 测试工作量
              • 测试用例效率
              • 测试生产率
              • 测试覆盖率
              • 测试用例的通过率等
            • 测试重点
              • 重点测试对象
              • 重点测试用例
            • 测试对象依赖关系分析及措施
            • 回归测试策略
            • 测试停止准则
        • 负责岗位
          • 测试工程师
        • 输出
          • 测试策略
      • 4.4.3.5. TR2评审
        • 活动描述
          • 在计划阶段对产品设计规格的评审。TR2重点关注产品设计需求到产品设计规格的完备性
          • PDT经理申请召开TR2评审会，研发总监确定项目评审小组并指定项目评审主持
          • PDT经理提前将TR2交付物发给各评审委员进行提前审阅
          • 进行TR2评审：
            • PDT经理进行项目情况简单介绍
            • 展示项目管理问题跟踪表
            • 评审委员对TR2交付物和项目管理问题提出疑问
            • 项目成员进行解答
            • 评审小组根据评审检查表的要求为项目打分
            • 评审小组确定是否通过该阶段评审
        • 负责岗位
          • PDT经理
        • 输出
          • TR2评审要素表
          • TR2评审报告
      • 4.4.3.6. 概要设计
        • 活动描述
          • 系统工程师以产品可选方案列表为基础，根据业务功能和限制条件确定可行的方案，并考虑功能重要性和价值，筛选概念方案，和各专业工程师（硬件、软件、结构、EMC等）合作，按照概要设计说明书文档模板要求，编写概要设计文档，包括系统概要设计、硬件概要设计、软件概要设计、结构概要设计等
        • 负责岗位
          • 系统工程师
        • 输出
          • 概要设计说明书
      • 4.4.3.7. 结构概要设计、评审
        • 活动描述
          • 结构概要设计包括结构整体方案说明，结构概要设计，包装设计方案，主要加工工艺性分析，整机可装配性设计及走线工艺要求，共用模组和共用零件、新配件说明，可采购性及成本分析，技术指标及性能测试清单
        • 负责岗位
          • 结构工程师
        • 输出
          • 结构概要设计说明书
      • 4.4.3.8. 硬件概要设计、评审
        • 活动描述
          • 确定关键模块、定义功能模块框图及模块接口
        • 负责岗位
          • 硬件工程师
        • 输出
          • 硬件概要设计说明书
      • 4.4.3.9. 软件概要设计、评审
        • 活动描述
          • 分析概要方案，描述采用的编译环境、仿真环境、模块结构图、软件模块接口等，赶写软件概要设计说明书
        • 负责岗位
          • 软件工程师
        • 输出
          • 软件概要设计说明书
      • 4.4.3.10. 制定系统测试与验证计划
        • 活动描述
          • 按照产品规格说明书起草系统测试计划，对测试工具进行提前准备。针对规定的测试特性，描述测试的总体概要方法、所需的主要活动、技术和工具
          • 测试计划内容应包括：
            • 项目类别
            • 功能模块列表
            • 测试方法
            • 测试应达到的标准
            • 测试通过的准则
            • 测试暂停和恢复的条件
            • 根据测试工作量给出测试资源需求：
              • 设备
              • 环境
              • 人员需求
              • 安排测试进度计划
          • 测试设计内容包括详细的测试用例，说明本测试用例对测试过程的约束要求，并说明为完成测试而需对系统操作的详细步骤。一般包括
            • 测试需求
            • 测试用例设计
            • 测试进度计划
              • 关键里程碑
              • WBS计划
              • 工具开发计划等
            • 测试资源计划
              • 人力资源
              • 环境资源
              • 工具等
            • 测试的风险分析和控制计划
            • 测试用例管理
            • 测试交付件
              • 测试报告
              • 测试工具
              • 测试代码
        • 负责岗位
          • 测试工程师
        • 输出
          • 产品测试和验证计划
      • 4.4.3.11. 制定制造计划、工艺总体方案
        • 活动描述
          • 工艺分析
          • 制定工艺路线
          • 工艺流程
          • 工艺防护要求
          • 加工控制方式
          • 确定关键工序
          • 需要的工装
          • 进行生产测试
          • 风险分析
        • 负责岗位
          • 工艺工程师
        • 输出
          • 工艺方案
      • 4.4.3.12. TR3评审
        • 活动描述
          • TR3是在计划阶段对概要设计的评审，确保设计规格已经完全、正确地在概要设计中得到体现。TR3的结果，将作为开发阶段的后续详细设计活动，是否继续投入资源的根据
          • 研发总监成立项目评审小组，确定成员，指定评审主持
          • PDT经理提交硬件概要设计说明书、软件概要设计说明书、系统测试计划、FAE计划、物料审核报告，发给评审委员提前评审
          • 进行TR3评审
            • PDT经理进行项目情况简单介绍
            • 展示项目管理问题跟踪表
            • 评审委员对TR3交付物和项目管理问题提出疑问
            • 项目成员进行解答
            • 评审小组根据评审检查表的要求为项目打分
            • 评审小组确定是否通过该阶段评审
        • 负责岗位
          • PDT经理
        • 输出
          • TR3评审要素表
          • TR3评审报告
      • 4.4.3.13. 整合物料需求计划
        • 活动描述
          • 根据概要设计结果确定关键元器件，由研发采购组选择关键器件的物料及供应商，选择关键器件旱应优先考虑现有的物料及供应商，研发采购应该咨询现有供应商，并评估是否有可供物料
          • 研发采购应该与采购部沟通，确认物料可用性（是否停产、是否有不良记录），索取样品并按要求提供物料承认书。
          • 硬件组和测试组按设计要求评估物料承认书和样品，并填写物料审核报告，
          • 如果需要，引入新供应商，但需按新供应商选择流程执行，咨询供应商背景、供货能力、供货品质信息，同时索取样品和承认书
        • 负责岗位
          • 采购工程师
        • 输出
          • 供应商分析报告
          • 物料承认书
          • 物料审核报告
      • 4.4.3.14. 提前采购
        • 活动描述
          • 长周期物料执行提前采购，如国外进口物料、关键物料等
        • 负责岗位
          • 采购工程师
        • 输出
          • 长周期物料采购计划
      • 4.4.3.15. PDCP
        • 活动描述
          • PDT经理申请召开计划决策评审会
          • PDT经理介绍评审材料，IPMT成员根据业务决策评审表现提出详细问题，PDT成员解答。通过，会签并形成会议纪要，进入下一阶段。不通过，终止相关活动
          • 落实评审修改意见
        • 负责岗位
          • PDT经理
        • 输出
          • PDCP评审检查表
          • PDCP评审报告
    • 4.4.4. 6大阶段流程-开发阶段
      • 4.4.4.1. 结构开发
        • 外观设计
          • 活动描述
            • 根据市场要求设计出产品外观，产品外观包含造型、颜色、面板图案、显示要求等
          • 负责岗位
            • 工业设计工程师
          • 输出
            • 效果图丝印图
        • 结构详细设计、评审
          • 活动描述
            • 基于分配到结构的需求和规格进行结构设计，设计包括造型、模具详细设计图纸、接插件及相关电缆、PCB尺寸及定位尺寸、EMC屏蔽措施方案等，完成设计后，由项目经理组织结构设计评审
            • 设计过程中需要与硬件保持同步，任何修改都必须及时通知对方
          • 负责岗位
            • 结构工程师
          • 输出
            • 结构详细设计说书
            • 3D图纸
        • 手板制作、验证、评审
          • 活动描述
            • 结构工程师负责联系打样厂家，跟踪并处理打样过程出现的问题，打样完成后由结构工程师确认效果，如结构组装的合理性、装配工艺的可操作性、可制造性等
            • 对手板进行检验，检查其是否符合设计图纸的设计要求。并记录有关材料、表面、尺寸、强度等相关方面的问题，跟踪和解决本阶段出现的问题（缺陷）
            • 根据《手板测试报告》修正原有设计问题，并结合组装原型机中发现的相关结构件或硬件问题而进行的更改，对原有设计进行修订
            • 启动手板评审活动，准备评估资料，并提交样机及相关文档，评审能否进行开模
          • 负责岗位
            • 结构工程师
          • 输出
            • 手板测试报告
            • 手板评审报告
        • 零件加工、检测、改进、验证
          • 活动描述
            • 将规格书提供给采购，协助采购监控整个模具的设计及制造。配合采购部门考察模具厂，整理图纸供模具厂进行预报价，确认零件制造方案、模具结构方案
          • 负责岗位
            • 结构工程师
          • 输出
        • 包装需求分析
          • 活动描述
            • 提供制作宣传资料所需要的素材
          • 负责岗位
            • 结构工程师
              • 我与是由包装设计师负责
          • 输出
            • 包装需求说明
        • 包装设计、评审
          • 活动描述
            • 设计整机的包装方案，提交纸箱、贴纸、丝印等的设计图纸
          • 负责岗位
            • 结构工程师
              • 我与是由包装设计师负责
          • 输出
            • 包装图
            • 包装设计检查表
        • 包装打样、验证
          • 活动描述
            • 联系包装供应商打样、送样并确认
          • 负责岗位
            • 结构工程师
              • 我与是由包装设计师负责
          • 输出
            • 纸箱样品报告
      • 4.4.4.2. 硬件开发
        • 硬件详细设计
          • 活动描述
            • 系统设计人员组织编写详细设计说明书，确定相关配合部门如结构和软件的工作负责人及完成时间，以及相互配合的接口要求
          • 负责岗位
            • 硬件工程师
          • 输出
            • 硬件详细设计说明书
        • 硬件原理图设计、评审
          • 活动描述
            • 硬件工程师根据硬件概要设计说明书对硬件模块进行原理图设计，用到新物料时进行物料编号申请及物料审核，生成原理图文件的物料清单（BOM）
            • 硬件工程师负责对新物料样品进行功能验证，完成物料审核报告。确认新物料规格后交给硬件测试组的物料认证工程师进行物料认证及可靠性验证，并由物料认证工程师更新物料审核报告。注明哪些物料不能修改或更换，若物料需要实验测试和验证，则待认可后再进行申请物料编号，尽量使用已有的物料
            • 硬件原理图完成设计之后，由项目经理组织原理图评审会议。原理图由硬件标准化审核员、硬件设计主管、硬件职能主管分别就标准化、原理及总体逐步评审，项目经理负责对评审结果进行跟踪，组织完善原理图的设计及硬件详细设计说明书的更新
            • 原理图设计要确定各器件的连接关系，以及器件的图号、型号、参数、封闭等内容，并且使用工具对原理图进行规则检查
            • 原理图进行总体评审原则上不应该超过3次，超过3次需要停止设计并进行整顿，将评审通过的原理图初步生成物料清单
          • 负责岗位
            • 硬件工程师
          • 输出
            • 原理图
        • PCB设计、评审
          • 活动描述
            • 硬件工程师根据硬件原理图、结构图、硬件详细设计说明书进行PCB板设计，完成设计之后，由项目经理组织PCB板评审会议，由硬件标准化审核员、硬件设计主管、硬件职能主管进行逐步评审，项目经理负责对评审结果进行跟踪，组织完善PCB板的设计及硬件详细设计说明书的更新
            • PCB板设计应该考虑工艺边、Mark点、测试点等工艺要求
          • 负责岗位
            • 硬件工程师
          • 输出
            • PCB设计说明
            • PCB投板评审要素
        • 单板制作、调试
          • 活动描述
            • 将评审通过的PCB板设计图纸发出制板，制板时需要填写制板要求文件。该文件包括PCB板文件名（产品名称+PCB板版本信息+发板日期）、制版数量、PCB板尺寸、PCB板材料、层数、责任工程师的联系电话、要求完成制板的日期、是否加急等
            • 应提前2~3天通知PCB板供应商，便于供应商安排，从而保证3天后收到PCB板
          • 负责岗位
            • 硬件工程师
          • 输出
            • 单板试制报告
            • 单板调试记录
            • 单板生产说明文件
        • 硬件集成及测试、评审
          • 活动描述
            • 根据硬件单元测试大纲和硬件详细设计说明书的描述，起草硬件单元测试要求，为后续样机调试和样机测试提供测试参考依据。对原型样机进行单元测试，测试完成提交硬件单元测试报告。
            • 由硬件测试工程师根据试制完成的时间编写可靠性测试计划，提交给硬件测试组组长评审并提出可靠性测试的申请，经批准后执行可靠性测试。产品没有新的关键器件则关注产品的软件功能，否则还要增加产品的加速寿命试验等测试
          • 负责岗位
            • 硬件工程师
          • 输出
            • 硬件测试报告
      • 4.4.4.3. 软件开发
        • 软件详细设计、评审
          • 活动描述
            • 软件工程师根据软件概要设计说明书划分的模块和定义的接口开始详细设计
            • 逻辑复杂的功能模块需要流程图的，应该在软件详细设计说明书中进行描述，并在源代码中指明，该模块的设计描述参见详细设计说明书。软件详细设计至少应该定义接口的参数、内部的有关操作和全局变量等
          • 负责岗位
            • 软件工程师
          • 输出
            • 软件详细设计说明书
        • 编程
          • 活动描述
            • 完成完整软件详细设计说明后，可以参照编码规范开始对各个模块单元进行编码
            • 建议模块详细设计的模块单元编码由不同的工程师完成，有助于检查详细设计及编码的可读性
          • 负责岗位
            • 软件工程师
          • 输出
            • 软件源代码
        • 代码走查
          • 活动描述
            • 代码完成后在项目组内部进行走读
          • 负责岗位
            • 软件工程师
          • 输出
        • 单元测试
          • 活动描述
            • 完成编码后由软件设计人员自行测试，并依据软件单元测试评审表完成代码自查
            • 进行单元测试时需要填写单元测试记录表格，记录其测试过程和环境，包括所有的硬件、软件环境和配置、测试用例和测试结果
          • 负责岗位
            • 软件工程师
          • 输出
            • 软件单元测试报告
        • 软件集成测试
          • 活动描述
            • 以软件设计概要说明书、各个模块单元工作正常的源代码为输入，熟悉软件描述、规格和约束、各个模块的层次结构和接口规范
            • 搭建软件模块集成调试环境，嵌入软件此时可能还缺乏运行实体，借助软件模拟环境、调试器等进行集成测试。填写集成测试记录表格，记录其测试过程和环境，包括所用的硬件、软件环境和配置、集成测试结果、集成过程中发现的问题和需要的修改，如接口和详细设计的修改
          • 负责岗位
            • 软件工程师
          • 输出
            • 软件集成测试方案
            • 软件集成测试用例
            • 软件集成测试报告
      • 4.4.4.4. 测试开发
        • 测试方案设计、评审
          • 活动描述
            • 测试代表安排各专业测试工程师，根据技术解决方案、详细设计说明书编写系统测试详细方案，编写自动化测试工具的详细方案，编写生产测试用单板、整机测试详细方案
          • 负责岗位
            • 测试工程师
          • 输出
            • 测试方案
        • 开发测试工具
          • 活动描述
            • 如果需要测试工具软件，由上位软件工程师根据系统测试计划和产品规格需求说明书负责设计和编码，调试自动化测试工具代码，编写自动化测试工具操作说明书。对于底层软件的硬件模块测试要求，底层软件设计时就要考虑编写测试模块代码。
            • 制作、调试、验证测试环境，调试单元测试、系统测试代码，调试生产测试用单板、整机测试代码
          • 负责岗位
            • 测试工程师
        • 测试用例设计、评审
          • 活动描述
            • 测试工程师根据系统测试计划和产品规格需求说明书进行测试设计工作，完成测试用例，确认测试用例除对功能测试用例描述外，还应该包括对健壮性、性能、压力、可靠性、安全性测试用例进行描述。正常输入包括普通用例和临界状态用例，非正常输入必须包含正向超出、负向超出和其它特殊要求等各种用例
            • 由用例设计者进行自查，然后由同组其它工程师进行交叉审查，最后由测试主管完成总体审查
            • 详细设计阶段开始就可以进行测试用例的设计
          • 负责岗位
            • 测试工程师
          • 输出
            • 测试用例
      • 4.4.4.5. 资料开发、翻译
        • 资料开发、翻译
          • 活动描述
            • 编写技术文档、操作手册、使用手册参考文档、在线支持文件/资料等，如有需要将技术资料翻译成合适的语言
            • 确认资料开发翻译是否具有准确性、可用性、可读性
          • 负责岗位
            • 资料工程师
          • 输出
            • 产品用户操作手册
            • 产品安装手册
            • 产品维修手册
      • 4.4.4.6. 制造工艺开发
        • 工艺路线设计、工艺文件设计
          • 活动描述
            • 根据产品技术规格要求、工艺设计总体方案的指导，设计制造工艺，确定制造工艺流程及关键控制工序，对制造工艺流程中各个工序进行工艺设计，在工艺设计时必须考虑工序能力、工序效率、工序成本、工艺重用性等因素
            • 对结构和电子详细设计进行必要的工艺指导及审核，使其符合可制造性需求
          • 负责岗位
            • 工艺工程师
          • 输出
            • 工艺路线
            • 产品工艺文件
        • 工装设备准备、工艺布局设计、检测方案
          • 活动描述
            • 设计和开发在生产过程中使用的测试装备，确定标准/非标准测试装备，测试夹具和测试程序。
            • 根据产品技术规格要求、工艺要求和初始样机制作情况制定生产、制造所需要的测试、生产治具、工具、测试仪器等必需设备
            • 在试产准备过程中通过熟悉产品完成产品制造系统验证方案和产品一致性验证方案。对产品在制造系统方面和产品一致性方面进行评估，用生产线试产（该生产线就是用来生产新产品的生产线，以便评估生产线），完成试产规划报告为生产初始产品做好准备
          • 负责岗位
            • 工艺工程师
          • 输出
            • 技术检测方案
            • 工序控制方案
            • 试制准备检查表
        • 材料定额/工时定额
          • 活动描述
            • 计算各种材料消耗定额，编制材料消耗工艺定额明细表和汇总表。
            • 计算劳动消耗工艺定额（即工时定额），提出人员需求计划
          • 负责岗位
            • 工艺工程师
          • 输出
            • 材料定额
            • 工时定额
      • 4.4.4.7. 样机制作与测试
        • 订购原型样机物料
          • 活动描述
            • 研发采购工程师联系供应商申请需求物料的样品，采购申请先提交给设计工程师进行审查，将无法提供的物料提交给采购部，由采购工程师统一采购
            • 对于交期的物料，采购工程师应征得硬件工程师同意才可采购替代物料
            • 硬件工程师准备PCB文件的制板要求，提交给采购申请单给研发采购工程师，安排PCB板供应商进行制作
          • 负责岗位
            • PDT经理
        • 样机焊接、装配、调试
          • 活动描述
            • 硬件工程师根据提交的样品制作申请领取样机物料，清点完毕后按照BOM进行焊接，样机焊接和制作时填写样机制作调试记录表，记录过程中发现的问题及解决建议。焊接完成后应首先完成功能调试。调试完成后，硬件工程师应该完成生产过程指引，提交给研发生产支持工程师了解产品的生产制程
            • 剩余的物料退回研发仓，分析台样机给软件工程师进行设计调试，其余样机留硬件工程师调试
          • 负责岗位
            • PDT经理
          • 输出
            • 样机制作调试记录表
            • 生产过程指引
        • 驱动软件和应用软件装载调试
          • 活动描述
            • 由底层软件工程师提供驱动软件装载到样机中配合样机调试，并在硬件用户接口上输出调试结果
            • 由软件测试工程师按照软件确认测试用例对软件功能进行测试，并负责统计软件的功能缺陷率，完成软件确认测试报告。软件测试工程师负责起草产品说明书，涉及硬件部分由硬件工程师提供，售后服务信息由售后服务部工程师提供
            • 系统产品需要进行集成测试
          • 负责岗位
            • 软件工程师
          • 输出
            • 软件确认测试报告会
            • 产品说明书
        • 原型样机测试
          • 活动描述
            • 根据测试方案、测试用例和测试计划针对所需测试的原型样机进行功能、性能的验证测试，验证产品是否符合碑规定的功能，测试完成后需提交测试报告
          • 负责岗位
            • 测试工程师
          • 输出
            • 预测试报告会
            • 原型样机测试报告
        • 技术评审(TR4A)
          • 活动描述
            • 对产品技术上的成熟度进行评估，确保所有人存在的问题和风险都进行了评估，并生成了相应的改进计划，以保证供应的制造能力足以支撑初始产品生产活动。对原型样机测试结果、遗留问题及风险、改进计划进行评审，判定原型样机的成熟度是否进入功能样机测试
            • 根据TR4A评审的产品版本所具有的功能和性能规格判断该版本是否适合启动BETA测试。对采购和制造能力进行基线化，保证足以支撑初始产品生产
          • 负责岗位
            • PDT经理
          • 输出
            • TR4A评审要素
            • TR4A评审报告
        • 订购初始物料
          • 活动描述
            • 开始订购小批量物料，准备试产和小批量生产
          • 负责岗位
            • 采购工程师
        • 功能样机测试
          • 活动描述
            • 进行型式测试，硬件工程师进行失效问题、安规试验、EMC等专业测试，测试后出具型式测试报告。在型式测试同时，物料认证工程师对新物料进行物料确认测试，对物料最终规格进行确认检查
          • 负责岗位
            • 测试工程师
          • 输出
            • 形式测试报告
        • 技术评审5(TR5)
          • 活动描述
            • TR5是在发布给客户前对项目整体状态在设计稳定性和技术成熟度方面的独立评估活动。
            • TR5的目的是确保产品符合预期的功能和性能要求，满足前期确定的产品包需求，保证产品在试制前功能和性能方面的问题均已发现和解决
            • 检查初始产品的规格是否符合计划阶段产品规格的要求，制造过程是否影响产品的功能、可靠性的性能规格
            • TR5是进入验证阶段的必要和充分条件，完成TR5表明小批量初始产品生产和销售已经准备就绪
          • 负责岗位
            • PDT经理
          • 输出
            • TR5评审要素
            • TR5评审报告
    • 4.4.5. 6大阶段流程-验证阶段
      • 4.4.5.1. 制造系统验证
        • 活动描述
          • 由制造工程师提出产品的可制造性评估需求，联系生产项目工程师，由生产项目工程师负责召集生产部门的制造工程师、工艺工程师和测试工程师参加会议
          • 制造工程师提供评估素材，样机2台、PCB板2套、PCB文件、BOM、生产过程指引文件，制造工程师提交可制造性评估报告
          • PDT经理召集举行产品试制会议，参与者为市场组、采购部、SQE、硬/软件测试组、生产支持组、生产项目组、生产PC、QA、生产工艺部、整机装配部和生产测试部，会议的内容包括：
            • 确认研发提交给生产项目组的相关生产文件列表及时间
            • 培训时间
            • 物料完成采购的时间
            • 测试设备完成采购和调试的时间
            • 生产工艺文件完成的时间
            • 计划安排试生产的时间
        • 输出
          • 制造工程师
        • 负责岗位
          • 生产资料包
      • 4.4.5.2. 下达量产物料计划
        • 活动描述
          • 在TR5后，物料计划工程师根据市场代表滚动刷新,并经市场部门评审通过的要货计划，按照相关计划操作流程录入预测、排产计划、下达物料采购计划（包括PCB、结构件、外观设备、软件）、制定物料半成品加工计划。以后每两周根据调整的市场要货计划滚动刷新生产物料计划
          • 到发布阶段后期及时检查生产物料的齐套性，启动生产
        • 输出
          • 制造工程师
      • 4.4.5.3. 生产试制产品
        • 活动描述
          • 与研发及相关部门进行积极、及时的沟通，收集记录试产过程中的所有相关信息，在试产完成后及时提供详细、准确的过程报告
          • 研发提供最新版本的生产文件归档清单，生产项目工程师根据清单获取Gerber文件、BOM、生产过程指引
          • 研发项目工程组下达采购试产物料PO，采购部负责根据PO按照时间和要求采购物料，并负责跟踪进度。生产项目组根据研发项目工程组的要求安排生产计划，协调生产物料计划组进行试制物料准备，安排供应商品质工程师SQE进行物料的品检，确认所有关于物料品质的客户文件。
          • 培训准备，知识培训，工艺测试设备准备，执行小指试产
          • 试产效果评估，生产部门统计生产数据，包括不良率、各工序的合格率和各工序的数据记录，生产部门召集项目经理、工艺及QA对小批试产进行总结，并完成试产评估报告，项目经理组织项目成员分析试产评估报告，试产问题跟踪
          • 项目经理组织会议针对试产总结中的问题提出解决方案，制定改善行动计划，并负责改进措施在产品设计中的实施
        • 输出
          • 制造工程师
        • 负责岗位
          • 试产报告
        • 这是我们目前工作的重点，现在项目进入到量产阶段，需要把试产问题全部关闭
      • 4.4.5.4. BETA测试
        • 活动描述
          • 统筹安排客户服务人员、测试人员、研发人员、试制人员进行客户现场测试，对BETA测试发现问题的解决进度进行跟踪，最终保障问题的解决在客户现场得到验证
        • 负责岗位
          • 测试工程师
        • 输出
          • 客户试用报告
      • 4.4.5.5. 用户资料出版
        • 活动描述
          • 收集整理资料在测试、出版等各方面的情况，评估用户资料内容能否满足客户使用的要求，评估资料出版、印刷能否满足量产需求
        • 负责岗位
          • 资料工程师
      • 4.4.5.6. 外部认证
        • 活动描述
          • 统筹外部系统认证工作，负责提交认证所需的文件。系统工程师提出外部系统认证的需求，测试工程师进行前期准备，包括设备调试和协助认证资料的准备。与外部测试单位对认证的测试方法进行沟通，协助外部认证单位工程师进行认证测试
        • 负责岗位
          • 认证工程师
        • 输出
          • 认证证书
      • 4.4.5.7. 工艺验证与改进
        • 活动描述
          • 总结工艺准备阶段工作，总结工艺、工装在试制中验证情况，对下一步改进工艺、工装的意见和对批量生产建议，反馈和改进设计问题。
        • 负责岗位
          • 工艺工程师
        • 输出
          • 工艺总结
      • 4.4.5.8. 组织产品技术鉴定
        • 活动描述
          • 根据公司确定的生产能力需求，在试制工艺方案的基础上，设计批产工艺方案，修改、新编工艺规程，改进、新增工艺装备
        • 负责岗位
          • 工艺工程师
        • 输出
          • 鉴定报告
      • 4.4.5.9. TR6评审
        • 活动描述
          • PDT经理申请召开TR6评审会
          • 研发总监成立项目评审小组，确定成员，指定项目评审主持
          • PDT经理提交测试计划与报告、物料审核报告，发给评审委员提前评审
          • 进行TR6评审：
            • 项目经理进行项目情况简单介绍
            • 展示项目管理问题跟踪表
            • 评审委员对TR6交付物和项目管理问题提出疑问
            • 项目成员进行解答
            • 评审小组根据评审检查表的要求为项目打分
            • 评审小组确定是否通过该阶段评审
          • 若通过评审，则验证阶段结束
          • 如果没有确定的客户订单则项目视为结束，由PDT经理申请挂起项目，有客户订单再开始验证阶段的试产
            • 符合我们公司没有订单的项目
        • 负责岗位
          • PDT经理
        • 输出
          • TR6评审要素
          • TR6评审报告
      • 4.4.5.10. 测试结果评审
        • 活动描述
          • 对测试结果进行评估
        • 负责岗位
          • 测试工程师
        • 输出
          • 测试总结
      • 4.4.5.11. 发布准备
        • 活动描述
          • 产品准备评估：
            • 评审产品各个方面的技术，包括产品成熟度、质量、可靠性等，明确没有解决的问题，评估风险，制定风险规避活动计划，按优先等级解决问题，分析BETA测试反馈，并为产品发布评估产品准备就绪情况如产品是否可操作和稳定、是否满足规定需求和规格、是否符合规定的成本目标等
          • 市场准备评估：
            • 根据产品的目标市场和定位，制定相应的市场宣传策略，宣传媒体的计划（行业杂志、相关网站等），自有专门针对性宣传资料的策划（如演示稿、展板、彩页、海报、专刊、其它特性宣传品）。制定宣传内容的重点和试点客户计划。
          • 制造准备评估：
            • 审视所有的制造方面的输出，明确尚未解决的问题并评估风险，制定风险缓解行动计划。评估面向发布的总体制造准备完成程度，产品能否在不同的地点，按照要求的质量批量生产，制造的基础架构能否运作（生产线设备、测试设备、工艺路线、操作指导、培训等）。制造工艺是否经过测试与验证，制造人员是否受过维护与解决生产线问题的培训等。
          • 采购准备评估：
            • 明确所有采购方面尚未解决的问题并评估风险，制定风险缓解行动计划，评估面向发布的总体采购准备完成程度，是否通过不同的供应商采购到符合质量要求的供批量生产的零部件，采购系统是否是可操作的和稳定的，以支持器件订购等
          • 资料准备评估：
            • 明确所有的文档尚未解决的问题并评估风险，制定风险缓解行动计划，评估面向发布的总体测试准备完成程度，审视所有产品文档、在线帮助，检查准确度，变更及修正材料
          • 订单履行评估：
            • 明确订单履行方面尚未解决的问题并评估风险，制定风险缓解行动计划。评估面向发布的总体订单履行方面的准备完成程度，如产品能否在各地合适地配置和订购，有没有合适的培训和帮助来支持订货问题。客户订单是否可以精确转化为制造订单，零部件的库存是否充足，可以满足预期的需求。运作机制是否可以满足发货
          • 销售准备评估：
            • 明确产品包的与销售相关尚未解决的问题并评估风险，制定风险缓解行动计划。评估面向发布的总体销售准备完成程度，现场销售人员是否等到充分的培训来支持产品包销售，销售人员是否了解产品的特性/功能/好处，他们是否能利用知识在竞争中胜出，是否有销售人员进行配置、定价并提供客户快速报价的支撑机制
          • 技术支持准备评估：
            • 明确技术支持未解决的问题并评估风险，制定风险规避活动计划并评估为产品发布评估技术支持方面全面的准备就绪情况。技术文档是否可以满足批量要求，技术支持的同事是否经过安装支持和故障排除的培训，是否明确了要打的补丁及其优先级
        • 负责岗位
          • PDT经理
        • 输出
          • 发布计划
          • 价格策略
      • 4.4.5.12. 可获得性决策阶段评审 ADCP
        • 活动描述
          • PDT经理申请召开可获得性决策阶段评审会
          • PDT经理提交试产评估报告和测试报告，发给评审委员提前评审
          • ADCP阶段评审：PDT经理进行项目情况简单介绍，展示项目管理问题跟踪表，评审委员对产品需求规格说明书和项目管理问题提出疑问，项目成员进行解答，评审小组根据评审检查表为项目打分，确定是否通过该阶段评审
          • 若通过评审，经总经理签字确认可进入项目结束阶段，同时准备进行批量生产
        • 负责岗位
          • PDT经理
        • 输出
          • APCP评审要素
          • APCP评审报告
    • 4.4.6. 6大阶段流程-发布阶段
      • 4.4.6.1. 量产操作切换
        • 活动描述
          • 制造流程已经被验证，初始产品被成功地生产出来，生产线被成功地转移到制造操作人员，逐渐放大产能到量产规模，并维护生产线直至制造结束时间
        • 负责岗位
          • 制造工程师
      • 4.4.6.2. Ramp up生产
        • 爬坡生产
        • 活动描述
          • 在切换后的生产线上建立批量生产能力
          • 订购制造需要的物料，测试采购系统并监控供应商绩效，下载面向生产的产品文档、制造指导书等，培训生产操作与测试人员，监控质量、生产周期，并提升流水线人员的技能
          • 通过生产线人员参与讨论识别瓶颈与问题，从而加快学习过程，明确解决办法、变通方法与长期的解决方案。
          • 重新平衡生产线，如果有必要，增添新设备
        • 负责岗位
          • 制造工程师
      • 4.4.6.3. 批产技术服务
        • 活动描述
          • 了解产品生产过程的状况，分析存在的问题，进一步完善工艺和质量控制措施
        • 负责岗位
          • 工艺工程师
          • 制造工程师
      • 4.4.6.4. 产品发布
        • 活动描述
          • 完成所有的发布材料最终稿，所有营销类资料开发完成后，发送给所有的营销人员
          • 培训销售人员，使他们对产品的功能、性能及其它交付有足够了解，支持他们以后的销售活动，以便让他们在发布日能够开始销售。向各个分销渠道发货，使得在GA点之前各个销售渠道能够满足部分客户的发货要求。
          • 获得准入证，准备媒体发布，完成培训资料的准备，准备好正式的发布申请，向外界正式公布产品及GA日期，发布新闻
        • 负责岗位
          • PDT经理
        • 输出
          • 发布准备情况对照检查表
      • 4.4.6.5. 项目结束经验总结
        • 活动描述
          • 市场部主导完成项目总结报告，内容包括项目获得的成果，包括技术、商务市场、项目管理的成果，项目中发现的问题乘积听未来改善机会
          • 研发部总结照给问题跟踪表，并记录到公共问题库中
          • PDT经理召集项目成员及其它项目相关人员（有后续量产任务则包括采购代表、生产代表和SQE代表）项目总结暨关闭会议，释放项目成员。总结会议主题包括项目总结报告内容分享、量产物料采购注意事项（认可的物料型号及供应商）、量产文件确定
        • 负责岗位
          • PDT经理
        • 输出
          • 项目总结报告
      • 4.4.6.6. GA
        • 批量供货点
        • 活动描述
          • PDT经理制定归档文件清单，检查归档文件版本是否为最新，文控中心管理员检查归档文件是否与归档文件清单相符合
          • 里程碑节点GA（一般可获得性）标志着发布阶段的结束，通知所有利益相关人产品已达GA点
        • 负责岗位
          • PDT经理
  • 4.5. 各代表关注点及主要活动
    • 4.5.1. 市场代表关注点及主要活动
      • 4.5.1.1. 概念
      • 4.5.1.2. 计划
      • 市场概况、环境分析、总体策略、细分&目标市场、需求确认、产品定位、竞争分析、分析成本&费用、预测销量盈利分析、上市策略和计划、营销资料计划
      • 4.5.1.3. 开发
        • 目标细分市场衔接，上市计划的执行进展，培训进展，营销资料进展，定价、配置器、准入、品牌宣传进展
      • 4.5.1.4. 验证
      • 4.5.1.5. 发布
      • 完成整套营销资料，上市策略活动评估，目标细分市场衔接，完成目标市场培训，完成定价、配置器、准入认证、品牌宣传、服务&支持，渠道管理，产品发布
    • 4.5.2. 财经代表关注点及主要活动
      • 4.5.2.1. Charter开发
        • 对项目的概念进行经济可行性方面的审视，项目所属产品未来3~5年损益预测。本项目对产品线的收入贡献、利润贡献。项目开发费用预测，设定目标制造毛利率、目标成本。
      • 4.5.2.2. 概念
      • 4.5.2.3. 计划
      • 项目在收益、成本方面的目标承诺，项目所属产品未来3~5年损益预测。本项目对产品线的收入贡献、利润贡献。项目开发费用预测，目标制造毛利率、目标成本承诺
      • 4.5.2.4. 开发
        • 项目在费用，成本方面的执行及达成情况，项目研发费用执行情况分析，目标成本层层分解，目标成本达成情况
      • 4.5.2.5. 验证
      • 4.5.2.6. 发布
      • 项目目标的达成情况，PDCP/ADCP主要财经指标对比及偏差原因分析，项目开发费用预算执行分析、回溯，目标成本达成情况审视
      • 4.5.2.7. 生命周期
        • 经营分析与指标监控，盈利情况、成长性、创新能力分析，跟踪目标达成情况，协助IPMT综合掌握市场、生产、服务运作绩效，及时进行相关运营管理决策
    • 4.5.3. 测试代表关注点及主要活动
      • 4.5.3.1. 概念
        • 参与项目启动和制定概念阶段计划，参与市场需求分析与验证，负责收集可测试方面的需求，共同开发产品需求和产品概念并进行技术评审TR1,初步制定测试策略，参与概念决策评审材料，参与测试计划编写，参与概念决策评审
      • 4.5.3.2. 计划
        • 确定、分配、增加外置测试人员，参与制定计划阶段计划，参与技术评审TR2，参与制定集成测试计划方案，可测试性设计，测试专利申请，完成测试工具概要设计，参与技术评审3，制定测试项目计划，参与计划决策评审
      • 4.5.3.3. 开发
        • 测试工具详细设计与开发，协助、监督单元测试，集成测试工作开展，生产测试设备设计、开发、参与技术评审TR4，领导系统设计验证（原型样机），参与技术评审TR4A，系统集成测试（功能样机），确定BETA测试用户，参与技术评审5
          • 项目需要在这个阶段，重点引导品质参与原型样机/功能样机的测试工作
      • 4.5.3.4. 验证
        • 系统验证测试，BETA测试，参与技术评审TR6，认证测试，测试结果评估，参与可获得性决策评审材料ADCP
      • 4.5.3.5. 发布
        • 参与网上问题的跟踪验证，协助设备升级，收集客户新的需求，参与重点客户的招标测试、技术支持，参与发布产品和公布GA日期
    • 4.5.4. 采购代表关注点及主要活动
      • 4.5.4.1. 概念
        • 提出可采购性需求、确保需求纳入产品需求并被准确完整地转化为设计需求，定义可采购需求，识别关键物料（包括新物料、老物料、自制产品、定制件、合作产品、外购物料等重要物料）
        • 制定关键物料采购策略，供应商前期介入管理，涉及外包合作项目，确定外包、合作策略，启动供应商寻源，启动关键器件的供应商选择。分析关键物料技术质量及商务风险，并制定风险规避计划和措施，配合系统工程师进行竞争对手物料造型和成本分析，启动定制件流程
      • 4.5.4.2. 计划
        • 确保可采购性需求高视阔步叶转化为设计规格和概要设计，跟踪关键物料选用风险，完成新物料的选型，关注原型机、小批量的申购
        • 参与可采购性需求分解分配，与PDT确定关键物料的需求量、目标成本及时间。概念阶段启动的寻源组织运作，协调物料专家团启动商务谈判，制定供应商选择方法和选择标准，已有关键物料降成本，跟踪关键物料风险及规避措施进展，新增加物料寻源/供应商选择，供应商前期介入管理，参与TR2评审，向产品线提供物料货期信息，对于长货期物料需要让PDT做出提前采购决定，对于己完成的寻源，启动编码申请，关注原型机、小批量物料的申购，参与TR3评审
      • 4.5.4.3. 开发
        • 确保物料的可采购性，重点关注非优选器件、生命周期后期物料、停产物料、高价物料，跟踪关键物料可用性、要采购性信息，与PDT保持紧密联系，反馈物料供货信息
        • 更新采购问题清单，更新关键及备选供应商名单，新增器件需求的寻源，对于己完成的寻源，启动编码申请，根据需求与供应商进行商务谈判，完成单板BOM清单评审，可采购性目标审视，跟踪采购风险及规避措施的落地，参与TR4评审，完成新物料的认证，价值供应商管理，解决物料的质量问题，参与TR4A评审，价值供应商成果验收、协议归档，参与TR5评审
      • 4.5.4.4. 验证
        • 解决验证阶段出现的来料质量问题，前期风险及重大遗留问题的跟踪解决，检视所有影响产品量产的物料问题已经关闭，跟踪量产后的需求计划己发布，推动关键器件替代测试，落实批量物料采购计划，协调采购相关部门，按计划采购生产物料，保证产品量产后的物料供货，参与TR6评审，评估产品目标成本是否达成，分析降成本机会点，总结验证阶段采购工作，拟制ADCP评审材料采购部分，向IPMT采购成员汇报
      • 4.5.4.5. 发布
        • 确保物料风险及问题己关闭，达到量产水平，关注后续需求己做滚动计划，达成成本和可采购性目标，落实批量物料采购计划，落实降成本措施，达成目标成本，解决供货、成本、质量的问题
      • 4.5.4.6. 生命周期
        • 持续供货保障、物料生命周期管理和降成本，物料采购降成本工作，解决供货问题，推动物料替代测试，停产物料供货保障，协助改版决策，批量物料质量问题处理及组织索赔，关注及刷新产品终止计划，确保采购物料与需求计划一致性，避免呆死料
    • 4.5.5. 制造代表关注点及主要活动
      • 4.5.5.1. 概念
        • 提出可供应/制造需求，确保需求纳入产品需求并被准确完整地转化为设计需求，制定供应/制造和订单履行策略，制定概念阶段项目计划，定义可供应/制造需求，制定供应/制造策略，制定订单履行策略，参与TR1评审
      • 4.5.5.2. 计划
        • 确保可供应/制造需求被准确完整地转化为设计规格和概要设计，制定供应/制造和订单履行计划、工艺和装备总体方案、物料需求计划
      • 4.5.5.3. 开发
        • 确保可供应/制造需求被正确完整地实现，设计、开发制造工艺和生产测试设备，完成试制准备，下达相应阶段物料计划，生产初始产品，输出PCB设计工艺要求
        • 参与整机试产，制定生产测试方案（含单板/整机/老化方案），输出测试装备规格书，下达原型机物料计划，参与TR4评审，输出制造系统验证方案，生产作业文件拟制，测试环境准备，初始产品物料计划，生产资源（含人员、场地、仪器等）准备，输出生产可测试性验证报告，参与报价模板/配置手册评审，参与TR4A评审，承担新产品试制验证，制造系统验证，下达RAMPUP物料计划，设置并验证订单履行环境，部分测试装备开发，参与TR5评审
      • 4.5.5.4. 验证
        • 开展制造系统验证，确保产品可供应/制造性得到验证并达到既定目标，完成新产品试制验证，输出验证报告，生产文件形式归档，测试装备正式验收，关闭试制验证暴露的问题，下达生产物料计划，完成对生产人员的产品知识培训，根据需要开发维修装备，参与TR6评审
      • 项目需要关注的重点
      • 4.5.5.5. 发布
        • 完成订单环境建立，向生产环境切换，RAMP UP生产，修改BOM状态属性
      • 4.5.5.6. 生命周期
        • 制造绩效监控参与EOX DCP评审，提供供应链库存/成本等分析发布EOX通知，组织最后一次生产,进行版本切换活动,资源释放，清理剩余生产物料/环境/夹具设备
    • 4.5.6. 服务代表关注点及主要活动
      • 4.5.6.1. 概念
        • 制定并分解目标服务成本，提出低服务成本关键需求，参与TR1评审，制定客户服务策略，参与CDCP评审
      • 4.5.6.2. 计划
        • 参与TR2评审，规划资料和早期培训需求，制定客户服务计划，制定服务准备对照检查表，参与PDCP评审
      • 4.5.6.3. 开发
        • 服务准备，BETA验证准备，参与TR5评审
      • 4.5.6.4. 验证
        • 实施BETA验证，参与TR6评审，技术服务准备评估，参与ADCP评审
      • 4.5.6.5. 发布
        • 发布服务交付件，经验、教训总结
      • 4.5.6.6. 生命周期
        • 组建生命周期团队，输出产品生命绩效管理目标，总结服务绩效管理，确认和反馈修正措施执行结果，提供EOS评估信息及EOS建议，制定EOS策略/公告，服务完成情况检查，EOS执行情况总结
    • 4.5.7. PQA关注点及主要活动
      • 4.5.7.1. 概念
        • 制定质量目标和产品质量计划，参与产品业务计划和E2E进度计划的评审，组织进行度量分析，对质量目标的达成情况进行监控，完成产品质量月报，进行本阶段流程执行过程中质量活动的引导和培训，负责组织、TR1评审，保证TR有效执行，关注产品质量问题并进行质量风险评估，进行本阶段的交付物审计，跟踪审计问题至关闭，跟踪本阶段的所有质量问题至关闭
      • 4.5.7.2. 计划
        • 优化产品质量计划，参与产品业务计划和E2E进度计划的评审，组织进行度量分析，对质量目标的达成情况进行监控，完成产品质量月报，进行本阶段流程执行过程中质量活动的引导和培训，负责组织、协调TR2、TR3评审，保证TR有效执行，关注产品质量问题并进行质量风险评估，进行本阶段的交付物审计，跟踪审计问题至关闭，跟踪本阶段的所有质量问题至关闭，确保产品质量策略和计划很好地向各个功能领域QA分解，协调各功能领域的QA活动，组织缺陷分析和质量回溯活动
      • 4.5.7.3. 开发
        • 监控产品质量计划，组织进行度量分析，对质量目标的达成情况进行监控，完成产品质量月报，进行本阶段流程执行过程中质量活动的引导和培训，负责组织、协调TR4、TR4A、TR5评审，保证TR有效执行，关注产品质量问题并进行质量风险评估，进行本阶段的交付物审计，跟踪审计问题至关闭，跟踪本阶段的所有质量问题至关闭，协调各功能领域的QA活动，组织缺陷分析和质量回溯活动
      • 4.5.7.4. 验证
        • 监控产品质量计划，组织进行度量分析，对质量目标的达成情况进行监控，完成产品质量月报，进行本阶段流程执行过程中质量活动的引导和培训，负责组织、协调TR6评审，保证TR有效执行，关注产品质量问题并进行质量风险评估，进行本阶段的交付物审计，跟踪审计问题至关闭，跟踪本阶段的所有质量问题至关闭，协调各功能领域的QA活动，组织缺陷分析和质量回溯活动
      • 4.5.7.5. 发布
        • 审核产品质量是否达到发布的要求，完成产品质量月报，协调各功能领域的QA活动，组织缺陷分析和质量回溯活动
      • 4.5.7.6. 生命周期
        • 组织缺陷分析和质量回溯活动
    • 4.5.8. 质量管理代表关注点及主要活动
      • 4.5.8.1. 概念
      • 4.5.8.2. 计划
      • 先期质量策划，技术评审，定期质量报告及纠正措施
      • 4.5.8.3. 开发
        • 外购外协过程质量控制，确认特性矩阵和关键特性，DFMEA,编制检验计划和标准，策划及准备测试/设备，检验首件模具，样品检验和试验，样机测试/可靠性测试，技术评审，定期质量报告及纠正措施
      • 4.5.8.4. 验证
        • 模具、夹具、检具验证，小批量检验，小批量测试，技术评审，定期质量报告及纠正措施
      • 4.5.8.5. 发布
        • 模具、夹具、检具验收，批量检验，批量产品抽样测试，技术评审，定期质量报告及纠正措施
  • 4.6. 产品开发过程专题
    • 4.6.1. 总体设计
      • 在总体设计的设计初期，所处的状态可以类比于处在十字路口而又看不清楚路在何方，这个时候需要多方探索、综合论证。在进行总体设计方案论证过程中需要由具备各方面技术能力的系统设计人员组成系统设计组，对系统方案进行论证说明，向相关决策人员解释各种设计方案，同时需要有具备相关决策能力的人员根据相关的论证说明进行决策。一项开发计划应当至少将10%～15%的资源投入到总体设计阶段。如果低于这一标准，将很可能导致无法对客户群做出准确把握。如果该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。
      • 4.6.1.1. 重点关注的内容
        • 在把握系统设计全局的同时关注系统设计的技术细节，系统设计方案是高层设计，但是高层设计不等于可以不关注系统实现的细节，在不影响进度的条件下，尽可能关注实现细节。因为对子问题的设计如果存在问题，那么整个系统的设计也不会完美
          • 关注细节，细节决定成败
        • 不放过任何可能，在技术的论证过程中，对任何可能的思路都要进行充分的分析和论证，避免将隐患埋藏在这些可能中
          • 把控风险
        • 在开发中存在历史系统的情况下，对历史系统进行全面的分析可以帮助系统设计人员理解新系统的设计，同时明确从历史系统中可以继承和需要摒弃的内容
          • 借鉴之前的经验，前提是需要做好之前的经验总结
        • 能够进行深入分析和测试的内容尽量提前做实际的工作，总体设计不是仅仅靠思考来解决的问题，能够通过测试（仿真测试或者实际测试）来获取数据的测试一定要进行，实际的数据是设计最可靠的依据
          • 所有的方案，都需要经过验证，以规避风险
        • 尽可能多收集数据，收集的数据包括和设计相关的各个方面，包括专利、历史系统的数据、技术发展趋势、标准的进展结论、标准的确定过程等
          • 做好技术收集及分析
        • 集体讨论，进行尽可能多的过程分析评审，集体讨论是脑力激荡的过程，过程分析和评审是通过每一小步的控制来实现总体控制的有效方法。在系统论证的过程中需要进行重复收放的节奏控制，“放”是分头研究，“收”是集中讨论
          • 集思广议
        • 具体的方案给出若干选项，在可能的方案中通常没有绝对优或劣，对可能的方案都要给出若干选项，进行优缺点比较
          • 做好方案分析
        • 选择能最好满足所建立标准的解决方案，通常要确定选择的标准和原理，对以往的相关的老产品的解决方案的描述、评价
        • 为相互冲突的目标和方案做出优先级划分，明确权衡点，对优先级的划分是需要项目管理人员参与的工作，优缺点比较是决策的基础
        • 为验证设计输出满足设计输入的要求，制定产品设计功能的验证测试及试验方案
        • 明确需要的资源（人、财、物、时间）及费用
        • 提高设计文档的质量，形成的报告要有详细内容的表述，包括设计思路的清晰表达、风险预测、平衡点的选择等，设计文档是将所有经过思考的内容落实到纸面的工作产品，这些记录有利于后续的深入分析，同时也是解释前面问题的依据
        • 对模糊的内容做出量化，这方面是最难做到的，也是容易忽视的，例如系统的质量特性，要对系统的质量特性进行数据刻画，同时对达到该目标的可能途经进行分析
        • 验证总体设计方案的标准有：
          • 系统方案
          • 系统设计与需求的一致性（可通过系统模型）
          • 系统方案与系统设计间的一致性
          • 定义清楚各大模块间的接口
          • 系统性能满足需求
          • 模块划分合理
          • 模块的输入输出接口定义恰当
          • 充分考虑到模块的可重用性
          • 模块细节描述清晰，可否直接用于开发
    • 4.6.2. 流程裁剪原则
      • 流程不是越细化越好，处于快速变化或者交期很短的行业，需求和产品变化非常快，产品生命周期短，流程结构化就不宜过于细化。企业研发规模比较大、产品比较复杂，涉及比较多的专业领域，流程可以细致一些，避免跨部门的沟通效率低，提高产品研发的质量
      • 我司的流程结构化就不宜过于细化
      • 4.6.2.1. 流程裁剪内容
        • 流程裁剪的目的是防止研发流程过度结构化，根据项目大小的不同，选择最优的流程和决策机制
        • 新产品项目
          • DCP裁减规则：PDCP、量产采购决策评审（纯软件项目除外）、ADCP不能删减
          • TR裁减规则：不能对己有的TR进行删减或者合并
        • 衍生类项目
          • DCP裁减规则：PDCP、量产采购决策评审（纯软件项目除外）、ADCP不能删减
          • TR裁减规则：TR3、TR5、TR6不允许删减
        • 升级类项目
          • DCP裁减规则：量产采购决策评审（纯软件项目除外）、ADCP不能删减
          • TR裁减规则：TR3、TR6不允许删减
        • 变更类项目
          • DCP裁减规则：DCP可选
          • TR裁减规则：TR6不能删减
      • 4.6.2.2. 裁剪流程
        • 提出
          • 项目经理、开发代表、PQA、项目管理工程师提出，PQA负责召集相关人员进行讨论确定
        • 批准
          • 对流程的裁减活动最终由PQA落实于该项目的《产品质量目标与计划》中，并且得到项目经理审核、研发管理部经理的批准。对交付件的裁减活动最终落实于该项目的《项目交付件清单》中，并且得到项目经理审核、研发质量部经理的批准
        • 变更
          • 在项目执行的过程中如果产生对流程和交付件清单的变更，按照设计变更流程进行处理，并最终落实《产品质量目标和计划》的变更
    • 4.6.3. 并行工程
      • 4.6.3.1. 传统的开发流程特点：
        • 信息流动是单向的，设计、制造过程中缺乏必要与及时的信息反馈，各环节配合不够紧密，设计制造不能一次成功
        • 基于图纸的设计，较多地依赖工程师的经验和试验数据
        • 缺少必要的产品开发、仿真工具，不能及早完善地考虑制造过程中质量控制等问题
        • 设计和工艺串行
        • 工艺设计完成前生产处于等待状态，生产准备时间较短，导致生产加工十分紧张，设备闲置时间较长
        • 产品的版本管理和变更管理手段落后，“孤岛”方式工作，集成手段差。
      • 4.6.3.2. 并行工程的目的
        • 提高全过程（包括设计、工艺、制造、服务）中全面的质量
          • 提高质量
        • 降低产品全生命周期中的成本（包括产品设计、制造、发送、支持、报废等成本）
          • 降低成本
        • 缩短产品研制开发周期（包括减少设计反复，降低设计时间、生产准备时间、制造时间、发送时间等）
          • 缩短周期
      • 4.6.3.3. 并行工程的方法
        • 
        • 全三维设计
        • 协同设计
        • MBD(Model Base Ddfinition)
          • 基于模型的工程定义
  • 4.7. 研发主要支撑流程
    • 研发主要支撑流程一般包括配置管理流程，产品认证流程，专利申请流程，外协管理流程，供应商物料认证流程，新供应商认证，问题、缺陷跟踪流程，物料描述变更流程，物料申请和维护流程，BOM发布流程，FAE流程等
    • 4.7.1. 配置管理流程
      • 4.7.1.1. 分配人力资源
        • 项目立项，IPMT给项目组分配人力资源，指定项目级CMO。项目负责人组建配置管理团队，并于项目开工会上正式任命
        • 组织级CMO在配置库中给项目分配独立的空间
      • 4.7.1.2. 项目团队培训
        • 项目开工会结束，视情况由项目级CMO组织项目组成员进行配置管理知识的培训。参与项目配置管理过程的所有成员，针对不同的角色，对配置管理培训内容不同，例如项目级成员只需培训过程中与职责对应活动内容，以及配置管理工具的使用
      • 4.7.1.3. 识别配置项
        • 项目负责人、系统工程师、项目级CMO对项目可能有的工作产品进行识别，并列入《配置项清单》，在识别配置项时，可直接参照《配置项清单》中的建议。遵循统一的命名规则，明确配置项纳入配置管理的时间及责任人
        • 输出：配置项清单
      • 4.7.1.4. 建立配置库
        • 设置配置库的目录架构，配置库的目录架构，标识出项目组员对配置库目录的操作权限，一般建议项目内的权限尽量宽松
      • 4.7.1.5. 制定、评审配置管理计划
        • 配置管理计划的制定由项目组CMO负责，项目负责人及系统工程师协助完成，配置管理计划主要包含资源、命名规范、配置库目录、访问权限、基线、发布、备份、变更控制等
        • 输出：配置管理计划
      • 4.7.1.6. 配置审计
        • 根据审计计划，执行配置审计，配置审计的目的是为了保证纳入基线之前的配置项的一致性和完整性，配置审计的人员一般为SE、QA、项目级CMO等
        • 输出：配置管理检查单
      • 4.7.1.7. 持续提交配置项
        • 在项目整个生命周期内，各成员按配置管理计划提交配置项，同时由项目级CMO提醒各成员
      • 4.7.1.8. 定期报告配置管理过程执行
        • 项目组CMO在执行配置管理日常工作的同时，就报告过程的执行情况。上述相关的过程数据，给项目提供参考，项目级CMO通过分析配置管理过程相关数据，拟写《配置管理工作报告》向项目组CMO的上一级行政主管汇报
        • 输出：配置状态报告
      • 4.7.1.9. 执行产品交付审计
        • 在项目交付前，项目级CMO将配置项整理，提交由组织级CMO、客户代表、QA、项目负责人、SE等人员组成的审计组进行交付审计，产品交付审计使用《配置审计检查单》进行检查，对交付审计结果中的不合格项，项目负责人进行关注、项目级CMO跟进解决，QA对不合格项的纠正情况进行检查
        • 交付配置审计结束后，项目级CMO将审计后的所有配置项及产品包整理改善给组织级CMO。同时，项目级CMO将配置库内相关人员的权限收回。项目级CMO将交付审计产品包提交给组织级CMO；组织级CMO并将其归档，同时将配置库备份
        • 输出：配置审计检查单/配置管理工作报告
    • 4.7.2. 产品认证
      • 4.7.2.1. 产品认证流程
        • 提交、批准认证申请
          • 根据产品说明书编写认证申请书，并经过签审
        • 签订认证合同、PO
          • 付费申请
        • 功能样机准备、网卡申请及资料准备
          • 提交功能样机及相关的资料到实验室
          • 检验样品是否符合标准；型式试验报告
        • 第三方认证机构进行测试、出报告、申请证书
          • 测试通过后，第三方实验室出测试报告及证书申请书
          • 安排证书费用
        • 工厂检查（如有）
          • 审查后如有不符合项，需要马上进行限期纠正。提交纠正预防措施报告，并跟进证书
        • 获得报告、证书
          • 索要证书、发票，申请印刷证书标志
        • 更新物料和BOM清单
          • 产品变更，增加对应标识
        • 申请年检（如有）
      • 4.7.2.2. 注意事项
        • 网上登记后，会在网站上显示需要准备的资料清单。如果申请的类别是第一次申请，则先要取得相应类别的工厂检查报告，再进行下面的认证程序
        • 样机一般由硬件工程师准备，在送检实验室之前最好先检测
        • 收到样品后，认证工程师注意保存样品，以备以后查验，及时通知结构工程师修改物料清单
        • CCC标志尺寸大小和工程师要确认好，CCC标志有效期为1年，每年进行年效
      • 4.7.2.3. 认证需要的资料清单
        • CCC认证
          • 所需材料（CQC）：CCC认证申请书、一致性声明、营业执照、加工协议书、商标注册证、商标授权书、工厂检查报告
          • 所需材料（SET）：CCC认证申请书、一致性声明、原理图、关键元器件清单、送检的样品要有序列号，贴纸上原则上不允许胡CCC标志
          • 备案资料：填写“印刷/模压标志申请书”并加盖公章，提供认证证书复印件，提供带有CCC标志图案和工厂代码、产品型号的铭牌样品一式四份，没有铭牌的，CCC标志直接加施在产品本体上需提供设计方案一式两份
          • 年审资料：填写年审申请书
        • CE认证
          • 原理图、框图、关键元器件清单等
        • UL认证
          • 线路图/Layout/Label、BOM表、外壳尺寸图、外壳的厂家和型号、电池厂家和型号等
    • 4.7.3. 专利申请流程
      • 4.7.3.1. 专利知识点
        • 定义
          • 是指发明、实用新型和外观设计
        • 分类
          • 发明专利
            • 是指对产品、方法或者其改进所提出的新的技术方案
            • 发明专利权的期限为二十年，均自申请日起计算
          • 实用新型专利
            • 是指对产品的形状、构造或者其结合所提出的适于实用的新的技术方案
            • 实用新型专利权的期限为十年，均自申请日起计算
          • 外观专利
            • 是指对产品的形状、图案或者其结合，以及色彩与形状、图案的结合所做出的富有美感并适于工业应用的新设计
            • 外观设计专利权的期限为十年，均自申请日起计算
          • 每年的缴费时间为专利申请日前一个月
        • 专职或者兼职的专利申报员
          • 定期收集国内外相关的专利信息，尤其是竞争对手的专利信息，并对收集到的专利信息进行整理、分析、预测、做出研究报告
          • 负责对公司员工进行专利知识培训
          • 负责对公司员工进行专利知识培训
          • 负责专利申请、专利运营、专利权维持和维护、专利纠纷处理等
          • 负责专利奖励和专利测评，鼓励和支持公司员工的发明创造
      • 4.7.3.2. 专利申请流程
        • 提出专利申请
          • 研发工程师在国家知识产权局的网站，对工作中涉及的发明创造进行初步检索，对于满足专利性（新颖性、创造性、实用性）的发明创造，研发工程师以发明人或设计人的身份填写《专利申请表》《技术交底书》，提出专利申请
        • 对发明创造进行专利性审核
          • 发明人或设计人提交《专利申请表》《技术交底书》给其部门经理，部门经理根据接收的材料，对发明创造是否具备新颖性、创造性、实用性进行审核
          • 希望按发明申请的专利，需要召开由发明人、所在部门经理、专利申报员参加的专利申请会议讨论。会议召开前发明人需提供《发明报告书》，说明现有技术问题、新技术内容及效果，并对拟申请专利的技术从技术本身、本公司实施状况、其它公司实施状况、其它公司牵制力方面进行评价。会议的结论以会议纪要的形式记载。确定按发明专利申请的专利，进入专利申请文件撰写
          • 希望按实用新型或外观设计申请的专利，直接进入专利申请文件撰写
        • 专利申请文件撰写
          • 专利申报员根据《专利时刻表》《技术交底书》，撰写专利申请文件，按专利申请的类型，主要的申请文件包括请求书、权利要求书、说明书、说明书附图、摘要、摘要附图、外观图片、简要说明等
          • 专利申报员完成专利申请文件的撰写后，交发明人审核，发明人审核专利申请文件描述的技术内容是否与发明创造一致，审核通过后，交部门经理审批
        • 向国家知识产权局申请专利
          • 由专利申报员负责提交给国家知识产权局。具体为：准备专利申请文件一式三份，两份邮寄给国家知识产权局专利局受理处，并跟踪邮件是否签收，一份存档
        • 国家知识产权局受理专利申请
          • 通常专利申请文件提交三个月内，国家知识产权局将受理专利申请，并发出《专利申请受理通知书》。填写借款单用于缴纳专利申请费，财务转账后将账单传真给国家知识产权局专利局收费处，并在账单上注明该款项的用途
        • 国家知识产权局初步审查阶段
          • 缴纳专利申请费后，国家知识产权局将对专利申请文件进行初步审查。期间，国家知识产权局可能会针对专利申请文件发出《补正通知书》。专利申报员收到《补正通知书》后，根据审查员的要求对专利申请文件进行修改。修改后的专利申请文件交发明人审核，发明人需审核修改后的专利申请文件描述的技术内容是否发明创造一致。审核通过后，交研发部门审批，由专利申报员负责提交给国家知识产权局。具体为准备补正的专利申请文件一式三份，两份邮寄给国家知识产权局专利局受理处，并跟踪邮件是否签收，一份存档
        • 国家知识产权局初步审查通过
          • 对于实用新型和外观设计专利，经初步审查，没有发现驳回理由的，国家知识产权局将发出《授予专利权及输登记手续通知书》。对于发明专利，经初步审查，符合专利法及其实施细则规定的，国家知识产权局将发出《发明专利申请初步审查合格通知书》
        • 国家知识产权局实质审查前
          • 专利申报员收到《发明专利申请初步审查合格通知书》后，需要召开由发明人、所在部门经理、专利申报员参加的专利进入实申、国际申请会议讨论，会议的结论以《会议讨论纪要》的形式记载。对于确定要进行实质审查的专利申请，由专利申报员填写《实质审查请示书》《请示提前公开声明》一式两份，一份邮寄给国家知识产权局受理处，并跟踪邮件是否签收，一份存档。同时填写借款单用于缴纳实质审查费，财务转账后将账单传真给国宝知识产权局专利局收费处，并在账单上注明该款项的用途
        • 国家知识产权局实质审查
          • 缴纳实质审查费后，国家知识产权局将对发明专利的申请文件进行实质审查。期间，国家知识产权局可能会针对专利申请文件发出《审查意见通知书》。专利申报员收到《审查意见通知书》后，针对审查员的疑问撰写《意见陈述书》，有时需要对原专利申请文件进行修改。《意见陈述书》交发明人审核，发明人需审核《意见陈述书》描述的技术内容是否与发明创造一致。审核通过后，交部门经理审批，部门经理对《意见陈述书》描述的内容是否进行专利申请进行批准，由专利申报员负责提交给国家知识产权局。具体为：准备补正的专利申请文件一式三份，两份邮寄给国家知识产权局专利局受理处，并跟踪邮件是否签收，一份存档
        • 国家知识产权局实质审查通过
          • 对于发明专利，经实质审查，没有发现驳回理由的，国家知识产权局将发出《授予专利权及办理登记手续通知书》
        • 国家知识产权局授权
          • 专利申报员收到《授予专利权及输登记手续通知书》后，填写借款单用于缴纳专利登记费，财务转账后将账单传真给国宝知识产权局专利局收费处，并在账单上注明该款项的用途
        • 国家知识产权局颁发证书
          • 缴纳专利登记费后，国家知识产权局将颁发专利证书
  • 4.8. 流程常见的问题及对策
    • 4.8.1. 流程需要优化的现象有哪些
      • 4.8.1.1. 开发产品没有一个“统一方法”
        • 项目团队成员没有经过系统的培训，都是按自己的方法在管理项目
      • 4.8.1.2. 术语和定义不一致
        • 没有经过专利的项目管理培训
      • 4.8.1.3. 注意力集中在“救火”上
        • 没有做好项目计划
        • 没有注意好风险控制
      • 4.8.1.4. 过多的澄清会议
      • 4.8.1.5. 中层管理人员太多（太多会议）
      • 4.8.1.6. 无法估计出资源需求（很忙、没有头绪）
      • 4.8.1.7. 进度表不准确
      • 4.8.1.8. 无法估计出资源需求
      • 4.8.1.9. 小组与小组之间的计划不衔接（对出现问题有不同的理解）
      • 4.8.1.10. 过量的任务间的相互依赖
      • 4.8.1.11. 对职责理解不够
      • 4.8.1.12. 浪费在没有附加值的工作上的时间（协调、重做）
    • 4.8.2. 流程优化的技巧
      • 4.8.2.1. 消除或压缩流程中的等待和传递时间
        • 流程多样化、提高针对性，将串行活动变成并行活动，去除不需要的活动，减少流程步骤，合并内部的界面（环节），调整各环节的地理位置或导入IT应用，压缩每个环节的时间，规定时间期限
      • 4.8.2.2. 优化流程中的检查与审核
        • 根据发生错误的概率来决定检查，评审点设置的必要性，取消重复审批点，根据控制对象的风险和金额的大小，进行分层审批，采用窗口式服务
      • 4.8.2.3. 减少流程中的返工
        • 提高流程中决策点的透明度，建立经验、教训、共享知识库，规范对流程执行人员的培训，重要活动定义操作规范和模板
    • 4.8.3. 流程如何有效推行
      • 4.8.3.1. 简单，不要复杂难以理解的流程，也不需要制定过多的流程规范
        • 不断优化/调整流程，以便更好的促进团队的工作
      • 4.8.3.2. 抓住主要问题，不要贪大求全
        • 抓大放小，全面推进
      • 4.8.3.3. 研发管理核心人员的支持
        • 需要提前与骨干沟通好，以取得他们的支持
      • 4.8.3.4. 注意宣传
        • 平时需要注意不断宣导，强调，指引，带领大家按流程来开展自己的工作
      • 4.8.3.5. 推广团队的稳定性及有效培训
      • 4.8.3.6. 纠正预防
        • 不断的总结评审
      • 4.8.3.7. IT系统落地
        • 团队熟练使用TB
    • 4.8.4. 如何保证流程体系执行的质量
      • 4.8.4.1. 规划管理文档体系
        • 明确定义各样的规范、指导书、Checklist等文档之间的关系，以及它们的主要作用
      • 4.8.4.2. 一次性把事情做好
        • 充分获取和理解各方面输入的资料，弄清楚产品的应用场景，这也是一个对需求理解的过程。要求必须完成前一阶段的工作并为下一阶段工作提高质量的输入，保证每一阶段的工作老师连续的、正确的
      • 4.8.4.3. 严格按照流程要求执行
        • 加深对流程的认识，严格按照流程规定操作而且要提高研发人员责任心。不要问题认为按照流程操作太机械化、不灵活，国际化的大公司就应该机械化，机械化的工作方式能够使犯错误的概率降至最低
      • 4.8.4.4. 加强各阶段的评审和监控力度
        • 保证每个阶段的输出质量
      • 4.8.4.5. 保证系统分析全面性
        • 对产品的备选方案进行全面检查，形成文档。减少后期工作很多不确定性，不要出现后期推翻之前的结论，或者到后期才发现很多现成的部件或模块由于结构安装布局或供电等原因而无法使用，只能要求重新开发的情况，提高模块或部件的共享性
    • 4.8.5. ODM/OEM行业VOC活动介绍
      • 4.8.5.1. 定义
        • VOC是ODM/OEM类型项目的典型活动之一，对认证、知识产权、技术功能、测试和物料需求进行评估。一般自主研发项目则没有VOC活动
      • 4.8.5.2. 交付的内容
        • 客户原始需求列表
        • 关键物料风险评估报告
        • Q&A问题整理列表
      • 4.8.5.3. 工作内容
        • 项目经理根据立项阶段获得的市场信息进行VOC
        • 照要求完成客户原始需求列表和规格信息，VOC应该包括客户对象、收集需求的时间、方式（交谈、邮件、电话或传真等）、责任人、结束的时间和客户确认的时间
        • 目经理组织需求分析人员进行信息分析，并分组提出问题，将问题写入客户原始需求列表的Q&A部分。分组为硬件、软件、结构、硬件测试和软件测试
        • 项目经理召开需求讨论会，组织需求分析人员对Q&A问题进行确认，删除不需要的问题，补充需要核实的问题
        • 项目经理将问题发给客户并规定客户回复的时间
        • 收到客户回复后，项目经理组织需求分析人员进行理解和消化，确定是否需要开始新一轮的VOC
• 5. 产品文档管理
  • 强交付，弱流程。强市场，弱文档。追求组织级研发，但核心人才不可替代
  • 5.1. 产品开发阶段文档清单
    • 5.1.1. 项目任务书阶段
      • 5.1.1.1. 市场评估报告
        • 市场分析、竞争分析、客户分析、目标市场分析、整体战略建议
      • 5.1.1.2. 项目可行性分析报告
        • 项目目标和范围、理解市场、可行性分析、组合分析和产品策略、产品描述、项目进度和资源、财务评估、风险评估
      • 5.1.1.3. 业务计划书
        • 市场分析和产品策略、竞争分析、需求分析、产品概述、执行策略、生产和供货计划、市场计划、客户服务/支持计划、项目进度和资源、风险评估、财务评估、最终建议
      • 5.1.1.4. 项目任务书
        • 客户需求、产品功能需求、市场机会、目标市场分析、竞争对手分析、法律法规或行业要求、人力和设备需求、交期、评估研发成本
      • 5.1.1.5. 立项决策评审报告
        • 产品背景简介、评审意见、问题汇总，以及解决计划、责任人、评审结论建议、决策参与人员
    • 5.1.2. 概念阶段
      • 5.1.2.1. 项目开发计划
        • 确定产品开发步骤、人员和时间
      • 5.1.2.2. 产品概念和可选方案
        • 目的、产品概述、备选概念及可选技术方案
      • 5.1.2.3. 产品包需求
        • 概述、市场需求、公司内部需求、设计约束
      • 5.1.2.4. 关键器件清单
        • 关键物料风险评估报告
      • 5.1.2.5. 产品质量目标和计划
        • 评审项目应达到的质量目标和文档交付计划
      • 5.1.2.6. TR1评审报告
        • 评审基本信息、产品质量评估、评审结论、技术评审过程规范评估、核心组成员会签记录
      • 5.1.2.7. 产品制造策略
        • 为产品生产拟制制造策略，包括生产场地、原材料供应、质量、物流、生产测试、工艺路线、订单履行、整机包装等
      • 5.1.2.8. 概念决策评审报告
        • 产品背景简介、评审意见、问题汇总，以及解决计划、责任人、评审结论建议、决策参与人员
    • 5.1.3. 计划阶段
      • 5.1.3.1. 总体设计说明书/总体设计方案
        • 产品可选方案列表，系统设计人员进行整理各类概念，敢打产品可选方案列表，该表应该包括概念说明、成本评估、技术瓶颈等
      • 5.1.3.2. 产品设计规格书
        • 正式描述产品的需求和规格，产品关键功能列表，标识出产品的关键功能
      • 5.1.3.3. 测试策略
        • 为新产品的设计开发制定产品测试的关键技术、测试环境、工具设备、测试方法的一系列策略
      • 5.1.3.4. TR2评审报告
        • 评审基本信息、产品质量评估、评审结论、技术评审过程规范评估、核心组成员会签记录
      • 5.1.3.5. 结构概要设计说明书
        • 概述、结构整体方案说明、结构概要设计、包装设计方案、主要加工工艺分析、整机可装配性设计及走线工艺要求、共用模组和共用零件、新配件说明、可采购性及成本分析、技术指标及性能清单
      • 5.1.3.6. 硬件概要设计说明书
        • 概述、针对需求的具体技术方案、总体技术方案、硬件系统框架说明、各功能单元概要设计说明、整体布局、PCB板布局、信号完整性分析、关键物料清单、物料成本分析、风险控制
      • 5.1.3.7. 软件概要设计说明书
        • 概述、设计约束、总体设计、接口设计、系统数据结构、模块定义、安装/运行/配置、软件调试测试方法
      • 5.1.3.8. 产品测试和验证计划
        • 确定的测试活动的范围、方法、进度和资源，明确测试项、被测特性，测试任务、谁执行任务等信息
      • 5.1.3.9. TR3评审报告
        • 评审基本信息、产品质量评估、评审结论、技术评审过程规范评估、核心组成员会签记录
      • 5.1.3.10. 供应商分析报告
        • 供应商总体情况、评价指标、等级划分建议等
      • 5.1.3.11. 长周期物料采购计划
        • 描述采购周期超过6周的物料清单
      • 5.1.3.12. 物料规格书/承认书
        • 描述物料可用性（是否停产、是否有不良记录）
      • 5.1.3.13. 物料审核报告
        • 公司评估承认书和样品，提交该报告
      • 5.1.3.14. 计划决策评审报告
        • 产品背景简介、评审意见、问题汇总，以及解决计划、责任人、评审结论建议、决策参与人员
    • 5.1.4. 开发阶段
      • 5.1.4.1. 结构详细设计说明书
        • 概述、整机装配设计、内部设计实现，包装装配图和零件图，组装与拆卸，搬运、安装、使用和维护动作模拟分解，零件可制造性分析，存在的风险及措施，需求符合性分析，模组说明，材料表，模具需求
      • 5.1.4.2. 3D/2D图纸
        • 结构详细设计图纸
      • 5.1.4.3. 手板试装报告/手板测试报告
        • 概述（零件号、零件名称、供应商、检验依据、试装/测试人员，地点，日期），试装情况描述，试装结论（认可、临时认可、拒绝）
      • 5.1.4.4. 手板评审报告
        • 评审基本信息、产品质量评估、评审结论、技术评审过程规范评估、核心组成员会签记录
      • 5.1.4.5. 包装需求说明
        • 包装风格、形式、色彩、技术要求、材质、规格、印刷文字、运输方式及要求、成本、产品开启方式
      • 5.1.4.6. 纸箱样品报告
        • 客户名称、料号、检验数量、打样次数、单号、检验日期
        • 检验项目（印刷、掉色、内容、颜色、外观，内外径尺寸、制造尺寸、耐破强度、边压/空箱抗压、结合、裱合、纸板厚度、含水率、RoHS要求等）、技术规格要求，是否合格
      • 5.1.4.7. 硬件详细设计说明书
        • 概述、各功能模块的详细设计说明，硬件单板主要接口定义、与相关板的关系，单板可靠性综合设计说明，单板可维护性设计说明，单板信号完整性设计说明，EMC、ESD、防护及安规设计说明，单板工艺设计说明，单板结构设计说明，风险管理，附件
      • 5.1.4.8. SCH文件
        • 原理图图纸
      • 5.1.4.9. PCB文件
        • PCB图纸
      • 5.1.4.10. PCB制版要求文件
        • 描述PCB板文件名（产品名称+PCB板版本信息+发板日期）、制版数量、PCB板尺寸、PCB板材料、层数、责任工程师的联系电话、要求完成制板的日期、是否加急等
      • 5.1.4.11. 单板试制报告
        • 试制说明、试制结果判定、试制数据记录、试制问题点记录
      • 5.1.4.12. 单板调试记录
        • 单板硬件/软件功能模块划分、单板硬件各模块设计进度、调试中出现的问题及解决方法、原始数据记录，系统方案/单板方案/器件/原理图/PCB图/可编程器件修改说明,调试工作阶段总结,调试进展说明,下一阶段调试计划及测试方案的修改
      • 5.1.4.13. 硬件测试报告
        • 概述、测试范围、调试测试用例记录、测试总结、测试结果
      • 5.1.4.14. 软件详细设计说明书
        • 概述、模块架构、数据结构、算法和逻辑、模块描述、类/对象接口、性能需求、其它需求、安装/运行/配置
      • 5.1.4.15. 软件单元测试报告
        • 记录测试过程和环境,包括所有的硬件/软件环境和配置,测试用例和测试结果
      • 5.1.4.16. 软件集成测试方案
        • 概述、需求跟踪、测试内容、测试环境、测试用例、测试通过准则、评审报告
      • 5.1.4.17. 软件集成测试用例
        • 对软件确认测试环境进行整体描述，包括硬件环境、软件环境和测试环境搭建方法的描述，还包括描述健壮性、性能、压力、可靠性、安全性测试用例
      • 5.1.4.18. 软件集成测试报告
        • 记录测试过程和环境，包括所用的硬件、软件环境和配置，集成测试结果，集成过程发现的问题和需要的修改，如接口或详细设计的修改。描述对软件功能进行测试的结果，包括功能缺陷率
      • 5.1.4.19. 测试方案
        • 概述、需求跟踪、测试内容、测试环境、测试用例、测试通过准则、评审报告
      • 5.1.4.20. 测试用例
        • 用例编号、用例名称、需求描述、测试目的、测试类别、测试对象，用例级别、测试工具、前置条件、测试步骤/测试方法、测试预期结果、测试结果、测试结论、测试工程师、测试日期、备注
      • 5.1.4.21. 产品用户操作手册
        • 产品简介、操作前的准备工作、各种功能实现的操作、软件操作等
      • 5.1.4.22. 产品安装手册
        • 安装注意事项、安装前准备工作、安装步骤（使用工具、步骤、提醒）、安装参考说明、技术参数
      • 5.1.4.23. 产品维修手册
        • 产品概述、功能特性、应用环境、工作过程、产品组成、原理分析、构造与维修、故障对照表、技术性能参数、主要零件技术要求与维修标准、维修案例、专用工具
      • 5.1.4.24. TR4评审报告
        • 评审基本信息、产品质量评估、评审结论、技术评审过程规范评估、核心组成员会签记录
      • 5.1.4.25. 产品工艺文件
        • 工艺流程图、工序流程卡、基本构成表、QC工程图、物料技术规范书、零件规格承认书、制造作业指导书、测试作业指导书、设备操作指导书、产品维修手机、SMT制板工艺文件、装配图、产品缺陷不良跟踪列表、程序烧录清单、产品装箱清单、产品标识规范等
      • 5.1.4.26. 预测试报告
        • 概述、测试概要、测试结果及发现、测试结论、分析摘要、测试资源消耗
      • 5.1.4.27. 原型样机测试报告
        • 概述、测试概要、测试结果及发现、测试结论、分析摘要、测试资源消耗
      • 5.1.4.28. TR4A评审报告
        • 评审基本信息、产品质量评估、评审结论、技术评审过程规范评估、核心组成员会签记录
      • 5.1.4.29. 功能样机测试报告
        • 概述、测试概要、测试结果及发现、测试结论、分析摘要、测试资源消耗
      • 5.1.4.30. TR5评审报告
        • 评审基本信息、产品质量评估、评审结论、技术评审过程规范评估、核心组成员会签记录
    • 5.1.5. 验证阶段
      • 5.1.5.1. 生产资料包
        • 制版文件、工程图纸、BOM、成品检验规范、生产加工注意事项、目标程序、测试程序（工厂用）、测试操作指引
      • 5.1.5.2. 试产报告
        • 生产部门统计生产数据，包括不良率、各工序的合格率和各工序的数据记录及总结
      • 5.1.5.3. 认证证书
        • 认证证书是指产品、服务和管理体系通过认证所获得的证明文件，如CCC、CE、UL、TUV等
      • 5.1.5.4. TR6评审报告
        • 评审基本信息、产品质量评估、评审结论、技术评审过程规范评估、核心组成员会签记录
      • 5.1.5.5. 测试总结
        • 测试主要版次、测试内容、测试遗留问题、测试结论、建议
      • 5.1.5.6. 发布计划
        • 市场分析、产品定位、发布主题、宣传和推广计划、技术交流会/现场发布会展览会安排、广告宣传计划、技术专刊、宣传光盘、产品（客户、内部各部门）交付件
      • 5.1.5.7. 价格策略
        • 产品市场定位、产品定价、产品收益分析、竞争品牌价格分析
      • 5.1.5.8. 上市决策评审报告
        • 产品背景简介、评审意见、问题汇总，以及解决计划、责任人、评审结论建议、决策参与人员
    • 5.1.6. 发布阶段
      • 5.1.6.1. 项目总结
        • 项目基本信息，进度完成情况总结，项目质量情况总结，测试工作总结，项目主要成果、经验、教训总结
  • 5.2. 系统设计文档模板
    • 5.2.1. 产品概念可选方案
      • 5.2.1.1. 目的
        • 基于产品需求确定备选概念，并评估、选择及定义概念
      • 5.2.1.2. 产品概述
        • 产品定位，系统对外接口
      • 5.2.1.3. 备选概念及可选技术方案
        • 备选概念1：
          • 备选概念详细描述，使用系统方框图方法，依据系统功能把产品分解成子系统、模块和元件及它们之间的接口部分，并明确各部分应部分功能。产品能力比较，明确现有产品己能提供的能力，并明确和新产品应提供能力间的差距在功能或者性能的比较上，可以分为产品性能、产品技术参数，以及我们能够遵守的公司或者行业规范等要求。审查功能差距，给出解决思路。扩展/重新设计现有元件、模块或子系统，由改良后的替换现有的，改变配置或者完全重新设计系统。这些便成为新系统的备选概念，这些备选概念仍用类似前面的框图表示
        • 备选概念2：
          • 同上，若有多个备选概念，依次描述
        • 评估并选择概念，分析各备选概念的功能/性能、产品成本、上市时间、开发成本、开发资源、客户满意度、质量、可靠性、可服务性、可制造性、可测试性等各维度评估备选概念的优缺点
        • 特别要描述该产品的目标成本，作为PDT开发选择的重要依据之一
    • 5.2.2. 产品包需求/设计需求模板
      • 5.2.2.1. 概述
        • 产品描述
        • 产品功能和特性，说明产品的卖点功能、特性，说明完成的业务特性
        • 产品开发环境，描述产品结构、硬件、软件、测试的开发环境
        • 产品应用环境，描述产品使用运行环境
      • 5.2.2.2. 市场需求
        • 外观需求，成本和目标价格需求
        • 功能和性能需求量1：说明功能的目的、实现方法、涉及技术等，本功能所进行的处理过程
        • 功能和性能需求2：
        • 国际化差异需求，环保需求，用户界面，其它。。。
      • 5.2.2.3. 公司内部需求
        • 可采购性需求，可靠性需求，可测试性需求（包括软件可测试性需求、硬件可测试性需求、装备可测试性需求），可制造性需求，可服务性需求，兼容性说明，固件/软件包发布需求，外部接口需求，硬件接口需求，固件/软件接口需求，其它
      • 5.2.2.4. 设计约束
        • 需要遵循的标准，硬件限制，固件/软件限制，工艺限制，成本限制，国际化支持，其它
    • 5.2.3. 长周期物料采购计划
      • 
    • 5.2.4. 关键器件清单
      • 
    • 5.2.5. 总体设计方案模板
      • 5.2.5.1. 引言
        • 编写目的、术语定义、参考资料
      • 5.2.5.2. 概述
        • 技术规格、开发环境、应用环境
      • 5.2.5.3. 结构总体设计
        • 用户操作界面，人机工程设计，操作指示及标识，状态指示灯等
        • 外部接口，电源接口，其它输入、输出接口等
        • 系统的基本结构组成，整机布局设计，表达出结构概况和相互关系，结构模组选择与规则
        • 安全性设计，安规设计，环境适应性设计，包装设计，安装维护方面的特殊设计，描述可能同其它系统的关系（附件、配件）
      • 5.2.5.4. 硬件总体设计
        • 软硬件接口设计，硬件安全设计，Layout布局设计，硬件框图
      • 5.2.5.5. 软件总体设计
        • 软件的架构设计，系统启动流程设计
        • 模块划分，列出可能划分的模块名称、功能、发布方式等
        • 系统资源分配，包括内存、定时器等资源分配共享的解决方案
        • 系统调用API接口，通信协议，如BOOT层、操作系统等协议，软件安全设计，关键用户界面，开机界面，菜单，版本显示等设计，兼容性设计，通信协议/API等兼容性设计
      • 5.2.5.6. 产品规格书模板
        • 范围
          • 名称、型号、版本、保密代号，定义产品包的名称、商标、型号和版本，说明产品包归属于哪个系列的、归属哪个产品线
        • 概述
          • 产品性质、产品开发的历史、标识项目利益相关人、当前和计划的使用地点
        • 系统总体设计
          • 产品包功能、性能特性、技术参数、遵循的标准：
            • 此概要说明产品包对外提供的功能特性及相应的性能指标，可以先设计需求进行概括描述。定义产品包在提供业务时对外表现的性能指标，所有性能指标需注明出息，如是参照国际标准、国标、竞争对手、理论计算等。定义功耗、电源参数、尺寸、电气特性等技术参数、说明本产品所遵循的国际、国家或行业、企业标准，判处列出本产品需要符合的产品规范、业务或协议标准、接口规范及标准
          • 系统总体结构：
            • 用系统方框图描述，说明组成系统的各部分是如何搭配成一个完整系统的
          • 功能实现原理：
            • 描述系统是如何运作以实现系统需求的，包括各功能模块的功能描述，各功能模块之间的控制关系、信息流向，系统需求中所胡功能如何通过这些模块及它们之间的互相关系来实现，逐项描述主要功能特性、业务的实现原理
          • 系统配置：
            • 平台配置、硬件配置、初始产品配置清单
          • 系统升级与可扩展性：
            • 新版本与原有版本之间的兼容性，客户在升级到新版本的成本是否较小，平邑 在业务、系统功能、性能上可扩展性方面的规格定义及设计，在一定时间内能满足部分新功能的开发
          • 系统内外部接口：
            • 描述系统外部接口，通过图例说明子系统间接口，并给每个接口赋予唯一的标识
        • 结构设计
          • 系统结构配置
            • 定义系统结构主要模块配置，典型应用集成
          • 结构设计标准及外形尺寸：
            • 定义结构设计所遵循的标准及规范，以及外观最大尺寸
          • 包装运输设计描述：
            • 明确产品基本特征，明确产品预计价值、产品物理化学易损性、产品强度与易损性、包装形式、产品包装防护需求
          • 三防（防霉、防潮、防盐雾）设计描述：
            • 完成结构件及其表面防护层的设计选用方案，并对其可行性进行分析，分别说明各种结构件要求使用的材料种类，分别说明不同材料结构件应采用的表面处理方式
          • IP防护设计描述：
            • 防尘需求、防水需求
          • 结构安全设计描述：
            • 说明产品的结构防火外壳、非金属材料的阻燃等级、产品的稳定性和强度、防止结构危险性能、电连续性能，以及电气间隙、标签方案等特性应符合这些标准中的规定
        • 硬件设计
          • 说明硬件采取的基本设计思路，概要描述为什么采取本方案
          • 硬件配置：描述主要应用中平台的硬件配置
          • 硬件开发平台：介绍硬件开发的环境、工具、编译器、可编程性设计工具
        • 软件设计
          • 说明软件采取的基本设计思路，概要描述为什么采取本方案
          • 软件配置：描述软件配置，包括驱动软件、协议软件、应用软件、工具软件等配置情况，说明编号及简要功能
          • 软件包描述：描述发布时软件包所包含的所有软件的内容，软件载体，软件安装方法，软件开发的环境、工具、编译器、数据库等
        • 成本分析
          • 列出主要、关键器件/部件，将目标成本分解到各个独立的项目（分解到关键器件/部件），根据关键器件等价格，计算组成产品的成本
        • 规格列表
          • 规格清单部分针对上述部分的系统规格描述、硬件子系统及模块规格、软件子系统及模块规格、结构子系统及模块规格，以简练、专业化的语言，采用列表的形式给出，相当于产品规格书的索引项目列表，作为产品规格更改控制、规格鉴定、市场发布与规格符合度测评的依据，也作为后续软硬件项目的分配需求
  • 5.3. 研发文档评审要素
    • 5.3.1. 产品包需求文档评审要素
      • 5.3.1.1. 市场代表
        • 产品简介、市场定义、产品目标是否清晰、明确？
        • 所有的市场需求、商业需求、内部需求是否已被识别、确定？外部客户需求包括主要客户的接口类型、容量、维护、性能、成本和目标价格等需求。市场需求要涉及国际化差异，明确相关地区的标准、语言、文化的差异。内部需求包括上一版本的特性与规范、公司的客户解决方案对本产品的需求等，客户需求和商业需求（如成本目标和价格）必须包含在产品需求中，客户的所有相关需求得到的定义
        • 关键特性是否满足主要客户提出的核心需求？
        • 竞争对手产品的主要特性公司能否提供？
        • 公司的主要卖点是否能与竞争对手产品竞争？
        • 是否考虑了新产品对老新产品市场可能的影响？
      • 5.3.1.2. 系统工程师
        • 需求规范性：产品需求是否清晰并依据产品需求模板进行整理？是否使用了最新的文档模板？文档名称是否正确？目录是否更新：
        • 需求完整性：所有和需求相关的问题是否被记录和进行风险评估？是否已经完成前一版本的可用性问题的分析，并作为可用性需求的输入？是否已经完成目标市场竞争对手产品的可用性分析，并作为可用性需求的输入？需求是否必要？需求中的所有需求是否确定优先级？环保需求是否已被识别、确定？包括设备功耗、电磁辐射、静音设计、环保材料选用、结构可拆卸设计、可回用设计等方面需求是己识别？是否定义无故障运行时间、故障恢复时间、安全控制、容火性要求、备份备用？所有的外部认证需求及其应用标准是否都己被识别、确定？
        • 需求一致性：需求描述是否清晰、明确，无二义？需求描述是否前后一致？需求描述是否不存在前后矛盾现象：
        • 需求可行性：每一项需求是否都准确地陈述所要实现的功能？需求是否可行？对关键任务用户交互场景的定义和概念设计是否可行？是否存在风险？系统的设计需求是否有抗反向工程的措施？信息安全需求是否已经考虑
      • 5.3.1.3. 客服代表
        • 所有可服务性需求是否已被识别、确定
      • 5.3.1.4. 测试代表
        • 所有可服务性需求是否已被识别、确定
      • 5.3.1.5. 制造代表
        • 所有可服务性需求（包括工艺约束条件）是否已被识别、确定
      • 5.3.1.6. 配置人员
        • 检查文档密级的设置是否符合公司信息安全规定？
        • 检查评审对象是否己上传至配置库中
    • 5.3.2. 总体技术方案评审要素
      • 5.3.2.1. 规范性
        • 是否使用了公司的最新模板？是否按模板要求撰写文档所有的相关内容？
        • 背景、定义、参考资料是否正确描述？
        • 系统方案的设计是否满足研制规范中的要求？
        • 对客户需求、可靠性需求、可测试性需求、可服务性需求、可安装性需求、可制造性需求是否进行了充分的分析论证，并转换为合理可行的技术需求？
        • 系统功能需求、性能需求、质量属性需求、外部接口需求、其它需求定义是否清晰合理
      • 5.3.2.2. 方案选择
        • 系统方案设计是否与各主要竞争对手采用的方案进行了分析（包括优势、劣势、差异性等）？是否提出多个实现方案？
        • 每个实现方案优缺点是否描述清晰，系统方案是否是不同方案的对比分析、综合权衡后优先的结果？
        • 建议选择的方案是否可行，共用硬件与软件的使用在系统总体方案中是否被考虑并得到更新？
        • 是否考虑版本升级时不同版本之间的兼容性？是否考虑对公司已有其它部件的兼容性？系统的兼容性和扩展性设计（包括设备的扩展和升级、与业界主流设备的接口、对国外标准的顺从等）？
        • 系统方案设计中是否考虑了可靠性、可维护性、可安装性、可制造性和、防静电、防潮设计、可焊性、机械应力、环保/绿色设计方面的要求
      • 5.3.2.3. 系统框架
        • 是否描述系统架构设想、设计概念、划分理由等？
        • 系统架构是否满足产品包需求中的功能、性能等目标要求？是否分析并参考业界的主流方案？系统方案的设计是否分析参考了业界的主流技术（包括关键器件的选用、采用的技术标准等）？是否描述了此架构的优点、缺点和风险？
      • 5.3.2.4. 可行性
        • 从进度、预算和技术角度上看该方案是否可行？
        • 是否仍存在可能不可行的设计部分？
        • 是否存在错误的，缺少的或不完整的逻辑
      • 5.3.2.5. 主要技术风险
        • 是否分类（结构、硬件、软件）列出系统开发过程中可能存在的技术风险？
        • 是否针对每一个技术风险提出切实可行的应对措施
  • 5.4. 研发文档评审
    • 5.4.1. 评审专家运作制度
      • 5.4.1.1. 技术评审专家的要求有
        • 由各个职能部门推举产生，一般每个部门至少推荐1～2个领域专家。由公司发放聘书，给予一定的奖励
        • 关心公司产品的设计质量，有热心推动设计质量的不断提高
        • 坚持原则，具有发展的眼光
        • 熟悉国内外、行业相关标准、知识产权等
        • 熟悉本行业的技术发展、竞争趋势
        • 精通所从事领域的专业知识，在所从事领域享有较高声誉
        • 从事专业技术类岗位5年以上
    • 5.4.2. 文档评审流程
      • 5.4.2.1. 提交评审
        • 必须填写完成静音中要求的项目并提交静音，跟踪静音的处理情况，及时就反馈的意见与评审成员沟通讨论，提醒各个评审成员及时处理表单等
      • 5.4.2.2. 同行评审
        • 作为评审成员认真阅读交付件，从自己的专业角度给出意见或者建议，承认会签意见
      • 5.4.2.3. 填写评审意见
        • 作为评审成员认真阅读交付件，从自己的专业角度出发给出意见或者建议，承认会签意见
      • 5.4.2.4. 填写评审结论
        • 作为评审成员的一员给出自己的意见，根据各个评审成员反馈的意见和交付件本身存在问题和风险状况，综合给出本次评审结论
    • 5.4.3. 交付物质量评定标准
      • 5.4.3.1. 把评审问题分成三个问题级别
      • 5.4.3.2. 评审问题级别
        • 严重问题
          • 影响产品关键功能/性能，必须改进，否则对产品下一阶段的设计开发工作带来严重偏差
        • 一般问题
          • 影响产品非关键功能/性能，必须改进，否则对产品下一阶段的设计开发工作带来偏差
        • 提示问题
          • 改进会带来好处，不改进对产品下一步的设计开发工作无影响
      • 5.4.3.3. 常见的严重问题
        • 文档类别交付件
          • 关键功能，约束条件等描述的缺失，如环境要求、环保要求、环保要求、生产要求、客服要求等
          • 设计规格、设计方案未能全部体现设计需求
          • 接口定义，关键器件的工作方式描述错误
        • 图纸类别交付件
          • 结构类：
            • 图面实测尺寸不符合所标注比例，图面尺寸标注不全，重点管控尺寸在技术要求中说明标注方式而图面尺寸标注中未具体标注中未具体标注出重点尺寸，螺柱规格不完全（如未说明是通孔或盲孔），表面这特殊处理位置只在技术要求中文字描述未在视图中清楚定义，组件（或称部件）图面中无具体工序说明及技术要求说明，图面内容或机构明细表项目不全，工艺选择及安排合理性问题（如止裂要求封焊，但不要求其它保护）
          • 硬件类：
            • 有明确规定的闲置Pin脚的处理，但最终没有处理，连线关系错误，封装定义错误，缺少关键器件，没有匹配电阻
      • 5.4.3.4. 常见的一般问题
        • 文档类别交付件
          • 关键部分的笔误，文档名称，页码，框图错误
        • 图纸类别交付件
          • 结构类：
            • 部分设计规格（如两对称面折弯高度不一致）导致加工工艺及管控困难，易加工错误，工艺选择合理性（如螺母紧固，采用焊接工艺使加工较困难），可扩大之其它加工成型工艺
          • 硬件类：
            • 逻辑芯片的空闲Pin没有处理，滤波、去藕电容、一些特殊器件在电路图上的旋转没有按照规范绘制
      • 5.4.3.5. 常见的提示问题
        • 文档类别交付件
          • 文档格式、封面、错字等，文字描述错误
          • 电路图上电容的容值描述不统一
          • 对文档里某些描述有疑问
    • 5.4.4. 评审度量
      • PQA需要记录评审过程数据，进行数据分析，改进评审质量
      • 5.4.4.1. 评审过程数据关注点大致如下
        • 参会人员与缺席人员名单与数量
        • 评审过程问题数据包括当次评审产生的缺陷数量、级别
        • 评审问题改进过程数据包括及时解决率、逾期解决率等，以评审过程确定的解决期限为基准
        • 评审结论数据：一次通过的次数、带着风险通过的次数、不通过的次数
        • 评审用时，包括整个评审过程用时，以及个人评审用时
      • 5.4.4.2. 专家的度量指标
        • 参与率
          • 一个统计周期内实际参加的次数/一个统计周期内累计应该参加的次数
        • 缺陷发现率
          • 一个统计周期内发现的有效缺陷总数/一个统计周期内累计应该参加的次数。有效缺陷指除被项目组拒绝之外的缺陷
        • 评审质量
          • 一个统计周期内各次评审发现的有效缺陷DI之和/一个统计周期内参与的评审总次数。DI=(严重问题)+（一般问题X1）+(提示问题X0.1)
        • 缺陷发现效率
          • 一个统计周期内发现的有效缺陷总数/一个统计周期内投入评审的总时长
      • 5.4.4.3. 专家的奖励措施包括
        • 每个受聘的技术专家发放公司特制的专用聘任书，公司承认其技术专家地位
        • 对于热心参加技术评审，并且在技术评审过程中发挥了关键作用，预防了可能的重大设计缺陷/质量事故的发生，由质量部定期（每季度）根据各个项目PQA上报的评审数据排出前3个表现突出的技术专家，发放一定的奖励金，作为质量贡献的鼓励
        • 定期（如每季度）公示表现突出的前3个评审专家及其奖励内容
        • 定期（如每季度）公示各个职能部门的评审质量状况
        • 按照季度统计表现突出的前3个评审专家由质量部通报给其部门作为关键事件记入当季的考核
        • 按照季度统计表现突出的前2个部门通报给研发部作为关键事件记入当季的部门考核
  • 5.5. 研发文档评审常见的问题
    • 5.5.1. 研发文档评审常见的问题
      • 5.5.1.1. 文档提交不完整
        • PQA定期检查，通过PLM系统强制提交
      • 5.5.1.2. 文档提交不及时
        • 通过PLM系统关联任务和交付，里程碑阶段强制检查
      • 5.5.1.3. 文档质量不高
        • 模板化、集成化、傻瓜化；文档分类管理，通过PLM系统按文档类型自动关联对应审批流程
      • 5.5.1.4. 文档变更受控程度低
        • 通过PLM系统管理文档版本，文档变更流程
      • 5.5.1.5. 文档安全性不高
        • IT支持多维度的权限管理
      • 5.5.1.6. 为什么要写文档
        • 很多研发人员不喜欢写文档，对于需要的实现方案通常是负责人邮件或电话跟一些相关人员讨论一下就确定了，很多时候连讨论的会议纪要都没有。国外的企业研发则非常重视文档，他们认为在脑袋里或心里想的东西是不清晰的、不全面的，以为很正确的方案实际上可能存在致命缺陷，必须把实现方案形成文档才能有效地避免这种问题，而且在写文档的过程中能更加有效地、更进一步整理思路，很多问题能在写文档的过程中发现。
        • 建议所有的过程分析都要形成文档。文档编写过程中建议多使用图表，尽量少用文字
    • 5.5.2. 为什么要写文档
      • 很多研发人员不喜欢写文档，对于需要的实现方案通常是负责人邮件或电话跟一些相关人员讨论一下就确定了，很多时候连讨论的会议纪要都没有。国外的企业研发则非常重视文档，他们认为在脑袋里或心里想的东西是不清晰的、不全面的，以为很正确的方案实际上可能存在致命缺陷，必须把实现方案形成文档才能有效地避免这种问题，而且在写文档的过程中能更加有效地、更进一步整理思路，很多问题能在写文档的过程中发现。
      • 5.5.2.1. 建议所有的过程分析都要形成文档。文档编写过程中建议多使用图表，尽量少用文字
    • 5.5.3. 文档写作基本要求有哪些
      • 5.5.3.1. 应使用标准模板写作
      • 5.5.3.2. 文档封页、页眉、页脚、修订记录、附录、参考文献应完善
      • 5.5.3.3. 关键词、摘要、缩略语应完整
      • 5.5.3.4. 目录要及时更新
      • 5.5.3.5. 通篇文档标题、文字格式、间距应协调美观
      • 5.5.3.6. 所有文档模板中的章节只可增加，不可删除
      • 5.5.3.7. 编写建议是用来指导文档写作的，在利用完后要及时删除
      • 5.5.3.8. 图号置于图形之下，表号置于表格之上
      • 5.5.3.9. 应追求图文并茂的效果
      • 5.5.3.10. 句子和段落要短
      • 5.5.3.11. 使用语言应严谨，不要使用白话
      • 5.5.3.12. 采用主动语气
      • 5.5.3.13. 不要出现“我们”“你们”“他们”这样的称谓，或“这个”“那个”这样的词，应使用“本××”“该××”“其××”
      • 5.5.3.14. 表述清晰，避免引起歧义
      • 5.5.3.15. 通篇文档细节上要保持一致
      • 5.5.3.16. 必须避免模糊的、主观的术语，减少不确定性，例如也许、大概、可能、界面友好、容易、简单、美观、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的
    • 5.5.4. 文档太多怎么办
      • 如果过程规范是适合于本企业的，那么所要求的文档工作量也应该是比较适宜的。员工们抱怨“文档太多了”，可能是因为以前文档写得太少了，一下子不习惯正常的文档工作量
      • 5.5.4.1. 应该想办法降低写文档的难度，提高写文档的效率。一般方法有:
        • 花时间与资深工程师讨论和制定出结构良好的文档模板，给出充足的提示和示例。让使用者“依葫芦画瓢”，总比靠自己琢磨怎样写要方便得多
        • 提高开发人员的写作能力，练“内功”。学习好的写作方法，不断地练笔，熟能生巧
• 6. 结构设计
  • 6.1. 结构设计常见的问题
    • 6.1.1. 标准件库和通用件库不完善
    • 6.1.2. 零部件标准化程度低、模块重用低，标准件通用件没有统一的管理，存放在工程师的个人电脑里，正确性、有效性不能保证
    • 6.1.3. 没有专职从事标准化工作的人员，导致零部件的借用混乱，只有老工程师知道哪些可以通用，新员工要很费劲才能找到能通用的零件
    • 6.1.4. 产品设计的3D和2D图纸没有关联
    • 6.1.5. 研发内部数据共享采用复制的方式，造成一图多物的情况，图纸设计更改时容易改漏
    • 6.1.6. 上下游的数据缺乏关联性，不方便查找，如外观设计的图纸没有和相关零部件关联
    • 6.1.7. 数据查询不方便，难以通过属性的查询和跨部门数据的查询
    • 6.1.8. 难以进行结构和硬件协同设计
  • 6.2. 结构设计流程
    • 
    • 6.2.1. 结构设计流程
      • 
      • 6.2.1.1. 概念
        • 定义产品包需求
          • 结构技术需求
          • 外观设计需求
        • TR1评审
      • 6.2.1.2. 计划
        • 需求分解与分配
          • 结构总体设计说明书/总体设计方案
        • 系统设计与设计规格定义
          • 结构产品设计规格书
        • TR2评审
        • 结构概要设计、评审
          • 结构概要设计说明书
          • 结构概要设计评审检查表
        • TR3评审
      • 6.2.1.3. 开发
        • 外观设计、评审
          • 效果图
          • 丝印图
          • 实体三维模型
        • 结构详细设计、评审
          • 结构详细设计说明书
          • 结构详细设计评审检查表
          • 3D图
          • 2D图
        • 手板制作、验证、评审
          • 手板试装报告/手板测试报告
          • 结构评审报告
        • 零件加工、检测、改进、认证
        • 包装需求分析
          • 包装需求说明
        • 包装设计、评审
          • 包装图
          • 包装设计检查单
        • 包装打样、验证
          • 纸箱样品报告
        • TR3评审
          • 原型样机测试
        • TR4A评审
          • 功能样机测试
        • TR5评审
      • 6.2.1.4. 验证
        • 生产试制产品
          • 产品结构件试产报告
        • TR6评审
      • 6.2.1.5. 发布
        • 项目结束经验总结
          • 产品总结报告
        • GA
      • 6.2.1.6. 生命周期
        • 产品优化
        • 产品改型
        • 生产过程中技术支持
        • 工程更改
          • 工程更改通知单
      • 注意事项
        • 若开发周期短，包装和结构详细设计可以并行，一般在产品待测试的样机做出来后再进行包装设计
        • 零件加工、检测、改进、认证环节进行模具开发
    • 6.2.2. 部分结构设计流程
      • 6.2.2.1. 定义产品需求
        • 活动描述
          • 搜索结合可选概念和技术可选方案，选择并评估结构可选概念，配合系统工程师做产品需求-结构部分
      • 6.2.2.2. 结构详细设计、评审
        • 活动描述
          • 根据产品规格确定结构整体尺寸，根据《产品续约概要设计》确定内部结构，设计3D图，组织召开评审会，会议结论进行记录和评审人员会签输出，出2D图、BOM
        • 模板/标准/工具
          • 结构详细设计说明书、3D、2D、BOM、技术评审表
      • 6.2.2.3. 手板制作、验证、评审
        • 活动描述
          • 根据评审的结果，对设计改进后的结构打样一套，加工回来样品后，对产品进行组装，根据打样验证结果对结构进行修改，并出相关图纸，组织召开评审会，并对会议结论进行记录和评审人员会签输出。评审包括图纸、《试装报告》等，根据评审记录出2D图
        • 模板/标准/工具
          • 打样Checklist、试装Checklist、试装报告、技术评审表
      • 6.2.2.4. 配合外部认证
        • 活动描述
          • 配合认证试验
      • 6.2.2.5. 配合小批量试制
        • 活动描述
          • 小批量生产跟进
      • 6.2.2.6. 配合量产
        • 活动描述
          • 生产跟进、解决突发问题
        • 模板/标准/工具
          • 现场不良反馈通知单
    • 6.2.3. 包装设计流程
      • 6.2.3.1. 包装需求分析
        • 活动描述
          • 根据结构设计产品的尺寸确定包装的基本尺寸，根据包装的形式和方式考虑产品的可靠性确定包装材料，根据材料特性进行包材结构设计
        • 模板/标准/工具
          • 包装需求说明
      • 6.2.3.2. 包装设计、评审
        • 活动描述
          • 出2D/3D图、BOM、提前三个工作日向相关人员发出设计评审会议通知，组织召开评审会，并对会议结论进行记录和评审人员会签
        • 模板/标准/工具
          • 包装评审报告
      • 6.2.3.3. 包装打样、验证
        • 活动描述
          • 根据评审的结果对设计改进后的包装材料打样一套，下物料申购单，加工回来样品后，对产品进行组装，对包装材料进行可靠性试验验证。根据产品的特性和实际需要可以选择性的进行试验，例如振动实验（运输实验）、跌落实验
          • 摇头晃脑三个工作日向相关人员发放评审通知，同时发放评审资料和评审检查表，要求各评审成员认真填写评审检查表。评审资料包括图纸、《评审报告》《试装报告》《振动实验报告》等
        • 模板/标准/工具
          • 打样Checklist物料申购单
          • 包装试装报告
          • 试装Checklist
          • 包装实验报告
          • 评审检查表
      • 6.2.3.4. 生产试制产品
        • 活动描述
          • 配合小批量试制，小批量生产跟进
      • 6.2.3.5. 量产
        • 活动描述
          • 配合量产，生产跟进，解决安全性问题
        • 模板/标准/工具
          • 现场不良反馈通知单
    • 6.2.4. 图纸评审流程
      • 6.2.4.1. 设计
        • 对产品的先进性、可靠性、安全性、经济性以及图样和文件的正确性、完整性、统一性等负全面责任，负责图样及设计文件的设计（编制）和校对
      • 6.2.4.2. 校对
        • 负责图样及设计文件的校对
      • 6.2.4.3. 工艺
        • 根据公司的设备、技术状况及今后发展方向，对设计图样进行工艺性分析，对工艺文件的正确性、完整性和统一性负责
      • 6.2.4.4. 标准化
        • 对标准化文件（如标准化审查报告、产品标准）进行审核。对图样及设计文件、工艺文件是否符合有关国家标准、行业标准及企业标准规定进行审查
      • 6.2.4.5. 审核
        • 对设计方案、产品性能、基本结构形式、主要数据、技术条件和关键配合尺寸等的正确性负责，负责规定图样及文件的编制或审核
      • 6.2.4.6. 批准
        • 对产品主要性能、主要零部件及文件的正确性负责，对设计文件是否满足技术要求、设计原则的正确和产品技术经济指标的合理性负责，负责零部件、产品总图和规定文件的最终审批
      • 流程可以拓展以下活动
        • 自评：图纸提交前根据图纸评审要素进行自评
        • 质量：对最终产品质量直接有关的图纸、技术、工艺文件进行会签。对其正确性及是否保证最终产品的质量指标，对最终产品主要技术指标和技术性能的检验是否有检验手段，检验手段是否可靠、科学负责
        • 发布接收：图纸评审通过后发布到哪些相关部门，相关部门接收后流程结束
    • 6.2.5. 打样流程
      • 6.2.5.1. 打样需求
        • 向采购提出数量、时间要求、发起人提供签字后的图纸
      • 6.2.5.2. 采购确认
        • 采购只接收专人发出的设计文档或相应签字后的图纸文件，才能启动打样
      • 6.2.5.3. 外发打样
        • 3D图纸必须经过结构部负责人审核后才能发放，原则上只能发放零件图。电子文档包括2D、3D、ID造型设计文件和文字性文件。在与供应商签订模具或产品合同以后，复制开模资料，刻录光盘后下发给采购部
      • 6.2.5.4. 样品确认、封样
        • 五金件必须试装，必须做盐雾测试、机械功能测试，对照图纸确认是否达到技术要求
        • 塑胶件必须试装，做机械功能测试，对照图纸，大政方针是否达到技术要求
        • 外包装箱封样必须试装，必须做丝印测试、包装运输测试
        • 封样的前提是整机和散件都己达到标准，在封样前必须做完相关测试（如环境/寿命测试、包装运输测试、机械功能测试、安全测试、防暴测试、防尘防水测试等）
  • 6.3. 结构设计专题
    • 6.3.1. 结构件分类属性
      • 
    • 6.3.2. ODM/OEM行业结构设计流程
      • 一般是客户给结构设计图，研发部门根据结构设计资料进行工艺评审、生产可行性评估，出具评估报告，客户进行评估报告确认，确认后研发部门进入模具设计活动，设计出模具3D、2D后进行设计评审，内部评审通过后一般再次需要客户确认。客户确认模具图纸资料后开始开模、修模和打样，样品送客户确认，同时进行样品验证，客户确认后进行量产
      • 6.3.2.1. 接收客户资料
        • 活动描述
          • 销售部门得到客户信息，确定需要进行结构设计的，将需求转给杜绝部门经理，指派项目经理
        • 模板/标准/工具
          • 客户资料
      • 6.3.2.2. 可行性分析
        • 活动描述
          • 检阅客户给的资料，与客户沟通，小组内部协调同ID人员做一些项目的可行性分析。可行性分析主要是工艺、效果图、ID设计
        • 模板/标准/工具
          • 可行性分析报告
          • 3D
          • 图片
          • 要求
          • 规格
      • 6.3.2.3. 客户第1次确认
        • 活动描述
          • 将文件直接让客户确认，或召开评审会议，邀请客户参加（一般参加人员有市场部人员、项目经理、结构设计人员、客户）
      • 6.3.2.4. 立项并开发
        • 活动描述
          • 客户会给一个比较详细的时间表，开始项目的启动会议，明确任务和分工。结构设计工程师进行3D设计
        • 模板/标准/工具
          • 结构设计图档
      • 6.3.2.5. 设计评审
        • 活动描述
          • 项目经理对完成的3D图档审核检查一遍，并召集相关的资源人士进行内部评审，评审内容包括功能、可靠性、制造性分析等
      • 6.3.2.6. 客户第2次确认
        • 活动描述
          • 召开正式的评审会议，参加人员包括结构设计人员，制造部门、硬件设计人员、市场部门和客户。评审内容包括功能、可靠性、可量产性等方面需求
        • 模板/标准/工具
          • 3D
          • 2D文档
          • 开模信息
      • 6.3.2.7. 开模、打样
        • 活动描述
          • 组织开模（一般先开软模）并试模，试模验证时发现的任何与结构有关的问题，由项目经理反馈到结构设计部门，结构设计部门再进行分析修改，同时会更新3D、2D文件，再重新组织修模、打样、样品验证
        • 模板/标准/工具
          • 模具
          • 样品
          • 样品验证报告
      • 6.3.2.8. 客户第3次样品确认
        • 活动描述
          • 客户再次对样品进行确认
    • 6.3.3. 产品结构工艺性审核
      • 新设计和改进设计的产品在设计过程中应进行结构工艺性审查，外来产品图样在首次生产前也建议进行结构工艺性审查。首次投产的产品在满足使用功能的同时，也应符合工艺性要求，以便能用比较经济的方法将其制造出来。
      • 6.3.3.1. 产品结构工艺性
        • 一般主要考虑产品的种类及复杂程度、产品的产量、现有的生产条件
        • 生产工艺性
          • 即指其制造的难易程度与经济性
        • 使用工艺性
          • 即指其在使用过程中维护保养和修理的难易程度与经济性
      • 6.3.3.2. 产品结构工艺性审核
        • 初步设计阶段的审查
          • 从制造观点审查结构方案的合理性，结构的继承性，结构的标准化与系统化程度，产品各组成部分是否便于装配、调整和维修，主要材料选用是否合理，工艺关键件加工的可能性
        • 技术设计阶段的审查
          • 产品各组成部件进行装配的可行性审核，包括装配时避免切削加工或减少切削加工的可行性，高精度复杂零件加工的可行性，主要参数的可检查性和主要装配精度的合理性，特殊零件加工的可行性
        • 正式出图设计阶段的审查
          • 各部件是否具有装配基准，是否便于装拆，各大部件拆成平等装配的小部件的可行性，审查零件的铸造、锻造、冲压、焊接、热处理、切削加工和装配等的工艺性
  • 6.4. 模具管理
    • 6.4.1. 模具的重要性
      • 6.4.1.1. 模具制造能力是制造企业的核心技术能力，将直接影响生产的响应速度和精确程度。需要较强的技术能力，要依靠持续的资源投入。对模具供应商的管理应逐步做到规范化、精确化，避免模具
      • 6.4.1.2. 对模具供应商的管理应逐步做到规范化、精确化，避免模具开发（包括委外和自制）的周期、精度和可靠性成为阻碍生产的瓶颈。
    • 6.4.2. 模具管理面临的挑战
      • 6.4.2.1. 流程
        • 缺少从产品研发、模具开发、制造、维修、外发设计、制造端到端的模具管理规范化、可按的业务流程支持（正确的人、正确的时间、按正确的方法、做正确的事）、改善设计流程成为标准化设计流程，以提升研发效率
      • 6.4.2.2. 效率
        • 模具进度不易控制，模具公司定期反馈进度及计划（时间间隔导致设计人员不能及时获取当前模具进度问题，设计人员不易看懂进度），外发时更加不易准确获取模具进度
        • 较少采用并行模具开发的方法，便利模具开发周期长、对具体工作人员要求高
        • 沟通时间太多，由于2D图面有时标示不清，设计工程师需要经常应付现场人员的沟通需要
        • 2D图面花费太多时间，现场人员要求图面尺寸需求详细标注，造成设计工程师花费大量时间在2D的图纸上
      • 6.4.2.3. 质量
        • 模具未验证，状态未有效维护，造成项目量产产品质量事故
      • 6.4.2.4. 成本
        • 供应商新开模具利用率低，资源浪费严重。模具共用率低
      • 6.4.2.5. 数据管理
        • 缺乏对模图及改模记录的有效管理，过去的模图无法找到（外发），实物与模图一致（经历改模后），导致复制模的制造出现问题
        • 模具与产品变更不关联，产品变更后，没有记录相应的模具更改信息
      • 6.4.2.6. 人员和经验积累
        • 人员流动频繁，花费太多培训的时间，人员流动频繁对公司是一项很大的负担。设计经验难以传承，如何将设计经验传承，并建立Know-How资料库
      • 6.4.2.7. 统计分析
        • 业务执行情况数据统计困难，如外发模具制造执行情况、模具数量（状态）等业务执行度指标主要由人工定时统计，费时费力不精确
    • 6.4.3. 模具开发流程
      • 6.4.3.1. 前期开发
        • 概念设计
          • 市场需求
      • 6.4.3.2. 产品设计
        • 产品3D造型设计
          • 客户2D产品图
        • 产品CAE
        • 产品2D工程图
      • 6.4.3.3. 模具设计
        • 模具3D设计
          • 产品3D实体
        • 模具2D工程图
        • 模具CAE
      • 6.4.3.4. 零件制造
        • 电极CAD、CAM
          • 模具3D实体
        • 部件CAM
        • 工艺文件准备
      • 6.4.3.5. 装配试模
    • 6.4.4. 如何缩短模具交付周期
      • 6.4.4.1. 缩短开模时间
        • 提升作业技能，构建标准件库，模块化设计，同步工程，作业引导系统，标准化设计方法，标准化制造方法
      • 6.4.4.2. 模具开发流程再造
        • 模具状况看板，及时了解模具制作进度，流水线生产，数据加工
  • 6.5. 结构设计输出文档模板
    • 6.5.1. 结构总体设计说明书/总体设计方案
      • 6.5.1.1. 概述
        • 项目介绍，参考资料，术语，特殊说明
      • 6.5.1.2. 结构解决方案
        • 方案示意图：
          • 方案结构示意图、方案简图等，有多个方案时需画出多个方案的示意图
        • 方案说明：
          • 说明方案与需求的针对性，列出要在方案设计活动中重点解决的问题，有多个方案时需列出不同方案的说明
      • 6.5.1.3. 方案对比及方案分析
        • 方案对比及分析：
          • 包括方案优缺点、方案周期、成本、风险等
        • 方案分析结果及说明：
          • 根据上面的分析得出对比结果，并对方案结果进行说明
      • 6.5.1.4. 方案建议
        • 根据前面的分析和对比，给出方案建议
      • 6.5.1.5. 其它
        • 方案存在的风险及措施：方案需求符合性分析
    • 6.5.2. 结构概要设计说明书模板
      • 6.5.2.1. 概述
        • 项目简介、设计背景、设计概要、产品功能、主要的国内外同类产品、国内外同类产品的结构设计分析、设计定位与思路、参考资料、术语、特殊说明
      • 6.5.2.2. 结构整体方案说明
        • 结构整体方案说明：
          • 方案示意图，结构的基本设计思路与环保要求，包括可拆卸性、可回用性及节能要求。说明设计与需求的针对性，列出要在详细设计活动中重点解决的问题。方案符合性分析
        • 结构设计标准及外形尺寸：
          • 定义结构设计所遵循的设计标准，描述产品外形的最大外形尺寸及其相关配套尺寸
        • 系统集成效果说明：
          • 产品集成、产品与周边及配套设备一起放置时的协调一致性及整体效果进行说明，ID风格是否与公司产品风格一致做寿 简要说明
        • 装配图：
          • 部件及结构关系，要求零部件表达出功能特征，表达出整机布局、空间利用和外观特征
        • 技术难点要点、方案存在的风险及预防措施
      • 6.5.2.3. 结构概要设计
        • 结构可靠性设计，工程可安装性设计，EMC设计，静电放电防护设计，热设计，防尘要求，防水要求，防异物要求，可维护性设计，结构相关的状态指示，定期更换（或清洁）的部分，定期维护的模块部分，结构安全设计，噪声控制设计，三防（防霉、防潮、防盐雾）设计，各结构件的材料应用，各结构件材料的表面防护措施，包装储运设计
      • 6.5.2.4. 包装设计方案
        • 方案说明：阐述包装方案结构组成，贴纸、包装盒、产品上包含的贴纸，BOM上包含的包装内容
        • 方案需求符合性分析：说明设计与需求的针对性，列出要在详细设计活动中重点解决的问题
      • 6.5.2.5. 主要加工工艺性分析
        • 分析结构件、包装物的可加工性、可装配性
      • 6.5.2.6. 整机可装配性设计及直线工艺要求
        • 整机装配过程：重要的装配点，给出这些重要装配点的指标要求
        • 直线：说明出线方式、工程布线方面的要求，提出直线路径和空间要求
      • 6.5.2.7. 共用模组和共用零件、新配件说明
        • 分析共用模组和共用零件，新配件选用的必要性及合理性
      • 6.5.2.8. 可采购性及成本分析
        • 分析可采购性（特别是外观配件），分析结构成本
      • 6.5.2.9. 技术指标及性能测试清单
        • 样机开发完成后需进行的相关实验清单
    • 6.5.3. 结构详细设计说明书模板
      • 6.5.3.1. 概述
        • 项目简介、参考资料、术语、特殊说明
      • 6.5.3.2. 整机装配设计
        • 装配图和零件图：结构设计功能框图，完全结构关系，详细的整机特征，零件工程图，详细商品化信息
        • 基本尺寸架构设计：基本尺寸、整体关键装配尺寸、外观尺寸要求、尺寸实现方式
      • 6.5.3.3. 内部结构实现
        • 输出输入功能模块设计：产品整体输入输出，并考虑相关配合设计
        • 其它功能模块设计：如电源设计、存储系统、控制系统等逐一结构定义
        • 系统热设计、防尘设计、可靠性设计、可生产性设计、其它设计考虑
      • 6.5.3.4. 包装装配图和零件图
        • 装配图：单机包装、栈板包装、备件包装
        • 设计说明：说明设计与需求的针对性，设计可靠性与校核
      • 6.5.3.5. 组装与拆解
        • 工艺装备、组装动作分解图、拆解动作分解图
      • 6.5.3.6. 搬运、安装、使用和维护动作模拟分析
        • 搬运、安装、使用、维护
      • 6.5.3.7. 零件可制造性分析
        • 工艺分析、工序分析、成本分析
      • 6.5.3.8. 存在的风险及措施
      • 6.5.3.9. 需求符合性分析
      • 6.5.3.10. 模组说明
        • 主要确认借用件、新配件选用，定义结构、功能特征等，并列出新器件清单
      • 6.5.3.11. 材料表
        • 出结构件BOM清单作为附件
      • 6.5.3.12. 模具需求
  • 6.6. 结构评审要素
    • 6.6.1. 结构技术方案评审要素
      • 6.6.1.1. 满足用户需求的程度和使用方便性，是否符合人机工程和使用习惯，机器清洁的方便性
      • 6.6.1.2. 产品标准（国标、行标）的符合性
      • 6.6.1.3. 结构概况相互关系和基本性能
      • 6.6.1.4. 产品总体方案设计的正确性、经济性和国内外同类产品水平分析比较
      • 6.6.1.5. 总体布局的合理性、工艺性（加工容易、装配简单、符合大批量生产和加工要求）、可靠性、耐用性、可维修性（维护简单、方便/部件模块化，无螺钉化）及安全与环境保护
      • 6.6.1.6. 基本参数及主要技术性能指标的正确性
      • 6.6.1.7. 新技术、新结构、新材料、新原理采用的必要性与可能性
      • 6.6.1.8. 标准化、系列化、通用化程度、实现标准化综合要求的可能性
      • 6.6.1.9. 是否符合政府有关法令、法规、国际标准与公共惯例
      • 6.6.1.10. 防暴、防尘、防水、产品的噪音问题、产品的散热问题、产品的EMC、ESD问题
      • 6.6.1.11. 课题范围合理性、设计功能充分有效性、可靠性设计充分有效性、可生产性、成本可行性、测试方案充分有效性、计划合理性
    • 6.6.2. 结构概要设计评审要素
      • 6.6.2.1. 基本参数及技术性能指标的正确性
      • 6.6.2.2. 设计的工艺性、装配的可行性、主要装配数度的合理性、主要参数的可检查性、可试验性
      • 6.6.2.3. 新技术、新结构、新材料、新原理的实施情况
      • 6.6.2.4. 主要零部件结构的继承性、经济性、工艺性、合理性
      • 6.6.2.5. 设计计算的正确性
      • 6.6.2.6. 特殊外购件、原材料采购供应的可能性，特殊零件外协加工的可行性
      • 6.6.2.7. 标准化程度的落实情况
      • 6.6.2.8. 故障分析及措施
      • 6.6.2.9. 产品成本构成情况
    • 6.6.3. 结构详细设计评审要素
      • 6.6.3.1. 是否具备产品定型的条件
      • 6.6.3.2. 设计改进的正确与完善情况，以及对产品质量的影响
      • 6.6.3.3. 改进部分的工艺性
      • 6.6.3.4. 产品包装、贮存、搬运要求的正确性、合理性与完善性
      • 6.6.3.5. 操作的方便性、宜人性，操作、指标标牌应采用形象化符号，标志合理、齐全是否符合标准规定
      • 6.6.3.6. 产品标准化程度
      • 6.6.3.7. 故障分析与措施
      • 6.6.3.8. 使用说明书的正确与完善
    • 6.6.4. 结构图纸评审要素
      • 6.6.4.1. 总成图
        • 总成图、部件图和新增零件的工程图是否充分足够
        • 总成图是否标明产品规格、型号、主要技术参数、适用范围、外形尺寸和安装尺寸
        • 总成图是否清楚表达了基本组成部件和明细
        • 总成图、部件图是否标明了主要配合尺寸和配合代号
        • 总成图、部件图的配合等级是否协调且符合使用状态要求
      • 6.6.4.2. 零件图
        • 零件图的视图表达是否清晰完整，反映了零部件的形状
        • 零件的结构设计的可靠性是否充分考虑，适用时得到了验证
        • 零件的结构设计是否能方便经济地加工、制造
        • 零件图是否具有确定零件形状和结构的全部尺寸和公差
        • 零件图有配合要求的尺寸、尺寸公差、形状公差、位置公差、表面粗糙度的要求是否协调
        • 零件技术要求是否充分、清晰
        • 系统图是否清楚表达了产品的基本组成、主要特征、功能关系、信息与过程的流向
        • 原理图是否表达了输入与输出之间的关系，是否清楚表明产品运作及工作程序功能
        • 接线图上的元器件型号、代号、规格、数量是否符合标准规定
    • 6.6.5. 结构手版评审要素
      • 6.6.5.1. 结构评审ID外观曲面
        • 示例：ID确认修改无误，可以实现，细节结构建模调整达成一致意见，各部分工艺己交代清楚
      • 6.6.5.2. ID评审结构外观建模
        • 示例：大面外观与原大面一致，或修改达成一致意见，细节部分无疏漏，分型面确认无误，按键曲面确认，盲点确认
      • 6.6.5.3. 结构完成，投模评审
        • 示例：挂绳确认，模具纹理，符号确认
    • 6.6.6. 产品结构外观设计审核要素
      • 6.6.6.1. 外观形态
        • 整体尺寸如何，整机置于桌面的稳定性，是否符合手持机要求，把握的舒适性，操作的舒适性（人机工程）
        • 评估外壳空间是否能瘏下整个电路结构，各外部接口位置的合理性（包括各接着手稿是否干涉），结构空间布局的合理性，是否存在尖角，是否存在夹手现象，是否有提示标识
        • 结构强度是否合理
        • 结构上是否留有升级和扩展空间
        • 整机的稳定性（包括机器本身的自重和机器与桌面的摩擦力）
      • 6.6.6.2. 整体加工
        • 机器由装配结构如何（由几件组成，如何组装），使用方式如何，是否便于装配、使用和维护
        • 各零件加工工艺性（如是否便于分模、注塑、机加工等）
        • 材料选择是否通用（包括成本），满足需求（包括环保方面、阻燃等），表面处理是否会存在困难
        • 配合面的脱模角
      • 6.6.6.3. 各模块使用方便性和功能方面
        • 示例：某显示（LCD及镜片）模块是否充分考虑镜片易划花的问题，是否充分考虑显示角度和视线死角，LCD的视角为正负40度，最佳视角为20度，考虑镜片上丝印的难度
        • 外部接口：结构强度、拔插方便性（位置）、防尘防水性、防尘防水性能、接口的防松脱性能等是否达到要求
        • 机壳及产品标识：丝印蚀刻产品名称型号、公司Logo、各操作标识、标识、铭牌、序列号（注意防呆）操作指示，底壳是否有脚垫保护底壳以免划花
      • 6.6.6.4. 其它
        • 经济和实用，符合标准化、通用化和系列化要求
    • 6.6.7. 结构样品评审要素
      • 6.6.7.1. 结构样品
        • 结构和电缆需要解决的遗留问题是否已经解决？
        • 热测试、噪声测试中的结构问题是否已经解决？
        • 环境测试、安规测试、EMC测试中的结构和电缆问题是否已经解决？
        • 产品结构包装是否符合设计要求
    • 6.6.8. 结构转产评审要素
      • 6.6.8.1. 结构转产
        • 试产过程中的结构件问题是否全部解决？
        • 结构相关的所有文档和图纸是否齐全？在小批量过程中发现的问题是否全部解决？
        • 结构是否符合环境测试、安规测试、EMC测试、散热的要求？
        • 产品是否满足工程安装和服务方面的要求？（恶劣环境、高空作业等情况下尤其应该关注）
• 7. 硬件设计
  • 7.1. 硬件设计领域常见的问题
    • 7.1.1. 没有统一的器件库，研发人员不方便查询和选型
    • 7.1.2. 原理图和PCB板不一致，没有同步更改
    • 7.1.3. 硬件设计和结构设计（空间尺寸的信息）无法协同研发，缺乏信息共享
    • 7.1.4. 版本容易出错
    • 7.1.5. 原理图、PCB图的签审效率和准确性低
  • 7.2. 硬件设计流程
    • 7.2.1. 硬件开发流程
      • 
      • 7.2.1.1. 总体设计方案和产品设计规格书一般同步完成，设计方案确定后一般进行关键物料提前采购和备料
      • 7.2.1.2. 总体设计方案后一般进行单板总体方案设计
      • 7.2.1.3. 硬件概要设计很多公司会省略
      • 7.2.1.4. 单板制作、调试活动同时进行物料的采购
      • 7.2.1.5. 硬件集成及测试、评审活动包括软硬件联调
    • 7.2.2. PCB设计流程
      • 7.2.2.1. PCB设计、评审
        • 设计文件提供：
          • 提供原理图文件和网络表文件及规则驱动，结构要素图文件，EDA工程师的库路径
        • 预布局建议：
          • 基本的布局模块示意，确定端子、商品等结构布局，根据建议确定器件和模块的基本位置和电源、信号流向，考虑工艺生产角度
        • 布局：
          • 精确确定结构布局，以结构要素图为标准
        • 布局评审：
          • 确定结构、可制造性设计、工艺、生产、可靠性、EMI、EMC、电源布局、信号流向等电气特性，确定布局
        • 布线、布线评审：
          • 确定结构、可制造性设计、工艺、生产、可靠性、EMI、EMC、电源布线、地设计、信号流向等电气特性，确定布线
        • 自检：
          • 仔细检查PCB的细节，按照PCB投板评审要素逐一详细检查
        • 复检：
          • 按照PCB投板评审要素逐一核对，并对相应细节与项目CAD人员沟通修改
      • 7.2.2.2. 器件封装设计流程
        • 器件建库申请
          • 制作封装设计BOM表，并下达
        • 建库申请BOM表
          • 列出本项目所需要用到的封装器件和实验阶段需要用到的新器件清单
        • 资料供给
          • 新建器件封装必须提供完整的资料（包括器件的外形、尺寸和管脚功能），器件管脚数少于2的简单规则器件可以不提供资料或自行寻找资料
        • 建库
          • PCB封装建库工程师必须具有专业的建库经验和了解器件工艺，根据申请人所提供的资料及结合设计规范严格设计器件封装库，设计的封装应具有良好的要加工性、正确性及美观性。封装一旦知识库后应严禁发动，尽量不要更改
            • 建库规范
            • PCB封装库命名
            • 规则
        • 内部评审
          • 为确保器件封装的可加工性、正确性及美观性，设计完的每一个封装必须严格进行检查。封装命名唯一，不能把新建的封装覆盖原来封装。检查封装在库内的唯一性，型号对应封装。检查封装设计的视图（器件封装必须按器件的顶视图来建库，部分特殊器件需要在PCB板上形容安装在底面，一定要有文件说明），应严格按《器件封装库设计检查Checklist》及配合工艺检查器件封装
            • 器件封装库设计
            • 检查Checklist
        • 入库
          • 经严格检查的封装库由专人入库，PCB封装建库工程师共享一个文件，入库专员每天需把库文件同步到服务器
          • 一旦入库的封装库应严格控制修改，如有修改的库必须有修改说明文件
  • 7.3. 硬件设计专题
    • 7.3.1. 硬件设计常见风险
      • 7.3.1.1. 设计
        • 封装错误，新技术应用，新器件应用，器件优先等级改变，EMC、热、环境、安规、国际化设计，可制造性设计，新电缆应用，公用基础模块（CBB）成熟度，结构要素图设计错误，新型结构应用、接口、性能、软件限制
      • 7.3.1.2. PCB
        • PCB设计可行性，PCBA加工实现，PCB设计时间不可控
      • 7.3.1.3. 单元、集成和系统测试
        • 测试项的完整性，开发调试环境，测试时间不可控
      • 7.3.1.4. 采购
        • PCB板采购，器件采购，结构件采购，电缆采购
      • 7.3.1.5. 管理
        • 人员变动或者不满足要求
    • 7.3.2. 单板硬件程序命名规范
      • 按单板型号划分，如半成品名称+工位号+待烧录芯片类型+程序日期+后缀名。其中，工位号为待烧录芯片在单板上的工位号，芯片类型如单片机MCU、Flash简称FL，程序日期为硬件程序的编制日期，后缀名为硬件程序的后缀名。按平台划分，如平台+型号+程序日期+后缀名。型号指整机型号，也可以是芯片型号。日期为程序生成的日期，后缀名为硬件程序的后缀名。如果多个BOM共用一个硬件程序，以第一个单板命名。有替代物料时，分别用两个不同的程序，加上芯片名称备注。
    • 7.3.3. PCB布局及布线要求
      • 7.3.3.1. 布局要求
        • 遵照“先大后小，先难后易”的布置原则，即重要的单元电路、核心元器件应当优先布局
        • 布局中应参考原理框图，根据单板的主信号流向规律安排主要元器件
        • 布局应尽量满足总的连线尽可能短，关键信号线最短，高电压、大电流信号与小电流，低电压的弱信号完全分开，模拟信号与数字信号分开，调频信号与低频信号分开，调频元器件的间隔要充分，交叉线最少，过孔最少，地线层和电源层没有连线，调频数字信号的间隔要大，尽量减少电源地层与信号层层距布线
        • 相同结构电路部分，尽可能采用“对称式”标准布局
        • 按照均匀分析、重心平衡、版面美观的标准化布局
        • 器件布局栅格的设置，一般IC器件布局时，栅格应为50-100mil,小型表面安装器件，如表面贴装元件布局时，栅格设置应不少于25mil
      • 7.3.3.2. 布线要求
        • 关键信号线优先，电源、模拟信号、高速信号、时钟信号和同步信号等关键信号优先布线
        • 密度优先原则：从单板上连接关系最复杂的器件着手布线。从单板上连线最密集的区域开始布线
        • 增加线间距，减少平行直线长度
        • 增加线宽度，降低其特性阻抗
        • 重要信号间可采用平行地线的方法隔离
        • 尽可能少拆线，不走90度折线
        • 少走过孔
        • 重要线不要走插座脚间穿过，频率高的线也应尽量避免
    • 7.3.4. 硬件度量指标
      • 7.3.4.1. 硬件进度偏差率
      • 7.3.4.2. 硬件第一次样机制作完成前缺陷发现数目
      • 7.3.4.3. 硬件遗留缺陷数目
      • 7.3.4.4. 硬件总体设计评审缺陷发现数目
      • 7.3.4.5. 硬件详细设计评审缺陷发现数目
      • 7.3.4.6. 样机
      • 7.3.4.7. 试产测试缺陷发现数目
      • 7.3.4.8. 原理
      • 7.3.4.9. 原理图重用率
      • 7.3.4.10. 构件重用率
      • 7.3.4.11. PCB重用率
      • 7.3.4.12. 结构图纸重用率
      • 7.3.4.13. 关键芯片重用率
    • 7.3.5. 硬件开发流程审计示例
      • 
      • 7.3.5.1. 开发活动必不可少的，不执行，开发便进行不下去
        • 单板硬件总体设计
        • 单板硬件详细审计
        • PCB设计等
      • 7.3.5.2. 保证开发质量的
        • 各种评审活动
        • 正规检视
        • 可靠性
        • 可测性
        • 可维护性设计
        • 详细设计阶段考虑单板工艺
        • 结构EM设计
      • 7.3.5.3. 流程执行时间如表
        • 
        • 各阶段起止时间说明
          • 单板总体设计阶段：硬件开发人员接到硬件开发任务书开始，单板总体设计方案评审通过结束
          • 单板硬件详细设计阶段：单板总体设计方案评审通过开始，到第一次PCB投板申请得到CAD室同意为结束
          • 投板阶段：指第一次投板时间，以第一次投板申请提交时间为开始，PCB回板开发人员开始第一次单板调试为结束
          • 单板硬件调试阶段：开发人员开始第一次单板硬件调试，到调试结束，包括第二次投板、多次投板的时间及每次的调试时间。如果有单板调试完成，但需等待其他单板完成才能开始系统联调，则要指出等待时间
          • 单板软件概要设计阶段：单板总体设计方案评审通过开始，单板软件概要设计方案评审通过结束
          • 单板软件详细设计阶段：单板软件概要设计方案评审通过开始，到单板软件编码结束时间为结束，包括编码时间
          • 单板软件调试阶段：单板软件调试开始，到调试结束
          • 系统联调/测试阶段：系统联调开始，到版本稳定为止
        • 执行较好的环节
          • 单板软硬件总体设计主要输入是硬件总体设计方案，在单板详细设计阶段考虑单板可测性、可维护性和可靠性，PCB布线经过评审，单板软硬件详细设计报告经过审核并按意见进行修改
        • 执行不好的环节
          • 单板硬件详细设计时没有考虑单板的工艺、装备和结构设计，关键器件没有替代策略，在单板详细设计阶段没有考虑单板EMC设计
        • 问题及改进建议
          • 产品的硬件总体方案没有总体组组织正式的评审就开始做单板
            • 由总体组对评审进行控制，产品的硬件总体方案评审报告归档后才能开始单板的开发，保证在以后的产品开发过程中不出现类似情况
          • 单板总体设计方案评审滞后于单板的详细设计
            • 项目组在做项目计划时按流程规定的时间顺序来安排活动，将单板总体设计方案放在单板详细设计的前面，然后严格按计划执行
          • 流程中规定应有一些输出，如单板可靠性设计报告、可维护性报告、单板工艺结构报告等，在审计过程中被访谈人员反映做过此类活动或在设计过程考虑到这点，但找不到相关正式记录（纪要、报告等）
            • 项目组按流程做项目计划，工作任务的完成应以相应流程规定的输出报告完成为结束标志
  • 7.4. 硬件设计输出文档模板
    • 7.4.1. 硬件总体设计方案
      • 7.4.1.1. 概述
        • 名称及版本号，说明本文档对应的硬件PCB板的正式名称及版本号
      • 7.4.1.2. 系统功能及功能指标
        • 系统总体结构图及功能划分，单板逻辑框图，组成系统各功能块的逻辑框图，电路结构图及单板组成，单板逻辑框图和电路结构图，关键技术讨论，关键器件清单，可靠性、安全性和电磁兼容性讨论，硬件测试方案，成本分析
      • 7.4.1.3. 单板总体设计
        • 单板尺寸，单板逻辑图及各功能模块说明，单板软件功能描述，单板软件功能模块划分，接口定义及相关板的关系，重要性能指标、功耗及采用标准，开发用仪器仪表等
    • 7.4.2. 单板总体设计方案
      • 7.4.2.1. 概述
        • 名称及版本号：说明本文档对应的单板的正式名称及版本号
        • 位置、作用、采用说明：简要说明单板在系统中的位置和主要作用，最好用框图表示（应与产品设计规格书保持一致），采用的标准（与产品设计规格一致，并细化），注意遵循公司所有有关的开发设计技术规范
        • 单板尺寸：说明单板的尺寸（含扣板、特殊器件）和单位，在尺寸要求特别严格的情况下，应说明使用该尺寸的足够理由
        • 开发目标：说明开发该单板的具体目标，具体目标包括面向产品实现产品功能，面向方案包括关键器件或电路的方案选择等，面向试验通过单板的调试过程决定某些可选功能（相关电路/软件模块）的增删
      • 7.4.2.2. 单板功能描述和主要性能指标
        • 说明各硬件单元、逻辑电路的划分，并说明单板软件、业务软件与硬件的支撑关系，建议采用框图和说明文字相结合的方式，需要说明各单元与其它单元的配合接口关系（主要接口类型和信息流向、处理关系）
        • 单板总体框图：对主要业务处理流程和各功能单元间配合关系进行分析说明
        • 功能单元1/2/3介绍
      • 7.4.2.3. 单板总体框图及各功能单元说明
        • 说明各硬件单元、逻辑电路的划分，并说明单板软件、业务软件与硬件的支撑关系，建议采用框图和说明文字相结合的方式，需要说明各单元与其它单元的配合接口关系（主要接口类型和信息流向、处理关系）
        • 单板总体框图：对主要业务处理流程和各功能单元间配合关系进行分析说明
        • 功能单元1/2/3介绍
      • 7.4.2.4. 单板接口定义、与相关板的关系
        • 外部接口：详细说明该单板的所有外部接口的设计要求，包括接口名、接口逻辑位置（批与系统中其它哪些模块相连）、接口硬件和软件特性和连接方式等，对模拟接口应说明电压特性、频率特性和负载特性等，对数字接口应说明电平特性、时序特性，必要时可加上某些通信协议特性等，对电源接口应说明电压特性、噪声容限要求、额定功率等
        • 用户接口：详细说明单板的面板上所有与用户有关的接口，包括面板指示灯、光口、以太网口、同轴电缆接口、串口，跳线、拔码开关等
        • 系统接口：单板与本系统外设备的接口，对于需要通过电缆或光纤连接的接口部分请注明，并同时给出对连接电缆性能指标的要求
        • 板际接口：以表格形式列出单板与母板插座信号的位置和定义，并详细说明单板对其它单板接口，包括每一个/组信号与哪块单板相连，输入/输出关系。以波形图的形式说明每组接口的时序，如果接口是标准接口（或其子集），如PCI，只需给出必要的说明
        • 内部接口：内部接口调测接口（如用于下载软件的串行口，测试点等）、设置接口（跳线、拔码开关、复位开关、电源开关等）和显示接口
        • 软件接口：站在软件人员的角度描述所有软件人员需要了解的硬件细节
        • 调试接口：详细说明单板上所有调试用接口，包括调试专用指示灯、跳线、拔码开关、电源保险丝、ISP接口、软件测试接口、硬件测试点等
      • 7.4.2.5. 关键器件选型
        • 考虑单板关键器件的选型（商务条件、技术可行性和供货风险），器件封装类型（选用新接插件要考虑线缆匹配，并进行可装配性分析，与单板工艺设计配套考虑）
      • 7.4.2.6. 单板各单元详细说明
        • 单板功能单元划分：从系统的角度阐述单板的逻辑实现，提供单板的逻辑框图，划分功能单元，对其中的各单元的功能进行简要说明
        • 单元详细描述：详细描述本单元的功能，给出本单元的功能框图，说明本单元对其它单元接口每个/组信号的详细定义，说明本单元的实现方法，包括使用的芯片、主要电路分析和解释，单元提供哪些自诊断、自测试功能，实际的硬件实现方式、需要哪些软件的支持
        • 单元间配合描述：详细说明采用什么总线、什么工作方式、下挂什么单元。详细说明单元间复位顺序，各单元间的时序关系，单板整体可测试性设计，软件加载方式说明等
      • 7.4.2.7. 单板软件需求和概要方案
        • 硬件对单板软件的需求，对单板内的所有与硬件可能相关的软件提出配套需求，包括功能需求、可测试性、可维护性需求等
        • 业务处理软件对单板硬件的需求可实现性评估
        • 单板软件与硬件的接口关系和实现方案
      • 7.4.2.8. 单板逻辑需求和概要方案
        • 单板内可编程逻辑设计需求，包括功能需求、性能需求、可测试性、可维护性需求等
        • 单板逻辑的概要方案
      • 7.4.2.9. 单板的产品化设计方案
        • 可靠性综合设计，单板可靠性指标需求、单板可靠性指标详细设计
        • 单板故障管理设计，主要故障模式和改进措施，故障检测率、隔离率计算、单板复位、断电重启流程等
        • 器件应用可靠性设计，简要说明单板器件过应力防护、降额、容限容差、寿命类器件维护设计方案
        • EMC、ESD、防护及安规设计，关键器件和关键信号的EMC设计，安规和防护设计，环境适应性和防护设计
        • 单板信号完整性设计说明
        • 单板工艺设计说明：包括PCB工艺方案、元器件工艺要求、预计的加工路线、单板装配、配线
        • 单板结构设计：包括接手条开机箱结构，指示灯、面板开关，紧固件，特殊器件结构配套设计，热设计及监控
        • 单板热设计、单板电源设计、单板可维护性设计、调试计划和方案
        • 其它配套措施：环境适应能力等方面的保障措施，单板调试、安装、使用维护注意事项，对生产维修环节的配套要求
      • 7.4.2.10. 附件
        • 安规器件清单
        • FMEA分析结果
    • 7.4.3. 硬件概要设计说明书
      • 7.4.3.1. 概述
        • 产品描述，产品功能和特性，说明产品的卖点功能、特性
        • 产品的开发环境
        • 产品的应用环境
      • 7.4.3.2. 针对需求的具体技术方案
        • 需求说明：可引用产品包需求文字
        • 约束条件：该项需求的设计约束、可制造性约束、物料约束、各类标准约束
        • 可实现的技术方案（含可替代方案）：详细描述技术方案，可用原理图、公式、3D图、仿真等方式体现
      • 7.4.3.3. 总体技术方案
        • 可实现的总体技术方案（含可替代方案）：对各需求的技术方案进行协调汇总，可用原理图、公式、3D图、仿真等方式体现
        • 多种总体技术方案的比较：从实现难度、复杂度、成本、性能指标、风险等方面加以比较
        • 结论：给出优选方案
      • 7.4.3.4. 硬件系统框架说明
        • 系统功能框图：系统包括哪些模块，以及各模块间的连接关系
        • 单板功能框图：单板的功能说明和大致布局
        • 单板内外接口说明及系统连线图：详细说明该单板的所有外部接口的设计要求，包括接口名、接口逻辑位置和与系统中其它哪些模块相连，以及使用接插件的类型
      • 7.4.3.5. 各功能单元概要设计说明
        • 示例：电源系统、说明系统、子系统的每路电源的设计原理和参考电路
      • 7.4.3.6. 整体布局、PCB板布局、信号完整性分析
        • 从整体的角度来考虑产品的设计，在具体设计中需要注意哪些方面
        • 确定系统需要多少块PCB板，对每块板PCB的结构、布局、层数和关键器件的摆放进行具体的分析对系统的关键信号和调整信号进行信号完整性分析，分析信号在电路中以正确的时序和电压进行传输，描述其信号质量
      • 7.4.3.7. 关键物料清单
        • 列出关键物料、长周期物料清单，并对物料的交期、最小采购数量等信息进行分析
      • 7.4.3.8. 物料成本分析
        • 给出典型配置的物料成本和其它配置主要模块的物料成本
      • 7.4.3.9. 风险控制
        • 分析项目进行中的风险，并说明应对风险的策略及跟踪管理手段
    • 7.4.4. 硬件详细设计说明书
      • 7.4.4.1. 概述
        • 背景：对应的单板硬件正式名称和版本号
        • 单板功能描述：简述单板功能，内容参照单板硬件概要设计方案中的相关章节
        • 单板运行环境说明：说明各种可能的物理环境和逻辑环境、软件支持环境等
        • 重要性能指标：列出单板的主要性能指标，例如处理器性能、缓存容量、端口通信速度等指标
        • 架构详细说明：产品的系统框图，各单板在系统中的位置和作用，主要功能特点，各单板上的功能模块、原理框图、性能指标、采用的标准
        • 关键器件：对单板的关键器件详细说明其软硬件特性并分析优缺点，如果曾经有多个可选对象，应说明目前选择该器件的原因和不选其它可能性的原因
      • 7.4.4.2. 各功能模块的详细设计说明
        • 单板功能单元划分：从系统的角度单核单板的逻辑实现，提供单板的逻辑框图，划分功能单元，对其中的各单元的功能进行简要说明。本节主要描述各单元内部的详细结构和相互之间的接口
        • 单元详细描述：各功能模块详细设计说明，以电源系统设计为例
        • 功能模块详细设计说明：详细描述本单元的功能，给出本单元的功能框图，需要指出电路的设计关键点，对主要的电路应提供局部原理图并进行分析和解释
        • 与其它单元的接口：说明本单元对其它单元接口每个/组信号的详细定义，包括时序说明
        • 实现方式：说明本单元的实现方法，包括使用的芯片、主要电路分析和解释。如果板上有可编程逻辑器件，应在此提供这些可编程器件的内部原理图、外部管脚图（含说明）、功能模块图（含说明）及相关的时序图
        • 关键器件特性指标：需要列出器件的关键特性指标（包括输入、输出信号电平指标，电流指标、功耗、ROHS、封装等）对单板中的关键器件详细说明其软硬件特性并分析优缺点，如果曾经有多个可选对象，应说明目前选择该器件的原因和不选其它可能性的原因
        • 可测试性说明：单元提供哪些自诊断、自测试功能、实际的硬件实现方式、需要哪些软件的支持，结合生产、维护等给出关键测试点
        • 单元间配合描述
        • 总线设计：说明采用什么总线、什么工作方式、下挂什么单元，需要给出图示和文字解释
        • 时钟分配：说明有什么时钟源、提供给什么单元、时钟之间关系如何
        • 复位逻辑：说明单元间复位顺序、Watchdog设计、复位单元加载顺序
        • 各单元间的时序关系：说明各单元的信号经过哪些逻辑的处理，符合什么样的时序关系，再输出到另一个单元
        • 单板整体可测试性设计：单板提供哪些自诊断、自测试功能，实际的硬件实现方式、需要哪些软件的支持
      • 7.4.4.3. 硬件单板主要接口定义、与相关板的关系
        • 板际接口：以表格形式列出单板与母板插座信号的位置和定义，并详细说明单板对其它单板接口，包括每一个/组信号与哪块单板相连，输入/输出关系
        • 系统接口：单板与本系统外设备的接口，对于需要通过电缆或光纤连接的接口部分请注明，并同时给出对连接电缆性能指标的要求
        • 软件接口：对单板软硬件接口部分进行进一步的补充设计描述，如单板片选信号、中断信号、通信端口、寄存器、关键器件分配及说明
        • 大规模逻辑接口：说明单板硬件各单元与大规模逻辑的接口定义、处理信息类型、配套控制方式、接口时序等
        • 调测接口：详细说明单板上所有调试用接口，包括调试专用指示灯、路线、拔码开关、电源保险丝、ISP接口、软件测试接口、硬件测试点等
        • 用户接口：详细说明单板的面板上所有与用户有关的接口，包括面板指示灯、光口、以太网口、同轴电缆接口、串口、路线、拔码开关等
      • 7.4.4.4. 单板可靠性综合设计说明
        • 单板可靠性指标：参照单板硬件概要设计方案中的内容。本节需要修正单板硬件概要设计方案中的估算数据
        • 单板故障管理设计：主要故障模式和改进措施，故障定位率计算，冗余单元倒换成功率计算，冗余单板倒换流程，单板复位、断电重启流程
        • 器件应用可靠性设计说明：单板器件可靠应用分析结论，器件工程需求符合度分析，单板硬件返修率预计及改进对策，上、下电过程分析，器件可选应用薄弱点分析，替代容差分析，器件主离散性、最坏情况容限分析
      • 7.4.4.5. 单板可维护性设计说明
        • 单板提供PCB和逻辑版本号上报功能的方式
        • 单板支持逻辑、单板软件和数据的加载和配置的方式，包括在线加载和远程加载
        • 单板能通过单板软件完成哪些设置、控制和操作，如工作方式设置、复位、倒换、闭塞、解闭塞、商品自环和单板自环等，硬件部分是如何支撑这些功能的
      • 7.4.4.6. 单板依赖完整性说明
        • 关键器件及相关信息，信号串扰、毛刺、过冲的限制范围和保障措施，其它重要信号及相关处理方案，物理实现关键技术分析
      • 7.4.4.7. EMC、ESD、防护及安规设计说明
        • 单板电源、地的分配图、关键器件和关键信号的EMC设计，安规、环境适应性和防护设计
      • 7.4.4.8. 单板工艺设计说明
        • PCB工艺方案，元器件工艺要求
        • 预计的加工路线，描述单板的加工路线，包括单板组装后处理方式（如涂覆等）、老化方式、测试路线等
        • 单板装配：单板的安装及坚固方式，单板上紧固件的种类及可装配性、可操作性、禁布区，小板和大板装配方式、装配空间，紧固方式、装配精度要求
        • 新工艺需求：新工艺应用及其实验安排，并提出对基础工艺平台的要求
        • 配线：说明单板（包括母板）出线的方式，接插件选择
      • 7.4.4.9. 单板结构设计说明
        • 拉手条或机箱结构，指示灯、面板开关、紧固件，特殊器件结构配套设计
      • 7.4.4.10. 风险管理
        • 分析开发过程中存在的各种影响开发进度的风险，例如关键器件的交货周期、关键技术的实现等，并对之进行分析，给出预防措施
      • 7.4.4.11. 附件
        • 安规器件清单，FMEA分析结果，物料清单编码索引，列出制成板，成品板和软件的编码，便于查询各种清单，参考资料清单，参考资料清单，其它重要详细设计信息
    • 7.4.5. 原理图和PCB图框
      • 
    • 7.4.6. PCB制版要求
      • 
    • 7.4.7. 单板调试记录
      • 
      • 7.4.7.1. 单板硬件
        • 单板硬件功能模块划分、单板硬件各模块调试进度、调试中出现的问题及解决方法
      • 7.4.7.2. 单板软件
        • 单板软件功能模块划分及各功能模块调试调试进度、单板软件调试出现问题及解决方法、下一阶段的调试计划、测试方案修改
      • 7.4.7.3. 汇总记录
        • 原始数据记录，系统方案修改说明，单板方案修改说明，器件改换说明，原理图，PCB图修改说明，可编程器件修改说明，调试工作阶段总结，调试进展说明，下一阶段调试计划及测试方案的修改
    • 7.4.8. 单板硬件测试报告
      • 硬件测试一般包括单板系统联调和样机测试
      • 7.4.8.1. 概述
        • 基本情况介绍：填写测试中针对的机型和测试验证重点
        • 单板模块划分：从调试测试的角度简要说明单板硬件功能模块的划分情况，以及各个模块的功能和相互关系
        • 调试测试网图：简单描述调试测试的组网图
        • 调试时间、地点及人员
        • 使用仪器和设备
      • 7.4.8.2. 测试范围
        • 硬件测试主要针对整机外部使用的特性，内部信号测试由硬件开发人员完成
        • 原型机阶段：预测试，对所有功能模块进行测试，对电气参数进行测试如系统信号测试等，对性能进行摸底测试，对可靠性进行摸底测试，对结构进行摸底测试，对提交文档进行验证
      • 7.4.8.3. 调试测试用例记录
        • 功能部分调试，模块测试用例；信号质量测试用例
        • 失效器件原因分析：描述对关键器件的失效分析结果、可靠性改进和预防措施
      • 7.4.8.4. 测试总结
        • 测试充分性评价：对本次调试的项目进行总结，包括完成总项数、通过多少项、失败多少项、部分通过多少项及百分比等，对产品实际测试使用的CASE在CASE库/样机测试用例中的比例说明，对这次测试了的模块的比例说明，测试偏重点的说明
        • 结果及风险分析：对缺陷分布的分析和测试同类产品对情况的分析，分析修改过或未修改，及可能未能测试到的问题带来的问题和情况的分析，测试结果的说明
        • 遗留问题报告：遗留问题是指调试过程中发生的，并且在调试报告时仍没有得到解决需要投下版PCB回归测试验证的问题
        • 调试测试经验总结
      • 7.4.8.5. 测试结果
        • 测试结论：通过，产品设计符合需求。不通过，产品存在重大缺陷导致产品不符合需求要求。有条件通过，产品部分功能不符合需求或存在部分缺陷，介对后续活动影响不大的情况。需要说明产品的后续处理方式，并进行跟踪
  • 7.5. 硬件评审要素
    • 7.5.1. 单板软件测试评审要素
      • 7.5.1.1. 单板升级兼容性测试
        • 与各种硬件版本、以前单板软件的兼容性
      • 7.5.1.2. 单板通用功能测试
        • 根据本板完成功能和各项要求与指标测试，测试项目是否完备
        • 测试方法是否科学
        • 是否对这些项目进行了测试：单板上电开工、后台复位、带电拔插等
        • 单板内是否有自检功能：如内存自检、邮箱自检、主要接口自检、主要功能器件自检
        • 单板内是否有调试口，是否对调试口进行了测试
        • 单板是否进行了超负荷测试，最大能力是多少？是否满足要求
        • 单板的维护功能是否做了测试
        • 该单板在详细设计中要求的特殊情况是否进行了测试
      • 7.5.1.3. 协议功能测试
        • 是否可用标准协议测试仪进行测试，测试结果是否满足要求
        • 协议的各种异常情况是否做了完整的测试
      • 7.5.1.4. 较复杂的软件
        • 是否对程序的主要分云进行了测试
        • 软件是否模块化
        • 对各项功能模块，是否对其功能进行了模拟输入测试
        • 是否进行了单元测试
        • 测试用例是否合理
        • 是否进行了内存占用率的测试
        • 编程是否按照规范
        • 是否进行了静态代码审查
    • 7.5.2. 单板硬件测试评审要素
      • 7.5.2.1. 规范性
        • 产品名称、型号、版本号、保密代号是否详细、清楚
        • 是否遵守模板要求
        • 资料、文献引用是否正确
      • 7.5.2.2. 技术可行性
        • 是否具有完备的单板功能说明
        • 是否具有待测试单板正常工作所需环境的详细说明
        • 是否具有完备的EMC测试布置图
      • 7.5.2.3. 测试完备性
        • 是否完备列举了所有应该测试的端口
        • 是否正确正确将不同商品进行测试类别分类、等级分类
        • 是否完备列举待测试单板可以测试的项目
      • 7.5.2.4. 可测试性
        • 是否考虑让单板工作在最大EMI发射状态
        • 是否考虑寻找最敏感EMS受扰状态
        • 是否考虑到特殊测试要求：如对比测试、极限测试等
        • 是否有明确的敏感度判断标准
        • 是否考虑了公司现有的试验条件
        • 是否考虑了出现问题时大致要采取的措施，现象处理手段、工具准备等
        • 是否考虑了意外防护
      • 7.5.2.5. 成本周期
        • 是否充分考虑了时间安排
    • 7.5.3. 外协评审要素
      • 7.5.3.1. 工程资料
        • BOM是否为本次生产有效版本
        • 器件清单、烘烤要求是否己提供，GERBER是否为本次生产有效版本
        • 是否有本次生产工艺流程要求
        • 测试平台软件是否己下达，测试是否有作业指导书或专人指导
        • 是否对外协提供电路原理图或维修培训
        • 测试夹具线料及专用耗材是否准备到位，贴片设备及钢网是否到位（含有、无铅切换准备）
        • 作业指导书是否准备
      • 7.5.3.2. 品质保障
        • 来料检验标准、PCBA检验标准、异常停线标准是否提供
        • 检验人员是否到位，有无检验标准，是否对人员进行培训
        • 该产品转产前平均直通率及主要问题点是否提供
      • 7.5.3.3. 计划商务
        • 物料是否正常入库并预先处理（烘烤等）
        • 生产交货计划能否达到交货要求
        • 报价是否完成，生产线体配置是否完成
    • 7.5.4. 硬件开发流程实施情况评审要素
      • 7.5.4.1. 单板软硬件总体设计之前是否己有硬件总体设计方案和软件总体设计方案？
      • 7.5.4.2. 单板软硬件总体设计方案是否经总体组组织的评审？是否按照评审意见进行了修改？
      • 7.5.4.3. 是否按照软硬件总体设计方案制定了单板的软硬件测试计划和单板综合测试计划？
      • 7.5.4.4. 单板软硬件的测试计划是否经过了总体组组织的评审？
      • 7.5.4.5. 单板硬件详细设计时是否考虑选用共享电路提供共享电路，是否考虑单板的工艺、结构、电源设计、EMC设计、装备设计、可靠性设计、可测试性设计、可维护性设计？
      • 7.5.4.6. 关键器件是否有替代策略？
      • 7.5.4.7. 选用多少非优选器件？有无计算器件的替代率和复用率？
      • 7.5.4.8. 单板的软硬件详细设计报告是否经过评审？单板软硬件详细设计是否按评审意见进行了修改？
      • 7.5.4.9. PCB布局、布线是否评审？PCB布局、布线是否按评审意见进行了修改？
      • 7.5.4.10. 软硬件的集成测试计划是否经过总体组的评审？
      • 7.5.4.11. 系统联调测试前是否通过版本申请提交版本
• 8. 软件管理
  • 8.1. 软件管理常见的问题
    • 8.1.1. 人员、组织
      • 8.1.1.1. 软件开发团队的管理职责不清晰，人员流动频繁，人员工作安排不合理
    • 8.1.2. 数据
      • 8.1.2.1. 没有集中、唯一、长期正确的软件管理平台，如VSS、SVN、Rational Clear case等
      • 8.1.2.2. 软件数据和其它产品数据分散管理
      • 8.1.2.3. 软件管理相关的文档，以及软件本身输出质量不高
      • 8.1.2.4. 软件配置管理有待提高，嵌入式软件与PCBA、系统软件之间的关联关系不清晰
    • 8.1.3. 流程
      • 8.1.3.1. 软件开发规范与方法、过程控制有待提高
      • 8.1.3.2. 软件需求没有统一管理
      • 8.1.3.3. 软件开发缺乏足够的系统分析
      • 8.1.3.4. 软件开发过程缺乏明显的阶段评审
      • 8.1.3.5. 子主题
      • 8.1.3.6. 开发的软件缺乏足够的测试，导致软件质量不高
      • 8.1.3.7. 没有全面的变更流程和问题跟踪流程
      • 8.1.3.8. 软件与其它专业的协同有待改善
      • 8.1.3.9. 开发周期出现严重拖期
  • 8.2. 软件管理流程
    • 
    • 8.2.1. 定义产品包需求
      • 8.2.1.1. 活动概述
        • 探索关键技术的概念，并对其进行评估和优劣势分析，配合SE做软件部分可选概念探索和选择，提出软件技术概念的选择建议
      • 8.2.1.2. 模板/标准/工具
        • 产品包需求
    • 8.2.2. 需求分解与分配/总体设计
      • 8.2.2.1. 活动概述
        • 产品总体设计，根据己确定的产品包概念、产品包需求进行软件的需求分解和分配，配合SE做软件部分分解分配
      • 8.2.2.2. 模板/标准/工具
        • 产品需求分解与分配模板
        • 产品总体方案
    • 8.2.3. 系统设计与设计规格定义
      • 8.2.3.1. 活动概述
        • 编写和审核产品技术规格说明书
      • 8.2.3.2. 模板/标准/工具
        • 产品技术规格书
    • 8.2.4. 软件概要设计、评审
      • 8.2.4.1. 活动概述
        • 进行软件的架构设计和各模块之间的接口，确认软件同其它相关的外部接口，各模块的主要技术，系统的核心逻辑，关键产品组件或关键功能模块，设计用户操作界面及交互界面
      • 8.2.4.2. 模板/标准/工具
        • 软件概要设计说明书
        • 软件概要设计评审要素
    • 8.2.5. 软件详细设计、评审
      • 8.2.5.1. 活动概述
        • 开发负责人主导，开发工程师实现
        • 编写详细设计说明书
        • 详细描述关键模块的功能
        • 软件工程师编写、审核和确认单元测试用例
      • 8.2.5.2. 模板/标准/工具
        • 软件详细设计说明书
        • 软件详细设计评审检查单
    • 8.2.6. 编程
      • 8.2.6.1. 活动概述
        • 完成代码
      • 8.2.6.2. 模板/标准/工具
        • 源代码
        • 《软件编码规范建议》
    • 8.2.7. 代码走查
      • 8.2.7.1. 活动概述
        • 根据编码规范走查各模块代码及单元测试代码
        • 对功能实现尽可能的逻辑审核，确认与设计的一致性
        • 对代码质量提出建议和意见，赶写代码走查单
        • 软件工程师根据代码走查修改意见修改代码，修改后的代码提交由审核人确认问题是否修改
      • 8.2.7.2. 模板/标准/工具
        • 《软件代码走读要素表》
    • 8.2.8. 单元测试
      • 8.2.8.1. 活动概述
        • 软件工程师根据各个组件模块选择合适的单元测试方法，如功能测试、模块白盒测试等
        • 对软件模块进行单元测试并记录单元测试结果及发现的缺陷
      • 8.2.8.2. 模板/标准/工具
        • 《软件单元测试报告》
    • 8.2.9. 集成测试
      • 8.2.9.1. 活动概述
        • 编写软件集成测试方案，软件工程师对软件系统进行集成测试，缺陷修改
      • 8.2.9.2. 模板/标准/工具
        • 软件集成测试方案
        • 软件集成测试报告
    • 8.2.10. 配合测试工程师进行SDV测试
      • 8.2.10.1. 活动概述
        • 软件工程师配合测试工程师进行SDV测试，软件工程师进行缺陷修改
      • 8.2.10.2. 模板/标准/工具
        • 《测试报告》
    • 8.2.11. 配合测试工程师进行SIT测试
      • 8.2.11.1. 活动概述
        • 软件工程师配合测试工程师进行SIT测试，软件工程师进行缺陷修改
      • 8.2.11.2. 模板/标准/工具
        • 《测试报告》
    • 8.2.12. 配合测试工程师进行SVT测试
      • 8.2.12.1. 活动概述
        • 软件工程师配合测试工程师进行SVT测试，软件工程师进行缺陷修改
      • 8.2.12.2. 模板/标准/工具
        • 《测试报告》
  • 8.3. 软件管理专题
    • 8.3.1. 软件管理“V模型”
      • 在一个软件为主的研发项目中，建议留出至少20%的时间用于需求分析，留出至少20%的时间用于概要设计和详细设计，编码时间一般不超过项目时间的40%，留出至少20%的时间用于验收测试，专职的技术经理负责根据系统的用例和设计进行编码与代码检查，建立标准的单元测试管理流程和文档体系
      • 8.3.1.1. 在一个软件为主的研发项目中，建议留出至少20%的时间用于需求分析，留出至少20%的时间用于概要设计和详细设计，编码时间一般不超过项目时间的40%，留出至少20%的时间用于验收测试，专职的技术经理负责根据系统的用例和设计进行编码与代码检查，建立标准的单元测试管理流程和文档体系。
    • 8.3.2. 软件概要设计原则
      • 8.3.2.1. 总体原则和方法：
        • 由粗到细、互相结合、定性分析和定量分析相结合、模型化，考虑系统的一般性、关联性、整体性和层次性；
      • 8.3.2.2. 分解协调：
        • 分解是指将一个复杂的系统分解为若干个子系统。协调是系统内协调，即根据系统的结构、功能、目标的要求，使各个子系统之间协调配合。在各个子系统局部优化的基础上，通过内部平衡的协调控制，实现系统的整体优化；
      • 8.3.2.3. 屏蔽抽象：
        • 从简单的框架开始，隐含细节；
      • 8.3.2.4. 一致性：
        • 统一的规范、统一的标准、统一的文件模式，每个模块应当有一个统一命名的容易理解的名字；
      • 8.3.2.5. 编码：
        • 由外向内；
      • 8.3.2.6. 面向用户：
        • 概要设计是对于按钮按下后系统怎么做的简要说明；
      • 8.3.2.7. 模块、组件的充分独立性、封闭性；
      • 8.3.2.8. 考虑静态结构与动态运行；
      • 8.3.2.9. 每个逻辑对象都应当说明其所处物理对象；
      • 8.3.2.10. 每个物理对象都有合适的开发人员，并且有利于分工与组装；
      • 8.3.2.11. 确立每个构架视图的整体结构，视图的详细组织结构、元素的分组，以及这些主要分组之间的接口；
      • 8.3.2.12. 必要的人员储备及培训，软件构架与使用的技术平台密切相关，具体的软件构架人员应当具备使用这些平台的软件开发经验；
      • 8.3.2.13. 通过需求功能与设计模块之间的列表对应，检查每个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现模块的完整性，同时可以检查重复和不必要的模块；
      • 8.3.2.14. 在需求调研分析过程中，对业务处理过程了解完整性和准确性。调查了解清楚所有的业务流程才能设计出适合各流程业务节点用户业务特点和习惯的软件；
      • 8.3.2.15. 进行软件概要设计时，要尽量排除业务流程的制约，把流程中的各项业务结点工作作为独立的对象，设计成独立的模块，充分考虑他们与其他各种业务对象模块的接口，在流程之间通过业务对象模块的相互调用实现各种业务。
    • 8.3.3. 8.3.3 软件配置与发布
      • 软件配置管理简称SCM（SoftwareConfigurationManagement的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。
      • 8.3.3.1. ♢专职的配置经理订立与执行软件发布管理计划；
      • 8.3.3.2. ♢建立标准的软件变更管理流程，收集上线系统的缺陷及功能扩展；
      • 8.3.3.3. ♢组建变更控制委员会来审批软件变更请求，必须严格管理上线系统的版本修改，维护人员不得随意更改上线版本，以便保证已修复的缺陷，在系统升级后不会重复出现；
      • 8.3.3.4. ♢采用发布管理工具来管理软件的修改和发布过程，在每次版本更新时都应提交一份详细的发布版本说明，描述在新版本中修复了哪些缺陷、增加了哪些新功能，以便用户顺利进行系统升级。
    • 8.3.4. 8.3.4 软件质量保证及审核
      • 
      • 8.3.4.1. 软件质量保证方式包括结对编程，保证软件测试时间，配置技术背景的QA，独立于项目组的QA，按阶段进行正式技术评审。
    • 8.3.5. 软件测试
      • 
      • 8.3.5.1. 一般测试通过标准是：单元功能同设计需求一致，规定的路径覆盖率及覆盖类达到要求，且单元执行正确，所规定的测试手段被使用，且单元执行正确，对残留错误有合法解释或被认可暂留，致命和严重类缺陷为0，一般类缺陷小于1%。
    • 8.3.6. 8.3.6 软件质量
      • 
    • 8.3.7. 8.3.7 软件管理改善路径图
      • 
      • 8.3.7.1. 改善软件管理过程需要首先保证输出的质量，其次要减少“救火”式行为，从“软件是测试出来”向“软件是设计出来”转变
  • 8.4. 敏捷软件开发
    • 
    • 8.4.1. 前言
      • 8.4.1.1. 信息时代需求变化更快，企业核心竞争力是快速交付
      • 8.4.1.2. 据业界调查显示，45%的软件特性客户没有使用，一个50人的开发团队，每人平均30%时间用于编码，70%的时间用于与客户和其他成员交流。客户一开始很难想清楚真正要的东西，一般是在过程中逐步发现真正需求的，应该通过不断地向客户交付可用的产品，启发客户逐步发现真正的需求
      • 8.4.1.3. 敏捷开发的特点包括把复杂的问题分解成一系列相对简单的问题，早期的迭代解决风险最高的问题，每次迭代都增加系统的功能并产生一个可运行的结果，每次迭代都包括有测试工作，支持动态联盟和虚拟组织，轻量级的开发过程，基于时间JustEnough，并行，基于组件的软件工程等
      • 8.4.1.4. 迭代化开发可以提前识别和避免风险
    • 8.4.2. 敏捷宣言
      • 8.4.2.1. 个体和交互 胜过过程和工具
      • 8.4.2.2. 可以工作的软件 胜过面面俱到的文档
      • 8.4.2.3. 客户合作胜过 合同 谈判
      • 8.4.2.4. 响应变化胜过 遵循计划
    • 8.4.3. 敏捷团队3种角色职
      • 
    • 8.4.4. 敏捷实践概览
      • 8.4.4.1. 概览
        • 迭代开发
          • 
      • 8.4.4.2. 团队
        • 完整团队
          • 
      • 8.4.4.3. 工作件
        • 产品Backlog
          • 
        • 迭代Backlog
          • 
          • 迭代Backlog。只有产品主管才能设置迭代的优先级。客户或者开发人员提出新需求或新任务时应该和产品主管及整个团队讨论，明确任务的价值和优先级之后，再决定是否可以把任务放到当前的迭代Backlog上。如果一定要按期完成工作，就得保证产品backlog的完整，并做好估算。哪怕需求信息量很小，有估算也比没估算的好。把估算跟团队生产率合并以后，制定出的计划就更容易执行和实现
        • 完成标准
          • 
      • 8.4.4.4. 管理实践
        • 迭代计划会议
          • 
        • 每日站立会议
          • 
          • 每日站立会议。目的是加强团队交流和信息共享，互相了解彼此都在做什么工作、完成了什么任务。每日的信息传递可以让每个人有更多的机会了解整个项目的业务和技术状况。如果在工作中遇到障碍或问题，也可以提出来请求大家的帮助。一般在敏捷团队中，遇到问题建议当场就提出来，或直接去找相关的同事，问他们有没有处理过类似的问题或者提供解决问题的建议。每日站立会议促使每个人在早上就做好一天的工作计划。每个人一天的工作就会有明确具体的目标，直接提高每个人每天的工作效率。每日站立会议最佳的时间是早上上班的时候，例如每天早上9：30按时举行的晨会，解决障碍和问题，沟通一天的工作安排，然后全身心地投入一天的工作中。每日站立会议不是每天的工作报告，也不是项目经理进行工作检查。项目经理应该营造一个安全的会议氛围，让每个人都愿意说出真正发生的事情，就算是昨天遇到技术问题没有任何的工作成果，也应该谅解并给出建议。每日站立会议时可以端杯饮料，很轻松地围成一圈，说说笑笑，会议结束后就开始一天的工作。
        • 可视化管理
          • 
          • 明确短期目标。如果让一个团队做半年的详细工作计划非常困难，但如果是做2周的工作计划是比较容易实现的。假设客户有100件事情要做，但团队在一个迭代（一般是2周左右）中，只能完成20件事情，建议明确告诉客户，一个迭代的时间周期里我们只可以完成20件事情，那么先开发其中20件最有价值的东西。根据项目团队的经验做好一个合理的2周计划应该不难，相对的计划会很准确，而且前面一个迭代的工作量，是这个迭代最好的参照
        • 迭代验收
          • 
        • 迭代回顾会议
          • 
      • 8.4.4.5. 技术实践
        • 用户故事
          • 
        • 结对编程
          • 
        • 测试驱动开发
          • 
        • 持续集成
          • 
    • 8.4.5. 敏捷软件开发典型7个场景
      • 8.4.5.1. PO和开发团队对产品业务目标达成共识
      • 8.4.5.2. PO建立和维护产品需求列表，需求会不断新增和改变，并进行优先级排序
      • 8.4.5.3. PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发
      • 8.4.5.4. 开发团队细化本轮迭代需求，并按照需求的优先级依次在本轮迭代完成
      • 8.4.5.5. 开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明
      • 8.4.5.6. PO对每轮迭代（2～4周）交付的可工作软件进行现场验收和反馈
      • 8.4.5.7. 回到第3步，开始下一轮迭代
    • 8.4.6. 实施敏捷的9个步骤
      • 8.4.6.1. 思想动员
        • 
      • 8.4.6.2. 差距分析
        • 
      • 8.4.6.3. 环境和工具准备
        • 
      • 8.4.6.4. 敏捷实践技能准备，技术能力准备
        • 
      • 8.4.6.5. 确定开发过程和准备应用的实践
        • 
      • 8.4.6.6. 敏捷实施
        • 
      • 8.4.6.7. 回顾评估与调整改进
        • 
      • 8.4.6.8. 激励表彰
        • 
      • 8.4.6.9. 项目结束总结
        • 
  • 8.5. 软件输出文档模板
    • 8.5.1. 软件需求规格说明书模板
      • 8.5.1.1. 简介
        • 
      • 8.5.1.2. 总体概述
        • 
      • 8.5.1.3. 具体需求
        • 
      • 8.5.1.4. 总体设计约束
        • 
      • 8.5.1.5. 软件质量特性
        • 
      • 8.5.1.6. 其它需求
        • 
      • 8.5.1.7. 需求分级
        • 
      • 8.5.1.8. 验收准则
        • 
    • 8.5.2. 软件概要设计说明书模板
      • 8.5.2.1. 概述
        • 
      • 8.5.2.2. 设计约束
        • 
      • 8.5.2.3. 总体设计
        • 
      • 8.5.2.4. 接口设计
        • 
      • 8.5.2.5. 系统数据结构
        • 
      • 8.5.2.6. 模块定义
        • 
      • 8.5.2.7. 安装/运行/配置
        • 
      • 8.5.2.8. 软件调试/测试方法
        • 
    • 8.5.3. 软件详细设计说明书模板
      • 
      • 8.5.3.1. 概述
      • 8.5.3.2. 模块架构
      • 8.5.3.3. 数据结构
      • 8.5.3.4. 算法和逻辑
      • 8.5.3.5. 模块描述
      • 8.5.3.6. 类/对象接口
      • 8.5.3.7. 性能需求
      • 8.5.3.8. 其它需求
      • 8.5.3.9. 安装/运行/配置
    • 8.5.4. 软件集成测试评审报告模板
      • 
      • 8.5.4.1. 评审要点
      • 8.5.4.2. 评审意见
      • 8.5.4.3. 项目组反馈意见
      • 8.5.4.4. 评审结论
  • 8.6. 软件评审要素
    • 8.6.1. 软件任务书评审检查要素
      • 
      • 8.6.1.1. 资源和进度
      • 8.6.1.2. 技术内容
      • 8.6.1.3. 项目费用
    • 8.6.2. 软件需求分析评审检查要素
      • 
      • 8.6.2.1. 资源和进度
      • 8.6.2.2. 需求内容
      • 8.6.2.3. 需求变更
    • 8.6.3. 软件概要设计评审要素
      • 
      • 8.6.3.1. 资源和进度
        • 
      • 8.6.3.2. 依从性
        • 
      • 8.6.3.3. 功能性
        • 
      • 8.6.3.4. 完整性
        • 
      • 8.6.3.5. 一致性
        • 
      • 8.6.3.6. 可行性
        • 
      • 8.6.3.7. 数据使用
        • 
      • 8.6.3.8. 接口
        • 
      • 8.6.3.9. 可维护性
        • 
      • 8.6.3.10. 可靠性
        • 
      • 8.6.3.11. 性能
        • 
      • 8.6.3.12. 安全性
        • 
    • 8.6.4. 软件详细设计评审检查要素
      •  
      • 8.6.4.1. 资源和进度
        • 
      • 8.6.4.2. 依从性
        • 
      • 8.6.4.3. 功能性
        • 
      • 8.6.4.4. 一致性
        • 
      • 8.6.4.5. 数据使用
        • 
      • 8.6.4.6. 接口
        • 
      • 8.6.4.7. 可靠性
        • 
      • 8.6.4.8. 清晰性
        • 
      • 8.6.4.9. 可追溯性
        • 
      • 8.6.4.10. 易测性
        • 
      • 8.6.4.11. 性能
        • 
      • 8.6.4.12. 可维护性
        • 
    • 8.6.5. 软件编码和单元测试评审检查要素
      • 
      • 8.6.5.1. 资源和进度
      • 8.6.5.2. 编码和测试
    • 8.6.6. 代码走查评审要素
      • 
      • 8.6.6.1. 代码走查评审要素
    • 8.6.7. 软件集成测试评审检查要素
      • 
      • 8.6.7.1. 资源和进度
      • 8.6.7.2. 测试过程
    • 8.6.8. 软件配置项测试评审检查要素
      • 
      • 8.6.8.1. 资源和进度
      • 8.6.8.2. 技术内容
• 9. 测试管理
  • 测试是产品成败的关键要素之一。国内企业研发由于交期或者能力水平原因，对测试普遍不关注，无法保证产品的质量。
  • 9.1. 测试管理常见的问题
    • 
    • 9.1.1. 测试前
    • 9.1.2. 测试中
    • 9.1.3. 测试后
    • 9.1.4. 测试过程
  • 9.2. 测试过程
    • 
    • 9.2.1. 测试分类
      • 9.2.1.1. SIV测试，系统集成验证System Integration Verify；
      • 9.2.1.2. 原型机测试=SDV测试，系统设计验证System DesignVerify；
      • 9.2.1.3. 功能样机测试、型式试验=SIT测试，系统集成测试Systemintegration Test；
      • 9.2.1.4. 组织面向制造测试、中试产品测试=SVT测试，系统确认测试System VerficationTest；
    • 9.2.2. 测试类型或阶段
      • 
      • 9.2.2.1. 测试分为三个阶段
        • 
        • 单元测试
        • 集成测试
        • 系统测试
      • 9.2.2.2. 集成测试也是产品最关键的一步测试，如果问题较多就把产品送到测试部，会造成反复测试，从而浪费人力、物力资源，延误工期
      • 9.2.2.3. 在确定测试的范围时，一个需要考虑的重要问题是这个产品有多少是可测试的。一个有价值的功能一定是可测试的，如果不能测试，这个功能要么是没有价值，要么是没有描述清楚。制定测试策略时先测试优先级最高的需求，对新的功能及修改旧功能的代码优先进行测试，测试那些最有可能出现问题的地方，关注最终用户最常使用的功能和配置情况，使用等价类划分技术和边界值分析技术来减少测试工作量
    • 9.2.3. 测试步骤
      • 
      • 9.2.3.1. 测试需求分析和计划
      • 9.2.3.2. 测试方案设计
      • 9.2.3.3. 测试用例编写
      • 9.2.3.4. 测试执行
      • 9.2.3.5. 测试评估
      • 9.2.3.6. 缺陷跟踪
      • 9.2.3.7. 测试报告
    • 9.2.4. 测试活动对照表
      • 9.2.4.1. 功能测试
      • 9.2.4.2. 用户界面测试
      • 9.2.4.3. 性能/指标测试
      • 详细说明
        • 
      • 9.2.4.4. 负载测试
      • 9.2.4.5. 压力测试
      • 9.2.4.6. 容量测试
      • 9.2.4.7. 外部接口测试
      • 9.2.4.8. 软件协议一致性测试
      • 9.2.4.9. 容限/容错测试
      • 9.2.4.10. 电磁兼容性（EMC）测试
      • 9.2.4.11. 防雷测试
      • 9.2.4.12. 安全测试
      • 9.2.4.13. 热测试
      • 9.2.4.14. 环境测试（包括高低温/温度等）
      • 9.2.4.15. 可靠性强化和鉴定测试
      • 详细说明
        • 
      • 9.2.4.16. 回归测试
      • 9.2.4.17. 需要的特别测试（如可安装性、可维护性测试等）
      • 详细说明
        • 
    • 9.2.5. 测试跟踪矩阵
      • 
      • 9.2.5.1. 需求编号应与用户需求说明编号一致，每一条需求应至少被一条（但不限于一条）测试用例所覆盖
      • 9.2.5.2. 每一条测试用例至少被一条（但不限于一条）测试规程所覆盖
      • 9.2.5.3. 规程的编号采用独立标号的方式，一般规则为：项目名称+项目测试阶段+序号
    • 9.2.6. 测试内容及通过条件
      • 
      • 9.2.6.1. 硬件原型样机
      • 9.2.6.2. 硬件功能样机
      • 9.2.6.3. 硬件小批量试产阶段
      • 9.2.6.4. 软件原型样机
      • 9.2.6.5. 软件功能样机
      • 9.2.6.6. 软件小批量试产
    • 9.2.7. 原型样机测试进入和退出标准
      • 9.2.7.1. 进入标准
      • 9.2.7.2. 中断
      • 9.2.7.3. 回归
      • 详细说明
        • 
      • 9.2.7.4. 退出
        • 详细说明
          • 
    • 9.2.8. BETA测试过程
      • 9.2.8.1. BETA需求
      • 9.2.8.2. 指定BETA测试负责人
      • 9.2.8.3. 更新测试计划，制定测试方案
      • 详细说明
        • 
      • 9.2.8.4. 寻找BETA测试客户
      • 9.2.8.5. 组织测试方案与计划评审
      • 9.2.8.6. 更新BETA测试方案
      • 9.2.8.7. 查询BETA测试产品是否库存
      • 9.2.8.8. 转研发加工单生产流程
      • 9.2.8.9. BETA测试前准备
      • 9.2.8.10. 发送BETA测试产品（样品）
      • 9.2.8.11. 进行BETA测试
      • 9.2.8.12. 编写BETA测试报告
      • 详细说明
        • 
    • 9.2.9. 面向制造测试
      • 9.2.9.1. 要点
        • 面向制造测试是在验证阶段针对生产制造而进行的针对性测试，其主要目的是确保发货产品的功能性能满足规格要求，并保证大批量生产时的可制造性
        • 面向制造测试通过小批量试生产过程来保证设计的完整性，不应该有新的需求或设计方面的验证，而应针对TR5的结论，对产品进行的有针对性的专题测试，测试的形式多为抽检方式
      • 9.2.9.2. 面向制造测试主要考虑以下几个方面
        • 发货的质量要求、生产良率要求，以及量产时自动测试的效率要求
        • 面向制造测试的测试重点，包括重点测试对象和重点测试向量
        • 对测试装备的依赖关系分析及措施
      • 9.2.9.3. 面向制造测试内容
        • 面向制造测试需求
        • 设计测试方案
        • 提供测试规格
        • 面向制造测试准备的进度计划
        • 资源计划（包括人力资源、环境资源、工具等）
        • 风险分析和控制计划
        • 面向制造测试的交付件
          • 面向制造测试报告
          • 测试工具
          • 测试代码
          • 测试向量
          • 测试规格
        • 面向制造测试的进入和退出标准
          • 
    • 9.2.10. 测试度量
      • 
      • 9.2.10.1. 测试生产率
      • 9.2.10.2. 工作量偏差率
      • 9.2.10.3. 发现缺陷密度
      • 9.2.10.4. 测试问题严重性
      • 9.2.10.5. 测试用例的问题发现效率
      • 9.2.10.6. 缺陷密度
      • 9.2.10.7. 测试覆盖度量
      • 9.2.10.8. 问题漏测率
      • 9.2.10.9. 遗留缺陷密度
  • 9.3. 缺陷管理
    • 9.3.1. 缺陷模板
      • 
    • 9.3.2. 缺陷流程
      • 
    • 9.3.3. 软件测试缺陷类型
      • 
  • 9.4. 测试管理输出文档模板
    • 9.4.1. 测试策略
      • 
      • 9.4.1.1. 概述
      • 9.4.1.2. 测试综述
      • 9.4.1.3. 系统测试
      • 9.4.1.4. 人力资源及工作量
      • 9.4.1.5. 质量过程
    • 9.4.2. 测试计划
      • 
      • 9.4.2.1. 概述
      • 9.4.2.2. 测试准备
      • 9.4.2.3. 测试计划
      • 9.4.2.4. 测试用例
      • 9.4.2.5. 培训计划
      • 9.4.2.6. 其它
    • 9.4.3. 测试方案
      • 
      • 9.4.3.1. 概述
      • 9.4.3.2. 需求跟踪
      • 9.4.3.3. 测试内容
      • 9.4.3.4. 测试环境
      • 9.4.3.5. 测试用例
      • 9.4.3.6. 测试通过准则
      • 9.4.3.7. 评审报告
    • 9.4.4. 测试用例
      • 
      • 9.4.4.1. 用例编号
      • 9.4.4.2. 用例名称
      • 9.4.4.3. 需求描述
      • 9.4.4.4. 测试目的
      • 9.4.4.5. 测试类别
      • 9.4.4.6. 测试对象
      • 9.4.4.7. 用例级别
      • 9.4.4.8. 测试工具
      • 9.4.4.9. 前置条件
      • 9.4.4.10. 测试步骤/测试方法
      • 9.4.4.11. 测试预期结果
      • 9.4.4.12. 测试结果
      • 9.4.4.13. 测试结论
      • 9.4.4.14. 测试工程师
      • 9.4.4.15. 测试日期
      • 9.4.4.16. 备注
    • 9.4.5. 测试报告
      • 
      • 9.4.5.1. 概述
      • 9.4.5.2. 测试概要
      • 9.4.5.3. 测试结果及发现
      • 9.4.5.4. 测试结论
      • 9.4.5.5. 分析摘要
      • 9.4.5.6. 测试资源消耗
    • 9.4.6. 测试总结
      • 
      • 9.4.6.1. 测试主要版次
      • 9.4.6.2. 测试内容
      • 9.4.6.3. 测试遗留问题
      • 9.4.6.4. 测试结论
      • 9.4.6.5. 建议
  • 9.5. 测试评审要素
    • 9.5.1. 测试策略评审要素
      • 
    • 9.5.2. 测试计划评审要素
      • 
    • 9.5.3. 单元测试计划评审要素
      • 
    • 9.5.4. 集成测试计划评审要素
      • 
    • 9.5.5. 系统测试计划评审要素
      • 
    • 9.5.6. 测试用例评审要素
      • 
    • 9.5.7. BETA测试评审要素
      • 
  • 9.6. 测试管理常见的问题对策
    • 9.6.1. 是否需要独立的中试部
      • 
    • 9.6.2. 如何解决测试和研发的冲突
      • 9.6.2.1. 尽早开始合作。如果只在项目测试环节测试人员才出现并寻找缺陷，测试人员会遇到阻力。产品开发的质量被完全处于局外的人所挑战，此时测试人员就会被当作威胁而不是支持。测试人员在设计初期能够参与，这样研发人员把测试人员的工作看作是帮助自己提高工作质量的一种方式，测试人员也不再是挑毛病、缺陷的局外人
      • 9.6.2.2. 责任与权利相符。测试人员在初期设计阶段能够参与或提供反馈，不能让测试部门夹在中间，责任很大而权力很小或没有
      • 9.6.2.3. 带着质量意识研发。通常研发人员和测试人员在质量的含义上有着不同的见解，不要指望能找到一个永远正确的答案，测试驱动式开发是一种流行的在初期就引入质量管理的开发模式，它使测试及质量保障与每个功能特性的设计结为一体
      • 9.6.2.4. 只有主管能发动和结束“战争”。如果在开发团队中发生冲突，就要从主管身上找原因。主管们应敢于进取，明智地承认这些问题，并带领双方制定一个如何改变的协作计划
    • 9.6.3. 如何进行外部测试
      • 9.6.3.1. 外部测试指国家管理机构（国家工商行政管理局、国家质量监督检验检疫局、行业管理机构等）、客户要求的、组织的或委托组织的对公司的产品、技术、解决方案所做的测试，或公司主动发起的涉外测试，以及公司在第三方权威测试机构进行的委托测试
      • 9.6.3.2. 外部测试的四个阶段
        • 
        • 测试需求阶段
          • 
        • 测试准备阶段
          • 
        • 正式测试阶段
          • 
        • 测试结果跟踪阶段
          • 
    • 9.6.4. 常见的测试风险有哪些
      • 
      • 9.6.4.1. 软件模拟环境测试方法的局限性
      • 9.6.4.2. 功能点不全
      • 9.6.4.3. 功能点不细
      • 9.6.4.4. 验证策略不完善
      • 9.6.4.5. Corner case和Error case 太少
    • 9.6.5. 测试管理的提升路径有哪些
      • 
      • 9.6.5.1. 开展系统测试工作
      • 9.6.5.2. 开展专项测试、测试工具引人
      • 9.6.5.3. 需求可测试分析、集成测试、建立测试标准
• 10. 工艺管理
  • 10.1. 工艺管理常见的问题
    • 10.1.1. 大量借用的图纸导致工艺人员需要花费很多时间找图纸、借用图纸，影响效率
    • 10.1.2. 手工做mBOM占用工艺人员大量时间
    • 10.1.3. 设计资料给得晚，留给工艺人员的时间不够
    • 10.1.4. 工艺文件需要不断根据材料改善、设备改善、技术改进进行相应的完善
    • 10.1.5. 设计与工艺协同出问题，在图纸会签完成后，由于某种原因设计人员对图纸进行更改，但没有告知工艺部会签人员重新会签，直接将图纸下发制造单位进行生产，制造单位容易出现问题，且责任不明确
    • 10.1.6. 衍生产品多，重复修改多份作业指导书和其他工艺文档
    • 10.1.7. 在工装模具的设计过程中，因为没有标准的模具库，将会出现设计人员的重复设计，降低设计人员的工作效率
  • 10.2. 工艺组织
    • 
    • 10.2.1. 工艺技术部
    • 10.2.2. 综合技术部
    • 10.2.3. 资产管理部
    • 10.2.4. 质量检查部
  • 10.3. 工艺管理流程
    • 10.3.1. 工艺管理流程
      • 10.3.1.1. 工艺管理流程
        • 
      • 10.3.1.2. 工艺管理流程描述
        • 定义产品包需求
        • 产品工艺性审查/分析
        • 工艺方案设计
        • 工艺路线设计
        • 详细说明
          • 
        • 工艺文件设计
        • 工装设备准备、工艺布局设计、检测方案
        • 材料定额/工时定额
        • 功能样机试制
        • 工艺验证与改进
        • 组织产品技术鉴定，设计批产工艺方案
        • 批产技术服务
        • 详细说明
          • 
    • 10.3.2. 总装工艺流程
      • 
      • 10.3.2.1. 作业指导书编制启动
      • 10.3.2.2. 作业指导书编制
      • 10.3.2.3. 作业指导书验证
      • 10.3.2.4. 作业指导书完善
      • 10.3.2.5. 作业指导书确认
    • 10.3.3. 总装工艺更改流程
      • 
      • 10.3.3.1. 更改启动
      • 10.3.3.2. 判断工艺是否需要更改
      • 10.3.3.3. 作业指导书更改
      • 10.3.3.4. 作业指导书确认
    • 10.3.4. 钣金工艺流程
      • 
      • 10.3.4.1. 作业指导书编制启动
      • 10.3.4.2. 作业指导书编制
      • 10.3.4.3. 作业指导书验证
      • 10.3.4.4. 作业指导书确认
    • 10.3.5. 钣金工艺更改流程
      • 
      • 10.3.5.1. 更改启动
      • 10.3.5.2. 判断工艺是否需要更改
      • 10.3.5.3. 作业指导书更改
      • 10.3.5.4. 模具更改
  • 10.4. 工艺管理专题
    • 10.4.1. 工艺文件设计要求
      • 
      • 10.4.1.1. 专用工艺规程（卡片）
      • 10.4.1.2. 典型工艺规程（卡片）
      • 10.4.1.3. 成组工艺规程（卡片）
      • 10.4.1.4. 工艺守则
    • 10.4.2. 工艺资源
      • 10.4.2.1. 常见的工艺资源包括工作场地（车间、工段、外协单位），设备，工装夹具，工具（刀具、量具等），原材料/辅料资源，工时定额资源，标准工序过程、标准技术要求、标准工步等。
    • 10.4.3. 工装管理
      • 
      • 10.4.3.1. 工装计划
      • 10.4.3.2. 工装设计
      • 10.4.3.3. 工装制作
      • 10.4.3.4. 工装验证
      • 10.4.3.5. 工装周检
      • 10.4.3.6. 工装封存
      • 10.4.3.7. 工装报废
    • 10.4.4. 工艺验证
      • 
      • 10.4.4.1. 验证准备
      • 10.4.4.2. 验证内容
      • 10.4.4.3. 实施验证
      • 10.4.4.4. 验证总结与审定
      • 工艺验证指新造、检修、改造产品的工艺的验证。凡需批量生产的新产品，应通过样机（样件）、小批或中批试制进行工艺验证。产品结构重大改进，产品工艺重大改进指工艺方案、工艺路线或生产工艺条件（场地、设备、工装等）发生重大变化。生产线较长时间停产后恢复生产时，应进行工艺验证
    • 10.4.5. 试制任务管理
      • 10.4.5.1. 试制任务难以保证质量和交期的原因
        • 生产排期干扰，优先量产订单
        • 工艺时间由工艺人员根据图纸中的技术要求和技术难度来定。图纸没有得到生产人员确认，不知道工作量大小
        • 研发部门的前期工作没有做好，导致在制作过程中对图纸变更频繁
        • 工厂现有设备条件下加工出来的零件存在达不到图纸的技术要求，需要跟技术部门沟通让步放行
        • 研发部门设计时不了解工厂的物料状况、生产设备，很多设计出来的产品不能够很好地利用一些现有的物料，造成申请的物料一大堆，而且产品变更频繁，导致很多物料利用率低
• 11. 问题及工程变更管理
  • 11.1. 常见的变更问题
    • 11.1.1. 手工管理变更或者使用OA管理变更通常的问题有：
      • 11.1.1.1. 变更影响的范围需要设计工程师估计确定，容易漏掉需要变更的数据
      • 11.1.1.2. 设计变更执行的对象来源不确定，设计资料不一定是从文控获取的
      • 11.1.1.3. 变更对象、步骤依靠个人经验判断，或者变更流程没有形成闭环，问题难以跟踪落实，流程无法追溯
      • 11.1.1.4. 对变更的分析和决策不足，直接根据“更改通知单”开始变更
      • 11.1.1.5. 变更影响到的数据没有和变更流程关联起来
      • 11.1.1.6. 为了保持生产能继续或其他原因先紧急更改，但数据往往不能随后得以更正
      • 11.1.1.7. 难以执行已有流程，存在设计变更执行之后再申请变更请求，使得变更请求流于形式
      • 11.1.1.8. 变更活动执行难以有效跟踪，无法追踪变更执行进度
      • 11.1.1.9. 变更流程过于复杂，更改评审流程效率低下
      • 11.1.1.10. 所有变更都需要经过这个变更流程，没有复杂变更和简易变更的概念
      • 11.1.1.11. 同样的问题重复发生，增加产品的研发成本，难以进行变更知识重用
  • 11.2. 变更流程
    • 11.2.1. 变更请求
      • 
      • 11.2.1.1. 提交变更申请
      • 11.2.1.2. 审核、指定变更分析小组
      • 11.2.1.3. 分析变更影响
      • 11.2.1.4. 变更影响、汇总评估变更决策
    • 11.2.2. 变更通告
      • 11.2.2.1. 变更通告申请、指定变更实施人
        • 
      • 11.2.2.2. 变更通告审核
      • 11.2.2.3. 变更任务实施及验证
      • 11.2.2.4. 变更审计、关闭
      • 详细说明
        • 
  • 11.3. 变更团队角色
    • 
    • 11.3.1. LCCB(PDT经理或SE)
    • 11.3.2. CCB(项目级/决策级)
    • 11.3.3. 配置管理员
    • 11.3.4. 变更申请人
    • 11.3.5. 变更分析人
    • 11.3.6. 项目经理/变更负责人
    • 11.3.7. 变更实施人
  • 11.4. 问题管理
    • 11.4.1. 企业产品常见的问题现状分几个阶段
      • 11.4.1.1. 第一阶段
        • 是发货、召回时“救火”搞定。“救火”的人好像很重要、很忙，陶醉在忙碌的“救火”状态下，其实是自己水平低，弄出问题。
      • 11.4.1.2. 第二阶段
        • 是产品开发过程中把缺陷、问题、故障搞定。
      • 11.4.1.3. 第三阶段
        • 是设计不错问题，真正水平高的人做的东西没有问题。
      • 司不能提拔制造事端并平息事端的人，不然容易打击真正在前期把方案、计划做好的人，一次性做好的人容易被遗忘
    • 11.4.2. 问题定级标准
      • 11.4.2.1. 致命
        • 
      • 11.4.2.2. 严重
        • 
      • 11.4.2.3. 一般
        • 
      • 11.4.2.4. 提示
        • 
    • 11.4.3. 问题流程
      • 
  • 11.5. 变更请求
    • 11.5.1. 变更类型
      • 11.5.1.1. 简单变更
        • 特点是简单、影响面小，不需要复杂的审批环节，走快速通道，占80%左右
      • 11.5.1.2. 复杂变更
        • 特点是复杂、影响面大，需要进行严格的审批（包括经过变更审阅委员会、变更执行委员会的审批），走完整通道，占20%左右
        • 对关键工艺和技术参数等的重大更改，进入小批生产的产品变更，通用件的变更，重大变更（如成本分析在3000元以上）变更时必须选择复杂变更通道
    • 11.5.2. 变更原因
      • 11.5.2.1. 常见的变更原因
        • 客户抱怨或者客户要求
        • 安全事项
        • 设计失误
        • 修改物料描述（如漏尺寸）
        • 工艺改进
        • 贯彻标准（如材料、标准件及外购件的改变）
        • 质量提高
        • 性能优化
        • 降低成本
        • 文档事项
        • 改进产品
        • 其它
    • 11.5.3. 变更分类
      • 
    • 11.5.4. 变更物料的处理
      • 11.5.4.1. 在变更请求时要慎重考虑已制品和在制品的处理可能性，工艺装备的利用和制造的可能性，外购器材及原材料供应和保证情况，考虑被更改件对其他借用件的影响（先查询，确认图样是否存在借用关系），产品是否纳入国家强制性产品认证管理，对开发和生产交货期的影响，对产品成本的影响
      • 11.5.4.2. 若变更的零部件经查询后有借用者，则必须经借用者确认。对于已进入正常生产的产品进行变更时，应和有关部门包括生产部门、采购部门和营销部门进行必要的联系，
      • 11.5.4.3. 对ERP已制品库存情况必须进行处理，处理意见有以下几种
        • 报废处理，即对以往的库存物品或再制品不再继续使用，进行报废处理
        • 返修处理，即对库存物品或在制品进行返修后，可继续使用的处理
        • 限期处理，即从某一特定时间或期限内可使用库存物品的处理
        • 被借用件图样的变更：被借用件图样的更改原则上应不破坏借用关系，在变更请求过程中，若变更图样经借用者确认同意变更，被借用件图样照常变更。若变更图样经借用者确认后，不同意更改，则借用件原图保留不改，供原借用者继续借用，被借用者将要更改的图样重新制图，另编新的图样代号及编码，并将原图替换
    • 11.5.5. 变更请求模板
      • 
      • 11.5.5.1. 变更请求编号
      • 11.5.5.2. 变更请求名称
      • 11.5.5.3. 变更请求发起人
      • 11.5.5.4. 变更请求原因
      • 11.5.5.5. 变更的初步分析
      • 11.5.5.6. 变更的数据
      • 11.5.5.7. 变更请求审批
      • 11.5.5.8. 变更受影响部门
      • 11.5.5.9. 变更请求时间
    • 11.5.6. 变更请求评审流程
      • 11.5.6.1. 设计人员提交，项目负责人审核（决定是否为重大变更），工艺审核，如果重大变更需要部门经理，采购和生产负责人审核。
  • 11.6. 变更通告
    • 11.6.1. 变更通告模板
      • 
    • 11.6.2. 变更通告内容
      • 
  • 11.7. 变更任务
    • 11.7.1. 物料变更
    • 11.7.2. 3D、2D图纸变更
    • 11.7.3. 测试验证
    • 11.7.4. 工艺文档修改
    • 11.7.5. 作业指导书
    • 11.7.6. 工艺路线
    • 11.7.7. 处理库存品
    • 11.7.8. 在制品，处理采购品
    • 11.7.9. 外协供应商图纸
    • 11.7.10. 更新供货周期
    • 11.7.11. 修改说明书
    • 11.7.12. 技术手册和检验规范
    • 11.7.13. 处理宣传资料
    • 11.7.14. 处理已打印的纸质图纸
  • 11.8. 工程变更常见的问题对策
    • 11.8.1. 如何保证问题不重复发生
      • 11.8.1.1. 形成问题库，在产品的每个开发阶段不断地查看问题库
      • 11.8.1.2. 修改评审要素表，形成新的评审要素表
      • 11.8.1.3. 经验分享，不定期举行项目的经验分享，传达其他项目出现过的问题
    • 11.8.2. 如何减少变更
      • 11.8.2.1. 提高需求的准确度，减少需求变更
      • 11.8.2.2. 提高开发过程中的数据和流程质量
      • 11.8.2.3. 定期的统计分析变更，找到导致变更的常见原因改善并跟踪
        • 变更原因统计表
          • 
    • 11.8.3. 变更过程控制评审要素
      • 11.8.3.1. 变更过程控制
        • 
• 12. 研发项目管理
  • 12.1. 项目管理常见的问题
    • 12.1.1. 综合管理
    • 12.1.2. 范围管理
    • 12.1.3. 时间管理
    • 12.1.4. 成本管理
    • 详细说明
      • 
    • 12.1.5. 质量管理
    • 12.1.6. 人力资源管理
    • 12.1.7. 沟通管理
    • 12.1.8. 风险管理
    • 12.1.9. 采购管理
    • 12.1.10. 干系人管理
    • 详细说明
      • 
  • 12.2. 项目整合管理
    • 项目整合管理包括制定项目章程、制定项目初步范围说明书、制定项目管理计划、指导和管理项目执行、监控和控制项目工作、整体变更控制、项目收尾等工作
    • 12.2.1. 立项管理常见的问题
      • 12.2.1.1. 项目任务书没有规范统一，项目目标不清晰
      • 12.2.1.2. 项目任务书、产品规划书之间的信息关联设计不一致
      • 12.2.1.3. 项目启动主线不清晰，项目分类、项目编号、项目信息和成员角色规则不统一
      • 12.2.1.4. 立项与启动混淆，项目启动缺少标准化过程，缺少要调用资源必须有明确Kickoff的意识
      • 12.2.1.5. 项目启动时，没有明确同时配套的资源分配，导致跨项目资源冲突
      • 12.2.1.6. 产品企划、技术规划没有按照项目化来运作，导致跨部门资源配合不及时
    • 12.2.2. 项目类型及编号
      • 12.2.2.1. 类型
        • 
        • 全新研发类项目
          • 全新研发类项目指在产品平台的基础上开发的对外销售的新产品系列
        • 派生产品类项目
          • 派生产品类项目指在产品平台或产品开发的基础上针对市场需求、特定应用、工程反馈、产品缺陷、技术改进等因素进行开发的派生产品，可单独销售
      • 12.2.2.2. 编号
        • 项目编号建议为项目类别2位+年号2位+流水号3位
      • 12.2.2.3. 项目立项评审会议
        • 项目经理启动项目前，提前三天将市场评估报告、项目可行性分析报告和项目任务书提交给项目组所有成员熟悉项目任务，确定召开项目启动会议的时间和地点
        • 项目经理主持召开项目启动会议，明确项目组组成成员、项目的范围和目的、项目的任务、项目的各阶段的周期、项目实施成本、项目的输出、执行项目的原则和要求等
        • 各成员无异议后，项目经理宣布项目正式启动
        • 如有异议，项目经理负责进行问题确认，明确后项目才能正式启动
        • 会议评审内容
          • 明确项目组组成成员
          • 项目的范围和目的
          • 项目的任务
          • 项目的各阶段的周期
          • 项目实施成本
          • 项目的输出内容
          • 执行项目的原则和要求
      • 12.2.2.4. 项目开工会
        • 项目经理介绍项目目标，宣读项目任务书
        • 研发负责人宣读项目组任命
        • 项目组成员相互介绍
        • 项目经理回顾前期阶段工作（可选）
        • 项目阶段流程简要介绍，交付件介绍（可选）
        • 项目经理明确项目阶段计划、项目绩效考评、日常沟通方式
        • 项目风险介绍
        • 领导动员
      • 12.2.2.5. 研发项目监控
        • 
        • 总体监控
        • 计划监控
      • 12.2.2.6. 项目结项管理
        • 项目经理进行项目进展整体状况分析、成本统计分析、项目组人员及考核总结、产品质量及开发方法、文档质量的完成情况遵循度分析
        • 项目组成员根据项目总结模板完成项目总结报告
        • 统计项目相关的问题和输出的经验、教训、典型案例信息，为项目评价提供客户绩效数据，也便于查询、重用、统计分析。经验知识评审入库
        • 项目经理对成员的绩效表现给出客观评价，有效落实给项目的授权，强化项目经理的领导力，为员工绩效评价积累客观支撑数据
        • 召开项目总结会议，分享、交流、表彰
        • 将资源释放、财务关闭、经验总结、绩效评价、项目关闭等收尾工作一体化完成，做到有始有终
        • 将历史失败教训与流程、体系改进关联起来，调整项目模板、风险经验表等文件
    • 12.2.3. 项目范围管理
      • 项目范围，包括项目的最终产品或服务以及为实现该产品或服务所需要做的各项具体工作。所以从这种意义上讲，项目范围的确定就是为成功地实现项目的目标，规定或控制哪些方面是项目应该做的、哪些是不该做的，也就是定义项目的范畴。
      • 12.2.3.1. 项目范围的界定
        • 就是将主要的项目可交付成果分解为较小的且更易于管理的单元，即形成工作分解结构（WorkBreakdownStructure），简称WBS。项目范围的界定
      • 12.2.3.2. 项目范围的界定目的
        • 便于项目的具体分工，明确各成员的权、责、利，提高对成本、时间及资源估算的准确性，为绩效测量与控制定义一个基准计划，便于进行明确的职责分配。
      • 12.2.3.3. 项目范围界定的工作内容
        • 进行项目范围界定时要充分研究客户的需求建议书，将项目范围内的工作分解为具体细致明确的执行单元，绘制工作分解结构图，编写项目工作分解结构，建立起描述项目责任落实情况的项目组织分解结构，建立起描述资源配置情况的项目资源分解结构。
      • 12.2.3.4. 项目目标的原则
        • 
        • 活动定义
        • 活动排序
        • 活动工期预计
        • 进度计划制定
        • 进度控制
    • 12.2.4. 项目时间管理
      • 12.2.4.1. 项目计划管理的5个步骤
        • 项目计划安排需要考虑业务模式，技术难度，业务重要性，建议经过一定时期规范化项目运作，积累历史数据，形成基本的标准工期、工时
        • 活动定义
        • 活动排序
        • 活动工期预计
        • 进度计划制定
        • 进度控制
        • 详细说明
          • 
      • 12.2.4.2. 提高项目计划能力
        • 打个比方，想要把一个箱子推到一个地方，为了到达那里，是不是要估计一下按什么路线推、要推多快？然后开始推，推的过程中要不时地和原先的计划比较，需不需要调整路线和速度。这个估计就是计划。计划的目标不是消除错误，而是让所有错误变成一堆经过细心规划后的小错误。研究四种设计方案，最终放弃三种，最多不过是三个小错误而已，但因没有做好设计就可能造成三个大错误，且要将产品开发过程重新执行三次，浪费人力、物力、时间。
        • 计划是为组织确定目标、实现目标的战略与手段、步骤、程序的过程
        • 计划是对项目团队未来工作的一种估计，没有人能够准确说出项目几个月后的情况。计划没有变化快，这句话说得很对，它提醒我们没有计划是不行的，不具备可执行性的计划也是不行的。
        • 计划不是拿来炫耀的，是要用来执行的。我们仍然逃不开现实和计划的背离的问题。我们虽然对预计一年后的事情把握不大，对把握项目组成员在想什么也比较难，但是如果想想未来两周内的事情应该还是能够估计得八九不离十的。很多人不愿意做计划或者把计划做得过细，大致有以下三个误解
          • 工作简单，制定计划纯属浪费时间。
            • 其实是对项目管理认识不够，还不能看到一个合理的计划为工作效率带来的贡献。而现实却是工程师觉得是简单的工作，不愿意再“多此一举”。笔者一向不崇尚复杂的管理模式，所有的管理措施是否简单有效？没有完美的管理，只有有效的管理。但是也不能没有管理，完全采用放羊模式，那也容易出现问题。
          • 计划没有用，制定了计划也没有办法按照计划执行。
            • 主要是一个方法和能力的问题，没有科学的方法和丰富的经验，的确是很难做好计划。能力的问题只能靠积累，可以借鉴的是科学的方法。
          • 将计划视为重中之重，花费大量的时间、人力讨论确认计划，做出来的计划期望事无巨细，否则觉得项目就有很大风险。
            • 主要是项目组成员要有相互信任，凡事做过了优点就变成了缺点，保持中间的那个度，保证计划考虑到了大的风险，也给予一定的灵活调整空间。
        • 项目经理的核心工作之一就是计划，计划的好坏，直接体现项目经理管理能力
          • 计划活动安排原则
            • 项目计划的活动控制在150个以内，否则就建议分层计划管理
            • 整体计划列出3～6个里程碑，分段监控；
            • 单个活动不宜过粗，也不宜过细，3～5天为宜；
            • 计划需要经过充分的讨论和沟通；
            • 计划需要预留一定余量；
            • 参考历史经验项目列出标准活动和工期；
            • 列出不同类型的项目计划模板和裁剪规则；
            • ♢建立项目基线，按阶段里程碑监控项目执行的差异。
        • 项目管理过程中常见容易忽略的活动
          • 项目/工作开始前的准备
          • 技术/业务培训
          • 评审和缺陷修正
          • 系统集成与调试
          • 处理变更请求
          • 组内协调/组间协调
          • 测试设计/环境搭建/用例和脚本实现
          • 回归测试/缺陷修正
          • 原型制作/需求确认/产品演示
          • 项目汇报
          • 项目文档/技术文档撰写
    • 12.2.5. 项目成本管理
      • 
      • 12.2.5.1. 人力资源费用
      • 12.2.5.2. 模具费用
      • 12.2.5.3. 材料费用
      • 12.2.5.4. 测试认证费用
      • 12.2.5.5. 委外设计费用
      • 12.2.5.6. 其他公摊费用
      • 制定项目任务书时确定以上项目成本预算信息，项目经理需要在项目过程中实时查看这些费用信息，与预算信息进行不断的比对，超出或严重超出项目成本时需要对项目进行变更/暂停/终止。在技术评审和业务决策评审时也需要查看项目的实际成本信息，以便进行相应决策。
    • 12.2.6. 项目质量管理
      • 12.2.6.1. 如果项目经常拖期，计划偏差大，需求经常变化，质量管理就无从谈起
        • 做好项目管理基础后才能考虑项目质量管理
      • 12.2.6.2. 三个方面
        • 过程稽核
          • 过程稽核针对项目进度以及对核心组和外围组周报告、会议出勤率、产品开发资料库、网上办公资源及各阶段详细工作计划中定义的任务的交付件，让项目组成员了解进度，及时发现偏差并采取有效措施修正。指标包括周报告及时率及质量、交付件及时率、交付件质量等。
        • 交付件稽核
          • 交付件稽核主要针对交付件的质量，交付件包括三类：各阶段具体任务的交付件、里程碑交付件、与产品质量密切相关需质量负责人格外关注的交付件。与产品质量密切相关需PDT中的质量代表格外关注的交付件包括设计FMEA报告、测试计划、测试报告、过程FMEA报告等。
        • 项目质量稽核
          • 项目质量稽核包括持续时间偏差、进度偏差等。除此之外，还要汇总上一阶段中每周的稽核报告
      • 12.2.6.3. 项目审计
        • 项目过程中的审计项
          • 
          • 项目策划
          • 立项过程
          • 奢求开发与管理
          • 项目跟踪与监控
          • 技术评审会议
          • 设计和编码
          • 质量保证过程
          • 测试和产品集成
          • 产品发布
          • 配置管理
          • 变更过程
          • 结项过程
          • 组织过程改进
          • 组织过程聚集
          • 组织培训过程
        • 项目过程审计内容
          • 
          • 产品数据
          • 项目过程方面
          • 流程执行审计
      • 12.2.6.4. 项目审计报告示例
        • 审计目的
          • 
        • 审计范围
        • 审计内容
        • 审计周期
        • 审计结果
        • 详细审计报告
        • 详细说明
          • 
      • 12.2.6.5. 产品和项目度量
        • 规模
        • 工作量
        • 进度
        • 生产率
        • 稳定度
        • 详细说明
          • 
        • 质量保证
        • 市场竞争力
        • 财务
        • 详细说明
          • 
        • 质量保证
        • 其它
        • 详细说明
          • 
      • 12.2.6.6. 项目报表
        • 项目总体报表
          • 
        • 项目费用汇总分析报告
          • 
        • 项目进度分析综合报告
          • 
    • 12.2.7. 项目资源管理
      • 资源管理主要是要做好资源需求计划，保证项目进度如期推进的同时资源不浪费
      • 12.2.7.1. 项目资源管理步骤
        • 
        • 报告人力资源需求
        • 分析人力资源需求
        • 执行人力资源需求
        • 注意事项
          • 需要从制度、绩效评价上，驱使项目经理针对资源要精打细算，节约钱，干成事。
          • 从而积累历史数据，形成基本的标准工期、工时，提升项目经理计划执行能力、资源分析能力，从而提高资源需求计划的合理性。
    • 12.2.8. 项目沟通管理
      • 12.2.8.1. 项目沟通
        • 沟通是信息传递与理解的过程，超过80%的人际冲突和工作失误来自沟通不畅
        • 目的
          • 收集和接收信息、分摊责任、鼓舞士气、实施计划等，
          • 基本的目的是传达、了解、谅解、理解。
          • 需要减少沟通的理解误差和无谓的人为消耗。
        • 信息在传递过程中会失真，传递信息的人想表达100%，表达出来80%，接收信息的人听到的变成60%，理解的变成了40%，记住可能就只有20%了
        • 有效沟通存在的障碍
          • 从主观角度去理解（想当然），听不进不同意见（武断），单向沟通（只想别人听你的），跳跃性的推论（过早判断），语言的理解差异，个人不良的情绪，时机把握不好，对人不对事。
      • 12.2.8.2. 会议有效沟通的关键要素
        • 
        • 会前
        • 会中
        • 会后
      • 12.2.8.3. 与不同角色沟通注意点
        • 
        • 领导者
        • 下属
        • 客户
    • 12.2.9. 项目风险管理
      • 12.2.9.1. 前言
        • 制定风险管理流程，强化风险意识，项目组全员参与，积累经验和教训
        • 据项目的实际情况和LPDT的管理经验，对每个识别出来的风险确定优先级，制定总的项目风险经验表，包括阶段、活动、风险、严重性、后果、预防、解决方案等
        • 对高优先级风险进行严格的评审，修正风险等级。所谓高优先级风险是指那些高影响且中概率、高影响且高概率、中度影响且高概率的风险。
      • 12.2.9.2. 风险跟踪表
        • 定期分析风险，提前识别，随时调整对风险的预估
        • 项目周会、月度会议上应专门讨论并跟踪，按项目风险经验表中的办法进行应付
        • 对所标识的风险及其排序、风险管理和响应计划取得一致认识
        • 纠正，形成项目的活动和措施项
        • 明确响应计划的触发条件
        • 明确责任人，更新项目风险经验表和模板
        • 顶级风险应每周向PDT经理报告
        • 总结和预防，提高项目经理的风险识别能力和应对能力
      • 12.2.9.3. 风险管理过程
        • 
        • 风险识别
        • 风险量化评估
        • 风险应对计划制定
        • 风险监控
      • 12.2.9.4. 12种项目风险库
        • 市场风险
        • 需求风险
        • 技术风险
        • 详细说明
          • 
        • 项目计划风险
        • 安全风险
        • 技术支持风险
        • 制造风险
        • 物料采购风险
        • 客户风险
        • 组织和人员风险
        • 设计和实现风险
        • 过程风险
        • 详细说明
          • 
      • 12.2.9.5. 风险管理模板
        • 
        • 风险序号
        • 产品级/模块化级
        • 类风险型
        • 发生概率
        • 影响等级
        • 风险等级
        • 风险影响描述
        • 风险响应措施
        • 风险责任人
        • 风险状态
        • 计划解决时间
    • 12.2.10. 干系人管理
      • 12.2.10.1. 识别和管理项目干系人
        • 研发项目干系人一般是积极参与研发项目，其利益在研发项目执行中或者成功后受到积极或消极影响的个人和组织。
        • 技术研发项目管理队伍必须识别研发项目干系人，确定他们的需求和期望，然后对这些期望进行管理并施加影响，以确保研发项目的成功。
        • 主要的研发项目干系人包括
          • 研发项目经理：负责管理研发项目的个人
          • 客户：使用研发项目产品的个人或组织
          • 研发项目发起者：执行组织内部或外部的个人或团体，他们以现金和实物的形式为研发项目提供资金资源，一般指IPMT团队
        • 管理研发项目干系人的各种期望实现有时比较困难，这是因为各个研发项目干系人常有不同的目标，这些目标可能会发生冲突。不同的人员从不同的角度定义新产品成功的标志
          • 负责研究的副总裁注重产品是否具有领先水平的技术
          • 负责生产的副总裁注重产品具有世界水平的实践
          • 负责市场的副总裁则主要关注产品具有的新特征。
        • 这并不意味着不考虑其他研发项目干系人的需求和期望，对技术研发项目管理而言，找到合理的解决方案来满足不同方面的需求是一种最大的挑战。
          • 一般来说解决研发项目干系人之间期望的不同应以如何对客户有利为原则。
      • 12.2.10.2. 月度汇报
        • 由PDT经理组织各核心组成员每月编制PDT月报，以向IPMT和其他功能主管部门汇报
        • PDT月度报告从以下几个方面反映项目的总体实施状况，主要集中在与项目基线的对比，并分成各跨部门、研发、市场、制造等领域分别描述
        • 进度
          • 月度监控点，目前所处的状态，本周工作完成情况，下周主要工作，计划完成率的估计，后续预计的安排
        • 成本
          • 已花费的费用，与预算的执行偏差等
        • 资源
          • 人力资源的到位情况，对进度的影响，资源的利用率，仪器设备、环境物料、软件工具等资源花费和需求情况
        • 质量
          • 质量控制状况，采取了哪些措施保证项目的质量
        • 文档完成情况
        • 风险管理
        • 存在的困难和需要的帮助
        • 管理改进的建议
    • 12.2.11. 项目流程汇总
      • 12.2.11.1. 项目立项流程
        • 
        • 启动调研
        • 市场/客户需求分析
        • 编写项目任务书
        • 组建产品规划团队
        • 确定里程碑计划
        • 项目信息审查
        • 提交立项审批
      • 12.2.11.2. 项目变更流程
        • 
        • 提交变更申请
        • 变更确认与影响分析
        • 制定变更方案
        • 变更分类
        • 市场部审批
        • 产品经理审批
        • 制定变更计划
        • 变更计划审核
        • 变更实施
        • 建立项线
        • 关闭
      • 12.2.11.3. 项目试制/试产流程
        • 
        • 提出试制/试产申请
        • 反馈排产日期
        • 试制/试产审批
        • 待关闭
        • 关闭
      • 12.2.11.4. 项目风险管理流程
        • 
        • 录入风险
        • 方案制定中
        • 风险跟踪中
        • 风险待关闭
        • 风险关闭
      • 12.2.11.5. 项目暂停流程
        • 
        • 提出暂停申请
        • 审核
        • 项目暂停
        • 关闭
      • 12.2.11.6. 项目恢复流程
        • 
        • 提出恢复申请
        • 审核
        • 项目恢复
        • 关闭
      • 12.2.11.7. 项目结项流程
        • 
        • 结项申请
        • 各项信息完整性确认
        • 结项会签
        • 业务领导审批
        • 项目组成员绩效评价
        • 关闭
      • 12.2.11.8. 典型案例管理流程
        • 
        • 提交典型案例
        • 案例信息完整性确认
        • 案例价值分析
        • 案例沉淀
        • 案例价值评价
    • 12.2.12. 项目管理输出模板
      • 12.2.12.1. 项目试产报告
        • 
        • 试产日期
        • 试产数量
        • 试产问题点
        • 试产小结
      • 12.2.12.2. 项目变更单
        • 
        • 变更申请人
        • 变更描述
        • 变更原因
        • 造成的影响
        • 审批
      • 12.2.12.3. 项目总结报告
        • 
        • 项目基本信息
        • 进度完成情况总结
        • 项目质量情况总结
        • 测试工作总结
        • 项目的主要成果
        • 经验、教训总结
    • 12.2.13. 项目评审要素
      • 12.2.13.1. 项目计划评审要素
        • 
        • 计划制定
        • 里程碑
        • 需求
        • 风险
        • 资源
        • 评审
        • 质量
        • 配置
        • 度量
      • 12.2.13.2. 项目监控过程评审要素
        • 
        • 周报、里程碑
        • 日常任务完成情况
        • 风险
        • 变更
        • 度量
      • 12.2.13.3. 项目里程碑评审要素
        • 
        • 基线审计
        • 里程碑会议
        • 里程碑报告
      • 12.2.13.4. 项目风险评审要素
        • 
        • 风险管理
      • 12.2.13.5. 项目质量过程评审要素
        • 
        • 项目质量过程
      • 12.2.13.6. 项目结项评审要素
        • 结项决策
        • 项目工期情况
        • 质量
        • 需求变更
        • 详细说明
          • 
        • 规范符合性
        • 配置项的变化情况
        • 风险评估
        • 后续阶段的计划
        • 申请与移交
        • 结项评估与审批
        • 详细说明
          • 
      • 12.2.13.7. 项目配置检查要素
        • 配置管理
          • 
        • 配置管理过程
          • 
        • 配置变更
          • 
    • 12.2.14. 项目管理过程常见的问题及对策
      • 12.2.14.1. 如何看企业的项目管理水平
        • 项目管理想要做好本身不是一件容易的事情，需要管理上不断地改进和完善，不是通过上一个IT系统就能解决项目管理过程中存在的问题的。如果项目管理水平本身比较薄弱，上IT系统反而会让项目管理更糟糕。
        • 项目管理优先看以下三个问题
          • 项目经理的定位
            • 项目经理有四种层次
              • 第一层是类似项目助理的角色，由一些文员或者助理询问和跟踪项目进度，这是最低级的
              • 第二层是相对比较资深的研发工程师兼任
              • 第三层是研发部门内部有专职的项目经理，通常这些人是由资深的研发工程师转型过来的
              • 第四层是公司层面下面的项目经理，调度含研发及研发外的市场、采购、工艺和生产部门的相关人员。
              • 大多数企业还处在第一层和第二层，但一般要到第三层或者第四层才算具备管理好项目的基础条件。
          • 项目计划的合理性和颗粒度
            • 有些企业的项目计划颗粒度非常粗，只管理到大的开发阶段或里程碑节点。
            • 这样的项目计划肯定是不够的，一般而言，需要结合产品开发流程排到每周的工作，一般单个活动不超过3～5天，否则就需要继续拆分。
            • 企业还需要根据不同的项目类型将项目计划列出不同的类型，如全新产品开发项目计划、变型产品开发计划等，每种项目计划需要根据实际情况列出不可裁剪项和可选项，重点项目要求走全新产品开发项目计划，以保证质量。非重点项目或者变型产品项目活动可以裁剪，以保证效率
          • 项目是否拖期
            • 项目拖期是产品研发型企业最常见的问题之一。很多企业因为项目拖期而期望通过上IT系统解决。抱有这种想法和目标的企业，最后都很难用好项目管理软件，甚至导致项目拖期时间更长。IT系统能够帮助企业里的项目管理者管理好活动任务分发和填写确认，减少因人的记忆而出现的遗忘失误。但是如果项目拖期，本质上通过项目管理软件并不能解决项目拖期的问题。一定要找到项目拖期的根本原因，解决后再考虑使用IT系统。
        • 成功的项目管理需要什么
          • 一个项目成功的要素
            • 最高管理层的支持
            • 明确的目标和目的
            • 客户足够的参与度
            • 适合的资源承诺
            • 切实可行的计划
            • 工作努力
            • 精力集中的团队
            • 有效的交流
          • 成功的项目管理要素
            • 项目基本信息
            • 管理要素
            • 项目监控
            • 沟通
            • 团队
            • 技术
          • 如何解决项目拖期
            • 常见的项目拖期的原因
              • 需求不明确或反复更改
              • 人力资源不足
              • 项目管理能力不足
              • 供应商合作方支持不够
              • 研发技能不足
              • 其他高优先级项目影响
              • 物料延期
              • 产品质量不过关
              • 跨部门团队协作差
              • 项目管理水平落后
            • 项目经理和项目成员需要真正理解4大要素的平衡关系
              • 需求
              • 资源
              • 工期
              • 质量
            • 建议的行动
              • 保证干系人的沟通
              • 向关键路径要时间，向非关键路径要资源，拆分关键路径上的活动，实现并行，管道管理，项目优先级排序，确保重点，技术开发与产品开发有效分离
              • 化繁为简，各个击破，将周期长的项目化分成几个明确的阶段。项目越大，对项目组的管理人员、开发人员的要求越高，参与的人员越多，需要协调沟通的渠道越多，周期越长，开发人员也容易疲劳。将大项目拆分成几个小项目，可以降低对项目管理人员的要求，减少项目的管理风险，而且能够充分地将项目管理的权力下放，充分调动人员的积极性，目标比较具体明确，易于取得阶段性的成果，使开发人员有成就感
              • 如果没有更好的办法，就要辛苦一点，实时紧盯项目的进展，每天仔细检查项目组每个成员的工作。如果有问题，改不完是不能休息的。实时控制确保项目经理能够及时发现问题、解决问题，保证项目具有很高的可见度，保证项目的正常进展
              • 控制项目组的规模，不要人数太多。人数多了，沟通的渠道就多了，管理的复杂度就高了，对项目经理的要求也就高了，控制项目组的人数不要超过10人
              • 识别项目的关键路径，选择最近的、时间估算较多的关键活动（路径），实施以下措施：投入更多的人，现有的人投入更多的时间（加班），换工作效率更高的人员去做，改进工作方法和工具，提高效率，缩小项目范围或降低活动质量要求
            • 如何提高项目管理效率
              • 项目组效率低下、进度落后的一些因素
                • 项目经理不了解项目当日状态，有些项目经理根本不知道今天每个成员会做些什么、该做些什么
                • 项目经理不了解项目实情，项目经理不知道每个成员当天做了多少活、做到什么程度、还要做多久，也就不知道项目到了什么程度，还有多少工作量
                • 项目经理不知道每个人能否按期交货，项目经理只能望天收成，期望成员凭良心、凭职业道德做事，没有人能保证产品能否按期交货
                • 项目经理不知道工作的重点是什么，哪些工作是本阶段必须要完成的、哪些是可以拖后的
                • ♢项目组的沟通不顺畅，重复工作，但是彼此间却不知道
                • ♢信息不能共享，项目成员彼此之间不知道别人做得怎么样，也不知道项目整体情况到底怎么样
              • 建议工作方法
                • ♢日计划管理，列出当天需要做的事情的工作清单，每天晨会由项目经理列出每个项目成员的工作清单，并对每个工作任务标注优先级别，设定任务完成的标准，指明当日必须完成的任务，并得到责任人的承诺
                • 为任务划优先级，标出当天必须完成的事情
                • 只做最重要的事情，而不是最紧急的事情
                • 绝不拖延，计划当天必须完成的事情就一定要做完。每天下班前20分钟，由项目经理依次检查开发人员的工作，评定工作是否完成。如果有项目成员未能完成任务，一起分析任务未能完成的原因
              • 计划经常变的原因
                • 
                • 需求变更频繁
                • 计划不准备，进度异常，预估不准确
                • 资源不到位
                • 突发事件
                • 技术不确定性
                • 缺乏有效激励
                • 跨部门协同不畅
                • 核心人员变化
              • 如何管理团队中的特殊人物
                • 
                • 能力较弱的人
                • 能力突出的人
                • 过去前贡献，但是冲劲不足
                • 个人能力突出，团结合作或集体意识不强的管理人员
                • 水平很高，但是不愿带新人的员工
              • 项目审计工作量大怎么办
                • 项目审计改善点
                  •  数据的采集、分析需要不断地学习和改进，将采集到的数据真正利用起来，不仅能反映问题，还能推动问题的解决，才是数据采集的真正用意
                  • 数据收集麻烦
                  • 汇总统计、分析工作量大
                  • 采集的数据及时反映到问题上困难
• 13. 6大技术评审
  • 13.1. 技术评审（TR）
    • 13.1.1. 目的
      • 13.1.1.1. 及时发现设计中欠考虑的方面及其原因，使产品项目的选择、问题和错误尽早明朗化，避免下游阶段对前期隐藏的缺陷无法纠正或者被迫耗费巨大的人力、物力和时间才能纠正
      • 13.1.1.2. 确保在设计中考虑到所有技术风险，并且在产品设计中进行充分考虑以满足规定的产品需求
      • 13.1.1.3. 不仅评估产品技术上的成熟度，还在项目关键点上评估产品开发的状况，为产品项目的决策提供有力的依据
      • 13.1.1.4. 明确设计中存在的风险，根据评审结论可以采取相应的风险规避措施或其他具体行动
      • 13.1.1.5. 做不做是态度问题，做得好不好是能力问题
      • 13.1.1.6. 技术评审不是一种不信任机制，技术评审是为PDT和所有项目组成员服务的。利用技术评审工具，辅助PDT做出综合判断，实现业务目标
  • 13.2. 技术评审管理常见的问题
    • 
    • 13.2.1. 评审前
    • 13.2.2. 评审中
    • 13.2.3. 评审后
    • 13.2.4. 评审过程
  • 13.3. 技术评审阶段介绍
    • 
    • 13.3.1. 技术评审阶段
      • 13.3.1.1. 概念
        • TR1
          • 
      • 13.3.1.2. 计划
        • TR2
          • 
        • TR3
          • 
      • 13.3.1.3. 开发
        • TR4
          • 
        • TR4A
          • 
        • TR5
          • 
      • 13.3.1.4. 验证
        • TR6
          • 
  • 13.4. 技术评审流程
    • 13.4.1. 注意事项
      • 13.4.1.1. 技术评审需要一步步地做，先抓住关键点，如转产（TR5和TR6），然后逐步引入产品开发过程中，做细了容易形成部门墙
      • 13.4.1.2. 两个评审点之间如果超过3个月，应该增加TR。复杂和技术含量高的产品，涉及专业领域多的产品可考虑设置更多TR。通过TR评审后才能提交业务决策评审。
      • 13.4.1.3. 评审会参与者会前需要阅读相关材料，和项目组沟通，发现并及时解决问题，评审专家数量一般控制在3～6人为佳，特殊情况根据实际需要处理。
      • 13.4.1.4. 预审要充分，预留充足的预审时间，避免直接开会，评审过程要规范，不可盲目裁剪。使用评审要素表，避免遗漏检查项。
      • 13.4.1.5. 评审时主持人注意控制时间，避免漫谈和跑题，评审要对事不对人，避免人身攻击，评审会议的重点是发现问题，而不是解决问题，不能将评审会议搞成解决方案讨论大会
      • 13.4.1.6. 会议必须有结论，会后贯彻会议结论，明确责任人，跟踪问题的解决，不可不了了之
    • 13.4.2. 技术评审流程
      • 13.4.2.1. 制定评审计划
        • 
      • 13.4.2.2. 准备评审材料
        • 
      • 13.4.2.3. 技术评审审批
        • 
      • 13.4.2.4. 预审
        • 
      • 13.4.2.5. 正式评审前检查
        • 
      • 13.4.2.6. 正式评审
        • 
      • 13.4.2.7. 汇总并形成技术评审报告
        • 
      • 13.4.2.8. 评审报告会签，报告归档
        • 
      • 13.4.2.9. 关闭
        • 
    • 13.4.3. 评审团队角色
      • 13.4.3.1. 主审人
        • 
      • 13.4.3.2. PQA
        • 
      • 13.4.3.3. PDT核心组成员
        • 
      • 13.4.3.4. 评审专家
        • 
      • 13.4.3.5. IPMT
        • 
      • 13.4.3.6. 作者
        • 
    • 13.4.4. 技术评审交付件
      • 13.4.4.1. TR1
      • 13.4.4.2. TR2
      • 13.4.4.3. TR3
      • 详细说明
        • 
      • 13.4.4.4. TR4
      • 13.4.4.5. TR4A
      • 13.4.4.6. TR5
      • 13.4.4.7. TR6
      • 详细说明
        • 
    • 13.4.5. 技术评审流程的裁剪
      • 13.4.5.1. 在实际执行中主审人可以根据实际情况对评审流程进行必要的裁剪。
      • 13.4.5.2. 技术评审的裁剪应该在做项目计划时就确定下来，不应等到评审时才提出要裁剪。
      • 13.4.5.3. 分类
        • 技术评审点的裁剪
        • 技术评审要素的裁剪
      • 13.4.5.4. 两种情况
        • 删除
        • 合并
      • 13.4.5.5. 技术评审的裁剪必须遵循以下原则
        • TR1～TR3的裁剪应在Charter评审时确定下来，在CDCP做一次修正
        • TR4～TR6的裁剪应在计划阶段做项目总计划时确定下来
        • 当评审对象比较简单时，可不召开介绍会议
        • 当预审发现的问题，作者没有异议，并且主审人认为问题发现得较为充分，可不召开评审会议（此种裁剪须较为慎重）
        • 当评审对象是外观、结构手板、样机等实物时，预审无法独立开展的情况下，主审人可决定直接召开会议，裁剪预审环节
        • 当不需要专门召开解决方案讨论会议时，第三小时会议可裁剪
        • 技术评审的裁剪不能损害产品质量目标的达成
        • 确定裁剪时，需获得受影响的相关部门的认同
        • 技术评审的裁剪应与流程、活动的裁剪相匹配
        • 技术评审的裁剪应严格按规定执行，没有明确规定的原则上不允许裁剪
        • 评审要素的裁剪必须经过PQA确认才能生效
      • 13.4.5.6. 评审结论和问题跟踪
        • 评审要素有以下三个评审结论
          • 通过（GO），没有遗留问题，或者遗留问题可以在短时间内解决。遗留问题暂时不解决并不会影响下一步活动的启动
          • 有条件通过（GOwithrisk），存在遗留问题。遗留问题对后续活动的影响不大，可说明对遗留问题的处理方式，并对其进行持续跟踪
          • 不通过（NoGO），存在重大问题。如果这些问题不解决，将影响到下一步活动。此种情况下必须首先解决这些问题，并重新进行技术评审
          • 评审问题一般包括编号、问题类型、问题描述、问题等级、解决措施建议、计划解决时间、提出人、责任人等信息，问题等级参考第十一章问题定级标准
      • 13.4.5.7. 评审衡量指标
        • 评审衡量指标
          • 
          • 规模
          • 评审专家总数
          • 各阶段的工作量
          • 缺陷个数
          • 评审专家打分
          • 一次通过率
        • 评审发展的问题趋势
          • 如果发现的异常比正常的少
            • 
          • 如果发现的异常比正常的多
            • 
      • 13.4.5.8. 评审专家衡量指标
        • 对技术评审专家所提建议，项目经理必须综合评价，不能给专家随意打分。项目管理组负责对评价把关，并细化评分标准
          • 两种评分方式
            • 方式1
              • 综合排名=所提建议数量排名×30%+提建议比例排名（个人所提建议数目/参加评审数目）×30%+项目经理评价排名20%+出勤率排名20%
            • 方式2
              • 
      • 13.4.5.9. 评审报告模板
        • 
        • XXTR评审基本信息
        • 产品质量评估
        • 评审结论
        • 技术评审过程规范评估
        • 核心组成员会签记录
  • 13.5. 技术评审要素
    • 13.5.1. TR1评审要素
      • 13.5.1.1. 项目经理
      • 13.5.1.2. 市场代表
      • 详细说明
        • 
      • 13.5.1.3. 采购代表
      • 13.5.1.4. 财务代表
      • 13.5.1.5. 制造代表
      • 13.5.1.6. 服务代表
      • 详细说明
        • 
      • 13.5.1.7. 开发代表
      • 13.5.1.8. 测试
      • 13.5.1.9. 产品质量
      • 详细说明
        • 
      • 13.5.1.10. 配置管理
      • 13.5.1.11. 信息安全
      • 详细说明
        • 
    • 13.5.2. TR2评审要素
      • 13.5.2.1. 项目经理
        • 
      • 13.5.2.2. 开发代表
        • 
      • 13.5.2.3. 产品质量保证
        • 
      • 13.5.2.4. 采购代表
        • 
      • 13.5.2.5. 市场代表
      • 13.5.2.6. 财务代表
      • 13.5.2.7. 制造代表
      • 13.5.2.8. 服务代表
      • 详细说明
        • 
      • 13.5.2.9. 配置管理
      • 13.5.2.10. 信息安全
      • 详细说明
        • 
    • 13.5.3. TR3评审要素
      • 13.5.3.1. 项目经理
        • 
      • 13.5.3.2. 开发代表
        • 
      • 13.5.3.3. 产品质量保证
        • 
      • 13.5.3.4. 市场代表
      • 13.5.3.5. 采购代表
      • 13.5.3.6. 财务代表
      • 13.5.3.7. 制造代表
      • 13.5.3.8. 服务代表
      • 详细说明
        • 
      • 13.5.3.9. 工艺
      • 13.5.3.10. 测试
      • 13.5.3.11. 产品质量保证
      • 13.5.3.12. 配置管理
      • 13.5.3.13. 信息安全
      • 详细说明
        • 
    • 13.5.4. TR4评审要素
      • 
      • 13.5.4.1. 开发代表
      • 13.5.4.2. 测试代表
      • 13.5.4.3. 信息安全
    • 13.5.5. TR4A评审要素
      • 13.5.5.1. 项目经理
        • 
      • 13.5.5.2. 开发代表
        • 
      • 13.5.5.3. 采购代表
        • 
      • 13.5.5.4. 财务代表
        • 
      • 13.5.5.5. 制造代表
        • 
      • 13.5.5.6. 服务代表
        • 
      • 13.5.5.7. 工艺
        • 
      • 13.5.5.8. 测试
        • 
      • 13.5.5.9. 产品质量保证
        • 
      • 13.5.5.10. 配置管理
        • 
      • 13.5.5.11. 信息安全
        • 
    • 13.5.6. TR5评审要素
      • 13.5.6.1. 项目经理
        • 
      • 13.5.6.2. 开发代表
        • 
      • 13.5.6.3. 市场代表
        • 
      • 13.5.6.4. 采购代表
        • 
      • 13.5.6.5. 财务代表
        • 
      • 13.5.6.6. 制造代表
        • 
      • 13.5.6.7. 服务代表
        • 
      • 13.5.6.8. 工艺
        • 
      • 13.5.6.9. 测试
        • 
      • 13.5.6.10. 产品质量保证
        • 
      • 13.5.6.11. 配置管理
        • 
      • 13.5.6.12. 信息安全
        • 
    • 13.5.7. TR6评审要素
      • 13.5.7.1. 项目经理
        • 
      • 13.5.7.2. 开发代表
        • 
      • 13.5.7.3. 市场代表
        • 
      • 13.5.7.4. 采购代表
        • 
      • 13.5.7.5. 财务代表
        • 
      • 13.5.7.6. 制造代表
        • 
      • 13.5.7.7. 工艺代表
        • 
      • 13.5.7.8. 服务代表
        • 
      • 13.5.7.9. 测试
        • 
      • 13.5.7.10. 产品质量保证
        • 
      • 13.5.7.11. 配置管理
        • 
      • 13.5.7.12. 信息安全
        • 
    • 13.5.8. 评审过程检查单
      • 13.5.8.1. 评审前
        • 
      • 13.5.8.2. 预审
        • 
      • 13.5.8.3. 评审前
        • 
      • 13.5.8.4. 评审后
        • 
  • 13.6. 技术评审相关问题
    • 13.6.1. 如何提高评审效率
      • 13.6.1.1. 选择合适专家
      • 13.6.1.2. 充分准备
      • 13.6.1.3. PQA要引导会议进程，确保讨论聚焦，会议时不偏离主题和重点
      • 13.6.1.4. 系统工程师SE要善于提炼，适时总结，减少会议过程中的争论
      • 13.6.1.5. 问题修改后及时跟踪
      • 13.6.1.6. 提高和优化评审要素（Checklist）质量
    • 13.6.2. 如何做好评审
      • 13.6.2.1. 各位主审人和评审专家，尤其是技术骨干要给予足够的重视，保证有效的投入。有困难时，必须提前与主审人、相关领导协调解决
      • 13.6.2.2. 做好评审/检视计划，在项目组的月度计划中包含评审计划。尽量详细，避免资源冲突，项目经理要特别注意这一点
      • 13.6.2.3. 各阶段和类型的评审以相应的评审要素表、评审操作指导书做指导，并且确保本阶段的主要相关角色负责人都能参与
      • 13.6.2.4. 各类评审、检视过程中由主审人/检视负责人安排各位专家分工检查被审对象是否符合相关的技术规范
      • 13.6.2.5. 各评审专家应按照邮件提示，及时参与评审、反馈意见。预审是非常重要的，不能等到评审/检视总结会上才看资料
      • 13.6.2.6. 评审要素需要定期更新，由专人维护，建议季度更新，积累来自变更、客诉、研发、测试的经验
      • 13.6.2.7. PDT功能部门代表既不能“左倾”，一味考虑PDT的市场机会而不顾及对功能部门的压力，也不能过“右倾”，一味从本部门利益出发，不愿意帮助PDT经理做出综合的考虑并承担相应的责任和风险
    • 13.6.3. 如何处理功能领域代表和SE、PQA之间的争议
      • 13.6.3.1. 这些不同意见都应该作为参考信息记录在TR报告里
      • 13.6.3.2. 对于这些争议，系统工程师SE提出初步决策，并在TR会议后形成TR报告优化稿
      • 13.6.3.3. 如果其他人不同意系统工程师SE的决策，可以在评审报告提交LPDT时提请重新裁决。LPDT对整个评审报告所有建议做出最终裁决，但同时为这些决策造成的后果负责；
      • 13.6.3.4. 如果这些决策会影响业务计划，则应该提交由IPMT做出决策
      • 13.6.3.5. TR报告终稿将会发布到所有相关人员，如果评审通过后因为PDT把关不严造成严重后果，将会启动对该评审的质量回溯
    • 13.6.4. 问题和风险如何界定
      • 13.6.4.1. “风险”是没有发生但可能发生的“问题”
      • 13.6.4.2. 一个问题，可能会跟随着风险
        • 譬如，在TR4时发现一个单板因为原理图少画一个连线需要飞线才能正常工作。这里的“问题”是原理图错误，导致的“风险”是EMC测试可能无法达标。
    • 13.6.5. PQA有能力实施技术性很强的要素表自检吗
      • 13.6.5.1. PQA可以实施要素表自检。每条要素表均有对应的关联交付件，是交付件的测试、检视、评审结果，而不是技术文件本身，不存在技术细节。类似于律师找证据（如一些技术机构的报告），必要时可寻求系统工程师SE和PDT功能部门代表的协助。
• 14. 4大业务决策评审
  • 14.1. 前言
    • 14.1.1. 业务决策是从投资角度审视产品目标市场的变化和产品研发状况，决定产品研发的下一步走向，相关的技术评审作为决策的输入之一
    • 14.1.2. 决策的依据主要来源于
      • 14.1.2.1. 产品所针对的目标市场变化情况
      • 14.1.2.2. 技术评审的结果
      • 14.1.2.3. 研发工作的进度
      • 14.1.2.4. 产品研发的关键绩效指标（如质量指标）
      • 14.1.2.5. 产品的预期成本、收益
      • 14.1.2.6. 下一阶段的资源需求和投入时间表
      • 14.1.2.7. 重要市场、竞争情况和行业信息
    • 14.1.3. 决策通常有三种结果
      • 14.1.3.1. 产品达到预定阶段目标，进入下一阶段
      • 14.1.3.2. 外部形势或内部资源发生重大变化，或产品与预定目标有重大偏离致使市场机会失去，产品研发目标调整甚至放弃
      • 14.1.3.3. 产品部分关键指标未达到预定阶段目标，需要返回经过修正后再进行决策
  • 14.2. 业务决策常见的问题
    • 14.2.1. 缺乏新产品投资决策评审机制，销售导向型而不是市场导向型
    • 14.2.2. 项目立项随意，销售人员一个电话就立项研发，导致研发资源投入严重不聚焦
    • 14.2.3. 缺少决策评审把关，产品上市随意，大部分产品上市后才知道不行
    • 14.2.4. 难以汇总展现业务决策需要的支撑信息，如遗留问题的解决情况、项目目标的达成情况、项目进度偏差情况、项目预算费用的偏差情况、项目目标成本的达成情况、项目所需资源的可供给性等，从而提升业务决策的准确性、透明度
    • 14.2.5. 决策决议难以贯彻执行，并落实为具体行动计划
    • 14.2.6. 难以自动收集决策支撑信息，包括进度、风险、遗留问题等
    • 14.2.7. 难以实现决策点决策结果的自动检查，如交付物齐套性、符合性检查等
  • 14.3. 业务决策阶段介绍
    • 14.3.1. 业务决策阶段介绍如图14-1
      • 
    • 14.3.2. 业务决策阶段
      • 
      • 14.3.2.1. 概念
        • CDCP
      • 14.3.2.2. 计划
        • PDCP
      • 14.3.2.3. 发布
        • ADCP
      • 14.3.2.4. 生命周期
        • LDCP
    • 14.3.3. 注意：
      • 14.3.3.1. 全新产品不建议裁剪或合并，改进型产品CDCP和PDCP可以合并。快速成长型企业可考虑优先导入立项决策
        • 案例1
          • 案例分析：某著名手机研发制造公司，2008年有300多位研发人员，每年研发40多款手机产品，但能达到预期收入目标的也就十几款，公司年销售收入20多亿元。公司建立新产品开发决策评审委员会，在新产品开发流程中设置了产品概念决策和计划决策评审点。对于市场人员提出的新产品开发需求，先经过系统性的市场分析，如对细分市场定位、用户需求、市场容量、竞争对手分析、财务收益等角度进行分析，并对公司的资源能力进行分析，然后评审委员会正式做出决策，才能正式立项。2010年年底，公司研发管理人员翻倍，有600多人，但是公司一年新立项研发的产品数量反而减少了。2010年立项不到30款手机，但达到预期收益目标的有20多款。单个产品的销售收入额大大增加，2010年销售收入有50多亿元，2013年销售收入达160亿元。
        • 案例2
          • 案例分析：某设备研发企业主管研发副总对目前公司研发管理现状很不满意，也很困惑。他表示目前新产品开发任务和研发资源严重不匹配，公司对所有销售人员反馈的客户需求有求必应，不能说“不”。客户要什么，公司就研发什么。公司有50多位研发人员，规格产品有700多种，还有30多个产品规格研发的需求等着研发部门满足。可是许多产品竞争力不强，销售并没有上量，有的甚至只卖一两台。但据统计，公司60多个规格的产品可以贡献80%以上的年度销售收入。
        • 案例3
          • 案例分析：某灯具制造企业，200多款节能灯产品中畅销的只有30～40款，研发资源非常紧张，单个产品研发投入不足导致销售人员经常没有叫好又叫座的产品销售，好不容易有了新产品，也由于质量或者上市晚等原因错过最佳销售时间窗口。
  • 14.4. 业务决策流程
    • 14.4.1. 业务决策流程
      • 
      • 14.4.1.1. 制定评审计划
      • 14.4.1.2. 提交业务决策申请
      • 14.4.1.3. 准备评审材料包
      • 14.4.1.4. 分发评审材料，预定会议议程
      • 14.4.1.5. 会前审阅评审材料、会前沟通
      • 14.4.1.6. 内部评审会预演
      • 14.4.1.7. 组织现场业务决策会
      • 14.4.1.8. 会签并形成会议纪要
      • 14.4.1.9. 决议执行
    • 14.4.2. 评审团队角色
      • 14.4.2.1. IPMT团队
        • 
      • 14.4.2.2. IPMT主任
        • 
      • 14.4.2.3. IPMT成员
        • 
      • 14.4.2.4. PQA
        • 
      • 14.4.2.5. PDT Leader(LPDT)
        • 
    • 14.4.3. 业务决策交付件
      • 
    • 14.4.4. 业务决策报告模板
      • 
  • 14.5. 业务决策评审要素
    • 14.5.1. 立项决策ChartDCP
      • 
    • 14.5.2. 概念决策CDCP评审要素
      • 该概念阶段业务决策评审作为一个产品决策相对于其他项目而言是否具有足够的业务发展潜力？
      • 14.5.2.1. 对市场的了解
        • 
        • 是否充分了解市场，是否已明确细分市场并选出了目标市场？
        • 细分市场的特点是什么？细分市场的特点是否来源于现在的实际信息（例如销售意见、市场调查、客户意见）？
        • 选定了哪个细分市场？没有选择哪些细分市场？市场吸引力优先顺序是怎样的（外观、价格、功能）
        • 所选细分市场如何与公司的业务愿景、宗旨、目标和战略相一致？
        • 在这个市场工细分市场中，客户为什么要购买我们的产品？
        • 针对产品的市场需求是怎样获得的
      • 14.5.2.2. 产品竞争力
        • 
        • 该概念阶段业务计划真的具有竞争力吗？什么是该产品的关键竞争优势？客户做出购买的决定的驱动力是什么？是否验证了客户的需求？该产品易用性目标是什么？
        • 市场中有哪些竞争产品？如何打败它们？
        • 公司还有哪些其它产品也准备进入这些细分市场？该产品与它们有什么关系？这些细分市场的主要风险是什么？
        • PDT所有主要成员都己明确且到位了吗？
        • 如何运用客户$APPEALS来评估该产品相对相关竞争对手产品的优劣势？
        • 在市场计划中，是否己完成了发布活动及交付计划的大纲？
        • 是否制定了概要的发布预算？
        • 该产品是否使用经过签发的业务和定价模板？如不是，是否已经制定了计划来提醒相应事业部的模板变更管理部门
      • 14.5.2.3. 业务潜力（相对其它产品而言）
        • 
        • 此概念建议作为一个产品是否具有足够的业务发展潜力？
        • 该概念阶段业务计划对于本业务领域或公司来说，是否是一项战略性投资？如是，解释一下原因及谁是赞助人？
        • 该产品是否有一个合理的业务方案？
        • 预计何时能实现盈亏平衡？
        • 有何业务风险？
        • 在这个市场上还有其它哪些公司的产品？相对其它公司产品该产品包如何定位？
        • 由于该产品的推出会导致哪些产品退出该市场
      • 14.5.2.4. 开发计划
        • 
        • 是否可制定一个具有可接受的开发计划？
        • 该产品的范围和定义是否足够清晰、确定，可以转入到下一个阶段？
        • PDT的业务计划是否包含项目初步的时间进度表，以及计划阶段的目标日期和主要里程碑？
        • 有哪些主要风险及其潜在的影响？
        • 如果这是一个“关键”项目，是否给PDT指定了一句通过资格认证的项目经理或指导者？
        • 是否已屯完成计划阶段工作的主要PDT人力资源？
        • 是否可获得人力资源？他们是否具有完成下一阶段工作所需的必要技能和经验？如没有，如何获取下一步工作实施所需的资源及技能？
        • 是否已经审视过以前项目的经验、教训总结，并在制定该项目的业务计划考虑到了
      • 14.5.2.5. 分销渠道
        • 
        • 在选定的细分市场中是否有有效的销售渠道？
        • 要在确定的细分市场中取得成功，需要采取什么措施？
        • 怎样使用现有渠道来销售该产品，并获取利润？
        • 是否需要新的渠道？若需要，如何建立能够盈利的新渠道？
        • 在市场机会窗中，是否有充足的行销和销售资源来支持该产品？
        • 是否需要解决一些战略问题，例如业务伙伴、技术许可、代理商等
      • 14.5.2.6. 其它策略
        • 
        • 技术路线有什么风险？
        • 生产策略、服务策略是什么？
        • 新供应商选择有什么策略和大致计划
    • 14.5.3. 计划决策PDCP评审要素
      • 此决策阶段评审主要审核计划操作性，可行性和完整性是否可以保证开发顺利进行
      • 14.5.3.1. 开发计划
        • 
        • 有没有一个切实可选的开发计划？计划是否考虑了所有关键利益相关人的意见？
        • 在最终业务计划中列出的总体进度是否是基于对所需要的工作量的充分理解？能否抓住市场机会窗？
        • 项目范围是不是已基于市场的需求分析做了分析做了相应改变？
        • 是否制定了计划，实现执行发布和产品推出流程所要求的最终期限？如没有，发布日期推后会有什么影响？
        • 是否清晰地定义了产品和技术的各项功能、性能等指标，并根据可制造性、可测试性、应用与可服务性制定了合理、可行性的技术方案？
        • 这一产品的上市计划与公司以前的产品相比如何？与主要竞争对手相比呢？与业界最佳的相比呢？
        • 这一产品是否有一些亲的挑战性的质量目标？如果有，是什么？
        • 做出了哪些决定以在设计中使用共用部件？
        • 从以前的项目中吸取了哪些经验、教训？如何应用到本项目？
        • 是否制定了资源需求（人力资源、设备资源、环境资源、资金资源）计划，考虑了哪些例外情况？
        • 是否确定了后续阶段的PDT成员？是否分配了PDT资源？
        • 有没有更改、问题及争议管理流程？
        • 在质量、可用性及可服务性方面将会有哪些具体的投资？该产品是否有一些新的挑战性的质量目标？如有，是什么？
        • 质量计划中是否已经准确地反应了该产品的质量目标？质量计划中是否说明了应如何完成这些目标，以及它们是否符合已经过认证的ISO规范
      • 14.5.3.2. 业务潜力/财务分析
        • 
        • 这个概念是否仍有充分的业务发展潜力（相对于其它产品而言）？
        • 对产品机会的财务分析是否已经足够详细，可以对该计划进行评估（销量、投资回报率和税前收益）？
        • 是否已制定了财务分析图来描述并证明该产品能支持公司财务计划？
        • 相对于风险和所需的资源，预期的收益（市场份额、利润率和投资回报率）是否适当？
        • 相对于其它可能争夺资源的产品，该产品的优先级如何。
      • 14.5.3.3. 分销渠道
        • 
        • 为确保该业务计划迅速成功需要做什么？
        • 是否有合适的销售渠道来发布和销售该产品包？
        • 每个确定渠道的预期销量是多少？将要实施什么样的销售激励计划？
        • 销售资源有何需求，它们是否已经得到承诺？
        • 是否已为销售和支持制定了培训计划？
        • 支持结构和交付渠道是否已经搭建起来？是否有足够的技能？为确保每个分销渠道积极支持所建议的产品，需要做些什么？
      • 14.5.3.4. 产品包的竞争力
        • 
        • 对于分销渠道和客户该产品是否具有竞争力和吸引力？
        • 公司的产品相对于业界最佳，其竞争力如何？
        • 为了确保客户对我们的产品从整体上比竞争对手的更满意，已经做了哪些工作？
        • 为了证实该产品对客户的销售渠道有吸引力已经做哪些工作？
        • 为了解市场和客户购买标准已经做了什么，能否得到市场调研和客户反馈信息的支持？
        • 该产品能否如期地在发布点保持充分的竞争优势？（为什么会赢？）竞争优势能否持续保持下去？在每个挑选的目标市场将如何获取足够的市场份额？
        • 是否符合保证的质量目标？
        • 该产品是否仍然符合公司战略
      • 14.5.3.5. 风险管理
        • 
        • 对于已发现的风险有哪些风险管理计划？
        • 有哪些主要风险及风险规避措施？
        • 是否已经评估所有的风险并制定好适当的规避计划？具体是什么？
        • 自概念DCP以来发生了哪些风险变更，如何影响产品的生存与发展能力
      • 14.5.3.6. 技术评审结论
        • 
        • 技术评审的问题有没有解决？
        • 遗留的问题是否制定了合理的解决方案及处理计划。
    • 14.5.4. 上市决策ADCP评审要素
      • 14.5.4.1. 发货质量
        • 是否进行了需求追溯，以验证该产品已实现达成共识的需求？
        • 是否已实现在早期阶段确立的可用性、性能和质量目标？
        • 新产品能比得上或超过以前产品的质量目标吗？
        • 为了确保客户在该产品中比以前的产品更少碰到故障，已经做了什么？
        • 如何验证设计稳定性？有哪些迹象显示该系统已经足够稳定？
        • 该产品是否已完成了所有的外部的内部认证要求？
        • 公司的知识产权是否受到了保护，如专利方面？
        • 测试结果和客户评估结果是否保证了该产品的一般可获得性，给出证据。
        • 公司产品与业界最佳相比，竞争力如何？
        • 是否准备好了资料文档，支撑早期销售？
        • 从试用或试销售中得到什么反馈和改进？
      • 14.5.4.2. 发布和宣传推广计划
        • 是否有有效的发布和宣传推广计划？关键的市场主题和信息是什么？
        • 采取了什么措施来确保关键的组织完全投入到产品的发布之中？（公司的销售队伍、业务伙伴、独立软件开发商、媒体、顾问、任何其它相关组织）
        • 发布计划的关键要素是什么？
        • 生成和分发市场营销材料的计划是什么？
        • 从试用的客户中获取了哪些客户的参考意见
      • 14.5.4.3. 渠道搭建与支持
        • 是否已完成了渠道搭建工作？
        • 关键渠道怎样？（公司销售队伍、渠道伙伴和经销商）
        • 什么是最有可能发生的渠道冲突？有什么计划来解决这些冲突？
        • 服务支持和缺陷支持系统是否到位？
        • 是否已制定/实施了销售、应用、服务人员、客户的培训计划？
        • 在每个销售区域和每个渠道，缺陷怎样处理
      • 14.5.4.4. 风险分析
        • 业务和技术风险是否可接受？是否制定好风险规避计划？
        • 有哪些主要的、尚未解决的业务/技术风险，怎样处理？有哪些相关的规避计划，责任人是谁？
        • 所有这些风险和不确定性是否已被消除或者减少到可以接受的水平？假如没有，相关的行动计划是什么？谁是责任人。
      • 14.5.4.5. 财务分析
        • 该产品是否仍然提供足够的业务潜力（相对于其它的产品计划和竞争）？
        • 目标成本达成情况如何？
        • 该产品何时能实现盈亏平衡？与竞争产品、同类最佳及前面推出产品的比较结果是什么样的
      • 14.5.4.6. 技术评审结论
        • 技术评审的问题有没有解决？
        • 遗留的问题是否制定合理的解决方案及处理计划？
    • 14.5.5. 生命周期决策LDCP评审要素
      • 
      • 14.5.5.1. 市场
      • 14.5.5.2. 业务计划
      • 14.5.5.3. 销售
      • 14.5.5.4. 开发
      • 14.5.5.5. 售后服务
      • 14.5.5.6. 采购
      • 14.5.5.7. 支持结构
      • 14.5.5.8. 退市策略
• 15. 需求管理
• 16. 市场管理
• 17. 研发绩效
• 18. 其它专题
• 19. 研发IT系统支撑（PLM）
• 20. 专业术语解释
  • 20.1. DFM
    • 20.1.1. Design for manufacture,面向制造的设计
  • 20.2. IPMT
  • 20.3. CBB
  • 20.4. R&D
    • 20.4.1. 研究与试验发展活动
  • 20.5. IPMT
    • 20.5.1. 集成产品管理团队
      • 20.5.1.1. Integrated Product Management Team
  • 20.6. PDT
    • 20.6.1. 产品开发团队
  • 20.7. PQA
    • 20.7.1. 全称Process Quality Assurance， 即全程质量检测认证。
  • 20.8. BOM
    • 20.8.1. Bill Of Material 物料清单或产品结构清单
  • 20.9. GA
    • 20.9.1. 批量供货点
  • 20.10. 型式试验
    • 20.10.1. 型式试验（type test）即是为了验证产品能否满足技术规范的全部要求所进行的试验。
      • 它是新产品鉴定中必不可少的一个环节。只有通过型式试验，该产品才能正式投入生产，然而，对产品认证来说，一般不对再设计的新产品进行认证。为了达到认证目的而进行的型式试验，是对一个或多个具有代表性的样品利用试验手段进行合格性评定。对于通用产品来说，型式试验的依据是产品标准。对于特种设备来说，型式试验是取得制造许可的前提，试验依据是型式试验规程或型式试验细则。试验所需样品的数量由认证机构确定，试验样品从制造厂的最终产品中随机抽取。试验在被认可的独立检验机构进行，对个别特殊的检验项目，如果检验机构缺少所需的检验设备，可在独立检验机构或认证机构的监督下使用制造厂的检验设备进行。 特种设备型式试验由国家核准的特种设备型式试验机构进行，特种设备及其安全保护装置、安全部件等均需进行型式试验
  • 20.11. Beta测试
    • 20.11.1. Beta测试是一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就会进入发布阶段。
      • 验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求， 确保所开发的软件产品符合用户的各项要求。 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。
  • 20.12. DCP
    • 20.12.1. Decision Check Point的缩写，决策检测点
  • 20.13. CDCP
    • 20.13.1. 概念决策评审
  • 20.14. PDCP
    • 20.14.1. 业务计划书和产品开发评审
  • 20.15. ADCP
    • 20.15.1. 产品即将推向市场前的决策评审点
  • 20.16. LDCP
    • 20.16.1. 设置在产品生命周期即将结束时的决策评审点

工艺管理



• 1. 研发物料及BOM管理
  • 1.1. 物料编码管理
    • 1.1.1. 物料编码常见的9个问题
      • 1.1.1.1. 没有物料编码体系，使用图号标识物料。这种情况管理比较少见，但是不少企业确实还停留在这个阶段
      • 1.1.1.2. 编码里体现了过多的非物料本身的信息如版本、供应商等信息
      • 1.1.1.3. 研发不给编码，由生产部门给编码。生产部门给编码最常见的结果就是无论是新物料还是可以重用的物料，都给新编码。这样导致大量的一物多码，同时导致大量的库存
        • 公司现在需要优化这块的工作，把重用的物料，做好标准件库，提高研发效率，降低研发风险，缩短研发周期
      • 1.1.1.4. 按照产品类别分类，每个产品类别下有一套物料分类体系。有多个产品线的企业应该尽可能在公司层面统一给编码
      • 1.1.1.5. 分类标准不统一，标准化程度低
      • 1.1.1.6. 物料名称和规格填写随意性大，不统一
      • 1.1.1.7. 物料分类不清
      • 1.1.1.8. 物料扩展不够用
      • 1.1.1.9. 物料编码规则过多，长度不统一
    • 1.1.2. 物料编码6大原则
      • 1.1.2.1. 唯一性
        • 每个物料只有唯一编码，保持一种分类方法并在系统的各组成部分中保持一致
        • 唯一性是物料编码方案的基本要求，唯一性意味着可能变化的信息不能体现在编码中，如使用公司信息、供应商、客户等信息
      • 1.1.2.2. 简单性
        • 编码结构应尽可能简单，长度尽量短，可节省阅读、填写、抄录的时间和存储空间
        • 应尽量使用数字，不建议使用字母，以提高输入的效率，并减少其中的错误机会，编码里不应该有过多的信息体现
      • 1.1.2.3. 稳定性
        • 在编码时要考虑物料编码变化的可能性，尽量保持编码的稳定性，物料编码所体现出的含义不会发生大的变化
      • 1.1.2.4. 可拓展性
        • 物料编码应有一定的可拓展性，保证编码使用和更改方便
      • 1.1.2.5. 规范性
        • 编码的结构及编码的编写格式应当统一，编码的长度统一
      • 1.1.2.6. 分类性
        • 按照物料的属性、物料的数量合理分类，物料编码承载少量分类信息，分类的目的主要是为了合理分配码段，并不是为查询
    • 1.1.3. 常见的编码做法
      • 1.1.3.1. 流水码
        • 唯一性
          • 可以完全保证“一物一码”
        • 简单性
          • 编码无含义，业务人员理解和使用较困难
        • 稳定性
          • 编码与物料属性不关联，稳定性强
        • 可拓展
          • 编码方法有很强的拓展性
      • 1.1.3.2. 分类码
        • 唯一性
          • 当需编码的新物料过多时，可能出现码段不足的情况
        • 简单性
          • 易出现编码过长的现象，增加使用难度
        • 稳定性
          • 长期使用中稳定度不够，会受到其它因素变更的影响
        • 可拓展
          • 通过流水编码部分保证一定的拓展空间
        • 常见的物料编码分类是采用“大类+中类+小类+流水码”。笔者经历过的企业中大部分企业属于这种编码划分方式，也有部分企业不需要大类，直接采用“中类+小类+流水码”的方式
          • 
      • 1.1.3.3. 编码注意事项
        • 部分企业把结构类和电气类物料划到原材料里，也有部分企业类似目前的建议分类
        • 原材料划分亦有按铜材、铝材和钢材划分（材料价格敏感型建议此类划分）
        • 包装件有放在结构类里的，也有放在原材料里的，也有单独作为一类
        • 不同的企业类型需要调整中类和小类的层次，如以板卡产品为主的企业则侧重电子类物料，结构类为主的企业则侧重结构类物料
        • 成品和半成品的分类由于不同的产品差异过大，不展开描述
        • 规模大、集团化的企业管理要求高，需要更多考虑物料的可拓展性
        • 除标准中规定的，其余特殊符号不准使用，大写罗马字母中的I、Q、O不能使用
      • 1.1.3.4. 物料编码调整的5个风险
        • 需要改变所有相关作业人员的习惯，项目实施难度加大。下游物料采购、物料出入库、生产发货等涉及的单据都需要调整
        • 所有物料数据的期初导入，需要进行新旧物料编码的转换
        • 新系统中，所有关于物料数据的核对需要用到旧系统的数据时，需要人工转换核对
        • 部分物料编号已印制在对应的实物上，需要进行统一规范
        • 旧图纸因物料编码的改变需重新出图
      • 1.1.3.5. 先有图还是先有料
        • 先有图再申请料号
          • 优点
            • 编码申请时，有图纸作为评审参考，提高评审质量
          • 缺点
            • 未进行设计前评审，可能审核时才发现零部件重复设计
          • 建议
            • 建议除复杂的产品自制件采用先画图再申请物料的做法
        • 先申请料号再画图
          • 优点
            • 符合先规划再设计的理念，避免重复设计
            • 产品组件规划比较清晰
            • 减少“一物多码”，保证物料引入的合理性
          • 缺点
            • 设计过程中可能因为方案变化，而导致废喇
            • 复杂的产品实际动作情况下可能会变成一个给号的流程，达不到监管的效果。原因是在没有图纸的阶段，无法发挥审核的作用。
          • 建议
            • 标准件、外购件、电子元器件都应采用先申请料再画图的做法
        • 不管选择哪种做法，都应该在设计之前多查询和搜索，在评审的时候进行审核，保证物料引入的合理性，以减少重复工作
  • 1.2. 物料分类与属性
    • 分类的目的是为了重用
    • 1.2.1. 物料分类6大原则
      • 1.2.1.1. 自制件分类细分程度需要与实际结合，不是越细越好
      • 1.2.1.2. 为便于分类维护和使用，建议分类节点的层级不超过4级，每个分类的子类6～10个左右
      • 1.2.1.3. 相对稳定，在比较长的时期满足业务需求，不需要频繁调整
      • 1.2.1.4. 分类节点名称尽可能保证互不相同，以免产生误解及误放
      • 1.2.1.5. 分类属性数量需适中，应区别于零部件的常规属性，选择若干个最能描述和体现物料特征的属性作为分类属性
      • 1.2.1.6. 对同一物料不同归属分类节点的情况，建议建立特殊物料分类的优先级约束规则，规范物料分类细则的方法，从业务层面（设计单元）规定其归属
    • 1.2.2. 物料属性描述规范
      • 1.2.2.1. 表达式中允许用“空格”或横杠“-”来表示间隔，但一定要保证所有的“空格”或横杠“-”都是英文半角状态
      • 1.2.2.2. 规格描述规范统一，如电容，功率描述规定为1/4W一种写法，而不是0.25W
      • 1.2.2.3. 不得出现全角字符，不能出现冒号、分号、引号、撇号、句号、逗号等特殊字符
      • 1.2.2.4. 一般情况下，英文字母一律采用大写半角（特殊说明的除外）
      • 1.2.2.5. 整数值要求小数点保留到整数位，正确写法是：1u/50V，错误写法是：1.0u/50V
      • 1.2.2.6. 小数值要求小数点保留到有效数字位，正确写法是：0.1，错误写法是：0.10
      • 1.2.2.7. “频率”为Hz，（大写H，小写z）
      • 1.2.2.8. 电流单位“安培”用大写字母“A”表示，“毫安”用“mA”（小写m，大写A）
      • 1.2.2.9. 交流用AC表示，直流用DC表示，均为大写，必须写在数值的前面，如DC220V
      • 1.2.2.10. 乘号“×”用“*”（星号）代替；“*”是英文半角状态，如螺钉GB818M3*8
      • 1.2.2.11. 表示温度的℃符号，用大写英文字母“C”代替；如85℃，可以写成85C
  • 1.3. 物料相关流程及规范
    • 1.3.1. 电子料引入流程示例1
      • 1.3.1.1. 物料申请
        • 针对由于设计优化、新项目及国产化要求，创建新电子物料导入需求，选择分类、填写相关属性
          • 硬件工程师
      • 1.3.1.2. 设计审核
        • 从产品设计层面确认物料规格是否合理
          • 硬件主管
      • 1.3.1.3. 物料审核与选型
        • 确认新规格物料的制造商、技术规格及具体的物料属性
          • 器件工程师
      • 1.3.1.4. 物料商务评估
        • 由商务评估员负责联系供应商，并对供应商进行评估，主要评估因素包括：采购周期、批量投产日期、是否符合认证要求、是否符合RoHS要求、停产风险、供应商可替代性、厂家实力、价格是否有优势，可上传商务评估报告，作为审核通过的依据。备选的供应商提供样品及规格书
          • 采购认证工程师
      • 1.3.1.5. 商务确认
        • 依据上传的商务评估报告，采购经理审核此评估报告是否通过
          • 采购经理
      • 1.3.1.6. 规格审核
        • 对器件工程师选型及采购认证工程师商务确认工作的复审。审核新规格的物料是否符合器件的发展方向及公司的器件选用原则。一般此时给料号
          • 专家委员会
      • 1.3.1.7. 器件库维护
        • 库管理员对已经编码的物料维护器件库
          • 器件工程师
      • 1.3.1.8. 物料测试
        • 测试器件单体，测试人员依据电子件测试规范逐项测试样品，并记录测试数据，完成测试报告。在不具备测试条件的测试情况下，要求供应商提供测试报告，无法进行单体测试的物料，可以不上传测试报告
          • 器件工程师
      • 1.3.1.9. 物料承认
        • 新零部件申请人负责签订物料承认书，器件工程师输出《物料认可书》，关联物料和《物料认可书》《规格书》《测试报告》
          • 硬件工程师
    • 1.3.2. 电子料引入流程示例2
      • 1.3.2.1. 物料申请
        • 针对由于设计优化、新项目及国产化要求，创建新电子物料导入需求
          • 硬件工程师
      • 1.3.2.2. 规范性评估
        • 物料填写是否符合公司要求规范
          • 器件工程师
      • 1.3.2.3. 物料审核
        • 从产品设计层面确认物料规格是否合理
          • 硬件主管
      • 1.3.2.4. 商务评估
        • 确认规格物料的供应商、交期、价格等信息。提供样品及规格书
          • 采购认证工程师
      • 1.3.2.5. 正式编码填写
        • 给申请的物料正式编码
    • 1.3.3. 电子料替代失效流程
      • 1.3.3.1. 物料替代失效申请
        • 供应商发布物料停产通知，研发使用的物料出现故障，器件失效，或归一化等原因发起替代失效申请
          • 硬件工程师
      • 1.3.3.2. 物料替代失效分析
        • 分析物料是否可以替代或失效
          • 硬件工程师
      • 1.3.3.3. 替代测试
        • 替代物料进行测试
          • 测试工程师
      • 1.3.3.4. 修改设计文件
        • 修改BOM和对应的物料状态信息
          • 硬件工程师
      • 1.3.3.5. 库存、计划处理
        • 根据研发工程师的意见处理库存和在制品
          • PMC
    • 1.3.4. 物料选型规范
      • 1.3.4.1. 首先选用物料数据库中已有器件，如物料数据库无满足要求的器件，则可根据实际使用要求在供应商供货清单范围内按优选顺序选择符合要求的器件
      • 1.3.4.2. 如供应商供货清单资源仍不能满足要求，或由于性能、质量、成本、货期等因素，需要引入新的品牌，应按新器件引入流程要求引入，获得批准后，器件工程师将新品牌信息补充维护到供应商供货清单中，方可选用
      • 1.3.4.3. 新产品器件选用应至少2个以上品牌，原则上不能只选一家
      • 1.3.4.4. 尽量选择通用器件，即制造商大规模量产的标准产品或推荐选用产品，且有多家制造商具备的生产能力
      • 1.3.4.5. 不用或少用专用器件，即器件的制造商唯一且无可替换产品或需要按单生产的特殊规格器件，以及需定制的非标准器件
      • 1.3.4.6. 满足适用原则，所选器件满足应用条件即可
      • 1.3.4.7. 满足应用条件的情况下，优先选择国产器件
      • 1.3.4.8. 选择供应渠道多的器件
      • 1.3.4.9. 降额设计要适中
    • 1.3.5. 物料来料检验
      • 1.3.5.1. 尺寸规格
      • 1.3.5.2. 功能
      • 1.3.5.3. 参数测试
      • 1.3.5.4. 外观检查包装情况
      • 1.3.5.5. 产品外形与样品是否一致
      • 1.3.5.6. 损伤（划伤、破损）
      • 1.3.5.7. 安规测试
      • 1.3.5.8. 其它
        • 实配
        • 上锡
          • 子主题
        • 试验（阻燃、耐温等）
        • 异常描述
  • 1.4. 物料BOM管理专题
    • 1.4.1. 物料管理3个关键指标
      • 1.4.1.1. 优选率
        • 对某一个产品BOM中优选物料与所有物料的比率
      • 1.4.1.2. 替代率
        • 具有相同规格并可以完全替代的物料数目占所有物料的比率
      • 1.4.1.3. 复用率
        • 复用物料占所有物料的比例
    • 1.4.2. 物料优选规则6个指标
      • 1.4.2.1. 物料成本
        • 竞争性评估，招标价格比较，成本分析，供应商早期介入
      • 1.4.2.2. 性能规格
        • 器件发展趋势，新技术、新器件引入，器件规格，器件设计开发，技术断裂点
      • 1.4.2.3. 质量可靠性
        • 质量可靠性技术标准，全流程器件可靠性保障体系，单板硬件可靠性设计，高温可靠性解决方案
      • 1.4.2.4. 可采购性
        • 优选、归一化、物料、单板、模块、平台归一化、替代、货期，生命周期导入、成长、成熟、饱和、衰退、退出、物料风险
      • 1.4.2.5. 可制造性
        • 插装器件表贴化，小型化器件引入，器件集成与模块化设计，简洁化设计
      • 1.4.2.6. 社会责任 （节能环保）
        • 器件功耗评估，低能耗器件引入，关键器件低能耗应用方案，无铅环保器件引入
    • 1.4.3. BOM介绍及形成过程
      • 1.4.3.1. 定义
        • 它是描述产品生产加工工序和每个工序所需物料、数量及工艺损耗的重要工艺文件，是研发部门最重要的基础数据。
      • 1.4.3.2. 分类
        • 设计物料清单EBOM
          • EBOM主要是设计部门产生的数据，产品设计人员根据客户订单或者设计要求进行产品设计
          • EBOM是工艺、制造等后续部门的其他应用系统所需产品数据的基础
          • 包含内容
            • 产品名称
            • 产品结构
            • 明细表
            • 汇总表
            • 产品使用说明书
            • 装箱清单
        • 制造物料清单MBOM
          • MBOM是制造部门根据已经生成的EBOM，对工艺装配步骤进行详细设计后得到的
          • 包含内容
            • 产品的装配顺序
            • 工时定额
            • 材料定额
            • 设备
            • 刀具
            • 卡具
            • 模具
            • 反映了零件、装配件和最终产品的制造方法和装配顺序，反映了物料在生产车间之间的合理流动和消失过程。MBOM也是提供给计划部门的关键管理数据之一
      • 1.4.3.3. BOM的形成过程
        • 搭建顶层EBOM
          • 系统工程师在PLM系统中搭建产品顶级EBOM框架
        • 搭建结构EBOM
          • 结构工程师根据前期设计和编码申请情况编制结构BOM，或由3D设计图生成结构EBOM，结构部门经理审核
        • 搭建硬件EBOM
          • 根据前期设计，将PCB和原理图分别从硬件设计工具中导出制成原理图EBOM，制作单板EBOM，或由硬件设计工具集成自动在PLM系统中生成原理图EBOM
          • 审核单板EBOM
          • 修改调整原理图EBOM
          • 将生产资料包改善给工厂、驻厂工程师、采购人员（电子档）
        • 整合产品EBOM
          • 整合电子、结构EBOM、制作产品顶级EBOM、分层（电子、包装、结构、组装），再次确认EBOM的正确性
        • EBOM审核
          • EBOM评审和生产资料发布流程
        • MBOM编辑与审核
          • 如果企业EBOM和MBOM分开，则增加该环节。工艺人员在EBOM的项目上制作并审核MBOM
        • 发布到ERP系统
          • 由PLM系统将EBOM/MBOM自动发送到ERP系统
• 2. 专业术语解释
  • 2.1. DFM
    • 2.1.1. Design for manufacture,面向制造的设计
  • 2.2. IPMT
  • 2.3. CBB
  • 2.4. R&D
    • 2.4.1. 研究与试验发展活动
  • 2.5. IPMT
    • 2.5.1. 集成产品管理团队
      • 2.5.1.1. Integrated Product Management Team
  • 2.6. PDT
    • 2.6.1. 产品开发团队
  • 2.7. PQA
    • 2.7.1. 全称Process Quality Assurance， 即全程质量检测认证。
  • 2.8. BOM
    • 2.8.1. Bill Of Material 物料清单或产品结构清单



• 1. 研发管理体系简介c
  • 1.1. 产品开发的目标
    • 1.1.1. 多
      • 1.1.1.1. 提高产品占有率
    • 1.1.2. 快
      • 1.1.2.1. 提高产品开发效率
      • 1.1.2.2. 缩短产品开发时间
      • 1.1.2.3. 加快上市效率
    • 1.1.3. 好
      • 1.1.3.1. 提高产品质量
      • 1.1.3.2. 提高客户满意度
      • 1.1.3.3. 减少产品后期出现的问题
    • 1.1.4. 省
      • 1.1.4.1. 更低的产品研发成本
      • 1.1.4.2. 减少产品开发浪费
    • 1.1.5. 准
      • 1.1.5.1. 创新，满足细分市场客户需求
      • 1.1.5.2. 提高产品命中率
      • 1.1.5.3. 提高新产品收益
      • 1.1.5.4. 提高组织的研发能力
  • 1.2. 企业研发管理问题概述
    • 1.2.1. 产品开发过程中的问题和对策
      • 1.2.1.1. 不适合市场的需求/没有竞争力
        • 缺乏正确的研发理念
        • 缺乏前瞻性、有效的产品规划，没有系列化，被动响应市场和竞争
        • 没有以市场为导向，缺乏对市场的深入分析，闭门造车式的产品研发
        • 没有设立优先级评估标准，产品和技术开发项目缺乏合理的先后顺序，不能及时开发成功
        • 基于市场的创新，开发团队对产品的市场成功负责
        • 没有做好客户需求调研及市场预测，收集与分析程度不够，设计没有满足需求，需求经常变更导致设计多次修改
        • 产品市场定位不明确，没有特色和卖点，没有市场
        • 在开发实现前没有明确的定义产品概念
        • 充分的市场调研，从客户角度来定义需求，明确产品对客户的差异化价值，在项目任务书中明确产品的目标客户和竞争定位 实施需求管理流程
        • 成本太高，超出预期。缺乏对产品开发项目的费用和盈利分析
          • 开发过程中做好成本管控
          • DFM(Design for manufacture,面向制造的设计)，良好的可生产性是以经济的成本生产为前提
          • 采用标准件，优选件，CBB、归一化，尽量采用已有的标准部件进行组合
          • 信息、资源共享、技术共享与重用，避免重复开发，选用标准的产品平台，模块化设计
      • 1.2.1.2. 产品开发周期长，上市时间太晚
        • 我们公司的季节性产品-风扇/加湿器尤其有这个问题
        • 职能化的组织架构阻碍跨部门协作，没有形成项目团队，协调和沟通困难
        • 部门之间缺乏配合，影响上市后的等客户满意度
        • 建立跨部门的PDT团队，减少沟通和协调工作，提高沟通效率
        • 问题和缺陷没有及时解决，导致不断修改，测试和试产时间超出计划
        • 技术重用差，缺乏CBB(Common Building Block,共用模块)与经验、教训的积累与共享机制
        • 建立CBB库，提高重用，减少产品开发问题和缩短开发时间
        • 技术开发与产品开发没有分开，缺乏技术规划与运作机制
        • 技术难题无法解决，技术上存在障碍，关键技术无法突破
        • 产品开发和技术开发分离
        • 不规范、不一致、随意、接力式/串行的产品开发流程和方法，没有衡量指标，没有文档，依赖英雄
        • 流程不够完整，没有规定各个部门的活动，没有覆盖整个产品生命周期
        • 开发过程中管理有问题，概念和计划未充分考虑就急忙投入详细设计，后期频繁修改
        • 建立可裁剪的产品开发流程体系 实施并行开发工程
        • 关键人员离职，很多工作需要较长时间才能衔接
          • 建立开发规范，完善文档管理
        • 同时投入开发的产品与技术开发项目太多，超出资源许可的范围。项目普遍延期严重，项目质量不理想，重点项目资源得不到保证。
          • 这点跟我们公司的现状相符
        • 项目管理薄弱，效率低，包括进度、质量、成本、风险等计划和任务无法及时完成
        • 建立合理的项目组织、项目计划、监控流程 提高项目管理能力
          • 我们重视项目计划的原因
      • 1.2.1.3. 研发浪费严重、投资产品不赚钱
        • 3D打印验证多，还没能解决问题 产品试产次数多 产品测试样品损耗大 产线急着上线量产后，问题多，组装成本提高，物料损耗大
        • 缺乏产品战略及规划，没有从市场出发建立项目选择标准，选择项目更多的靠领导“拍脑袋”，随意性大
        • 没有明确的产品立项活动
        • 建立产品平台、产品线战略
        • 立项“拍脑袋”，没有完整的分析与评审
        • 在开发过程中缺乏业务决策评审。缺乏项目筛选机制，没有对项目的投资回报进行有效的分析和评估。
        • 缺乏决策评估团队，导致低价值项目占比过高
        • 以投资的观点评审项目里程碑（DCP）,及时取消不应该继续的项目
        • 项目缺乏资源（人力、技术）的保障
          • 我们公司现在也是项目团队刚成立，人手不足，经常缺乏、需要磨合 所以我们在面对这么多项目的时候，尤其需要确定好产品的优先顺序 集中资源，保证重点项目的进度/质量
          • 我们公司现在也是项目团队刚成立，人手不足，经常缺乏、需要磨合 所以我们在面对这么多项目的时候，尤其需要确定好产品的优先顺序 集中资源，保证重点项目的进度/质量
          • 运用产品组合分析方法，确定产品的优先顺序 在项目之间合理分配资源
      • 1.2.1.4. 产品开发质量时好时坏
        • 产品质量不稳定
        • 未建立或实施技术审核制度，技术评审不规范，评审要素缺乏持续完善，甚至没有评审
        • 产品出现大量问题和缺陷
        • 建立技术评审体系，及早发现问题，持续完善评审要素，减少问题的重复发生 保证足够的测试时间，形成经验问题库
        • 大量采用新器件、新模块和新技术
          • 稳定CBB库，提高产品质量
        • 技术不过关，不稳定
          • 有效的技术开发管理、研究、储备可靠先进的技术
      • 1.2.1.5. 产品开发团队士气不高
        • 需要鼓舞士气
        • 项目经理领导能力不足，执行比较随意，长官意识明显
          • 选拔合格的项目经理，发展领导能力
            • 招人/培养人
        • 缺乏对项目组的关注，沟通不足
          • 领导层、中层和执行层，各层面充分沟通
        • 评价不合理，激励不到位，缺乏有效的研发绩效考核和激励机制
          • 我们公司现在也是项目团队刚成立，人手不足，经常缺乏、需要磨合 所以我们在面对这么多项目的时候，尤其需要确定好产品的优先顺序 集中资源，保证重点项目的进度/质量
          • 解决做多做少一个样，做好做坏一个样的问题
        • 人员流动性大
        • 有效的评价和激励机制
        • 团队合作氛围不好
        • 产品开发过程中，各角色之间存在职责不清晰现象
        • 缺乏有效的培养机制，研发人员的职业化素质不足
        • 明确产品开发过程中每个阶段和节点的职责，关键交付物 持续培训和团队建设，形成团队合力
          • 目前培训工作这块有在做安排
    • 1.2.2. 研发各层级人员的问题汇总
      • 1.2.2.1. 高层
        • 研发投入大，但是产品总是不能按时量产
          • 延期
        • 公司资源究竟投到什么地方？重点项目的资源有没有得到有效保障？
          • 重点项目管理
        • 研发人员离职对公司和项目冲击很大，如何固化公司的知识库？
          • 需要加强我司的知识库管理，需要有专人来整理/优化/管理
        • 如何量化评估研发项目和研发人员的绩效
          • 做好绩效管理
        • 如何把研发工作量化管理，缺乏有效的数据支撑
          • 利用TB把工作量化
      • 1.2.2.2. 中层
        • 计划失控，无法按要求完成
        • 人员忙闲不均，工作不透明
        • 任务布置不下去，员工反馈工作很忙，但不知道忙什么？
        • 研发项目信息不透明，布置下去的工作不能天天盯着，无法实时监控
        • 解决方案
          • 利用TB把工作量化,同时监控好项目里程碑，做好项目风险管理
        • 过去犯过的错误重复犯，缺乏经验、教训的积累
        • 缺乏量化数据，绩效考核缺乏客观数据
        • 解决方案
          • 目前通过写日志的形式，还有更新TB上的项目状态
          • 做项目经验分享总结
      • 1.2.2.3. 一线员工
        • 同时承担多个项目的工作，如何安排好自己的工作时间
          • 解决方案
            • 掌握工具，梳理手上工作的轻重缓急
            • 使用好TB工具
        • 做多做少没区别，做得多领导也看不见，很委屈
        • 如何让领导在评价自己的绩效时，有客观的历史数据参考。
        • 解决方案
          • 实行绩效考核
          • 积极主动汇报工作，及时报告项目进度/风险
        • 如何做好每天的工作记录和总结，保证每天进步一小步？
        • 如何继承他人的意见/经验，避免犯同样的错误？
        • 解决方案
          • 目前通过写日志的形式，还有更新TB上的项目状态
          • 做项目经验分享总结
    • 1.2.3. 优秀的研发体系特征
      • 1.2.3.1. 对客户需求理解透彻
      • 1.2.3.2. 恰当的产品定位
      • 1.2.3.3. 集成的、结构化的、并行的产品开发流程
      • 1.2.3.4. 完善的项目管理机制
      • 1.2.3.5. 良好的设计能力和技术储备
      • 1.2.3.6. 全方位的质量保障和监控机制
      • 1.2.3.7. 顺畅的跨部门协同
      • 1.2.3.8. 清晰、明确、有前瞻性、切合实际的产品战略和产品规划
      • 1.2.3.9. 平台化、系列化的产品开发模式（技术预研、平台、技术规划、技术开发与产品开发分离）
      • 1.2.3.10. 产品线与资源线并重，研发经验、教训积累与分享，老中青比例合适的研发团队，有较好的人才梯队建设
  • 1.3. IPD体系介绍
    • 1.3.1. 关注要素
      • 1.3.1.1. 组织管理：职业化的人才梯队
      • 1.3.1.2. 市场管理：基于市场的创新、产品开发，产品开发是投资行为
      • 1.3.1.3. 流程管理：结构化流程、跨部门团队
      • 1.3.1.4. 产品管理：异步开发与重用，技术与产品开发分离
      • 
    • 1.3.2. IPD体系的7个特点
      • 1.3.2.1. 产品开发是一项投资行为，IPMT代表公司进行产品开发项目的投资分析和决策，优化投资组合管理
      • 1.3.2.2. 基于市场的研发，产品开发必须满足客户需求，而不是凭空推出自己认为是好的产品，杜绝“闭门造车”，着眼于一开始就把事情做正确。
      • 1.3.2.3. 平台化开发，所谓产品平台，就是一系列共用技术要素及这些要素组成的产品技术平台。
      • 1.3.2.4. 跨部门协作，产品开发绝不仅是研发部门的事情，需要市场、研发、采购、生产、财务等所有职能领域的跨部门协同。
      • 1.3.2.5. 结构化流程，将产品开发划分为若干阶段，明确各阶段的输入输出准则，关键控制点，统一产品开发的术语。
      • 1.3.2.6. 技术开发和产品开发分离
      • 1.3.2.7. 职业化人才梯队
      • 难点在于非结构化和过于结构化之间取得平衡，同时保证开发流程的效率和指导性。明确哪些角色和部门应当参与产品开发过程，什么时候参与、任务有哪些、输入和输出。进行开发阶段划分，过程中设置评审点（里程碑点），高层和技术专家参与开发过程。
    • 1.3.3. IPD适用的6种条件
      • 1.3.3.1. 产品或项目多，员工按各自的习惯做项目，研发定义的产品不赚钱，甚至亏钱的项目多
      • 1.3.3.2. 企业研发规模相对比较大，人员急速扩张，没有统一的工作方法
      • 1.3.3.3. 行业进入稳定发展期，产品没有太多的新技术，创新
      • 1.3.3.4. 长周期的项目，指产品投入开发到退市的周期，研发周期长、投入大、短则半年，长则数年的项目，上市后的产品存活周期也比较长
      • 1.3.3.5. 产品技术相对成熟，产品比较稳定
      • 1.3.3.6. 平台化开发，在研发“R&D”（研究与试验发展活动）中偏“D”的产品开发
      • 以上6条，我司都非常符合
    • 1.3.4. IPD推行可能存在的14个问题
      • 对于快速成长型企业，产品的战略远比开发流程重要。少而精的核心人员比建立一支“人多不干事”的重型团队重要。 又好又卖座的产品是由热爱产品的天才开发出来的，在人群中，天才是少数，庸才是多数。识别好、选拔对这些产品天才，给他们足够的授权，设计好结果导向的激励措施，远远比搞细致的流程、评审、绩效体系更重要。
      • IPD的一些理念很好，也能对企业的管理水平和产品开发有一定的帮助，但是要清醒地认识到IPD不是灵丹妙药。公司生意不好，靠IPD是很难就变好的。IPD等管理手法适用于企业所处行业发展不错，企业自身发展也比较快的公司。IPD也不能决定企业的产品战略发展方向，只能是用一套规范的方法保证、确定研发的产品按照流程研发出来。另外，IPD也不能替代人，企业管理能力的核心是人。
      • 1.3.4.1. 标准的流程不适用于具体企业，没有根据企业的实际情况进行充分的定制，导致流程没有可操作性
        • 目前我们公司的流程，也是刚刚建立起来，是按公司的实际情况做的。但是需要不断的试行与改善
      • 1.3.4.2. 制定了一套流程，但成为“一堆A4纸”存了起来，没有落实和执行，也没有不断地改进
        • 我们公司现在也是刚建立了一套流程，但是目前却还没有执行起来，还是按之前的方式在做项目，需要结合公司的情况。真的把流程跑起来
      • 1.3.4.3. 只有跨部门流程，却没有跨部门团队和各功能部门组织能力支撑
        • PDT职位职责不清楚，缺乏合理的绩效指标
        • 产品线和资源线之间的关系没有定义清楚，PDT没有充分授权，无法调动资源
        • PDT成员大部分来自研发，市场、采购、财务、生产和服务参与度不够。参与PDT工作前缺乏全面深入的培训，尤其是项目管理、跨部门沟通技能。PDT成员年轻，缺乏流程开发经验。
      • 1.3.4.4. 对企业内部人员提出了新的要求，尤其是产品管理人员。项目经理不具备足够的能力和权威管理跨部门项目组，导致项目运作困难。
      • 1.3.4.5. 流程管理部门制作流程、制度和模板，各专业部门不参与
      • 1.3.4.6. 流程范围仅聚焦在研发部门，绝大部分的企业把产品开发的成败归结于研发部门
      • 1.3.4.7. 没有时间严格执行结构化流程，研发人员认为项目交期太紧，没有时间严格走流程
      • 1.3.4.8. 要写太多文档，研发人员认为大部分时间都花在写模板上，没有时间做开发
      • 1.3.4.9. 没有足够的资源执行流程，每人身兼数职或项目经理负责远超过正常水平数量的项目
      • 1.3.4.10. 没有产品数据管理方案，如物料和BOM管理，产品开发过程中的图纸和文档管理方案，对产品数据管理难以有直接的支持和效果。
      • 1.3.4.11. 决策层、管理层和专家介入不当，要么介入太多，要么介入太少。
        • 介入太多，不能充分调动项目组成员的积极性和责任心，或者因为决策层、管理层的影响力导致决策层、管理层提出的绝大多数建议被采纳。
        • 介入太少，又不能充分发挥决策评审和技术评审的作用，也影响项目质量
      • 1.3.4.12. 过于重视流程，忽略了核心技术对产品和项目的影响，核心技术在关键路径上，应当提前进行技术开发
      • 1.3.4.13. 由于成本和范围的因素，导致顾问公司没有持续跟进，由于公司内部人员变动过快，导致制定的流程没有在新的项目上有效执行。
      • 1.3.4.14. 没有IT工具落地
  • 1.4. 快速成长型企业研发提升方向
    • 1.4.1. 研发能力提升路径图
      • 
      • 1.4.1.1. 综合
        • 朝远期发展
        • 近期
          • 研发组织（跨组织团队）
        • 中期
          • 研发组织（弱矩阵式组织）
          • 业务决策评审
        • 远期
          • 研发组织（强矩阵式组织，技术走向管理）
          • 人才培养机制
          • 研发绩效
        • 朝中期发展
      • 1.4.1.2. 效率
        • 朝中期发展
        • 近期
          • 物料和BOM管理
        • 中期
          • 市场管理
          • 项目管理
          • 产品开发流程（并行工程，跨部门协同，系统工程）
          • 技术预研与平台规划
          • CBB
        • 远期
          • 需求管理
      • 1.4.1.3. 质量
        • 目前这块不好界定，都有做，但是都需要完善，尤其是文档管理跟测试
        • 近期
          • 产品开发流程（概念到发布）
          • 产品文档管理
          • 工程变更管理
        • 中期
          • 技术评审，同行评审
          • 研发流程深化应用
          • 产品开发流程（支撑流程，生命周期管理，设计规范，工艺管理，测试管理）
        • 远期
          • 市场管理
          • 供应商协同
          • 认证和合规管理
          • 测试及问题跟踪
      • 1.4.1.4. 成本
        • 目前这块做的可以
        • 近期
          • 物料和BOM管理
          • 新物料引入流程
        • 中期
          • 产品成本管理
        • 远期
      • 1.4.1.5. 创新
        • 这块需要重点加强，基本从零开始
        • 近期
        • 中期
          • 技术平台管理
          • 需求管理
        • 远期
          • 创新管理
      • 1.4.1.6. IT
        • 处于中期阶段，需要加强工艺管理
        • 近期
          • 物料管理
          • BOM管理
          • 核心流程管理
          • 技术文档管理
          • 工程变更管理
          • 设计工具集成
          • ERP集成
        • 中期
          • 项目管理
          • 需求管理
          • 测试管理
        • 远期
          • 工艺管理
    • 1.4.2. 研发能力提升的方法汇总
      • 1.4.2.1. 降低产品成本
        • 减少产品数量，减少产品开发费用
          • 做好市场调研，决策评审，集中资源开发有价值的产品
        • 加强成本意识，开发过程中关注产品成本
          • 在产品的整个开发过程中，全程关注成本（研发成本/材料成本/生产成本）
        • DFM,良好的可生产性是以经济的成本生产为前提
          • 做好DFM评审
        • 采用标准件、优选件，CBB、归一化，尽量采用已有的标准部件进行组合。
          • 做好CBB，把产品研发标准化，提高研发效率，减少研发风险
        • 信息、资源共享、技术共享与重用，避免重复开发，选用标准的产品平台，模块化设计。
          • 把产品开发平台化，提高开发效率
        • 提高质量，降低质量损失。
        • 降低原料、物料的消耗，考虑全生命周期的成本
        • 提高开发质量，产品生产的时候直通率高。就会大大降低成本
      • 1.4.2.2. 提高产品质量
        • 设计过程中质量保证，严格的技术评审， 规范测试过程，减少产品缺陷
          • 提高研发、设计的质量，把产品的风险控制在前期
        • 从优选器件中选择器件，基于产品平台的研发模式，尽量采用成熟的技术（货架技术）
          • 用好的器件+成熟的技术，减少产品风险
        • 减少制造缺陷，及时记录、跟踪、解决问题
          • 保证生产的质量，并积极生产中的质量问题
      • 1.4.2.3. 提高产品开发效率
        • 把握源头、减少需求变更，提高项目前期（需求、设计）周期与投入
          • 前期加强需求管理与分析，确定好需求
        • 提高项目管理效率，压缩产品开发周期
          • 提高团队项目管理能力，专业技能。与供应商共同分享技术经验，共同成长
        • 并行研发，技术开发与产品开发分离
        • 化解技术风险，研发知识库持续积累，
        • 需要在产品研发的时候，提前把技术与产品分开，做并行，以免影响整个产品周期。同时注意知识库的积累
        • 减少资源瓶颈，转变观念（从改变员工到寻找合适的人），外包也是一个非常不错的选择
          • 不要让人力/物力影响



• 1. 企业及研发组织
  • 1.1. 产品研发各部门的职责内容
    • 1.1.1. 市场与规划
      • 1.1.1.1. 市场分析、竞争分析、需求调研和管理、早期发货、营销策划、上市计划、推广和销售（渠道和直销）、市场领域评审
      • 1.1.1.2. 确保客户的需求能及时满足，对需求建立跟踪机制，并对需求实现进行验证，定期评估执行的绩效，根据市场需求及时调整战略规划
    • 1.1.2. 研发
      • 1.1.2.1. 产品创意与概念设计、项目管理、需求管理、系统和子系统设计、测试、变更、工艺、研发领域技术评审
      • 1.1.2.2. 计划：市场、产品、技术预研和产品规划
      • 1.1.2.3. 开发：技术预研、平台开发、产品开发
      • 1.1.2.4. 测试：制定产品测试标准，测试验证
      • 1.1.2.5. 支持：产品的制造，市场导入
      • 1.1.2.6. 管理：项目管理、评审、人力资源、供应商、专利申报、技术培训
    • 1.1.3. 项目管理
      • 1.1.3.1. 项目管理活动，包括项目计划和控制、干系人管理、资源管理、沟通管理等
    • 1.1.4. 采购
      • 1.1.4.1. 供应商选择、认证和管理、新物料选型、执行采购、质量管理、采购领域评审
    • 1.1.5. 质量
      • 1.1.5.1. 组织进行质量目标设定、质量策划、质量管控
    • 1.1.6. 财务
      • 1.1.6.1. 目标成本管理，研发费用管理、财务分析、盈利分析
    • 1.1.7. 制造
      • 1.1.7.1. 订单预测与计划、制造策略与计划、制造调度控制、试制、新产品导入、订单履行、订单发货货运、制造领域评审
    • 1.1.8. 技术服务/售后
      • 1.1.8.1. 安装、维护、产品维修、问题解决、服务成本预测、客户服务策略与计划、服务领域评审
  • 1.2. 研发组织架构
    • 1.2.1. 职能型组织 （功能型组织）
      • 1.2.1.1. 描述
        • 每个职能部门的成员具有相同的技能和职能，仅对自己的职能经理负责，适合生产和销售标准产品的企业
      • 1.2.1.2. 优点
        • 职能分工，成本高效，专业化，技能提升
      • 1.2.1.3. 缺点
        • 不注重客户和项目，人们强烈忠于自己的部门。跨部门合作困难，效率低
    • 1.2.2. 矩阵型组织
      • 1.2.2.1. 描述
        • 项目经理对项目结构负责，职能经理为项目提供资源，共同为公司和项目的成功贡献力量，适合需要不断推出新产品的公司
      • 1.2.2.2. 优点
        • 资源共享，有助于员工技能的提升，注重客户，并能真正为客户负责
      • 1.2.2.3. 缺点
        • 双层汇报关系，沟通和协调复杂，员工的绩效考核办法比较复杂，资源经理和项目经理的权力平衡
      • 矩阵式架构相对扁平化，能够较好的解决忽视客户满意度，组织臃肿这些问题，同时激发小团队的效率，这也是我们团队，需要发展的方向
        • 弱矩阵的特点：项目局限在研发内部，项目经理类似项目协调员，关键项目决策仍需职能经理做出，部门间容易埋怨和相互责备
        • 强矩阵的特点：项目经理关注整个产品开发过程，对项目的人、财、物有绝对的领导权，项目成员代表职能部门对项目进行承诺，绝大多数的项目经理由资深的工程师兼任
    • 1.2.3. 项目型组织
      • 1.2.3.1. 描述
        • 项目成员在同一时间内全部投入一个项目，仅对自己的项目经理负责，适合以项目为主要业务的企业，如建筑业、咨询业等
      • 1.2.3.2. 优点
        • 项目经理是项目的真正领导人，效率高
      • 1.2.3.3. 缺点
        • 项目间缺乏人员和知识的交流和共享，对项目成员来说，缺乏一种事业的连续性和保障
  • 1.3. 两个跨组织团队
    • 1.3.1. 集成产品管理团队IPMT
      • 1.3.1.1. 职责
        • 负责产品投资决策和业务决策评审，制定企业总的战略和发展方向，对各产品线的运作进行指导和监控，推动产品线、研发、市场、销售、服务和供应链等部门的协作，制定企业的业务计划，对新产品进行业务决策。
      • 1.3.1.2. 主要关注点
        • 我们的战略是否正确？我们的技术是最先进的吗？下一个大规模的商业机会是什么？
        • 我们在每个细分市场上应建立何种竞争优势？我们怎样才能打入新市场？怎样才能使我们的产品系列得到最大的回报？
        • 我们应该怎么把公司合并进来？我们应该与哪些公司发展战略联盟？
        • 现有的项目组合中有哪些项目应当放弃？我们应该把哪些资源由一个项目转到另一个项目中去？
        • 替代产品推向市场时，是否已经制定了旧产品的停产计划？
        • 我们是否确定产品系列可以相互兼容与支撑？
        • 我们是否有合适的技术人员和资源
      • 1.3.1.3. 成员
        • 公司的总经理
        • 副经理级别
        • 技术总监
        • 研发总监
        • 账务总监
        • 市场总监
        • 采购总监
        • 制造总监
    • 1.3.2. 产品开发团队PDT
      • 1.3.2.1. 职责
        • 重点是执行工作，把产品推向市场。IPMT给PDT下发项目任务书，要求交付产品。
      • 1.3.2.2. 主要关注点
        • 在实现产品的进度、质量、成本目标方面，我们还应做什么？
        • 我们需要IPMT做出哪些决策？
        • 我们有无足够的人力和资源，在不降低产品功能的条件下准时完成产品开发？
        • 我们有无能力确保产品支持某种功能
      • 1.3.2.3. 角色
        • 产品经理
          • 建议由掌管职能部门的人承担，不能仅仅是协调工作的一般人员，需要对产品的最终表现承担责任
        • 项目经理
          • 建议由某个专业领域非常擅长的人转岗或者合理分配时间担任
      • 1.3.2.4. 成员
        • 采购
        • 开发
        • 生产
        • 质量
        • 财务
        • 市场
        • 营销
        • 客服
  • 1.4. 部门与职责
    • 1.4.1. 研发管理部设立的目标
      • 1.4.1.1. 结合公司实际情况优化研发流程，规范研发过程，同时提高研发质量与效率，保证各个部门之间有效的协作，确保产品数据作为公司的技术资产有效地保留和传承。提供资料开发和翻译服务，为产品开发的市场推广提供有效支持，负责产品认证工作。
    • 1.4.2. 研发管理部9大职责
      • 1.4.2.1. 研发绩效管理
        • 收集并统计研发绩效管理的基础数据，为研发绩效管理提供量化数据
      • 1.4.2.2. 流程制定与优化
        • 负责产品开发体系涉及的所有流程和PLM系统中所有与研发相关的工作流程的制定和持续优化，包括主流程、各级子流程、文件模板等
      • 1.4.2.3. 流程引导与培训
        • 根据各部门需求开展流程普及培训，项目各阶段引导PDT成员按流程开展各项活动，如果有需要，刚开展正式培训。
      • 1.4.2.4. 标准化
        • 负责维护产品、软件、物料、BOM相关规则，含编码、命名、描述、版本规则及审核发布流程
      • 1.4.2.5. 参与项目管理、过程审计
        • 根据项目状况引导工程师对项目进行关闭、暂停、恢复等操作，并对项目进行该操作的条件进行审核
        • 每周定期对项目计划、交付件、流程执行情况等进行例行审计，输出审计报告
      • 1.4.2.6. 组织并参与TR评审
        • 检查技术评审的准入条件，组织技术评审的过程，并参与技术评审
        • 监督评审过程的流程符合性，跟踪评审的遗留问题的解决情况。
      • 1.4.2.7. 组织研发质量回溯
        • 实时关注项目状况，观察是否存在重大质量隐患，如果发现隐患则及时启动质量回溯
        • 当接到客户/内部质量投诉、发生较大质量问题时组织质量回溯。质量回溯前收集数据、分析问题发生的原因，并给出初步的纠正预防措施，然后召集质量回溯会议。输出质量回溯报告，并跟踪问题解决情况，直到问题关闭
      • 1.4.2.8. 产品资料开发与翻译
        • 负责新产品资料开发，在研发工程师提供的初稿基础上完成中英文用户手册，快速安装指南的优化与翻译，并根据测试意见、客户反馈等进行必要的修改
        • 根据市场部门的需求，在研发工程师协助下，负责用户手册的开发。翻译客户所需的生产工艺、品质、维修手册等资料，整理、维护已有的用户手册
      • 1.4.2.9. PLM系统维护
        • 针对PLM系统进行操作培训，对各个部门提供PLM系统操作中出现的问题进行答疑，并解决用户由于对系统的理解、基本设置造成的问题。发现并收集PLM系统的缺陷（含易用性方面的需求），并提交供应商修改。
    • 1.4.3. 产品/项目管理部4大职责
      • 1.4.3.1. 前期策划
        • 参与前期投资机会研究，参与前期项目策划的方案选择，参与可行性论证和评审
      • 1.4.3.2. 组织新项目立项
        • 根据产品需求，确定待开发研究项目，申请立项、组织立项前的各项准备活动，负责组织项目立项会议并输出《项目任务书》，下达项目任务书，指定项目经理。
      • 1.4.3.3. 项目过程管理
        • 项目质量与进度管理，资金与资源管理，监控与报告，过程中的沟通协商，项目移交、验收、编写总结报告。
      • 1.4.3.4. 技术支持
        • 项目前期研究、试验与可行性分析，与客户进行技术交流并提供技术支持，起草技术协议
    • 1.4.4. 角色间沟通要素
      • 1.4.4.1. IPMT和LPDT、LMT项目经理
        • 项目任务书/合同，可衡量的项目目标，项目组授权，核心组成员，项目资金和资源的批准，DCP交付件的讨论和决策，项目风险计划、项目状态、项目问题（变化）
      • 1.4.4.2. IPMT和功能部门经理
        • 资源计划、能力、可获得性，资源分配
      • 1.4.4.3. 项目经理和功能部门经理
        • 项目计划活动/工作任务、资源需求、资源可获得性与分配，项目、功能部门和资源问题
      • 1.4.4.4. 项目经理和项目组成员
        • 项目任务书/合同，可衡量的项目目标，项目沟通与管理，项目计划内容与资源需求，项目计划活动/工作任务分配及状况，项目风险计划、团队决策，项目、功能部门和资源问题
      • 1.4.4.5. 功能部门经理和项目组成员
        • 授权团队代表功能部门并做出承诺，技能培养与培训，功能部门支持
  • 1.5. 理想的企业组织架构
    • 1.5.1. 单一产品线组织架构
      • 
    • 1.5.2. 单一产品线
      • 1.5.2.1. 特点
        • 专职的产品经理，产品开发和市场合二为一，需要授权产品经理为“小总经理”，否则产品经理可能形同虚设；
        • 专职的项目经理，研发部内部设立项目管理部的原因是很多企业项目经理都是由资深工程师兼任，或者项目助理文员跟进，往“专职”靠近一步。未来可逐步由产品经理负责
        • 研发管理部统筹研发管理、流程执行、资料开发和认证等工作
        • 公司级的PQA，若无法实现，短期可将PQA放在研发管理部下面
    • 1.5.3. 多产品线
      • 1.5.3.1. 特点
        • 可支持多产品体系，产品体系总监实际上就是大产品经理
        • 项目经理和产品经理合二为一
        • 将结构、硬件、软件工程师均划拔给对应的产品体系，使“产品体系总监”更具资源控制权
        • 每个产品体系增加系统设计部门，提高产品系统设计能力
        • 因为多产品体系，所以总体办划归到公司级的研发中心，提高公司级产品重用
        • 市场部转为单纯市场推广、信息收集职能
        • 若产品体系过多，可以在所有产品体系和研发中心上架设一层研发副总
        • 研发人员相对更有积极性，但过于强调研发人员的“单兵”能力，不利于研发人员的成长
    • 1.5.4. 产品经理组织的优缺点
      • 1.5.4.1. 优点
        • 产品营销组合要素得到较好的协调统一
        • 对市场上的问题进行快速反应
        • 弱项产品不会被忽略
        • 培养锻炼了管理人才
      • 1.5.4.2. 缺点
        • 与职能部门容易产生矛盾和摩擦
        • 产品经理的能力要求很强
        • 管理费用提高
        • 产品经理的项目性质导致关注短期效益
        • 产品经理难站在总部的角度考虑问题
          • 缺乏大局观
    • 1.5.5. 产品线职责
      • 1.5.5.1. 承接公司在本产品线的经营目标，对本领域的经营指标、投入产出、持续发展、市场成功负责
        • 范围
      • 1.5.5.2. 整合利用一切内外部资源，自主研发与开放合作相结合，把握市场节奏，最大限度地追求本领域的商业成功，创造商业价值
        • 目标
      • 1.5.5.3. 管理本产品线的客户需求、产品和技术开发，品牌管理、市场策略等产品全流程，包括生命周期、质量、成本等要素。分析竞争对手，捕捉市场机会，负责本领域的解决方案、产品规划和对外合作，市场拓展及产品销售。
        • 过程
      • 1.5.5.4. 管理本产品线预算，提高资源配置效率，支撑并促成IPMT关于产品规划、业务目标及业务策略及时、快速、准确地决策。
        • 资源
      • 1.5.5.5. 针对IPMT关于产品发展规划和业务目标及业务策略的决策，快速有效地运作实施。对本产品线的产品定价提供决策支撑，对本产品线的商务授权和经营利润负责，保证公司业务变革在本产品线的成功
        • 监控
  • 1.6. 技术走向管理
    • 这个需要重点讲，与我们团队的实际情况非常相符
    • 1.6.1. 技术人员的特点
      • 1.6.1.1. 不愿意遵守规则，一旦遵守，又死心塌地
      • 1.6.1.2. 自尊心强，易情绪化，易防守，IQ高，忽略EQ
      • 1.6.1.3. 不愿意求人，怕得罪人，爱单干，相对内向，蔑视权威，人际能力不足
      • 1.6.1.4. 不善于沟通，不愿意表达自己的真实想法
      • 1.6.1.5. 串行处理工作
      • 1.6.1.6. 专注执行
      • 技术转型管理常出现的几点，这是我们的优势，我们需要转变，让它不要成为我们转管理的绊脚石，需要灵活处理项目工作。
      • 1.6.1.7. 喜欢求新，追逐技术前沿，好奇心强，喜欢折腾，技术导向性强，市场、质量、时间意识不足
        • 这个尤其是我们目前在跟进项目进度的时候，存在最大的问题，需要强力扭转过来，把市场、质量、时间意识充分提高。做为我们在开展项目工作的3道红线。
      • 1.6.1.8. 专业素质高，工作严谨，追求精确
      • 1.6.1.9. 喜欢非黑即白
      • 1.6.1.10. 埋头拉车，拘泥于细节，性格比较执着，追求完美，容易忽略全局
      • 1.6.1.11. 流动意向明显
    • 1.6.2. 管理人员的要求
      • 1.6.2.1. 充满使命感
        • 保护持久的工作热情和高度负责的工作态度，自我激励和激励他人，挑战自我，追求卓越，不会“小富即安”
      • 1.6.2.2. 宽广的胸怀
        • 以事业成功为重，做到求大同存小异。包容地处理来自于他人的不同意见甚至冲突。清楚地知道反对自己的人的优点是什么？有哪些值得肯定与学习的地方，自己青睐的人有哪些缺点需要改进
      • 1.6.2.3. 良好的品德
        • 不能以权谋私，生活腐化，对公司发牢骚，讲坏话，必须自律，先管好自己
      • 1.6.2.4. 开阔的视野和结构性思维能力
        • 看到问题的本质并抓住工作的重点，不光要盯住“短木瓜”解决眼前的问题。建立机制以防范问题的能力，避免“头痛医头，脚痛医脚”。看清整体与局部的关系，抓住战略机会与战略制高点
      • 1.6.2.5. 均衡发展的管理能力
        • 善于“救火”，更善于“防火”。不能重业务轻管理，提高综合管理能力。除熟悉业务外，还须具备系统的财务，人力资源、运营管理、组织运作等管理知识与技能及较高的职业素养
      • 1.6.2.6. 善于学习
        • 只有学习型的组织，才能从容地面对高度不确定的商业环境，学会在实战中进行总结与举一反三。人是有记忆的，但是组织没有记忆，采取有效的措施保证个体的经验，在组织内传播与共享。建立一个系统以保证案例中所蕴藏的经验与教训在组织内进行有效的复制
  • 1.7. 人才培养机制
    • 需要时刻关注培养机制
    • 1.7.1. 技术研发人才培养机制框架
      • 1.7.1.1. 开展技术研发人员专业能力素质评估，盘点能力差距
      • 1.7.1.2. 对应能力标准，将部门人员设立三级标准
        • 没有达到要求
        • 基本达到要求
        • 达到或超越目标要求
      • 1.7.1.3. 建立系统的技术研发培训课程体系，根据能力差距制定技术研发人员培训计划，列出月度培训计划，落实培训计划，提升员工能力，定期进行培训效果评估
    • 1.7.2. 专业能力标准示例
      • 1.7.2.1. 市场敏感
        • 对市场变化动态高度关注，对市场趋势敏感感知，按照市场趋势调整工作思路及方向的能力
      • 1.7.2.2. 客户导向
        • 以客户（包括内部客户和外部客户）为所有活动的中心，始终密切关注客户的需求和想法，为客户提供服务并致力于让客户满意，最终建立长期良好的客户关系，从而使集团受益
      • 1.7.2.3. 创新求进
        • 开辟新的学习渠道，获取新信息、新工具、新方法，产生有价值的想法，并使用这些想法来研发新技术能力
      • 1.7.2.4. 整合资源
        • 通过组织和协调，对企业内部分割的资源和企业外部可以利用的资源进行整合和优化，并通过对资源的有效的管理与配置，使资源使用率最大化。
      • 1.7.2.5. 项目管理
        • 能够规划、执行、监控项目全过程，协调和整合资源，在进度、质量与财务等方面实现项目目标的的能力
      • 1.7.2.6. 沟通协调
        • 内部员工之间或外部合作者之间交换信息、分享思想及感情的过程，并影响和产生实质的行动或结果。从整体利益最大化的角度出发，协调处理内、外的人际关系、冲突和矛盾，促成共赢合作
      • 1.7.2.7. 问题解决
        • 针对己发生的问题，采取合理的方法，并克服障碍和阻力，圆满解决问题。
      • 1.7.2.8. 自我管理
        • 准确认识自身能力，不断给自己设定更高、更新的目标，进行自我驱动与激励，时刻保持工作激情与积极心态，成功完成工作任务。
      • 1.7.2.9. PLM知识
        • 熟悉PLM平台的概念，日常操作
      • 1.7.2.10. 产品开发流程
        • 熟悉公司的产品开发流程，了解开发过程中的注意点和难点
    • 1.7.3. 快速培养人才计划
      • 1.7.3.1. 制定培养目标
        • 如半年内，加入培养计划的研发人员80%能够胜任项目经理角色
      • 1.7.3.2. 确定培养对象选择原则
        • 有着强烈的成长愿望
        • 对技术和研发品质执着追求
        • 员工自愿加入
        • 项目导师代表公司对培养对象的发展提供必要的支持，培养对象在遇到项目管理问题时，应首先向项目导师求助
      • 1.7.3.3. 明确能力要求、责任及绩效期望
        • 公司明确提出对项目经理的能力和知识技能的要求
          • 解决问题
          • 项目管理
          • 沟通协调
          • 团队管理等能力要求
          • PLM使用等技能要求
            • TB的使用
        • 公司明确提出对项目经理的职责和绩效期望
          • 项目周期管理
          • 项目质量
          • 项目成本
          • 知识分享等
      • 1.7.3.4. 制定培养计划和定期考核
        • 导师与参与共同研讨制定阶段性的培养计划，定期回顾计划执行情况，并进行阶段性考核和最终考核，考核结果将决定是否成为项目经理
    • 1.7.4. 如何培养产品经理
      • 已经跟团队都有聊过，大家都有意愿朝产品经理方向发展
      • 1.7.4.1. 企业常见的产品管理问题
        • 缺乏合格的产品经理
        • 缺乏有效的组织及流程体系
        • 过于依赖部分好的产品经理
      • 1.7.4.2. 产品经理的能力要求
        • 项目管理（含团队合作）能力占35%
        • 业务能力占20%
        • 技术能力占15%
        • 个人影响能力占15%
        • 沟通及处理冲突能力占15%
      • 1.7.4.3. 培养的方法
        • 周边部门锻炼
          • 市场部
          • 服务部
          • 制造部
          • 提高产品全流程意识和技能
          • 这个可能不太好实现
        • 参加相关知识的技能培训，特别是提高软技能
          • 情绪控制能力
          • 领导力
          • 团队沟通等能力
          • 可以组织培训
        • 通过在产品经理/PDT经理助理等岗位上进行培训，获取经验
        • 与一些资深经理探讨、学习
        • 自我批评总结，不断学习总结、改正错误
        • 敢于压担子，充分授权，明确责权利
        • 在日常过程中执行
    • 1.7.5. 项目经理应该具备的7大能力
      • 1.7.5.1. 项目经理存在的一些常见的问题
        • 事无巨细、事必躬亲、亲力亲为，沉于事务性工作，不能抓住重点，自己太累
        • 缺乏狼性，成功欲望不足，开拓性、侵略性不足，多半扮演了一个保姆、管家的角色。缺乏警察与工头的个性，危机意识与警觉性不够；
        • 管理太软，对下属不敢严加管理，太仁慈，不能做“魔鬼”；
        • 激励和沟通能力差，不善于交流协调，经验不足，对周边部门的推动不够，缺乏号召力，个性上欠缺领袖魅力；
        • 不能提前预测问题和风险
      • 1.7.5.2. 项目经理能力要求
        • 综合能力
          • 综合素质高，不一定是技术专家或管理专家，但知识面要广，思路要开阔。协调和沟通能力强，善于调用资源，包括项目外部资源的利用和内部资源的调配。总是能记住项目的总体目标
        • 业务/技术知识
          • 了解业界相关的技术、公司愿景和核心业务，理解业务决策的含义，了解业务决策的影响。具有沟通价值的能力，能从客户的角度看问题，具有项目管理技能，如计划、风险、问题管理能力
        • 分析/谈判技能
          • 强大的分析能力，能够解决不同业务部门间的分歧，能够建立良好的人际关系
        • 想象力
          • 富有想象力，创造性思维，从客户的角度考虑问题
        • 领导力/个人品质
          • 很强的领导力，具备推行流程的能力，具备一定的幽默感，勇于、乐于接受变革
        • 团队建设能力
          • 组建团队的能力，对整个团队的管理，建立关系的能力
        • 远见、创造性
          • 有远见，创造性思维，有创造能力
    • 1.7.6. 如何培养项目经理
      • 1.7.6.1. 项目经理的评价
        • 合格
          • 一个能弥补和解决问题的项目经理是合格的
        • 优秀
          • 主要是看他能在多大程度上提前识别并消除风险
          • 风险未被及时识别或妥善处理，就会转换成问题
      • 1.7.6.2. 培养方法
        • 体系驱动与牵引
        • 周边部门锻炼，提高全流程意识和技能
        • 参加内外部项目经理知识和技能培训
        • 批评与自我批评，总结，改正错误
        • 资源池集中培养，挑选、培养、考核
        • “师父带徒弟”，通过在项目经理助理等上进行培训，获取经验
        • 与一些胡想学习的项目经理进行探讨
        • 赋予充分的责权，敢于压担子
• 2. 专业术语解释
  • 2.1. DFM
    • 2.1.1. Design for manufacture,面向制造的设计
  • 2.2. IPMT
  • 2.3. CBB
  • 2.4. R&D
    • 2.4.1. 研究与试验发展活动
  • 2.5. IPMT
    • 2.5.1. 集成产品管理团队
      • 2.5.1.1. Integrated Product Management Team
  • 2.6. PDT
    • 2.6.1. 产品开发团队
  • 2.7. PQA
    • 2.7.1. 全称Process Quality Assurance， 即全程质量检测认证。

软硬件管理

• 硬件设计
  • 硬件设计领域常见的问题
    • 没有统一的器件库，研发人员不方便查询和选型
    • 原理图和PCB板不一致，没有同步更改
    • 硬件设计和结构设计（空间尺寸的信息）无法协同研发，缺乏信息共享
    • 版本容易出错
    • 原理图、PCB图的签审效率和准确性低
  • 硬件设计流程
    • 硬件开发流程
      • 总体设计方案和产品设计规格书一般同步完成，设计方案确定后一般进行关键物料提前采购和备料
      • 总体设计方案后一般进行单板总体方案设计
      • 硬件概要设计很多公司会省略
      • 单板制作、调试活动同时进行物料的采购
      • 硬件集成及测试、评审活动包括软硬件联调
    • PCB设计流程
      • PCB设计、评审
        • 设计文件提供：
          • 提供原理图文件和网络表文件及规则驱动，结构要素图文件，EDA工程师的库路径
        • 预布局建议：
          • 基本的布局模块示意，确定端子、商品等结构布局，根据建议确定器件和模块的基本位置和电源、信号流向，考虑工艺生产角度
        • 布局：
          • 精确确定结构布局，以结构要素图为标准
        • 布局评审：
          • 确定结构、可制造性设计、工艺、生产、可靠性、EMI、EMC、电源布局、信号流向等电气特性，确定布局
        • 布线、布线评审：
          • 确定结构、可制造性设计、工艺、生产、可靠性、EMI、EMC、电源布线、地设计、信号流向等电气特性，确定布线
        • 自检：
          • 仔细检查PCB的细节，按照PCB投板评审要素逐一详细检查
        • 复检：
          • 按照PCB投板评审要素逐一核对，并对相应细节与项目CAD人员沟通修改
      • 器件封装设计流程
        • 器件建库申请
          • 制作封装设计BOM表，并下达
        • 建库申请BOM表
          • 列出本项目所需要用到的封装器件和实验阶段需要用到的新器件清单
        • 资料供给
          • 新建器件封装必须提供完整的资料（包括器件的外形、尺寸和管脚功能），器件管脚数少于2的简单规则器件可以不提供资料或自行寻找资料
        • 建库
          • PCB封装建库工程师必须具有专业的建库经验和了解器件工艺，根据申请人所提供的资料及结合设计规范严格设计器件封装库，设计的封装应具有良好的要加工性、正确性及美观性。封装一旦知识库后应严禁发动，尽量不要更改
            • 建库规范
            • PCB封装库命名
            • 规则
        • 内部评审
          • 为确保器件封装的可加工性、正确性及美观性，设计完的每一个封装必须严格进行检查。封装命名唯一，不能把新建的封装覆盖原来封装。检查封装在库内的唯一性，型号对应封装。检查封装设计的视图（器件封装必须按器件的顶视图来建库，部分特殊器件需要在PCB板上形容安装在底面，一定要有文件说明），应严格按《器件封装库设计检查Checklist》及配合工艺检查器件封装
            • 器件封装库设计
            • 检查Checklist
        • 入库
          • 经严格检查的封装库由专人入库，PCB封装建库工程师共享一个文件，入库专员每天需把库文件同步到服务器
          • 一旦入库的封装库应严格控制修改，如有修改的库必须有修改说明文件
  • 硬件设计专题
    • 硬件设计常见风险
      • 设计
        • 封装错误，新技术应用，新器件应用，器件优先等级改变，EMC、热、环境、安规、国际化设计，可制造性设计，新电缆应用，公用基础模块（CBB）成熟度，结构要素图设计错误，新型结构应用、接口、性能、软件限制
      • PCB
        • PCB设计可行性，PCBA加工实现，PCB设计时间不可控
      • 单元、集成和系统测试
        • 测试项的完整性，开发调试环境，测试时间不可控
      • 采购
        • PCB板采购，器件采购，结构件采购，电缆采购
      • 管理
        • 人员变动或者不满足要求
    • 单板硬件程序命名规范
      • 按单板型号划分，如半成品名称+工位号+待烧录芯片类型+程序日期+后缀名。其中，工位号为待烧录芯片在单板上的工位号，芯片类型如单片机MCU、Flash简称FL，程序日期为硬件程序的编制日期，后缀名为硬件程序的后缀名。按平台划分，如平台+型号+程序日期+后缀名。型号指整机型号，也可以是芯片型号。日期为程序生成的日期，后缀名为硬件程序的后缀名。如果多个BOM共用一个硬件程序，以第一个单板命名。有替代物料时，分别用两个不同的程序，加上芯片名称备注。
    • PCB布局及布线要求
      • 布局要求
        • 遵照“先大后小，先难后易”的布置原则，即重要的单元电路、核心元器件应当优先布局
        • 布局中应参考原理框图，根据单板的主信号流向规律安排主要元器件
        • 布局应尽量满足总的连线尽可能短，关键信号线最短，高电压、大电流信号与小电流，低电压的弱信号完全分开，模拟信号与数字信号分开，调频信号与低频信号分开，调频元器件的间隔要充分，交叉线最少，过孔最少，地线层和电源层没有连线，调频数字信号的间隔要大，尽量减少电源地层与信号层层距布线
        • 相同结构电路部分，尽可能采用“对称式”标准布局
        • 按照均匀分析、重心平衡、版面美观的标准化布局
        • 器件布局栅格的设置，一般IC器件布局时，栅格应为50-100mil,小型表面安装器件，如表面贴装元件布局时，栅格设置应不少于25mil
      • 布线要求
        • 关键信号线优先，电源、模拟信号、高速信号、时钟信号和同步信号等关键信号优先布线
        • 密度优先原则：从单板上连接关系最复杂的器件着手布线。从单板上连线最密集的区域开始布线
        • 增加线间距，减少平行直线长度
        • 增加线宽度，降低其特性阻抗
        • 重要信号间可采用平行地线的方法隔离
        • 尽可能少拆线，不走90度折线
        • 少走过孔
        • 重要线不要走插座脚间穿过，频率高的线也应尽量避免
    • 硬件度量指标
      • 硬件进度偏差率
      • 硬件第一次样机制作完成前缺陷发现数目
      • 硬件遗留缺陷数目
      • 硬件总体设计评审缺陷发现数目
      • 硬件详细设计评审缺陷发现数目
      • 样机
      • 试产测试缺陷发现数目
      • 原理
      • 原理图重用率
      • 构件重用率
      • PCB重用率
      • 结构图纸重用率
      • 关键芯片重用率
    • 硬件开发流程审计示例
      • 
      • 开发活动必不可少的，不执行，开发便进行不下去
        • 单板硬件总体设计
        • 单板硬件详细审计
        • PCB设计等
      • 保证开发质量的
        • 各种评审活动
        • 正规检视
        • 可靠性
        • 可测性
        • 可维护性设计
        • 详细设计阶段考虑单板工艺
        • 结构EM设计
      • 流程执行时间如表
        • 
        • 各阶段起止时间说明
          • 单板总体设计阶段：硬件开发人员接到硬件开发任务书开始，单板总体设计方案评审通过结束
          • 单板硬件详细设计阶段：单板总体设计方案评审通过开始，到第一次PCB投板申请得到CAD室同意为结束
          • 投板阶段：指第一次投板时间，以第一次投板申请提交时间为开始，PCB回板开发人员开始第一次单板调试为结束
          • 单板硬件调试阶段：开发人员开始第一次单板硬件调试，到调试结束，包括第二次投板、多次投板的时间及每次的调试时间。如果有单板调试完成，但需等待其他单板完成才能开始系统联调，则要指出等待时间
          • 单板软件概要设计阶段：单板总体设计方案评审通过开始，单板软件概要设计方案评审通过结束
          • 单板软件详细设计阶段：单板软件概要设计方案评审通过开始，到单板软件编码结束时间为结束，包括编码时间
          • 单板软件调试阶段：单板软件调试开始，到调试结束
          • 系统联调/测试阶段：系统联调开始，到版本稳定为止
        • 执行较好的环节
          • 单板软硬件总体设计主要输入是硬件总体设计方案，在单板详细设计阶段考虑单板可测性、可维护性和可靠性，PCB布线经过评审，单板软硬件详细设计报告经过审核并按意见进行修改
        • 执行不好的环节
          • 单板硬件详细设计时没有考虑单板的工艺、装备和结构设计，关键器件没有替代策略，在单板详细设计阶段没有考虑单板EMC设计
        • 问题及改进建议
          • 产品的硬件总体方案没有总体组组织正式的评审就开始做单板
            • 由总体组对评审进行控制，产品的硬件总体方案评审报告归档后才能开始单板的开发，保证在以后的产品开发过程中不出现类似情况
          • 单板总体设计方案评审滞后于单板的详细设计
            • 项目组在做项目计划时按流程规定的时间顺序来安排活动，将单板总体设计方案放在单板详细设计的前面，然后严格按计划执行
          • 流程中规定应有一些输出，如单板可靠性设计报告、可维护性报告、单板工艺结构报告等，在审计过程中被访谈人员反映做过此类活动或在设计过程考虑到这点，但找不到相关正式记录（纪要、报告等）
            • 项目组按流程做项目计划，工作任务的完成应以相应流程规定的输出报告完成为结束标志
  • 硬件设计输出文档模板
    • 硬件总体设计方案
      • 概述
        • 名称及版本号，说明本文档对应的硬件PCB板的正式名称及版本号
      • 系统功能及功能指标
        • 系统总体结构图及功能划分，单板逻辑框图，组成系统各功能块的逻辑框图，电路结构图及单板组成，单板逻辑框图和电路结构图，关键技术讨论，关键器件清单，可靠性、安全性和电磁兼容性讨论，硬件测试方案，成本分析
      • 单板总体设计
        • 单板尺寸，单板逻辑图及各功能模块说明，单板软件功能描述，单板软件功能模块划分，接口定义及相关板的关系，重要性能指标、功耗及采用标准，开发用仪器仪表等
    • 单板总体设计方案
      • 概述
        • 名称及版本号：说明本文档对应的单板的正式名称及版本号
        • 位置、作用、采用说明：简要说明单板在系统中的位置和主要作用，最好用框图表示（应与产品设计规格书保持一致），采用的标准（与产品设计规格一致，并细化），注意遵循公司所有有关的开发设计技术规范
        • 单板尺寸：说明单板的尺寸（含扣板、特殊器件）和单位，在尺寸要求特别严格的情况下，应说明使用该尺寸的足够理由
        • 开发目标：说明开发该单板的具体目标，具体目标包括面向产品实现产品功能，面向方案包括关键器件或电路的方案选择等，面向试验通过单板的调试过程决定某些可选功能（相关电路/软件模块）的增删
      • 单板功能描述和主要性能指标
        • 说明各硬件单元、逻辑电路的划分，并说明单板软件、业务软件与硬件的支撑关系，建议采用框图和说明文字相结合的方式，需要说明各单元与其它单元的配合接口关系（主要接口类型和信息流向、处理关系）
        • 单板总体框图：对主要业务处理流程和各功能单元间配合关系进行分析说明
        • 功能单元1/2/3介绍
      • 单板总体框图及各功能单元说明
        • 说明各硬件单元、逻辑电路的划分，并说明单板软件、业务软件与硬件的支撑关系，建议采用框图和说明文字相结合的方式，需要说明各单元与其它单元的配合接口关系（主要接口类型和信息流向、处理关系）
        • 单板总体框图：对主要业务处理流程和各功能单元间配合关系进行分析说明
        • 功能单元1/2/3介绍
      • 单板接口定义、与相关板的关系
        • 外部接口：详细说明该单板的所有外部接口的设计要求，包括接口名、接口逻辑位置（批与系统中其它哪些模块相连）、接口硬件和软件特性和连接方式等，对模拟接口应说明电压特性、频率特性和负载特性等，对数字接口应说明电平特性、时序特性，必要时可加上某些通信协议特性等，对电源接口应说明电压特性、噪声容限要求、额定功率等
        • 用户接口：详细说明单板的面板上所有与用户有关的接口，包括面板指示灯、光口、以太网口、同轴电缆接口、串口，跳线、拔码开关等
        • 系统接口：单板与本系统外设备的接口，对于需要通过电缆或光纤连接的接口部分请注明，并同时给出对连接电缆性能指标的要求
        • 板际接口：以表格形式列出单板与母板插座信号的位置和定义，并详细说明单板对其它单板接口，包括每一个/组信号与哪块单板相连，输入/输出关系。以波形图的形式说明每组接口的时序，如果接口是标准接口（或其子集），如PCI，只需给出必要的说明
        • 内部接口：内部接口调测接口（如用于下载软件的串行口，测试点等）、设置接口（跳线、拔码开关、复位开关、电源开关等）和显示接口
        • 软件接口：站在软件人员的角度描述所有软件人员需要了解的硬件细节
        • 调试接口：详细说明单板上所有调试用接口，包括调试专用指示灯、跳线、拔码开关、电源保险丝、ISP接口、软件测试接口、硬件测试点等
      • 关键器件选型
        • 考虑单板关键器件的选型（商务条件、技术可行性和供货风险），器件封装类型（选用新接插件要考虑线缆匹配，并进行可装配性分析，与单板工艺设计配套考虑）
      • 单板各单元详细说明
        • 单板功能单元划分：从系统的角度阐述单板的逻辑实现，提供单板的逻辑框图，划分功能单元，对其中的各单元的功能进行简要说明
        • 单元详细描述：详细描述本单元的功能，给出本单元的功能框图，说明本单元对其它单元接口每个/组信号的详细定义，说明本单元的实现方法，包括使用的芯片、主要电路分析和解释，单元提供哪些自诊断、自测试功能，实际的硬件实现方式、需要哪些软件的支持
        • 单元间配合描述：详细说明采用什么总线、什么工作方式、下挂什么单元。详细说明单元间复位顺序，各单元间的时序关系，单板整体可测试性设计，软件加载方式说明等
      • 单板软件需求和概要方案
        • 硬件对单板软件的需求，对单板内的所有与硬件可能相关的软件提出配套需求，包括功能需求、可测试性、可维护性需求等
        • 业务处理软件对单板硬件的需求可实现性评估
        • 单板软件与硬件的接口关系和实现方案
      • 单板逻辑需求和概要方案
        • 单板内可编程逻辑设计需求，包括功能需求、性能需求、可测试性、可维护性需求等
        • 单板逻辑的概要方案
      • 单板的产品化设计方案
        • 可靠性综合设计，单板可靠性指标需求、单板可靠性指标详细设计
        • 单板故障管理设计，主要故障模式和改进措施，故障检测率、隔离率计算、单板复位、断电重启流程等
        • 器件应用可靠性设计，简要说明单板器件过应力防护、降额、容限容差、寿命类器件维护设计方案
        • EMC、ESD、防护及安规设计，关键器件和关键信号的EMC设计，安规和防护设计，环境适应性和防护设计
        • 单板信号完整性设计说明
        • 单板工艺设计说明：包括PCB工艺方案、元器件工艺要求、预计的加工路线、单板装配、配线
        • 单板结构设计：包括接手条开机箱结构，指示灯、面板开关，紧固件，特殊器件结构配套设计，热设计及监控
        • 单板热设计、单板电源设计、单板可维护性设计、调试计划和方案
        • 其它配套措施：环境适应能力等方面的保障措施，单板调试、安装、使用维护注意事项，对生产维修环节的配套要求
      • 附件
        • 安规器件清单
        • FMEA分析结果
    • 硬件概要设计说明书
      • 概述
        • 产品描述，产品功能和特性，说明产品的卖点功能、特性
        • 产品的开发环境
        • 产品的应用环境
      • 针对需求的具体技术方案
        • 需求说明：可引用产品包需求文字
        • 约束条件：该项需求的设计约束、可制造性约束、物料约束、各类标准约束
        • 可实现的技术方案（含可替代方案）：详细描述技术方案，可用原理图、公式、3D图、仿真等方式体现
      • 总体技术方案
        • 可实现的总体技术方案（含可替代方案）：对各需求的技术方案进行协调汇总，可用原理图、公式、3D图、仿真等方式体现
        • 多种总体技术方案的比较：从实现难度、复杂度、成本、性能指标、风险等方面加以比较
        • 结论：给出优选方案
      • 硬件系统框架说明
        • 系统功能框图：系统包括哪些模块，以及各模块间的连接关系
        • 单板功能框图：单板的功能说明和大致布局
        • 单板内外接口说明及系统连线图：详细说明该单板的所有外部接口的设计要求，包括接口名、接口逻辑位置和与系统中其它哪些模块相连，以及使用接插件的类型
      • 各功能单元概要设计说明
        • 示例：电源系统、说明系统、子系统的每路电源的设计原理和参考电路
      • 整体布局、PCB板布局、信号完整性分析
        • 从整体的角度来考虑产品的设计，在具体设计中需要注意哪些方面
        • 确定系统需要多少块PCB板，对每块板PCB的结构、布局、层数和关键器件的摆放进行具体的分析对系统的关键信号和调整信号进行信号完整性分析，分析信号在电路中以正确的时序和电压进行传输，描述其信号质量
      • 关键物料清单
        • 列出关键物料、长周期物料清单，并对物料的交期、最小采购数量等信息进行分析
      • 物料成本分析
        • 给出典型配置的物料成本和其它配置主要模块的物料成本
      • 风险控制
        • 分析项目进行中的风险，并说明应对风险的策略及跟踪管理手段
    • 硬件详细设计说明书
      • 概述
        • 背景：对应的单板硬件正式名称和版本号
        • 单板功能描述：简述单板功能，内容参照单板硬件概要设计方案中的相关章节
        • 单板运行环境说明：说明各种可能的物理环境和逻辑环境、软件支持环境等
        • 重要性能指标：列出单板的主要性能指标，例如处理器性能、缓存容量、端口通信速度等指标
        • 架构详细说明：产品的系统框图，各单板在系统中的位置和作用，主要功能特点，各单板上的功能模块、原理框图、性能指标、采用的标准
        • 关键器件：对单板的关键器件详细说明其软硬件特性并分析优缺点，如果曾经有多个可选对象，应说明目前选择该器件的原因和不选其它可能性的原因
      • 各功能模块的详细设计说明
        • 单板功能单元划分：从系统的角度单核单板的逻辑实现，提供单板的逻辑框图，划分功能单元，对其中的各单元的功能进行简要说明。本节主要描述各单元内部的详细结构和相互之间的接口
        • 单元详细描述：各功能模块详细设计说明，以电源系统设计为例
        • 功能模块详细设计说明：详细描述本单元的功能，给出本单元的功能框图，需要指出电路的设计关键点，对主要的电路应提供局部原理图并进行分析和解释
        • 与其它单元的接口：说明本单元对其它单元接口每个/组信号的详细定义，包括时序说明
        • 实现方式：说明本单元的实现方法，包括使用的芯片、主要电路分析和解释。如果板上有可编程逻辑器件，应在此提供这些可编程器件的内部原理图、外部管脚图（含说明）、功能模块图（含说明）及相关的时序图
        • 关键器件特性指标：需要列出器件的关键特性指标（包括输入、输出信号电平指标，电流指标、功耗、ROHS、封装等）对单板中的关键器件详细说明其软硬件特性并分析优缺点，如果曾经有多个可选对象，应说明目前选择该器件的原因和不选其它可能性的原因
        • 可测试性说明：单元提供哪些自诊断、自测试功能、实际的硬件实现方式、需要哪些软件的支持，结合生产、维护等给出关键测试点
        • 单元间配合描述
        • 总线设计：说明采用什么总线、什么工作方式、下挂什么单元，需要给出图示和文字解释
        • 时钟分配：说明有什么时钟源、提供给什么单元、时钟之间关系如何
        • 复位逻辑：说明单元间复位顺序、Watchdog设计、复位单元加载顺序
        • 各单元间的时序关系：说明各单元的信号经过哪些逻辑的处理，符合什么样的时序关系，再输出到另一个单元
        • 单板整体可测试性设计：单板提供哪些自诊断、自测试功能，实际的硬件实现方式、需要哪些软件的支持
      • 硬件单板主要接口定义、与相关板的关系
        • 板际接口：以表格形式列出单板与母板插座信号的位置和定义，并详细说明单板对其它单板接口，包括每一个/组信号与哪块单板相连，输入/输出关系
        • 系统接口：单板与本系统外设备的接口，对于需要通过电缆或光纤连接的接口部分请注明，并同时给出对连接电缆性能指标的要求
        • 软件接口：对单板软硬件接口部分进行进一步的补充设计描述，如单板片选信号、中断信号、通信端口、寄存器、关键器件分配及说明
        • 大规模逻辑接口：说明单板硬件各单元与大规模逻辑的接口定义、处理信息类型、配套控制方式、接口时序等
        • 调测接口：详细说明单板上所有调试用接口，包括调试专用指示灯、路线、拔码开关、电源保险丝、ISP接口、软件测试接口、硬件测试点等
        • 用户接口：详细说明单板的面板上所有与用户有关的接口，包括面板指示灯、光口、以太网口、同轴电缆接口、串口、路线、拔码开关等
      • 单板可靠性综合设计说明
        • 单板可靠性指标：参照单板硬件概要设计方案中的内容。本节需要修正单板硬件概要设计方案中的估算数据
        • 单板故障管理设计：主要故障模式和改进措施，故障定位率计算，冗余单元倒换成功率计算，冗余单板倒换流程，单板复位、断电重启流程
        • 器件应用可靠性设计说明：单板器件可靠应用分析结论，器件工程需求符合度分析，单板硬件返修率预计及改进对策，上、下电过程分析，器件可选应用薄弱点分析，替代容差分析，器件主离散性、最坏情况容限分析
      • 单板可维护性设计说明
        • 单板提供PCB和逻辑版本号上报功能的方式
        • 单板支持逻辑、单板软件和数据的加载和配置的方式，包括在线加载和远程加载
        • 单板能通过单板软件完成哪些设置、控制和操作，如工作方式设置、复位、倒换、闭塞、解闭塞、商品自环和单板自环等，硬件部分是如何支撑这些功能的
      • 单板依赖完整性说明
        • 关键器件及相关信息，信号串扰、毛刺、过冲的限制范围和保障措施，其它重要信号及相关处理方案，物理实现关键技术分析
      • EMC、ESD、防护及安规设计说明
        • 单板电源、地的分配图、关键器件和关键信号的EMC设计，安规、环境适应性和防护设计
      • 单板工艺设计说明
        • PCB工艺方案，元器件工艺要求
        • 预计的加工路线，描述单板的加工路线，包括单板组装后处理方式（如涂覆等）、老化方式、测试路线等
        • 单板装配：单板的安装及坚固方式，单板上紧固件的种类及可装配性、可操作性、禁布区，小板和大板装配方式、装配空间，紧固方式、装配精度要求
        • 新工艺需求：新工艺应用及其实验安排，并提出对基础工艺平台的要求
        • 配线：说明单板（包括母板）出线的方式，接插件选择
      • 单板结构设计说明
        • 拉手条或机箱结构，指示灯、面板开关、紧固件，特殊器件结构配套设计
      • 风险管理
        • 分析开发过程中存在的各种影响开发进度的风险，例如关键器件的交货周期、关键技术的实现等，并对之进行分析，给出预防措施
      • 附件
        • 安规器件清单，FMEA分析结果，物料清单编码索引，列出制成板，成品板和软件的编码，便于查询各种清单，参考资料清单，参考资料清单，其它重要详细设计信息
    • 原理图和PCB图框
      • 
    • PCB制版要求
      • 
    • 单板调试记录
      • 
      • 单板硬件
        • 单板硬件功能模块划分、单板硬件各模块调试进度、调试中出现的问题及解决方法
      • 单板软件
        • 单板软件功能模块划分及各功能模块调试调试进度、单板软件调试出现问题及解决方法、下一阶段的调试计划、测试方案修改
      • 汇总记录
        • 原始数据记录，系统方案修改说明，单板方案修改说明，器件改换说明，原理图，PCB图修改说明，可编程器件修改说明，调试工作阶段总结，调试进展说明，下一阶段调试计划及测试方案的修改
    • 单板硬件测试报告
      • 硬件测试一般包括单板系统联调和样机测试
      • 概述
        • 基本情况介绍：填写测试中针对的机型和测试验证重点
        • 单板模块划分：从调试测试的角度简要说明单板硬件功能模块的划分情况，以及各个模块的功能和相互关系
        • 调试测试网图：简单描述调试测试的组网图
        • 调试时间、地点及人员
        • 使用仪器和设备
      • 测试范围
        • 硬件测试主要针对整机外部使用的特性，内部信号测试由硬件开发人员完成
        • 原型机阶段：预测试，对所有功能模块进行测试，对电气参数进行测试如系统信号测试等，对性能进行摸底测试，对可靠性进行摸底测试，对结构进行摸底测试，对提交文档进行验证
      • 调试测试用例记录
        • 功能部分调试，模块测试用例；信号质量测试用例
        • 失效器件原因分析：描述对关键器件的失效分析结果、可靠性改进和预防措施
      • 测试总结
        • 测试充分性评价：对本次调试的项目进行总结，包括完成总项数、通过多少项、失败多少项、部分通过多少项及百分比等，对产品实际测试使用的CASE在CASE库/样机测试用例中的比例说明，对这次测试了的模块的比例说明，测试偏重点的说明
        • 结果及风险分析：对缺陷分布的分析和测试同类产品对情况的分析，分析修改过或未修改，及可能未能测试到的问题带来的问题和情况的分析，测试结果的说明
        • 遗留问题报告：遗留问题是指调试过程中发生的，并且在调试报告时仍没有得到解决需要投下版PCB回归测试验证的问题
        • 调试测试经验总结
      • 测试结果
        • 测试结论：通过，产品设计符合需求。不通过，产品存在重大缺陷导致产品不符合需求要求。有条件通过，产品部分功能不符合需求或存在部分缺陷，介对后续活动影响不大的情况。需要说明产品的后续处理方式，并进行跟踪
  • 硬件评审要素
    • 单板软件测试评审要素
      • 单板升级兼容性测试
        • 与各种硬件版本、以前单板软件的兼容性
      • 单板通用功能测试
        • 根据本板完成功能和各项要求与指标测试，测试项目是否完备
        • 测试方法是否科学
        • 是否对这些项目进行了测试：单板上电开工、后台复位、带电拔插等
        • 单板内是否有自检功能：如内存自检、邮箱自检、主要接口自检、主要功能器件自检
        • 单板内是否有调试口，是否对调试口进行了测试
        • 单板是否进行了超负荷测试，最大能力是多少？是否满足要求
        • 单板的维护功能是否做了测试
        • 该单板在详细设计中要求的特殊情况是否进行了测试
      • 协议功能测试
        • 是否可用标准协议测试仪进行测试，测试结果是否满足要求
        • 协议的各种异常情况是否做了完整的测试
      • 较复杂的软件
        • 是否对程序的主要分云进行了测试
        • 软件是否模块化
        • 对各项功能模块，是否对其功能进行了模拟输入测试
        • 是否进行了单元测试
        • 测试用例是否合理
        • 是否进行了内存占用率的测试
        • 编程是否按照规范
        • 是否进行了静态代码审查
    • 单板硬件测试评审要素
      • 规范性
        • 产品名称、型号、版本号、保密代号是否详细、清楚
        • 是否遵守模板要求
        • 资料、文献引用是否正确
      • 技术可行性
        • 是否具有完备的单板功能说明
        • 是否具有待测试单板正常工作所需环境的详细说明
        • 是否具有完备的EMC测试布置图
      • 测试完备性
        • 是否完备列举了所有应该测试的端口
        • 是否正确正确将不同商品进行测试类别分类、等级分类
        • 是否完备列举待测试单板可以测试的项目
      • 可测试性
        • 是否考虑让单板工作在最大EMI发射状态
        • 是否考虑寻找最敏感EMS受扰状态
        • 是否考虑到特殊测试要求：如对比测试、极限测试等
        • 是否有明确的敏感度判断标准
        • 是否考虑了公司现有的试验条件
        • 是否考虑了出现问题时大致要采取的措施，现象处理手段、工具准备等
        • 是否考虑了意外防护
      • 成本周期
        • 是否充分考虑了时间安排
    • 外协评审要素
      • 工程资料
        • BOM是否为本次生产有效版本
        • 器件清单、烘烤要求是否己提供，GERBER是否为本次生产有效版本
        • 是否有本次生产工艺流程要求
        • 测试平台软件是否己下达，测试是否有作业指导书或专人指导
        • 是否对外协提供电路原理图或维修培训
        • 测试夹具线料及专用耗材是否准备到位，贴片设备及钢网是否到位（含有、无铅切换准备）
        • 作业指导书是否准备
      • 品质保障
        • 来料检验标准、PCBA检验标准、异常停线标准是否提供
        • 检验人员是否到位，有无检验标准，是否对人员进行培训
        • 该产品转产前平均直通率及主要问题点是否提供
      • 计划商务
        • 物料是否正常入库并预先处理（烘烤等）
        • 生产交货计划能否达到交货要求
        • 报价是否完成，生产线体配置是否完成
    • 硬件开发流程实施情况评审要素
      • 单板软硬件总体设计之前是否己有硬件总体设计方案和软件总体设计方案？
      • 单板软硬件总体设计方案是否经总体组组织的评审？是否按照评审意见进行了修改？
      • 是否按照软硬件总体设计方案制定了单板的软硬件测试计划和单板综合测试计划？
      • 单板软硬件的测试计划是否经过了总体组组织的评审？
      • 单板硬件详细设计时是否考虑选用共享电路提供共享电路，是否考虑单板的工艺、结构、电源设计、EMC设计、装备设计、可靠性设计、可测试性设计、可维护性设计？
      • 关键器件是否有替代策略？
      • 选用多少非优选器件？有无计算器件的替代率和复用率？
      • 单板的软硬件详细设计报告是否经过评审？单板软硬件详细设计是否按评审意见进行了修改？
      • PCB布局、布线是否评审？PCB布局、布线是否按评审意见进行了修改？
      • 软硬件的集成测试计划是否经过总体组的评审？
      • 系统联调测试前是否通过版本申请提交版本
• 软件管理
  • 软件管理常见的问题
    • 人员、组织
      • 软件开发团队的管理职责不清晰，人员流动频繁，人员工作安排不合理
    • 数据
      • 没有集中、唯一、长期正确的软件管理平台，如VSS、SVN、Rational Clear case等
      • 软件数据和其它产品数据分散管理
      • 软件管理相关的文档，以及软件本身输出质量不高
      • 软件配置管理有待提高，嵌入式软件与PCBA、系统软件之间的关联关系不清晰
    • 流程
      • 软件开发规范与方法、过程控制有待提高
      • 软件需求没有统一管理
      • 软件开发缺乏足够的系统分析
      • 软件开发过程缺乏明显的阶段评审
      • 子主题
      • 开发的软件缺乏足够的测试，导致软件质量不高
      • 没有全面的变更流程和问题跟踪流程
      • 软件与其它专业的协同有待改善
      • 开发周期出现严重拖期
  • 软件管理流程
    • 
    • 定义产品包需求
      • 活动概述
        • 探索关键技术的概念，并对其进行评估和优劣势分析，配合SE做软件部分可选概念探索和选择，提出软件技术概念的选择建议
      • 模板/标准/工具
        • 产品包需求
    • 需求分解与分配/总体设计
      • 活动概述
        • 产品总体设计，根据己确定的产品包概念、产品包需求进行软件的需求分解和分配，配合SE做软件部分分解分配
      • 模板/标准/工具
        • 产品需求分解与分配模板
        • 产品总体方案
    • 系统设计与设计规格定义
      • 活动概述
        • 编写和审核产品技术规格说明书
      • 模板/标准/工具
        • 产品技术规格书
    • 软件概要设计、评审
      • 活动概述
        • 进行软件的架构设计和各模块之间的接口，确认软件同其它相关的外部接口，各模块的主要技术，系统的核心逻辑，关键产品组件或关键功能模块，设计用户操作界面及交互界面
      • 模板/标准/工具
        • 软件概要设计说明书
        • 软件概要设计评审要素
    • 软件详细设计、评审
      • 活动概述
        • 开发负责人主导，开发工程师实现
        • 编写详细设计说明书
        • 详细描述关键模块的功能
        • 软件工程师编写、审核和确认单元测试用例
      • 模板/标准/工具
        • 软件详细设计说明书
        • 软件详细设计评审检查单
    • 编程
      • 活动概述
        • 完成代码
      • 模板/标准/工具
        • 源代码
        • 《软件编码规范建议》
    • 代码走查
      • 活动概述
        • 根据编码规范走查各模块代码及单元测试代码
        • 对功能实现尽可能的逻辑审核，确认与设计的一致性
        • 对代码质量提出建议和意见，赶写代码走查单
        • 软件工程师根据代码走查修改意见修改代码，修改后的代码提交由审核人确认问题是否修改
      • 模板/标准/工具
        • 《软件代码走读要素表》
    • 单元测试
      • 活动概述
        • 软件工程师根据各个组件模块选择合适的单元测试方法，如功能测试、模块白盒测试等
        • 对软件模块进行单元测试并记录单元测试结果及发现的缺陷
      • 模板/标准/工具
        • 《软件单元测试报告》
    • 集成测试
      • 活动概述
        • 编写软件集成测试方案，软件工程师对软件系统进行集成测试，缺陷修改
      • 模板/标准/工具
        • 软件集成测试方案
        • 软件集成测试报告
    • 配合测试工程师进行SDV测试
      • 活动概述
        • 软件工程师配合测试工程师进行SDV测试，软件工程师进行缺陷修改
      • 模板/标准/工具
        • 《测试报告》
    • 配合测试工程师进行SIT测试
      • 活动概述
        • 软件工程师配合测试工程师进行SIT测试，软件工程师进行缺陷修改
      • 模板/标准/工具
        • 《测试报告》
    • 配合测试工程师进行SVT测试
      • 活动概述
        • 软件工程师配合测试工程师进行SVT测试，软件工程师进行缺陷修改
      • 模板/标准/工具
        • 《测试报告》
  • 软件管理专题
    • 软件管理“V模型”
      • 在一个软件为主的研发项目中，建议留出至少20%的时间用于需求分析，留出至少20%的时间用于概要设计和详细设计，编码时间一般不超过项目时间的40%，留出至少20%的时间用于验收测试，专职的技术经理负责根据系统的用例和设计进行编码与代码检查，建立标准的单元测试管理流程和文档体系
      • 在一个软件为主的研发项目中，建议留出至少20%的时间用于需求分析，留出至少20%的时间用于概要设计和详细设计，编码时间一般不超过项目时间的40%，留出至少20%的时间用于验收测试，专职的技术经理负责根据系统的用例和设计进行编码与代码检查，建立标准的单元测试管理流程和文档体系。
    • 软件概要设计原则
      • 总体原则和方法：
        • 由粗到细、互相结合、定性分析和定量分析相结合、模型化，考虑系统的一般性、关联性、整体性和层次性；
      • 分解协调：
        • 分解是指将一个复杂的系统分解为若干个子系统。协调是系统内协调，即根据系统的结构、功能、目标的要求，使各个子系统之间协调配合。在各个子系统局部优化的基础上，通过内部平衡的协调控制，实现系统的整体优化；
      • 屏蔽抽象：
        • 从简单的框架开始，隐含细节；
      • 一致性：
        • 统一的规范、统一的标准、统一的文件模式，每个模块应当有一个统一命名的容易理解的名字；
      • 编码：
        • 由外向内；
      • 面向用户：
        • 概要设计是对于按钮按下后系统怎么做的简要说明；
      • 模块、组件的充分独立性、封闭性；
      • 考虑静态结构与动态运行；
      • 每个逻辑对象都应当说明其所处物理对象；
      • 每个物理对象都有合适的开发人员，并且有利于分工与组装；
      • 确立每个构架视图的整体结构，视图的详细组织结构、元素的分组，以及这些主要分组之间的接口；
      • 必要的人员储备及培训，软件构架与使用的技术平台密切相关，具体的软件构架人员应当具备使用这些平台的软件开发经验；
      • 通过需求功能与设计模块之间的列表对应，检查每个需求功能是否都有相应的模块来实现，保证需求功能的可追溯性和需求实现模块的完整性，同时可以检查重复和不必要的模块；
      • 在需求调研分析过程中，对业务处理过程了解完整性和准确性。调查了解清楚所有的业务流程才能设计出适合各流程业务节点用户业务特点和习惯的软件；
      • 进行软件概要设计时，要尽量排除业务流程的制约，把流程中的各项业务结点工作作为独立的对象，设计成独立的模块，充分考虑他们与其他各种业务对象模块的接口，在流程之间通过业务对象模块的相互调用实现各种业务。
    • 8.3.3 软件配置与发布
      • 软件配置管理简称SCM（SoftwareConfigurationManagement的缩写），是在团队开发中，标识、控制和管理软件变更的一种管理。
      • ♢专职的配置经理订立与执行软件发布管理计划；
      • ♢建立标准的软件变更管理流程，收集上线系统的缺陷及功能扩展；
      • ♢组建变更控制委员会来审批软件变更请求，必须严格管理上线系统的版本修改，维护人员不得随意更改上线版本，以便保证已修复的缺陷，在系统升级后不会重复出现；
      • ♢采用发布管理工具来管理软件的修改和发布过程，在每次版本更新时都应提交一份详细的发布版本说明，描述在新版本中修复了哪些缺陷、增加了哪些新功能，以便用户顺利进行系统升级。
    • 8.3.4 软件质量保证及审核
      • 
      • 软件质量保证方式包括结对编程，保证软件测试时间，配置技术背景的QA，独立于项目组的QA，按阶段进行正式技术评审。
    • 软件测试
      • 
      • 一般测试通过标准是：单元功能同设计需求一致，规定的路径覆盖率及覆盖类达到要求，且单元执行正确，所规定的测试手段被使用，且单元执行正确，对残留错误有合法解释或被认可暂留，致命和严重类缺陷为0，一般类缺陷小于1%。
    • 8.3.6 软件质量
      • 
    • 8.3.7 软件管理改善路径图
      • 
      • 改善软件管理过程需要首先保证输出的质量，其次要减少“救火”式行为，从“软件是测试出来”向“软件是设计出来”转变
  • 敏捷软件开发
    • 
    • 前言
      • 信息时代需求变化更快，企业核心竞争力是快速交付
      • 据业界调查显示，45%的软件特性客户没有使用，一个50人的开发团队，每人平均30%时间用于编码，70%的时间用于与客户和其他成员交流。客户一开始很难想清楚真正要的东西，一般是在过程中逐步发现真正需求的，应该通过不断地向客户交付可用的产品，启发客户逐步发现真正的需求
      • 敏捷开发的特点包括把复杂的问题分解成一系列相对简单的问题，早期的迭代解决风险最高的问题，每次迭代都增加系统的功能并产生一个可运行的结果，每次迭代都包括有测试工作，支持动态联盟和虚拟组织，轻量级的开发过程，基于时间JustEnough，并行，基于组件的软件工程等
      • 迭代化开发可以提前识别和避免风险
    • 敏捷宣言
      • 个体和交互 胜过过程和工具
      • 可以工作的软件 胜过面面俱到的文档
      • 客户合作胜过 合同 谈判
      • 响应变化胜过 遵循计划
    • 敏捷团队3种角色职
      • 
    • 敏捷实践概览
      • 概览
        • 迭代开发
          • 
      • 团队
        • 完整团队
          • 
      • 工作件
        • 产品Backlog
          • 
        • 迭代Backlog
          • 
          • 迭代Backlog。只有产品主管才能设置迭代的优先级。客户或者开发人员提出新需求或新任务时应该和产品主管及整个团队讨论，明确任务的价值和优先级之后，再决定是否可以把任务放到当前的迭代Backlog上。如果一定要按期完成工作，就得保证产品backlog的完整，并做好估算。哪怕需求信息量很小，有估算也比没估算的好。把估算跟团队生产率合并以后，制定出的计划就更容易执行和实现
        • 完成标准
          • 
      • 管理实践
        • 迭代计划会议
          • 
        • 每日站立会议
          • 
          • 每日站立会议。目的是加强团队交流和信息共享，互相了解彼此都在做什么工作、完成了什么任务。每日的信息传递可以让每个人有更多的机会了解整个项目的业务和技术状况。如果在工作中遇到障碍或问题，也可以提出来请求大家的帮助。一般在敏捷团队中，遇到问题建议当场就提出来，或直接去找相关的同事，问他们有没有处理过类似的问题或者提供解决问题的建议。每日站立会议促使每个人在早上就做好一天的工作计划。每个人一天的工作就会有明确具体的目标，直接提高每个人每天的工作效率。每日站立会议最佳的时间是早上上班的时候，例如每天早上9：30按时举行的晨会，解决障碍和问题，沟通一天的工作安排，然后全身心地投入一天的工作中。每日站立会议不是每天的工作报告，也不是项目经理进行工作检查。项目经理应该营造一个安全的会议氛围，让每个人都愿意说出真正发生的事情，就算是昨天遇到技术问题没有任何的工作成果，也应该谅解并给出建议。每日站立会议时可以端杯饮料，很轻松地围成一圈，说说笑笑，会议结束后就开始一天的工作。
        • 可视化管理
          • 
          • 明确短期目标。如果让一个团队做半年的详细工作计划非常困难，但如果是做2周的工作计划是比较容易实现的。假设客户有100件事情要做，但团队在一个迭代（一般是2周左右）中，只能完成20件事情，建议明确告诉客户，一个迭代的时间周期里我们只可以完成20件事情，那么先开发其中20件最有价值的东西。根据项目团队的经验做好一个合理的2周计划应该不难，相对的计划会很准确，而且前面一个迭代的工作量，是这个迭代最好的参照
        • 迭代验收
          • 
        • 迭代回顾会议
          • 
      • 技术实践
        • 用户故事
          • 
        • 结对编程
          • 
        • 测试驱动开发
          • 
        • 持续集成
          • 
    • 敏捷软件开发典型7个场景
      • PO和开发团队对产品业务目标达成共识
      • PO建立和维护产品需求列表，需求会不断新增和改变，并进行优先级排序
      • PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发
      • 开发团队细化本轮迭代需求，并按照需求的优先级依次在本轮迭代完成
      • 开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明
      • PO对每轮迭代（2～4周）交付的可工作软件进行现场验收和反馈
      • 回到第3步，开始下一轮迭代
    • 实施敏捷的9个步骤
      • 思想动员
        • 
      • 差距分析
        • 
      • 环境和工具准备
        • 
      • 敏捷实践技能准备，技术能力准备
        • 
      • 确定开发过程和准备应用的实践
        • 
      • 敏捷实施
        • 
      • 回顾评估与调整改进
        • 
      • 激励表彰
        • 
      • 项目结束总结
        • 
  • 软件输出文档模板
    • 软件需求规格说明书模板
      • 简介
        • 
      • 总体概述
        • 
      • 具体需求
        • 
      • 总体设计约束
        • 
      • 软件质量特性
        • 
      • 其它需求
        • 
      • 需求分级
        • 
      • 验收准则
        • 
    • 软件概要设计说明书模板
      • 概述
        • 
      • 设计约束
        • 
      • 总体设计
        • 
      • 接口设计
        • 
      • 系统数据结构
        • 
      • 模块定义
        • 
      • 安装/运行/配置
        • 
      • 软件调试/测试方法
        • 
    • 软件详细设计说明书模板
      • 
      • 概述
      • 模块架构
      • 数据结构
      • 算法和逻辑
      • 模块描述
      • 类/对象接口
      • 性能需求
      • 其它需求
      • 安装/运行/配置
    • 软件集成测试评审报告模板
      • 
      • 评审要点
      • 评审意见
      • 项目组反馈意见
      • 评审结论
  • 软件评审要素
    • 软件任务书评审检查要素
      • 
      • 资源和进度
      • 技术内容
      • 项目费用
    • 软件需求分析评审检查要素
      • 
      • 资源和进度
      • 需求内容
      • 需求变更
    • 软件概要设计评审要素
      • 
      • 资源和进度
        • 
      • 依从性
        • 
      • 功能性
        • 
      • 完整性
        • 
      • 一致性
        • 
      • 可行性
        • 
      • 数据使用
        • 
      • 接口
        • 
      • 可维护性
        • 
      • 可靠性
        • 
      • 性能
        • 
      • 安全性
        • 
    • 软件详细设计评审检查要素
      •  
      • 资源和进度
        • 
      • 依从性
        • 
      • 功能性
        • 
      • 一致性
        • 
      • 数据使用
        • 
      • 接口
        • 
      • 可靠性
        • 
      • 清晰性
        • 
      • 可追溯性
        • 
      • 易测性
        • 
      • 性能
        • 
      • 可维护性
        • 
    • 软件编码和单元测试评审检查要素
      • 
      • 资源和进度
      • 编码和测试
    • 代码走查评审要素
      • 
      • 代码走查评审要素
    • 软件集成测试评审检查要素
      • 
      • 资源和进度
      • 测试过程
    • 软件配置项测试评审检查要素
      • 
      • 资源和进度
      • 技术内容
• 测试管理
  • 测试是产品成败的关键要素之一。国内企业研发由于交期或者能力水平原因，对测试普遍不关注，无法保证产品的质量。
  • 测试管理常见的问题
    • 
    • 测试前
    • 测试中
    • 测试后
    • 测试过程
  • 测试过程
    • 
    • 测试分类
      • SIV测试，系统集成验证System Integration Verify；
      • 原型机测试=SDV测试，系统设计验证System DesignVerify；
      • 功能样机测试、型式试验=SIT测试，系统集成测试Systemintegration Test；
      • 组织面向制造测试、中试产品测试=SVT测试，系统确认测试System VerficationTest；
    • 测试类型或阶段
      • 
      • 测试分为三个阶段
        • 
        • 单元测试
        • 集成测试
        • 系统测试
      • 集成测试也是产品最关键的一步测试，如果问题较多就把产品送到测试部，会造成反复测试，从而浪费人力、物力资源，延误工期
      • 在确定测试的范围时，一个需要考虑的重要问题是这个产品有多少是可测试的。一个有价值的功能一定是可测试的，如果不能测试，这个功能要么是没有价值，要么是没有描述清楚。制定测试策略时先测试优先级最高的需求，对新的功能及修改旧功能的代码优先进行测试，测试那些最有可能出现问题的地方，关注最终用户最常使用的功能和配置情况，使用等价类划分技术和边界值分析技术来减少测试工作量
    • 测试步骤
      • 
      • 测试需求分析和计划
      • 测试方案设计
      • 测试用例编写
      • 测试执行
      • 测试评估
      • 缺陷跟踪
      • 测试报告
    • 测试活动对照表
      • 功能测试
      • 用户界面测试
      • 性能/指标测试
      • 详细说明
        • 
      • 负载测试
      • 压力测试
      • 容量测试
      • 外部接口测试
      • 软件协议一致性测试
      • 容限/容错测试
      • 电磁兼容性（EMC）测试
      • 防雷测试
      • 安全测试
      • 热测试
      • 环境测试（包括高低温/温度等）
      • 可靠性强化和鉴定测试
      • 详细说明
        • 
      • 回归测试
      • 需要的特别测试（如可安装性、可维护性测试等）
      • 详细说明
        • 
    • 测试跟踪矩阵
      • 
      • 需求编号应与用户需求说明编号一致，每一条需求应至少被一条（但不限于一条）测试用例所覆盖
      • 每一条测试用例至少被一条（但不限于一条）测试规程所覆盖
      • 规程的编号采用独立标号的方式，一般规则为：项目名称+项目测试阶段+序号
    • 测试内容及通过条件
      • 
      • 硬件原型样机
      • 硬件功能样机
      • 硬件小批量试产阶段
      • 软件原型样机
      • 软件功能样机
      • 软件小批量试产
    • 原型样机测试进入和退出标准
      • 进入标准
      • 中断
      • 回归
      • 详细说明
        • 
      • 退出
        • 详细说明
          • 
    • BETA测试过程
      • BETA需求
      • 指定BETA测试负责人
      • 更新测试计划，制定测试方案
      • 详细说明
        • 
      • 寻找BETA测试客户
      • 组织测试方案与计划评审
      • 更新BETA测试方案
      • 查询BETA测试产品是否库存
      • 转研发加工单生产流程
      • BETA测试前准备
      • 发送BETA测试产品（样品）
      • 进行BETA测试
      • 编写BETA测试报告
      • 详细说明
        • 
    • 面向制造测试
      • 要点
        • 面向制造测试是在验证阶段针对生产制造而进行的针对性测试，其主要目的是确保发货产品的功能性能满足规格要求，并保证大批量生产时的可制造性
        • 面向制造测试通过小批量试生产过程来保证设计的完整性，不应该有新的需求或设计方面的验证，而应针对TR5的结论，对产品进行的有针对性的专题测试，测试的形式多为抽检方式
      • 面向制造测试主要考虑以下几个方面
        • 发货的质量要求、生产良率要求，以及量产时自动测试的效率要求
        • 面向制造测试的测试重点，包括重点测试对象和重点测试向量
        • 对测试装备的依赖关系分析及措施
      • 面向制造测试内容
        • 面向制造测试需求
        • 设计测试方案
        • 提供测试规格
        • 面向制造测试准备的进度计划
        • 资源计划（包括人力资源、环境资源、工具等）
        • 风险分析和控制计划
        • 面向制造测试的交付件
          • 面向制造测试报告
          • 测试工具
          • 测试代码
          • 测试向量
          • 测试规格
        • 面向制造测试的进入和退出标准
          • 
    • 测试度量
      • 
      • 测试生产率
      • 工作量偏差率
      • 发现缺陷密度
      • 测试问题严重性
      • 测试用例的问题发现效率
      • 缺陷密度
      • 测试覆盖度量
      • 问题漏测率
      • 遗留缺陷密度
  • 缺陷管理
    • 缺陷模板
      • 
    • 缺陷流程
      • 
    • 软件测试缺陷类型
      • 
  • 测试管理输出文档模板
    • 测试策略
      • 
      • 概述
      • 测试综述
      • 系统测试
      • 人力资源及工作量
      • 质量过程
    • 测试计划
      • 
      • 概述
      • 测试准备
      • 测试计划
      • 测试用例
      • 培训计划
      • 其它
    • 测试方案
      • 
      • 概述
      • 需求跟踪
      • 测试内容
      • 测试环境
      • 测试用例
      • 测试通过准则
      • 评审报告
    • 测试用例
      • 
      • 用例编号
      • 用例名称
      • 需求描述
      • 测试目的
      • 测试类别
      • 测试对象
      • 用例级别
      • 测试工具
      • 前置条件
      • 测试步骤/测试方法
      • 测试预期结果
      • 测试结果
      • 测试结论
      • 测试工程师
      • 测试日期
      • 备注
    • 测试报告
      • 
      • 概述
      • 测试概要
      • 测试结果及发现
      • 测试结论
      • 分析摘要
      • 测试资源消耗
    • 测试总结
      • 
      • 测试主要版次
      • 测试内容
      • 测试遗留问题
      • 测试结论
      • 建议
  • 测试评审要素
    • 测试策略评审要素
      • 
    • 测试计划评审要素
      • 
    • 单元测试计划评审要素
      • 
    • 集成测试计划评审要素
      • 
    • 系统测试计划评审要素
      • 
    • 测试用例评审要素
      • 
    • BETA测试评审要素
      • 
  • 测试管理常见的问题对策
    • 是否需要独立的中试部
      • 
    • 如何解决测试和研发的冲突
      • 尽早开始合作。如果只在项目测试环节测试人员才出现并寻找缺陷，测试人员会遇到阻力。产品开发的质量被完全处于局外的人所挑战，此时测试人员就会被当作威胁而不是支持。测试人员在设计初期能够参与，这样研发人员把测试人员的工作看作是帮助自己提高工作质量的一种方式，测试人员也不再是挑毛病、缺陷的局外人
      • 责任与权利相符。测试人员在初期设计阶段能够参与或提供反馈，不能让测试部门夹在中间，责任很大而权力很小或没有
      • 带着质量意识研发。通常研发人员和测试人员在质量的含义上有着不同的见解，不要指望能找到一个永远正确的答案，测试驱动式开发是一种流行的在初期就引入质量管理的开发模式，它使测试及质量保障与每个功能特性的设计结为一体
      • 只有主管能发动和结束“战争”。如果在开发团队中发生冲突，就要从主管身上找原因。主管们应敢于进取，明智地承认这些问题，并带领双方制定一个如何改变的协作计划
    • 如何进行外部测试
      • 外部测试指国家管理机构（国家工商行政管理局、国家质量监督检验检疫局、行业管理机构等）、客户要求的、组织的或委托组织的对公司的产品、技术、解决方案所做的测试，或公司主动发起的涉外测试，以及公司在第三方权威测试机构进行的委托测试
      • 外部测试的四个阶段
        • 
        • 测试需求阶段
          • 
        • 测试准备阶段
          • 
        • 正式测试阶段
          • 
        • 测试结果跟踪阶段
          • 
    • 常见的测试风险有哪些
      • 
      • 软件模拟环境测试方法的局限性
      • 功能点不全
      • 功能点不细
      • 验证策略不完善
      • Corner case和Error case 太少
    • 测试管理的提升路径有哪些
      • 
      • 开展系统测试工作
      • 开展专项测试、测试工具引人
      • 需求可测试分析、集成测试、建立测试标准