目前我也在做一个独立项目：一个个人的时间管理工具。我的感受就是要充分使用“迭代”的方式。也就是做好一版然后再优化一版然后再优化。

当初想的就是先自己能把这个软件的初版用起来，后面再迭代到可以发布。即便这样想，我制定的 mvp(最小可用版本)还是包含了很多功能，而且有些功能的质量标准还比较高，基本就是一步做到位的程度。

看到这儿你可能会想，那简单啊，把这很多功能精简到只留下必要的功能，把标准高的降低标准。问题就在这里，用抽象的词句来表达遇到的问题总是很容易得到抽象的解答。但真正的难点是，当时我就是觉得这些功能都是 mvp 的必需，无法删减和妥协。具体到实际项目，怎样决定哪些功能是非必要的呢？哪些功能的标准还可以降低呢？又如何降低呢？

到最后我能将原来的 mvp 再次瘦身的原因，是自己给这个 mvp 的完成时间设定了一个截止日期～～因为再不这样感觉自己就永远用不上这个 mvp 了。

在设定了截至日期后，时间的紧迫性逼迫自己思考：哪些自动完成的计算可以交给用户手动调整？哪些体验良好的交互可以用简单的交互替代？可以为哪些功能保存必要的数据，将来再实现它们？怎样充分利用之前的代码框架实现一些功能而不必推翻一些代码基础？

所有的这一切变化都是因为紧迫的时间。