这是一个创建于 238 天前的主题，其中的信息可能已经有所发展或是发生改变。
年前年后一直在做一个首页改版功能。开发前产品给的文档很简单，只有几幅示图和简短的说明。
可是做着做着想要的功能点就越来越多，这感觉不好就改一下，那感觉不合理就改一下。
我是也是前端菜鸡，开发节奏完全跟着产品走，这个改版需求从 12 月底到 2 月中旬还是有些问题，今天险些改了整体的数据结构
可是做着做着想要的功能点就越来越多，这感觉不好就改一下，那感觉不合理就改一下。
我是也是前端菜鸡，开发节奏完全跟着产品走，这个改版需求从 12 月底到 2 月中旬还是有些问题，今天险些改了整体的数据结构
 | 1 jingcheng1108 238 天前 定版本，一个版本一个版本迭代 |
 | 2 murmur 238 天前 没法避免，到最后都是要么加资源，要么重构 |
 | 3 snimstice 238 天前 程序员没办法避免，毕竟只是干活儿的，踏实干活儿赚工资就行了 |
 | 4 emSaVya 238 天前 需求变更很正常 但是产品需求要落地 邮件+产品文档。每次变更 开发要给出对应工作量+排期。 |
 | 5 standchan 238 天前 没法避免，尽量不要太完美主义吧 |
 | 7 1zh3n 238 天前 从你描述来看就是产品不专业，需求不明确。只要需求随意变动，就没办法解决你说的问题。 最好让产品出需求文档和原型图。不行的话至少把每次把要实现的需求留档，让产品确认后再改。 开发迭代按照产品目标做里程碑，一个里程碑算一个阶段目标。 |
 | 10 coderluan 238 天前 程序员不要把自己当厨子，做一个无情的压面机就可以了，不加班。 |
 | 11 liu731 PRO 无解，架构设计之初没有时间空间留给后面无限的需求 |
 | 13 killva4624 238 天前 如果 PM 管理不好功能的预期，就试着去做 PM 的预期管理： - 这个需求需要做 X 天； - 这个增加的需求如果加进来，需要增加 X 天； - 现在开发工作已经饱和了，需要完成 A 后才能做 B ； PM 其实权力很大，如果他把握不好节奏，就会把项目弄垮。 可以去看一些项目管理或者迭代管理的书，掌握基本的概念会对你回绝他的不合理需求很有帮助。 |
 | 14 jadehare 238 天前 开发文档肯定要有的，不是公司大小的问题，只要有开发需求，就得有需求文档。做开发要有自己的态度啊，对需求文档就是你不写我随缘做，我没做或者做的不对那不是我的问题，是你没写。 |
 | 15 7gugu 238 天前 这种是产品问题，不是开发能解决的。因为根本问题是，产品没有提供一个稳定的需求文档，导致需求反复变更，开发跟着反复变更。一般这种情况下，应该是让 PM 去把握节奏，如果 PM 能接受发布时间延期，你也就只能跟着一块做变更了。 |
 | 16 weidaizi 238 天前 不就应该是这样的吗？无论是代码、产品还是战斗机，都是一代一代迭代升级出来的，一开始做个初始的东西，发现不完美的东西，慢慢更新往上堆，然后过了很久意识到需要进行大的改动的时候，重构就开始了，接着又是更新，修修剪剪，再次重复以前的步骤；只不过比较强的选手，可以更快的到达一个当下更接近满意且方便日后升级的阶段 |
 | 17 BeautifulSoap 238 天前 这和程序员有什么关系？就国内这种牵条狗来都能当产品经理的环境，这就是纯粹产品经理或者负责需求设计的人的锅 对业务不熟悉，对业务各种约束条件和复杂的业务没一丁点认识，考虑不到任何复杂点的业务逻辑 原本这些工作都应该是产品的责任，结果到最后都是程序员在那写代码了，才发现一些代码上的判定条件根本没考虑到（表现出来是程序判定条件没考虑到，但本质上就是业务设计出了纰漏） |
 | 18 leejinhong 238 天前 本质上就是产品的业务水平问题。真正厉害的产品对需求的理解应该是要比开发还要深刻的  还有一个问题就是产品本身对开发是一点也不了解，以为代码就跟文字一样可以随便改动，或者是一开始没考虑到的需求，到后期不就是补一下而已。就会导致产品在设置需求的时候，想不通的一些链路就先跳过  不要问我为什么！兄弟感同身受 |
 | 19 MRG0 OP @BeautifulSoap #17 的，还真是，后边就是各种打补丁 |
 | 20 AdminZ 236 天前 我这个月都在重构，还好留了比较多时间，优化无底洞 |
Select Language