企业官网建设流程全解析

简介：这是华为IPD项目管理方法论“六步一法”的内部交流PDF，源自华为公司国内项目管理部2008年7月的分享资料，系统阐述了这套框架的完整过程。文档将项目划分为定义、计划、开发、验证、发布、学习与改善六个阶段，并在每个阶段末设置决策评审（Gate）作为关键控制点，确保项目在进入下一阶段前达到预定标准。内容具体覆盖市场调研、竞品分析、项目计划制定、资源分配、里程碑设置、产品测试验证以及项目复盘等操作细节，尤其对跨部门协作和流程化管控的实践方法讲解透彻。资源为单一PDF文件，大小约3.01MB，共1个文件，排版紧凑、结构清晰，便于直接研读。目前已有262人学习下载，适合产品研发、项目管理、PMO从业者及对IPD感兴趣的管理层参考，可据此优化自身项目的管理节奏与评审机制。

1. 华为IPD项目管理六步一法：为什么同一个团队，换一套流程就能把交付拉回来

一个新产品项目，20个人，定好了6个月后的GA节点，前两个月按部就班，第三个月开始天天救火：硬件等改板、软件等环境、测试等样机。这种场景我在做研发流程改进时见过太多。华为IPD项目管理里反复出现的那套“六步一法”，目标就是把这种无序收敛成一条可检查的主线：六步管住项目从立项到收尾的六个关键动作，一法管住贯穿全程的风险、问题和变更。它不是另一个理论框架，而是一份能直接拿来做项目计划、设门禁、开评审会的操作抓手；适合正在往IPD模式转的研发团队，也适合被多项目并行搞到失控的交付团队。

2. 拆开六步一法：六步的次序、一法的闭环，以及它和PMBOK的差别

这份材料之所以叫“交流”而不是“标准”，本身就说明它不是让你照本宣科的操作手册，而是华为在推行IPD过程中沉淀下来的经验总结。所以六步在各地落地时叫法不完全一致，这不影响它背后的骨架。我见过比较常见的一种拆分，是把项目生命周期切成六个可验收的动作：启动、计划、组织、执行、监控、收尾。一法，则是把这六步里反复出现的“问题处置方式”统一成一套闭环。

2.1 六步的实际骨架：从概念到GA的六个管理关口

IPD和普通项目管理最大的区别在于：项目成败不是项目经理一个人拍板，而是由一组跨功能团队在固定的管理关口上做投资决策。六步一法里的六步，本质上就是把项目生命周期切成了六个“可以停下来检查”的管理关口，每一关都有明确的输入、动作和输出。

我在实际项目里通常会把它和IPD阶段对齐成下面这张表：

这张表的价值在于“对应IPD阶段”那一列：每个步骤不是孤立的动作，而是踩在IPD的门禁节奏上。启动必须对应概念阶段的DCP，收尾必须对应GA之后的移交，中间的执行和评审必须跟着技术评审节点走。项目经理如果抛开IPD阶段硬套六步，就会出现“流程上在第二步，技术其实还停在第一轮方案验证”这种失真。

六个步骤的权重并不平均。从项目复盘数据看，大部分偏差来自前两步。IPD项目最昂贵的返工发生在方案阶段，如果计划阶段的WBS粒度超过7天，后面所有监控都会变成空转。所以把时间花在前面不是低效，是省钱。我跟项目经理说得最多的一句话是：前两步省下的时间，后面会用十倍返工还回来。

2.2 “一法”不是工具：是一套统一的问题处置闭环

“一法”经常被理解成某个工具或某个模板，实际它更像一条贯穿六步的闭环规则：识别、登记、定Owner、定目标日期、跟踪、验证关闭。任何风险、问题、变更，都走同一个闭环，不允许绕过台账私下解决。

为什么华为要把这一条单独拎出来？因为IPD项目是跨功能协作，硬件、软件、结构、测试、供应各管一段。如果不统一闭环，就会出现几种常见局面：问题靠开会现场“喊一嗓子”安排，会后没人认；风险写在某个人脑子里，人一走信息就没了；变更直接改计划，事后谁都不承认改了。一法要根除的，正是这些“靠人情、靠记忆、靠个人责任心”驱动的管理方式。

落地时最朴素的标准：每一张风险、问题、变更单，字段必须齐全，状态必须有专人推进。字段可以精简，但不能缺“Owner、目标日期、当前状态、最新进展”四样。我见过有团队试图做一个几十字段的复杂系统，结果填表成本太高，两周就废了；反而Keep到一张共享表格时执行得很好。一法不是系统建设问题，是运作习惯问题。

2.3 和PMBOK、敏捷的差别：IPD项目管理为什么看重门禁

很多人初看六步会把它当成“又一个PMBOK流程”或者“瀑布模型”，其实是两码事。PMBOK按十大知识领域管理项目，敏捷按迭代批次交付功能，而IPD项目管理六步一法是按“阶段门禁”管理项目。差别在决策机制上：PMBOK里项目经理对项目绩效负责，可以自己拍板；IPD里项目能不能往下走，要由IPMT这类跨功能管理团队在DCP决策点拍板。

DCP和TR是IPD项目管理里最容易混淆的两个门禁。简单区分：DCP问“这个项目还值不值得投钱、投人、投时间”，是经营决策；TR问“这个产品的技术方案是否成熟到可以进入下一阶段”，是技术决策。六步里的第五步“评审监控”同时包含这两层。项目经理在准备评审材料时，不能只准备技术汇报，还要准备一份面向经营决策的建议书，明确写出来：建议GO还是NO GO，依据是什么，继续下去需要多少资源。

这也是为什么六步一法特别强调前置投入。IPD的前三个管理关口会层层筛掉不靠谱的项目，发现越早，损失越小。到了验证阶段再发现方向错了，人力、物料、市场窗口全搭进去。所以第六步第一步“启动”不是开个会就算，而是一个真正把目标、边界、资源投入讲清楚的决策关口。这一关不过，后面几步越努力越危险。

落到日常节奏上，一个IPD项目经理每天要看的是关键路径清单和问题台账，而不是甘特图；每周要开一次PDT例会，刷新风险、变更、行动项；每个DCP或TR之前要做一次门禁预检。这套节奏不是额外的负担，它就是把六步一法变成肌肉记忆的过程。

3. 把六步落到IPD流程里：每个阶段的交付件、评审门禁和一步一检查

框架理解了还不够，难点在于每一步具体做什么、产出什么、由谁来检查。这一章讲操作层的东西，按启动、计划、开发验证、发布收尾四个段落拆开。

3.1 启动和计划阶段：项目任务书、WBS基线、以及“不拉通不开工”

启动这一步，要避免“名字上叫项目、实际是任务”的状态。我通常要求团队先回答三个问题：第一，项目的目标市场是谁，哪些明确不做；第二，GA发布要达成哪些可验证指标；第三，项目开始前需要哪些部门给出书面资源承诺。这三个问题都落在项目任务书上，启动才算完整。很多项目的烂尾从立项时就注定了：目标是“做个平台”，资源是“各中心派人”，边界是“先干着再说”，后面所有评审都会在这些模糊点上打架。

计划这一步，核心是WBS和基线。WBS不要按组织架构拆，要按交付物拆；任务粒度控制在2到5天，最长不要超过5天。研发活动一旦超过一周还没有检查点，基本可以预判它会失控。WBS拆好后，进度基线、成本基线、质量基线要一起定，而不是只定一个日期。这里有一个实用的做法：让核心组每个成员背靠背先独立估算工作量，再把所有估算摆在桌上校准。直接开排期会时，前两个人一开口，后面的人很容易被锚定，独立估算可以降低这种心理偏差。

计划阶段还要把IPD的评审节点写进基线。我一般会让计划里至少标出三类时间点：DCP决策点、TR技术评审点、GA发布点，并且每个节点往前推3天安排“材料定稿日”，往前5天安排“材料预审日”。没有这两个缓冲，评审材料永远会在评审前一晚加班补。

一个常见误区是“不拉通就开工”。研发团队觉得计划是项目经理的事，各干各的，等到了集成阶段才发现接口对不上。六步一法在第二步结束时会给每个跨功能代表一张承诺清单，明确每个人在哪个时间点要交出什么、依赖哪个人。这个动作被很多团队叫“拉通”，本质是把所有隐性依赖亮出来，宁可今天在会上吵，不要三个月后在集成时报故障。

3.2 开发和验证阶段：按TR节奏看执行，而不是按周报看

执行和监控是六步里持续时间最长、最容易走样的两步。在IPD项目里，最好的执行监控节奏不是周报，而是TR节点。每个TR评审前，项目经理要做一次门禁预检：对照评审要素表，检查当前交付物是否齐套、已知问题是否有规避方案、剩余风险是否有人负责。如果答案是“不齐套”，就要提前预警并推动解决，而不是等到评审会上被评审专家指着材料问。

我习惯在开发阶段维持一份“关键路径清单”，而不是只看整体甘特图。关键路径上的任务每出现一天延误，都要在当天回答三个问题：是否可以并行、是否可以调整资源、是否可以缩小交付范围。很多项目到了后期才意识到关键路径上的某个任务已经延误两周，就是因为大家只看里程碑日期，忽略了中间任务的偏差累积。六步一法里的监控不是看进度颜色，而是看偏差归零动作是否发生。

验证阶段的重点是“缺陷不是坏消息，未暴露的缺陷才是坏消息”。所以验证活动要往前拉：单元测试、模块联调、系统测试都要在TR评审意见里闭环。一个实用指标叫“缺陷发现趋势”，每周新发现缺陷数和关闭数要形成可见对比。如果新发现数连续两周不降，说明验证还没收敛，这时候不要说“按时进入GA”，应该考虑把验证周期拉长，而不是把标准降低。这会得罪很多人，但做PM就是要扛这个压力。

我最常被问到的一个问题是：TR评审材料到底要准备什么。我的答案是，材料要能回答四件事：本阶段交付物清单及完成状态、技术指标达成情况、未解决问题和规避方案、下阶段计划。这四件事列成一张表，就是评审材料的骨架。花里胡哨的分析报告反而会让评审会偏离重点。

3.3 发布与收尾阶段：GA前Checklist和移交清单

走到GA，六步一法的最后两步常被当成体力活，正好相反，这里最出经验。GA之前必须过一份发布Checklist，至少要覆盖：产品版本齐套、已知问题清单和规避方案、客户支持计划、市场发布材料、供应准备情况。每一项必须有Owner和确认日期，不能是空项。我见过最典型的翻车是：研发觉得软件代码完成就能发，结果没有备件、没有文档、没有客服培训，发布当天客户一用就暴露。

收尾动作要包含三件事：未关闭项清零、文档归档、复盘。未关闭项不是“放一放”，而是每条都要指定解决版本或明确降级为已知问题；文档归档不能只靠自觉，要落到项目管理系统里；复盘会不要开成表彰会，要开成时间线回放，按顺序把每个节点的事实、决策、结果讲一遍，不追责，只提取可复用的动作项。

提示：收尾做得好不好，最能看出一个组织的项目管理成熟度。如果每个项目收尾都是“赶紧开完会去弄下一个”，说明六步一法在这个组织里只走了形式，还没长出能力。

4. “一法”的实操参数：问题、风险、变更三类记录的写法与Owner机制

一法之所以叫“法”，不是因为它规定了几个字段，而是它定了一套统一的处置规则。这里把三类记录的字段、填写边界和处理参数展开，可以直接抄成模板用。

4.1 问题记录的三段式：现象、根因、行动项

问题记录是六步里最常用的台账。很多团队把问题单写成一句话，比如“测试环境不稳定”，这没有价值。一法要求问题记录必须有三段：现象、根因、行动项。

现象要写“什么时间、哪里、发生了什么、影响是什么”，例如：“测试环境在3月2日上午不可用，原因是编译服务器磁盘满，5个测试用例阻塞1天”。根因要往下追一层，不能停在“服务器磁盘满”，要继续问“为什么没人监控磁盘水位”，答案往往是“运维监控覆盖有缺口”，这才是要解决的问题。行动项必须指定到自然人并给完成日期，不能写“加强监控”这种口号，要写“本周五前由某某配置磁盘水位告警，阈值80%”。

处理参数上，我通常定三条规则：问题单从登记到有人认领不超过24小时；状态每3天刷新一次；影响关键路径的问题单，项目经理每天过一遍。超过7天未关闭的问题单自动升级一级。这个升级动作要提前约定好，否则到现场临时升级就像在发脾气。

下面是一张我常用的问题单字段表，字段不多，但够用：

4.2 风险登记：概率、影响、应对策略一张表

风险不是问题，是“还没发生但可能发生”的事。一法里风险登记要量化，不能只写“进度有风险”。常见做法是用概率乘以影响给风险打分，影响面覆盖进度、成本、质量、市场、供应五个维度，每项分1到5级。分数超过12分的进核心风险台账，由项目经理直接跟踪。

风险应对策略按四类选：规避、减轻、转移、接受。规避是改变计划绕过风险；减轻是提前做预案降低概率或影响；转移是把风险移到另一个主体，比如供应商；接受是评估后认为可承受并记录监控。每一类策略后面都要挂一个“如果风险发生，第一动作是什么”。这个第一动作很重要，否则风险台账再漂亮，发生那一刻大家还是会慌。

我见过最无效的风险登记，是把“人力资源不足”写上去了事，没有概率等级、没有影响等级、没有应对策略，每周例会念一遍，念到项目结束也没解决。人力资源不足不是风险，而是常态约束，要写出具体的“缺哪个岗、少几个人、从什么时候开始影响关键路径”，然后落到行动项。风险登记表不是愿望清单，它是一份“我打算怎么办”的决策记录。

风险参数表可以这样设：概率等级按“低、中、高、极高”对应1到4分，影响等级按“影响<1天、1-3天、3-5天、超过关键路径>”对应1到4分。两者相乘，12分以上为核心风险，每月由项目经理向管理层汇报一次。

4.3 变更控制：CCB决策时效和紧急变更通道

IPD项目的需求变更，最伤人的不是变更本身，而是变更走了暗路。研发同事和产品经理私下沟通一句“这个功能先加上”，开发就真加了，最后进度炸了都没人记录。一法里的变更控制不复杂，但必须有：任何变更都要走统一的变更申请单，附影响分析，然后由变更控制委员会决策。

CCB的常见组成是项目经理、PDT核心代表、财务代表、市场或产品代表。一般变更建议48小时内决策，紧急变更走电话会议加事后补签。影响分析至少要覆盖四个维度：进度、成本、质量、市场。变更申请可以简洁，“增加A功能，影响开发周期约5天、测试约2天，质量影响低，市场需要度中，建议同意”，这就是一份说得过去的分析。可怕的是只写一句“客户要求”，没有任何量化的影响说明。

一个特别容易踩的规则问题：技术方案不完善时，不要用变更流程绕过技术评审。也就是说，重大技术路径调整不能只走CCB，还要先做一次技术评审。否则会出现“变更批准了、方案却是错的”这种组合，等于给项目埋了两个雷。

变更单上还需要留一列“变更提出日期”和“决策日期”，用于统计决断效率。如果一个项目里变更平均决策时间超过3天，就说明CCB运作偏慢，变更背后的需求其实一直在暗流涌动。

5. 六步一法落地的常见问题：流程僵化、Owner缺位、评审走样的排查

这一章写落地中最常遇到的五个问题。每条都按“现象、原因、解决”三个层次写，可以直接对着项目现状排查。

5.1 评审会开成汇报会

现象：DCP或TR评审会上，专家们第一次看到材料，主持人花40分钟把PPT从头念到尾，念完后大家提几句无关痛痒的感想，评审通过。项目实际风险一个都没在会场被认真评估。

原因：评审材料发出时间太晚，甚至开场才发；或者组织者没有把“会前预审”作为评审流程的硬性环节。材料不齐套的时候，评审会就只能变成事实说明会，评审专家根本没有足够时间形成意见。

解决：定两条硬规则。第一，评审材料至少提前48小时发出，同时提供一份“材料齐套检查表”；第二，评审会开场只汇报三件事：本阶段目标达成情况、偏差和原因、需要评审专家决策的问题。专家会前提交的意见要逐条有处理结论，会上只讨论分歧项。这两条不依赖强力领导，靠项目经理一个动作就能建立：准备评审议程时，把“预审意见处理表”列在第一位。

5.2 Owner缺位：问题挂在台账上，没人认领

现象：问题单上Owner写的是部门名或者“待定”，目标日期写“尽快”。每周刷新状态时，几个问题永远挂在“处理中”，实际没有任何人在推进。

原因：项目经理在填单时不敢指定到人，怕被人说“给人派活”；或者被指定的代表没有权限调动资源，只能被动等待。根子在于启动阶段没有约定：指定Owner等于授予行动权限，而不是单纯派活。

解决：在第一次项目例会上把机制说清楚：所有问题单必须有自然人作为Owner；Owner有权调用自己范围内的资源，超出范围时由项目经理向上升级；24小时内无人认领的问题单视为红色项，直接升级到部门主管。这个规则一旦立住，后续运营成本极低。我一般会在项目启动材料里预留一页“问题单流转规则”，文字不多，但能省掉后面大量扯皮。

5.3 六步变成门禁盖章，NO GO也挡不住项目

现象：项目已经连续两个TR评审红灯，但项目还在继续加人、继续开发。DCP开了好几回，每次都是“有条件通过”，几乎没有真实否决的决策。团队在心理上已经默认“门禁是流程表演”。

原因：门禁结果没有和实际权力绑定。评审如果不决定“下一阶段能不能启动、资源能不能到位”，它就对项目没有约束力。更深一层是组织文化不愿意喊停，管理层觉得停一个项目等于承认之前的决策错了。

解决：把门禁和预算、人力挂钩：GO才启动下一阶段活动，NO GO就是不加人、不拨款，项目进入待重新规划状态。这个规则不需要每次评审都启用，但必须存在，并且由IPMT在DCP上明确表达。对项目经理来说，最该学会的一句话是“我建议不通过”。在IPD语境里，敢建议NO GO的PM比只会协调进度的PM值钱得多。

5.4 一法变成套表工程，行动项不闭环

现象：风险台账、问题单、变更单都填得漂亮，字段完整，颜色标得规范，但行动项一个月都不更新，状态只在评审会前批量改成“关闭”。团队把填表当成负担，台账变成黑匣子，没有人在日常工作中看一眼。

原因：表单没有接进团队的运作节奏。如果每周例会第一屏不是“未关闭行动项”，而是各部门轮流念进度，那台账自然变成档案文件。另一个原因是行动项本身定得不好：没有明确交付物，比如“和测试确认环境问题”这种行动项无法验收，能做一辈子。

解决：例会第一屏强制看行动项，直接过“上周计划完成、本周新增、逾期未关”三个列表。行动项必须能验收，不能再写“协调”“确认”这类动词，要写“输出某文档”“完成某测试”“邮件发出某结论”。我还习惯统计行动项按期关闭率，低于80%就说明计划能力和执行能力至少有一个出了问题，不是态度问题，是行动项本身拆得不够细。

5.5 计划阶段拍脑袋，WBS不拆到可执行粒度

现象：计划在三周内做完，WBS只有三层，顶层任务周期是20天，里程碑之间没有任何可检查的中间产物。项目启动后，前两个月一切正常，第三个月开始每周都在刷新计划。

原因：计划阶段没有足够的耐心，或者项目组成员对交付内容了解不够，只能先画一个大框。另一个常见原因是管理层强压日期，项目经理只能先排一个好看的大节点，细节只能在执行中“填坑”。

解决：WBS必须拆到2到5天的任务粒度，超过5天的任务一律要再拆一层；暂时拆不了的任务，直接标记为“计划风险”，由相关负责人给出拆分时间点。计划不是一版定稿，但基线一旦确认，任何变更都要走正式变更流程。这里是我的血泪经验：如果一份计划里找不到一个超过两周没有检查点的任务，后面执行阶段会省掉很多“能不能提前一天”的谈判。

6. 验证这套方法有没有生效：三个指标和一个复盘模板

六步一法落地三到六个月后，怎么判断它是真生效还是又多了一套表？不看感觉，看三个指标。

第一个是行动项按期关闭率。它衡量的是“一法”的闭环能力。统计口径是：当月按目标日期关闭的行动项数，除以当月应关闭的行动项总数。长期低于80%，说明要么行动项拆太大，要么Owner机制没立住，要么管理层没有支持PM去追；高于90%，说明问题到行动的转化是通的。

第二个是门禁一次通过率，也就是DCP或TR评审中，材料一次通过、无条件GO的比例。这个指标不能单独看，要看它和项目最终交付质量的关系。如果通过率很高但项目最后还是延期，说明门禁评审被做成了形式；如果通过率在一个合理区间，甚至偶尔出现真实的NO GO，且该停的项目真的被拦下，说明门禁在起作用。

第三个是项目关键里程碑偏差率。取计划基线里最核心的几个节点，比如详细设计完成、集成测试开始、GA日期，用实际日期和计划日期的差除以计划周期。IPD项目里能做到平均偏差在5%以内已经很扎实；偏差经常超过15%的，说明计划阶段WBS和估算质量有系统性问题，不是执行阶段能补回来的。

复盘模板我固定在项目收尾时用，很简单，四段：目标达成情况，按立项时指标逐条对比；主要偏差与根因，选影响最大的三个偏差做根因分析；做对的与可复用的动作；下一次项目必须解决的三个问题。每个项目开完复盘会，就把这四段填进一页纸，交给下一个项目组的PM。我没有把复盘搞成分数制，因为分数会诱导大家报喜不报忧，一页事实记录比评分表有用得多。这套验证动作我已经用了很久，最大的教训是：不要等项目结束才复盘，每走完六步中的一步，就花半小时记一下“这一步哪件事让我后悔”。把后悔记下来，比任何课程都有效。希望帮到你。

本文还有配套的精品资源，点击获取