当前位置 : 主页 > 编程语言 > 其它开发 >

工作感言:任务分配及管理

来源:互联网 收集:自由互联 发布时间:2022-05-25
工作感言:任务分配及管理 前面说到过,刚开始带小组,接到一个任务,我就估算了我大概要多少时间,然后小组多少个人就算是多少个我,估算时间=我要的总时间"小组人数(好笨
工作感言:任务分配及管理 前面说到过,刚开始带小组,接到一个任务,我就估算了我大概要多少时间,然后小组多少个人就算是多少个我,估算时间=我要的总时间"小组人数(好笨的想法呀,不用时间跟组员交待任务的吗?个个组员都是我吗,比我强的还好,顶多做完了休息,差一点的就麻烦了),结果实际时间多了很多,而且小组里有的人做完了无事可做,有的人则忙得焦头烂额,容易打击组员的积极性,造成组员之间的不满。 随着经验的积累,要想把任务分配得比较合适,首先要对自己的组员有一定的了解,最好能量化,其次要把握好任务(这就看需求分析及系统设计的功力了),以下是我的一点经验,我把我的组员分类(简称ABC分类),主要划分的指标有技术能力,做事速度,业务理解能力。 主要看前两个指标,因为我在做需求分析的时候已经把业务弄熟了,分配任务的时候我会尽量从程序员的角度跟他们描述业务逻辑,以下是我跟组员讨论业务的一点心得:

      前面说到过,刚开始带小组,接到一个任务,我就估算了我大概要多少时间,然后小组多少个人就算是多少个我,估算时间=我要的总时间"小组人数(好笨的想法呀,不用时间跟组员交待任务的吗?个个组员都是我吗,比我强的还好,顶多做完了休息,差一点的就麻烦了),结果实际时间多了很多,而且小组里有的人做完了无事可做,有的人则忙得焦头烂额,容易打击组员的积极性,造成组员之间的不满。
      随着经验的积累,要想把任务分配得比较合适,首先要对自己的组员有一定的了解,最好能量化,其次要把握好任务(这就看需求分析及系统设计的功力了),以下是我的一点经验,我把我的组员分类(简称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

Y

A     A+

Z

B     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个小时(很好组员都心不在焉,不过也可以理解,都辛苦一天了,晚上还要加班),还有周六、周日加班的话,很容易造成下周整个小组的疲惫,影响正常的工作效率(个人观察发现的结果,不知有同感吗?);不过发现上级很喜欢以小组加班与努不努力挂勾,看见小组加班就觉得很卖力(其实出的活很少,我统计过完成的任务量),像这种情况就做做样子做上级看好了。

 

 

上一篇:谈谈我的缓存(一)
下一篇:没有了
网友评论