最近在作研發工做管理時出現了一個比較嚴重的問題,二個不一樣工做需求同時發生,而且須要同一個團隊來解決,這是一個典型的工做時間衝突,這種衝突少能夠過的去,一但時間長並且難度大,免不了會給研發的同窗帶來壓力,我作了一個簡單的解決辦法,相信這不是最終的辦法,前面的路仍是很長。。。。併發
先說說 時間衝突來源,產品功能本質是上一套,但應用點會有多個方向,一個運營,一個是企業應用,這樣一來當運營的工做與企業應用的工做在同一時間辛併發時就會出現一個前後,但有時是很難肯定前後,並且系統功能上有些是交叉,在研發工做上是有交叉點,這樣一來就更難排列工做的前後級別了,二邊都須要等待研發團隊的即時反饋,把研發同窗搞的暈頭轉向了,並且有時工做的時間壓力大,致使研發同窗心理承受的壓力很大,團隊的生產效率下降,這些天一直在想辦法解決這個衝突。ide
從衝突問題點上看,是屬於工做量與工做時間的分配上存在着衝突,這個衝突不是本質而是表象,因此回到源頭來看衝突的根本在於工做需求的來源,一個是來自於運營部門的工做,一個是來自銷售部門的工做,因爲這二個部門的工做併發進行,而研發的工做是獨立進行,如何把這二部份工做有效的分解才能比較有效的解決如今存在的問題。產品
對於這個衝突我提出了二個解決方案,一個是把需求的來源進行分組,當運營的需求與銷售的需求下來後,研發團隊把工做進行分類分配到不一樣的研發工做組來進行,這樣的好處是把工做進行了歸類後分配給不一樣的組來進行,並且在系統功能的研發上能統一管理,不會致使系統功能的不一致性。另一個方案是先把研發團隊拆分紅二組,一組是應應一組是運營組,不一樣的組來承擔不一樣的工做,這樣在工做的分配和時間分配上都沒有衝突,但很差的地方就是在系統的功能研發溝通上存在着一些問題,由於系統是一套,但應用是會定製的,當企業的應用定製後有升級系統需求,企業能夠把當前的軟件版本升級到更高的版本並且又不能修改企類的定製功能,在研發的溝通上若是作的不到位,會給後面的升級工做帶來不少的問題。it
一般作管理工做就是這樣,解決了一個問題又會出現另一個問題,只是現階段合適用什麼方法來解決,有沒有什麼方法能夠保障它的順利進行。我認爲做爲一個管理者應該具有識別問題和解決問題,保障工做順利進行的能力。class