平台化改造新增需求怎么排期？先看版本容量
平台化改造过程中，新增需求往往会和现有改造任务、版本目标一起出现。面对需求堆积，很多团队都会疑惑：到底该先做哪些，哪些可以延后？
排期应围绕版本目标、业务价值和交付风险来判断
排期时不要只看“谁先提出来”，而要结合版本容量、需求价值、依赖关系和实施复杂度综合评估。优先安排能支撑核心目标、影响面更大的需求，同时关注技术依赖和资源占用情况。对于短期内无法纳入版本的需求，可以进入候选池，按业务紧急度和改造收益持续复评。
很多时候，平台化改造进行到一半，业务方又提出新增需求，团队会担心现有排期被打乱。版本容量已接近上限时，是否还能接入新需求，需要怎么判断？
可以评估插入，但必须有明确的取舍机制
当版本容量接近饱和时，新需求并不是不能进，而是要做容量置换。也就是说，新增需求如果足够重要，就需要同步评估是否有其他低优先级事项退出本版本。这样能避免团队超负荷，也能保证版本交付质量。若需求无法替换掉既有内容，更适合进入下一版本规划。
在平台化改造项目里，新增需求经常处于“看起来很急，但又不确定值不值得占用当前版本容量”的状态。团队需要一个更清晰的判断依据。
看三点：是否影响主线目标、是否存在强依赖、是否能在当前容量内稳定交付
判断是否纳入当前版本，可以重点看需求是否直接影响版本主线目标，是否依赖当前改造成果才能落地，以及团队在现有容量下能否稳定交付。若需求与当前版本目标高度一致，且开发、联调、测试都能在容量内完成，就适合纳入当前版本。若需要额外协调较多资源，或容易挤压核心任务进度，放到下个版本会更稳妥。
当业务方提出新增需求，而研发团队评估后发现版本容量不足时，沟通方式很关键。既要说明限制，也要避免让对方感觉需求被直接否定。
用容量和优先级作为沟通依据，给出可执行方案
沟通时可以清楚说明当前版本的容量边界、已承诺交付范围，以及新增需求对现有计划的影响。比起单纯说“做不了”，更适合提供可执行选项，例如：进入本版本候选池、拆分为阶段性交付、或安排到下一版本优先评审。这样既能保护交付节奏，也能让业务方理解排期依据。