企业官网建设流程全解析

EET方法和AGR方法放在一起对比时，最容易让人误会的点是：它们看起来都是用来“做判断”的，但一个是从经验证据往前推，一个是从目标差距往回拉。我先把结论放在前面：如果你的团队已经有足够多的历史数据，优先把 EET 作为估算底座；如果你面对的是一个新目标或重构任务，历史数据稀薄，AGR 反而更容易把范围拆清楚。这篇文章会围绕这两类方法，从适用场景、操作流程、选型标准、常见坑和边界条件几个角度展开，适合做需求评估、技术方案选型、项目复盘和团队评审的人直接参考。

需要先说明一点：这里讨论的 EET 和 AGR，严格说不是某个官方标准或认证框架，而是两类方法论的简称。EET 更偏“经验外推”，AGR 更偏“目标反推”。即使你在其他资料里看到相同缩写，定义可能不同，但“一个看历史、一个看差距”的对比逻辑是通用的。

1. 先弄清楚这两个方法分别擅长解决什么问题

1.1 EET方法到底是什么

EET 可以理解为“经验外推法”。核心逻辑是：要判断一件新事情大概要多少成本、多少时间、多少资源，不要凭感觉拍脑袋，而是先去翻历史记录，找到与当前任务最接近的过往样本，把样本里的关键指标抽出来，再通过对比差异、修正影响因子，最终给出一个可验证的估计区间。

EET 之所以在很多团队里受欢迎，是因为它把“凭经验”变成了“有依据地用经验”。传统专家判断经常表现为“我做过类似项目，我觉得需要三周”。EET 会强迫你把“类似”拆成可对比的维度：业务复杂度、接口数量、改动范围、参与人数、历史缺陷率、需求变更次数、联调耗时、测试周期。只有这些维度能对上一个旧项目，你给出的三周才有可推导路径。

EET 的典型输入是历史项目数据，典型输出不是“一个确定日期”，而是“区间估计加置信理由”。比如：“如果复用现有权限模块，预计 8 到 12 人日；如果重新设计权限模块，预计 18 到 25 人日。”

这个思路在生活中也很常见：你装修房子，不看当地报价单，直接猜全包价，很容易被坑。等你把户型、面积、施工项目、材料等级、淡旺季逐项拿出来对比同小区案例，价格区间才会变得可信。EET 本质上就是这件朴素的事。

1.2 AGR方法到底是什么

AGR 可以理解为“目标差距评审法”。它不依赖“过去发生了什么”，而是先定义“未来应该长什么样”，再回头测算现在和理想状态之间的差距，把差距变成一张可执行的任务清单。

AGR 常用的流程可以拆成四步：

1. 定义目标。目标要能量化，不能只说“提升体验”，要说“客服系统平均响应时间从 5 分钟降到 1 分钟以内”。
2. 盘点现状。当前系统和理想目标之间的每条差异都要记录，不能只写一句“现状很落后”。
3. 按差距归类。把差异项归成流程、数据、代码、基础设施、组织协作等类型，方便后续安排负责人。
4. 从差距生成行动。每条行动必须对应到至少一个差距，不能出现“不知道该干嘛”的待办。

AGR 最容易被误解的地方是它“不重视经验”。其实它重视的是“经验不能替代目标清晰度”。如果你连目标状态都描述不清楚，再多的老专家坐在会议室里也给不出可靠方案。相反，一旦目标状态清晰，即使团队没有同类项目经验，也可以通过拆解“当前状态到目标状态的每个断点”找出任务。

1.3 两者解决的根本问题不同

EET 解决的核心问题是：一件事情大致的量级是多少。 AGR 解决的核心问题是：朝向某个目标，我们还缺哪些工作。

很多人把这两个问题混在一起，于是评审会会变成这样：有人提出“我觉得要做 20 人日”，另一个人反驳“我觉得 30 人日都不够”，但他们讨论的其实是“量级估算”。真正该讨论的应该是“为了达到什么目标，任务列表是什么”。这就是为什么很多团队用 EET 或 AGR 单跑都能跑通，一放一起就说不清楚，因为它们根本不在同一个决策层。

建议：开会之前先确认本场评审要产出什么。如果只是排期，EET 更快；如果是确定范围和分工，AGR 更稳。

2. 核心差异：为什么不能混着用

2.1 推导方向不同

EET 是从历史推导未来。它的前提是“过去发生过的规律可以延续”。AGR 是从目标反推现状。它的前提是“目标状态可以被描述，并且当前状态存在可识别的差距”。

这两个方向听起来简单，实际执行时影响很大。EET 适合回答“如果照以前的方式做，大概需要多久”。AGR 适合回答“如果我们要达到一个没去过的状态，到底缺了什么”。当项目从增量优化变成结构性重构时，历史经验往往不够用，这时只有 AGR 能把新的要求拆成任务。

我把两者的差异放在一起看，会更容易理解：

2.2 对输入数据的依赖不同

EET 非常依赖历史样本的质量。如果历史项目数据口径不统一，比如上一个项目的工时记录里混入了大量脱产培训时间，你的类比外推就会失真。更麻烦的是，很多团队的历史项目记录只保存了“计划工时”和“实际上线时间”，没有记录“中途砍掉的需求”“临时加入的联调成本”“返工次数”。这些缺失数据会让 EET 的估算看起来精确，实际却非常脆弱。

AGR 对历史数据要求低，但对目标定义要求高。目标如果只写“提高人效”，这个目标无法拆出收敛的任务清单，因为“人效”没有边界、没有度量口径、没有起点和终点。同样的指标，从“客服人均处理量”和“客户满意度”两个角度拆，得到的两套任务可能完全不同。目标写得越模糊，AGR 拆出来的任务就越像在给决策者交差，而不是真正指导执行。

2.3 输出形态不同

EET 大概率输出“多少资源、多少钱、多少时间、在什么条件下成立”。AGR 输出“待办列表、里程碑、依赖关系、验收口径”。如果你只需要回答“这个迭代排多少天”，EET 更直接。如果你需要回答“为什么排这么多天、哪些任务可以砍掉”，AGR 更有说服力。

两者不是非此即彼，而是各自回答不同层面的问题。一个常见错误是：用 EET 输出一次估算，就当作 AGR 的差距清单来用。比如“20 人日”只是一个数字，它没有告诉你这 20 人日到底花在哪个后端模块、哪些前端页面、哪些联调环节。反过来，如果把 AGR 拆出的任务直接加起来估时间，却没有做过任何历史校准，也容易高估或低估。

3. 同一个需求，用 EET 和 AGR 各走一遍

这一节用一个相对常见的案例来说明，方便对照落地。假设背景如下：

• 项目名称：客服系统重构。
• 现状：客服系统响应慢，报表模块和第三方机器人耦合严重，遇到高峰时段消息经常堆积。
• 目标：通过前后端分离和消息队列优化，把平均响应时间从 5 分钟降到 1 分钟以内。
• 团队情况：有三个月的历史项目记录，包含数个项目工时、缺陷数据、联调耗时；但历史项目中没有和客服系统完全一样的项目。

3.1 用 EET 走一遍

第一步，收集历史项目数据。先把历史项目按技术栈、模块数、接口数、页面数、参与人数、测试周期、联调天数、缺陷数整理成一张表。不要只收集“看起来漂亮”的项目，还要把延期项目、失败项目、中途砍需求的项目也放进去，否则样本偏差会很大。

第二步，筛选相似项目。客服系统重构涉及权限模块、实时消息、异步任务、报表模块。拿这些维度去匹配历史项目。如果完全匹配不上，就找相近的：有一个历史项目做过工单系统，消息链路类似；另一个项目做过数据大屏，报表模块类似。把这些项目作为类比样本。

第三步，校准影响因素。历史项目可能没有做过真正的异步任务队列，当前客服系统涉及第三方机器人连接，复杂度更高。这时需要把接口数量、异常分支、并发量等因素纳入修正系数。比如基础人日按相似项目取中位数，再根据实时消息和第三方依赖复杂度乘以 1.2 到 1.5。

第四步，输出估算区间。不要只写一个“ 25 人日”。要写成“如果沿用现有团队、不引入消息中间件，预计 25 到 32 人日；如果引入消息中间件并做压测，预计 32 到 42 人日。”每一个数字都要配一句“在什么条件下成立”。

第五步，找两三个资深同事独立看一遍。如果独立估算的结果偏差超过 30%，回去检查样本和修正系数；如果偏差在 20% 以内，说明这个区间基本可用。

注意：EET 这一步只能回答“大概率需要多少人日”，不能回答“这些天到底花在了哪些差距上”。所以下一轮要用 AGR 补上差距清单。

3.2 用 AGR 走一遍

第一步，定义可量化目标。可以把客服系统重构拆成三个子目标：

• 平均响应时间从 5 分钟降到 1 分钟以内。
• 第三方机器人故障时，系统能持续提供服务，不影响核心工单处理。
• 运营报表数据能在 10 分钟内完成同步，不再依赖人工导出。

每个子目标都配一个验收口径：用什么样的压测环境，跑多少并发，观察多长时间，数据从哪里取。没有验收口径的 AGR，很容易变成纸上谈兵。

第二步，盘点现状。逐项列出当前系统离目标还差在哪里。比如：

• 请求链路经过多个同步调用，导致平均耗时长。
• 第三方机器人接口超时后，没有熔断机制。
• 报表模块直接读业务库，大数据量查询会拖慢主流程。
• 缺少消息队列积压监控和告警。
• 没有独立的压测环境，无法准确评估响应时间。

第三步，按差距归类。把上面的现状差异归成：链路优化、稳定性治理、数据同步、监控告警、测试环境建设。每一类都要有一个责任人视角，但不一定现在就指定人。

第四步，从差距生成行动清单。例如：

• 在消息处理链路上引入异步队列，把非核心通知类请求改成异步处理。
• 给第三方机器人调用增加超时和熔断策略，失败时切换到备用通道。
• 把报表模块改造成读取只读副本，避免影响主流程。
• 配置队列积压监控和告警规则。
• 搭建独立压测环境，编写压测脚本。

第五步，做闭环验证。检查每一条行动是否能至少消除一条现状差异。如果有一条行动找不到对应差距，先不要保留，因为它大概率是“想当然的优化项”而不是“目标反推的必做项”。

3.3 结果怎么判断

EET 的有效性，看估算区间是否覆盖真实消耗。项目结束后，把实际人日和估算区间对比。如果实际数字经常落在区间之外，说明样本或修正系数有问题，需要回来修正方法论本身。

AGR 的有效性，看行动清单是否闭环且可验收。每个差距都有对应行动，每个行动都有明确的完成标志。如果拆出 50 个任务，但没有人说得清“做完之后目标是否达成”，说明差距拆解仍然停留在表面。

两种方法合起来跑，才能既知道要做哪些事，也知道这些事大概需要多少资源。

4. 怎么选型：判断标准、组合用法和常见误区

4.1 选型判断表

实际使用时可以按照下面这张表快速判断：

这里有个容易被忽略的点：EET 并不等于“有历史就行”。历史项目是否真的完整记录，数据维度是否统一，直接决定 EET 能不能用。我见过不少团队说“我们有很多历史项目”，但真去拉数据时，发现工时表只记录到“提交测试”，没有“联调改动”和“上线后修复”的部分，这种数据只能用来做趋势判断，不能做精准外推。

4.2 组合用法：先AGR拆范围，再EET估量级

最稳妥的组合方式是“AGR 拆范围，EET 估量级”，而不是反过来。

先讲一个反例：团队先用 EET 根据历史项目估算出一个总人日，比如 40 人日，然后用 AGR 去拆任务。结果拆出来的任务列表和当初估算总人日时的假设完全对不上，因为估算时参考的历史项目里没有现在这种第三方机器人依赖。这时候总人日就悬空了，讨论时只能重新回到“是不是该加 5 天”这种没有依据的博弈。

正确的顺序应该是：

1. 用 AGR 把目标拆成三到五个可衡量的子目标。
2. 每个子目标下列出差距清单。
3. 对每个差距项或行动项，用 EET 从历史项目里找类似工作项做估算。
4. 把所有估算区间汇总，再根据团队人员水平、技术熟悉度、外部依赖做整体校准。
5. 最后请至少两名同事独立复核估算区间，确认偏差范围。

这套组合的好处是：每一个估算数字都能追溯到“它是在解决哪个差距”。评审会上有人质疑“为什么这里要 5 人日”，你可以直接说“这个差距是当前状态到目标状态之间缺少异步队列，历史项目里类似的消息改造工作耗时 4 到 6 人日。”这个逻辑比单纯拍一个数字清晰很多。

4.3 常见误区

误区一：EET 等于拍脑袋，AGR 等于更高级。实际上 EET 需要高质量历史数据，AGR 更依赖目标质量。两者都需要严格过程，不存在谁自动更优。

误区二：先用 EET 估总人日，再让 AGR 去拆任务。这个顺序容易造成估算和任务脱节。越早把目标和差距拆清楚，后面的估算越可靠。

误区三：把 EET 的估算区间当成上线日期承诺。EET 给出的是决策输入，不是合同日期。尤其是业务方追问“到底能不能 30 天上线”时，应该回答“在什么条件下能，在什么条件下不能”，而不是给一个看起来确定的数字。

误区四：只跑 AGR 不校验工作量。任务拆得很细，每个任务要不要人日完全不知道，最后排期仍然失控。AGR 只解决“做什么”，不解决“多贵”；“多贵”必须交给 EET 或者更细粒度的估算方法。

5. 落地时会踩的坑：现象、原因和排查顺序

5.1 常见现象对应表

实际推进过程中，团队很容易遇到下面这些情况：

5.2 排查顺序：先看问题，再看输入

很多人一遇到结果不准，第一反应是换方法。其实多数问题不在方法本身，而在输入质量和使用顺序。我建议按这个顺序排查：

1. 先确认这次评审要回答的问题是什么。是“大概多少工作量”，还是“要做哪些事情”。如果两个问题混在一起，先花 10 分钟把它拆清楚。
2. 再确认输入质量。EET 看历史项目记录是否完整，AGR 看目标描述是否可度量。输入不干净，过程再好也没用。
3. 再确认输出质量。EET 输出的是不是“区间加假设”，AGR 输出的是不是“任务加验收口径”。如果只有单一数字或一批没有验收标准的待办，说明执行过程走了样。
4. 最后检查操作顺序。有没有先拆目标再估量级？估算时有没有做独立校准？差距清单有没有做到闭环？

很多看起来像“方法不对”的问题，最后都出在同一个地方：输入材料没有处理干净，或者团队根本没有确定要什么输出。

5.3 复盘检查清单

项目结束后，我建议用下面这份清单做一次简短复盘：

• 实际人日和 EET 估算区间相比，是偏高还是偏低？
• 哪些偏差来自历史数据缺失？哪些偏差来自需求变更？
• AGR 拆出的行动清单里，有多少任务真正落地了？
• 有没有任务当时拆得出来，但后来发现和目标没有直接关系？
• 下一次评审时，至少要补充哪一类数据或哪个维度的目标描述？

这份清单不需要很长，但每一条都要落到具体项目上，才有复盘价值。

6. 一些关于边界的实话

EET 的边界在于：历史数据只是一个参考，外部环境变化、团队人员变化、技术栈更替都会让经验失效。如果历史项目与当前任务差异过大，EET 的区间会从“窄而清晰”变成“宽到没有意义”。这时候不要硬套历史数据，不如先用 AGR 把未知项找出来，再回到历史里找局部相似点。

AGR 的边界在于：目标清晰是前提。但很多探索型项目，目标本身就是模糊的，比如“我们要引入一套新的消息中间件，但还不确定它是否适合客服场景”。如果强行 AGR，容易把“不知道”伪装成“差距”，拆出一堆看似合理但没有实质内容的任务。探索阶段更适合先做原型实验，把目标和真实反馈校准之后，再回到 AGR 做任务拆解。

我在实际使用时会把两者当成两个互补工具，而不是非此即彼的选择。先跑一个最小样本，比如用上一个项目的一条迭代记录，分别用 EET 和 AGR 对同一个小需求做一次试验。EET 帮你校准历史数据的口径和估算区间，AGR 帮你验证目标是否能被拆成闭环任务。这个过程做一遍，团队就能直观感受到两种方法的差异，不会在正式评审时吵成一团。

真正落地时，最该盯住的不是“谁更先进”，而是输入是否干净、输出是否可验证、评审会是否用对了输出。EET 和 AGR 都只是工具，能稳定解决“量级”和“差距”这两个问题，就已经很有价值。