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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 531 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

第 1 条附言 · 2023-06-12 08:56:19 +08:00

对自己个人项目来说，初版确实很容易陷入完美主义陷阱，在基本功能和 UI 相对完善的情况下，确保初版核心模块无 bug 可能是最重要的事，换句话说，个人开发可能更容易陷入功能循环，然而可能成为一个合格的测试是一个合格的个人产品绕不开的事，下面打算先着重测试去改 bug 了 XDM 。。。。争取先上了再说

bug

Fine

微调

平常

47 条回复 • 2024-08-11 10:43:02 +08:00

angkec

2023-06-11 09:49:45 +08:00

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

PerFectTime

2023-06-11 09:53:41 +08:00

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

pcxys

2023-06-11 10:15:59 +08:00

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

ChefIsAwesome

2023-06-11 10:20:05 +08:00

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

deorth

2023-06-11 10:25:00 +08:00 via Android

我不是，能用就行

hlwjia

2023-06-11 11:31:38 +08:00

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

Radeon

2023-06-11 11:35:35 +08:00

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

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

miv

2023-06-11 12:50:07 +08:00 via Android

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

helooo

2023-06-11 12:55:50 +08:00 via Android

同感

wonderfulcxm

2023-06-11 12:58:44 +08:00 via iPhone

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

WhoCanBeRich

2023-06-11 13:49:23 +08:00

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

WhoCanBeRich

2023-06-11 13:55:30 +08:00

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

aydd2004

2023-06-11 13:59:02 +08:00

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

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

Mantext1989

2023-06-11 14:18:18 +08:00

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

opengps

2023-06-11 14:40:39 +08:00

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

seki

2023-06-11 14:43:18 +08:00

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

looppppp

2023-06-11 14:52:01 +08:00

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

qztx

2023-06-11 15:18:09 +08:00 via Android

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

bybyte

2023-06-11 15:52:00 +08:00 via Android

原来不止我一个这样

yifangtongxing28

2023-06-11 15:59:14 +08:00

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

gps949

2023-06-11 16:43:26 +08:00

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

jiansongy

2023-06-11 17:16:21 +08:00

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

k9982874

2023-06-11 17:22:30 +08:00 via Android

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

yufeng0681

2023-06-11 17:34:15 +08:00

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

bybyte

2023-06-11 17:43:26 +08:00

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

xiaocongcong

2023-06-11 17:48:04 +08:00 via iPhone

是的，自己做东西不一样

windyskr

2023-06-11 17:49:08 +08:00

你需要一个产品经理🐶

hamsterbase

2023-06-11 17:53:25 +08:00

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

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

id80108900

2023-06-11 18:57:35 +08:00

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

inframe

2023-06-11 22:39:49 +08:00

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

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

likunyan

2023-06-11 23:16:37 +08:00

真实

hamsterbase

2023-06-11 23:58:14 +08:00

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 持续四个礼拜或者五个礼拜。

fyxtc

2023-06-12 08:48:37 +08:00

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