如何作好項目管理任務分配

TL;DR

• 常見項目管理工具介紹
• 項目管理最重要的內容
• 誰來撰寫以及分配任務
• 如何有效地分配任務

項目管理工具

在我工做的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一頓；心情很差的話，你就得去帳務室，結下工資，出門左轉...

形成這個問題的緣由有兩種：

1. 老闆催着你必須在2個月內完成。

   這個好辦，你只要跟老闆講兩個字：儘可能。若是老闆回你兩個字：必須！。你有兩套方案，先進入瘋狂加班模式，到第2個月中，發現還有80%還沒有完成，啓動Plan B，你該好好更新下簡歷了！

2. 任務分配者對任務的時間預估誤差太大。

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

固然若是這個任務只是用來應付老闆的，找過最閒的手下去作就能夠了。

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

任務通常在細分後，在週一上午，團隊在一塊兒過一下每一個人本週所要完成的任務功能點，這樣有以下幾個好處：

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

• 讓你們瞭解彼此所作的事情，方便研發過程當中的溝通。

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

• 項目任務之間不免會有一些依賴關係。好比後臺必須先寫好接口，APP才能作獲取服務器數據的工做，須要對任務進行優先級上的調整，避免「A等待B的現象」。

不要低估內外部溝通成本

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

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

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

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

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

不要高估程序員的效率

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

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

若是你的工做計劃作得很細，以小時爲單位的總預期工時很是準，但若是你是按一天8小時算的，很差意思，這個項目必定會延期！並且會延期雙倍時間。

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

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

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

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

• 加班 加班是最不明智的方法，常態的加班只能讓程序員效率變低，最終的效率還不如正常下班的帶來的效率高。固然項目進度很緊的話，短期內的加班仍是有必要的。
• 加人 "趕忙招一個補上"。天那！這也不是工廠，招一個新人的成本過高了，這兄弟啥時能上手啊，等上手的時候估計項目已經延期好久了。還要考慮一個老兵帶新兵帶來的」內耗」。

我的博客

個人我的博客

歡迎點贊！