如何做好項目管理任務分配？

作者：Charlie Chu

原文：www.cnblogs.com/charliechu/p/6768351.html

（點擊文末閱讀原文即可前往）

項目管理工具

在我工作的10多年中，使用過不少的項目管理系統，Excel, Microsoft，Project,dotProject, Redmine, Jira, Teambition, Worktile, Tello...。比我談過的女朋友還多。

這裡不講哪個工具更優秀，只能說應人而異吧。目前市場上用的比較多的有Redmine, Jira等傳統老兵，也有類似Teambition,Worktile看板式的新秀。

Redmine是我現在用的項目管理系統。它是基於ROR框架開發的一套免費開源的跨平台項目管理系統，數據可以很方便地存放在本地，插件也算豐富。

Teambition看板風格的界面更為時尚，還有APP方便隨時隨地查看。

我個人倒是沒有深入使用，不知道相應的任務和BUG狀態追蹤是否好用，比如一個BUG從「新建->分配->處理->已解決->待驗證->關閉/拒絕」。另外，看板視圖的拖來拖去，在狀態追蹤過程中會不會容易拖錯地方。有了解的可以說一下使用的感受。

項目管理最重要的內容是什麼？

用什麼工具不是最重要的，重要的是要把工具真正用起來。功能再強大的工具你沒有用起來，或者太複雜使用的成本太高，那也是白搭！

往往工具越複雜，使用的成本就越高，運用到項目中的機率也越低。

可以選擇一個最簡單的工具，而不要一上來就整一個「大麥克」，號稱「全宇宙第一」（你又不是Visual Studio!）。

那種全家桶式的工具，除了對日外包之外的公司，我感覺它的管理成本、學習成本應該不低，你們有真正用起來嗎，如果有的話，歡迎說下你們的感受。

不少人認為Redmine功能過於簡單，我倒是認為Redmine功能還是有點複雜了。如果由我來負責Redmine的產品設計，一上來我就會先砍掉一半的功能。

工具不能成為給領導彙報的形式。這樣只會浪費時間，增加毫無意義的管理成本。

無論選擇哪個工具，包括如下信息才能算作一款好的項目管理工具：

• 計劃完成日期 該任務計劃在哪一天完成。

• 預期工時 細分后的任務要給出一個合理的預期工時，必須以小時為單位。

• 實際完成日期 指定的任務實際完成時的日期。

• 實際工時 該任務完成時實際所耗的工時。

• 優先順序 任務以及BUG都應該有一個優先順序，將影響別人的任務優先順序設置為更高，避免團隊其他成員」Waiting for you「。

其中任務分配時的預期工時必須足夠細，越細越好，一般控制在半天之內，最多不超過一天，不過這也增加了管理上的成本。這需要管理者根據自身的研發團隊作一個權衡。

我們是如何做的？見下圖：

當然如果你們的研發團隊是自帶雞血的，總是能完美收工的話，你只需要粗略地將一周的任務安排給他們，那就爽歪歪了。

誰來分配任務

老闆讓你2個月開發出一個產品，研發吭哧吭哧地搞了2個月，到了第2個月的30號交給老闆，老闆很開心地打開系統，發現連TM登錄都登錄不了。

老闆心情好的話，可能你會被狠K一頓；心情不好的話，你就得去賬務室，結下工資，出門左轉...

造成這個問題的原因有兩種：

• 老闆催著你必須在2個月內完成。

  這個好辦，你只要跟老闆講兩個字：盡量。如果老闆回你兩個字：必須！。你有兩套方案，先進入瘋狂加班模式，到第2個月中，發現還有80%尚未完成，啟動Plan B，你該好好更新下簡歷了！

• 任務分配者對任務的時間預估偏差太大。

要想項目的分配儘可能地準確，任務分配者必須了解項目研發相關的技術，倒不是要非常熟練，至少有所了解。另外最好工作經驗在6年以上。

當然如果這個任務只是用來應付老闆的，找過最閑的手下去做就可以了。

每周一開會過一下本周的任務

任務一般在細分后，在周一上午，團隊在一起過一下每個人本周所要完成的任務功能點，這樣有如下幾個好處：

• 儘快擺脫」星期一綜合症「。

• 讓大家了解彼此所做的事情，方便研發過程中的溝通。

• 了解一下自己本周要完成的任務，看看有哪些可能會遇到的坑，方便自己合理安排時間。

• 項目任務之間難免會有一些依賴關係。比如後台必須先寫好介面，APP才能做獲取伺服器數據的工作，需要對任務進行優先順序上的調整，避免「A等待B的現象」。

不要低估內外部溝通成本

碰上項目需要對外跟客戶進行溝通，那你就慘了。客戶在軟體項目上的智商只有真正打過交道的人才知道！

加上習慣性被忽視的內部溝通成本，產品經理、項目經理、研發經理、研發團隊內部...

對了，還有那可惡的銷售人員，不知啥時跟客戶喝酒時說產品啥功能都有，1個月就可以交付使用。終於知道心中一萬隻奔騰而過是什麼感受了。

還有從來都是被遺忘的產品測試和調試時間，其實這是項目研發過程中耗在這上面的時間是很長的，甚至於超過編碼時間。

加上老闆有事沒事來看望你兩眼，總會打斷了你的思路。（表示關心，其實是催一下進度，看你有沒有混日子，但你還要對老闆講，謝謝老闆關心）

不要高估程序員的效率

在我工作的十年中，說來懺愧，記不得哪個項目是真正意思上按時完成的！

什麼，你說你們的項目都是按時完成的？我的第一反應會是：這兄弟絕對在逗我！

如果你的工作計劃做得很細，以小時為單位的總預期工時非常准，但如果你是按一天8小時算的，不好意思，這個項目一定會延期！而且會延期雙倍時間。

你真認為你的程序員們真的像發動機一樣，在8小時高速運轉嗎？基礎上99.99%的公司不是（還有0.01%留給你們公司，供你們YY）。

你要說美國FAG？我告訴你那些牛逼的公司更不會是。正常的有效工作時間只有8的一半：3小時！

還有現在所想不到的」不可抗力因素「：程序員戀愛了、失戀了、結婚了、吵架了、懷孕了...；辦公室突然斷電了、斷網了...

要是突然一個重要的程序員生病了，離職了，在老闆看來，辦法無非兩種：（其實這兩種辦法都不明智）

• 加班 加班是最不明智的方法，常態的加班只能讓程序員效率變低，最終的效率還不如正常下班的帶來的效率高。當然項目進度很緊的話，短時間內的加班還是有必要的。

• 加人 "趕緊招一個補上"。天那！這也不是工廠，招一個新人的成本太高了，這兄弟啥時能上手啊，等上手的時候估計項目已經延期很久了。還要考慮一個老兵帶新兵帶來的」內耗」。