艾伟也谈项目管理,工作感言:任务分配及管理

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

 

 

时间: 2024-10-23 04:59:18

艾伟也谈项目管理,工作感言:任务分配及管理的相关文章

艾伟也谈项目管理,产品版本改造中的项目管理

近段时间,一直在负责一个产品版本改造(C/S系统进行B/S改造)的研发项目管理,在任务紧.时间短.团队成员又没有相关技术(Silverlight)背景的恶劣情况下,我带领包含我在内只有6个人员(5个研发人员,1个产品经理,产品经理在系统版本改造中主要精力投入到辅助市场部进行产品推广去了)的超小型项目团队,终于在公司给定的时间范围内完成了整个产品的版本改造.这其中经历了需求变更.技术风险.人员变动等诸多问题,项目任然取得了成功,这种使用新技术的试验项目能够取得成功不得不说有几分侥幸,更多的还是团队

艾伟也谈项目管理,我的项目管理观点

    公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面.我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得.我把我所要分析的内容大概做了一个讲义,也希望更多人能够参与到这个Workshop中.项目经理好做吗?      项目经理好做吗?好做!项目经理好做吗?不好做.不同的人.不同的态度.不同的方法,其结果也就存在有极大的

艾伟也谈项目管理,敏捷的坏态度

虽然所有软件开发的专业人士都会对这篇文章感兴趣,但是经理.CIO以及软件架构师会对它最感兴趣.这个话题可能会引起许多争议,但我写这篇文章是为了让你了解在敏捷运动中看起来正在日益增长的问题. 你为什么在这?敏捷不需要经理. 以前听过这种说法吗? 想象一下,如果你听到开发人员认为你这个职位根本就不应该存在,你会感到多么震惊,就好像是你特意为自己搞出经理这么个职位似的.这个话最常应用在项目经理第一次与将要和他一起工作的开发团队碰面的时候.的确,最初的敏捷宣言绝对没有提到项目管理,并且后来的敏捷理论家更

艾伟也谈项目管理,软件研发中的冲突及解决之道

深圳易方数码科技新技术研究主管,微软MVP时永安认为: 软件项目在研发过程中牵涉到很多利益相关方,这些相关方因为关注角度的不同,会产生很多矛盾冲突.这些冲突,轻则打击士气,拖延项目的进度,重则使项目无法正常进行.在我这些年的软件项目管理工作中,遇到过各种各样的冲突,其中最常见的有:项目开发周期的冲突和团队内部人际关系的冲突. 软件项目的研发周期,本来是应该根据项目工作量和开发人员情况来估算的.但现实中,往往会受到市场部门以及公司高层的干涉.他们从产品销售的角度考虑,希望软件产品越早发布越好,在他

艾伟也谈项目管理,项目经理要如何看待技术?

当上项目经理后,技术人员往往对自己的定位失去了感觉.其中最令人困惑的就是自身原有的技术标签,撕了也不是,因为技术还不能丢,贴着也不是,因为个人的成败往往决定于自己对团队的管理,而不再是自己的技术. 想要从这种困惑中摆脱出来,首先就要搞清楚下面几个问题: Question 1--项目经理职位对技术到底有什么要求? Answer: 想把项目管理工作做到点子上,两个观点要明确: ①技术不是必须项.项目经理个人技术很重要,但这不属于必须项,属于有了更好的东西,当然越高越好.因此,在工作中,固然出任项目经

艾伟也谈项目管理,五年Skype架构师之路的感言

简介 作为架构师和设计者,我们常把手头的事情作为工作焦点,很少反思过去如何.我们应该温故而知新.我从作为skype架构组领导的55 个月经历中总结了6个经验.其中一些是技术性的,另外一些是架构师较为软性的观点.首先介绍一下Skype的背景资料. Skype背景 Skype是让用户可以进行音频视频通话的软件,也可以拨打普通电话以及发送短消息.公司成立于2003年,从成立以后就有令人难以置信的成长曲线.公司现在有超过五亿两千万注册用户,大约650名员工.这些用户同时产生平均21万个通话,其中大约三分

艾伟也谈项目管理,较大型项目的产品工作心得

最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目.从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享. 立项前 1.统一元素设计需考虑周全 也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲. 哪些元素应该做到统一? A.提示方面:统一的操作成功/失败提示:统一的弹窗形式:提示语言采用较统一的句型:为空情况的友好提醒:溢出情况的友好提

艾伟也谈项目管理,让亲身实践者执行工作流程

文 / 黄易山 在这里,我使用"工作流程"这个词来描述"个人或团体为了完成一项活动而遵循的步骤"意义上的流程,以及组织的一般制度.随着一家公司的成长,有必要增加或整理工作流程. 最重要的利弊权衡通常是工作流程所带来的阻力,以及效率或效益上的收益孰轻孰重. 一方面,很难评估这种权衡中的利弊,因为其中牵涉到很多因素,所以有一条可能会有帮助的原则:只允许那些有特殊需要的工作流程被执行,而且要由那些直接使用它的人来执行.通常,经理和管理人员会提议工作流程,因为它会帮助他们更

艾伟也谈项目管理,对项目管理的几点认识

自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目.中国有句古话叫"旁观者清",同一个问题站的角度不同,可能会形成不同的结论.下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正. 1. 团队成员选择 人员选择要谨慎,要尽量选择合适的人员,在选择团队成员时要重点考虑其团队合作能力.编码可读性.能力和项目的匹配度等因素. 2. 项目远景的确定 项目初期项目经理需要和高层以及客户协商,定下项目的远景目标(即