如何做好項目管理任務分配
項目管理工具
在我工作的10多年中，使用過不少的項目管理系統(tǒng)，Excel, Microsoft Project, dotProject,Redmine, Jira, Teambition, Worktile, Tello…。比我談過的女朋友還多。
這里不講哪個工具更優(yōu)秀，只能說應人而異吧。目前市場上用的比較多的有Redmine, Jira等傳統(tǒng)老兵，也有類似Teambition,Worktile看板式的新秀。
Redmine是我現(xiàn)在用的項目管理系統(tǒng)。它是基于ROR框架開發(fā)的一套免費開源的跨平臺項目管理系統(tǒng)，數(shù)據(jù)可以很方便地存放在本地，插件也算豐富。
Teambition看板風格的界面更為時尚，還有APP方便隨時隨地查看。
我個人倒是沒有深入使用，不知道相應的任務和BUG狀態(tài)追蹤是否好用，比如一個BUG從“新建->分配->處理->已解決->待驗證->關(guān)閉/拒絕”。另外，看板視圖的拖來拖去，在狀態(tài)追蹤過程中會不會容易拖錯地方。有了解的可以說一下使用的感受。
項目管理最重要的內(nèi)容是什么?
用什么工具不是最重要的，重要的是要把工具真正用起來。功能再強大的工具你沒有用起來，或者太復雜使用的成本太高，那也是白搭!
往往工具越復雜，使用的成本就越高，運用到項目中的機率也越低。
可以選擇一個最簡單的工具，而不要一上來就整一個“巨無霸”，號稱“全宇宙***”(你有不是Visual Studio!)。
那種全家桶式的工具，除了對日外包之外的公司，我感覺它的管理成本、學習成本應該不低，你們有真正用起來嗎，如果有的話，歡迎說下你們的感受。
不少人認為Redmine功能過于簡單，我倒是認為Redmine功能還是有點復雜了。如果由我來負責Redmine的產(chǎn)品設(shè)計，一上來我就會先砍掉一半的功能。
工具不能成為給領(lǐng)導匯報的形式。這樣只會浪費時間，增加毫無意義的管理成本。
無論選擇哪個工具，包括如下信息才能算作一款好的項目管理工具：
- 計劃完成日期 該任務計劃在哪一天完成。
- 預期工時 細分后的任務要給出一個合理的預期工時，必須以小時為單位。
- 實際完成日期 指定的任務實際完成時的日期。
- 實際工時 該任務完成時實際所耗的工時。
- 優(yōu)先級 任務以及BUG都應該有一個優(yōu)先級，將影響別人的任務優(yōu)先級設(shè)置為更高，避免團隊其他成員”Waiting for you“。
其中任務分配時的預期工時必須足夠細，越細越好，一般控制在半天之內(nèi)，最多不超過一天，不過這也增加了管理上的成本。這需要管理者根據(jù)自身的研發(fā)團隊作一個權(quán)衡。
當然如果你們的研發(fā)團隊是自帶雞血的，總是能***收工的話，你只需要粗略地將一周的任務安排給他們，那就爽歪歪了。
誰來分配任務
老板讓你2個月開發(fā)出一個產(chǎn)品，研發(fā)吭哧吭哧地搞了2個月，到了第2個月的30號交給老板，老板很開心地打開系統(tǒng)，發(fā)現(xiàn)連TM登錄都登錄不了。
老板心情好的話，可能你會被狠K一頓;心情不好的話，你就得去賬務室，結(jié)下工資，出門左轉(zhuǎn)…
造成這個問題的原因有兩種：
1.老板催著你必須在2個月內(nèi)完成。
這個好辦，你只要跟老板講兩個字：盡量。如果老板回你兩個字：必須!。你有兩套方案，先進入瘋狂加班模式，到第2個月中，發(fā)現(xiàn)還有80%尚未完成，啟動Plan B，你該好好更新下簡歷了!
2.任務分配者對任務的時間預估偏差太大。
要想項目的分配盡可能地準確，任務分配者必須了解項目研發(fā)相關(guān)的技術(shù)，倒不是要非常熟練，至少有所了解。另外***工作經(jīng)驗在6年以上。
當然如果這個任務只是用來應付老板的，找過最閑的手下去做就可以了。
每周一開會過一下本周的任務
任務一般在細分后，在周一上午，團隊在一起過一下每個人本周所要完成的任務功能點，這樣有如下幾個好處：
- 盡快擺脫”星期一綜合癥“。
- 讓大家了解彼此所做的事情，方便研發(fā)過程中的溝通。
- 了解一下自己本周要完成的任務，看看有哪些可能會遇到的坑，方便自己合理安排時間。
- 項目任務之間難免會有一些依賴關(guān)系。比如后臺必須先寫好接口，APP才能做獲取服務器數(shù)據(jù)的工作，需要對任務進行優(yōu)先級上的調(diào)整，避免“A等待B的現(xiàn)象”。
不要低估內(nèi)外部溝通成本
碰上項目需要對外跟客戶進行溝通，那你就慘了。客戶在軟件項目上的智商只有真正打過交道的人才知道!
加上習慣性被忽視的內(nèi)部溝通成本，產(chǎn)品經(jīng)理、項目經(jīng)理、研發(fā)經(jīng)理、研發(fā)團隊內(nèi)部…
對了，還有那可惡的銷售人員，不知啥時跟客戶喝酒時說產(chǎn)品啥功能都有，1個月就可以交付使用。終于知道心中一萬只奔騰而過是什么感受了。
還有從來都是被遺忘的產(chǎn)品測試和調(diào)試時間，其實這是項目研發(fā)過程中耗在這上面的時間是很長的，甚至于超過編碼時間。
加上老板有事沒事來看望你兩眼，總會打斷了你的思路。(表示關(guān)心，其實是催一下進度，看你有沒有混日子，但你還要對老板講，謝謝老板關(guān)心)
不要高估程序員的效率
在我工作的十年中，說來懺愧，記不得哪個項目是真正意思上按時完成的!
什么，你說你們的項目都是按時完成的?我的***反應會是：這兄弟絕對在逗我!
如果你的工作計劃做得很細，以小時為單位的總預期工時非常準，但如果你是按一天8小時算的，不好意思，這個項目一定會延期!而且會延期雙倍時間。
你真認為你的程序員們真的像發(fā)動機一樣，在8小時高速運轉(zhuǎn)嗎?基礎(chǔ)上99.99%的公司不是(還有0.01%留給你們公司，供你們YY)。
你要說美國FAG?我告訴你那些牛逼的公司更不會是。正常的有效工作時間只有8的一半：3小時!
還有現(xiàn)在所想不到的”不可抗力因素“：程序員戀愛了、失戀了、結(jié)婚了、吵架了、懷孕了…;辦公室突然斷電了、斷網(wǎng)了…
要是突然一個重要的程序員生病了，離職了，在老板看來，辦法無非兩種：(其實這兩種辦法都不明智)
- 加班 加班是最不明智的方法，常態(tài)的加班只能讓程序員效率變低，最終的效率還不如正常下班的帶來的效率高。當然項目進度很緊的話，短時間內(nèi)的加班還是有必要的。
- 加人 “趕緊招一個補上”。天那!這也不是工廠，招一個新人的成本太高了，這兄弟啥時能上手啊，等上手的時候估計項目已經(jīng)延期很久了。還要考慮一個老兵帶新兵帶來的”內(nèi)耗”。
【本文為51CTO專欄作者“朱成林”的原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
