互聯網產品項目管理經驗分享

背景

筆者目前經營着一個開發人員爲主的團隊。成員有產品經理、前端開發、後臺開發、測試、UI設計師等。在實際的項目開發中，一旦項目週期較長，上線時間就很是難以把握，項目輸出的軟件產品質量也很難有所保證。

通過幾回有些失敗的項目開發經歷，我總結了影響項目進度一大緣由：溝通問題。特別是在先後端分離的開發過程當中，更容易出現因開發人員溝通協調不到位而出現問題。

痛定思痛。原先堅決認爲小團隊不須要進行項目管理的筆者，也不得不去思考一些有效的方案來破局。在最近的一次項目中，我在團隊中嘗試了一套比較簡單的項目管理方式，取得了出乎意料的成果，今天在這裏分享給你們。

正文

需求確認

筆者最先在學習軟件工程的時候，就聽過一句話：一切軟件問題，歸根結底都是需求問題。這句話雖然有些誇張，可是需求分析的確是不少團隊的短板。這種狀況也進而造成了如今產品開發圈裏吐槽產品常常改需求的特殊文化。

原先咱們的流程是產品經理作需求分析，製做原型，而後組織全體研發成員進行評審。這樣的流程咱們在前期進行了好久，可是問題有不少，好比：你們在會議上要麼沒法有效提出改進意見；要麼就是提的意見太多，會議沒法正常進行。而且，在團隊人數逐漸增長的過程當中，這種狀況會愈演愈烈。

此外，一個有開發經驗的產品經理可遇不可求。產品經理設計出的原型，每每由於其缺少開發思惟，會出現一些邏輯錯誤。好比一個常見的問題：原型上只考慮了最表層的頁面流程，而這個流程涉及到的後臺流程卻被產品忽略。

針對以上問題，咱們在這個所謂的「產品評審」環節前增長了一個「架構師評審」的環節。由一個資深的開發人員對產品原型先進行評審，這位開發人員須要是擅長後臺開發的技術人員，輔助完善產品設計上的後臺邏輯部分（前端的內容比較形象，產品每每也可以很容易考慮到，固然可以找到前端一塊兒分析最好）。在這個「架構師評審」環節完成以後，再組織全體研發人員進行公審，能夠節約很多時間。

任務拆解

對於一個週期較長的項目來講，若是在開發把全部的功能所有實現以後在再開始進行測試和需求驗證，風險會很大。因此，在開發以前，咱們須要先將一個完整的產品拆分紅相對對立的模塊，每一個模塊須要可以獨立的進行測試（典型的就是可以實現完整的增刪改查功能），最後再將各個模塊組合起來進行完整測試。

這項工做提及來簡單，可是實際操做上並不容易。對於一個較爲複雜的產品來講，各個模塊的耦合度仍是挺高的。因此在進行工做的安排時，完成順序須要進行良好的規劃。好比一個系統在進入測試（這裏指的是有 QA 人員進行的測試）的時候，其最早須要完成的步驟。因此在規劃上，咱們須要把被依賴最多的模塊安排在優先級最高的地方。

因此，作好任務拆解，可以讓測試較早地介入工做。項目經理經過規劃好項目更新的計劃，由開發先完成一個相對完成較爲獨立的模塊，而後進行測試提交。便可很好地完成將測試進度與開發進度交叉起來。

按照這種方式進行拆解，在前期難以測試到各個模塊相互交叉關聯的地方。因此最後在整個項目開發完成，進行完整的集成測試仍舊是必須的。

任務跟進

里程碑

里程碑是一個在項目管理中常常被強調的概念。相信不少人跟我同樣，上學的時候老師佈置的寒假做業、暑假做業常常只有到假期快結束的時候纔會想起來寫。在項目開發中也同樣，大部分人對於時間節點是沒有明確概念的。因此在項目中設定多個里程碑，每一個里程碑都從新梳理項目的計劃以及剩餘工時，可以有效的下降項目最終延期的風險。

站例會

筆者起初對於站例會不太在乎，老是以爲團隊內部有什麼問題，直接進行溝通就好了，應該不存在須要天天開會來解決的問題。並且如今有相似 Tower、Teambition 這樣的協做產品，在團隊的進度實時同步上可以提供很大的幫助。

可是在實際的項目實踐中，每每由於各類緣由，不少同事不會或者不肯意進行溝通。在Tower、Teambition 這種工具的使用過程當中，也發現不少同事並不肯意及時去更新上面的任務狀態，最終這類軟件的任務安排流於形式，沒法有效地跟蹤任務進度情況。

前期咱們遇到這個問題的時候，只能經過詢問每一個開發的方式來獲取最新的項目進度狀況，可是這個方式很是討嫌。大部分開發仍是比較討厭別人向他們問進度狀況的。

這個時候，站例會的優點就體現出來了。站例會的基本規則就是要求每一個開發自述本身當前的項目狀況，例如：

• 我當前在作什麼
• 我今天會完成什麼
• 我有什麼須要支持的工做

在會上若是成員提出須要何人支持，能夠獲得項目組相關成員的當即響應，及時解決須要支持、依賴的工做，可以有效地促進你們工做的完成。

甘特圖

甘特圖真的是一個好東西，能夠很清晰的掌握項目的總體進度。可是咱們在嘗試使用的時候老是沒有很好的辦法讓他落地。其中一個很重要的緣由是一開始咱們就把甘特圖定的太細了。

例如，咱們開發模式是先後端分離開發，爲此將每一個先後端的任務所有拆分開進行展現。這樣作的後果就是甘特圖上的任務過多，沒法很清晰的定位，進而沒法很好地把握總體項目進度。

通過咱們的屢次項目實踐，發現一個較好的使用甘特圖的方式就是：每一個任務按獨立的模塊劃分。不管是前端仍是後臺，咱們將他們的模塊放在一塊兒進行管理。這樣作的好處還有一點，就是可以刺激先後端共同合做把模塊作好，而不是在遇到問題的時候，各類推脫甩鍋。

網上又不少甘特圖軟件，可是就靈活性和易用性來說，我仍是喜歡使用 Excel 裏的甘特圖模板，耐心體驗一下就會發現很是好用。有機會筆者會出一篇小教程來說講如何使用 Excel 裏的甘特圖模板。

後記

說說寫這篇文章的感想吧。《羅輯思惟》有一期比較老的節目，裏面講到了「實驗室經驗」和「工廠經驗」。前者指的是科學家們在研究所裏面對新的技術、產品去研究，總結併發布本身的經驗；後者指的是工廠在生產中總結出的各類難以複製的實踐經驗。

做爲一個工做了 7 年的程序員，深知不少知識是難以在書本以及博客上學習到的。不少時候咱們在某一個博客上學習到了某個技術知識，可是當它應用到生產的時候，就會出現各類問題。正如這篇文章講的項目管理知識，我的在剛開始帶團隊的時候，也看了很多相關的文章和資料，可是大多都過於理論化，難以應用到咱們實際的工做當中。

今天我寫這篇文章，正是想要分享我在實踐工做當中的「工廠經驗」，這些經驗可能不是最好的，但必定是通過實踐考驗的。但願可以幫到看到這篇文章的你。

都看到這裏了，點個贊關注一波哦。