項目管理的作用對象是項目團隊（當然也有項目外部的干系人，本文只針對項目團隊），最好的項目管理應該是讓團隊有清晰統(tǒng)一的目標、親密無間的團隊協(xié)作，團隊成員各司其職，在舒適的心理狀態(tài)下（良好的人際關(guān)系），同仇敵愾，為同一目標不懈努力。這一前提的關(guān)鍵是經(jīng)過不斷探索和磨合，找到適合團隊的項目管理最佳實踐，并雷打不動地執(zhí)行最佳實踐。由此，團隊將越來越好，越來越親密無間。

下面總結(jié)梳理一下我自己跟蹤項目的最佳實踐。正是因為這個最佳實踐，讓團隊中的每個人每天在逗逼開心中，完成著幾乎不可能的進度。期望也對大家有幫助：

一、項目立項階段：一致認同的產(chǎn)品定位

雖然此階段還不涉及寫代碼等實現(xiàn)層面的工作，但對產(chǎn)品定位的清晰認識和認同，是幫助團隊成員在后期實現(xiàn)中尋找成就感、理解細節(jié)需求的必要條件。

若僅在后期實現(xiàn)時，開發(fā)人員才接觸到產(chǎn)品，他們一定會被淹沒在細節(jié)需求和如何實現(xiàn)需求中，最后演變成，他們自己不知道自己做的是個神馬東西。如此，成就感何來？當他們理解了產(chǎn)品的定位，一開始就知道大概的業(yè)務，對他們后期理解需求，絕對有很大的幫助，且能夠站在技術(shù)實現(xiàn)的角度給產(chǎn)品設計提出很好的建議。如此，何樂而不為？

此階段產(chǎn)品人員一般要輸出MRD? BRD 競品分析等文檔，但對項目組來說，一份精簡的產(chǎn)品規(guī)劃書就夠了。具體有哪些內(nèi)容，可參考上一篇文章《如何用一份產(chǎn)品規(guī)劃書代替BRD、MRD 競品分析？》或下圖：

通過項目組內(nèi)評審討論，達成共識的產(chǎn)品規(guī)劃書，是此階段的最終產(chǎn)物。

二. 項目實施階段：有條不紊的迭代步伐

1. 清晰的迭代流程

清晰的迭代流程，標準的迭代周期幫助團隊成員掌握工作的步伐，保證大家在同一頻道上。

每次版本迭代逃不掉的流程有：

每一階段都有特定的參與人和輸出產(chǎn)物：

（1）如何進行版本規(guī)劃以確定需求范圍？

產(chǎn)品經(jīng)理根據(jù)自己的判斷，以一個月為周期（視情況而定，不同公司、團隊， 長度不同），從backlog中挑出若干個優(yōu)先級高的需求，形成細化版的版本需求列表。版本需求列表與backlog的區(qū)別在于，產(chǎn)品對每個需求的細節(jié)邏輯經(jīng)過了更深入的細化和描述，能夠很清楚地告訴團隊，這個功能是做什么的，業(yè)務邏輯是怎樣的，方便團隊判斷技術(shù)難度和研發(fā)周期。

產(chǎn)品出具此列表后，召集團隊進行評審。評審過程中，一般會砍掉或替換一些需求。經(jīng)過評審后，團隊就此次迭代的目標和范圍有了清晰的認識和共識。除非非常極端的情況，達成共識的需求列表不輕易做變更。

（2）如何細化需求？

迭代范圍確定后，進入需求細化、PRD設計階段。

細化需求的步驟是什么？應該注意的點有哪些？可參考文章《當我們接到一個新需求點時，應遵循的需求分析步驟有哪些？》。不再贅述。

（3）如何管控研發(fā)階段？

進入研發(fā)階段后，工作的大頭從產(chǎn)品轉(zhuǎn)向研發(fā)。此時管控的對象從自己轉(zhuǎn)向了別人。最好的管控就是積極參與到他們的工作中。為此，產(chǎn)品應積極參與到研發(fā)工作中，主要有兩點：一是，積極幫助研發(fā)人員理解需求，有求必應，幫助研發(fā)解決一切影響他們工作的外部因素（此時像一個“家庭管家”的角色）；二是，幫助研發(fā)人員走查測試功能點，這不僅幫助研發(fā)節(jié)省時間和精力，也將大部分問題扼殺在搖籃里，減輕后期測試的風險。

（4）如何管控測試工作？

測試工作有兩部分重要的工作內(nèi)容：一是編寫測試用例，通常需求確定提交研發(fā)后，測試人員開始進行此項工作。此時，產(chǎn)品要積極幫助測試人員理解需求，保證用例的全面準確性。要知道，高質(zhì)量的測試用例，是高質(zhì)量測試結(jié)果的前提。若迭代時間允許，團隊可就編寫完的測試用例進行評審，評審的過程又是項目組理解需求，發(fā)現(xiàn)問題的一次機會。第二項主要的測試工作就是，對版本功能進行測試驗收，并出具測試報告。在研發(fā)人員提交測試人員前，產(chǎn)品應先走查主流程是否走通。只有主流程通常后，才可正式提測。

（5）如何組織內(nèi)部測試？

測試完成后，測試人員出具正式測試報告。產(chǎn)品根據(jù)測試報告，判定是否可上線（通常結(jié)果都是YES，因為影響上線的大bug應在早期就發(fā)現(xiàn)并解決，不可能留到最后才發(fā)現(xiàn)）。若需要組織內(nèi)部測試，則先更新內(nèi)測環(huán)境，并通知安排相關(guān)部門進行內(nèi)測。這一步驟是可選的，如此次迭代屬于技術(shù)上的化造，則無需內(nèi)測。

（6）如何進行上線驗收？

內(nèi)測結(jié)束后，重要的bug修修補補后，即可上線正式部署，部署后產(chǎn)品需第一時間在正式環(huán)境走查。此步驟必不可少，產(chǎn)品千萬不可偷懶，認為測試都測過了，不用走查。走查的目的是，避免因部署系統(tǒng)時，參數(shù)配置錯誤導致的bug。這些bug在測試時，無法覆蓋。

（7）如何對外發(fā)布？

驗收無問題后，功能就算正式上線，要面向用戶使用了。此時需要產(chǎn)品給運營、市場等外部干系人正式發(fā)出發(fā)布說明。說明一般交代此次更新的功能是什么？有什么注意事項等。

2. 輕巧靈活的站會

同步信息是保證大家齊力同心目標一致的前提。站會無疑是很有效的信息同步方式。

（1）組織者

由產(chǎn)品經(jīng)理把控和組織

（2）頻率

至少兩天一次。若覺得有必要，如每天都有新功能完成（這可是很重要的節(jié)點和信息呢），可一天一次。

（3）長度

時間長度應掌控在十五分鐘以內(nèi)，最長不要超過20分鐘，否則，就喪失了效率。我一般控制在十分鐘內(nèi)。

（4）時間

一般為早上上班十五分鐘后或晚上快下班前，不建議選擇一天中的中間時刻。

（5）主題

主題有三個，即昨日進展、今日安排、問題障礙。

• 昨日進展指每個人昨日任務的完成情況，如XX功能已做完；XX功能完成40%等。
• 今日安排指每個人今日要做的任務有哪些？通常是大功能的拆分，由技術(shù)負責人進行并分派給各個研發(fā)負責。
• 問題障礙指每個人在完成任務時遇到的問題 或項目組遇到的外部影響因素。

這三個主題幫助項目組成員了解其他人的工作情況，也幫每個人了解項目的狀況。對問題和障礙，若需要群策群力，則大家一起討論解決；若只是小范圍的問題，則進行點對點的溝通解決；若涉及到外部影響因素，則產(chǎn)品要積極進行推進和解決。

（6）決議

有會議就應該有決議。此決議可用于領(lǐng)帶匯報，也可同步到項目組交流群。每次站會開完后，產(chǎn)品話幾分鐘時間輸出總結(jié)：

應注意， 站會不是大家向項目主管匯報工作的形式，而是項目組內(nèi)相互同步信息的信息交換機制，產(chǎn)品經(jīng)理作為組織者，要做好氣氛的調(diào)節(jié)。比如一句逗逼的話語和表情結(jié)束會議，也開啟了小伙伴們一天的美好心情。

3. 實時更新的Task Board

任務墻是很常規(guī)的任務跟蹤方式。網(wǎng)絡上有很多此方法的解說，每個人在使用中都會創(chuàng)新和尋找適合自己的方式。我的做法是：

• 買一張白板，放在項目組座位范圍內(nèi)。買一些便利貼用來寫任務。
• 橫軸為任務狀態(tài)：todo（已分配在手上，還沒開始著手做的）、doing（正在做的）、testing（已完成可提交測試的）、done（已測試完成可上線的）?？v軸為姓名：開發(fā)、產(chǎn)品、前端、UI 等所有項目組成員。
• 每個人每天根據(jù)情況更新便利貼內(nèi)容，并貼在相應的位置。

通常站會和Task Borad結(jié)合使用。站會時大家圍著白板討論。

誠然，項目性質(zhì)和團隊大小等因素不同，流程和操作方式也不盡相同。比如toB項目跟toC項目，迭代流程會有較大差異。

除標準的流程和操作外，在日常的溝通工作中，或許應時刻謹記：

（1）多問觀點背后的原因

當與開發(fā)、UI觀點不一致時，先不要判斷誰是誰非。仔細聆聽他人觀點背后的原因、他為什么覺得應該是這樣？由此，可相互補充，使得方案更加完善。且在溝通的過程中，能夠幫助自己了解到開發(fā)、設計方面的知識，是很好的補充自己知識盲區(qū)的方式。

（2）榮辱與共，相互扶持

應該知道，同一項目組是榮辱與共，不問誰是誰非，只關(guān)注團隊共同的成果的。外界對每個人成果的評價，也是建立在團隊成果的基礎上。因此團隊成員之間應該是相互扶持，共同解決項目遇到的任何問題，而不是干產(chǎn)品的，需求完了就沒自己什么事了；開發(fā)做開發(fā)的，做不完是他們的錯。絕不是這樣的。

以達到團隊目標為基準，提高團隊工作效率的方式方法就是最好的管理。營造輕松快樂的工作環(huán)境，讓團隊在舒適的狀態(tài)下高效運轉(zhuǎn)的方式方法就是最好的管理。

本文由 @小麻雀?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Pexels，基于 CC0 協(xié)議