前面说到过，刚开始带小组，接到一个任务，我就估算了我大概要多少时间，然后小组多少个人就算是多少个我，估算时间＝我要的总时间"小组人数（好笨的想法呀，不用时间跟组员交待任务的吗？个个组员都是我吗，比我强的还好，顶多做完了休息，差一点的就麻烦了），结果实际时间多了很多，而且小组里有的人做完了无事可做，有的人则忙得焦头烂额，容易打击组员的积极性，造成组员之间的不满。
      随着经验的积累，要想把任务分配得比较合适，首先要对自己的组员有一定的了解，最好能量化，其次要把握好任务（这就看需求分析及系统设计的功力了），以下是我的一点经验，我把我的组员分类（简称ABC分类），主要划分的指标有技术能力，做事速度，业务理解能力。
主要看前两个指标，因为我在做需求分析的时候已经把业务弄熟了，分配任务的时候我会尽量从程序员的角度跟他们描述业务逻辑，以下是我跟组员讨论业务的一点心得：
      1，业务上的一些概念名词要注意讲清楚，不要一带而过；特别是跟程序名词相近的。
      2，讲流程，尽量多画图，对着流程图讲解方便易懂，把来龙去脉讲清楚。
      3，多讲讲为什么这样做（思想），反过来可以验证自己是否真的理解了业务了。
      4，对于组员提出来的疑问，要能明确回答（验证业务、设计是经得起别人考验）
组员划分等级（每项满分10分），如图：

工作任务，主要从两个指标进行划分难度（技术，业务上），工作量，如图：

分配任务，任务类型对号入座到相应能力等级的组员中去(红色能力等级优先分配，依次往右递减）：

    我分配任务的原则是：技术好的多做脑力活，技术次之的多做体力活。
    不仅仅需求要分析到位，任务也要分析到位。很多Y，Z类的任务通过分析，可以化为X、Z-，化为这两种类型任务的好处是多做脑力活动，少做体力活动，相对减少开发时间。如图： 

      转换1示例：信息系统中的一大部分为：业务数据的录入+数据处理+流程控制，可以把流程的控制抽象为一个工作流控制组件，组内一个人做好，其它的人根据说明文档直接调用就可以了。 
      转换2示例：一些数据表对应的业务逻辑对应的操作仅仅是添加，删除，修改（难度小，量大），我们可以把它做成一个自动生成的模板，直接生成相应页面及操作代码。（CodeSmith是一个很好的自动生成工具，而且网上有很多做好的模板，很好用，推荐！）
    在平时开发中，在完成一个任务之后，我再回过头来看自己的编码，经常会突然想出另外一种方法，对比一下发现这种方法省时又省力，然后后悔当初为什么不用这种方法？
    需求没做好，过早地编码是做负功；任务设计分配没做好，过早编码则是多做功！

组员任务的时间确定
      让每个人分别估算每个任务的时间，PM自身也要估算任务的时间，差距不大时以组员为准，差距大时商议决定！（时间尽量以组员的为准，体现着信任，再则假如PM硬压时间下去，该组员肯定心里有情绪，也不利于工作，再则之间关系闹僵也不利于之后的工作开展）

      在实际的操作中，比较关键的任务（比如基础的模块，很多地方要调用到）我会认真地估算一下时间，然后再跟组员的对比；对于一些不太重要的任务我只是感觉一下时间，只要跟组员差不了很多（组员的时间＝我感觉的时间*2之内），一律以组员为准。个人认为应该放权给组员，面面俱到，亲力亲为的话PM会很累，对于一些不是很重要的东西，放心地让别人去做吧！感觉程序员都还是比较实在的，组员一般估算的时间都比我的少，几乎没出现过＝我感觉的时间*2的情况。

白纸黑字，责任要明确
      把每个人每段时间要做的任务写成文档，该文档最好是由任务的执行者来执笔，因为很多时候你给组员交代任务的时候，他看上去是听懂了（他自己当时也认为是懂了），可是做到中途的时候，才发现是似懂非懂，模凌两可，这时候他估算的时间自然也就不可靠了，整个项目的进度自然就比计划的慢了。PM看了文档后，就可了解该组员对任务的了解情况，发现有问题，便可有的放矢了。以下是我认为任务文档里应该清楚说明的几个地方：

（1）该任务是实现的功能是什么？
（2）什么时间完成？
（3）要达到什么样的质量？（为了防止只顾速度，不管质量，可把测试标准的一部分当成要达到的质量要求，例如：不能存在1类错误<设计中有的功能未实现>，2类错误<存在严重的错误使流程无法继续>）
（4）延时怎么处理？（开发中出现延时再正常不过了，我的做法：该任务执行人再估算余下需要的时间，只要是合理的延时直接同意）
（5）什么情况该任务终止？ （我的做法：延时一次后未能完成该任务，该任务终止，换人或方案）

飞眉 发表于 2014/1/22 14:54:28阅读全文 | 回复(0) | 引用通告 | 编辑 | 收藏该日志