案例背景：背景：负责中台项目已近两年，因不像传统项目存在既定需求和时间节点，产品的规划或者版本迭代会因为业务线实际诉求被打乱或者穿插部分需求，往往这类诉求都是非常急迫，基本上改完就要上线的那种，团队成员之间虽能理解但出于频繁切换工作内容且由于时间急迫很多功能都要临时处理对于工作效率及后续产品本身良性发展和迭代多少会有影响，那么这些穿插的需求怎么才能和通用化平台结合？
目标：提高团队成员的工作效率，及主观能动性，由于项目的特殊性，要求每个成员所写的代码都得要考虑后面的延续性，保证业务线对接或者二次开发留下余地。
实施策略：急迫的诉求和穿插的需求现状不可能被打破，那打破的只能是我们开发的模式，目前我们团队按照如下方式进行：
一般非紧急需求统一由产品收口，划入大版本迭代中，会考虑产品功能通用化。
重要且上线时间可商量需求开发产品之间拉会讨论，临时划入小版本迭代，会考虑产品功能通用化。
紧急且马上要上线需求产品收到后团队直接马上内部讨论后当场下方案开始着手，一时无法通用化的需求会考虑个性化话处理，待上线后再在大版本中将需求通用化提炼。
最终结果：由于需求通用化后原来临时处理的表结构及数据都要进行迁移，有些活动线上还在跑着的还要做兼容性处理，每次大版本升级都非常痛苦。
管理问题：问题：各部门之间如何在保证质量的同时高效愉快的完成工作。
案例：A员工处理某个临时需求，需要当日上线，评估下来改造量不大，在中午就完成改造发布测试环境并提测计划上线，但由于B员工测试认为这块功能很重要需要全流程回归，开发建议只需要测改动点后被怼，待等到凌晨才完成发版，整个过程开发及测试活干的都不是很愉快。
自我管理优势（经验总结）：
如前面案例站测试角度看待没有一点问题，而且工作态度值得表扬，这个时候其实是需要管理岗位的人出来进行协调的，一方面对整个需求和A员工开发的内容进行整体CR，把控上线风险，另一方面协调B员工针对用例进行调整，保证在有限的时间内能完成工作任务。