品牌行銷策略，產品行銷與設計，各類型行銷推廣案例分享-品牌行銷點點讚
編輯導讀：想要產品按時交付，順利產出，必須對項目進行監控和管理。而這個工作通常會落在產品經理的身上，無論是哪個方法論，對項目的管理都繞不開人和事兩個關鍵點。本文作者從自身工作經驗出發，對如何進行項目管理發表了自己的看法，與你分享。
“項目管理”這個老生常談的事情，一直以來都是產品落地的大問題。工欲善其事必先利其器，要想產品按時交付，順利產出，必須對項目進行監控和管理。
項目管理是一門專業的學科，研究其的方法論各有千秋，但最終還是圍繞兩個關鍵點：人和事。
產品按項目也分為不同性質的類型，一類是項目型產品，一種是自導型產品，所謂項目型指特定的企業或政府通過公開的方式進行項目招標或認領，從起草項目標書至項目完成，以招標方的主要需求和既定方案為核心展開的一系列項目活動，最后的產出品是為項目型產品，此類產品針對性強，通用性低，且周期時間會明確出限定范圍。而自導型則是由公司內部發起，為滿足公司業務發展或提高增效或降低成本或支撐利潤的標準類產品，此產品基礎功能適用性較高，面對對象豐富不局限，有很大的拓展空間或預留改造空間。
不管是哪類項目，都一樣需要項目組配備對應的資源，包括人力、設備、時間、空間、資金等基本要素。
常見的項目流程包括：制定章程——限定范圍——計劃管控——成本管理——質量核準——風險預案——結項收尾。
小而輕量的互聯網公司喜歡采用敏捷開發，小步快走，低成本試錯；而中不溜的企業則因為自身規模或產品的構造模式的限制，不得不以項目的形態作為團隊衡量輸出的一個標準。
然鵝，非傳統項目型的企業，在信息化轉型的過程中，并非所有產線都具備項目經理這一重要而又業務精深的專職人員。此類工作，常常由產品經理擔任。
所以為什么，我們可以經常聽到，產品經理也要懂項目管理。實際上，除了因為缺少專職人員，部分對項目管理的了解不能容易陷于停留項目的表層，僅了解其流程最終無法保障項目的質量是否達到預期目標，因此對業務的深淺也要有一定的要求。另外即使有項目經理這一角色，他手上多個項目在并行時，難以協助產品重點推進該產品線的進度和管理。所以，產品經理和項目經理倒是像相互協作的兩兄弟，相互配合、協作。
但是，問題難就難在，如果沒有項目經理而有產品人員擔任的時候，大多產品無權也無責過問項目成員的安排和進程，僅靠人品或個人魅力只會消耗個人的情緒和工作負余。以下有幾點建議：
- 組織立項會議時，邀請相關利益方加入，特別是技術團隊的老大和產品團隊的老大，以及雙方的老大大，讓其明確授權，包括調配資源、管理團隊、進度匯報收集的權利。如果老大無暇參加此會議，則需要書面聲明或者郵件周知相關人員，由誰負責或擔任此類工作。不要看似簡單，其實在很多流程不夠規范的公司內，職權是界定不清的，導致相關人員不同程度的甩鍋與拖延無責的心態繼續摸魚，另外，群聊記錄的口頭聲明是不可靠的。
- 項目匯報的管控，時間為一周一次或一周兩次為宜，記錄的內容需包含現階段人員的一周按日程格子記錄的開發進度，以及狀態是否正常、延期、完成率的百分比。如有備注要聲明人員的具體情況，比如請假、臨時任務、其他事項等等，補救措施是調休加班、往后期延或是提前完成不需調補等說明，確保跟上開發計劃。進度每周抄送一次項目組成員，利用大眾的監督施加適當的壓力與責任，而不是產品經理一人對一個技術團隊。
- 明確制度，賞罰分明，一旦計劃確認完畢，執行者在執行過程中除特殊情況，否則不可隨意修改，有明確的賞罰制度，也有一定的獎勵制度，但是獎勵需要公司層面才能決策的，所以不一定都有，所以部門內看能否通過其他途徑給項目成員獎勵。獎金的激勵一定程度上會促進成員的積極性，賞罰能夠規制約束項目成員，否則立不立項、能不能如期完成對成員來說無關痛癢，急的說不定就是產品經理自己。
- 營造參與感與成就感，不管是誰，當做出了一款產品并得到他人的夸贊時，內心的成就感是不言而喻的，是對自己付出的犒勞和自我追求的認同感。所以項目過程中，要確保項目成員能夠從中獲得自己想要的一些東西，經驗也好、金錢也好，贊許或評選鼓勵也好，都是可以促進成員的積極性。很不好的是如果都是產品經理一個人在孤軍作戰，那么項目是真的很難推動，把相關的權益和責任讓不同的人員負責，才是對資源的最好分配。
- 項目計劃分配，不同的項目計劃模板各有不同，細到什么程度因不同公司決定，但是工作任務一定要拆解開來，WBS（工作分解結構）是最常用的一種方式，大化小，小成無。將整體項目劃分為不同的工作包，由長期解構為短期，這倒是挺貼合產品經理日常思考模式的，整體——拆解——分析——執行——完成，WBS能直觀快速的表現出對每個階段的任務點及目標，協助清晰的按照計劃進行，也便于快速查找問題。
- 風險控制，風險一般包括定性風險和定量風險，此部分比較偏知識論，經驗有限的人員常常對風險不能做好全面的預判，高級產品也是因為在項目中不斷的總結，避開了遇到過的坑坑洼洼。所以，在項目結束做好總結中或吸取以往項目的經驗的維度，是風險控制的初級識別的一個重要方式。其次，可通過頭腦風暴，組織項目成員在負責的模塊所會碰到的潛在問題，以及產品經理和其他部門對接時的可能性事件，如流程變更、人員離職、需求變更等等，列出表格，預留解決的時間。定量的話是指風險不確定但可被量化，書本的定義是對每一風險發生的概率及其項目目標產生的影響，以及項目整體風險的范圍進行數值分析。這類分析通過發生概率的大小而有針對性的采取不同的措施進行規避。
- 需求變更，作為需求發起人，又作為項目監控人，這樣的事情簡直讓人左右為難，一邊需要項目如期完成，一邊又需要變更增加開發量。當然，需求不是你想變，想變就能變的，往往因為公司層面的硬性要求、領導緊急下發的必要性需求、驗收時與初期需求不符、影響核心利益的或市場政策的變化，如產品商標變動、個人信息隱私保護法的推出等等不確定因素，導致項目過程中需要及時的做出調整，調轉方向。項目不同進行階段的變更對項目的風險和影響是不一樣的。變動涉及的范圍也是不一樣的，以不涉及流程變動為例的變更：
影響程度：立項前<立項未開發<立項已開發<開發完成<測試<驗收，時間越長，風險成本越大。
- 項目立項后，開始進入開發之初，此時提出變更風險較少，項目計劃可以隨之調整。
- 進入開發階段，技術和產品之間會反復確認需求點，到了相應模塊時，在前后端技術確認好（不可遺漏任何一邊），進行調整，在開發計劃中加入變更事項，重新安排計劃。
- 開發完成或測試階段時，這時候提出變更，技術肯定已經有自己的小脾氣了，本來已經完工，剩下來就是改改bug等驗收了，禿頭的毛終于可以減速了；何耐產品經理又賊兮兮的來了，此時耐心的溝通及表明變更的必要性是非常重要的，我們常用領導來說事，但是假如站在領導的立場，恐怕也會在心里小聲嘀咕‘常常拿我說事，這個人工作能力不怎么樣呀’。所以搬出領導的事情不能過于頻繁，畢竟這也可能是最后一張底牌了，久而久之，領導心里就有了對產品人不滿意的自我暗示，而，暗示是會固化的且不易消除。
所以怎么辦呢？對此不敢說必須有見成效，畢竟項目管理也有百來年的歷史了，專家們都沒琢磨透呢，只能說通過自己的經驗分享一下。
馬斯洛的需求原理越來越多人熟知了，但終歸還是太泛，請大家吃一頓好像也不能彌補對個人情感的需求，且我是做不來的，畢竟與生俱來的冷場王。所以又還是尋找中規中矩的方式推動了，如（客觀地）讓項目相關人明白需求變動的原因及重要性，闡明需求的內容和尋找最小變動的可執行方案，計算出潛在價值或改動可帶來的收益，會議也是必要的，私下通知沒有支撐力。（主觀）讓他們知道產品是站在他們角度去想問題的，一起吐槽吐槽變動的來源但又無可奈何的態度。
需求變動是真的很常見，而產品經理本身就需要過濾需求，把控項目，大的變更也是有可能中斷項目的，所以不能忽視這一點。產品在市場部和項目管理部中間本就是左右為難，除了是個需求傳話筒的工具人，我想，更要在其中發揮自己的主觀能動性，沒有什么產品提出馬上就能做出來的，好的產品值得等待，而項目過程所花費的時間和精力就是我們的等待，但是這個等待值不值得，只有市場才能驗證。
本文由 @漂浮檸檬核 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。