一个人的时间分配：怎么同时维护 N 个产品

一个人维护三个产品，最贵的不是工时，是切换。

一、每天碰三个产品的那个人

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

一位开发者同时维护两个 SaaS 和一个浏览器扩展。他的日程是这样的：

• 早上打开 A 的邮箱，回两个工单。
• 中午看一眼 B 的监控，修一个小 bug。
• 晚上给 C 发一个版本更新。

看起来每个产品都在推进，但三个月后，三个产品都没有实质进展：A 的新功能停在设计稿，B 的迁移只做了一半，C 的留存继续下滑。

问题不在工时不够，而在于每次切换都要重新加载上下文：A 的代码结构、B 的数据库状态、C 的发布流程。这些加载成本不会出现在任何工时表里。

二、上下文切换的真实成本

一天切换四次，光是恢复上下文就可能吃掉两个小时。这是需要实测的排程风险，不是所有任务的定律；工单和事故仍可能需要跨产品快速处理。表中分钟数是时间预算假设。

三、把时间按产品分块，而不是按任务分块

正确的时间结构是：一周内给每个产品分配固定的整块时间，块内只做这一个产品的事。

这张表的关键不是具体怎么排，而是三条规则：

1. 深度开发至少 2 小时连续。 本文用 2 小时作为试验起点；短块也可完成清晰的小任务，按实际完成情况调整。
2. 支持与维护集中处理。 不要随时响应，除非是 P0 事故。
3. 每天留出缓冲。 意外一定会发生，不要把时间排满。

3.1 为什么要把「规划」单独拿出来

组合运营比单产品多了一件事：决定这周哪个产品优先。这件事必须在周初做一次，否则你会被当天最响的那个问题牵着走。

周一上午的 30 分钟规划，应该回答三个问题：

• 这周每个产品的最低目标是什么？
• 有没有必须在某天完成的外部截止时间？
• 哪个产品这周可以完全不动？

四、每产品最小维护配额

每个产品都有一条「不做就会坏」的底线。把这条底线量化，才能判断组合是否可行。

把每个产品的最小配额加起来，就是组合的时间地板。

如果一个产品的最小配额是 3 小时，而你每周只有 20 小时可支配，20÷3 仅是静态算术上限，不是可稳定维护 6 个产品的结论；还需扣获客、行政、休息、支持与事故缓冲，并检验工时波动。

超过地板，产品就会开始腐烂，而且是从看不见的地方开始：证书、依赖、备份。

五、一个人的值班规则

没有团队，你既是开发也是 on-call。必须给自己定规则，否则会被随时打断。

5.1 告警分级

5.2 三条值班纪律

• 通知只留 P0 到手机。 其他级别的告警进邮箱或看板。
• P0 必须有明确的判定标准。 否则所有事都会被当成 P0。
• 每周固定一个维护窗口。 计划依赖升级和非紧急修复放周维护；P1 当天响应、P2 48 小时响应，不等周维护才首次查看。

六、批处理：把同类事情攒起来做

批处理的前提是你能接受延迟。能否延迟由响应期限、损害和法定/合同要求决定，不能因为不是 P0 就统一延到下周。

七、常见错误

八、行动清单

• 列出所有产品，写下每个产品的最小周维护配额。
• 把配额相加，和你的可支配时间对比。
• 画一张一周时间块表，深度开发至少 2 小时连续。
• 定义 P0 的判定标准，只让 P0 打断你。
• 设一个固定的维护窗口。
• 把可批处理的事情列出来，定频率。
• 每周一花 30 分钟做组合规划。

使用边界与实操验收

这套级别与资产韧性第 09 篇一致；响应指确认与开始处理，不承诺所有 P1 当天彻底解决。维护配额须包含支持及不可预测事件缓冲。

周五 16:00 收到 P1：当天确认范围、给绕行方案并安排跟踪；P2 则在 48 小时内响应，不默认等到下周五。若 20 小时可用，先预留 4 小时波动和 5 小时获客行政，再分配维护；不能把全部 20 小时都按每产品 3 小时分满。

关键参考与核验范围

以下链接支持对应的机制或规则；本文的案例、成本和经营评分是说明方法的假设，不能当作平台统计或收益承诺。核验日期：2026-10-22。

• EDPB 数据泄露指南 ：按处理角色与风险判断通报，不以恢复完成作为起点。

系列导航

• 上一篇：共享底座：账号、计费、邮件与部署的复用边界
• 下一篇：组合指标：哪些数字合看，哪些必须分开
• 回到目录：一个人的产品线：第二个产品与组合运营
• 相关阅读：SaaS 创始人的时间预算 、副业项目与业余时间管理