懂技術，也要懂管理。

我把管理技能分為兩類，分別為專案管理和團隊管理，這篇文章教你如何做好專案管理。

在講述這篇文章前，先簡單介紹一下我的管理經驗：之前在百度呆了3年半，系統學習了百度的專案管理流程，19年來到小米後，帶領ShareSave團隊做了1年專案管理和團隊管理工作，之後帶領海外商城基礎服務後端團隊，做了1年團隊管理工作。

縱觀我帶過的專案，在保證專案質量的同時，少有延期的情況，主要還是源於自己的一套專案管理經驗，下面我以ShareSave為例，將這套經驗分享給大家。

備註：本人沒有考過PMP證書，也沒有經過系統的專案管理培訓，文章內容全憑經驗之談，如有偏頗，歡迎指出，定會改進！

專案流程

我把專案管理分為4個階段，分別為需求階段、研發階段、測試階段和上線階段。

專案管理過程中，需要藉助專案管理工具，我們以TB（Teambition）為例。

產品規劃

為什麼我需要將“產品規劃”單獨列出來，因為這個真的太重要了，產品規劃就像是海上的燈塔，指引你前進的方向。

有了產品規劃，產品可以將需求提前放入需求池，每個迭代只做高優需求。

下面是產品規劃要求：

需求評審

需求評審階段，一定是需要產品給出完整的需求文件，如果有UI互動的地方，需要提前給出原型圖，拒絕沒有原型圖的需求評審。

需求一定是要非常明確，最好是能細化到具體的功能點，拒絕模糊需求（比如一句話需求）。

下面是需求評審要求：

為了提高需求評審的效率，我們在需求評審前，需要做很多準備工作，比如需求前期溝通、研發初步評估，前期工作準備到位後，需求評審期間就可以主要討論問題，避免一個需求反覆溝通的情況。

下面是需求階段流程（有些環節可以刪掉，僅供參考）：

研發階段

技術方案是整個專案的靈魂，很多專案到後期出現問題，很大原因就是技術方案沒做好。

專案排期用於控制整體專案的節奏，有以下幾點經驗之談：

1. 專案排期每天不要排滿，建議預留 20% buffer;
2. 如果專案時間緊，可以採用分批提測的方式；
3. 排期要有里程碑，開發、聯調、提測、上線、驗收等；
4. 專案排期不能僅到上線階段，還需包括線上灰度和專案驗收；
5. 前端排期依賴UI設計。

下面是專案排期要求：

下面是研發階段流程（有些環節可以刪掉，僅供參考）：

測試&上線階段

上線方案可以為線上的穩定性保駕護航，重要性不言而喻。 因為上線導致嚴重的線上問題，這個專案可能就白乾了。

關於測試&上線流程，有以下幾點經驗之談：

1. 測試環節需要大家一起過測試Case；
2. 提測前，有的專案還需要做專案演示；
3. 上線前，需要一起過上線方案，突出風險點；
4. 上線後可能需要小流量驗證，或者灰度；
5. 有的專案還有專案驗收環節，最後才全員開放。

下面是測試&上線階段流程（有些環節可以刪掉，僅供參考）：

需求變更

重點說一下需求變更，這也是很多程式設計師頭疼的問題，只要做到正確把控，其實也沒那麼可怕。

下面是需求變更要求：

總結一下：需求變更越早越好，變更需求，需要調整排期，臨近上線，原則上不再允許需求變更，否則需要領導審批。

每日站會

為什麼要提這個呢，因為有的同學平時悶聲不響，最後給你憋大招。所以你需要知道大家每天的工作進度、問題和風險，方便你推動和協調解決，甚至會對專案節奏臨時調整。

站會怎麼開，這個也有講究，10-15分鐘最佳，每位同學都要參與：

1. 昨天做了什麼？
2. 今天打算做什麼？
3. 遇到什麼問題？

備註：站會時間早上或晚上最佳，方式比較靈活，前期可以每週2-3次，後期就每天都開。

總結

總結一下專案管理的幾個重要的點：

1. 產品規劃就像是海上的燈塔，不能亂打一氣；
2. 需求文件一定要儘可能詳細，拒絕無原型的需求評審；
3. 技術方案是整個專案的靈魂，這塊多投入時間絕對不虧；
4. 專案排期有里程碑、有buffer，排期需包括線上灰度和專案驗收時間；
5. Code Review、測試Case都不能少；
6. 上線方案要預知風險，為線上的穩定性保駕護航。

最後希望大家都能成為優秀的專案負責人，這個是ShareSave敏捷開發流程，教你如何用敏捷的方式管理專案，非常值得大家借鑑！