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

[fyxtc]

平常：产品和你说这里微调一下那里微调一下都感觉烦的要死。内心 OS:有区别吗？有区别吗？？
个人项目：fine ，改吧，不然太丑了

平常：测试和你说这里有个小 bug 解决一下，那里一个小 bug 解决一下。内心 OS：有毛影响？有毛影响？
个人项目：fine ，改吧，不然放着难受

[fyxtc]

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

[fyxtc]

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

[fyxtc]

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

[fyxtc]

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

[ajax10086]

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

[fyxtc]

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

[ny562kPWNJK9g86f]

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