做自己的个人项目的时候，真的会发现无限的需求要改，无限的 bug 要改

感觉就是自己变产品经理了

亲生儿子和替人养儿子还是有很大的区别的

如果站在产品角度，问题无限，需求无限。
如果站在开发角度，能用就行，够用就好。

所以个人项目没几个不烂尾的。做好的东西，看着不顺眼，重做；看到别人做得更好，重做。公司也这么漫无目的的改，结果就是加班三年，最后还上不了线。

我不是，能用就行

这是独立开发者不成功的核心原因 - 完美主义

那当然，但是这是好事，因为说明至少有人用。有人用比没人用好无穷倍

一个软件设计的时候以为只要留出 N 个扩展维度就行了，实际上是变成 N*N*N ... 个分形维度要维护 /扩展。本质上反映了人类的需求是无限的这个事实

警惕完美主义。
如果你不为你发布的第 1 个产品感到脸红，那么他发布的太迟了。

同感

我发现自己做经常有一些可有可无虚假的需求，迫不及待地改来改去，只有停一段时间，比如半年才会发现哪些功能是真正的刚需。

可以学些软件工程和需求工程的知识，自己的项目不代表没有优先级和主次了，别被无关紧要的 bug 影响了前景发展。

@miv "如果你不为你发布的第 1 个产品感到脸红，那么他发布的太迟了。"
这种听起来充满哲理实践起来一堆烂摊子的没有逻辑支撑的产品理念，还是别当做真正的实践方案吧。

当初我自己的一个项目还特么抽风重构了下，那酸爽。

屎山代码原来说的就是我自己。

笑死，本人真实写照了可以说是

所以说，没给自己做过东西的人，体会不到编程的乐趣

所以做个人项目也能带来不一样的好处，做了很多平常不会去做的事情

深有同感，还懒的先画 ui ，改了好几版了

需求分析和设计不完善就急于写代码的结果，看一下 11 楼

原来不止我一个这样

实际情况是复杂的，比人的想象还要复杂。所以软件工程师总是被业务挑刺，实在心累。

所以一个优秀的产品经理真的得懂两件事，一个是计算投入产出比，一个是懂得排工期。
另外，无限不是件好事吗？ Intel 本身肯定也希望 ticktock 一直迭代下去，而不是在某一代酷睿后就没事做了。

微信还是一直在迭代升级，都成为国民级的大产品了，依然每天都在改进啊

我的一个个人产品去年 10 月左右开工，业余时间做一下，磨了半年终于快做完上线了。上个月觉的不行开始大重构，重构完得比原来的体量大三倍，到现在终于快要弄完了💀

如果想清楚了，就改； 复盘看自己的重构，还是没有达到目的，说明没想清楚，损耗了生命

跟我几乎一摸一样，个人开发的时候追求完美主义，不过我慢慢想通了，其实能正常的稳定运行就已经可以了，远远比烂尾好，有一定是比没有好的

是的，自己做东西不一样

你需要一个产品经理🐶

我深有体会。 分享一下我的做法。


1. 先写好需求文档， 写完需求文档以后。
2. 严格按照需求文档开发，只能修 bug ，砍需求 。 不能加需求
3. 实现好一会自己测试一下， 把 bug 记录
4. 把 bug 都需求，不要加需求。

定时定量吧，
先解决最重要的。

定时定量按照开发模型走，不管是经典瀑布流还是敏捷啥，按阶段迭代，确保每个节点都有对自己的交付物；

其实很多事情也是这么走的，核心就是一步吃不成胖子

真实

https://zhuanlan.zhihu.com/p/87424183

推荐读一下这篇文章。 讲 vs code 和 Basecamp 是怎么保障发布的。

下面是我拷贝过来的原文



直到最近我读了 Basecamp 的产品方法论 Shape Up: Stop Running in Circles and Ship Work that Matters 。这份文档介绍了 Basecamp 是如何保证，一个想法通过层层把关，在一个自由的工作环境中，最终准时变成产品发布出去的。

## 发布
重要的事情最先说，整个文档的核心目标就是发布。这些年大环境的熏陶下，大家都明白了 “Ship it”，重要的是把产品发布出来，因为一个产品没有问世见到客户，一切都是空谈。“Ship it” 很难，努努力总是可以达到的，没达到的团队就死了。

相比之下，更难的则是产品发布后，持续的发布迭代。为了确保每个 release 计划的新功能都能够发布出去，Basecamp 的第一个准则就是小步快跑，六个礼拜一个 release ，把 deadline 作为严格标准，其他事情都得为 deadline 做让步。
六个礼拜的时间是 Basecamp 实践后找到的最合适他们的产品发布周期。VS Code 也差不多，通常一个 release 持续四个礼拜或者五个礼拜。

@k9982874 我这个项目开发时长差不多接近 500 小时，目前差不多完成 70-80%的样子，期间大重构了一次 UI （为了用户体验换了 UI 框架，主要是后面突然发现这个新的 UI 体验更好，只能咬牙上了），大重构了一次网络（为了解决某些 bug 不得已再封了一层底层网络库），自己大重构却没有足够的测试用例以及自动化测试的情况下说实话真的心慌，然而根本没时间去搞测试环境🐶

我想开了，做完美不一定有人用，而且还耗时耗精力，这样期望越大失望也越大。还是平常心，不如先把核心搞出来上线，寻求社区型测试，有好的反馈就有完善的动力了。

比完美更重要的是完成。

站在开发角度，这是你写的代码质量太差才导致的，优质的程序员落地的代码 bug 少多了

我是无限的重构

个人产品，你们会写需求文档、原型图、UI 吗？还是直接上代码？

活是永远干不完的，可以记录一个列表，然后划分优先级，优先做高优先级。

但真的，个人项目前期真的要多想多设计。不然有的页面可能会出现摆烂的情况。“做出来就行了管他的”。

但实际上，如果这个个人项目最终是给别人用的。那么每个地方都不能马虎。因为使用者不同于开发者，使用者很容易就察觉出哪些地方体验不好。

@szdev 一人团队说站在开发角度是不是有点不对题？就算站在开发角度，一个人负责一个模块和负责整个项目迭代质量上绝对有差，加上 deadline 对待方式上是两个概念，就我个人来说公司项目在专员测试下 bug 一个月不超过 5 个，自己项目有时候随便玩玩一天就能发现 3 个。

@gyt95 确实是这样，开发者和用户看的角度区别很大，就要把自己的产品当成是路边捡来的方式来体验才能感觉到。不然经常会出现自己感觉很好，用户可能只觉得一般，自己感觉凑合，用户就觉得极差了

@libook 嗯啊，目前就在尽量缩短高优先级列表

@hoopan 需求文档大概率是需要写的，哪怕是草稿，不用正式但要自己能明白说了啥，除非项目构成脑内已经很清晰，UI 可能会上花瓣找些参考图

我现在就苦恼软件质量问题，自己测的也不专业 外加精力有限 总感觉忙不过来，另外很多东西在写需求文档时 根本想不到，只有思路处于那个场景之下才会察觉遗漏，遂又返回去补充。搞来搞去 时间全花在这类事上面了

@ajax10086 一样一样啦，一开始可能就想到最简单的场景，后面慢慢迭代出来的，不要苦恼，一步步来，等有经验以后都会慢慢好起来的

我觉得你应该按照正常的工作流来实现，不要一上来就编码，自己至少要画个原型，并且把每个页面的细节都推敲和打磨好，不要觉得这个过程太浪费时间，例如你就让自己花 2 ～ 3 周时间来做这个。只要完全了这一步，后续的调整就会比较少了。