这是一个创建于 412 天前的主题，其中的信息可能已经有所发展或是发生改变。
需求文档版本确立之后产品一直在同一个版本中修改或更新，目前相当于边开发边确立需求，这种正常吗
 |
1
starSnail 2023-10-18 14:41:41 +08:00
这种不太正常，我这边是按月更新不同的文档。不然很难看出进度如何。
如果有帮助，希望能够给个赞赏，谢谢~ |
 |
2
SpacePig 2023-10-18 14:44:30 +08:00
不合理，做什么一般都是头一版订完了，二次迭代后面再提需求开发，不然很累。
|
 |
3
aboutyang 2023-10-18 16:09:50 +08:00
规划 roadmap 先
|
 |
4
airbo 2023-10-18 16:26:31 +08:00  1
见过
写第一部分需求 评审第一部分需求 开发第一部分 然后 写第二部分需求 评审第二部分需求 开发第二部分 这种开发的方式，好像是敏捷开发吧 同一个版本中修改或直接更新不太合适吧，怎么也得迭代版本吧 |
 |
5
xiaohang427 2023-10-18 16:28:05 +08:00 1
小公司很正常，大公司不清楚
|
 |
6
unco020511 2023-10-18 16:53:18 +08:00
一般是要拒绝这样的,不然开发不得累死
|
 |
7
rqzrqh 2023-10-18 16:56:41 +08:00 1
走需求变更流程，评估需求变更流程导致的开发额外耗时，这样就能让老板或项目经理看到需求变更额外耗费了多长时间，需求变更的次数。
|
 |
8
SACKJJKLL 2023-10-18 16:57:27 +08:00
敏捷开发是吧
|
 |
9
jfds 2023-10-18 17:55:15 +08:00
完全不正常，一定要拒绝。需求变更要么下个迭代，要么重新评估技术方案，重新排期，而且反馈清楚这中间的代价是产品需求变动导致的。
|
 |
11
MENGKE 2023-10-19 09:45:50 +08:00
你不懂拒绝它就会一直改需求，确实有影响的帮忙改，麻烦的延长排期。无关紧要的东西下个版本改
|
 |
12
veni2023 2023-10-19 09:54:20 +08:00
不正常,但你也没办法,细问就说是老板的要求
|
 |
13
vice 2023-10-19 16:17:21 +08:00
不合理，不过也因情况而异。
1 、开发过程因实现可行性变更：不可厚非，需求 review 不到位，一起改 2 、需求没想好逻辑有问题：revie 不到位 3 、来自合理的外部变更：开发过程中，需求使用人或者场景变更导致的变更，没办法，一起改 4 、来自老板：评估合不合理，插入或变更的优先级高不高，如果既合理优先级又高，那就改吧 |
Select Language