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

2023-06-11 09:41:03 +08:00
 fyxtc
平常:产品和你说这里微调一下那里微调一下都感觉烦的要死。内心 OS:有区别吗?有区别吗??
个人项目:fine ,改吧,不然太丑了

平常:测试和你说这里有个小 bug 解决一下,那里一个小 bug 解决一下。内心 OS:有毛影响?有毛影响?
个人项目:fine ,改吧,不然放着难受
5152 次点击
所在节点    随想
47 条回复
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
我的一个个人产品去年 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
是的,自己做东西不一样
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
定时定量按照开发模型走,不管是经典瀑布流还是敏捷啥,按阶段迭代,确保每个节点都有对自己的交付物;

其实很多事情也是这么走的,核心就是一步吃不成胖子
QKgf555H87Fp0cth
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 不得已再封了一层底层网络库),自己大重构却没有足够的测试用例以及自动化测试的情况下说实话真的心慌,然而根本没时间去搞测试环境🐶
LowBi
2023-06-12 09:19:59 +08:00
我想开了,做完美不一定有人用,而且还耗时耗精力,这样期望越大失望也越大。还是平常心,不如先把核心搞出来上线,寻求社区型测试,有好的反馈就有完善的动力了。
FreeEx
2023-06-12 09:37:24 +08:00
比完美更重要的是完成。
szdev
2023-06-12 09:40:12 +08:00
站在开发角度,这是你写的代码质量太差才导致的,优质的程序员落地的代码 bug 少多了
jokeface
2023-06-12 09:58:51 +08:00
我是无限的重构
hoopan
2023-06-12 10:06:20 +08:00
个人产品,你们会写需求文档、原型图、UI 吗?还是直接上代码?
libook
2023-06-12 10:48:00 +08:00
活是永远干不完的,可以记录一个列表,然后划分优先级,优先做高优先级。
gyt95
2023-06-12 13:34:54 +08:00
但真的,个人项目前期真的要多想多设计。不然有的页面可能会出现摆烂的情况。“做出来就行了管他的”。

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/947670

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX