當團隊陷入互相指責的惡性循環 - PMP

以下內文節錄自blog拙作 https://lnkd.in/gSB_g_X


背景
這個實際案例是公司的其他PM所領導的專案所面臨的困境，並非我自己實際參與；但也因
為這樣，比較容易從旁觀者的角度來觀察，在與該PM的討論過程中，我也竭盡所能給了一
些建議，期待能有些突破，對專案能有所推展；當然也希望自己永遠沒有機會陷入這種窘
境。

這個產品事業部在公司內部相對是比較小的營收份額，但其實也存在已經有十多年了；也
許由於工業領域的關係、而產品技術相對門檻比較高些，新產品研發速度相對緩慢很多。
而近來又由於軟體架構要改朝換代，新產品開發的時程估算出來，光baseline就拉了2-3
年之久。而更複雜的是，軟體研發團隊又人才盡失、近半年走了很多主力戰將，更讓整個
專案雪上加霜。

第一次衝突
由於專案複雜度高、軟體主管在評估資源分派、時程的時候，相對保守，且必須顧及內部
組成、避免更多人才流失，一開始抓baseline就拉了2-3年之久，其中包含了，SQA test
plan在年久失修的情況下，也得趁這次產品軟體架構要改朝換代，需用比較系統化的方式
建立test plan。PM在缺乏其他專案資訊可以參照的情況下，且有專職的SW PM，沒辦法
challenge 專案團隊規劃出來的project schedule/resource baseline，就先這樣執行了
幾個月。

但在幾個月後，與最高主管的staff meeting中，第一個milestone就出現問題：SQA測試
不下去，原因是RD交付的項目有blocking issue導致無法按照原始規畫的範疇完成驗證。
在最高主管面前，RD、SQA團隊當然是互相攻訐怪是對方的錯。因為此研發專案的時程很
長，且critical path取決於軟體開發的進程，所以PM, RD, SQA三方合議、在主管的同意
下採取"Agile"的開發方式：也就是當RD開發到一定程度後﹝所謂one sprint﹞，就提供
給SQA做部分驗證跟測試，以避免又出現blocking issue導致SQA無法完成驗證。

第二次衝突
如此又過了兩個月，在第二次向最高主管報告的時候，最高主管當場才猛然驚覺，規劃出
來居然最快要兩年多才能上市，當場震怒！又開始RD、SQA互相指責，指稱對方才是主要
罪魁禍首的原因；RD、SQA也都聲稱都是因為資源不足等等，無法滿足公司期待的目標；
PM站在旁邊只能傻眼，不知如何進行下去這還有2年要開發的日子，心也冷了…

稍微正面一點是，至少最高主管現在開始重視這個團隊問題，要求要有月檢討會議，並針
對專案目前的issue、schedule update等作檢視。

我的看法
專案管理手法
一開始建立project baseline的時候，軟體相關這種架構性的大改造，的確非常難評估其
efforts；我建議一樣要先以產品要上市的預期時間，往回倒推，PM先以商業利益優先先
列出大方向的milestones & date (也許是以"季"為單位)；之後交付軟、硬體、SQA等協
同的團隊，一起再將milestones breakdown列出可能要有的小里程碑。並好好管理團隊內
部可能有的比較"次要"的任務；比如開發中的design documents、QA survey測試計畫建
立的系統等時程。的確這些任務不是不重要，但其實不緊急。缺乏以商業角度出發的主要
目標，會導致專案團隊以處理自己眼前任務的邏輯bottom-up規劃時程，完全偏離組織、
或公司的要求。長遠而言，就會造成產品沒有競爭力、公司越來越不重視這條產品線，當
然就團隊士氣低迷、人才盡失。

「人」的管理
其實PM在整個討論過程中非常重要，但很可惜的是，連主要stakeholders的要求都沒有弄
清楚。schedule在第一次發生團隊紛爭的時候，就應該表明給最高主管，讓他清楚知道其
實這個新產品上市時間，已經嚴重偏離市場期待。當下就可以要求團隊一起想辦法解決；
而且，PM就可以拿著「尚方寶劍」，有更高的權力要求RD、SQA主管想辦法把不重要的任
務先擺到後頭。RD主管、SW PM其實mindset也許在行之有年的氛圍下，也變得不注重時程
；這更需要最高主管的當頭棒喝，要不靠一個PM在後面抽鞭子，其實鞭長莫及，也沒有效
益。

結論
不知道大家看完這個案例分享，是否也有其他可能的解法？在我PM職涯中，即使不是我領
導的專案，我還是會看看其他PM怎麼處理專案的各種狀況，也想想自己會怎麼解，會有一
些不同的學習、啟發、體悟。


--