項目管理的作用對象是項目團隊（當然也有項目外部的干係人，本文只針對項目團隊），最好的項目管理應該是讓團隊有清晰統一的目標、親密無間的團隊協作，團隊成員各司其職，在舒適的心理狀態下（良好的人際關係），同仇敵愾，為同一目標不懈努力。這一前提的關鍵是經過不斷探索和磨合，找到適合團隊的項目管理最佳實踐，並雷打不動地執行最佳實踐。由此，團隊將越來越好，越來越親密無間。
項目管理的作用對象是項目團隊（當然也有項目外部的干係人，本文只針對項目團隊），最好的項目管理應該是讓團隊有清晰統一的目標、親密無間的團隊協作，團隊成員各司其職，在舒適的心理狀態下（良好的人際關係），同仇敵愾，為同一目標不懈努力。這一前提的關鍵是經過不斷探索和磨合，找到適合團隊的項目管理最佳實踐，並雷打不動地執行最佳實踐。由此，團隊將越來越好，越來越親密無間。
下面總結梳理一下我自己跟蹤項目的最佳實踐。正是因為這個最佳實踐，讓團隊中的每個人每天在逗逼開心中，完成著幾乎不可能的進度。期望也對大家有幫助：
一、項目立項階段：一致認同的產品定位
雖然此階段還不涉及寫代碼等實現層面的工作，但對產品定位的清晰認識和認同，是幫助團隊成員在後期實現中尋找成就感、理解細節需求的必要條件。
若僅在後期實現時，開發人員才接觸到產品，他們一定會被淹沒在細節需求和如何實現需求中，最後演變成，他們自己不知道自己做的是個神馬東西。如此，成就感何來？當他們理解了產品的定位，一開始就知道大概的業務，對他們後期理解需求，絕對有很大的幫助，且能夠站在技術實現的角度給產品設計提出很好的建議。如此，何樂而不為？
此階段產品人員一般要輸出MRD BRD 競品分析等文檔，但對項目組來說，一份精簡的產品規劃書就夠了。具體有哪些內容，可參考上一篇文章《如何用一份產品規劃書代替BRD、MRD 競品分析？》或下圖：
通過項目組內評審討論，達成共識的產品規劃書，是此階段的最終產物。
二. 項目實施階段有條不紊的迭代步伐
1. 清晰的迭代流程
清晰的迭代流程，標準的迭代週期幫助團隊成員掌握工作的步伐，保證大家在同一頻道上。
每次版本迭代逃不掉的流程有：
（1）如何確定需求範圍？
產品經理根據自己的判斷，以一個月為週期（視情況而定，不同公司、團隊， 長度不同），從backlog中挑出若干個優先級高的需求，形成細化版的版本需求列表。版本需求列表與backlog的區別在於，產品對每個需求的細節邏輯經過了更深入的細化和描述，能夠很清楚地告訴團隊，這個功能是做什麼的，業務邏輯是怎樣的，方便團隊判斷技術難度和研發週期。
（1）如何確定需求範圍？
產品經理根據自己的判斷，以一個月為週期（視情況而定，不同公司、團隊， 長度不同），從backlog中挑出若干個優先級高的需求，形成細化版的版本需求列表。版本需求列表與backlog的區別在於，產品對每個需求的細節邏輯經過了更深入的細化和描述，能夠很清楚地告訴團隊，這個功能是做什麼的，業務邏輯是怎樣的，方便團隊判斷技術難度和研發週期。
產品出具此列表後，召集團隊進行評審。評審過程中，一般會砍掉或替換一些需求。經過評審後，團隊就此次迭代的目標和範圍有了清晰的認識和共識。除非非常極端的情況，達成共識的需求列表不輕易做變更。
（2）如何細化需求？
迭代範圍確定後，進入需求細化、PRD設計階段。
細化需求的步驟是什麼？應該注意的點有哪些？可參考文章《當我們接到一個新需求點時，應遵循的需求分析步驟有哪些？》。不再贅述。
（3）如何管控研發階段？
進入研發階段後，工作的大頭從產品轉向研發。此時管控的對象從自己轉向了別人。最好的管控就是積極參與到他們的工作中。為此，產品應積極參與到研發工作中，主要有兩點：一是，積極幫助研發人員理解需求，有求必應，幫助研發解決一切影響他們工作的外部因素（此時像一個“家庭管家”的角色）；二是，幫助研發人員走查測試功能點，這不僅幫助研發節省時間和精力，也將大部分問題扼殺在搖籃裡，減輕後期測試的風險。
（4）如何管控測試工作？
測試工作有兩部分重要的工作內容：一是編寫測試用例，通常需求確定提交研發後，測試人員開始進行此項工作。此時，產品要積極幫助測試人員理解需求，保證用例的全面準確性。要知道，高質量的測試用例，是高質量測試結果的前提。若迭代時間允許，團隊可就編寫完的測試用例進行評審，評審的過程又是項目組理解需求，發現問題的一次機會。第二項主要的測試工作就是，對版本功能進行測試驗收，並出具測試報告。在研發人員提交測試人員前，產品應先走查主流程是否走通。只有主流程通常後，才可正式提測。
（5）如何組織內部測試？
測試完成後，測試人員出具正式測試報告。產品根據測試報告，判定是否可上線（通常結果都是YES，因為影響上線的大bug應在早期就發現並解決，不可能留到最後才發現）。若需要組織內部測試，則先更新內測環境，並通知安排相關部門進行內測。這一步驟是可選的，如此次迭代屬於技術上的化造，則無需內測。
（6）如何進行上線驗收？
內測結束後，重要的bug修修補補後，即可上線正式部署，部署後產品需第一時間在正式環境走查。此步驟必不可少，產品千萬不可偷懶，認為測試都測過了，不用走查。走查的目的是，避免因部署系統時，參數配置錯誤導致的bug。這些bug在測試時，無法覆蓋。
（7）如何對外發布？
驗收無問題後，功能就算正式上線，要面向用戶使用了。此時需要產品給運營、市場等外部干係人正式發出發佈說明。說明一般交代此次更新的功能是什麼？有什麼注意事項等。
2. 輕巧靈活的站會
同步信息是保證大家齊力同心目標一致的前提。站會無疑是很有效的信息同步方式。
（1）組織者
由產品經理把控和組織
（2）頻率
至少兩天一次。若覺得有必要，如每天都有新功能完成（這可是很重要的節點和信息呢），可一天一次。
（3）長度
時間長度應掌控在十五分鐘以內，最長不要超過20分鐘，否則，就喪失了效率。我一般控制在十分鐘內。
（4）時間
一般為早上上班十五分鐘後或晚上快下班前，不建議選擇一天中的中間時刻。
（5）主題
主題有三個，即昨日進展、今日安排、問題障礙。
- 昨日進展指每個人昨日任務的完成情況，如XX功能已做完；XX功能完成40%等。
- 今日安排指每個人今日要做的任務有哪些？通常是大功能的拆分，由技術負責人進行並分派給各個研發負責。
- 問題障礙指每個人在完成任務時遇到的問題 或項目組遇到的外部影響因素。
這三個主題幫助項目組成員瞭解其他人的工作情況，也幫每個人瞭解項目的狀況。對問題和障礙，若需要群策群力，則大家一起討論解決；若只是小範圍的問題，則進行點對點的溝通解決；若涉及到外部影響因素，則產品要積極進行推進和解決。
（6）決議
有會議就應該有決議。此決議可用於領帶彙報，也可同步到項目組交流群。每次站會開完後，產品話幾分鐘時間輸出總結：
（1）如何確定需求範圍？
產品經理根據自己的判斷，以一個月為週期（視情況而定，不同公司、團隊， 長度不同），從backlog中挑出若干個優先級高的需求，形成細化版的版本需求列表。版本需求列表與backlog的區別在於，產品對每個需求的細節邏輯經過了更深入的細化和描述，能夠很清楚地告訴團隊，這個功能是做什麼的，業務邏輯是怎樣的，方便團隊判斷技術難度和研發週期。
產品出具此列表後，召集團隊進行評審。評審過程中，一般會砍掉或替換一些需求。經過評審後，團隊就此次迭代的目標和範圍有了清晰的認識和共識。除非非常極端的情況，達成共識的需求列表不輕易做變更。
（2）如何細化需求？
迭代範圍確定後，進入需求細化、PRD設計階段。
細化需求的步驟是什麼？應該注意的點有哪些？可參考文章《當我們接到一個新需求點時，應遵循的需求分析步驟有哪些？》。不再贅述。
（3）如何管控研發階段？
進入研發階段後，工作的大頭從產品轉向研發。此時管控的對象從自己轉向了別人。最好的管控就是積極參與到他們的工作中。為此，產品應積極參與到研發工作中，主要有兩點：一是，積極幫助研發人員理解需求，有求必應，幫助研發解決一切影響他們工作的外部因素（此時像一個“家庭管家”的角色）；二是，幫助研發人員走查測試功能點，這不僅幫助研發節省時間和精力，也將大部分問題扼殺在搖籃裡，減輕後期測試的風險。
（4）如何管控測試工作？
測試工作有兩部分重要的工作內容：一是編寫測試用例，通常需求確定提交研發後，測試人員開始進行此項工作。此時，產品要積極幫助測試人員理解需求，保證用例的全面準確性。要知道，高質量的測試用例，是高質量測試結果的前提。若迭代時間允許，團隊可就編寫完的測試用例進行評審，評審的過程又是項目組理解需求，發現問題的一次機會。第二項主要的測試工作就是，對版本功能進行測試驗收，並出具測試報告。在研發人員提交測試人員前，產品應先走查主流程是否走通。只有主流程通常後，才可正式提測。
（5）如何組織內部測試？
測試完成後，測試人員出具正式測試報告。產品根據測試報告，判定是否可上線（通常結果都是YES，因為影響上線的大bug應在早期就發現並解決，不可能留到最後才發現）。若需要組織內部測試，則先更新內測環境，並通知安排相關部門進行內測。這一步驟是可選的，如此次迭代屬於技術上的化造，則無需內測。
（6）如何進行上線驗收？
內測結束後，重要的bug修修補補後，即可上線正式部署，部署後產品需第一時間在正式環境走查。此步驟必不可少，產品千萬不可偷懶，認為測試都測過了，不用走查。走查的目的是，避免因部署系統時，參數配置錯誤導致的bug。這些bug在測試時，無法覆蓋。
（7）如何對外發布？
驗收無問題後，功能就算正式上線，要面向用戶使用了。此時需要產品給運營、市場等外部干係人正式發出發佈說明。說明一般交代此次更新的功能是什麼？有什麼注意事項等。
2. 輕巧靈活的站會
同步信息是保證大家齊力同心目標一致的前提。站會無疑是很有效的信息同步方式。
（1）組織者
由產品經理把控和組織
（2）頻率
至少兩天一次。若覺得有必要，如每天都有新功能完成（這可是很重要的節點和信息呢），可一天一次。
（3）長度
時間長度應掌控在十五分鐘以內，最長不要超過20分鐘，否則，就喪失了效率。我一般控制在十分鐘內。
（4）時間
一般為早上上班十五分鐘後或晚上快下班前，不建議選擇一天中的中間時刻。
（5）主題
主題有三個，即昨日進展、今日安排、問題障礙。
- 昨日進展指每個人昨日任務的完成情況，如XX功能已做完；XX功能完成40%等。
- 今日安排指每個人今日要做的任務有哪些？通常是大功能的拆分，由技術負責人進行並分派給各個研發負責。
- 問題障礙指每個人在完成任務時遇到的問題 或項目組遇到的外部影響因素。
這三個主題幫助項目組成員瞭解其他人的工作情況，也幫每個人瞭解項目的狀況。對問題和障礙，若需要群策群力，則大家一起討論解決；若只是小範圍的問題，則進行點對點的溝通解決；若涉及到外部影響因素，則產品要積極進行推進和解決。
（6）決議
有會議就應該有決議。此決議可用於領帶彙報，也可同步到項目組交流群。每次站會開完後，產品話幾分鐘時間輸出總結：
應注意， 站會不是大家向項目主管彙報工作的形式，而是項目組內相互同步信息的信息交換機制，產品經理作為組織者，要做好氣氛的調節。比如一句逗逼的話語和表情結束會議，也開啟了小夥伴們一天的美好心情。
3. 實時更新的Task Board
任務牆是很常規的任務跟蹤方式。網絡上有很多此方法的解說，每個人在使用中都會創新和尋找適合自己的方式。我的做法是：
- 買一張白板，放在項目組座位範圍內。買一些便利貼用來寫任務。
- 橫軸為任務狀態：todo（已分配在手上，還沒開始著手做的）、doing（正在做的）、testing（已完成可提交測試的）、done（已測試完成可上線的）。縱軸為姓名：開發、產品、前端、UI 等所有項目組成員。
- 每個人每天根據情況更新便利貼內容，並貼在相應的位置。
通常站會和Task Borad結合使用。站會時大家圍著白板討論。
誠然，項目性質和團隊大小等因素不同，流程和操作方式也不盡相同。比如toB項目跟toC項目，迭代流程會有較大差異。
除標準的流程和操作外，在日常的溝通工作中，或許應時刻謹記：
（1）多問觀點背後的原因
當與開發、UI觀點不一致時，先不要判斷誰是誰非。仔細聆聽他人觀點背後的原因、他為什麼覺得應該是這樣？由此，可相互補充，使得方案更加完善。且在溝通的過程中，能夠幫助自己瞭解到開發、設計方面的知識，是很好的補充自己知識盲區的方式。
（2）榮辱與共，相互扶持
應該知道，同一項目組是榮辱與共，不問誰是誰非，只關注團隊共同的成果的。外界對每個人成果的評價，也是建立在團隊成果的基礎上。因此團隊成員之間應該是相互扶持，共同解決項目遇到的任何問題，而不是乾產品的，需求完了就沒自己什麼事了；開發做開發的，做不完是他們的錯。絕不是這樣的。
以達到團隊目標為基準，提高團隊工作效率的方式方法就是最好的管理。營造輕鬆快樂的工作環境，讓團隊在舒適的狀態下高效運轉的方式方法就是最好的管理。
本文由 @小麻雀 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基於 CC0 協議