系统上线之后，需求不会停。业务用着用着就有新想法，这是正常的。麻烦在于怎么接，全盘答应会拖垮开发方，一律拒绝业务会不满，两种极端都不可取。
解决办法不是态度问题，是流程问题。有一套双方认可的流程，加减都在规则内，反而好办。
一、提报要走一个口子
需求从各个渠道零散地来，是最乱的情况。今天业务科长打电话说想加个字段，明天一线人员在群里说这个按钮放得不对，后天领导开会提到一个想法。这些没有统一记录，容易被漏掉，也容易重复。
建议设一个提报入口，所有需求统一登记。形式不必复杂，一个共享的表格就够用。登记的信息包括提出人、提出时间、希望的实现、业务原因、期望时间。有这几项，后面评估和排期才有依据。
登记之后要有回音。哪怕是暂时做不了，也要告诉提出人排到哪一批或者为什么不做。需求提上去没有反应，是业务方最反感的事，也会导致他们绕过流程直接找领导施压。
二、评估看四个维度
评估一个需求要不要做、什么时候做，建议看这四点。
影响面，就是有多少人、多少业务会用到。受益面大的优先。紧急程度，是不是有明确的时间要求，比如配合某个政策或者某个节点。改动成本，是改个配置就行，还是要动数据结构、要重做相关模块。风险，会不会影响已经在跑的业务，需不需要停机。
四个维度综合起来，大致能分成三类。改动小又影响大的，尽快安排。影响大但改动也大的，纳入版本计划，跟其他需求一起排。影响小改动大的，跟提出人沟通，看看能不能换个思路或者先不做。
三、按版本节奏走，别零散发
需求一个个零散地改，看着每次改动都不大，实际成本很高。每次都要开发、测试、升级、通知，还要承担改动引入新问题的风险。
建议固定版本节奏。比如每月发一版，把当月确认的需求集中处理。这样开发方可以统筹安排，测试可以集中做回归，业务方也形成预期，知道什么时候能等到。
版本计划要提前公布，说清楚这一版包含哪些需求、预计什么时候上线。被排到下一版的需求，要告诉提出人大致的批次。有了明确预期，业务方的焦虑会小很多。
四、真要紧急怎么办
有些需求确实等不了，比如政策要求限期内改，或者线上出了阻断业务的问题。这类需要留一条应急通道。
应急通道的使用要有门槛，避免什么都被说成紧急。建议约定只有满足这两种情况才能走，一是现有功能无法使用影响业务开展，二是有外部明确的时间要求。走应急通道的需求，把原定的版本计划往后顺延，这个代价要让提出方知道。
应急通道不要频繁使用。一个月用一两次还能承受，每周都走应急，说明排期机制本身出了问题，或者需求提报得太随意，需要回头看看前面几环是不是没做好。