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