企业官网建设流程全解析

简介：77页PPT系统讲解华为研发需求管理的核心理念与落地方法，面向产品经理、研发管理者及流程改进人员，旨在解决企业产品需求收集不清、分析不透、验证缺失等常见痛点。资料共1个PPT文件，压缩包约2.22MB，当前已有173人学习。内容完整覆盖需求管理Why与How，从战略规划、业务计划到IPD流程的位置，到需求管理流程（收集-分析-分发-实现-验证）逐环节展开；详细呈现客户需求分层描述框架（原始需求/初始需求/系统特性/系统需求），并附有手机通话录音等需求分解样例；同时讲解产品管理部的组织设置、RAT需求分析团队职责，以及客户需求十问、需求探针、专家顾问团等收集方法。整套PPT基于华为实践，帮助读者理解如何将客户声音转化为可验证的产品包需求，支撑产品战略与竞争力领先，适合用于团队内部培训、研发流程优化或需求管理能力提升。

1. 华为研发需求管理到底在管什么：从“一句话需求”到“可交付特性”

研发团队最常遇到的场景是：客户在交流会上随口说了一句“要是能这样就好了”，产品经理记在本子上，销售转手把消息发到群里，老板在饭桌上拍板“这个必须做”。三个来源，三个版本，最后研发做出来的东西和谁说的都对不上。华为的研发需求管理体系，解决的就是这个问题——它把零散的诉求收拢成一条可追踪、可决策、可验收的链路。这套逻辑被整理成一份内部流程教材，外界常以“77页PPT”指代它。但核心从来不是那77页，而是四个动作：需求分层、规范收集、决策拍板、闭环验收。下面按这条链路拆开讲，顺便把每步落地的参数和坑说清楚。

2. 需求分层分级：把需求拆成“决策层、规划层、执行层”的底层逻辑

2.1 需求分层：为什么一把抓的管理必然失控

大部分团队的需求管理混乱，不是因为大家不努力，而是把所有需求塞进同一个桶里。客户说的“要一个更快的导入功能”、销售转达的“大客户要求支持某个协议”、老板说的“下季度要做出差异化亮点”，这三件事的性质完全不同：一个是具体缺陷，一个是商业诉求，一个是战略方向。放在一起评估，只能比嗓门大小。

华为的做法是把需求分成三个层次来管理，每一层有独立的描述语言和评审规则。最外层是OR（Offering Requirement，产品包需求），也就是客户视角的语言，描述“我要解决什么问题”；中间层是PR（Product Requirement，产品需求），把客户语言翻译成产品特性，描述“产品要具备什么能力”；最内层是DR（Design Requirement，设计需求），落到具体模块和实现方案，描述“技术要怎么做到”。

分层之后，每层需求有各自的归口角色和评审会，不会出现“销售说了一个功能，研发直接就去改代码”的越级传导。这也是小团队最容易忽略的一点：不是不能简化，而是不能把不同层级的判断标准混在一起。

2.2 需求分级：P1到P4的优先级不是拍脑袋

分层解决“这是什么需求”，分级解决“这个需求有多重要”。华为内部对需求有一套分级约定，常见的是P1到P4这四档。P1是阻塞性需求，不做就无法交付或客户明确拒绝验收；P2是增强性需求，做了能显著提升竞争力，不做也能交付但会丢分；P3是改善性需求，做了体验更好，不做用户感知不明显；P4是远期或探索性需求，当前不具备明确业务价值，先记录不承诺。

分级的难点不在定义，而在执行。我见过很多团队把P1当成“最想要的”，结果所有需求都是P1，等于没有分级。华为的做法里有两个约束值得借鉴：一是每个版本的P1需求必须有上限，做不完就要砍版本而不是扩版本；二是P1必须能被验收标准描述，不能只说“客户很急”，要说清楚“客户在什么场景下、验收什么指标才算通过”。

判定流程我一般这样走： 需求到达后，先问三个问题—— 问题1：不做这个需求，这个版本能不能正常交付验收？ 能 → 不可能是P1 不能 → 候选P1，需补充验收标准 问题2：做了它，客户是否愿意多付钱或显著提高忠诚度？ 愿意 → 候选P2 不愿意 → 候选P3或P4 问题3：这个需求现在有明确的市场窗口期吗？ 有 → 按P2排入近期版本 没有 → 进P4，放入需求池冻结区

2.3 从三层两级到小团队的两层模型

华为的完整分层适合几百人以上的产品线，几十人的团队照搬会把自己压垮。我一般建议做简化：砍掉DR这一层，把设计需求并入PR的技术实现描述，只保留“客户需求”和“产品需求”两层。客户需求层解决“做什么”，产品需求层解决“怎么做、做到什么程度”。至于全套流程，可以保留评审动作，不保留评审会议，用线上评审代替。

简化后的需求单仍然要保留一个核心字段：需求层级标记。哪怕只有两层，也要让评审人一眼看出这条需求是客户原始诉求还是产品内部方案。这个标记是后续追溯的关键——很多团队半年后复盘，想不起来某个功能为什么做，就是因为原始诉求和产品方案混在一起，找不到源头。

3. 需求收集与分发：$APPELS八要素法与需求池建设

3.1 统一需求入口：一张需求单解决“来源乱”

华为的需求收集有一个明确约束：所有需求必须通过统一入口进入，不接受口头、微信、邮件散养。这个入口落到实操，就是一张结构化的需求单。谁都可以提需求，但必须按格式填，没按格式填的视为无效需求，退回补充。

这张需求单是所有后续工作的地基，字段不能太少也不能太多。我见过只填“标题+描述”的需求单，评审会根本没法开，分析人拿到需求还要打电话追问背景。也见过字段多到二十个的需求单，提需求的人填一次要半小时，最后敷衍乱填。

3.2 $APPELS八要素：把需求从“一句话”扩成“完整场景”

华为需求管理中一个流传很广的方法是$APPELS，也有人写成$APPLE，本质是通过八个维度把一个模糊需求补全成可评估的完整描述。这八要素分别是：$（背景，Situation）、A（优势，Advantage）、P（产品，Product）、P（渠道，Place）、E（体验，Experience）、L（生命周期，Lifecycle）、S（支持，Support）。

一句话需求“客户希望导入快点”和一份合格的$APPELS需求单，差距非常大。完整的$APPELS描述应该包含：客户当前的导入数据量是多少、在哪个环节感觉卡、期望达到什么速度、这个能力在哪些场景下被使用、要不要考虑异常处理和断点续传、导入功能上线后如何运维和排障。

逐条说清楚这八要素填什么，给你一个可抄的模板：

• $背景：客户遇到什么具体问题，现在的数据是什么规模，现状指标是多少。不写“客户觉得慢”，要写“客户每次导入约2万行数据，耗时约40秒，业务部门每周操作十余次”。
• A优势：客户希望达到什么目标，这个目标为什么值得做。写“目标提升到10秒以内，可减少等待时间”比“提高效率”可评估。
• P产品：这个需求落在哪个产品、哪个模块，涉及哪些接口或界面。
• P渠道：需求的来源渠道——是标准产品需求，还是某大客户的定制需求，是哪个区域提交的。
• E体验：用户操作前后的体验变化，包括交互、反馈、报错信息是否友好。
• L生命周期：需求上线后如何演进，要不要考虑后续版本扩展，旧数据是否兼容。
• S支持：上线后运维层面需要什么支持，是否需要日志埋点、监控告警、帮助文档更新。
• 最后的S（支撑）：实现这个需求需要哪些前置条件，依赖哪些模块或外部系统。

一个合格的$APPELS需求描述，至少要让我看完后能回答三个问题： 1. 这个需求为谁解决什么问题； 2. 现在和期望的差距量化到多少； 3. 实现它涉及哪些模块、依赖哪些条件。 答不出这三个问题，需求单就退回重写，不进入评审。

3.3 需求池分流：做、不做、待定、合并的判断规则

需求收集进来后，不会立刻进入开发。华为的做法是先入池，再分流。需求池不是一张简单的“待办清单”，而是一个带状态的数据集合。每条需求经过分析后，会被分到四个去向之一：立项开发、暂缓待定、明确不做、合并同类。

立项开发的需求进入版本规划流程，暂缓待定的需求留在池子里等条件成熟，明确不做的需求归档并说明原因，合并同类是把多个渠道提交的同一底层诉求合为一条。这里的常见误区是“暂缓待定”成为无限滞留区，需求一放就是一年。我一般会加一个规则：待定需求每季度review一次，连续两个季度既不转立项也不关闭的，强制转入“不做”，防止需求池腐烂。

4. 需求决策与优先级排序：RMT/RAT机制与“做不做、先做谁”的拍板规则

4.1 RAT与RMT：把“分析需求”和“拍板决策”分开

华为需求管理体系里有两个角色必须分清楚：RAT（Requirement Analysis Team，需求分析团队）和RMT（Requirement Management Team，需求管理团队）。RAT负责把需求分析清楚，输出“这个需求是什么、工作量多大、技术风险多高”的事实判断；RMT负责做决策，输出“这个需求做还是不做、什么时候做”的价值判断。

这两个角色分开的核心原因是不让“权力的决策”干扰“事实的分析”。如果让拍板的人同时做分析，很容易出现“领导觉得简单，于是所有人都说简单”的情况。RAT的产出是一份相对中立的需求评估结论，包括技术可行性、工作量估算、依赖关系、风险评估。RMT基于这份结论做决策，决策依据是版本目标、资源约束、商业价值。

小团队实践时，这两个角色可以分别由不同的人兼任，但至少要保证“分析和决策”不落在同一个人脑袋里。哪怕是三个人，一个研发负责人做分析评估，产品负责人做决策，都比一个人既评估又拍板要靠谱。

4.2 决策评审点：在哪个节点必须说“做还是不做”

华为的每个需求在进入开发前，要经过明确的决策评审点。其中最常见的两个节点是：概念决策评审点和计划决策评审点。概念评审点回答“这个需求值不值得立项”，计划评审点回答“这个需求按什么方案、什么资源、什么时间交付”。

落到日常节奏里，我一般建议一个迭代周期设一次需求决策会。会议只做两件事：一是对进入候选池的需求做立项判断，二是对已立项的需求做优先级调整。会议时长控制在1小时内，迟到或缺席视为默认同意，不搞全员拉通。很多团队需求管理慢，不是流程复杂，而是决策会一拖再拖，等所有人到齐才开会，结果永远开不起来。

4.3 优先级打分表：价值与成本双维度

需求排序最怕只凭直觉。华为体系里常用的是多维度加权打分，本质是把“价值”和“成本”两组因素数字化。价值维度看四个方面：客户影响（涉及多少客户、影响多大收入）、战略匹配（是否符合产品方向）、市场时机（窗口期是否紧迫）、竞争差异（做了能否拉开差距）。成本维度看三方面：工作量（人月估算）、技术风险（实现难度、不确定性）、依赖复杂度（涉及几个模块、几方协同）。

我建议每个版本的阈值设成“价值总分占比60%以上，成本总分占比不低于均值的需求优先排入”。更重要的是一个习惯：把打分结果和最终决策对照记录。三个月后复盘时，你会发现自己当时打分和实际结果之间的偏差，这个偏差数据比打分表本身更有价值。

5. 需求管理避坑指南：五个高频翻车点与排查方法

5.1 统一入口成了形式，销售群里一句话还是需求

现象：需求管理系统搭了，需求单模板也发了，但销售还是习惯在群里说“客户要个功能，很急”，产品经理也默认接收，还亲自去填单。流程跑了一个季度，群里冒出来的需求数和系统里的需求数对不上。

原因：统一入口只约束了“填写动作”，没有约束“接收行为”。只要有人接收口头需求，提出者就没有动力去填系统。华为这套逻辑生效的前提是：所有接收需求的人，听到任何需求的第一反应是“麻烦提个需求单”，而不是“好的我记一下”。

解决：把“不接收口头需求”写进团队工作约定，产品经理和研发负责人收到口头需求时，统一回复“请提需求单，评审会上处理”。同时补一个机制：群里的需求由轮值运营人每周归档一次，发现有没提单的，补录后标记“渠道不规范”，连续出现则通告。三个月后，口头需求自然消亡。

5.2 $APPELS八要素填满了，但没人读

现象：需求单的八个字段都填了，评审会上没人看，大家还是盯着标题和优先级打分拍板。八要素成了文字游戏，填单的人为了必填项拼命凑字，评审人一页都不翻。

原因：八要素的目的是让评审人高效理解需求，而不是让填单人完成KPI。只收集不消费，流程就会为了填而填。本质是评审机制出了问题——评审会上没有把八要素作为发言顺序。

解决：把需求评审会改成按八要素逐项过，每人只看自己相关部分。具体做法是：评审时按此顺序走——先讲背景和优势（2分钟），再讲产品和渠道（1分钟），接着讲体验和生命周期（1分钟），最后讲支持和支撑（1分钟）。5分钟讲完一条，讲不清楚的直接挂起。这样填单人知道有人真的在读，填的认真程度也会不一样。

5.3 优先级打分人人满分，排序白做

现象：同一批需求的价值打分全部集中在4到5分，成本打分全部在2到3分。排序结果和直觉排序几乎一样，打分完全失去区分度。

原因：打分表里的评分说明写得太模糊，填表人把“4分”理解成“还不错”，把“5分”理解成“挺好的”。加上中国人情文化，大家不想得罪提需求的人，习惯性给高分。

解决：给每个分值写“可验证的行为锚定”，不许凭感觉。客户影响维度：5分=全球TOP10客户明确要求；4分=区域头部客户要求且愿意参与验收；3分=多个中小客户反馈；2分=单个客户建议；1分=内部设想。锚定写完，分数自然拉开。再加一条硬约束：每个版本的价值分排序中，后30%的需求如果没有特殊说明，默认不排入。

5.4 需求变更靠口头，改到一半发现所有人理解不一致

现象：需求做到一半，产品经理口头跟开发说“这里客户又提了新要求，稍微改一下”。开发觉得是个小改动，闷头改了三天。提测时才发现，测试用例、设计文档、验收标准全部还是旧版本，需求实际变更了但没有一个人说清楚变更范围。

原因：变更不走流程的本质是怕麻烦。口头变更当时最省事，但代价是状态不一致。华为的做法里有一条值得直接抄走：所有需求变更必须走变更单，哪怕只是改一个字段，变更单里必须写“变更前是什么、变更后是什么、为什么变更、影响哪些模块”。

解决：在项目管理工具里加一个“变更”按钮，任何需求的状态从“开发中”变回“待分析”，都必须关联变更单。没有变更单的一律不允许回退状态。技术上限制也简单：把需求状态字段的流转设置成“必须有变更记录才能反向流转”。制度加系统约束，双保险。

5.5 只管理到“上线”，不管理“验收是否达成”

现象：需求状态流转到“已上线”就结束了。半年后复盘，没人知道这个需求上线后客户用了没有、问题解决没有。再有人提类似需求时，又当新需求重新走一遍流程。

原因：把“上线”当成了终点，需求管理管的是“交付”，没管“价值”。华为的需求管理链路里，最后一步是需求验证，即对照立项时的目标逐条确认达成情况。没有这一步，前面的分层、收集、决策全部白做。

解决：给每个需求增加一个“商业验收”环节，状态从“已上线”变成“已验证”才算闭环。验证动作不复杂：立项时定的客户影响目标是什么，上线后一个月内回访确认目标是否达成；没达成的进入“需跟进”状态，写清差距原因。这条规则坚持下去，你会发现前期的需求优先级判断会越来越准。

6. 把华为这套逻辑落回自家团队：从流程到看板的最小可行方案

6.1 一页纸流程与三角色

不用照搬77页，小团队跑这套逻辑最少只需要三个角色。需求分析人负责把收集到的每一条需求填好$APPELS八要素并做初步的工作量和风险评估；决策人负责定期开评审会，对需求做“做/不做/待定/合并”的判断和优先级排序；研发Owner负责对自己承接的需求从开发到验收全程跟进。

6.2 七个状态的需求看板

用一个看板工具把需求状态机建出来，状态建议直接照抄下面这组，不要自己发明：

6.3 每周半小时，只看三张表

每周固定的30分钟需求周会，按顺序过三张表：本周新增需求表（只过有新提交的需要决策项，不逐条念）、下周待决策表（每条的评估结论已由分析人提前写好）、已上线验收表（对标记“已上线”的需求核对验收进展）。半小时够用，关键在于会前把材料准备好，会上只做决策和确认，不做技术讨论。

我自己的工作习惯是每月月底把打过分、排过序的需求翻出来，对比上线后的真实表现，标出“分打高了”和“分打低了”的案例。这个动作做了半年之后，优先级判断的准确性会明显提升。华为这套需求管理体系的价值不在流程本身，而在于它逼着你把每一个决定变成可追溯的记录。希望帮到你。

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