企业官网建设流程全解析

我接到 WorkBuddy 这个项目时，需求文档只有一句话：做一个能帮团队把任务理清楚的 App。没有用户画像，没有流程图，没有竞品分析，甚至没人说清楚要先做手机版还是网页版。我当时的反应是：这个项目如果直接动手写代码，大概率会在两周后推翻重来。后来的进展证明，这句话背后藏着完整的协作工具需求，也藏着 90 天从零到上线的全部节奏感。

标题里的 WorkBuddy FDE，就是我在这个项目中沉淀出来的实战方法论——FDE（Feature Driven Engineering，特性驱动工程），核心思想很简单：以可交付的功能特性为单位，去拆需求、排计划、做验收，而不是以页面、接口或模块为单位。这篇手册适合正在创业团队、个人独立开发、或者刚接手模糊需求项目的朋友参考。我会把从需求澄清到上线复盘的所有关键动作摊开讲，包括哪些决定省了时间、哪些坑本来可以提前避掉。

1. 一句话需求背后的真实问题：需求澄清比写代码更费劲

1.1 原始需求里的三个关键词，没有一个是清楚的

大多数人在接到模糊需求时，第一反应是追问细节，但追问的方向往往错了。原始需求里最核心的三个词是：团队、任务、理清楚。团队是谁？是三个人到十个人的小组织，还是上百人的跨职能团队？任务是什么形态？是待办清单、看板卡片，还是甘特图里的项目节点？理清楚又是什么标准？是每个人知道自己今天该干什么，还是管理者能看到全盘进度？这三个问题不解决，后面所有设计都是空中楼阁。

我用了整整两天去约不同角色聊，不做问卷，只做开放式访谈，每次大约四十分钟。访谈对象分三类：执行任务的人、分配任务的负责人、跨部门需要知道进度的协作方。这三类角色对同一个任务的感受完全不同。执行者关心的是"我今天优先做什么、哪些事情快到截止时间了"；负责人关心的是"谁手上任务积压、哪条链路卡住了"；协作方只想知道"这东西什么时候能给我"。

这轮访谈直接推翻了我最初的假设。我原本以为 WorkBuddy 的核心是做一个漂亮的看板，后来发现大家真正缺的不是看板，而是"任务指派之后有没有人跟进、做完之后有没有人知晓"。也就是说，价值重心不在列表展示，而在任务状态变化带来的通知与同步。

1.2 把模糊目标翻译成可验收的用户故事

在 FDE 的框架里，需求澄清的唯一产出不是长文档，而是一组可验收的用户故事。每个用户故事必须满足三要素：角色、行为、价值。WorkBuddy 最早期的故事清单是这样的：

这里的关键是：每个故事后面必须有验收标准，否则只是愿望清单。比如"创建任务"这件事，如果验收标准只是"能保存成功"，那太弱了。我把它定为"创建后任务立即出现在看板，刷新不丢失"，这就逼着后端接口和本地缓存必须同时工作。FDE 的整个执行单元就是一个带验收标准的特性，而不是一段代码、一个页面。

1.3 砍需求的三个原则

我们最初列了 24 个用户故事，最终只保留了 8 个作为 MVP。砍掉的功能包括 AI 自动排期、甘特视图、第三方日历同步、多级子任务、自定义字段、文件附件预览。这些功能并不是没有价值，而是在 90 天路径里会挤占核心闭环的验证时间。

砍需求我用了三个问题反复追问。第一，这个特性砍掉后，用户是否还有替代方式完成同样目标？如果有，那就不是刚需。第二，这个特性能不能在两个星期内做出端到端闭环？如果做不到，说明它背后还有没想清楚的依赖。第三，它是不是直接服务于那句原始需求里的"理清楚"？如果只是锦上添花，就进 P2，留给第二期。

这个决策过程必须有记录。我把砍掉的每个功能都写进了一个"暂缓清单"，标注了暂缓原因和重新评估的触发条件。这样做有两个好处：一是以后不会被反复质疑"当初为什么没做这个"；二是新需求进来时能快速判断该进哪个版本，而不是每次都重新讨论一遍。

2. 90天路径规划：里程碑倒排法与每周交付节奏

2.1 上线日期先定，再反推每阶段该干什么

整个 90 天规划最关键的一个决定，是把上线日期当作不可变节点。第 12 周周五必须提交审核，而不是"差不多就上"。有了硬节点，倒排计划才有意义。有人会问：如果做到一半发现需求变了怎么办？答案是需求变更不能影响上线日期，只能影响功能范围。这就是我在项目里反复强调的：日期是锚，范围是变量。

具体到阶段划分，90 天被我切成四段：

阶段一最反直觉：整个两周不写业务代码，只做原型。很多人觉得这是在浪费时间，但原型验证的是交互路径和数据结构。我用原型工具把 F-01 到 F-04 的完整流程点了一遍，发现任务创建到指派这个链路里，需要确认的字段比想象中多得多。设计上多做一天，开发阶段就能少返工三天。

2.2 每周一个垂直切片，而不是先做完整 UI 再做逻辑

FDE 最核心的实践是垂直切片。第三周交付的必须是"能创建任务、数据落到数据库、再显示回看板"的完整功能，而不是只做好看板界面的静态页面。每个切片都是一条从数据库到界面的完整链路。第三周做任务创建，第四周做任务列表，第五周做指派与通知，第六周做状态流转，第七周做项目维度汇总。这样每周五都有一版能演示的东西。

垂直切片最大的好处是风险每周暴露。如果某周的数据结构设计有问题，当周就能发现，而不是等到所有界面做完之后联调时才炸。我可以用装修来类比：装修不能先把所有墙刷完再通电通水，而是每一面墙做完都要试灯、试插座、试网口。看起来多了一道工序，但避免了最后一次性排查时根本不知道哪个环节出问题。

另一个容易被忽略的点是：垂直切片必须有对外可见的结果。我给自己的要求是，每周切片完成后，找一个完全没参与项目的人来操作两分钟，只看他会不会用。如果对方找不到入口，说明这个切片还不算真正完成。

2.3 里程碑检查：每周五的 15 分钟验收

每周五下午收工前，我用三个问题做里程碑检查。第一个问题：这个切片能被用户独立使用吗？还是说中间需要开发者在旁解释概念才能跑通。第二个问题：新用户不看我演示，能自己找到入口并完成核心操作吗？这考验的是交互自然度。第三个问题：如果下周我暂时离开项目，另一个人接手这个代码，能在一天内搞清楚当前进展吗？这个问题直接决定了代码注释的密度、数据表的命名规范、以及接口文档是否更新。

这三个问题看起来简单，但执行起来很有压迫感。因为第三个问题意味着每个周五都要把最近的代码当作"要交接出去的版本"来整理，不能攒到最后。很多项目的混乱不是技术问题，而是长期缺少这种强制性的阶段性验收，导致每个模块看起来都在做，但没有一个模块真正收口。

2.4 90 天里的三个关键里程碑

除了每周验收，整个 90 天里还有三个必须严肃对待的关键节点。

第一个是第 2 周结束时的需求冻结。从第 3 周开始，不再新增 P0 需求。任何新想法都先进暂缓清单，等第一个可用版本上线后再评估。没有需求冻结，90 天路径就是一句空话，因为新需求会不断稀释已有排期。

第二个是第 7 周结束时的核心闭环冻结。F-01 到 F-04 全部完成并且可演示。从第 8 周开始只做三类事：修问题、优化体验、补齐发布材料。这个节点如果没守住，后面所有环节都会往后滚。

第三个是第 10 周结束时的内测问题清零。内测用户反馈的关键问题必须全部关闭，不关闭的问题要明确给出延期理由。否则第 11 周还在处理第 8 周就该解决的问题，审核和灰度准备就会被挤到角落里。

3. 技术选型与架构：决定 App 能否 90 天上线的关键博弈

3.1 架构决策的优先级：速度大于优雅，但不等于没有架构

对于 90 天项目，选型首要标准不是技术最先进，而是团队上手速度快、生态完善、部署简单。我在 WorkBuddy 里主动放弃了微服务、容器编排、复杂消息中间件，选型只有一个原则：单机跑得动、后续能平滑演进。过度设计在时间紧张的项目里是致命的，因为它会让每一行代码都变重。

但"不做过度设计"不等于"不设计"。我见过很多项目因为没有架构约束，最后变成一个大泥球。WorkBuddy 的做法是定三层边界：客户端只负责状态展示和用户交互；服务端只负责业务规则和数据持久化；中间通过统一 API 通信。这个边界能保证任何一层内部调整时，另外两层不跟着重构。

3.2 客户端：一套代码覆盖双端，减少维护成本

客户端我选了跨平台开发框架，而不是原生双端各写一套。原因很简单：项目团队人力有限，90 天里要同时维护两套原生代码几乎不可能。协作工具这个品类的 UI 复杂度属于中等水平，跨平台方案完全能覆盖，而且生态里已经有成熟的状态管理、路由、网络请求和本地存储方案。

这个选择的代价也要提前说清楚：跨平台方案的坑集中在真机兼容性上，尤其是相机、推送、后台任务这些系统能力。WorkBuddy 里唯一涉及系统能力的模块是推送通知，我为此专门预留了额外的真机测试时间。如果项目里要大量调用传感器、蓝牙或高性能图形，这条选型思路可能就不适用了。

3.3 服务端：从单体开始，但留好扩展点

后端最初是单体应用加关系型数据库，所有业务逻辑都在一个服务里。理由不是单体更好，而是我们没有足够证据在第一天就把服务边界划分正确。服务拆分的依据应该是独立扩展需求和独立故障域，而不是代码行数。90 天项目里最怕的就是为了架构而架构，拆出一堆互相调用的服务，结果每个都在裸奔。

虽然单体起步，我还是预留了三个明确的扩展点。第一是消息队列，用来承接异步事件，比如任务变更后的通知分发；第二是对象存储，为后续文件上传做准备；第三是第三方推送服务接入的适配层，这个适配层很薄，但不提前留好，后面硬接会很痛苦。这三个扩展点让单体应用在业务增长后不至于推倒重来。

3.4 数据模型：一张任务表如何撑起协作逻辑

后端数据结构我保持了极度克制。没有为看板、列表、日历各建一套表，底层只有一张任务表，外加项目和成员两张辅助表。任务表的核心字段长这样：

tasks ( id UUID PRIMARY KEY, title TEXT NOT NULL, description TEXT, status TEXT NOT NULL DEFAULT 'todo', assignee_id UUID REFERENCES users(id), creator_id UUID REFERENCES users(id), project_id UUID REFERENCES projects(id), due_date TIMESTAMP, created_at TIMESTAMP NOT NULL, updated_at TIMESTAMP NOT NULL )

状态只保留三个：todo、doing、done。很多人喜欢把状态设计成自由字符串，这会让报表统计和权限校验变得极难维护。我还在服务端加了状态机校验：todo 到 doing 到 done 是合法路径，done 不允许直接跳回 todo，必须经过 doing。这个限制在初期看起来有点死板，但它保证了任务完成率这个核心指标不会被随意篡改。

另一个容易被忽略的字段是 updated_at。我要求所有更新操作都必须刷新它，因为后续做离线同步和增量推送时，这个时间戳就是冲突判断的基础。没有它，客户端之间的数据合并会变成一场灾难。

4. 核心功能实战：任务看板、实时协作、离线同步的实现路径

4.1 看板的数据结构与状态流转

看板本质上是任务列表按状态分组渲染。技术上没有任何炫酷的地方，真正复杂的是状态流转。小组件里点一下"完成"，背后要发生四件事：本地状态更新、接口请求、服务端状态机校验、其他在线成员的界面刷新。这四件事任何一件断掉，用户都会觉得"状态变了但好像没变"。

内测阶段发生过一次有意思的事。某个团队用户反复把任务从 done 拖回 todo，理由是"我标错了"。结果一天之内，任务完成率从 80% 掉到 20%。我们的状态机直接拦住了这条非法路径，之后设计上增加了一个"重新打开"按钮，但操作边界必须经过 doing，同时在任务动态里记录了一条"由已完成重新打开"的日志。这个日志后来成了团队复盘的重要依据。状态机不是用来限制用户，而是用来保证数据的可信度。

4.2 实时协作：推送和轮询的取舍

第一版实时协作我偷懒用了轮询，客户端每 5 秒拉一次任务列表。内测只有 12 个人在线的时候，服务器负载已经不好看，而且任务状态刷新有明显延迟。后来换成实时通信协议长连接加增量消息推送，才彻底解决。

这里的关键不是技术本身，而是消息体只传变更字段，不传整个任务对象。比如任务状态从 todo 变成 doing，服务端推送的消息只需要包含任务 ID、变更后的状态、操作者 ID 和时间戳，客户端用这四条信息更新本地状态。如果每次都推送完整任务对象，网络流量和前端渲染压力都会翻倍。这个优化思路在任何实时协作场景都适用：先想清楚"最小变更集合是什么"。

4.3 离线优先：本地缓存与冲突处理

手机 App 必须处理电梯、地铁、车库这些断网场景，否则用户就会在信号恢复后看到一个和自己操作不一致的界面。WorkBuddy 的做法是：所有写操作先进本地队列，界面立刻反馈成功；网络恢复后按顺序同步到服务端。冲突处理采用最后一次写入覆盖，同时保留更新日志。

这个方案从技术上看不是最完美的，但它是 90 天里最务实的选择。真要实现字段级冲突合并，需要一个完整的版本向量机制，那会占掉至少两周开发时间。对于任务协作这类低冲突业务，最后一次写入覆盖加上审计日志已经够用。如果后续要支持多人同时编辑同一个文档，这个方案就要升级成基于操作日志的合并。

4.4 从内测数据反推产品问题

第 8 周我们开始邀请真实用户内测，数据暴露了一个设计盲区：超过 40% 的任务没有指派负责人。原因让人哭笑不得——创建任务表单里，指派人是非必填项，很多用户顺手就跳过了。但任务没有负责人，整个协作闭环就断了一半。我立刻调整了表单交互：只有选择负责人才能提交任务。后端同时加了校验，强制要求任务必须有关联成员。

这类问题只有真实流量下才会暴露，单元测试写不出来。这也解释了为什么我把内测放在第 8 周而不是最后一周：数据反馈需要时间才能转化为产品调整，如果第 12 周才第一次让真人用，发现问题也只能带着问题上线。内测问题清零不是靠祈祷，而是靠提前暴露。

5. 上线前的最后两周：测试、审核与监控，一样都不能少

5.1 真机测试清单：不能再只有"模拟器能跑"

跨平台方案最大的教训是：模拟器永远只能验证功能，验证不了真实体验。我整理了一份真机测试清单，每台设备按清单走一遍：

这份清单在第 11 周每天跑一轮。最典型的问题是后台切换：用户把 App 切到后台半个小时后回来，长连接已经断开，界面还显示在线状态，最后是通过监听应用回前台事件并主动重建连接解决的。这些问题在模拟器里一个都复现不出来。

5.2 发布审核与灰度策略

发布审核准备最容易被忽略的是隐私政策页面。我在提交前一晚发现应用商店要求必须有隐私政策和用户协议入口，差点整周推迟。所以第 11 周第一天就该检查三件事：隐私政策是否可访问、权限声明是否与实际调用一致、测试账号是否已经移除。任何一条不过审，整个 90 天计划都会崩。

灰度策略我用了最简单的做法：先开放报名制的内测渠道，收集崩溃率和反馈；审核通过后只开放 10% 的邀请码，观察三天；确认崩溃率低于千分之一再全量开放。不要一上来就全面推广，因为后端服务容量和监控告警都需要时间验证。灰度不是一种保守姿态，而是给线上系统一个预热期。

5.3 线上监控：崩溃、接口、性能三条线

上线不是终点，而是另一个调试阶段的开始。我要求崩溃收集服务在第一个版本就接入，这不算额外成本，却能第一时间拿到用户端的崩溃堆栈。没有崩溃上报的发布等于盲发。

接口层做了两件事：耗时监控和错误告警。任务列表接口 P95 耗时如果超过 1 秒，告警通知立刻发出来。页面性能用采样统计，重点看首屏渲染时间和任务列表滚动帧率。很多项目上线第二天才发现接口在高峰时段超时，用户一两分钟内就流失了，监控的价值不是事后找原因，而是让问题在影响扩大前被拦住。

6. 复盘 WorkBuddy：哪些决策省了时间，哪些坑可以提前避

6.1 做对了的三件事

第一，需求冻结时砍掉了所有 P1 以下功能。当时的暂缓清单现在回头看，有一半功能已经不需要做了，另外一半放进二期后明显做得更从容。砍需求不是减少价值，而是为真正重要的特性争取空间。

第二，坚持每周垂直切片，让每个相关方每周都有东西可看。这个节奏带来的直接好处是：没有任何一个模块在最后阶段突然返工。因为每个模块交付已经超过四周，即使有问题也已经提前暴露并修复。

第三，从第一天就接入了崩溃收集服务，而不是产品稳定之后补。这是我做过成本最低、收益最高的决定。因为后面的每轮内测都能直接看到真实崩溃情况，不用每次等用户截图手动描述问题。

6.2 应该更早做的两件事

第一，用户访谈应该提前到需求调研第一天，而不是第二周才开始。前面两天我陷入了一种自我感觉良好的状态，以为已经理解需求。直到访谈完第一组真实用户才发现，我的假设至少有三处是错的。越早接触真实用户，错误假设的成本越低。

第二，真机测试应该在第四周就开始逐步进行，而不是集中到最后两周。跨平台框架的兼容问题通常在具体设备上才会出现，早测一台，就早一点暴露问题。我最初担心版本未稳定测了也白测，实际教训是：功能每完成一个切片，就该立刻拿到不同类型的手机上跑一遍，哪怕只是看界面布局和基础交互。

6.3 复制这套打法的最小行动清单

如果你也准备启动一个从模糊需求到上线的 App 项目，我建议你至少做到这六件事。

第一，拿到一句话需求后，先用访谈拆分角色，不要急着列功能。第二，把功能定义成带验收标准的用户故事，用 FDE 的思路控制范围。第三，把上线日期设为硬锚点，需求变更只能改范围，不能改日期。第四，按周交付垂直切片，每周五做三问验收。第五，第 8 周就让真实用户上手，用数据反推产品调整。第六，上线前两周集中处理隐私政策、权限声明、真机测试、灰度策略、崩溃上报，这五件事缺一不可。

这套打法不一定适合所有团队——如果你们有足够资源同时铺开多个功能，那节奏可以更激进。但如果你和我一样，只有有限的人力和 90 天窗口，那么克制范围、固定节奏、提前暴露风险，就是最稳妥的路。WorkBuddy 项目已经上线运行，回头看那段从一句话需求到应用商店上架的旅程，最值得留住的不是最终代码，而是过程中反复验证的那套判断标准：什么时候该坚持，什么时候该砍掉。