硬件项目开发流程大纲修订与试点宣贯.pptxVIP

硬件大纲试点宣贯赵新新2021-3-10与场景亲密接触做方案创新专家

目录硬件大纲修订范围硬件大纲修订核心思路试点项目重点关注事项

目录硬件大纲修订范围

硬件大纲优化背景及范围

《PO05-硬件项目开发流程大纲》中和研发设计相关的领域（结构、热、EMC、安规、工艺、硬件测试、互联、模拟、开关电源、部品、可靠性、FPGA/CPLD、CPU、成本、射频、天线等）的整合和优化。包括配套的管理规范和模板的的新增修订：变更管理流程、项目管理规范、配置管理规范、质量管理规范、TR技术评审等。

目录硬件大纲优化思路

硬件大纲优化思路

1.大纲从整体上将经营决策层、技术评审决策层、项目管理层面（包括变更管理）、项目执行层、第三方监控层区分开；

明确职责：分层管理责任执行责任监控责任端到端意识经营决策层技术评审决策层项目管理层项目执行层第三方监控层

硬件大纲优化思路

2.主干流程中的活动将所有活动的评审动作合并到活动主体中，默认活动交付是评审过的交付件。

端到端管理意识活动名称统一：名词+动词大纲层面的活动是功能层面，需要完成交付功能。子流程里的活动是操作层面，需要指导具体操作。统一流程语言拟制/设计完成≠交付完成拟制/设计完成+评审完成（意见关闭）=交付完成

硬件大纲优化思路

3.大纲中保留的均为各专业域的关键活动及验证，一些更详细的活动在各域的子流程中体现。

大纲中活动保留原则：涉及多个领域/专业域的协同。关注入口和出口。目的：主干轻，更灵活。过程下沉到专业域,专业域改进权责明确，赋能空间大。旧大纲新大纲

硬件大纲优化思路

4.职责分工部分根据最新的项目管理组织架构及角色定位做修订。（项目管理架构会体现在《项目管理计划》中）。

硬件大纲优化思路

5.负责人与参与者区分开，通过评审操作指南细化管理角色、执行角色、评审角色、知悉角色（RACI角色）。

大纲层面定义：负责人与参与人分开参与人建议是到领域而非具体角色的颗粒度（保持灵活性）

硬件大纲优化思路配套评审指南定义：通过RACI矩阵分析明确具体落地层面的角色需要达成共识：系统里的角色设置是可参考，项目仍可根据实际情况去识别干系人，灵活添加。

硬件大纲优化思路

6.阶段名称修订保持与IPD一致。旧大纲新大纲

硬件大纲优化思路

7.增加变更管理规范：硬件PM及各级管理者为变更管理的责任人。变更闭环

硬件大纲优化思路

8.增加TR准入准出，充分识别质量风险。

严格阶段的准入准出，资源管道管理

硬件大纲优化核心思路一览序号核心痛点优化内容可衡量指标1大纲定义：原活动与实际执行情况不符合，起不到指导作用，原活动的颗粒度不一，大纲层面和专业域子流程层面的活动逻辑上不清晰。

1.重新梳理实际执行现状，互赖关系的整理,依据项目管理的架构梳理大纲层面保留的关键控制活动。

2.将能力提升部分内容剔除，大纲活动定义仅明确管理角色、执行支撑角色、输入、输出，活动交付标准，角色定义在项目管理架构中到管理层（PMSEPTM、专业组长），给到各级管理者灵活的执行空间，同时明确管理责任。流程质量维度

全：关键活动覆盖是否全：增补优化活动数量

大纲修订前后新增、修改、删除活动的数据。2需求方案阶段投入不足，直接开发，后期变更多，返工多1。重点梳理概念计划阶段活动的输入输出，活动定义，明确SE职责，PM职责（包括平台SE和平台PM)，以及最小依赖，确保质量的前提下允许项目迭代进行。需求传递变更过程规范性：

1.QA审核需求传递、变更是否规范闭环。

需求变更是否受控：

1.需求变更次数

2.例外决策次数：PDCP之后提交IPMT决策的次数

3.需求变更率：TR2之后需求新增+删除+修改/TR2阶段准出时的需求基线数。

3变更没有控制，设计文件版本控制混乱，计划变更、需求变更不受控，配置管理缺失1.增加变更管理规范，变更管理端到端闭环，设置快速变更通道和IPMT决策变更通道，确保需求、计划、成本等的变更受控。

2.增加阶段的配置审核活动，确保配置项基线化的管理和变更的受控管理。4TR点准入准出执行不严格，文档在最后一个阶段补，无效评审活动多增加TR点准入准出条件，符合则发起，不符合则继续该阶段活动，同时梳理最小依赖关系，允许项目在保证项目质量的前提下进行活动的迭代进行，同时做好变更的控制和配置管理。流程质量维度：

有效活动数

5交付件同行评审走虚，没有起到真正的质量把关1.按照RACI重新梳理项目参与人员的角色职责

2.QA评估报告作为准入准出的必要条件，第三方的监控。

3.度量指标里增加评审相关的指标统计，数据说话。评审有效性:

泄露故障定位原因占比：

需求和设计6流程意识：端到端的管理角色职责不明确，沟通成本高1.配套增加项目管理规范，明确项目管理架构和端到端的管理责任主