前面說到過，剛開始帶小組，接到一個任務，我就估算了我大概要多少時間，然後小組多少個人就算是多少個我，估算時間＝我要的總時間"小組人數（好笨的想法呀，不用時間跟組員交待任務的嗎？個個組員都是我嗎，比我強的還好，頂多做完了休息，差一點的就麻煩了），結果實際時間多了很多，而且小組裡有的人做完了無事可做，有的人則忙得焦頭爛額，容易打擊組員的積極性，造成組員之間的不滿。
随着經驗的積累，要想把任務配置設定得比較合适，首先要對自己的組員有一定的了解，最好能量化，其次要把握好任務（這就看需求分析及系統設計的功力了），以下是我的一點經驗，我把我的組員分類（簡稱ABC分類），主要劃分的名額有技術能力，做事速度，業務了解能力。
主要看前兩個名額，因為我在做需求分析的時候已經把業務弄熟了，配置設定任務的時候我會盡量從程式員的角度跟他們描述業務邏輯，以下是我跟組員讨論業務的一點心得：
1，業務上的一些概念名詞要注意講清楚，不要一帶而過；特别是跟程式名詞相近的。
2，講流程，盡量多畫圖，對着流程圖講解友善易懂，把來龍去脈講清楚。
3，多講講為什麼這樣做（思想），反過來可以驗證自己是否真的了解了業務了。
4，對于組員提出來的疑問，要能明确回答（驗證業務、設計是經得起别人考驗）
組員劃分等級（每項滿分10分），如圖：
能力等級
技術能力
做事速度
A+
非常好（8-9）
慢（5）
A
好（7）
快（6）
B
一般（6）
C
工作任務，主要從兩個名額進行劃分難度（技術，業務上），工作量，如圖：
任務類型
技術難度
工作量
X
大
小
Y
Z
Z-
配置設定任務，任務類型對号入座到相應能力等級的組員中去(紅色能力等級優先配置設定，依次往右遞減）：
A+ A
A A+
B A, A+
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個小時（很好組員都心不在焉，不過也可以了解，都辛苦一天了，晚上還要加班），還有周六、周日加班的話，很容易造成下周整個小組的疲憊，影響正常的工作效率（個人觀察發現的結果，不知有同感嗎？）；不過發現上級很喜歡以小組加班與努不努力挂勾，看見小組加班就覺得很賣力（其實出的活很少，我統計過完成的任務量），像這種情況就做做樣子做上級看好了。