最漫长的一次交付项目复盘

最近经历了入职公司最长的一个项目,前后跨度3年,更换3任PM,SE等关键角色;本次项目周期长,有美国的助攻(中间暂停3个月左右),有需求范围持续变更等客观因素造成,也有项目管理中人为原因造成;现将项目的过程几个典型的片段进行回顾,最后做下项目管理的心得小结。

第一个TR5交付时整体需求大概有5000+,组织SE,开发等澄清保留3000+;设计是项目的源头,建议定期和开发,测试澄清一次,尤其人员变更,项目范围变更等时需要主动组织开展;

一到版本转测试管理软件的同事就通宵达旦合入代码和验证,转测试后经常测试出低级问题(配套表不正确,不能升级,升级后启动异常等)造成版本反复被打回,如果一个事件反复出现,背后一定有更深层次的原因(组织,流程,代码架构等深层次原因)。

人一生少犯同样的错误,能够大大的提升个人的成功率,组织如果能够积累,少犯相同的错误,尤其是低级错误,那么这个组织就能不断高效高质交付。

一直没有的系统测试看护,项目组从立项开始就没有系统测试人员,每次测试是都是测试经理多方求助才有人力完成相关测试。初期还有一个独立小组,负责产品的交付,还容易协调到人力;后期组织解散,人力不断升级,一会软件人员测试下,一会硬件测试测试下……总之系统测试能力一直没有建设起来。

几乎没有按时达成的月度计划:版本从转测试初期,月度计划基本没有按时,往往因为人力原因延期3~5周后转测试,转测试后低级问题多,又反复需要出版本,版本就陷入的循环:延期,出问题,延期转测试……最终版本火车也没法保证,版本多次进行PR延期交付时间点。

心得

  1. 交付项目最好在6~8个月结项,长时间不结项的项目是很可能出问题的;增量版本单独立项,单独分配人力;
  2. 项目立项只谈了立项的进度和费用情况,但时间人力投入太少;
  3. PM很关键,要持续跟踪,交付计划按月度达成,就是平时少量延期也不至于3年才出来;
  4. 每个版本交付件要齐全,能够验证,减少反复;
  5. 尽快进行生产装备的试制,打通生产制造流程;
  6. 从开始就要全系统配合的测试,支持的单板,部件,场景覆盖;
  7. 人员流动做好工作交接,形成组织资产;
  8. 配套产品一起转测试,一起管理起来,作为整体进行系统测试;
  9. 拉通下游一起开展联调和测试,尤其是满框业务的压力测试;
  10. 需求进行定时澄清;
<think>嗯,用户之前让我介绍了华为项目管理中的交付流程,现在他们进一步要求基于这个交付流程来写一个项目的整个交付流程的审批流。我需要先理解他们的具体需求。他们可能是在规划自己的项目,或者想要参考华为的流程来优化自己的审批机制。 首先,用户提到的“交付流程的审批流”应该是指各个阶段中需要哪些审批环节,由谁负责,以及审批的具体内容是什么。我需要回顾之前提供的华为交付流程的五个阶段:准备、计划、执行与监控、交付与验收、收尾与复盘。然后,在每个阶段中,确定关键的审批节点。 比如,在项目准备阶段,项目任务书(Charter)需要管理层评审。这时候可能需要高层领导的审批,比如项目管理委员会(PMO)或者门负责人。接下来,在计划阶段,基线确定后可能需要项目Sponsor或相关干系人的审批。 执行阶段中的变更管理可能需要变更控制委员会(CCB)的审批。验收阶段需要客户的正式签署,这也是一个关键的审批点。收尾阶段的合同关闭和财务结算可能需要财务门和法务的审批。 另外,用户可能希望这个审批流程清晰、结构化,有明确的角色和步骤。可能需要用流程图或分阶段列表的形式来展示,每个阶段的关键审批节点、审批人、审批内容以及输出文档。 还要注意华为的特色,比如铁三角团队、数字化平台的应用,可能在审批流程中也会有体现,比如使用特定的系统进行电子审批,或者需要不同角色的协同审批。 需要确保每个审批环节都有明确的目的,避免冗余,同时保证关键节点的控制,比如范围变更、预算调整等重大事项必须经过严格审批。还要考虑不同规模项目的审批流程是否有所差异,是否需要灵活调整,但用户可能希望一个标准化的流程作为参考。 可能还需要包括一些模板或示例,比如项目任务书模板、变更请求表等,但用户目前可能只需要流程的结构,而不是具体文档。后,总结时需要强调流程的闭环管理和以客户为中心的核心原则,确保审批流服务于项目成功和客户满意。 在组织内容时,可以分阶段列出每个阶段的审批节点,每个节点包括审批事项、审批人、审批依据和输出结果。这样用户能够一目了然地看到整个流程中的关键审批环节,方便他们应用到实际项目管理中。</think>以下是基于华为项目管理交付流程设计的项目全生命周期**审批流程框架**,结合关键角色、审批节点及核心控制点,适用于中大型复杂项目场景: --- ### **一、审批流程设计原则** 1. **权责对等**:分层分级授权,避免过度审批或失控。 2. **风险导向**:高风险节点强制审批(如范围/成本变更)。 3. **效率优先**:简化低风险环节,采用电子化会签。 4. **客户参与**:关键验收节点需客户方签字确认。 --- ### **二、分阶段审批流程详解** #### **1. 项目启动审批** - **审批事项**:项目任务书(Charter) - **审批人**: - 发起人:客户经理/事业负责人 - 决策层:PMO(项目管理办公室)+ 财务总监 - **审批依据**: - 商业可行性分析(ROI ≥ 15%) - 资源匹配度(团队/供应链) - **输出**:签署的《项目立项决议书》 --- #### **2. 项目计划审批** - **审批事项**:项目基线(范围/进度/成本) - **审批人**: - 交付经理 + 解决方案架构师 - 客户代表(联合评审) - **审批依据**: - WBS分解完整性(覆盖合同SOW) - 风险储备金合理性(建议≥总预算5%) - **输出**:批准的《项目基线计划》 --- #### **3. 执行过程关键审批** - **3.1 重大变更审批** - **触发条件**:范围变更、成本超支≥10%、进度延迟≥15天 - **审批人**:CCB(变更控制委员会,含客户代表) - **输出**:签署的《变更请求单》(CR Form) - **3.2 里程碑评审** - **节点示例**:需求冻结、系统设计完成、UAT通过 - **审批人**:技术委员会 + 质量保障(QA) - **输出**:《阶段验收报告》 --- #### **4. 交付验收审批** - **4.1 预验收审批** - **审批人**:客户技术团队 + 华为交付总监 - **依据**:测试报告(缺陷率≤0.1%) - **输出**:《预验收确认书》 - **4.2 终验审批** - **审批人**:客户CEO/授权代表 + 华为区域总裁 - **依据**:运维稳定性报告(连续30天无重大故障) - **输出**:《项目终验证书》 --- #### **5. 项目收尾审批** - **5.1 财务关闭审批** - **审批人**:财务 + 法务 - **依据**:应收账款核对单、尾款到账凭证 - **输出**:《项目财务结项单》 - **5.2 知识资产归档审批** - **审批人**:PMO知识库管理员 - **依据**:经验总结报告(含3个以上改进点) - **输出**:《组织过程资产入库记录》 --- ### **三、审批流程支撑机制** 1. **数字化平台**: - 使用华为内系统(如ePMIS)实现电子化审批流,自动触发提醒与催办。 2. **紧急通道**: - 对客户紧急需求开通“绿色通道”,24小时内完成特批(需记录备案)。 3. **审计回溯**: - 每季度由内审抽查审批合规性,违规操作纳入绩效考核。 --- ### **四、流程图示意(简化版)** ``` 立项申请 → PMO初审 → 决策层终审 → 基线审批 → 执行监控(变更/里程碑)→ 验收审批 → 收尾闭环 ↑ | | 风险超限驳回 预算不足驳回 客户异议驳回 ``` --- ### **关键控制点提醒** - **风险阈值**:成本/进度偏差超限必须升级审批(如超支≥20%需董事会介入)。 - **客户否决权**:UAT测试未通过时,客户有权要求返工并重新审批。 - **合规红线**:未经CCB批准的变更,即使完成也视为无效交付。 通过该审批流,华为实现了**“既要流程规范,又要快速响应”**的平衡,既能防范重大风险,又避免陷入过度官僚化。实际应用中可根据项目规模(如千万级vs亿元级)动态调整审批层级。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值