我接到 WorkBuddy 这个项目时需求文档只有一句话做一个能帮团队把任务理清楚的 App。没有用户画像没有流程图没有竞品分析甚至没人说清楚要先做手机版还是网页版。我当时的反应是这个项目如果直接动手写代码大概率会在两周后推翻重来。后来的进展证明这句话背后藏着完整的协作工具需求也藏着 90 天从零到上线的全部节奏感。标题里的 WorkBuddy FDE就是我在这个项目中沉淀出来的实战方法论——FDEFeature Driven Engineering特性驱动工程核心思想很简单以可交付的功能特性为单位去拆需求、排计划、做验收而不是以页面、接口或模块为单位。这篇手册适合正在创业团队、个人独立开发、或者刚接手模糊需求项目的朋友参考。我会把从需求澄清到上线复盘的所有关键动作摊开讲包括哪些决定省了时间、哪些坑本来可以提前避掉。1. 一句话需求背后的真实问题需求澄清比写代码更费劲1.1 原始需求里的三个关键词没有一个是清楚的大多数人在接到模糊需求时第一反应是追问细节但追问的方向往往错了。原始需求里最核心的三个词是团队、任务、理清楚。团队是谁是三个人到十个人的小组织还是上百人的跨职能团队任务是什么形态是待办清单、看板卡片还是甘特图里的项目节点理清楚又是什么标准是每个人知道自己今天该干什么还是管理者能看到全盘进度这三个问题不解决后面所有设计都是空中楼阁。我用了整整两天去约不同角色聊不做问卷只做开放式访谈每次大约四十分钟。访谈对象分三类执行任务的人、分配任务的负责人、跨部门需要知道进度的协作方。这三类角色对同一个任务的感受完全不同。执行者关心的是我今天优先做什么、哪些事情快到截止时间了负责人关心的是谁手上任务积压、哪条链路卡住了协作方只想知道这东西什么时候能给我。这轮访谈直接推翻了我最初的假设。我原本以为 WorkBuddy 的核心是做一个漂亮的看板后来发现大家真正缺的不是看板而是任务指派之后有没有人跟进、做完之后有没有人知晓。也就是说价值重心不在列表展示而在任务状态变化带来的通知与同步。1.2 把模糊目标翻译成可验收的用户故事在 FDE 的框架里需求澄清的唯一产出不是长文档而是一组可验收的用户故事。每个用户故事必须满足三要素角色、行为、价值。WorkBuddy 最早期的故事清单是这样的特性ID用户故事验收标准优先级F-01作为团队成员我可以在看板上创建任务以便记录待办事项创建后任务立即出现在看板刷新不丢失P0F-02作为团队负责人我可以把任务指派给具体成员以便明确责任被指派的人能收到实时通知P0F-03作为执行者我可以勾选完成任务以便相关方看到进度完成状态在看板上实时同步P0F-04作为负责人我可以按项目查看所有任务以便掌握整体进度项目页能列出全部任务及状态P0F-05作为成员我可以给任务设置截止时间以便管理自己的排期到期前推送提醒P1F-06作为协作方我可以评论任务以便讨论执行细节评论与回复实时可见P1这里的关键是每个故事后面必须有验收标准否则只是愿望清单。比如创建任务这件事如果验收标准只是能保存成功那太弱了。我把它定为创建后任务立即出现在看板刷新不丢失这就逼着后端接口和本地缓存必须同时工作。FDE 的整个执行单元就是一个带验收标准的特性而不是一段代码、一个页面。1.3 砍需求的三个原则我们最初列了 24 个用户故事最终只保留了 8 个作为 MVP。砍掉的功能包括 AI 自动排期、甘特视图、第三方日历同步、多级子任务、自定义字段、文件附件预览。这些功能并不是没有价值而是在 90 天路径里会挤占核心闭环的验证时间。砍需求我用了三个问题反复追问。第一这个特性砍掉后用户是否还有替代方式完成同样目标如果有那就不是刚需。第二这个特性能不能在两个星期内做出端到端闭环如果做不到说明它背后还有没想清楚的依赖。第三它是不是直接服务于那句原始需求里的理清楚如果只是锦上添花就进 P2留给第二期。这个决策过程必须有记录。我把砍掉的每个功能都写进了一个暂缓清单标注了暂缓原因和重新评估的触发条件。这样做有两个好处一是以后不会被反复质疑当初为什么没做这个二是新需求进来时能快速判断该进哪个版本而不是每次都重新讨论一遍。2. 90天路径规划里程碑倒排法与每周交付节奏2.1 上线日期先定再反推每阶段该干什么整个 90 天规划最关键的一个决定是把上线日期当作不可变节点。第 12 周周五必须提交审核而不是差不多就上。有了硬节点倒排计划才有意义。有人会问如果做到一半发现需求变了怎么办答案是需求变更不能影响上线日期只能影响功能范围。这就是我在项目里反复强调的日期是锚范围是变量。具体到阶段划分90 天被我切成四段阶段时间目标关键交付物阶段一第1-2周验证核心假设、冻结MVP范围可点击原型、特性清单、技术选型阶段二第3-7周跑通核心闭环可安装的内部测试版完成 F-01 到 F-04阶段三第8-11周打磨体验、内测与修问题稳定版本、内测报告、发布材料阶段四第12周提交审核、灰度发布、线上监控应用上架、监控看板、告警规则阶段一最反直觉整个两周不写业务代码只做原型。很多人觉得这是在浪费时间但原型验证的是交互路径和数据结构。我用原型工具把 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 真机测试清单不能再只有模拟器能跑跨平台方案最大的教训是模拟器永远只能验证功能验证不了真实体验。我整理了一份真机测试清单每台设备按清单走一遍测试项测试内容常见问题屏幕适配小屏、刘海屏、全面屏底部按钮被手势条遮挡弱网环境网络切换、断网恢复请求超时无提示、同步卡死后台切换切后台 30 分钟后回前台连接状态未恢复导致重复登录通知权限首次弹窗、拒绝后重新开启权限开启后收不到推送电池消耗长时间挂后台长连接未释放导致耗电异常存储空间缓存持续增长列表图片缓存无上限这份清单在第 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 项目已经上线运行回头看那段从一句话需求到应用商店上架的旅程最值得留住的不是最终代码而是过程中反复验证的那套判断标准什么时候该坚持什么时候该砍掉。 
长河君 · 2026/10/11 7:52:15 · 阅读 1.2k 从模糊需求到90天上线：WorkBuddy FDE方法论实战手册
我接到 WorkBuddy 这个项目时需求文档只有一句话做一个能帮团队把任务理清楚的 App。没有用户画像没有流程图没有竞品分析甚至没人说清楚要先做手机版还是网页版。我当时的反应是这个项目如果直接动手写代码大概率会在两周后推翻重来。后来的进展证明这句话背后藏着完整的协作工具需求也藏着 90 天从零到上线的全部节奏感。标题里的 WorkBuddy FDE就是我在这个项目中沉淀出来的实战方法论——FDEFeature Driven Engineering特性驱动工程核心思想很简单以可交付的功能特性为单位去拆需求、排计划、做验收而不是以页面、接口或模块为单位。这篇手册适合正在创业团队、个人独立开发、或者刚接手模糊需求项目的朋友参考。我会把从需求澄清到上线复盘的所有关键动作摊开讲包括哪些决定省了时间、哪些坑本来可以提前避掉。1. 一句话需求背后的真实问题需求澄清比写代码更费劲1.1 原始需求里的三个关键词没有一个是清楚的大多数人在接到模糊需求时第一反应是追问细节但追问的方向往往错了。原始需求里最核心的三个词是团队、任务、理清楚。团队是谁是三个人到十个人的小组织还是上百人的跨职能团队任务是什么形态是待办清单、看板卡片还是甘特图里的项目节点理清楚又是什么标准是每个人知道自己今天该干什么还是管理者能看到全盘进度这三个问题不解决后面所有设计都是空中楼阁。我用了整整两天去约不同角色聊不做问卷只做开放式访谈每次大约四十分钟。访谈对象分三类执行任务的人、分配任务的负责人、跨部门需要知道进度的协作方。这三类角色对同一个任务的感受完全不同。执行者关心的是我今天优先做什么、哪些事情快到截止时间了负责人关心的是谁手上任务积压、哪条链路卡住了协作方只想知道这东西什么时候能给我。这轮访谈直接推翻了我最初的假设。我原本以为 WorkBuddy 的核心是做一个漂亮的看板后来发现大家真正缺的不是看板而是任务指派之后有没有人跟进、做完之后有没有人知晓。也就是说价值重心不在列表展示而在任务状态变化带来的通知与同步。1.2 把模糊目标翻译成可验收的用户故事在 FDE 的框架里需求澄清的唯一产出不是长文档而是一组可验收的用户故事。每个用户故事必须满足三要素角色、行为、价值。WorkBuddy 最早期的故事清单是这样的特性ID用户故事验收标准优先级F-01作为团队成员我可以在看板上创建任务以便记录待办事项创建后任务立即出现在看板刷新不丢失P0F-02作为团队负责人我可以把任务指派给具体成员以便明确责任被指派的人能收到实时通知P0F-03作为执行者我可以勾选完成任务以便相关方看到进度完成状态在看板上实时同步P0F-04作为负责人我可以按项目查看所有任务以便掌握整体进度项目页能列出全部任务及状态P0F-05作为成员我可以给任务设置截止时间以便管理自己的排期到期前推送提醒P1F-06作为协作方我可以评论任务以便讨论执行细节评论与回复实时可见P1这里的关键是每个故事后面必须有验收标准否则只是愿望清单。比如创建任务这件事如果验收标准只是能保存成功那太弱了。我把它定为创建后任务立即出现在看板刷新不丢失这就逼着后端接口和本地缓存必须同时工作。FDE 的整个执行单元就是一个带验收标准的特性而不是一段代码、一个页面。1.3 砍需求的三个原则我们最初列了 24 个用户故事最终只保留了 8 个作为 MVP。砍掉的功能包括 AI 自动排期、甘特视图、第三方日历同步、多级子任务、自定义字段、文件附件预览。这些功能并不是没有价值而是在 90 天路径里会挤占核心闭环的验证时间。砍需求我用了三个问题反复追问。第一这个特性砍掉后用户是否还有替代方式完成同样目标如果有那就不是刚需。第二这个特性能不能在两个星期内做出端到端闭环如果做不到说明它背后还有没想清楚的依赖。第三它是不是直接服务于那句原始需求里的理清楚如果只是锦上添花就进 P2留给第二期。这个决策过程必须有记录。我把砍掉的每个功能都写进了一个暂缓清单标注了暂缓原因和重新评估的触发条件。这样做有两个好处一是以后不会被反复质疑当初为什么没做这个二是新需求进来时能快速判断该进哪个版本而不是每次都重新讨论一遍。2. 90天路径规划里程碑倒排法与每周交付节奏2.1 上线日期先定再反推每阶段该干什么整个 90 天规划最关键的一个决定是把上线日期当作不可变节点。第 12 周周五必须提交审核而不是差不多就上。有了硬节点倒排计划才有意义。有人会问如果做到一半发现需求变了怎么办答案是需求变更不能影响上线日期只能影响功能范围。这就是我在项目里反复强调的日期是锚范围是变量。具体到阶段划分90 天被我切成四段阶段时间目标关键交付物阶段一第1-2周验证核心假设、冻结MVP范围可点击原型、特性清单、技术选型阶段二第3-7周跑通核心闭环可安装的内部测试版完成 F-01 到 F-04阶段三第8-11周打磨体验、内测与修问题稳定版本、内测报告、发布材料阶段四第12周提交审核、灰度发布、线上监控应用上架、监控看板、告警规则阶段一最反直觉整个两周不写业务代码只做原型。很多人觉得这是在浪费时间但原型验证的是交互路径和数据结构。我用原型工具把 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 真机测试清单不能再只有模拟器能跑跨平台方案最大的教训是模拟器永远只能验证功能验证不了真实体验。我整理了一份真机测试清单每台设备按清单走一遍测试项测试内容常见问题屏幕适配小屏、刘海屏、全面屏底部按钮被手势条遮挡弱网环境网络切换、断网恢复请求超时无提示、同步卡死后台切换切后台 30 分钟后回前台连接状态未恢复导致重复登录通知权限首次弹窗、拒绝后重新开启权限开启后收不到推送电池消耗长时间挂后台长连接未释放导致耗电异常存储空间缓存持续增长列表图片缓存无上限这份清单在第 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 项目已经上线运行回头看那段从一句话需求到应用商店上架的旅程最值得留住的不是最终代码而是过程中反复验证的那套判断标准什么时候该坚持什么时候该砍掉。