项目做不完，先给功能单减重

个人项目一做不完，最顺手的补救办法就是继续加时间。

今晚多熬两小时，周末再补半天。功能列表一直留着，只有日历在退让。对还在上班的人来说，这很容易变成第二份没有下班时间的工作。

当然，有些活确实需要更多时间。值得先查的是：加出来的时间，在完成原来的事，还是养大了一个不断增加功能的项目？

Basecamp 在 《Shape Up》的“设定边界”一章里，介绍了一种时间预算：先决定这件事值得投入多少，再设计预算内能做成的方案。

它和“先列功能，再估工期”的顺序相反。时间先定，范围允许变化。书里用一到两周和六周作为团队项目的常用预算，并没有“八小时做不完就砍成四小时”这条通用规律。

书中的一个例子很直白：剩下一周，要在修正错别字和新增一节之间取舍。作者选择不加那一节，留时间把已有部分做好。

省掉的是新增范围，已有内容的质量仍要守住。

时间预算的用处，是让取舍提早发生。

放到业余项目里，可以设一个很小的假设预算，比如周末四小时，验证一个人能否走完一次资料提交。

这一轮可能只需要一个表单，通知先手工发，结果先人工确认。账号体系、统计面板、全自动处理都可以等下一轮。这个版本只回答一个问题：这条流程有没有人愿意走，卡在哪里。

四小时只是示例，换成两小时或两天也可以。它不会让复杂工作违反原有工期，更不能把安全检查、数据完整性或法律要求一起砍掉。

如果保留这些底线后，最小的结果仍装不进去，就有几种诚实选择：缩小问题、把这一轮改成验证关键风险，或者承认需要更大的预算。没有哪条规则要求必须在四小时内交出一个勉强可用的产品。

这和“先做差一点”有区别。功能可以少，但承诺过的那一步要走得完整。资料确实收到、结果能查到，才叫这一轮完成；只有一个漂亮页面，只能算页面做出来了。

我更认同这样的安排：每轮结束能看到一个结果，也能知道哪些事还没做。下一轮是否继续，由这次得到的信息决定。

业余时间本来就有限。让功能单也接受这个事实，比让每一个晚上无限加班，更像一份能守住的计划。