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