案例背景：背景：負責中臺項目已近兩年，因不像傳統項目存在既定需求和時間節(jié)點，產品的規(guī)劃或者版本迭代會因為業(yè)務線實際訴求被打亂或者穿插部分需求，往往這類訴求都是非常急迫，基本上改完就要上線的那種，團隊成員之間雖能理解但出于頻繁切換工作內容且由于時間急迫很多功能都要臨時處理對于工作效率及后續(xù)產品本身良性發(fā)展和迭代多少會有影響，那么這些穿插的需求怎么才能和通用化平臺結合？
目標：提高團隊成員的工作效率，及主觀能動性，由于項目的特殊性，要求每個成員所寫的代碼都得要考慮后面的延續(xù)性，保證業(yè)務線對接或者二次開發(fā)留下余地。
實施策略：急迫的訴求和穿插的需求現狀不可能被打破，那打破的只能是我們開發(fā)的模式，目前我們團隊按照如下方式進行：
一般非緊急需求統一由產品收口，劃入大版本迭代中，會考慮產品功能通用化。
重要且上線時間可商量需求開發(fā)產品之間拉會討論，臨時劃入小版本迭代，會考慮產品功能通用化。
緊急且馬上要上線需求產品收到后團隊直接馬上內部討論后當場下方案開始著手，一時無法通用化的需求會考慮個性化話處理，待上線后再在大版本中將需求通用化提煉。
最終結果：由于需求通用化后原來臨時處理的表結構及數據都要進行遷移，有些活動線上還在跑著的還要做兼容性處理，每次大版本升級都非常痛苦。
管理問題：問題：各部門之間如何在保證質量的同時高效愉快的完成工作。
案例：A員工處理某個臨時需求，需要當日上線，評估下來改造量不大，在中午就完成改造發(fā)布測試環(huán)境并提測計劃上線，但由于B員工測試認為這塊功能很重要需要全流程回歸，開發(fā)建議只需要測改動點后被懟，待等到凌晨才完成發(fā)版，整個過程開發(fā)及測試活干的都不是很愉快。
自我管理優(yōu)勢（經驗總結）：
如前面案例站測試角度看待沒有一點問題，而且工作態(tài)度值得表揚，這個時候其實是需要管理崗位的人出來進行協調的，一方面對整個需求和A員工開發(fā)的內容進行整體CR，把控上線風險，另一方面協調B員工針對用例進行調整，保證在有限的時間內能完成工作任務。