首页 > theory > PM > > 正文

绩效考核与任务分配—项目管理

发布人:zhoulujun    点击:

项目管理最核心的方法就是对程序员的工作进行有效考核!问题的关键就转变成如何公平的衡量工作量。我觉得,越精细化,越有可能实现公平。

创业泡沫的“军功章”,高薪低能的程序员分一半》里提到两个观点,我都是很赞成的:1、编程日益简化;2、程序员可以更多的把时间花在编码和思考架构上。我觉得这是个好事情,而且也是社会发展的必然。任何一个行业的蓬勃发展,都需要高度的专业化分工,以及随之而来的大量的熟练产业工人。我感觉过去的几百年工业史可以简化为下面这个模型:

  1. 少数天才发明了机器,赚了大钱;

  2. 更多的天才涌入机器制造行业,也开始赚钱,

  3. 机器越来越多,带动了机器的使用、维护、再制造等一系列行业,整个产业开始繁荣;

  4. 产业的繁荣需要更多的人手,不断的吸引人才的加入,直到人才不够了。

  5. 这时候,聪明的天才们开始了两条道路的探索:

    • 用机器制造机器,减少的人工的使用(现在很多行业都已经是大量的使用机器人了,你看诺大的车间就没几个人,全部是自动化)

    • 将机器的制造、使用、维护……变得更加简单,哪怕是个蠢才培训一下都能干活(流水线作业,想想卓别林的《摩登时代》吧)

大家对比一下吧,软件行业今天发展到哪一个阶段了?人类社会的发展,是一个永远加速的过程。我很好奇,在我有生之年,能不能看到“程序员就像狗,满街都在走”的奇幻世界。

程序员这个行业,是有门槛,但门槛不是那么高不可攀的。而且随着技术的发展,这个门槛会越来越低。

就像很久很久以前,拜师傅做徒弟学门手艺,入门都得三年;你看现在,把一个农民培训成一个流水线上的产业工人需要多久?我大嫂勉强初中文化,一直带孩子卖票之类的直到40岁,进厂做工人,培训了两个星期,现在还是个小头目。当然,她的工作没什么技术含量。但就算是开车床学挖机,技校培训,连实习上岗,也就最多两年而已。软件行业有什么不一样的?别扯什么算法编译二进制啦,开车床的还需要研究电磁场原理?

所以,这对准备自学成才的同学来说,是个好消息;当然,对已经身处其中的同学来说,那就相当的不妙了!

我这种言论遭到了围攻群殴,其中一个同学留言,“你这样就只能招到流水线工人!”

“咦?!”我拍案叫绝,说得太贴切了!对于绝大多数程序员,你不就是一个流水线上的工人?软件工程师?产品经理还是经理呢!很伤自尊,但我觉得这就是真相,虽然很残酷。

Sorry,跑题了。我是个奸商,所以我着重谈一下,作为用人单位,或者项目管理者,如何利用这种形势吧。


鞭子

还是很多年前,记得有一次,我和黎叔一起去他的工地。他的一个侄儿在工地上帮他看现场,见黎叔来了,就要卖力一些,戴着安全帽夹着一个小包,在工地上走来走去,还不是吆喝两声:“用心点!”,“你这里搞快点!”,“这里这里,来个人……”黎叔看了一会儿,走到他跟前,对他说,“你还差个东西啊!”他很迷茫,就去摸他的安全帽。黎叔笑眯眯的接着说,“你还差根鞭子在手里!谁做得慢就给他一鞭子,是吧?”我在旁边想笑不敢笑,差点憋成内伤。

但这些年来,我自己开过公司,也待过很多家公司,这个场景却让我记得越来越深刻。我经常不由得想,管理者手里究竟有没有拿着“鞭子”?该不该拿着“鞭子”呢?

拿着鞭子,凶神恶煞,“谁做得慢就给谁一鞭子”的监工形象,来源于各种影视作品,讲的肯定是古代的事了。但时至今日,有形的鞭子早就没了,但无形的呢?各种KPI考核、扣奖金、裁员……没有这根鞭子,员工还能好好干活么?估计很难,我们国家改革以前的“大锅饭”,甚至我待过的一些赫赫有名的外企,“大公司病”里最重要的一点,被管理者偷奸耍滑混日子(或许都包括我自己,呵呵)的越来越多,一个重要的原因就是管理者手里没权,没有“鞭子”。

胡萝卜

但“鞭子”慢慢的退出历史舞台,除了文明进步、日益严格的劳动法律法规以外,我觉得最重要的原因,还是管理者发现:“胡萝卜”比“鞭子”更管用。

历史的发展似乎也印证这一点。按主流的说法,最初,我们实行的是残酷的奴隶制,监工手里拿着鞭子使劲抽;后来,封建社会,地主们就聪明了,多少地收多少租子,农民多劳多得,这就把农民的积极性给刺激起来了。其实,仔细想想,还真是这个道理。第一、“威逼”是有成本的,而且这个成本不低,至少监工要吃饭吧?第二、发自内心的驱动力是无比强大的,被人推着走和自己撒开脚丫子往前跑,完全是两个概念。这个,对比一下改革开放前后“包产到户”的效果就一目了然了。

还想到了一个例子,以前我们都说金字塔是奴隶们修的,后来西方有考古学家就说了,“不对,奴隶做不了这么精致的活。应该是自由工匠做的”。还有很多考古证据,我是外行,但想想这个推论,其实是很有道理的。

误区

综上,很多管理者就把“威逼利诱”当成了法宝,奉行“赏罚分明”;俗一点,“打个巴掌,给个枣吃”。但这样有用么?我觉得,有时候有用,有时候没用。

先说说没用的时候。首先,如果我是被管理者,就会很抵触这种做法。凭什么打我一巴掌?稀罕你这颗枣子呢?把爷当傻子耍?去你妈的!不要把别人都当傻子似的,利益面前谁都不傻。其次,这种行为会造成管理者和被管理者之间的复杂博弈。简单点说,就是勾心斗角阳奉阴违。你以为你在玩他,他其实悄悄在玩你,搞成了宫斗权谋,一片乌烟瘴气。

很多公司试图从“企业文化”这个角度来解决这个问题。试图把这些问题柔化掉,大家一起吃吃饭,沟通一下,喊两句口号,树立一致目标之类的,但以我的观察,都是缘木求鱼而已。上下级矛盾、部门扯皮,矛盾的根源没有解决,只是让大家谦恭忍让,忍得了一时忍得了一世?相反的,矛盾只会越积越深,直到崩盘。

公平

奖惩能够真正产生正面效力的基础是公平。这一巴掌该打多重,这颗枣该有多甜,标准是什么?这个标准是不是公平,才是问题的关键。

这一点,我觉得都没什么必要论述,但很多管理者往往遗忘甚至有意识的忽略它。受某D的影响,很多人还把劳动关系看成剥削关系,他们认为,“向管理要效益”就是多剥削一些员工的血汗钱。给你3000让你干5000的活就是我赚的,再搞个绩效考核,扣你200,晚上睡觉都乐醒。这种思路,不属于本文探讨范畴,我觉得这其实不是主流。更常见的情况是,管理者觉得自己被坑了,我发了这么多工资,你究竟有没有干这么多活?

这种顾虑的根源在于“计时”工资。这就和奴隶制时代很相似,你干一天的活,我给你一天的吃的。但问题在于,你是不是认真“干活”了呢?这就太难以衡量了。所以什么指纹打卡、装摄像头之类乱七八糟的管理方式就出台了。而且,从管理者的角度,还有一种潜意识,我给你8小时的工资,你就得干8小时的活,水都不喝一口这个要求过分了,但你躲在厕所抽烟我就接受不了。所以我看到新闻,某工厂每天上厕所次数不多于三次,每次不超过15分钟的奇葩规定就出来了。作为员工,尤其是现在的年轻一代,哪里还受得了?据我观察,一天8小时,能认认真真干4个小时的活就不错了;能干6小时的活,那绝对是优秀员工楷模了;干满8小时,那是绝对不可能的(加班除外)。

所以,在计时工资的框架内,管理就转变成了“如何在单位时间内提高员工工作效率”的问题。出于人性的贪得无厌(资方)和好逸恶劳(工方)考虑,这注定将是一场斗智斗勇难解难分的大混战。

计件

在工业时代,工资支付方式的革命就是“计件”——按工作成果而不是工作时间来支付工资,这无疑是最公平最符合人性最具有激励作用,所以也就是最好的制度。这已经被无数的人类实践所证明,90后没经历过改革开放之初农村家庭联产承包责任制,后来的国企内部承包改革等一系列重大事件,我们亲身经历,那种改变,真的只能用一个词来形容,“天翻地覆”!地还是那块地,人还是那些人,以前一个个饿得皮包骨头,现在家家户户吃不完的粮食,为什么?就一个简单的制度改变而已。

但问题在于,程序员的工作很难计量(其实所有行业都一样,好计量计件的,早就按计件支付了,剩下按工作时间支付的,都是难以计件的)。靠代码量来计算?懂行的就知道这明显不科学。有些单位靠功能来划分,这稍微科学点,但还是失之于粗糙。某加班的程序员不满了,“艹,他凭什么就下班了?他的功能明显要简单得多,就看见他在玩游戏!”下班的程序员不爽了,“是我有本事,好吧?你自己磨磨蹭蹭的搞不出来……”


这里的计件,还包括内部承包、销售提成等一系列非“计时”支付方式。这几乎是解决上述问题的灵丹妙药。对于管理者来说,减少了一系列的管理成本;对于被管理者来说,摆脱了被监视督促的困境,可以自由的安排工作。更重要的是:公平!一旦达成协议,双方按约履行,多干多得少干少得大家心服口服。所以,其实看看周围,差不多能计件的,都计件了!

剩下的,就是一些确实不好计件的。软件开发,在很多人看来,恰好就是这种不好计件的工作。

难以计件,不是因为工作本身很复杂,需要特殊的难以掌握的知识技能等,而是工作本身能否简单的被计量。一般来说,工作越简单越容易计量,比如建筑工地上砌砖墙,工作简单,计量也简单,直接用面积/用砖数量计算就可以了。但一些看上去很复杂很高科技的工作,一样可以计量,比如医生动手术,够专业吧?一样可以用手术类型和时间计算,切胆结石手术一次用时3小时,就OK了,可以计件算报酬了。据我所知,挂多少号做多少床手术,这些都是和工资奖金直接挂钩的。但一些简单的工作,却没办法计件只能计时,比如餐馆迎宾服务员,怎么计件?鞠了多少个躬收了多少盘子?

那么回过头看程序员的工作呢?只能是“做一天和尚撞一天钟”?只能“吃大锅饭”,没办法多劳多得少劳少得?

切分

说任何复杂的事物,过于绝对,但大部分的软件开发工作,其中大部分的内容,其实是可以切分成一个一个简单任务的——简单到可以比较准确的计算其工作量。

切分的工作,其实我们都有意无意的在做着。一个项目,只要是多人合作,必然要进行切分,你做什么他做什么,都有个分工,不可能一拥而上吧?但有的切分是依据程序员的岗位或技能进行的,比如张三做前台、李四做后台;有的切分是按任务量来切分的,比如张三做甲功能,李四做乙功能。因为本文主要谈任务切分是否公平,所以我们着重讨论“按功能切分”,这种切分主要的问题是不够细,粒度太大。

假设两个功能点,核算都是14个人天的工作量,直接分给张三和李四,张三和李四会不会觉得公平,服不服?我估计最可能的情况是他们自己都不知道!里面可能出情况的地方太多了,所以他们其实是硬着头皮接下这个任务,因为他也不知道这任务的工作量是多少!大家都只有拼人品了。但总是这样做也不是个事儿,尤其是在任务重工期紧的时候(前期大家可能都悠哉乐哉的玩儿),矛盾很容易就爆发出来:

加班的先嘀咕了,“艹,他凭什么就下班了,我就要加班?”

项目经理解释了,“他的功能已经完成了呀!”

这时候不服了,“他的功能明显要简单得多,就看见他在玩游戏!我的功能多麻烦多复杂……”

然后摆事实讲道理,这里原以为怎么怎么,结果怎么怎么,要是里面还有点需求变更,就纯粹一堆烂帐了,谁说得清楚?

项目经理一般就只有投降了,“那张三,帮一下李四吧,特殊情况!”

一次两次就算了,但可能只是一次两次么?谁人品那么好?最终下去,两种情况:1、这次你帮我下次我帮你,帮来帮去帮成“大锅饭”;2、有人能力不行或偷奸耍滑,长期要人帮,老实人吃亏,怨气积累直到爆发。无论哪种情况,项目经理都是大眼瞪小眼无可奈何。

精细化

所以切分一定要切分到可控的粒度为止。任务太大,30个人天确实不好估计;但30分钟以内能完成的任务,应该心里有数没什么争议吧?根据我的实践经验,我一般会把任务切分到20分钟左右的粒度,最多不超过60分钟。在这个粒度范围内,任务已经相当的具体,可以说是胸有成竹十拿九稳。

按照这种模式,我们就有可能形成精细化的管理实践。而越精细化,就越有可能实现公平。就像买卖交割,一只羊43.78千克,每千克46元,合计2013.88元;其公平性肯定远高于以物易物式的谷子一堆。当然,你可能会说,只要双方你情我愿有何不可?但事实是,如前文说分析,基于人性的贪婪和计较,双方很难你情我愿,所以大而化之的以物易物现在几乎已经绝迹了。

成本

有同学感到疑惑,如果任务要切分到这么细,是不是项目经理一天到晚就划分任务去了,不用干别的?这个问题我们从两方面考虑:

第一,任务切分这个成本是必须的。比起切分任务,写设计文档才是“浪费”时间呢!我在实践中,至少发现了切分任务的以下这些好处:

  1. 能够真正的厘清功能和任务实现。在切这个任务的过程中,以前朦朦胧胧的概念,才一点点的清晰起来。

  2. 能够“纠错”。清晰过后,一些疏漏错误也就自然而然的暴露出来了。可能以前以为是2小时就能完成的工作,进行切分之后,才发现漏了一些功能点,把实现想得简单了一些之类的,自己就要适当的调整开发进度。

  3. 对开发人员有指导作用。我用的都不是高手大牛,但他们新人也可以顺着这个路子一步一步的做下去,至少其中一些简单的部分可以分给他,复杂的留给我自己做。

  4. 开发人员偷不了懒,但比较服气。不是每一个任务时间都估得那么准,如果你估多了,开发人员偷着乐就是了;估少了,他完全可以提出来。因为任务已经被切得很细很小了,他一提出来什么什么情况,你马上就能反应过来,任务量就相应的调整就是了。

总之,切分完任务,对这个项目,基本上就心中有数胸有成竹啦。作为管理人员,作为领导,威信就建立起来了。而不是稀里糊涂的把任务布置下去之后,下面一问三不知,错漏百出。一次两次问题不大,次数多了,下面的人不服,“聪明”点的就开始动心思糊弄了……

第二,可以采用“从下往上”垒的方式。如果开发人员值得信赖,你也可以让开发人员自己进行任务切分,你在任务验收时同时核查任务的工作量。因为代码都已经提交review了,这时候的工作量已经是挺好衡量的了。开发人员一般也不会乱来。但这里有一个小问题,就是开发人员开始可能会抵触这种做法。他们会认为切分任务和写文档、写注释、写日报周报一样,是无用的工作。

说说我是怎么处理的吧!我拗不过他,就随他的便,但只有一个要求, 你先把你要花多少时间告诉我。他说行,比如一个功能点,他信心满满的说,“120分钟够了”。结果够个屁!哈哈,他两天都搞不出来,想加时间,我不干了呀,你加时间的依据在哪里?我知道是因为任务在做的过程中变复杂了,但东一榔头西一棒,他怎么说得清楚?搞得他焦头烂额之后,他自己去体会。多尝试几次之后,同时随着他技术的逐步提高,最后他也养成了做之前,先切任务的习惯。其实切任务就是一个理思路的过程,做之前思路清晰了,事半功倍,“磨刀不误砍柴工”说的就是这个道理。

其他作用

我们是由着“计件”这个话题谈到任务切分的,但实际上,即使任务切分,让程序员拿计件工资,我觉得现阶段还是不现实(鼓励大家多尝试,我有机会也试试)。当初我们公司开发人员入职,我给他们讲的都是计件,但实际上还是按月发大致固定的工资。但是,通过任务切分,我们可以做到以下几点:

第一、合理的安排人手。项目成员中水平有高有低,新人都有一个成长的过程。任务切分之后,像剔骨头一样,嫩肉给新人菜鸟,硬骨头给老人高手。这样,项目组才更具有效率和活力。你把简单的重复性工作给高手做,纯粹是让千里马犁地,浪费啊;把复杂的扔给菜鸟,他百度google,半天弄不出来也是浪费时间。但如果没有切分,难的简单的混在一起,区分不出来啊!

第二、有理有据的绩效考核。距今为止,我所见过的所有绩效考核,基本上都是扯淡。在无法量化的情况下,其唯一的作用就是无事生非,破坏安定团结的大好局面。你说他这个月绩效打80分,凭什么?他加了班?加班应该给加班费啊!代码出了bug?谁的代码没bug?都没bug要测试干什么?可能最大的原因是他和你顶了嘴?你看他不顺眼打击报复吧?所以最后基本上两种结局,要么弄得鸡飞狗跳,要么稀里糊涂一锅粥。

但我有了任务管理系统的记录和统计,每一周每一个月我把数据拉出来,明明白白的告诉他,为什么这个月多给,上个月少给,他基本上也认同。这里必须要说一下,工作量(时间)不是他实际完成工作的时间,而是我认为一个普通程序员(其实就是我啦)完成该工作的时间。比如我给这个任务20分钟,是指我能在20分钟完成,你哪怕花一天才搞出来,那是你的事!不然,你每天的工作量都是8小时,有什么意思?然后根据工作量,就可以统计出来你的绩效了。当然,任务是有难度划分的,还可 以包括很多其他因素,比如:验收不合格的比率、按时完成任务的比率等等,这些我们以后再谈。

第三、清晰准确的项目预算。我做开发七八年了,我从来没看到过一份清清爽爽的软件项目预算。都是做工程,比如建筑工程装饰工程,根据图纸,材料人工,一项一项的清单报价,不管多大的工程,价格算出来都是精确到分的,比如1080732.76元。但软件开发,合同能精确到百,都不错了,一般都是20万、3500,感觉在价格就是随口喊出来的一样。工期也是一样,建筑工程,误了工期,时间稍微长一点,违约金赔都赔不起。软件开发,延期延期再延期,才是常态,是吧?即使勉强交货,那都是蒙人的,里面bug一大堆,先交了货,再慢慢“维护”吧!

这个问题的根源在于,项目负责人对项目的细节没有切实的把控。只能凭着“经验”或者“想象”来大致的“估算”项目的工作量,而事实证明,这种估算是相当不靠谱的,由此而产生大量的纠纷。据我观察,一般只有小项目,才会采用按项目整体计价的方式发包;规模稍大的项目,如果双方都有一定的行业经验,通常是用外包人天事后核算的方式结算。按实际的人天结算,其实并没有真正的解决预算的问题,发包方一样需要预算啊!项目会花多少钱,该什么完工,心里一直没数。再说了,你外包过来的程序员究竟有没有认真干活,是不是在混日子,谁知道呢?

第四、应对需求变化。可能有这样一种想法:我花了大量的时间精力,事先把任务切分得清清楚楚,并据此做好了所有预算,但需求会随时改啊,最后还不是改得一塌糊涂?所谓“计划永远没有变化快”。其实不是这样的。如果你的计划是一个不可分割的整体,犬牙交错,牵一发而动全身的那种,那么当然,每一次改动都是一次伤筋动骨的大折腾。

但通过良好组织的任务切分,改动就可以被有效的对应到相应的计划部分。这时候,“有计划的变化远胜于无计划的变化”,因为每一次的改动就是一个局部的改动,是非常容易被重新计量评估的。比如,某次改动,会影响原任务3098-4012,原任务3876-3879,任务量共计480分钟;改动新增任务5678-5894,任务量共计300分钟;所以任务总量减少180分钟,非常清晰。

当然,我们还有一系列的措施应对需求变动。但良好的任务切分,具有基石般的重要作用!