項目經理和產品經理本是兩個相關卻獨立的崗位，很多人會混淆這兩個崗位的工作內容。而巧的是項目經理的英文縮寫（project manager，PM）和產品經理（product manager，PM）一樣，同為PM，或許就奠定了這兩者之間不可分割的關系。

實際上在很多沒有成規模的互聯網公司中，迫于團隊規模的限制，產品經理往往會承擔一定的（全部）項目管理職能，因此很多產品經理在做好產品管好需求的同時也要同時思考如何管好項目！那么產品經理應該如何做好項目管理呢？下面就“產品經理如何進行項目管理？”給大家帶來一些我的想法和總結。

項目管理是個很大很大的話題，本人斗膽鋪陳了一些粗淺陋見，并不全面，歡迎各位看官多多指教！

一：項目流程

1.開發模式

• 瀑布開發
  瀑布開發是傳統的開發方式，源頭就想好了整個過程，需要輸出大量的文檔，缺點是周期長，速度慢，風險可預見性差，已經被互聯網所淘汰了。

• 迭代開發
  迭代開發就是經典的小步快跑，快速迭代的理論指導，開始的時候可能想得不完成，先做一個MVP模型，然后逐步完善的過程，彌補了瀑布開發的缺點。

• 螺旋式開發
  瀑布開發與迭代開發的的結合開發模式，更加強調風險性。

• 敏捷開發
  簡單地說，敏捷開發是追求快速產出的一種方法，減少中間過程的內容，例如需求文檔。

對比：
瀑布開發、迭代開發、螺旋開發是軟件開發周期的模型，區分標準是過程的復雜度和最后產品的完善度。敏捷開發是多種開發方式的集合，它是一種方法，而迭代開發則是一種開發模型。

這里著重強調一下敏捷開發的核心概念：以最簡單的方式快速達成目標，并在過程中及時響應外界的變化，做出迅速的調整，多次迭代，小步快跑。

敏捷開發適合小團隊和創業團隊，能夠極大的減少時間上的成本。敏捷開發小組主要的工作方式可以歸納為：PM和RD作為一個整體工作； 按短周期迭代工作；每次迭代交付一些成果：關注業務優先級；機動檢查與調整。

詳細介紹點這里===>>軟件項目的開發模式

2.項目流程

啟動期：

• 第一個問題，為什么要立項？

這個時候，作為產品經理的你需要去了解這個項目的來龍去脈，最好的方式是和你的上級或者BOSS溝通，因為他們掌握的信息量遠遠比你大且比你多，所以通過和他們溝通再加上自己理解，就能夠對項目立項的原因有一個清晰的認知。

• 第二個問題，項目目標是什么？

產品經理作為項目的負責人，是一定要明白整個項目的目標是什么，然后在里面找出最核心的目標。例如有的項目是時間（越快越好，花多少錢無所謂），有的項目是錢（做慢點沒關系，但是要花最少的錢）。這些都可以通過跟你的領導聊一聊得出這些信息，知道了項目目標后你需要把這個目標用準確的文字寫下來。

對，一定要寫下來，因為口說無憑，再一個寫下來的東西才能成為所有人具體執行的方向和準則。

• 第三個問題，項目的相關人員都有哪些？

關于干系人，寶潔的方法論是找出PACE。P是Participant（參與者），A是Approver（審批者），C是Consultant（顧問），E是Executor（執行者）。當然，產品經理（尤其是創業公司的產品）在日常的項目工作中，恐怕不會有這么繁瑣的流程，所以，也就遵循一切從簡的原則。

項目相關人員，可以從這幾個角度去考慮下，如哪些人或部門會受到項目結果的影響，哪些人可為項目提供資源（人、財、物）等。當然，在互聯網公司，常見的相關人員也就是老板、產品經理、項目經理、項目團隊（包含設計、開發、測試、運維等）及用戶等。

找到了項目的相關人員后，現在你要做的就是把團隊成員綁到自己的船上。你需要去了解團隊里每個成員的核心KPI，也就是他們于這個項目的需求是什么，做這個項目可以給他們帶來什么。如果這個項目沒被囊括在這個成員的工作評價 list 里面，你需要去找他的老板溝通。根據我的經驗，85%出工不出力的情況都是因為你的項目根本不會對這個成員的KPI有什么正向的幫助。當然，如果找他的老板溝通無效，還有最后一招，感情投資，請那個成員擼串、吃飯，利用感情讓他幫你做好這個項目。

• 第四個問題，怎么立項？

通常來說，這個時候需要開一個項目啟動大會。這個啟動大會的目的是召集項目團隊成員，成員之間初步認識一下，產品經理主持會議，然后清楚地傳達項目要做什么，目標是什么，為什么要做，怎么做，誰來做等等。另外，跟所有的啟動大會一樣，項目的啟動大會，也需要給團隊成員來點雞湯、打點雞血。產品經理需要去統一團隊的思想，明確團隊的管理和運作方式，以及團隊的溝通機制等，產品經理需要動員團隊成員積極參與項目，并高質量地完成項目。

規劃期：

• 1.需求收集和需求清單
  這個時候，項目相關的文檔其實應該已經完成了，因為只有當詳細的產品需求文檔有了之后，開發團隊才能估算項目時間及里程碑等。明確的產品需求和詳細的需求文檔，都是項目得以順利進行的基本前提保障，所以，產品經理的規劃能力、撰寫文檔的能力在這個時候就顯得尤為重要了。

• 2.項目分解，工時預估
  拿到一個項目首先應該做的事就是將項目分解，并落實到每個人。這算是項目經理最核心的一項工作之一！
  一個完整的項目可以分為產品經理整理需求和畫原型，設計師畫視覺草圖，前端工程師的頁面重構和動效制作，后端工程師完成數據接口的開發和一些功能的實現。而項目經理應該做的，就是評估各部分需要的工時，并作出項目進度計劃。

• 3.利用工具對項目排期
  

  排期是項目經理的一項基本能力，根據項目的大小，要用到很多種工具，但應用最多的無疑就是甘特圖。
  甘特圖就是以圖示的方法將項目各部分，持續時間和時間節點形象清晰地表示出來的一種圖表。通過甘特圖，項目經理可以直觀的知道項目是否按照計劃進行或是在哪一部分出了問題。
  

  而畫甘特圖的工具很多，Microsoft project、viscro、xmind都可以畫，但我比較傾向使用ppt和excel畫，一是使用方便，也很直觀；二是大部分同事都有這兩個軟件。
  當然這個階段還涉及到成本的估算、質量管理規劃、人力資源規劃、風險管理等問題，由于涉及到的知識更加的專業，這里就不再贅述了（其實是我不太懂）！

執行期&監控期：

執行期&監控期都處在項目具體實施的階段，這里我就將二者合并來說。

任務清單和項目周報是項目實施階段質量監督和進度監督的重要工具。

任務清單列表：是一組當前迭代選出的任務代辦事項列表，該列表由項目組成員維護，并交由測試人員監控。
項目組成員根據迭代計劃對需求進行分解，將需求分解為一個個可以獨立部署的任務計劃，測試團隊根據項目組成員給出的任務清單跟蹤任務完成情況并督促開發人員提測，做到持續集成。項目組成員確保把最優資源投入到高優先級需求上。
任務分解（WBS）：作為產品經理代理項目經理，很難做好任務分解和進度評估工作，需要產品經理有一定的技術功底，能夠大概知道背后的實現邏輯如何；另外你還必須充分信任開發團隊，信任他們所給出的時間節點。

項目周報：是對一周項目迭代的情況匯報以及下周項目組的工作計劃，另外對于項目管理過程中出現的一些問題，例如流程上的漏洞、資源的欠缺都要及時向上反饋，以便獲得領導的支援，切忌報喜不報憂。

收尾期：

此階段的工作就是測試和上線&部署、迭代總結；

• 上線
  上線是項目開發的最后一環，這之前要經歷測試（單元、黑白盒、性能）、驗收環節；APP類產品還要涉及到上線應用商店的審核準備工作，以及上線后的緊急Bug修復以及運維工作！每個公司都有自己的一套標準的上線流程，盡可按照既定的流程推進上線即可，但做到這里需要提醒一點，一定要做好工程的備份和版本管理工作，便于后期的Bug修改和需求更新工作！

• 迭代總結
  

  在每個迭代結束后，整個團隊要聚在一起召開迭代回顧會議，識別出哪些做得好，哪些做得不好，所有人都必須發言。迭代回顧會議的目的是為了找出潛在的改進事項，為將來的改進制定計劃。迭代總結是在整個項目管理過程中，比較重要的一個環節。迭代總結的重要性在于，它能如實的反映項目迭代過程中存在的一些問題，并根據這些問題進行跟蹤改進。

3.關鍵活動

• 立項會
  內容：明確戰略目標和核心價值
  目標：確定項目的可行性和價值
  輸出：立項書
• 需求評審
  內容：通過評審委員會篩選收集到的需求，分析需求、對需求歸類、確定需求的優先級。
  目標：確定產品需求池
  輸出：需求清單
• 可行性評審
  內容：評審小組對初步的產品方案進行可行性評審，主要由技術團隊發現其中可能存在的問題，給出建議。產品經理根據評審小組給出的建議優化產品方案，確保進入迭代階段時應該為當時最優的產品方案。
  目標：保證產品方案的可行性
  輸出：產品原型和PRD
• 進度評審
  內容：每個迭代以進度評審會作為開始，項目組成員從需求清單中挑選出高優先級需求并配合產品目標組成當前迭代的計劃。項目組成員對需求進行拆解，形成一個個可獨立部署的任務，并對工作量進行評估，若超出迭代周期則需要壓縮工作量或移出需求。
  目標：評估工作量的粒度
  輸出：任務清單
• 每日立會
  內容：每日站立會議在同樣的時間和同樣的地點召開，會議準時開始。每日站立會議不得超過15分鐘，每一個開發團隊的成員都必須發言，會議中不進行討論，發言內容需提供以下信息：昨天完成了什么？今天即將做什么？遇到了什么困難？
  目標：幫助團隊快速發現問題
  輸出：日會記錄
• 測試用例評審
  內容：產品經理或QA經理主持會議，對測試用例清單進行評估和分析
  目標：確認測試用例的有效性和全面性
  輸出：測試用例清單（User Case List）
• 迭代總結會
  內容：迭代總結是在整個項目管理過程中，比較重要的一個環節。迭代總結的重要性在于，它能如實的反映項目迭代過程中存在的一些問題，并根據這些問題進行跟蹤改進。
  目標：總結項目經驗和教訓
  輸出：迭代總結會議紀要

二：團隊管理

1.角色

• 評審委員會
  評審小組是由開發團隊leader組成的團體，評審小組從系統實現的角度評估需求的合理性、可行性，對產品的設計提出建設性意見。

評審小組的職責義務：
1.協助產品經理評審方案的可行性，找出產品方案可能存在的問題
2.協助產品經理評估方案預期的工時，讓產品經理心中有數
3.協助產品經理分析方案對其他模塊的影響，做好跨產品線協作

• 產品經理：
  產品經理作為產品的第一責任人，負責帶領團隊做出有價值的產品。

產品經理的責任和義務：
1.清晰地表達產品的需求清單（需求記錄清晰，沒有歧義）
2.對產品需求清單的條目進行歸納（同類需求合并，大需求拆分，前置需求后置需求歸類）
3.確保開發團隊所執行工作的價值（解決用戶的實際問題）
4.確保需求清單對所有人可見、透明、清晰，并指示團隊的下一步工作（需求清單公開）
5.確保開發團隊對產品需求清單中的條目達到一定程度的理解

• 項目經理：
  項目經理是項目進度、項目質量的監督者，負責團隊的進度跟蹤和質量把控，在敏捷迭代的模式中，項目經理是一個服務式的領導。

項目經理服務于產品經理：
1.清晰地和開發團隊溝通愿景、目標和需求清單
2.找到有效管理需求清單的技巧
3.理解長期的產品規劃
項目經理服務于團隊：
1.指導開發團隊自組織完成產品迭代
2.領導開發團隊創造高價值的產品
3.幫助開發團隊移除進展過程中的障礙
4.協助開發團隊進行需求分解

項目組成員：
項目組成員作為需求的實現者，按照迭代計劃完成產品需求，交付高質量的產品包。只有開發團隊的成員才能創造產品的增量（產品增量通常指一次迭代交付的可用的軟件包）。通常項目組成員包括：前端開發、后端開發、UX、QA、運營等人員。

2.人員管理

人員管理涉及到：人力資源規劃、項目成員的培訓、溝通機制的建立和維護等工作，尤其是人力資源這塊的工作是非常專業化的，我就不誤人子弟了。這里我著重的講講溝通機制和人員管理原則！

• 互相尊重
  在項目管理過程中，你可能會遇到在項目進行到某一階段，遇到了突發情況，項目無法正常進行下去。此時，某些項目管理者可能會使用自己的職能，直接提出解決方案，讓項目成員執行。敏捷迭代的方法論中有說，團隊要自組織，要尊重團隊每個人員的專業能力。項目經理代表的不是他的專業能力，而是代表他所管理的這個群體的整體利益，這種情況你唯一要做的事情，就是幫他排除障礙，如果他需要討論，你就幫助他召集相關人員討論；如果他需要查閱資料，你就幫他準備好相關的材料。當你尊重了別人的能力，你也會收獲更多的尊重和領導力。
• 開放交流
  做項目管理，除了需要管理項目迭代，還需要管理人。員工處于什么狀態，你心理是否有數，那個誰誰誰最新為什么情緒這么低落，那個誰誰誰最近為什么這么消極，那個誰誰誰最近表現還可以，那個誰誰誰最近實現的需求老是出嚴重bug是不是遇到了什么事情。有些事情需要項目經理主動去了解，而不是聽取他人的評論，多溝通，多交流，是做項目管理另外一件重要事情。不良的風氣很容易影響團隊的價值傾向，我曾經在一家公司工作時，離職的時候，整個團隊幾乎全部解散，就是因為消極的團隊氛圍導致。
• 幫助團隊成員成長
  最后這一點，是我做項目管理以來，感觸最深的，也是我學習到的最寶貴的經驗。我所代表的是團隊整體的利益，對外我是項目組的產品/項目經理，別人認可你是因為你的團隊是執行力最強的團隊，而別人的對你的認可來自于團隊成員每一個人的付出，你無法居功自傲的說是因為你自己很牛逼。
  為幫助團隊成員成長，你需要做的事情是：把成員付出的努力及時的讓上級知曉，做到這一點并不難，只需要在周報中，時不時的告知上級，誰誰誰在這次迭代中，花了多少心思，為項目付出了多大努力，為其爭取盡可能的福利。另外，鼓勵成員互相分享心得，把自己的經驗與他人共享，共同成長。最后，當團隊遇到問題時，你要作為第一責任人主動思考原因，而不是直接責問他人為什么沒有把事做好。除了這些，幫團隊爭取福利，組織好的拓展活動，加強團隊成員之間的凝聚力，這些都是作為項目經理力所能及的。

3.資源

了解公司對項目的總體投入情況，在戰略預算框架內為項目團隊爭取最大化的資源和利益！
總結下來就是三件事：要錢！要人！要時間！

三：工具

1.文檔

• 立項報告：
  立項報告，是在某一項目早期，當項目條件還不夠成熟，對項目的具體建設方案還不夠明晰，且僅具有規劃意見書的時候，對擬建項目提出的框架性的總體設想。立項報告主要從宏觀上論述項目設立的必要性和可能性，把項目投資的設想變為概略的投資建議，立項書的呈報可以供項目審批方做出初步決策。

主要包含內容：項目簡介；團隊簡介；市場分析；痛點分析；解決方案；商業模式；競品分析......

需求清單在其他的一些互聯網產品團隊中，也被稱為需求池，顧名思義需求清單是一個用來記錄各渠道來源的需求、所涉及的產品、需求的優先級、需求狀態以及發布時間的一個清單。

需求清單中有幾項是需要特別注意的：
描述：描述是用來記錄需求的詳細信息，描述中的語言一定不能產生歧義，否則會給開發團隊帶來困擾。
優先級：優先級決定了需求調研的先后順序、需求開發的先后順序，我們采用四象限的方式來定義需求的優先級。
狀態：狀態標記了需求目前所處的情況，需求清單應該是一個公開的清單，任何人都可以查看清單的信息，因此狀態一定要跟實際情況一致，及時反映需求的進展。
提出人：提出人信息是為了方便對需求進行追溯，由誰提出的需求，后續關于該需求的變更都要及時告知提出者。

• 任務清單：

  任務清單列表是一組當前迭代選出的任務代辦事項列表，該列表由項目組成員維護，并交由測試人員監控。
  項目組成員根據迭代計劃對需求進行分解，將需求分解為一個個可以獨立部署的任務計劃，測試團隊根據項目組成員給出的任務清單跟蹤任務完成情況并督促開發人員提測，做到持續集成。項目組成員確保把最優資源投入到高優先級需求上。

• 排期表：

  對項目團隊的任務進行時間上規劃和安排，根據項目團隊的大小，排期表有不同的詳細程度，通過多層級的分配將時間安排到每一個人。排期表切記要有據可循并且時間安排條理清晰。在排期表編制完成后，要和團隊所有人共享，讓每個人都清晰的知道自己的工作安排和時間節點。
  排期表的形式并不固定，你可以使用Excel甘特圖、時間看板、管理軟件等工具，做到：工作量估算有據、時間節點控制精確、里程碑明確即可！

• 項目報告：

  項目報告是對一段時間內（周or月）項目迭代的情況匯報以及下一階段項目組的工作計劃，另外對于項目管理過程中出現的一些問題，例如流程上的漏洞、資源的欠缺都要及時向上反饋，以便獲得領導的支援，切忌報喜不報憂。

• 迭代總結報告：

  迭代總結是在整個項目管理過程中，比較重要的一個環節。迭代總結的重要性在于，它能如實的反映項目迭代過程中存在的一些問題，并根據這些問題進行跟蹤改進。
  記錄問題只是其中的一部分，重要的是作為項目經理的你有沒有事后去推動改良這些事情，不然迭代總結只是一個形式主義。

2.工具

• 管理工具：
  小型項目
  Leangoo
  

  
  Worktile
  
  
  大型項目
  禪道
  
  
  JIRA
  
  
  Ms Project

• 協同工具：
  有道云
  

  
  印象筆記
  

• 時間日程管理：
  滴答清單
  

  
  365日歷
  

以上是我理解的項目管理的一些簡略內容，著重寫了和產品經理相關的一些項目管理的知識，雖然內容很長，但請大家記住項目管理無非就是圍繞著：“時間”、“成本”、“質量”這3點做文章！大家抓住核心，多多實踐，都會取得不錯的項目管理效果！希望本文對各位小伙伴在項目管理方面有一定的幫助！也請各位多多提寶貴意見！

思維導圖：點這里

文 |TurboLee
進擊的產品經理一枚
部分圖片&文字參考援引于網絡，如有侵權請知會本人刪除