以下內文節錄自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怎麼處理專案的各種狀況，也想想自己會怎麼解，會有一 些不同的學習、啟發、體悟。 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.136.37.242 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/P_Management/M.1615473647.A.BC3.html