企业官网建设流程全解析

前段时间整理工作文档，翻到前年做的一个官网改版项目。那个项目让我第一次认真写“进度控制笔记”，因为整段延期过程实在太有代表性了：前两周一切平静，第五周突然发现联调窗口几乎被吃掉一半，最后只能砍掉两个次要页面赶上线。事后我把排期、跟踪、纠偏、复盘的全过程重新捋了一遍，才意识到崩盘根本不是最后两周发生的，而是从排期时“任务太粗、估算靠拍、依赖没理清”这三处默认错误里一点点长出来的。

这份笔记，就是把我这几年在进度上踩过的坑、用过的表和改过的流程整理成的一套可复用方法。它不依赖任何昂贵工具，一张Excel、一块白板、甚至一本纸质笔记本都能落地。

如果你正在带一个三五人的小团队，或者自己接外包项目、管内部交付，又或者只是觉得“明明排了期却总在延期”，那这篇笔记应该能帮上忙。内容不绕弯子，全是实操层面的东西。

1. 先搞清楚进度控制到底在控什么

1.1 一个耗时五周才暴露的问题

先说那个官网项目。计划六周交付，拆了两个前端、一个后端、一个设计，外加我负责统筹。

前两周风平浪静。设计在出视觉稿，前端在搭框架，后端在搭数据库。第三周开始不对劲，设计师和客户来回拉扯，一套视觉稿改了五版，但所有人都以为这只是“局部调整”，不影响总工期。到了第五周，前端还在等最终稿，而后端接口虽然早写完了，却没人和前端联调过。距离上线还剩一周，联调、测试、内容迁移全挤在一起，最后不得不砍需求。

这件事让我记住了一个道理：进度控制的对象从来不是“时间”本身，而是“时间被什么东西吃掉了”。在这个项目里，时间是被隐藏的返工吃掉的，被不明确的验收标准吃掉的，被不敢上报的“局部调整”吃掉的。如果你只盯日历，不看任务状态、依赖关系和变更趋势，那日历永远只是一块遮羞布。

1.2 进度控制盯的是范围、时间、成本与质量的关系

做过项目的人都听过“不可能三角”：质量、成本、进度，三选二。但实际项目里，四个变量都会动。

• 范围变了，进度要变。客户临时加一个模块，那不是“增加工作量”，而是推迟所有下游任务。
• 资源变了，进度要变。团队从三个人变成两个人，不是“每个人多干一点就行”，而是关键路径上所有估算都要重算。
• 质量标准变了，进度也要变。验收从“页面能打开”变成“通过所有核心流程的自动化测试”，工作量完全不是一个数量级。

所以进度控制的内核，是盯着这四个变量的关系做取舍，并把每一次取舍都记录下来。

我后来养成了个习惯：每次排期，都会单独写一页“约束条件”，内容包括“这个版本必须包含什么功能”“质量标准是什么”“团队有几个人”“硬性交付日期是哪天”。一旦出现偏差，先看是哪个约束被触发了，再决定是调范围、调资源，还是调日期。不做这一步，进度控制就变成了盲人摸象。

2. 动手之前：把任务拆到能算出时间

2.1 用WBS把交付物拆到“一至三天颗粒度”

很多人排期喜欢按“模块”或“页面”为单位写任务，比如“官网开发 10天”“登录功能 7天”。这种写法最大的问题是：看不见过程。一个10天的任务，第8天时你问负责人“怎么样了”，对方说“80%了”，但没人知道这个80%到底是写得差不多了，还是逻辑通了但没测试，还是只能跑通一条路径。

我现在的做法是拆WBS，拆到能一至三天交付一个“可验证结果”的程度。还是拿官网改版举例，拆完之后大概是这样：

• 需求梳理与页面清单确认（2天）
• 视觉设计：首页与模板页（3天）
• 视觉设计：内页与响应式适配（2天）
• 前端框架搭建与路由（1天）
• 首页、列表页、详情页开发（5天）
• 后端接口开发：内容管理模块（4天）
• 后端接口开发：前端对接（3天）
• 前后端联调与Bug修复（4天）
• 历史内容迁移与校验（2天）
• 测试、兼容性检查与上线部署（3天）

做这次拆解时，我给自己定了三个标准：每个任务都有明确产出物，每个产出物都能被验收，每三天的进度变化都肉眼可见。任务一旦拆到这个颗粒度，延迟就藏不住了——某一天该完成的事没完成，第二天立刻就能看到连锁反应。

2.2 三点估算：给每个任务算一个期望工期

任务拆完，下一步是估时间。我见过最多的做法是“拍脑袋加20%”，比如觉得功能大概要8天，就写成10天。但这种做法既不科学也容易出问题——你把缓冲藏在了单个任务里，前端开发看到有富余时间，反复调整样式、优化细节，任务依然用满了10天，到联调时该缺的时间还是缺。

我现在的标准做法是三点估算，给每个任务三个数字：

• 乐观工期（O）：一切顺利，没有返工，需要几天？
• 最可能工期（M）：正常情况，小有波折，需要几天？
• 悲观工期（P）：遇到麻烦，返工重做，需要几天？

然后用公式计算期望工期：

期望工期 = (O + 4M + P) / 6

举个例子，后端接口开发任务：乐观5天，最可能8天，悲观14天。代入公式：

(5 + 32 + 14) / 6 = 51 / 6 = 8.5天

这个8.5天就是你的基准工期，而不是拍出来的10天。还能顺带算标准差：

标准差 = (P - O) / 6 = (14 - 5) / 6 = 1.5天

意思是这个任务至少需要7天，理想情况下10天也正常。排期表里我会写上“期望工期8.5天，范围7到10天”，而不是硬邦邦写一个“9天”。这样后续出现延迟时，你能清楚地判断它是正常波动还是真实偏差。

2.3 依赖关系和缓冲：排期的两种常见错误

拆完任务、估完时间，接下来是排顺序。这里最容易犯两种错误。

第一种是“把依赖关系完全搞反”。前端等着视觉稿，后端接口等着前端给字段定义，内容等着设计给图片尺寸——这些链条不捋清楚，排期就是一张废纸。我的做法是先画依赖，再谈排期。常见的依赖类型主要是完成-开始（FS），也就是上一个任务完成了，下一个才能开始。比如联调必须等接口和前端都完成，视觉设计必须等原型评审通过。

第二种是“把缓冲塞进每个任务”。每个任务都加了两天余量，看起来是安全了，但根据帕金森定律，工作总会膨胀到填满分配给它的时间。你给10天，他就慢悠悠做10天；你给7天，他反而能赶在7天前交付。

缓冲应该放在两条地方：

• 项目缓冲，放在关键路径末尾，专门吸收整体的不确定性，只留一个。
• 接驳缓冲，放在高风险任务之后，比如“外部设计师返工”或者“第三方接口不稳定”的任务后面。

这样做的好处是：缓冲不参与日常排期，团队不会提前把它消耗掉，真正遇到意外时它才发挥作用。官网项目里，第五周那次危机，准确说就是“所有任务的个人缓冲都被消耗完了，但谁都不觉得自己延期了”。

3. 跟踪阶段：量化偏差、控制节奏、可视化

3.1 用偏差率和SPI判断进度是否健康

排期做完只是开始，真正体现功力的是跟踪。跟踪不能靠感觉，要靠数字。

我用的最简单指标有两个。

第一个叫进度偏差率，公式是：

偏差率 = (实际完成工作量对应的计划工期 - 实际使用工期) / 计划工期

举个实际例子：前端页面开发计划5天，第5天时应该100%完成。结果第5天检查，只完成了60%。那偏差率就是：

(3天 - 5天) / 5天 = -40%

这意味着你已经落后了约2天的工作量，而不是“还有20%没做完”这种轻飘飘的说法。

第二个是SPI，挣值管理里的进度绩效指数：

SPI = EV（已完成的计划工作量） / PV（计划到此时应完成的工作量）

SPI低于1就是进度落后，0.9以下就要警惕，0.8以下基本可以断定按当前趋势必然会延期。

这里有个经验值表可以参考：

我当时的官网项目，第五周才有意识去算，发现SPI已经掉到0.72了。如果从第三周就开始算，视觉稿打回第二次时就能发现问题，根本不用等到第五周。

3.2 日报、周会与里程碑评审各干各的活

很多团队把进度汇报做成了形式主义：每天一封邮件，每人写“今天完成了XX，明天计划XX”，项目群里刷屏，真正有用的信息却没几句。

我在踩过几次坑之后，把节奏固定成三层：

• 日报，只报阻塞，不报进度。每天早上15分钟站会，每人只回答一个问题：“有什么事情在阻碍你完成今天的任务？”没有阻塞就说“没有”。这样3分钟就能开完，而且大家愿意把问题抛出来，因为不会被追问“那你今天到底干了啥”。
• 周会，只调资源，不念流水账。每周五花30分钟，把看板上的任务过一遍，看有没有任务停在同一列超过两天，看谁手上的并行任务太多，看有没有人可以支援瓶颈任务。
• 里程碑评审，只看验收结果，不问“进展如何”。快照式地演示当前可用的功能、可展示的页面、可调用的接口，而不是听口头汇报。

三层各司其职，进度控制才不会变成“比谁汇报得好听”。

3.3 燃尽图与看板：两个直观的进度仪表盘

跟踪的日常操作，我建议可视化。最实用的是燃尽图。

做法很简单：横轴是时间，纵轴是剩余工作量。项目开始时，剩余工作量是全部任务的总和；每天结束时，更新剩余工作量，把点连成线。理想情况下，这条线应该从左上角一路走到右下角，变成一条直线。实际线在理想线上面，说明落后；在下面，说明超前。

举个例子，总工作量20个点，计划10天做完。第3天结束时应该剩余14个点，实际还剩15个点，说明落后了1个点的工作量。折线图可能看着不明显，但用表格记就一目了然。

另一个我强烈推荐的是带WIP限制的看板。WIP就是在进行中的任务数。允许的WIP数量越小，团队越不能“同时在十件事上各做一半”。

我之前带的项目，看板列分为待办、开发中、测试中、已完成，WIP限制是2个。效果非常明显：开发中的任务还没测完，就没人敢开下一个，所有人的注意力都被迫聚焦在“怎么把手上这件事推完”，而不是“怎么多开一条线”。半成品大量减少，交付节奏反而变快了。

4. 当偏差真的出现：四类应对手段怎么选

4.1 先说清：这是偏差、漂移还是范围蔓延

进度一旦出问题，我会先做一个分类，因为三类问题的处理方式完全不一样。

• 偏差：指计划内的正常波动。比如某任务比估算多花了一天，但总缓冲还够。处理方式是微调，不必大动干戈。
• 漂移：指整体进度偏离了原基准线。比如两周内多个任务都晚于计划，SPI已经跌到0.9以下。处理方式是启动纠偏流程，而不是假装没发生。
• 范围蔓延：指需求在未经正式确认的情况下悄悄膨胀。比如设计稿被反复要求“再加一点细节”，开发被要求“顺便兼容一下老系统”。这是最危险的，因为它伪装成常态工作，却在无休止地吞噬进度。

官网项目里，视觉稿改五版就是标准的范围蔓延。设计师没在进度表上体现返工，客户也不觉得自己在加需求，但进度就是这么被吃掉的。

4.2 赶工、并行、裁剪与重排：一个决策顺序

确认是漂移之后，按照这个顺序决定应对手段，不要一上来就宣布延期或裁员式加班。

• 第一步，压缩单点任务。先看有没有哪个任务可以通过改善工具、复用已有代码、简化验收环节来缩短时间。比如把“手动录入内容”改成“编写脚本批量导入”，一个3天的任务可能压缩到1天。
• 第二步，有限度地加班。我一般只允许关键路径上的任务加班，其余任务不许。而且连续加班不超过两周，超过后产出严重递减，还容易制造返工。
• 第三步，并行推进本来串行的任务。这是fast tracking，风险在于下游返工。实施前提是：下游已经可以拿到半成品或mock数据开始动手。
• 第四步，裁剪范围。砍掉优先级最低、对核心目标影响最小的功能。这一招最有效，但需要客户或内部干系人拍板。
• 第五步，重排基准。以上手段都不够时，调整交付日期，明确告诉干系人“原来的计划已经不可能完成，需要基于新信息重排。”

我个人的实践是，前三步在团队内部就能决定，第四步和第五步必须尽早同步给干系人。越晚说，可选择的空间越小。

4.3 关键路径不压缩，其他都是白费劲

压缩进度，最容易犯的错是“逮着谁延期就催谁”。实际上，只有关键路径上的任务延期，才会直接影响总工期；非关键路径上的任务延期，只要没超过浮时，对交付日期毫无影响。

什么叫关键路径？就是一个项目里，从起点到终点、累计工期最长的那条任务链。比如官网项目的链路可能是：

原型设计（2天） → 视觉设计（5天） → 前端页面开发（6天） → 联调（4天） → 测试（3天） → 上线（1天）

总工期算出来是21天，这条链就是关键路径。内容迁移虽然也要2天，但它可以放在联调期间并行做，即使慢了一天，只要不超过联调的4天，就不影响交付。

所以，任何一个进度纠偏动作开始前，先把关键路径找出来，只盯着这条链上的任务压缩时间。

官网项目后期，我们就是重新画了一遍关键路径，发现真正卡住的是前端页面等待视觉定稿。于是把视觉评审从“全套完成再评审”改成“首页先定稿、其他页面模板化复制”，前端立刻开始动工，这样才抢回来3天。

4.4 把延期复盘写进笔记，别只补一次进度

项目上线后，很多人第一反应是睡觉，彻底不想碰这个项目。但我更建议趁记忆还热，做一次复盘，否则同一类坑会在下一个项目里原样踩一遍。

我的复盘模板很简单，就四个问题：

1. 延期的直接触发点是什么？
2. 触发点最早在哪一天就露出苗头了？
3. 当时为什么没人上报？
4. 下次怎么做，才能提前两周发现问题？

官网项目的复盘结果特别扎心：直接触发点是视觉在第三周连续打回，最早露出苗头是第三周第二次打回时，没人上报，因为“不好意思”和“觉得不严重”，下次行动是“视觉稿超过两次修改，必须拉会评审，确认修改点和预期限制”。

复盘不是为了追责，是为了把模糊的教训变成可执行的检查点。我把每个项目的复盘都记在同一份“进度控制笔记”里，下一个项目排期之前先翻一遍，效果比任何培训都好。

5. 常见问题与排查技巧实录

5.1 进度心理学：为什么大家总把事情拖到最后

进度控制里最容易被忽略的，其实是人的心理。我见得最多的是这两种。

一种是学生综合症，假期作业总要拖到开学前一天晚上才写。项目里也一样，明明四周后截止，前两周往往节奏缓慢，真正发力都在最后一周。

另一种是帕金森定律，时间多就慢慢做。任务给了10天，第6天时往往只完成一半，但你问起来，对方会说“时间还够，急什么”。

对付这两种现象的办法不是喊口号，而是用结构去约束：

• 单任务颗粒度压小，最好三天以内有可见产出，不给拖延留空间。
• 检查频率固定，每周至少两次同步，让“最后一刻发力”无法成立。
• 缓冲放在末端统一看管，别让单个任务的“宽松感”膨胀成整个项目的延期。

还有一个屡试不爽的技巧：把任务从“做某事”改成“完成某可验证结果”。比如“开发登录页面”容易被拖，“明天下午5点前提交可演示的登录页Demo”就很难拖，因为它有一个明确的验收点。

5.2 完成度、依赖假象与汇报中的水分

几乎每个团队都存在“完成度虚高”的问题。我刚开始带项目时，问“页面做完了吗”，对方说“完了”，联调时才发现所谓“完了”是UI画完了，逻辑没跑通，接口没对接。后来我要求所有完成状态必须对应一个演示动作：能演示、能验收、能发布。不能说“完成了”，要说“完成了哪个部分，能用什么样的方式验证”。

依赖假象也是一样。上游任务报告“基本完成”，下游团队就提前开工了。可一上手才发现核心数据还没接好，只能垫着临时数据写逻辑，结果一半代码以后要返工。这个问题的排查方法很简单：下游开工前，确认上游提供的产物满足“完成定义”，而不是“看起来能用了”。凡是口头说“基本、差不多、应该可以”的，一律扣下，等确认后再放开。

5.3 工具选型：表格、甘特图、看板各司其职

总有人纠结用什么工具管进度，其实工具根本不复杂。我的建议是看场景。

工具选定之后，最关键的是统一“状态语言”。比如我们团队固定几种状态：进行中、开发完成待测、测试中、已验收、已上线。不允许出现“快好了”“基本完成”这种模糊词。

这里多说一句，看板工具最核心的不是墙上有多少列，而是WIP限制和不依赖口头汇报的状态流转。有些团队把看板当成装饰墙，一个任务从进板到出板都不更新，这比不用工具还糟。

6. 从项目笔记到个人计划：这份方法能搬到日常生活

6.1 个人进度控制三件套：拆解、每周回顾、可见产出

项目管理的这套东西，迁移到个人生活里也完全够用。无论是准备考试、写论文、做副业，还是筹划装修，道理都是相通的。

我给你一套最简单的个人进度控制三件套。

第一，把目标拆成一至三天能做完的“可见产出”。不是“复习高数”，而是“做完习题集第三章20道题并核对答案”；不是“写论文”，而是“完成开头的摘要部分，约300字”；不是“减肥”，而是“本周完成三次30分钟快走，记录打卡”。

第二，每周只做一次进度快照。固定每周日晚抽15分钟，打开你的进度控制笔记，回答三个问题：本周哪些任务没完成？为什么？下周最重要的三件事分别是什么？不用每天都做复杂记录。

第三，给大目标留一块“缓冲”。提前一个周期当作缓冲期，比如原本预计六周完成的事，对外或对自己的计划按四周半来排。给意外留出空间，比每天焦虑更稳妥。

6.2 一份A4纸周计划的具体写法

我自己常年用的个人周计划，就是一张A4纸，分成四栏。

• 目标栏：本周必须完成的三件事，要符合“可见产出”标准。
• 日历栏：周一到周日，每天只写一到两项任务，多了根本完不成。
• 阻塞栏：本周遇到的卡点，比如“等资料”“设备坏了”“某件事比我预想的难”。写下来是为了周复盘时有据可查。
• 复盘栏：周日晚写，本周低估了什么、高估了什么、下一周要不要调整节奏。

这个格式看起来很简单，但坚持半年后你会发现自己对时间的敏感度明显提升，因为每周日都要面对一张写满真实数据的纸，那些“我好像挺忙的”错觉会立刻消失。

我在实际做这份“进度控制笔记”时还有一个习惯：每个任务后面都留一列“阻塞记录”，哪怕是“不知道怎么写”这种情绪型卡点，也照样写。写出来的好处是，卡点会被正视，而不会默默发酵成拖延。有一次我准备一个分享稿，连续三天卡在“开头怎么写”，写进笔记后才发现，是自己想一口气写出完美开头，于是把任务拆成了“先写100字垃圾初稿”，十分钟就完成了第一版。这种细小的调整，往往比大张旗鼓的规划更能解决实际问题。

这套方法整理到这里，其实节点只有一个：所有的进度失控，都是从第一次掩盖开始的。第一次视觉打回时你不说，第一次任务超期时你假装正常，第一次缓冲被消耗时你视而不见，后面的事就会顺着惯性滑向不可控。而我后来学会的，就是尽早把那些“不好意思说”“觉得不严重”的事，写进笔记里，变成下一周检查清单上的一条硬指标。这样做之后，项目反而越来越稳，我也少踩了蛮多坑。