前面说到过，刚开始带小组，接到一个任务，我就估算了我大概要多少时间，然后小组多少个人就算是多少个我，估算时间＝我要的总时间"小组人数（好笨的想法呀，不用时间跟组员交待任务的吗？个个组员都是我吗，比我强的还好，顶多做完了休息，差一点的就麻烦了），结果实际时间多了很多，而且小组里有的人做完了无事可做，有的人则忙得焦头烂额，容易打击组员的积极性，造成组员之间的不满。
随着经验的积累，要想把任务分配得比较合适，首先要对自己的组员有一定的了解，最好能量化，其次要把握好任务（这就看需求分析及系统设计的功力了），以下是我的一点经验，我把我的组员分类（简称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个小时（很好组员都心不在焉，不过也可以理解，都辛苦一天了，晚上还要加班），还有周六、周日加班的话，很容易造成下周整个小组的疲惫，影响正常的工作效率（个人观察发现的结果，不知有同感吗？）；不过发现上级很喜欢以小组加班与努不努力挂勾，看见小组加班就觉得很卖力（其实出的活很少，我统计过完成的任务量），像这种情况就做做样子做上级看好了。