首页 > 代码库 > 关于任务分配方式的一种设想

关于任务分配方式的一种设想

  场景1:一个5个人的小团队在开会,他们在对工作包进行时间的估算,他们每人手上一幅牌,牌上面是一些1/2,1,2,4,5这些数字。A:4,B:1+2,C:4+1/2,D:5...这样他们各自表达了自己对当前任务的开发时间的估计,由于每个人的善长点,考虑的点都不同,所以时间几乎不相同。然后组长在分别收集他们每人对当前讨论任务给出时间的依据,特别注意用时最长和用时最短的人的想法,最后他们沟通后找到一个折中的时间,如果其中有些成员想法没有统一,最后也只能双方妥协,听组长安排,比如A说,这个地方肯定会用2天的时间,B又说这个地方用不到,只要半天。双方都说了理由,但是最后还是没有改变两方的看法,最后队长说那我们用1.5天来完成吧。

 

  场景2:团队前一段时间组合大家的意建把工作包时间估算出来了。现在是分派任务,然后就A做这几个,B做这几个,C做这几个……,或者是他们先自己选自己最想做的,最后来协调剩下的,总之最后是把所有的任务分到了每个人手上。

 

  从上面两个场景来看,认是还是很和谐的场景。但是没有经过细想,仔细想这两个中都会存在一些问题。第一个场景里面听取大家的意建来估算时间,这一点很不错,但是最后又把一个任务时间强行落到一个时间上面,这里有些略微的不妥,不过目前能这样来估算时间的都是不错的了,更不用考虑其它的情况。然后看看第二个场景,确实坑爹了不少,以前真的见过一公司是把任务列出来,大家选,最后剩下的都是大家不原意做的,而且大家这样乱选你觉时间时没有大问题吗?反正这样做肯定不是最优的做法。

 

  下面是本文提出的一种设想,同一活动节点下面多个工作包一起估算时间,也要考虑参与的人数,比如三个人做一个节点的工作,那么我们把下的工作包三个一组三个一组的分,尽量做成三个一组。那么我们估算时间的时候分别对三个工作包估算,比如工作包x,三个人A:2,B:3,C:3结果,当然这个过和同上面场景1是一样的效果,只是我们不急于去定死这个x包确定的时间。我们可以收集他们的意建,并公布,然后再来几次估算时间,是后得到一组比较折中的时间,但是我们不把这个确定成一个时间。那么最后我们出来的就是一个矩阵,然后我们再用匈牙利法求得最优解,这样子分配下去任务肯定最后时间是用得最少的方案。

这种方式的重点:
1.在大的节点下考虑,不用所有的成员都参与,只是要参与结点工作的人参与。这样每一个节点用时最后,项目的总体时间下来就最少。(这里说明一下,这里是用自下而上的方式,每个节点的时间少了,项目的总时间肯定少,但是不能说节点的时间缩短了,项目的工期就变短了)
2.按组来估时间,不确定到一个数字上面,保持大家对任务的意建和方案(这里也要说明,这不是成员说一个时间我们就保留这个时间,我们是在经过几轮下来确定的,也就是中间的难点,易点我们在过程中已经提出,大家也是清楚的情况下来保留的,这个点像德尔菲法)
3.最后就是要对这些数量还是较大的矩阵来求最优解。

  到目前为止我认为我说得不是很清楚,这个只是一个初步的设像,主要灵感来源就是效率矩阵,平时我们任务分派中没怎么用上这些方法。然后再结果敏捷里面的一些方法综合得出。这种方法我认为是较好,但是过程中的投入会较大,主要是上面的2,3两点会用时比前面场景的方法要多一些,不过我认为多不了多少,第3点这个是由项目管理来做的,这也更能体现项目管理人员的价值所在,第2点我们也可以减少中间估时的轮数,代价也不是很大。相比直接分配,最终效果肯定是会更好的。