前面說到過，剛開始帶小組，接到乙個任務，我就估算了我大概要多少時間，然後小組多少個人就算是多少個我，估算時間＝我要的總時間"小組人數（好笨的想法呀，不用時間跟組員交待任務的嗎？個個組員都是我嗎，比我強的還好，頂多做完了休息，差一點的就麻煩了），結果實際時間多了很多，而且小組裡有的人做完了無事可做，有的人則忙得焦頭爛額，容易打擊組員的積極性，造成組員之間的不滿。
隨著經驗的積累，要想把任務分配得比較合適，首先要對自己的組員有一定的了解，最好能量化，其次要把握好任務（這就看需求分析及系統設計的功力了），以下是我的一點經驗，我把我的組員分類（簡稱abc分類），主要劃分的指標有技術能力，做事速度，業務理解能力。
主要看前兩個指標，因為我在做需求分析的時候已經把業務弄熟了，分配任務的時候我會盡量從程式設計師的角度跟他們描述業務邏輯，以下是我跟組員討論業務的一點心得：
1，業務上的一些概念名詞要注意講清楚，不要一帶而過；特別是跟程式名詞相近的。
2，講流程，盡量多畫圖，對著流程圖講解方便易懂，把來龍去脈講清楚。
3，多講講為什麼這樣做（思想），反過來可以驗證自己是否真的理解了業務了。
4，對於組員提出來的疑問，要能明確回答（驗證業務、設計是經得起別人考驗）
組員劃分等級（每項滿分10分），如圖：
能力等級
技術能力
做事速度 a+
非常好（8-9）
慢（5） a
好（7）
快（6） b
一般（6）
快（6） c
一般（6）
一般（6）
工作任務，主要從兩個指標進行劃分難度（技術，業務上），工作量，如圖：
任務型別
技術難度
工作量 x
大 小
y大 大
z小 大 z-小
小 分配任務，任務型別對號入座到相應能力等級的組員中去(紅色能力等級優先分配，依次往右遞減）：
任務型別
能力等級 x
a+ a
ya a+
zb a, a+
z-c b, a, a+
我分配任務的原則是：
技術好的多做腦力活，技術次之的多做體力活。
不僅僅需求要分析到位，任務也要分析到位。很多y，z類的任務通過分析，可以化為x、z-，化為這兩種型別任務的好處是多做腦力活動，少做體力活動，相對減少開發時間。如圖：
轉換1示例：資訊系統中的一大部分為：業務資料的錄入+資料處理+流程控制，可以把流程的控制抽象為乙個工作流控制項，組內乙個人做好，其它的人根據說明文件直接呼叫就可以了。
轉換2示例：一些資料表對應的業務邏輯對應的操作僅僅是新增，刪除，修改（難度小，量大），我們可以把它做成乙個自動生成的模板，直接生成相應頁面及操作**。（codesmith是乙個很好的自動生成工具，而且網上有很多做好的模板，很好用，推薦！）
在平時開發中，在完成乙個任務之後，我再回過頭來看自己的編碼，經常會突然想出另外一種方法，對比一下發現這種方法省時又省力，然後後悔當初為什麼不用這種方法？
需求沒做好，過早地編碼是做負功；任務設計分配沒做好，過早編碼則是多做功！
組員任務的時間確定
讓每個人分別估算每個任務的時間，pm自身也要估算任務的時間，差距不大時以組員為準，差距大時商議決定！（時間盡量以組員的為準，體現著信任，再則假如pm硬壓時間下去，該組員肯定心裡有情緒，也不利於工作，再則之間關係鬧僵也不利於之後的工作開展）
在實際的操作中，比較關鍵的任務（比如基礎的模組，很多地方要呼叫到）我會認真地估算一下時間，然後再跟組員的對比；對於一些不太重要的任務我只是感覺一下時間，只要跟組員差不了很多（組員的時間＝我感覺的時間*2之內），一律以組員為準。個人認為應該放權給組員，面面俱到，親力親為的話pm會很累，對於一些不是很重要的東西，放心地讓別人去做吧！感覺程式設計師都還是比較實在的，組員一般估算的時間都比我的少，幾乎沒出現過＝我感覺的時間*2的情況。
白紙黑字，責任要明確
把每個人每段時間要做的任務寫成文件，該文件最好是由任務的執行者來執筆，因為很多時候你給組員交代任務的時候，他看上去是聽懂了（他自己當時也認為是懂了），可是做到中途的時候，才發現是似懂非懂，模凌兩可，這時候他估算的時間自然也就不可靠了，整個專案的進度自然就比計畫的慢了。pm看了文件後，就可了解該組員對任務的了解情況，發現有問題，便可有的放矢了。以下是我認為任務文件裡應該清楚說明的幾個地方：
（1）該任務是實現的功能是什麼？
（2）什麼時間完成？
（3）要達到什麼樣的質量？（為了防止只顧速度，不管質量，可把測試標準的一部分當成要達到的質量要求，例如：不能存在1類錯誤《設計中有的功能未實現》，2類錯誤《存在嚴重的錯誤使流程無法繼續》）
（4）延時怎麼處理？（開發中出現延時再正常不過了，我的做法：該任務執行人再估算餘下需要的時間，只要是合理的延時直接同意）
（5）什麼情況該任務終止？ （我的做法：延時一次後未能完成該任務，該任務終止，換人或方案）
這項在一般公司的任務文件說明裡很少見，但我覺得很有必要，它的好處如下： a防止無限延時（無底洞），有時候某人勝任不了該任務（分配任務的失誤），到了時間做不完，延時，再做不完不甘心，再延時，如此反覆，期間你不同意有點不近人情，不給面子，同意的話時間上又受不了。有了此項說明，出現了這情況就終止，有文件為證証，按依據辦事＝＝對事不對人，這時對雙方都是一種解脫。
b起督促作用，因為延時後再完成不了會被stop，出現了延時之後，組員都會提起十二分精神搞定，因為已經沒下次了。
這部分分檔一式三份，乙份交上級，乙份pm，乙份任務的執行者；有專案管理系統的話，直接錄入即可。在這種情況下建議還是生成乙份文件交給上級，因為上級一般不太進專案管理系統；再則看到專門的文件容易引起重視。
信任，但是要檢查
當乙個任務的時間大於6天以上，要進行相應的細化，細化到3-6天為宜（在任務上寫清楚，在該時間點上，應該出來什麼成果，如何進行檢查），主要出於以下幾個方面的考慮：
a個別組員自我管理能力差點，當任務時間比較長時，容易出視前松後緊的情況，這時候把任務細化到3點一檢查，可以避免這種情況。
b檢查時間正好為一周，在這個點上，正好小組一起開個例會，在例會上小組每個成員依次發言，內容為我這一周的計畫是什麼，實際進行得怎樣，實際比計畫好，則說說自己做得好的地方在哪，讓大家學習；實際比計畫差，則說說自己問題出在哪，大家支支招；最後我進行總結發言。這個例會看似簡單，實則發揮作用很大，試想一下你完成不了計畫的任務，當著這麼多人的面說起來，假如原因僅僅是自己做事慢；又或者你每週都是在講完成不了任務，只要不是臉皮很厚的，都會覺得自責，不好意思，甚至於臉紅！這就是一種無形的督促，約束，這個組員下週肯定會拼命幹（糗了一次，不能糗第二次嘛，人很正常的心理，這比你平時直接叫他快點做，或者責怪、批評他要強得多）
c這好比跑馬拉松，因為距離很長，在很長一段時間內看不到目標，人很容易疲倦，但你人為地將它劃分為若干個目標（檢查點）之後，目標清晰可見而容易到達，人就很有動力了，且不容易覺得很累。
每次檢查都要做完相應的記錄，形成文件（更新到系統中），一定時間段內傳送給上級，做為匯報的內容，讓上級知道小組在幹什麼，幹都怎麼樣。
任務文件相於計畫，檢查記錄相於實際，實際與計畫對比就出來績效
。實際比計畫好，就是做得好，反之則差，好多少，差多少，也可以在文件中找到相應的依據（時間，質量）。還有就是這種避免了中途加功能，出現延時說不清楚（對著文件，新加的功能作為一項新的任務，自然要加時間，可能在客戶那邊是一樣的延時，但對於你的上級來看則是不一樣了，他至少不會認為是小組不努力，偷懶造成了延時）。
記得有乙個專案，因為是專案收尾時客戶加了功能，所以延了時間，還有銷售、市場人員給客戶演示系統的時候出了點問題（銷售、市場人員對系統不解、操作不熟練，當然也有系統不夠人性化的原因），在協調會上，銷售人員就往開發身上推責任，就事論事也就得了，居然還扯到其它的，說開發的怠工，不夠賣力，還延時了比較久。當時上級表示了也有同感（事後分析時估計是上級來檢查時，正好組員完成了該段時間任務，有點放鬆，在看看書、報），假如是以前我的做法是訴苦：「你也不看看中間加了多少功能？」，「小組都加了好幾天班了」之類的話語，別人肯定不買單，最後就變成吵架會了！這時我把任務、檢錄記錄文件拿出來，指出哪些是加的功能，哪些是最初設計的功能（這些文件裡都有記錄），一對比，加的功能佔了多少，都是在什麼時間段追加的（主要是在後期，趕工也來不及了呀），這就是為什麼延時的原因？再有是組員檢查時的進度與計畫的比較（那次還算比較好，實際基本跟計畫一致），到底是不是我故意在延時，或怠工造成了延時，還有開發的賣不賣力，文件記錄都能說明問題。講完之後再把文件的遞給銷售、市場的人看，當即他們就啞火了，事實勝於雄辯呀！事後他還向我道了歉，說自己脾氣比較直，說話說過頭了，呵呵。
1，pm不要給自己分配給過多的任務，任務型別為x，z-為佳，因為pm要抽出較多的時間比進團隊的管理。因為開發以技術以主，pm要能服人心，關鍵是技術要比較好，所以建議選x型別任務，不會因為工作量太多而致使沒時間管理小組。
2， 需求分析—估算時間—分配任務，不是乙個直線下來的操作，在需求分析的時候可以敏銳地找出一些與業務無關的技術難點，此時可以安排組員攻關。分配好任務，每個組員算好自己的時間，可做為估算時間的乙個參考依據。
3，不要把加班的時間當成正常的工作時間，因為開發經常會出現延時，加班的時間一般當成補漏的時間比較合適，再則我發現加班的時間效率比較低，一般晚上2、3個小時還不如正常工作時間的1個小時（很好組員都心不在焉，不過也可以理解，都辛苦一天了，晚上還要加班），還有周
六、週日加班的話，很容易造成下週整個小組的疲憊，影響正常的工作效率（個人觀察發現的結果，不知有同感嗎？）；不過發現上級很喜歡以小組加班與努不努力掛勾，看見小組加班就覺得很賣力（其實出的活很少，我統計過完成的任務量），像這種情況就做做樣子做上級看好了。
專案管理 任務分配閒談
這件事事實上發生在本週三吧。記得比較清楚是由於我周四要歇息。當時.net專案那邊的乙個技術支援找到我，希望我能做乙個svn分支版本號的規劃和培訓文件什麼的。事實上當時自己手下也沒有什麼事情。本來是應該答應的。可是當時停頓了兩秒，感覺這件事情不應該是我來做。或許這麼說不恰當，應該說是這件事不應該是交到...
專案管理 任務分配閒談
這件事其實發生在本週三吧，記得比較清楚是因為我周四要休息，當時.net專案那邊的乙個技術支援找到我，希望我能做乙個svn分支版本的規劃和培訓文件什麼的。其實當時自己手下也沒有什麼事情，本來是應該答應的。但是當時停頓了兩秒，感覺這件事情不應該是我來做，也許這麼說不恰當，應該說是這件事不應該是交到我這裡...
專案管理之任務分配
乙個專案需求確定了 需求這個東西永遠沒有確定的哪一天，時時刻刻都是在變化,但是經理認為確定了那就是確定了 p 然後專案經理給了乙份需求文件就算真是開始開發了。大致用了一天的時間資料庫就由乙個開發人員設計了出來 其實對於這個速度我還是比較 驚訝 的，一天就把資料庫設計出來，可見資料庫中丟字段 字段設計...