產品通過定時迭代版本來新增和優化功能，一個產品、版本或功能都是一個個內部項目，如何在一個確定的有限的時間段內，準時高效地交付高質量產品，就顯得格外重要。大部分的公司沒有內部項目經理，產品經理算是研發團隊中最懂管理的人，並且是產品 owner，所以責無旁貸的需要負責內部項目管理的職責。
如果一個產品經理沒有項目管理的經驗、也沒有系統性學習過項目管理的知識，那麼內部項目可能面臨很大的失敗風險。下面總結了幾點項目管教心得！！！
避免定位不清晰，目標不統一
項目開始時基礎共識沒有達成，定位模糊不清；之後的設計、開發因此頻繁改動變化；再加上所有人對準出標準目標要求不統一，這些不確定性足夠讓項目失敗。開始一個新的版本迭代，或開發一個新功能，需要在項目開啓的時就確定以下問題：
- 功能價值：實現該功能改變了什麼現狀，解決了什麼問題，能夠帶來什麼價值。如果無法回答或不清晰，那麼需要從新調研，甚至停止項目，因爲不清楚價值，等於做了沒有回報。
- 功能定位：你做的一個什麼樣功能，比如基礎功能， 魅力功能等。
- 功能目標：項目結束後，實現哪些功能，這些功能的標準是什麼。
- 開發信息：該功能在哪個版本開發（當一個產品有多個版本時），該功能是內置還是插件等信息。
- 項目時間：項目時間需要謹慎計算的，避免拍大腿決定。因爲時間節點無達給出標準交付物，在某種意義上項目是失敗的。時間需要相關人員進行評估，以及留出足夠的緩衝時間。
- 項目成員：項目成員一定要確定，且得到相關人的知曉，因爲可以避免後期成員會流動變化，比如成員被拉去臨時項目。
- 項目負責人：確定項目負責人是誰，避免因角色不清晰，導致項目無人負責。或者說確定產品經理是不是項目的負責人。
當上述信息清晰確定後，就可以 Kickoff 了，將上述信息傳達給相關人員，作爲項目負責人一定要主動、頻繁、大範圍的傳播，讓每個人都瞭解，儘量降低項目的不確定性。
分期完成，避免停滯
產品經理喜歡在一個版本將功能做的盡善盡美，做出讓人眼前一亮的功能。但大部分是大招沒有憋出，反倒項目延期。產品經理需要遵循 MVP 原則，在項目的定位和目標的基礎上，整合現有資源，將最大的價值打包交付，得到項目回報。所以在做需求時候，可以將需求分類分級，儘量在第一期實現基本型需求，而不要在魅力型需求停滯不前。否則項目結束了，卻什麼成果也沒有。
避免成員變動
一個項目的成員不足，加班加點還是可以準時完成。但是如果一個項目成員頻繁變動，那麼這個項目失敗的可能性就很大，主要是兩方面原因：一是重複對接和溝通，需要告知新成員的工作內容及各種工作交接；第二是新成員不適合當前空缺或做不必要工作，比如整體代碼架構不熟悉，甚至需要修復上一位遺留的 BUG。
項目計劃及節點交付物
工作任務的評估難以量化，所以大部分項目成員都不仔細評估工作量，認爲評估有什麼用，只要準時完成就可以，最後完成不了又說時間不足。
項目前期需要認真評估各階段所需的時間，並在總評估時長上留出 10% 緩衝時間，再作出詳細的項目計劃。比如我們經常會低估需求和設計工作量，但是一個正確的研發週期，需求設計和技術設計時間要佔整個項目時長的 30% ，如果低於這個時間，那麼前期設計工作做的肯定不充分，後期很有可能會頻繁修改設計、接口等。
一個項目計劃時間少則兩週、多則幾個月，所以不能最後統一交付，因爲最後的交付的可能是一坨💩，甚至連屎都交付不出來。所以需要指定項目時間節點，並制定每個節點的交付物，比如使用 TR1-TR7 的研發流程：
- 需求：產品經理進行用戶調研、競品分析，輸出需求列表，並讓相關人員進行評估，確定項目內完成的需求。
- 計劃：需求可行性分析、人員安排、時間安排、形成任務書。
- 系統設計：PRD、技術詳細設計（API 、架構圖）。
- 研發：初版本的軟件和交付文檔，研發儘量分多個階段進行驗收，比如幾個子功能一個 RC 版本。
- 測試與版本迭代：測試進行功能測試，研發進行迭代開發。
- 封板驗證：測試進行迴歸測試，重要問題需進行評估是否修復。
- 發佈：正式版本軟件和發佈相關文檔。
項目負責人需要每週對這些時間節點的交付物進行進度跟蹤和更新，如果發現某個節點出現延期、或交付物質量不符，應該及時找人協助，也要對項目時間進行調整。
直面困難，拋出問題
項目中會遇到很多問題，不要裝作看不見問題，也不要想着只憑借自己一己之力解決問題。項目是一個團隊合作的結果，我們需要直面困難，專心去學習解決問題，如果項目成員無法解決，需要及時對外拋出問題，找更有能力的人解決，至少讓相關人員知道目前的問題，而不是項目成員默默等待。問題和困難不會因爲時間而消失，最終還是需要解決，及時拋出和專心解決纔是王道。
評審和質量把控
設計被修改是正常的事情，比如交互、樣式，或者部分 API。但如果按照設計稿一比一開發，但在功能開發完成後，說設計不對，需要修改。那麼各個評審會的時候幹嘛呢？我認爲主要以下原因導致評審會沒有提出問題：
- 設計稿沒有分享傳播，可能是忘記、也可能是怕他人提出問題，僅在評審會過了一遍。評審會人員在簡短的時間內只會查看主流程是否可行，不會對細節進行深究，所以不會提出更細節的問題。
- 設計稿和真正使用體驗不同，有的問題只有在真正使用後纔會發現問題，儘量做到高保真且具備交互的設計
- 交付物的輸出標準不同，可能評審人員認爲可通過，但是以老闆的標準，可能就會被駁回。
- 產品對問題沒有考慮完善，害怕頻繁修改設計稿被開發懟，忍受了一些已知的問題，但在最後交付時被全部暴露。
從需求——設計——開發整個過程，一定要正式認真開好每一個評審會。評審會的資料需要準備充分，考慮詳細；在開會之前將資源進行分享，提前找相關人員 review，更要多找老闆、或經驗更豐富的同事把關；最後就是發現問題及時修改，不要敷衍過去。評審會過完，一定要確保所有問題都解決了，且通知到相關人員。
項目負責人、產品經理、開發人員在一定程度上會有知識盲區，會忽略一些問題。所以項目需要更多經驗豐富的人員來把控產品質量，比如高級研發工程師或架構師把控架構、組件、API、高可用等問題；設計師把控界面樣式、交互邏輯。如果考慮不周，輕度影響後期拼命修改設計，驗證可行性，改架構；更嚴重的是這些問題在測試發佈時都沒有顯露，在客戶環境發現問題，出現事故。
準時驗收
項目應該遵循各時間節點的交付物，準時進行驗收。驗收發現問題時，重新評估問題風險是否影響項目整體進度，如果有影響，需及時反饋和調整。永遠不要在項目結束對外解釋因爲未知問題導致延期。比如某子功能完成後，產品經理需對功能進行驗收，設計師需對界面佈局樣式和設計稿進行對比，測試進行功能測試。一定要避免所有問題在最後發現， 在最後提出。
後記
某個項目是在測試階段發現很多問題，導致項目成員加班一週才解決，搞得大家身心疲憊。不只是加班累，更重要成員失去信心，對自己的付出產生了懷疑，一個好的產品怎麼會後期大量修改呢？
另外一個項目是因爲項目定位、目標不明確，又遇到無法解決的問題，結果在項目後期才暴露出來，導致項目長時間延誤。
對於一個沒有內部項目經理的公司，產品經理或者技術人員作爲項目負責人時，真的太難了，因爲他們不具備專業的項目管理知識，更沒有評估項目風的經驗，所以項目很容易失敗。
總結： 平時需要多讀專業書籍。