如何正確拆解專案管理問題？

完成率百分比怎麼算

編輯導讀：想要產品按時交付，順利產出，必須對專案進行監控和管理。而這個工作通常會落在產品經理的身上，無論是哪個方法論，對專案的管理都繞不開人和事兩個關鍵點。本文作者從自身工作經驗出發，對如何進行專案管理發表了自己的看法，與你分享。

“專案管理”這個老生常談的事情，一直以來都是產品落地的大問題。工欲善其事必先利其器，要想產品按時交付，順利產出，必須對專案進行監控和管理。

專案管理是一門專業的學科，研究其的方法論各有千秋，但最終還是圍繞兩個關鍵點：人和事。

產品按專案也分為不同性質的型別，一類是專案型產品，一種是自導型產品，所謂專案型指特定的企業或政府透過公開的方式進行專案招標或認領，從起草專案標書至專案完成，以招標方的主要需求和既定方案為核心展開的一系列專案活動，最後的產出品是為專案型產品，此類產品針對性強，通用性低，且週期時間會明確出限定範圍。而自導型則是由公司內部發起，為滿足公司業務發展或提高增效或降低成本或支撐利潤的標準類產品，此產品基礎功能適用性較高，面對物件豐富不侷限，有很大的拓展空間或預留改造空間。

不管是哪類專案，都一樣需要專案組配備對應的資源，包括人力、裝置、時間、空間、資金等基本要素。

常見的專案流程包括：制定章程——限定範圍——計劃管控——成本管理——質量核准——風險預案——結項收尾。

小而輕量的網際網路公司喜歡採用敏捷開發，小步快走，低成本試錯；而中不溜的企業則因為自身規模或產品的構造模式的限制，不得不以專案的形態作為團隊衡量輸出的一個標準。

然鵝，非傳統專案型的企業，在資訊化轉型的過程中，並非所有產線都具備專案經理這一重要而又業務精深的專職人員。此類工作，常常由產品經理擔任。

所以為什麼，我們可以經常聽到，產品經理也要懂專案管理。實際上，除了因為缺少專職人員，部分對專案管理的瞭解不能容易陷於停留專案的表層，僅瞭解其流程最終無法保障專案的質量是否達到預期目標，因此對業務的深淺也要有一定的要求。另外即使有專案經理這一角色，他手上多個專案在並行時，難以協助產品重點推進該產品線的進度和管理。所以，產品經理和專案經理倒是像相互協作的兩兄弟，相互配合、協作。

但是，問題難就難在，如果沒有專案經理而有產品人員擔任的時候，大多產品無權也無責過問專案成員的安排和程序，僅靠人品或個人魅力只會消耗個人的情緒和工作負餘。以下有幾點建議：

組織立項會議時，邀請相關利益方加入，特別是技術團隊的老大和產品團隊的老大，以及雙方的老大大，讓其明確授權，包括調配資源、管理團隊、進度彙報收集的權利。如果老大無暇參加此會議，則需要書面宣告或者郵件周知相關人員，由誰負責或擔任此類工作。不要看似簡單，其實在很多流程不夠規範的公司內，職權是界定不清的，導致相關人員不同程度的甩鍋與拖延無責的心態繼續摸魚，另外，群聊記錄的口頭宣告是不可靠的。

專案彙報的管控，時間為一週一次或一週兩次為宜，記錄的內容需包含現階段人員的一週按日程格子記錄的開發進度，以及狀態是否正常、延期、完成率的百分比。如有備註要宣告人員的具體情況，比如請假、臨時任務、其他事項等等，補救措施是調休加班、往後期延或是提前完成不需調補等說明，確保跟上開發計劃。進度每週抄送一次專案組成員，利用大眾的監督施加適當的壓力與責任，而不是產品經理一人對一個技術團隊。

明確制度，賞罰分明，一旦計劃確認完畢，執行者在執行過程中除特殊情況，否則不可隨意修改，有明確的賞罰制度，也有一定的獎勵制度，但是獎勵需要公司層面才能決策的，所以不一定都有，所以部門內看能否透過其他途徑給專案成員獎勵。獎金的激勵一定程度上會促進成員的積極性，賞罰能夠規制約束專案成員，否則立不立項、能不能如期完成對成員來說無關痛癢，急的說不定就是產品經理自己。

營造參與感與成就感，不管是誰，當做出了一款產品並得到他人的誇讚時，內心的成就感是不言而喻的，是對自己付出的犒勞和自我追求的認同感。所以專案過程中，要確保專案成員能夠從中獲得自己想要的一些東西，經驗也好、金錢也好，讚許或評選鼓勵也好，都是可以促進成員的積極性。很不好的是如果都是產品經理一個人在孤軍作戰，那麼專案是真的很難推動，把相關的權益和責任讓不同的人員負責，才是對資源的最好分配。

專案計劃分配，不同的專案計劃模板各有不同，細到什麼程度因不同公司決定，但是工作任務一定要拆解開來，WBS（工作分解結構）是最常用的一種方式，大化小，小成無。將整體專案劃分為不同的工作包，由長期解構為短期，這倒是挺貼合產品經理日常思考模式的，整體——拆解——分析——執行——完成，WBS能直觀快速的表現出對每個階段的任務點及目標，協助清晰的按照計劃進行，也便於快速查詢問題。

風險控制，風險一般包括定性風險和定量風險，此部分比較偏知識論，經驗有限的人員常常對風險不能做好全面的預判，高階產品也是因為在專案中不斷的總結，避開了遇到過的坑坑窪窪。所以，在專案結束做好總結中或吸取以往專案的經驗的維度，是風險控制的初級識別的一個重要方式。其次，可透過頭腦風暴，組織專案成員在負責的模組所會碰到的潛在問題，以及產品經理和其他部門對接時的可能性事件，如流程變更、人員離職、需求變更等等，列出表格，預留解決的時間。定量的話是指風險不確定但可被量化，書本的定義是對每一風險發生的機率及其專案目標產生的影響，以及專案整體風險的範圍進行數值分析。這類分析透過發生機率的大小而有針對性的採取不同的措施進行規避。

需求變更，作為需求發起人，又作為專案監控人，這樣的事情簡直讓人左右為難，一邊需要專案如期完成，一邊又需要變更增加開發量。當然，需求不是你想變，想變就能變的，往往因為公司層面的硬性要求、領導緊急下發的必要性需求、驗收時與初期需求不符、影響核心利益的或市場政策的變化，如產品商標變動、個人資訊隱私保護法的推出等等不確定因素，導致專案過程中需要及時的做出調整，調轉方向。專案不同進行階段的變更對專案的風險和影響是不一樣的。變動涉及的範圍也是不一樣的，以不涉及流程變動為例的變更：

影響程度：立項前<立項未開發<立項已開發<開發完成<測試<驗收，時間越長，風險成本越大。

專案立項後，開始進入開發之初，此時提出變更風險較少，專案計劃可以隨之調整。

進入開發階段，技術和產品之間會反覆確認需求點，到了相應模組時，在前後端技術確認好（不可遺漏任何一邊），進行調整，在開發計劃中加入變更事項，重新安排計劃。

開發完成或測試階段時，這時候提出變更，技術肯定已經有自己的小脾氣了，本來已經完工，剩下來就是改改bug等驗收了，禿頭的毛終於可以減速了；何耐產品經理又賊兮兮的來了，此時耐心的溝通及表明變更的必要性是非常重要的，我們常用領導來說事，但是假如站在領導的立場，恐怕也會在心裡小聲嘀咕‘常常拿我說事，這個人工作能力不怎麼樣呀’。所以搬出領導的事情不能過於頻繁，畢竟這也可能是最後一張底牌了，久而久之，領導心裡就有了對產品人不滿意的自我暗示，而，暗示是會固化的且不易消除。

所以怎麼辦呢？對此不敢說必須有見成效，畢竟專案管理也有百來年的歷史了，專家們都沒琢磨透呢，只能說透過自己的經驗分享一下。

馬斯洛的需求原理越來越多人熟知了，但終歸還是太泛，請大家吃一頓好像也不能彌補對個人情感的需求，且我是做不來的，畢竟與生俱來的冷場王。所以又還是尋找中規中矩的方式推動了，如（客觀地）讓專案相關人明白需求變動的原因及重要性，闡明需求的內容和尋找最小變動的可執行方案，計算出潛在價值或改動可帶來的收益，會議也是必要的，私下通知沒有支撐力。（主觀）讓他們知道產品是站在他們角度去想問題的，一起吐槽吐槽變動的來源但又無可奈何的態度。

需求變動是真的很常見，而產品經理本身就需要過濾需求，把控專案，大的變更也是有可能中斷專案的，所以不能忽視這一點。產品在市場部和專案管理部中間本就是左右為難，除了是個需求傳話筒的工具人，我想，更要在其中發揮自己的主觀能動性，沒有什麼產品提出馬上就能做出來的，好的產品值得等待，而專案過程所花費的時間和精力就是我們的等待，但是這個等待值不值得，只有市場才能驗證。

本文由 @漂浮檸檬核 原創釋出於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。