小公司該如何做好項目管理工作？

01-06

小公司，沒有項目經理，項目多，基本上一個程序員是一個項目的主要負責人。作為一名產品狗，除了要出每個項目的需求外，還需要跟進整個項目的開發進度、項目測試及項目完成發布。但是發現很多項目進度很難把控，經常延期，因此很苦惱，求各位產品大神賜解決方案。萬分感謝！

對於這個問題我建議你好好思考下，首先不要將這個問題理解為項目管理方法和工具層面的問題，很多時候一個小團隊，有excel來做項目管理已經能解決問題，不是用了項目管理工具或啟用了項目管理過程你的問題就能夠解決。

這個問題的本質我的理解還是三個方面的內容

1.對需求，架構等核心的關鍵點個人的把控能力

作為一個小團隊的項目經理，你必須具備這個能力，即對業務和需求的能力，對技術架構的把控，不要說這些是由需求或開發人員完成的與自己沒有關係。小團隊的項目經理最核心的能力還是在技術把控上，你很多時候的關鍵把控和里程碑評審將直接減少項目變更和後續返工。

2.對各種風險的預估和預判能力

任何一個項目，如果沒有風險就應該是成功的項目。那麼在項目執行過程中你自己意識到了有哪些風險，又如何提前有針對性的應對這些風險就至關重要了。

3.對團隊人員本身能力的了解和激勵能力

你需要清晰的了解團隊中每個人的技能水平和工作效率，否則你分配出去的任務將沒有任何保障。同時需要激發團隊人員的熱情和協作的態度，保持團隊有足夠的向心力完成目標。這個看起來感覺比較虛，但是很多項目失敗原因往往就在此。

每個項目準備三個表：

XXX項目需求列表.xls

XXX項目BUG列表.xls

XXX項目項目進度表.xls（包含三方面內容：本周完成任務，下周計劃，總體進度）

每周五發周報給領導，抄送負責該項目的程序員。

非常贊成 @何明璐的答案

他總結的三個能力基本上全部概括了問題要點，說得非常在點，是一幅良方

但是偏重理論，題主要的解決問題手段沒有出現。能力問題，尤其是類似對技術架構的把控和風險預判這種能力，不是一天兩天能學會的。

光開方子，不抓藥，不能解決題主的問題

我來嘗試抓點葯

所以我從開發管理和團隊管理方面的實操角度解答一下

我們解決管理問題的思路，是有跡可循的

所有的管理問題，可以入手的方面不外乎兩件事情，一個是制度，一個是人

出現一個問題，最基本的，是要分辨這個問題是制度導致的，還是人導致的，還是制度和人都有問題，需要細分。哪個有問題就整哪個。

分析問題

從你的描述來看，公司在開發管理方面有基本的制度，所有職位各就各位，但是發現事情還是不順利，主要體現在項目進度無法把控的延遲。

這裡有兩個信息，一個是無法把控，一個是延遲。這兩個看似一樣，其實不是一件事。

延遲是相對於計劃，超出計劃之外就算延遲，但是可以在發生之前預先知曉的。

而無法把控是管理者處於一種對實際情況完全不知曉的狀態，這才是最可怕的事情。

然後我們來判斷一下，這兩個問題的出現是因為制度還是因為人。

先把延遲放一邊，我認為這個不是主要矛盾。

我們來看無法把控，無法把控，首先是制度問題，因為沒有建立很好的進度記錄製度和溝通制度，才會產生無法把控的感覺。

然後人肯定有問題，因為當無法把控和延期同時發生的時候，證明開發人員在工作上出現了問題，至於這個問題是水平導致還是態度導致，由於沒有進一步的信息，無法判斷。

從經驗上判斷

這種情況一般是由於開發人員技術水平有限，導致估時不準而延期，又因為沒有主動溝通意識或者其他原因導致不通知其他人。

解決手段

制度方面

1、建立進度記錄製度，比如日報，工作日記。防止進度情況不明。

2、建立溝通制度和日常共享通道，比如定時的周會、晨會、郵件規則。防止溝通障礙。

記得制度要建立，更要執行。

以上兩點是解決了制度上的問題

至此根源問題還未能解決，就是估時不準和預判進度延遲。

估時不準一般是由於開發人員水平不高，經驗不足，或者涉足未接觸過的領域時會出現，解決問題最直接的方法是找個能力夠的高手來，高手坐鎮，水平經驗都夠了，自然解決了。

如果沒有高手怎麼辦？比較常用的辦法就是群策群力+經驗積累。

具體的操作方法是收到需求以後做設計和任務拆分，然後召集公司較為有經驗的開發人員一起來評審。

參與評審的人員需要給出三個方面意見

1、需求是否有不明確的地方，如果有則需要明確

2、設計是否有不明確的地方，如果有則需要明確

3、對任務進行估時，如果上述兩項有不明確的地方，估時必然是不準的，實操當中需要根據情況調整。

這樣估時比單人評估要準確很多。

如果項目進行到最後發現估時不準確，則記錄原因和需要改進的地方，發給評審參與者，大家把經驗積累下來。

更具體的要點，可以參考scrum裡面的迭代啟動會議，感覺裡面很多要點用在這裡比較合適。

預判進度延遲。為了有效的預判進度延遲，需要做兩方面的工作。

1、對任務進行拆分

2、對任務進行估時

需要注意的是，拆分任務越細緻，越合理，越是有利於判斷進度延遲。

假如一個項目所有工作都拆成一個小時一個任務包，管理人員只要盯著任務包完成情況就知道是不是有延遲了。

但是………………實際上這是不可能的。因為工作拆得太細會使管理成本急劇上升，同時導致開發人員反感而難以落實。

建議拆成兩天左右一個工作包，那是否進度延遲只要看工作日報就明確了，發現延遲也很及時。

更具體的要點，可以參考scrum裡面的任務拆分，基本上是比較合適這個場景的。

基本上就是這樣啦，因為有些信息不明，也只能分析到這一步。

至於工具，我很贊成 @何明璐說的，只要一個excel就能解決問題了。

但是我想說，用excel那是下限，只能說可以完成工作。如果想準確高效省時省力，可以以excel為核心，配合郵件和其他的工具組合成一套管理工具。

主要覆蓋到

1、項目情況記錄（比如需求列表、設計文檔、任務拆分結果和估時結果）

2、多人書面溝通（比如進度情況周知、各種文件備案）

3、點對點書面溝通（比如日報）

4、文件文檔備份（比如歷史項目備份）

比如說excel缺乏溝通能力，可以用有道雲筆記或者EverNote補充為團隊書面溝通手段，另外用遠程白板類工具作為日報工具，SVN作為文件文檔備份等等等等。

本題裡面有些人推薦了一些工具，我沒有用過，但是都會是有合適的使用場景的，你可以挑選自己合適的。

小公司連項目經理都沒有，要開那麼多項目幹什麼？居然還養產品狗？

小公司里總經理就是項目負責人，或者技術總監就是項目經理，再或者部門經理就是項目經理。

我覺得首先要弄清楚一個問題，要解決的是『多項目管理』還是『多人協作』？

這兩者這之間雖然並不矛盾，但是有主次之分。

很多類似回答都歸為多人協作的工具，但是這些產品在多項目管理方面卻稍顯薄弱。

以我之見，項目管理應該專註於項目本身，並且圍繞這些項目進行周邊的管理，例如任務，協作，財務，等等，這些情況的使用場景有程序員接私活，自由職業者，外包團隊等。

以
程序員接私活舉例，一個程序員接了五個私活，這五個私活就是五個項目，而每個項目又有若干任務，例如資料庫，前端，後台，等等，這個程序員可能還會把其中
某一兩個項目的某一兩個任務交給他的小弟去做，那麼面臨的問題是多項目中多任務的管理，並且由此而來的資金流動，統計等問題，都更為複雜。這時候，上面答
案提到的所有工具基本上都無法很好的解決。

而國內最符合多項目管理的條件的產品，我覺得是『簡單 - 幫你把工作變得更簡單』，它可以解決多項目的管理問題。

這款產品是以項目為核心的：