以前每到年底，我都会有一种很熟悉的感觉。

该做年度总结了。

然后开始回顾这一年做了什么，哪些事情完成了，哪些没有完成。

接下来，再认真写一份明年的计划。

工作。

学习。

家庭。

身体。

副业。

个人成长。

最好每一个领域都写得清清楚楚。

甚至会给自己安排到月份。

一月份做什么。

二月份做什么。

三月份做什么。

看起来非常完整。

那一刻，我通常会产生一种错觉：

明年的生活，好像已经被我设计好了。

但真正到了第二个月，计划就开始变形。

工作突然来了新的事情。

家庭出现新的安排。

原本想学的东西没有学。

原本准备做的项目推迟了。

某个计划做到一半，突然发现自己根本不想做了。

到了年中，再打开年初那份计划。

经常会发现：

里面很多东西，已经和现实没有关系了。

以前我会觉得：

“是我执行力不够。”

后来我开始怀疑：

也许问题不是我没有执行好年度计划，而是我用了一种不适合人生的计划方式。

程序员应该很容易理解这种问题。

你很少会在一月份把整个项目未来十二个月的所有代码全部写完，然后规定自己接下来一年不能改变。

因为你知道：

需求会变化。

用户会变化。

技术会变化。

环境会变化。

甚至你自己对产品的理解也会变化。

所以软件开发后来逐渐形成了一套更适合不确定环境的方式：

敏捷开发。

这让我重新思考了一件事情：

人生的年度计划，

是不是也可以敏捷一点？

我们真正需要的，可能不是“年度计划”，而是“年度方向”

传统年度计划有一个很大的问题：

它很容易把“目标”和“路径”混在一起。

比如：

今年我要做一个副业。

于是开始写：

第一季度学习。

第二季度做产品。

第三季度推广。

第四季度变现。

看起来非常完整。

但这里其实隐藏了一个很大的假设：

我在年初就已经知道正确的路径。

可是现实往往不是这样。

尤其是人生里的事情。

我可能知道自己想增加收入。

但不知道具体应该通过什么方式。

我可能知道自己想做内容。

但不知道什么内容真正适合自己。

我可能知道自己想拥有第二增长曲线。

但不知道最终会长成什么样。

这时候，如果我硬要在年初把路线规划完整，最后很容易出现一种情况：

为了完成计划，而继续执行一个已经被现实证明不合适的方案。

所以现在我越来越倾向于：

年度计划不要写得太细。

年度只回答一个问题：

这一年，我准备把人生系统往哪个方向移动？

至于具体怎么走。

留给后面的迭代。

年度计划，其实更像产品 Roadmap

软件项目里有一个很重要的概念：

Roadmap。

它不会告诉开发团队：

“2027年3月17日下午2点，必须完成某一个具体功能。”

它更多是在描述：

我们未来一段时间准备解决什么问题。

希望产品往什么方向发展。

哪些能力需要逐渐建立。

这其实更适合人生。

比如我现在比较关心的事情：

职业的稳定性。

第二增长曲线。

个人影响力。

家庭。

个人能力积累。

这些可以成为我的年度方向。

但具体怎么实现？

可以变化。

甚至应该变化。

因为我真正需要的是：

方向稳定，路径可变。

而不是：

路径固定，现实必须配合。

然后，把一年拆成一个个 Sprint

如果一年只有一个计划周期，很容易出现一个问题：

年初特别有动力。

年底突然发现：

“怎么一年又过去了？”

中间发生了什么，很少有人认真检查。

所以我更喜欢把一年拆成多个短周期。

比如：

一年 → 季度 → 月度 → 两周。

这就很像敏捷开发里的 Sprint。

但这里有一个非常重要的区别：

Sprint不是把年度任务机械切成12份。

而是：

每一个周期，都重新决定下一步最值得做什么。

比如我今年希望建立自己的第二增长曲线。

第一个 Sprint，我可能只是验证：

有没有一个真正愿意持续输出的内容方向。

第二个 Sprint，可能发现：

内容方向没问题，但生产成本太高。

于是下一轮优化的就不是“多写文章”。

而是：

如何降低内容生产成本。

再下一个 Sprint，可能发现：

阅读量还不错，但没有形成用户连接。

于是下一轮开始测试：

社群、邮件、产品或者其他承接方式。

这就是敏捷开发真正有价值的地方：

每一次迭代，都不是为了证明上一轮计划是正确的。

而是为了获得新的信息。

我以前最容易犯的一个错误：把计划当承诺

以前我制定计划的时候，会有一种心理：

既然我写下来了，就一定要完成。

于是计划慢慢变成了对自己的承诺。

问题是：

当现实发生变化以后，我明明已经知道原计划不合理了，却还是不愿意修改。

因为修改计划，会让我感觉：

“是不是我又失败了？”

于是出现一种很奇怪的状态。

计划已经失效。

但我还在努力维护它。

这和软件系统里的技术债很像。

一个设计当初可能是合理的。

但随着环境变化，它可能已经不适合了。

如果因为：

“这是当初设计好的。”

所以永远不允许修改。

最终维护成本只会越来越高。

所以现在我更愿意接受一个事实：

计划本来就应该允许失败。

甚至可以说：

一个不能被修改的计划，不是一个好计划。

敏捷不是“想做什么就做什么”

这里也很容易产生一个误解。

如果计划一直调整，那是不是意味着：

“我今天想学编程，明天想做自媒体，后天想创业，反正都可以调整？”

当然不是。

敏捷不是没有方向。

而是：

方向稳定，实验灵活。

比如：

我今年确定要建立第二增长曲线。

这是方向。

但具体是内容、产品、咨询、工具还是其他方式，可以验证。

我确定要提高个人影响力。

这是方向。

但具体通过公众号、小红书、视频、播客还是其他渠道，可以测试。

我确定要给未来增加选择权。

这是方向。

但具体积累什么能力，可以根据反馈调整。

所以真正需要锁定的，不是所有任务。

而是：

你这一年真正想解决的问题。

每一个 Sprint，都应该有一个最小目标

以前我的计划经常写得特别大。

比如：

“今年完成个人品牌建设。”

这句话其实几乎没有执行意义。

因为它太大。

什么叫完成？

不知道。

后来我开始尝试把它变成一个 Sprint 可以验证的东西。

比如：

这两周，完成4篇内容。

观察：

自己是否能够持续。

读者是否有反馈。

哪些主题更容易产生讨论。

生产一篇内容需要多少时间。

然后下一轮再决定。

这里有一个非常重要的变化：

我不再要求这一轮解决全年问题。

我只需要让这一轮比上一轮多获得一点信息。

这其实就是敏捷开发里的迭代思想。

计划里应该有一个“Backlog”

我现在越来越喜欢把那些“以后可能做”的事情单独放起来。

不要一想到什么，就立刻加入当前计划。

比如：

想学一个新技术。

想做一个新产品。

想开一个新的账号。

想读一批书。

想研究一个新的方向。

这些事情都可以进入 Backlog。

但：

进入 Backlog，不等于马上执行。

真正进入当前 Sprint 的事情，需要经过一次筛选。

问自己：

这件事情现在真的重要吗？

它是不是当前阶段最值得验证的问题？

如果不做，会产生什么影响？

如果做了，能够获得什么新的信息？

这样可以避免一个很常见的问题：

计划越来越长，注意力越来越碎。

我还需要一个“回顾会议”

敏捷开发里面有 Retrospective。

这个东西对人生特别有价值。

因为很多人会复盘结果，却不会复盘系统。

比如：

这个月没有完成阅读计划。

传统复盘可能会说：

“时间管理不好。”

“执行力不足。”

“拖延了。”

但如果用敏捷的方式，我会继续问：

这个 Sprint 为什么没有完成？

目标是不是太大？

是不是同时启动了太多事情？

是不是工作占用了预估之外的时间？

是不是这个目标本身已经失去意义？

是不是我根本不想做？

是不是反馈告诉我应该换方向？

这样一来：

复盘的对象，就从“我”变成了“系统”。

这也是我越来越喜欢工程思维的原因。

它不会第一时间骂系统。

它会先看：

哪里出了问题？

为什么？

什么假设错了？

下一轮怎么调整？

一个真正有用的年度计划，应该允许出现“删除”

以前我总觉得：

计划就是不断增加事情。

今年我要：

学习这个。

完成那个。

建立这个。

坚持那个。

最后整个年度计划越来越庞大。

后来我发现：

成熟的计划系统，最重要的能力之一其实是删除。

如果某件事情已经不重要了。

删掉。

如果某个方向验证失败了。

暂停。

如果某个目标已经不再符合当前阶段。

重写。

如果一个习惯只是在消耗自己，却没有产生真正价值。

停止。

这不是半途而废。

这是迭代。

软件开发里，一个功能被删除，并不意味着产品失败。

它可能只是意味着：

我们获得了新的信息。

我现在会把年度计划拆成四层

如果让我重新设计自己的年度计划，我可能不会再写一张巨大的 Todo List。

而是分成四层。

第一层：年度方向

只回答：

今年最想解决什么问题？

比如：

建立第二增长曲线。

增加家庭和工作的稳定性。

提高个人影响力。

这些是方向。

第二层：季度主题

每三个月只解决一个相对明确的问题。

比如：

第一季度：找到能够长期输出的内容方向。

第二季度：建立稳定生产流程。

第三季度：验证商业化可能性。

第四季度：总结和重构。

当然，现实发生变化以后，季度主题也可以调整。

第三层：Sprint目标

每两周或者一个月，选择当前最值得验证的事情。

不是：

“完成全年目标的十二分之一。”

而是：

“这一轮，我最想获得什么信息？”

第四层：每日任务

最后才进入 Todo List。

也就是说：

任务应该是战略推导出来的，而不是任务堆积成战略。

这是一个非常重要的区别。

我越来越觉得，人生真正需要的是“反馈循环”

传统计划更像：

目标 → 计划 → 执行 → 年底检查。

敏捷模式更像：

目标 → 假设 → 小规模行动 → 获得反馈 → 调整 → 再行动。

它不是：

Plan once, execute forever。

而是：

Plan → Do → Review → Adjust → Repeat。

这可能更符合40岁之后的人生。

因为年轻的时候，我们可能拥有更多确定性。

觉得只要努力，就能够按照计划得到结果。

但到了后来，影响人生的变量越来越多。

行业变化。

家庭变化。

身体变化。

技术变化。

机会变化。

甚至你自己也会变化。

所以：

一个允许自己改变的计划系统，可能比一份看起来完美的年度计划更重要。

年度计划不是为了预测未来

这可能是我现在对计划最大的一个改变。

以前做计划，是想提前知道：

明年我要做什么。

现在做计划，更像是在告诉未来的自己：

我准备往哪里走。

至于具体怎么走。

到了那里再看。

这其实和软件开发很像。

我们并不是因为不知道未来，所以才迭代。

恰恰是因为知道未来不可能完全确定，所以才需要迭代。

人生也是一样。

我不可能在40岁的时候，把45岁的自己完整设计出来。

甚至明年的我，可能都会和今天的我不一样。

所以我现在不再要求自己：

“一定要把这一年规划得非常完整。”

我更希望：

每一次迭代，都比上一轮更接近真正想要的生活。

最后，我想给自己的年度计划加一个新的定义

以前我理解的年度计划是：

我要在一年里完成什么。

现在我更愿意把它理解成：

这一年，我准备验证什么，积累什么，改变什么。

完成当然重要。

但更重要的是：

有没有获得新的认知？

有没有形成新的能力？

有没有发现错误的方向？

有没有减少不必要的事情？

有没有让下一轮决策变得更容易？

如果有。

那么即使某些目标没有完成，

这一年也不是失败的。

因为人生不是一次性交付的软件项目。

它更像一个持续运行、持续产生新需求、持续受到外部环境影响的复杂系统。

我们没有办法一次把它设计完。

能做的，是不断观察。

不断反馈。

不断调整。

不断重构。

所以从今年开始，

我可能不会再问自己：

“我今年的计划完成了多少？”

我会更想问：

“这一年的几轮迭代之后，我是不是比年初更清楚自己要什么了？”

如果答案是肯定的。

那这套系统，

就在向前运行。

而我，也还在继续 Debug。