问问老哥们，需求评估之后开发问题

这种不太正常，我这边是按月更新不同的文档。不然很难看出进度如何。
如果有帮助，希望能够给个赞赏，谢谢~

不合理，做什么一般都是头一版订完了，二次迭代后面再提需求开发，不然很累。

规划 roadmap 先

见过
写第一部分需求
评审第一部分需求
开发第一部分
然后
写第二部分需求
评审第二部分需求
开发第二部分
这种开发的方式，好像是敏捷开发吧
同一个版本中修改或直接更新不太合适吧，怎么也得迭代版本吧

小公司很正常，大公司不清楚

一般是要拒绝这样的,不然开发不得累死

走需求变更流程，评估需求变更流程导致的开发额外耗时，这样就能让老板或项目经理看到需求变更额外耗费了多长时间，需求变更的次数。

敏捷开发是吧

完全不正常，一定要拒绝。需求变更要么下个迭代，要么重新评估技术方案，重新排期，而且反馈清楚这中间的代价是产品需求变动导致的。

@airbo 小公司需求老是变来变去

你不懂拒绝它就会一直改需求，确实有影响的帮忙改，麻烦的延长排期。无关紧要的东西下个版本改

不正常,但你也没办法,细问就说是老板的要求

不合理，不过也因情况而异。
1 、开发过程因实现可行性变更：不可厚非，需求 review 不到位，一起改
2 、需求没想好逻辑有问题：revie 不到位
3 、来自合理的外部变更：开发过程中，需求使用人或者场景变更导致的变更，没办法，一起改
4 、来自老板：评估合不合理，插入或变更的优先级高不高，如果既合理优先级又高，那就改吧

@MENGKE 这咋拒绝，主要是产品直接在同一个版本中多次修改需求，需求加到下个版本倒是无所谓

@airbo 需求确立后下版本迭代到本版本一块了，大幅度修改本版本，而不是推到版本迭代中

@seeu2ex 这个咋说，有时候直接需求文档也没怎么通知，测试的时候才知道改了

@seeu2ex #14
“我排期时间不够了，改需求的话请联系我的领导给我重新排期。”
“这个功能我已经做完了，重新开发需要 1 ～ 2 天时间，请联系我的领导重新排期。”
“这个功能改了之后我的开发时间不够，需要加一天排期，你去联系测试也把排期往后延。”
“需求改动太大太多，这个地方需要叫上其他同事重新评审，你定个会议吧。或者下个版本再上。”
“明天就要提测了，没时间改，如果必要的功能需要延期上线，不必要建议下个版本上。”
。。。。。理由太多了