精华内容
下载资源
问答
  • 绩效考核)电大本科JAVA技术形成性考核册作业答案(最新) 电大天堂JAVA技术形成性考核册答案 注本答案仅供参考如有错误敬请指正 来源电大天堂/forumdisplay.php?fid=2 电大天堂JAVA技术形考作业壹 壹填空题 面向对象的...
  • 小型软件公司的绩效考核 近几个月,我常和一些朋友讨论如何在小型软件公司中对软件开发人员进行绩效考核的问题,发现很多朋友都为此问题而烦恼。由于我正好在一家小型软件公司里负责绩效考核工作,有一些成功的实践...

    小型软件公司的绩效考核

     

      近几个月,我常和一些朋友讨论如何在小型软件公司中对软件开发人员进行绩效考核的问题,发现很多朋友都为此问题而烦恼。由于我正好在一家小型软件公司里负责绩效考核工作,有一些成功的实践经验,所以特此在这里与大家交流一下我的心得。这些心得可能仅限于小型软件公司,因为某些方法只符合小型软件公司的特点。如果你在一家大型软件企业里工作,那么这篇绩效考核的文章可能与你无关。

        我这里提及的小型软件公司是指50个人以下的公司。因为从工业和信息化部提供的软件企业数量以及从业人员数量来推算,50个人的软件公司应该算是小公司了。而从《2007中国软件自主创新报告》里我们得知,在本土软件企业中,拥有50名员工以下的企业占60%。在这样的比例之下,解决如何搞好小型软件企业的绩效考核,提高企业竞争力的问题相对于大型软件企业更具有社会意义。实际上,小型软件公司相对于大型软件公司,更缺乏的是绩效考核,或者说是缺乏可量化的绩效考核方法。

    组织模式

        首先,工作如何量化?这取决于公司的组织结构。不同的组织结构导致了不同的工作量化方式。小型软件公司一般是小项目/小组织的特点[1998年软件工程过程改进小组(SEPG)会议对“小”做了定义。“小”被定义成“5个或更少的人进行为期3至4个月的开发” ],小型软件企业里十之八九都是项目型组织结构。比方说:A公司有15个工作人员,又有4个项目并行,最常见的就是分4拨人(每拨人包括项目经理、程序员、测试员)。表面上每个项目都有一个责任明确的“包工头”,最高领导者很省心。其实不然,项目做下来省不了多少心。一会儿报告来不及做,一会儿报告说跳槽了,一会儿客户来投诉质量太差。而且,这样的人力资源利用率是否最高呢?其实更不然,撇开每个项目经理管理的能力差异(项目经理管理能力差异很大导致团队产出差异也很大)不提,每个项目组里的某段时期里中总有人空闲。我们企业改变这一现象的办法就是:把企业的组织模式改为职能型组织结构。这样一来,A公司有15个工作人员,4个项目并行,也仅有一个团队。其中有1个职能经理,4个项目经理,3个测试人员,7个开发人员。对于团队负责人职能经理来讲,人力资源的使用情况一目了然。

        有朋友提出:一个人在多个项目里“切换”,但人不是CPU ,不是多任务的,频繁切换(即使是一周换一个项目)会降低效率。可事实证明是可以“切换”的,甚至可以频繁到一个人一日多项目。就拿我们公司9月份来说,有14名员工“切换”在12个项目里(有的项目还在继续中,其中3个是较大的项目),所以,毋庸置疑“切换”的可行性。实际上,在小型软件企业中推行职能型组织管理,只需要改变一下领导者的管理理念和支撑的管理平台(后文中会有所提及)。

        职能型组织的特点就是提高人力资源的使用率,对缺乏人员的小型软件公司来讲这一点非常的重要。当然,职能型组织模式还有其他管理优势。职能型组织趋向于“机械式组织”,它有利于专业化管理,有利于组织稳定,有利于集权化和正规化。如果企业做的项目规模比较小,并且是以非创新技术为重点的项目,那么“机械式组织”有利于创造高效率和低成本。

    团队建设

        组织模式确定之后,接下来就是团队建设。首先,我们要定义工作角色。有了角色,职权就能定义了。通常的角色有项目经理,程序开发,数据库开发,测试,技术支持等。由于采用的是职能型组织结构,所以项目经理的主要任务就是接受客户需求,进行设计和任务分解。项目经理对于项目的管理权利是非直接的,而是由职能经理负责这方面的工作,由他来决定哪些人做哪些事情,并要求何时完成任务(真正的实权在握)。

    开发流程

        我们从组织模式谈到团队建设(定义角色),而这些都是绩效考核的基础工作。接下来就是一个重点, A公司怎么依靠1个职能经理,把15个人、4个项目运作起来?这个问题首先涉及到开发流程。凡是搞软件开发的人都知道,开发流程大致分需求分析、设计,开发、测试和部署环节。如果你在一家公司里,发现几个人包揽了全部环节,那么可以不用花力气搞绩效考核。因为公司所依仗的就是这些“牛人”,就像地方政府依仗缴税大户一样,大都是免检。活生生的例子就是三鹿奶粉,由于它维持地方财政税收,自然是“免检产品” 。那么如果要施行考核制度,就必须分环节和引入竞争。要把那少数几个“牛人”干的活,分成多个人来做。这样做有几个好处,从企业管理的难易程度上讲,多个人分工合作好于一个“牛人”独自做;从企业成本来讲,多个人的合计成本反而低于一个“牛人” ;从项目风险来讲,一个人一个项目的风险不言而喻;从个人工作强度来讲,专业分工更节省人力;从个人的职业发展来讲,做得更专业比做得泛泛的好。于是,这样对于企业对于个人都有好处。

        有了角色分工就能和开发流程对应起来。比如,项目经理要完成需求和设计工作;开发人员要完成开发工作;测试和技术支持人员要完成测试和部署工作。那么,如何把大家的工作贯穿起来?我们是通过任务单。设计人员必须完成含有设计说明,预估完成工时等信息的任务单。职能经理分派任务单给相应的开发人员和测试人员。任务的分派过程由管理平台支持,职能经理基于这个平台,实现了职能型组织的管理。

        通过管理平台跟踪整个开发过程,管理者就可以统计方方面面的信息了,比如个人的能力系数,缺陷系数等等,到这里便可以开始真正的“绩效”了。那么具体都包括哪些信息呢?针对设计人员角色有每月完成的任务单数、设计总工时、估计总工时、相应的开发总工时、相应的测试总工时、相应的测试总次数、相应的缺陷总数、缺陷系数和周工作量系数等。职能经理可以通过设计总工时或者周工作量系数,来了解设计人员工作是否饱和,哪个人设计的缺陷比较多,哪个人效率比较高等信息。举例,A公司的职能经理,他可以知道手下4个项目经理每月的工作情况(这里的项目经理,其实更应该称为设计人员,因为有的时候可能只有一个真正的项目经理,另外三人在做设计工作)。数据累计一定量之后,便可以知道哪个人不能完成最低设计工作量,哪个人能力比较强了。

        设计完成之后,职能经理就可以派发任务单给开发人员了。设计人员对每个任务都有一个预估时间,对比开发人员的实际开发时间,可以得到一个能力系数。当然还有很多其他信息,比如开发人员每月完成的任务单数、相应的估计总工时、开发总工时、测试总工时、测试总次数、缺陷总数、缺陷系数等等。其中仅能力系数和缺陷系数两项指标就足够衡量一名开发人员了。另外,因公司而异,公司可能会有最低的开发工作量和缺陷率。通过统计,你会诧异的发现优秀的开发人员可比一般开发人员高出一倍产量,同时只有1/4的缺陷。这里要插一句,团队中的“南郭先生”会立刻显露无遗,而优秀的开发人员可以站出来大呼加薪了。

        当开发完成之后,职能经理就可以派发任务项给测试人员了。因为有详细设计文档,测试人员只要按照文档进行测试,然后把缺陷编号录入到管理平台中。同样,管理平台也可以评价测试人员的工作效率,比如每月所测的任务单总数、测试总工时、发现的缺陷数量等等。这样管理人员就能够了解测试工作量是否饱和,哪个人找缺陷最拿手。

        有些朋友问到关于管理平台方面的事情,比如成本。其实绩效考核的的目的是为了建设一个公平竞争的环境,找出业务水平有待提高的员工,让优秀的员工有相应的回报,让公司也能高效率的运作。对企业来讲,成本倒不是问题。因为采用了职能型组织之后,就会发现原来小公司内部还有那么多空闲时间(我们的管理平台就是在空闲中完成的);另一方面,如果工作效率提高了,产量增加了,三个月就能收回开发成本。举例,我们公司执行之后的月开发量提高了179%,2个月的工作量相当于之前3.5个月的工作量。

    再谈考核

        我们一直在讲 “绩效”,还没有谈到“考核”。公司光有“绩效”没有“考核”是不能提高工作效率的。如何建立奖惩制度也是一门学问,不同公司做法不同。《论语》中谈到:“名不正则言不顺;言不顺则事不成;事不成则礼乐不兴;礼乐不兴,则刑罚不中;刑罚不中,则民无所措手足”。这句话是告诉我们要如何做好绩效考核的。首先要名正言顺,有了良好的舆论环境才能立项做事,才能建立工作流程;有了工作流程,才能有奖罚标准;有了奖罚标准,员工就知道怎么做才是正确的。

    文/周群
    展开全文
  • 绩效考核

    千次阅读 2010-08-05 13:20:00
    <br />每年过年后的一段... 其实加薪的过程从时间上来讲,近则可以追溯到去年年终的绩效评级,远可追溯到过去一年甚至多年每个checkpoint的评价,从范围上来讲,是一个员工和老板之间,员工与员工之间,甚至

    每年过年后的一段时间内,便是一年一度论功行赏的时候了。

    年终奖一般设置在年前,而加薪设置在年后,却是一种蛮不错的设计,从而年前大家皆大欢喜,一片祥和,年后又带来新的一年的希望,并激起竞争的欲望。

    很多人在讨论加薪的时候,如何同上司或者老板谈方能获得更高的涨幅成为了一个热门的话题。

    其实加薪的过程从时间上来讲,近则可以追溯到去年年终的绩效评级,远可追溯到过去一年甚至多年每个checkpoint的评价,从范围上来讲,是一个员工和老板之间,员工与员工之间,甚至Team与Team之间的一个博弈的过程。

    当你走进上司的办公室谈话的时候,其实已经没有什么可以博弈的了,尤其是在流程相对规范的外企。因为高层已经根据每个Team的贡献分配可以加薪的份额,而在你的Team中,你所占的位置上司已经基本心中有数,况且去年的绩效评级已经基本决定了你的加薪范围,所以其实没什么好谈的,无非是优秀者褒奖,普通者激励,不足者抚慰罢了。

    当然还有一种情况可以进行谈,加薪一般分三种,原职位加薪,升职加薪以及跳槽加薪,如你在公司外有一个相对高薪的位置的时候,便有了可以博弈的另外的筹码,可以一谈,有的上司也许会多加一些薪水给你的,自然大多达不到公司外的薪水的高度,也是我十分不提倡的加薪方式,且留到后面跳槽一章详细说明。

    加薪的博弈其实从很早就开始了的。多早?让我们从入职说起。

    一、入职培训中了解绩效体系。

    入职培训中,除了描绘出的美好未来和一些令人激动的技术讲座之外,一个不容忽视的方面即HR讲述公司的绩效体系。

    而这又恰恰是新人容易忽略的方面,一方面大多认为合同已签,薪水已定,什么绩效,什么加薪是遥远的事情,一方面填表格,走流程实在是令技术人员头痛的事情,很多人宁愿花十分力气埋头苦干,也不愿出一分力气将其表述出来,多少有些到时候别人怎么填我就怎么填的从众心理。

    有的程序员清高的认为,自己的所做作为,绩效如何,上司和HR有责任清楚的知道,直到绩效反馈One on One的时刻,获得不合期望的评级的时候,才猛然发现,好钢竟然没有用在刀刃上。凡事预则立,不预则废,加薪要从娃娃抓起。

    绩效评价的方法多种多样,很少有外企单独的使用其中一种,往往是综合起来使用,而不同的评价方法有不同的注意事项:

    • 目标管理法:也即先制定目标,一定时期后review目标看完成情况的方式。如果采取这种方式,目标的制定和完成反馈就相对重要,下面我们会详细讲这个事情。
    • 关键绩效指标法:提取出岗位所需要的结果的,行为的,优势的,劣势的等等方面关键因素进行评定。则因素之间的权重就显得比较重要,这个权重不仅仅在HR的ppt上,也在你的绩效评定者的心中(也即HR觉得某行为重要不算重要,你的绩效评定者觉得重要才算重要)。崇尚按时来按时走还是加班加点?技术分享更重要还是问题解决更重要(多数情况下,给别人解决一个问题比介绍其一项技术更加让人感恩)?注重技术还是注重流程(有的技术大牛能力杠杠的,就是不愿写注释,写文档)?
    • 360度考核法:有的公司进行的是全方位的考核,如上司,下属,QA,同事等,有的则仅仅是上司及上司的上司。了解你的评级相关方,如何与他们良好的沟通,是非常关键的。
    • 强制排名或强制分布法:有的公司会对员工进行排名,或者按照很优秀,优秀,一般,差,很差几个等级进行强制分布。这是一种十分残酷的评级方式,也使得你能不能跑得过老虎不重要,能不能跑得过同伴更重要。如果很优秀的会有一个人,优秀的会有三个人,则第四名和第五名虽然从贡献和结果上来讲差别不大,然而对后来的薪资涨幅,升职,甚至股票等都有很大的差别,这就需要你时常通过沟通,了解自己在Team中的位置了。

    二、了解评级相关方

    了解了绩效体系之后,你就明白了给自己最终的评级将有那些人了。

    平时我们常常说顾客就是上帝,观众是衣食父母,而研发人员天天躲在象牙塔里,是几乎不会跟客户见面的。所以很多人认为客户导向这句话是销售人员的事情,与研发无关。然而从某种程度上来说,你做做的模块的调用者,测试你的模块的QA,你的下属,你的上司等等都可以算作你的客户,只有每个模块的客户都达到满意,则最终的产品才能让真正花钱的客户满意。所以日常工作中,如何同你的客户进行交流,让他们了解你的目标,进度,困难,成绩,优势,劣势,期望等,是十分重要的。

    然而人各有不同,对于不同的人的沟通方式也不尽相同。

    • 过程型还是结果型:

    结果导向和过程导向是两种不同的管理风格,是一直被争论不休的。

    中国的传统文化中原本是过程导向的,所谓的德、能、勤、技,中国人其实是更加注重过程中表现出的德、勤两个方面的,从较早的举孝廉到后来的以四书五经为纲的科举制度,都表明了过程中表现出的操守要胜于最终建立的功业。从民间崇拜的对象,我们也可以看出,相比于百战百胜的卫青霍去病,人们却更加崇拜投降曹操又过五关斩六将的关羽,相比于辅佐刘邦建立大汉王朝的萧何,人们却更加崇拜六出祁山但未能成功的诸葛亮,相对于帮助秦国强大的商鞅,人们却更加崇拜周游列国知其不可为而为之的孔夫子。

    近代外国现代管理思想的引入,使得以过程为导向的方式迅速向以结果为导向的方式转变,老板们多喜欢说这样一句很酷的话:"不要给我说过程,我要的是结果"。后来,随着企业发展,人们又越来越发现如果只关注结果,则会造成企业的短视和部门间合作的问题,对于整个公司来讲,如果只为公司的股票和市值负责,在有线电话有巨大利润的AT&T自然不用关心无线通信的发展,所以成就了摩托罗拉,在大型机及硬件方面有巨大利润的IBM自然不用关心一份软件的license能赚多少钱,所以成就了微软。对于部门来讲,如果仅仅关注本部门的结果,又有谁关心部门之间的空白地带呢?

    所以后来,人们发现如果不能很好的控制过程,则多半不会达到预期的结果,不但要注重结果,也同样要注重员工的激励和思想行为的培养,从而发明了平衡记分卡等方式,从单纯的绩效考核上升到绩效管理的高度。

    其实不仅是管理,结果型和过程型也是人的做事风格之一。当你描述一件自己做过的事情的时候,结果型的人往往会先问事情的结果,对于最终成功的,则过程中的一切便被解释成为正确的,可以理解的,至少是不得已的,而过程型的人则会仔细倾听事情的来龙去脉,并点评和探究其中的点点滴滴。

    结果型的人多喜欢财富,权力,成功学等方面的知识,并力争成为这方面的专家,而多不屑例如考古挖掘,红楼梦探轶,农民兄弟自己发明飞机等类似的事件,过程型的人自然也喜欢钱,但同样对不能带来利益的神秘过程感兴趣。

    结果型的人多喜欢竞技类的游戏和运动,且往往是高手,在乎每一次的输赢,如羽毛球,乒乓球,篮球,足球,网球,象棋等,过程型的人也会在上述游戏中乐在其中,但更喜欢游泳,唱歌,旅游等非竞技类的活动。

    所以在工作中,项目规划的时候,对于结果型的相关方,则应该定下明确的目标,如测试用例覆盖度,性能指标等,而对于过程型的,除此之外,方案的评审,也即你将如何达到既定的目标,同样是很重要的。在项目的进度安排中,对于结果型的相关方,主要设定重要的checkpoint点就可以了,至于学习什么,研究什么,帮助他人做的职责外的事情,请自己留buffer,而对于过程型的领导,这些可以写入时间规划。在项目执行过程中,对于结果型相关方,多汇报进度,如遇到困难,则应有证据证明存在的问题,并估计其对进度的影响,对于过程型的相关方,还可以描述问题的原因,探究及可能的解决方法。在项目结束的时候,对于结果型的相关方,一份详尽的报告逐一用数据表明达到目标很重要,对于过程型的,还可以发起一个knowledge sharing,分享项目中的难点和解决。

    • 视觉型,听觉型还是感觉型:

    不同的人感知外在世界的方式有所差别,大概分为此三种,当然人们都是这三种类型的综合,只不过更多的偏向于某一种而已。

    视觉型的同事常打印出一部分书籍或者文档,并边看便在空白处或者本子上写写画画,画出思路图,或者标出过程的一二三。其学习技术的方式倾向于看书而非看教学视频,因为看书能够很快的跳过各种废话,直奔主题,当然如果书籍能够形象直接的提炼出要点,则将十分欣喜。和他人沟通,首选用邮件或者文档的方式,写明要点,并附上详尽的框图,其次是到会议室中,把框图在白板上画给你看,最不爱采用的,就是电话的方式。在开会的时候,其喜欢坐在能和会议的举行者可以目光交流的地方,而不是角落里,其似乎随时准备上台提炼出演讲者的一二三,或者把过程画出流程图。

    听觉型的同事也喜欢看书,但是在其觉得重要的句子下面画波浪或者下划线是常用的方式,在其看来,作者的文章字字珠玑,所以划线的地方非常多。其注重细节,相对于视觉型的人,其掌握架构的速度有些慢,然而一旦掌握,将成为此方面的专家,对方方面面都有所了解。其学习技术倾向于看视频,会不厌其烦的一字不落的听着讲座的每一步,相比于看书,讲座者的语气强调更能给他带来深刻的印象。与他人沟通,电话是其最喜欢的方式,简单直接,且能听到对方的语气,开会其次,如果使用邮件或者文档,将写的非常仔细。其开会的时候往往会坐在非中心的位置,相比于视觉型的人,你可能觉得他似乎不太积极,然而后来你会发现,其对会议的很多细节在较长时间后仍能够清晰记忆,"我记得你在一次会上曾经说过"。如果其是会议组织者,其技术讲座,技术方案都会详尽到代码级别,开会超时是经常的事情,如果视觉型的是其领导,将会在其ppt中删除大量的涉及代码的细节,换以图片,这将使其心疼不已。

    感觉型的同事相对喜欢看原书,而非打印稿,如果其觉得书不错,比较倾向于买一本属于自己的书,尽管图书馆,公司,同事的书可以供他无限期的借阅,觉得自己看过的书再次查阅的时候比较容易找出需要的知识。其不太喜欢仅仅讲述理论的书,如果有实例,做上一做,方才有感觉。如遇到问题,尽管从理论或者他人的经验即能推出结论,其还是愿意写个程序加以验证,真正输出结果,方才放心。其接触过的问题,大多真正的实际做过,其经验比较可信,然而其却不太相信他人的经验。其往往不是某一方面的专家,然而经过长时间的工作积累,只要是做过的部分,多有十分扎实的经验,能很快的帮助他人解决问题,或者提出十分可靠的技术方案。与他人沟通,来到他人的座位上是经常的。在讨论接口或者方案的时候,多能够体谅他人的感受,也无形中自己默默的多做了很多事情。

    所以对待视觉型的人,邮件中列明要点,附件一个ppt文件,是其最喜欢的方式,ppt既条理分明,又能够画图。如果还有其他的参考资料,可另行附上,如有多个,最好表明每个参考资料和要点中的哪一点相关,否则很有可能被忽略。如果对方是听觉型的,可以先发一个带有详细信息的邮件,然而一定要有一个电话或者会议与其进行沟通,通过语气或显式强调邮件中那些是最重要的,那些是次重要的,否则其在浏览中提取出的重要信息可能偏离你的预期。如果对方是感觉型的,则走到其座位上是最好的沟通方式,拍拍肩膀是很好的表达友好的方式,相信他的经验,如果欲使他相信你的经验,则需要准备足够的证据,有时候认同比争论更容易让其同意你的观点,多体谅他的感受,情绪控制十分重要。

    • 技术型还是管理型

    所谓技术型和管理型,其实很少有领导完全只懂技术,不懂管理,或者只懂管理,不懂技术,所以将技术型和管理型分为以下几类:

    第一类:使用相同类型技术做过相同类型产品的管理者。

    比如要使用Java技术搭建一个搜索引擎系统,如果项目管理者原是做过此方面的,则此类是程序员最受欢迎的管理者了。

    由于其对此项目的整体架构,模块划分,技术难点等十分清楚,因而在项目规划过程中,能够相对精确的把握时间进度,需求变更,在项目设计的时候能够进行较好的人员,模块,接口的分配,在项目执行过程中,能够及早的提醒可能出现的问题,并在出现问题的时候帮助员工解决,在项目测试阶段,能够把握测试指标和要点,项目结束后,对各个子模块,各个人员的绩效的评估相对准确。

    只要比较有心,此类的管理者可以说是明察秋毫的,除了遇到困难请求帮助外,程序员多可静下心来默默的做自己的程序,可以少去很多不必要的沟通,因为只要最后成果一展示出来,只要稍加描述,此类管理者便大概能把握使用了那些技术,会经过那些难点,有多大的工作量,程序员多不用担心自己的成果或者辛勤被埋没。

    然而此类的管理者多会给员工以较大的压力,因为其能看到项目进行中的每一步,于是往往以自己的标准来要求员工,在一步刚刚走完,员工还没调整过来,就被催促着进入下一步,在员工看来上不可控的风险在其看来完全可控,在员工仅仅看到第一个跨栏的时候,其已经看到了终点,往往过于乐观的估计员工的水平以及项目当前的状态。当然由于很有经验,其有时候会参与到项目的实际工作中来排除困难,促使项目在其规划的范围内完成,也多搞得员工比较疲惫。

    对于此类管理者,模棱两可是最不可以接受的,其往往希望对项目的每一个技术细节有所把握,除了和大多数管理者一样需要有扎实的数据外,从技术理论角度要能够讲的通是非常必要的。在项目规划的时候,你至少应该想出大部分此类管理者能够想出的方案,除了用数据表明一种方案优于其他外,到底采用了那些技术方有此数据表现也是很重要的。在项目执行过程中,遇到了困难block甚至delay了项目进度的时候,除了使用log或者其他工具证明确实有此问题存在之外,要对此问题进行技术理论方面的解释,分析可能那些原因造成了此问题。在项目结束,除了展示漂亮的结果和飞快的速度,如何达到此类速度是其非常想知道的。当然同此类管理者沟通技术是相对容易的,你只需一点,其马上可以体会到背后的奥秘,"哦,你一定是用了XXX技术吧,我原来有个项目也是这样做的…"。相对较难的是对项目进度的沟通,当其评估需要3天时间,你觉得需要5天来完成任务的时候,一定要有充足的证据。

    第二类:使用不同类型技术做过相同类型产品的管理者。

    如果项目管理者原来用C/C++实现过搜索引擎系统 ,则属于此类。

    此类管理者多能够很好的把握需求和架构,以及最终结果的技术指标。然而由于不同类型的技术在具体实现方面的设计思路不同,能够使用的资源也不同,面临的难点和问题也不同,也就造成了其对风险的控制,技术难点的解决,时间进度的控制方面,则要多依赖手下的兄弟们,也可能会有些偏差。

    在项目执行过程中,有时候会对风险的评估过高或者过低,对时间进度的控制或紧或松,比如有的功能使用C/C++则需要完全自己实现,而Java中已经有成熟的工具可用,再如有的Java框架在数据量比较大的情况下会出现不稳定,没有真正使用过的很难预料到。其有时候会对遇到的技术难点十分理解,有时候却觉得所谓的技术瓶颈不可理喻。

    对于此类的管理者,在上述三个方面,程序员要主动承担一些责任,在项目方案评审阶段,要对风险点有全面的调查,并明确的告知,帮助其进行风险控制,在项目规划的阶段,对自己任务的划分应该足够的细致,对每个子任务的所花费的时间,都应该有明确的理由,在项目遇到没有预料到的技术难点的时候,要主动沟通,解释原因,好在此类管理者多是很有经验的技术人员出身,尽管平台不同,只要耐心解释,还是能够获得理解的,当然你还应该对此技术难点所要花费的时间,是否有替代方案等有一个估计,方便其对进度进行控制。

    第三类:使用相同类型技术做过不同类型产品的管理者。

    如果项目的管理者用Java做过ERP系统,则属于此类。

    此类管理者与第二类恰好相反,其能看到树木,对森林的把握可能会略显不足。其可能会过于关注具体的技术细节,甚至到第一线去写程序以及解决问题。而由于没有相关方面的经验,可能只吃过猪肉,没见过猪跑,对需求的理解可能会有偏差,对模块的划分可能不很合理,从而导致项目开发的过程中多有反复,摸着石头过河,造成经常进行代码重构,在结果出现不理想的时候,出现放弃千辛万苦实现好的旧方案,尝试新方案,时间一长,会造成开发团队人心不稳,目标不明,因为谁也不愿意看着自己的辛苦付之东流而在原地踏步。

    就风险管理方面来看,一个团队中至少有一个见过猪跑的人会大大降低风险。如果碰巧你是这样的人,则在项目规划阶段贡献出自己的经验是责无旁贷的,可以使得团队少走很多弯路,千万不要抱着出了事再说的态度,因为这样会给你留下知情不报,有所保留的印象。

    如果非常不幸,可能由于人员招聘的原因,你碰巧在一个从来没有人见过猪跑的团队来设想如何养出一头最最先进的猪的时候,你可能在辛辛苦苦的重新造一个市场上已经有了的轮子,如果你到了真正的养猪场,你会发现原来你辛辛苦苦探索的方法在这里随便一个养猪工人都知道。所以此种情况下,前期研究的时间要留的长一些,磨刀不误砍柴工,切勿匆匆下手,导致项目反复。如果有类似的开源软件,则应该对其进行详细的调研,如果市场上已经有公司这方面做的比较成功,则安排一定的技术交流是非常必要的,如果有相关方面的会议,能够参加一下也是有帮助的。

    在此类团队中,代码的可扩展性和灵活性十分重要,可能最初设计的时候费些事,会使得以后的反复过程中轻松很多。对于此类管理者,不但最后的结果是成果,中间的反复也是成果,证明一个东西好是成果,证明一个东西不好同样是成果,对技术难点的攻克同样是成果,这些中间的尝试,都应该及时的汇报,以免中间的辛苦因为最后的结果没有使用而被埋没。

    第四类:使用不同类型技术做过不同类型产品的管理者,及只了解基本的技术原理的纯项目管理者。

    有的项目管理者原来是管理的完全不同的产品,或者虽然读书读的是计算机,然而一毕业就直接从事项目管理工作,而非从开发人员一直坐上去的。所以此类的管理者多是结果导向型的,也多是授权型的。

    此类管理者由于缺乏对技术细节的敏感度,因而多表现出以下几个特点:

    首先,有成果满分,没成果零分。这如同高考中看不懂计算过程的问答题一样,最后结果正确则基本满分,最后结果错误则几乎零分。

    其次,工作态度十分重要。当对技术细节不甚了解,则工作态度就成为是否努力的衡量标准。

    其三,通过员工之间的对比和互相评价判断员工的评级。如果不能够很好的把握绝对值,对相对值的把握就成为一种手段。然而每个人干的活不同,此种方法很容易出现偏差,有的功能看着很简单,但背后可能要做很多工作,有的功能看着很复杂,其实却只需稍作修改,这只能导致前者哑巴吃黄连,后者没事偷着乐。

    其四,对任务等待的time out时间较短,心理学中的等待效应有八条原则,其中一条是没有说明理由的等待比说明了理由的等待时间更长,由于管理者不明白技术原理,则比较容易time out。我们知道,很多的前期调研工作是十分耗费时间的,常称之为过山车式的,即开始进度缓慢,总是不出成绩,只有当积累到一定的知识量,有了总体的把握,则成绩会迅速大量的出现,然而往往在过山车马上达到顶峰,即将释放势能的时候,管理者time out 了,于是很多马上要出结果的调研工作终止或者换人,使得研究了很长时间的员工的辛苦付之东流,或者后继的员工站在前人的肩膀上大出结果的时候,反而庆幸自己尽快换了人,进而褒奖后者的能力,而批判前人的努力,造成对员工评价的不公正。

    所以对此类管理者,除了工作态度认真之外,要将任务划分成众多小的阶段,每个阶段都要有结果,要在管理者time out之前,将结果展示出来,将Timer reset一下,重新进行下一个小的任务,也算是针对管理者这个客户的敏捷开发吧。当遇到技术难题的时候,仅仅埋头苦干是不行的,要多和同事进行技术讨论,甚至向此方面擅长的技术专家进行请教,要知道,别人替你说一句"这个模块有很多技术难点啊"比你自己喊有多难有分量的多,也是一种沟通的手段。

    三、进入Team后,打响第一枪

    这就是所谓的首因效应,即人与人第一次交往中给人留下的印象,在对方的头脑中形成并占据着主导地位的效应。

    一位心理学家曾做过这样一个实验:他让两个学生都做对30道题中的一半,但是让学生A做对的题目尽量出现在前15题,而让学生B做对的题目尽量出现在后15道题,然后让一些被试对两个学生进行评价:两相比较,谁更聪明一些?结果发现,多数被试都认为学生A更聪明。

    首因效应虽然可以通过训练进行避免,然而不能不说,还是起着重要的作用的。

    首因效应之所以十分明显,因为其多半后来会伴随着马太效应,即凡有的,还要加给他叫他多余;没有的,连他所有的也要夺过来。

    这在生活中太多见了,想想我们从小到大的学习阶段,几乎所有的好处都给了学习好的学生们,什么三好学生,优秀干部,竞赛机会等,甚至连微不足道的演讲比赛,书法比赛都不放过,虽然他们未必是这方面的高手。再想想新闻中宣传处的模范人物,也是几乎所有的光环都给了他们,领导接见,授予奖章,媒体采访,甚至连感动中国也必须有他们的一方席位,虽然他们只是将人民赋予的使命干的很不错,但没有让人落泪而已。

    在公司里,也同样是这个样子的,如果你有幸被冠以某方面强人的名号,则bonus,加薪,升职,代表Team去开会,演讲等都会慢慢的到来。

    当然牛人也是可以进行市场细分的,比如语言的,平台的,框架的,工具的,英语的,沟通的,流程的等等,当然还有一种是成为最努力的人。

    比如在西游团队中,孙悟空是技术型的,沙僧属于努力型的,猪八戒就属于沟通型的。

    每个人要根据自己和整个Team的成员情况,看走什么路线比较好。当然其中技术型的路线相对比较受推崇。

    对于英语的,沟通的,努力型的,要正确向技术型进行转型,至少寻求在某项技术类型中占据老二的位置,否则你是最可爱的,最受欢迎的,也可能是常被边缘的。

    转型则需要你在本职工作外,做一些中间地带的有挑战性的工作,或是在某个牛人休假,生病,离职等情况下顺利接手,这些都可以成为你是这个方向的专家的标志。

    对于其中的努力型,需要指出的是,转型要快,因为你永远拼不过刚毕业的小伙子们,而且时间长了会被认为你的成绩皆是努力所得,并非技术强人的印象,影响了你的前途,况且一旦不能坚持,则容易引起阿伦森效应,一个例子就是,小刚大学毕业后分到一个单位工作,刚一进单位,他决心好好地积极表现一番,于是,他每天提前到单位打水扫地,节假日主动要求加班,领导布置的任务有些他明明有很大的困难,也硬着头皮一概承揽下来。但日子一长,小刚没有了那股干劲,水也不打了,地也不拖了,还经常迟到,对领导布置的任务更是挑肥拣瘦。结果,领导和同事们对他的印象由好转坏,甚至比那些刚开始来的时候表现不佳的青年所持的印象还不好。因为大家对他已有了一个“高期待、高标准”,另外,大家认为他刚开始的积极表现是“装假”。

    四、绩效目标的商定

    和上司商定绩效目标的时候,是需要遵循一定的原则的,一般的说法是SMART原则:

    • Specific:明晰,即要做哪些任务,怎么做,花费多长时间,优先级是什么,可能的技术难点在什么地方,是否有解决或者替代方案,是否需要资源支持如机器,带宽,软件lisence等,是否需要技术支持,Team内,公司内还是公司外,是否需要添加人员支持。
    • Measurable:可衡量,即如何界定任务是否完成,如功能指标,性能指标,测试用例覆盖度,系统测试,集成测试,Demo,文档,技术会议,report等。
    • Attainable:可实现,即评估任务是否有技术的,资源的,人员的,流程的限制,是否依赖其他的任务,比如美国的设计文档等,评估上述衡量指标是否过高或者过低,过低则任务没有挑战,工作没有成就感,过高则容易使员工绝望,破罐子破摔。所以一般来说,最好顶一个所谓的跳起来够得着的高度,也有的说120%的完成度,最能够激发员工的主动性和潜力。当然如果后期发现完成100%,也应该算作此任务完成,超过则要有奖励。
    • Relvent:相关,即任务要同项目相关。有时候对此项的过分严格的要求,会降低Team的融合程度,因为如果仅仅与子团队的目标相关的话,子团队之间的空白地带将无人去做,所以任务制定要考虑的因为对整个Team的贡献留有buffer。此所谓的任务绩效和周边绩效的概念,任务绩效主要包括两种,一种是技术任务绩效,一种是领导任务绩效,一般的程序员只有第一种,而技术经理,架构师等则同时包括第二种,周边绩效也包括两种,一种是工作贡献,如对流程,方案提出建设性建议,主动承担非工作范围的任务等,一种是人际促进,如帮助他人,协调工作,便利沟通等。
    • Time:时间,需要上司和员工一起商议每个任务所需要的时间,并将任务按照优先级排序,从而得到每个任务的checkpoint点。时间一般应该首先由员工给出,由上司审核后确认,时间不宜指定的过于紧迫,否则一定影响代码质量,可扩展性,技术选型及系统架构。

    除此之外,还应该注意以下几点:

    • 上司一般可没有耐心等到一个阶段过后才看到可衡量的目标,因而除了最终的目标外,可将目标划分为小的目标,定时考核。
    • 除了有工作相关的目标,最好还有一些发展相关的目标,每一个上司都希望看到自己的员工积极上进,不断进步的。

    五、绩效沟通与反馈

    当项目目标制定好了以后,很多员工就一头就扎进自己的任务中,认为只要最后的结果能够出的来,就一定会有回报。而管理者们也多以授权为由,不太关心项目实施过程,而仅仅check结果进行考评,没有在平时留心记录员工的业绩和表现,在最后以总体印象进行评价。

    所以每年的绩效考评的时间,都是多少有些尴尬的过程,有的平时十分内向的员工看到自己的评级的时候,失望,惊讶,甚至愤怒,觉得自己的努力没有被认可,个别会出现在同事面前抱怨评级,同上司争吵,甚至越级上告的情况,无论是上司,同事都很惊讶的发现,这还是平时那个默默工作,积极主动,帮助他人的人吗?

    当我们做一个多节点系统的时候,经常需要通过Heartbeat来同步节点的拓扑信息,否则不同的节点将看到不同的拓扑图。

    当然项目执行过程中也是这个样子,需要不断的沟通来填补上司和员工对当前状态的理解的差异,当然所谓的沟通,也不是通过良好的表达能力就可以的,沟通中往往存在以下的障碍:

    • 因不同的经验水平和知识差异而带来的信息不对称。由于知识背景的缺乏,很多上司觉得很简单的事情,对员工来讲可能是比较困难的,由于经验水平的差距,很多上司看来显而易见的风险,对员工来说可能是毫无思路的。正如老罗语录中所提及老股民在新股民前面卖弄专业术语的时候多会忘记自己当时的困惑一样,很多上司也多会忘记自己当年的懵懂,发出每一代人都会发出的一代不如一代的感叹,觉得还不如自己亲自去做来的省事。然而人总是要成长的,你也不可能自己做完所有的事情,培训下属同样是上司的职责之一。有的上司也会培训下属,甚至一步一步的交给下属怎么做,可有时候还是起不到效果,其实有时候背景知识和原理要比具体步骤更加重要,授人以渔胜过授人以鱼,明白了为什么,聪明的程序员们很容易看懂这一步步的步骤,反而如果只知其然不知其所以然,一旦出现变数,则无法应对。对于背景知识的培训,往往开始需要较长的一段时间,但是无论如何都是值得的,上司一定要有耐心,做为下属,也可以让上司推荐相关的书籍文档等,下功夫尽快度过这个时期。对于经验的积累,却丝毫没有捷径,只有真正做过,遇到真实的场景,方才会有体会,所以经验较少的员工的技术方案评审,上司是一定要把关的,可以很好的进行风险控制,另外一点就是机会教育,也即当项目过程中遇到棘手的问题并得到解决的时候,获得经验的不仅仅是当事者本人,而是应该扩大到整个团队。
    • 选择性处理对自己的评价。人对信息的接收,理解和记忆都是具有选择性的,一个人总会根据自身的价值观来选择接收那些信息,并对信息进行解释甚至曲解,使其同固有的认识相互协调而不是相互冲突,并将信息中对自己有用,有利,有价值的信息储存在脑子里。试想当某明星出现丑闻的时候,其粉丝总是不能接受这些信息,并试图证明这不是真的,这一定是有合理原因的,尽管这些证据在外人看来是那么的铁证如山。试问如果你是一个对房价看跌的人,你是否看到有关证明房价会跌的新闻迫不及待的点开,而对证明房价会涨的言论不屑一顾?反之亦然。所以,在绩效沟通中也同样存在这样的问题,中国人的沟通总是会照顾面子的,因而很多人会选择说模棱两可的话,"你总体表现还是不错的,只不过XX方面尚欠缺,没关系,多看看这方面的资料就好了",有的人是乐观主义的,于是可能会忽略不足的部分,选择记忆好的部分,最后惊讶的发现在一直不错的评价下最后获得了仅合格的评级,造成心理落差。有的人是悲观主义的,从而造成了很大的心理压力。
    • 对项目目标或任务重要程度理解不同所带来的方向性问题。有时候项目的目标和程序员的目标在理解上会有一定的差距,项目的目标往往是根据内部客户或者外部客户的需求制定的目标,而程序员则多喜欢有技术含量的工作,一般还要几种倾向:一是技术完美性,如项目目标是做一个有完整功能的,但性能较差的Demo产品,然而测试出来的速度程序员会认为从技术角度是不可接受的,所以花费大量的时间来改进性能;二是方案原则性,即做一个东西,应该用什么方法做,就要用什么方法做,哪怕承担做不完的风险,也不使用丑陋的折中解决方案;三是架构完整性,即一个系统应该包括那几个模块,应该是麻雀虽小,五脏俱全的,哪怕用户没有要求有此模块。这几种现象如果不影响项目进度,是锦上添花的事情,如果不幸影响了最终的deliver,则会最终影响绩效的,但在平时沟通中,不但没有得到提醒,甚至得到鼓励,"我看你做了一些性能改进,好像提高了不少嘛","没想到你还支持这个功能"。然而最后绩效评价的时候,当上司以项目delay进行减分的时候,员工往往会十分困惑,"我虽然没按时做完这个,但是我的性能是其他同事不能比的啊,当时你不也给予肯定了吗?"。
    • 对员工所在状态的认知。按照经典理论,员工会处于以下四个阶段,对于不同的阶段,应该采用不同的管理方式。第一个阶段:低能力,高意愿,刚进公司,下属的工作热情高,但能力较低,容易听从指挥,应使用指挥式管理。 第二个阶段:有一定的能力,低意愿,过一段时间,能力得到提高,但激情逐渐消退,则应该使用教练式管理,通过培养能力来提高意愿。第三个阶段:更高的能力,变动的意愿,当工作一段时间,能力有了大幅度提高,但意愿处在一种不确定的状态,则应该使用支持性方式,相信其能力,通过让其自行解决问题来激发意愿。第四个阶段:高能力,高意愿,能力已经十分成熟,可以独当一面,行为相对成熟,则应该使用授权型,让其自由发挥,达到自我实现的目的。此理论并不新鲜,然而问题是员工到底处于哪种状态是需要很好的沟通的,而非由上司指定的,如果在上司眼中,员工处于第二阶段,而员工自认为在第四个阶段,则员工会感觉上司对自己不信任,反正员工可能会在面对问题的时候手足无措。

    所以在平时,可以由上司发起,也可以由员工发起,定时对以下方面进行沟通:

    • 数据化任务的完成情况,任何任务都应该有以数据为支撑的指标,上面已经详细叙述。
    • 证据化工作中好的表现和需要改进的地方。为了防止上述的对信息的选择性处理,绩效沟通的信息反馈一定要清晰,最好伴有实际的例子,做的好的地方比如什么项目中的什么工作,需要改进的地方比如什么时候的什么表现,如果作用不很明显则可以通过反复沟通加以确认,尤其对于可以改进的部分制定相应的计划,并实时跟进,如"上次推荐你看的书看的怎么样了?"。
    • 仔细分析工作中的困难和瓶颈。为了解决信息不对称的问题,上司此处应该做一个好的听众,学会站在员工方面看一下问题,甚至充当辅导员的角色,帮助分析遇到瓶颈的原因,是动机问题(对界面工作不感兴趣,希望做底层),还是职位角色问题(此职位涉及太多不同模块之间的沟通,希望深入写算法方面的东西),或是工作方法问题(不应该盲式,可借助工具进行分析),或是能力问题(原来是学C++的,刚转到Java,对一些框架不是很了解),或是沟通问题(没能够正确理解美国老板的需求,英语不好,远程会议达不到目的)等等等等。员工也应该站在上司的角度,通过列举事实,说明某些任务耗费很长时间的原因,自己是怎么想的,如何设计的,为什么选择这个方案,为什么没有估计到这个问题等,当然上司也应该区分是团队的共性问题还是员工的个别的问题,如果是个别问题,则可以商讨解决方案及改进措施,如果是共性问题,则应该对团队进行机会教育,并不应该对该员工的绩效有减分印象。
    • 如果评级最终不可避免,那么就做在平时。一般仅仅在最终的年终考核的时候,才会对员工进行很好,好,一般,差,很差五级(不同的公司叫法不同,有可能比较委婉,但没有关系,关键你属于哪个级别)的评级,而平时是不会的,况且评级会带来一些尴尬,因而多进行避免。其实既然最终不可避免,与其最后给一个惊讶,不如平时坦诚沟通更能避免情绪的大起大落,从而影响到团队的士气。当然平时的评级不必大张旗鼓的进行,也不必每个月或者每个季度都给员工打上一个戳,给员工带来很大的压力,可以通过One on One的沟通进行。按照杰克威尔奇的分布理论,员工是按照20%优秀,70%普通,10%不足进行分布的。在这其中,前20%是众所周知的明星员工,是不必显式的沟通就可以达成共识的,而大部分普通的员工也是兢兢业业工作,有自知之明,也不太aggressive的。需要显式沟通的是70%中的比较优秀的部分(我们称之潜力股),以及最后的10%的部分(我们称之ST股),是会情绪波动比较大的部分。其中潜力股部分,由于本身比较aggressive,也相对比较乐观,容易误认为自己是属于前20%的部分的,当然如果名额宽松,他们是可能进入第二等评级的,但当名额不足,其落入第三等评级的时候,他们会很失望,自信心大受挫折,从极端的乐观主义变成极端的悲观主义,如果不很好的进行沟通,他们往往从第三等级的top一下跌至第四甚至第五等级,甚至出现离职,他们会想,我这么努力的贡献,和大多数平庸的人一样,还不如也平庸下去。对于潜力股,在肯定其潜力的同时,要显式的表明其与前20%的差距,并对其进行辅导和提供培训,通过非评级和财务的奖励(培训机会,演讲机会,独当一面的机会),让他们觉得付出有回报,树立向前20%进发的激情。对于ST股,在企业整体效益比较不错的情况下,往往也会给第三级评价,所以他们往往也感觉不出自己属于最后的10%,觉得自己的一些失误可能瞒过了上司的眼睛,觉得自己和大多数人也差不多,仅仅在公司效益出现问题的时候(金融危机中),或者需要裁员的时候,才显现出来,他们往往也十分的惊讶,从而产生敌对的情绪,影响大部分普通员工的情绪,会传递出这样的信息,你看,我每次的工作都合格了,最后也被裁了,这次是我,下次就指不定是谁了。对ST股,也要有显式的沟通,除了肯定其完成了大部分任务外,表明其与大部分同事的差距,通过对他们额外的监管(多问,多指导)表明对其还是关心的,不放弃的,对其失误也是清楚的,还可以通过安排前20%的员工或者普通员工和其pair work,或者对其进行帮助,来让其自身意识到差距的存在。
    • 辨别员工所处的阶段。这个阶段既不是完全由上司进行判定,也不是完全由员工进行判定,而是一种通过不断的沟通,对指挥行为和支持行为所占的比重的调整。上司大可不必定义,你属于低能力的阶段,需要更多的指挥,所以你要听我的,这样反而引起下属的反感。在项目有所delay的时候及时的介入指挥行为,随着进度的赶超而慢慢的减缓,在员工士气向下波动的时候及时介入支持行为,随着员工意愿的提高而慢慢减缓。当然在不同的项目,使用不同的技术的时候,员工所处的状态也不尽相同,不可一成不变。
    • 调整目标偏移。当员工为了自己心中的理想和信念,而非项目的目标进行工作的时候,不要反对他们这样做,这样会挫伤他们的积极性,然而你知道,如果继续这样做下去会影响进度,所以行为修正是必须的,然而负向强化不等于打击其追求完美的积极性,一种方法就是不做评价,并同时对高优先级的任务一再的跟进,进行反复的正向强化,从而使员工向正确的项目目标转移。

    六、近因效应不可避免

    所谓近因效应是指在多种刺激一次出现的时候,印象的形成主要取决于后来出现的刺激,即交往过程中,我们对他人最近、最新的认识占了主体地位,掩盖了以往形成的对他人的评价。

    近因效应不可避免,但也不要做的太明显,否则会给同事及上司很功利的形象。

    由于绩效管理制度的逐渐成熟,近因效应很大程度上可以减弱,其实是一种锦上添花,而非雪中送炭的事情。

    所以,对于近因效应:

    • 避免其反作用:即一年表现都不错,最后切忌因为取得了不错的成绩而骄傲自满,甚至懒惰,要注意保护自己的劳动果实。在绩效管理的培训中,很多回强调如何规避近因效应的正向作用,对于反向作用却很少被提及,而由于心理落差,作用相对十分明显。所以千万不要干功亏一篑的事情。
    • 是70%中的较优秀分子向前20%冲击的最后阶段。如果恰巧名额宽松,能够挤进第二等评级,则在未来一年甚至更长的时间都会有作用,这是一个资格问题,也是一种等级问题。
    • 使得近因效应保持一定的惯性,千万不要像读书的时候那样,考前看通宵,考后扔书包,毕竟绩效考核到最终定下薪资涨幅,还是有一段时间的,而且持续一段时间有利于减少功利的形象。

    七、年终考评——最后的机会

    终于到了一年的年终,是该综合考评的时候了,也是有可能剑拔弩张的时候了。

    一般这一切从自我评价开始。

    如果说一年就不谦虚一次,我认为应该是这一次

    其实自我评价真的起不了什么作用,唯一起的作用是减少近因效应的影响,使得领导能够回望全年的成绩,并不会遗漏。

    即便如此,毫不谦虚的将工作成绩列举出来仍然是必要的:

    • 提醒上司:当然列举事实是必须的,最好能够让上司回想起那样共同奋斗的日子,如突破一个难题,向高层demo一个结果,共同加班到深夜等,唤起革命友情。
    • 总结过去:工作成绩当然不应该散列出来,而应该加以总结,归类,不但可以看到自己的总体进步,对于以后的跳槽时候的简历书写也是很有用的。
    • 反省自我:自己的程序人生应该有所规划,也只有自己对自己负责,当前状态同自己欲达成的目标还有那些距离,在未来的一年如何向职业目标迈进。当然这一切不必让上司知晓,然而如果不经常的反思自我,你会发现,自己总是东一榔头西一棒槌的,为了公司的目标做了很多杂七杂八的事情,反而在职业生涯上迷失了方向。

    360度评价,只为上司一句话

    有的公司在年终考评的时候,会使用全方位的360度评价法,也即通过自我评估,客户评估,同事评估,上级评估,下级评估,部门评估等多个方面对员工的绩效进行考核。相关评级方或填写问卷,或书写评价,甚至可以给出评级。虽然其信息收集相对全面,但也存在很多的缺点,比如评级方的评价会相对主观,而非根据任务完成情况,因而有良好沟通能力,会做人的员工打分会相对比较高,再如不同的评级方给出的评级有时候会出现冲突,如何综合处理是比较困难的,所以很少有公司是完全按照360度考核的结果作为最后的绩效决策,而是作为参考的手段,从而发现员工在那个方向的结果和行为上需要改进。

    其实各方面的评价无论多么的好,无论你的上司在你的评语中写了多少的优美词汇,真正最后起作用的,就是在最后的五个评级中选择的那一个,那最后的鼠标一点,胜过千言万语。

    公司对于每个评级应该达到的状态是有严格的描述的,比如成绩会超过期望等等,然而促使上司最后鼠标一点的,却不是你是否达到了这些描述,而是他心中的那个排序。

    每个人心目中总有一个排名或分布

    有的公司要求用强制分布法,有的公司的不会。然而只要是资源有限,是稀缺的,则需求方就会出现博弈,就会出现竞价,排序就不可避免,无论是在制度中,还是在人们的心里。

    所以不要纠结你是否达到了公司的业绩描述,而是看你在team中所处的位置,在平时隐式的不断沟通你认为的位置和你上司认为你的位置,尽量平时就达成同步,而非最后现上轿才扎耳朵眼。

    在上司提交前最后一次反馈期望

    一般,上司在做最后提及之前,会就你的自我评价以及他的评价对你进行沟通,就你的各种成绩进行反馈以及评价,但是却往往不会告知你最后他的鼠标点在什么地方。但这是最后一次可能表达你的期望的时候,如果平时用隐式的方式,这次可通过较为显式的方式表达自己认为自己应该所处的评级,因为一旦点击提交,则很难反悔。当然如果不能达到你的期望,也不必过于偏执一端,分析原因,面向未来吧,况且你没有博弈的筹码了。

    理解上司的权衡,评级比涨幅更重要

    有的时候,碰巧你在排名的时候同另外一个同事打了个平手,然而名额有限,你的上司必须做一个权衡,一个给评级,一个给较高的薪资涨幅和培训。如果有幸你可以选择,你应该坚决的表达这种态度:你想要评级。

    评级比涨幅重要的多,这是一个资格问题,关系到你后来的很多福利甚至升职。有的公司会有这样的强制规定,在股票或奖金等方面不同的评级范围不同,可能相差很多钱。有的公司也会有一些隐性的规则,比如连续几次第二评级以上,可以参加管理方面的培训,或者进行升职等,没有评级,可能就失去了机会。如果你因为项目原因进入另外一个组,那个组的成员及lead可看不到你过去的努力,而一个好的评级,是好的印象的开始。有的公司跳槽的时候,reference check也会问及在原公司的表现,一个好的评级显然更利于你在面试中的博弈。所以评级远非一点点钱那么简单,如果你有选择,评级很重要。

    当然如果你的上司替你做了选择,理解他吧。

    八、One on One——一切已经过去

    绩效考评完毕,就是进行绩效反馈的时候了,这个时候,你已经知道了自己的评级,还会组织一次One on One进行沟通,无论你是否满意,一切已经过去了。

    其实如果在一年中经过前面的不断沟通,既不应该有惊喜,也不应该有惊讶,每个人都是应该有自知之明的。

    如果不幸,你很失望,请记住博弈已经不再可能,应该重点面向未来。

    这时候,上司也会和你讨论绩效改进计划,应对自己的不足之处积极的配合制定改进计划,同绩效计划一样的认真执行,千万不要因为情绪原因进一步恶化和上司的关系,陷入恶心循环。

    想想经常被提及的下面这个寓言故事吧:做一棵永远成长的苹果树。

    一棵苹果树,终于结果了。

    第一年,它结了10个苹果,9个被拿走,自己得到1个。对此,苹果树愤愤不平,于是自断经脉,拒绝成长。第二年,它结了5个苹果,4个被拿走,自己得到1个。“哈哈,去年我得到了10%,今年得到20%!翻了一番。”这棵苹果树心理平衡了。

    但是,它还可以这样:继续成长。譬如,第二年,它结了100个果子,被拿走90个,自己得到10个。

    很可能,它被拿走99个,自己得到1个。但没关系,它还可以继续成长,第三年结1000个果子……

    其实,得到多少果子不是最重要的。最重要的是,苹果树在成长!等苹果树长成参天大树的时候,那些曾阻碍它成长的力量都会微弱到可以忽略。真的,不要太在乎果子,成长是最重要的。

    你是不是一个已自断经脉的打工族?

    刚开始工作的时候,你才华横溢,意气风发,相信“天生我才必有用”。但现实很快敲了你几个闷棍,或许,你为单位做了大贡献没人重视;或许,只得到口头重视但却得不到实惠;或许……总之,你觉得就像那棵苹果树,结出的果子自己只享受到了很小一部分,与你的期望相差甚远。

    于是,你愤怒、你懊恼,最终,你决定不再那么努力,让自己的所做去匹配自己的所得。几年过去后,你一反省,发现现在的你,已经没有刚工作时的激情和才华了。

    “老了,成熟了。”我们习惯这样自嘲。但实质是,你已停止成长了。

    这样的故事,在我们身边比比皆是。

    之所以犯这种错误,是因为我们忘记生命是一个历程,是一个整体,我们觉得自己已经成长过了,现在是到该结果子的时候了。我们太过于在乎一时的得失,而忘记了成长才是最重要的。 

    当然作为上司,此时也不要太揪住过去不放,对于优秀员工,此时已经信心过于饱满,可以适当谈一些其缺点和可以进一步发展的地方,对于比较差的员工要重塑信心,防止其破罐子破摔,主动倾听他的意愿,从其原意改进的地方入手,哪怕暂且牺牲一下绩效(比如多利用一些工作时间进行学习来提高技术水平,而少做一些任务),只要其能够不对立,采取合作的态度,再对其行为进行正向激励,就能恢复到正轨上来。

    虽然评级基本决定了薪资涨幅,然而同一评级涨幅也不相同,很多上司在同普通员工沟通的时候,无论其涨幅多少,都说是平均涨幅,防止他们产生心理不平衡,其实坦然的沟通更好,永远不要以为薪资保密真的很管用,员工总会知道他们每个人所谓的平均涨幅是不同的,这样反而会使得他们猜来猜去,对上司产生不信任,对绩效好的员工产生怀疑和敌意,从而影响了调薪后一段时间的工作效率,也就是所谓的调薪后遗症,薪水都涨了,效率反而下来了,团队反而不和睦了。

    展开全文
  • 使用excel统计销售业绩,方便进行绩效管理,适合团队或自己创业使用 使用excel统计销售业绩,方便进行绩效管理,适合团队或自己创业使用
  • 绩效评估或考核会议是对员工在考核期间的表现进行回顾、总结和强调的机会。 自我评估是大多数绩效评估的标准部分。通过使用绩效计划和评估表作为指导,员工可以评估自己的绩效,为考核会议做准备。这一过程可以发现...

    此图像的alt属性为空;文件名为2021030112131767-1.jpg

    绩效评估或考核会议是对员工在考核期间的表现进行回顾、总结和强调的机会。

    自我评估是大多数绩效评估的标准部分。通过使用绩效计划和评估表作为指导,员工可以评估自己的绩效,为考核会议做准备。这一过程可以发现员工的自我认知与管理者的观点之间的差距,并可以在会议期间对这些业绩点进行更深入的讨论。

    管理者应审查其全年产生的绩效管理笔记和文件,以便更有效地评估员工的绩效。只有已经与员工讨论过的问题才应该成为评估文件和会议的一部分。这将确保管理者在出现绩效问题时进行处理,并确保在绩效评估会议上不会出现意外。

    在绩效评估会议上,员工和管理者需要做以下工作:

    总结上一年相对于绩效期开始时设定的目标所完成的工作。这包括抓住每个目标的关键结果、成就和不足。
    记录一年中遇到的挑战,并确定需要培训和/或发展的领域。
    识别并讨论实现目标过程中的任何不可预见的障碍。
    员工和主管应在表格上签字。这表示员工参与了这一过程,但并不一定同意评估的内容。如果员工对绩效评估的任何部分有异议,应提供机会让他或她附上意见,并与绩效评估表一起存档。

    管理人员必须确保员工收到一份评估表的副本,并将签字后的文件放入员工的档案中。

    处理考核异议
    即使有一个精心设计和实施的绩效管理程序,也可能出现员工与经理对其绩效评估有严重意见分歧的情况。应该建立一个程序,让员工讨论对程序的不同意见。

    处理绩效考核异议的一些方案有:

    阶梯式审查制度
    不同意见由更高层次的管理层如主管的经理听取,必要时再由执行董事听取。在小组织中,可能没有更高层次的管理层可以申诉。

    同行评审制度
    由同等数量的雇员和管理人员组成的小组审查不同意见。(注意,这一制度在工会工作场所可能不会受到制裁)。

    监察员
    雇员可以向组织内被指定为公正的监察员的个人寻求帮助。

    避免评分者的偏见或评估错误
    我们对很多事物的判断都会受到我们认知的影响。当一个人对别人进行评价时,评价既反映了被评价者,也反映了评价者的内在偏见。管理者应该意识到自己可能存在的评价偏见,从而在评价过程中尽量消除这些偏见。

    一些常见的偏见包括:

    1.对员工形成普遍的正面印象的倾向,即对员工的所有评分标准都给予很高的评价,而不是对每个项目都单独给予评价。

    2.与光环效应偏差相反,对员工的印象普遍负面,导致人为地降低评分。如果管理者普遍不喜欢或对员工信心不足,就可能出现这种偏差。

    3.在应用评分表时,倾向于将大多数员工评价为 “平均”。例如,给定一个从1(差)到7(优秀)的评分表,4分是平均分,有些经理拒绝使用两端的分数。趋势是几乎所有的评级都在3-5的范围内。较短的评级尺度(例如,那些只有3分,而不是7分的尺度)往往会导致较少的中心倾向偏差,但它们也变得不那么精确。

    4.当一个管理者在对员工进行评级时,有比她或他的同行更宽松或更严格的倾向,或者对一个员工比对另一个员工更宽松或更严格。

    5.倾向于对被评价者认为相似的员工的评价比对不相似的员工的评价更有利。

    此图像的alt属性为空;文件名为image-20.png

    展开全文
  • 如何做开发部门的绩效考核

    千次阅读 2015-02-24 23:11:35
    记者:开发部门为什么要实行绩效考核? 刘青焱:绩效考核作为管理六要素之一,在有效管理、凝聚团队、提升士气等方面有着不可或缺的作用。可以说,成功的业务离不开成功的产品,成功的产品离不开成功的执行...

    记者:开发部门为什么要实行绩效考核?


    刘青焱:绩效考核作为管理六要素之一,在有效管理、凝聚团队、提升士气等方面有着不可或缺的作用。可以说,成功的业务离不开成功的产品,成功的产品离不开成功的执行,成功的执行离不开成功的绩效考核。开发部门是生产部门、执行部门,所以有效的实施绩效考核是必不可少的。


    绩效考核可以增强沟通。在绩效考核的过程中,有点强制性的迫使管理人员和团队成员进行定期的沟通,这对于增进管理人员和团队成员之间的相互信任、消除误解都有积极的作用。


    藉由尊重和沟通,对开发人员进行持续地激励,从而帮助他不断地进步,将他们的潜力发挥到最大。这样,通过有效地实施绩效考核,将绩效考核变为绩效管理和绩效改进,可以有助于保持整个团队的凝聚力,进而保持高生产力以及工作可控性。


    记者:对开发人员实行绩效考核有哪些经验体会?


    刘青焱:基本上我遇到的问题也都是些比较典型的问题。比如开发工作很难数字化这个问题。本质的原因是,开发工作是创造性的工作,总是具有不确定性在里面。有句话说得好,每个软件项目都是一个新项目。所以传统软件工程搞了这么多年,其实是废了的。如果不能有效地管理开发人员,软件的质量就是不可管理的。


    但是我们又要尽量把目标用一些数字描述出来,因为数字是相对客观公正的。所以我们可以把框架性的目标用数字描述出来,这样沟通起来最清楚,也不容易产生沟通和理解上的偏差。而对于具体的执行过程,则属于数字之外的东西。绩效管理,数字是绩效,数字之外的是管理。


    所以,开发工作往往不能过度追求数字。一味追求数字的后果只有一个,那就是绩效被过度重视而管理被过度忽视,从而增加质量失控的风险。


    举个例子, 完成一个后台系统模块。这里“一”就是数字,但是其他的部分呢,就完全在此之外了。或者,我们再加上一个,bug数控制在N个以下。但这是无济于事的。因为当你的业务量急速上升的时候,你会发现开发人员甲做的模块可以平滑扩容,很好地支撑起新的业务量;而开发人员乙呢,就可能甚至需要停止业务,花费很大精力去重构。


    所以我的观点是,除了钱可以被控制( 度量),其他东西是不可以被控制(度量)的。也就是说,除了销售人员的quota是真正可以数字化的之外,其他职位的目标都是无法真正数字化的。要量化,但是不能过度追求数字。


    同样是上面的例子,我们会发现,即使有量化目标,也无法区分优秀的开发人员和一般的开发人员。一般而言,一个优秀程序员的能力是一般程序员的十倍甚至二十倍还要高,但是他们的薪酬却不会差那么大。其根本原因就是,没有什么绩效考核机制能够准确地识别出这些优秀的人员。因为度量工具永远都不会拥有发现的功能:同样是完成了期望的目标,你无法说甲比乙优秀多少。结果往往是,都是符合期望,于是得分都一样。长此以往,绩效考核也就成了埋没人才的罪魁祸首。


    前人说了,千里马常有而伯乐不常有。把千里马当牛用的人,不在少数。因为在僵化的环境中,都是讲求德比才重要。而且往往对德的判断都是管理者的主观臆测。一个德才兼备的人才,在顶级的管理者眼中是德才兼备的,在二流管理者眼中就往往是才胜于德,在末流管理者眼中可能就是无德无才了。


    因此,用人先要识人。看一个人有没有才,要从他的实际工作看,而不是只看一个数字化的结果。看一个人有没有德,则更多取决于管理者的胸怀大小了。


    所以,要做好绩效管理,就要深刻理解“绩效管理=绩效+管理+管理者”的道理。


    记者:在俱乐部会员讨论时候,你曾经提到“量化标准还是最重要的”,请问如何很好地制定这个标准呢?


    刘青焱:要很好制定出量化的考核标准,最重要的一条是,技术管理者一定要懂技术,要专注技术。唯有如此,才有可能制定出公平且一致的标准,并经充分的沟通,让技术人员信服。然后,技术管理者需要对过程和结果保持开放和透明的评价,必须公正客观,并在团队内部达成充分一致。不然,一个技术管理者很快就会堕落为一个技术官僚,并被顶级的程序员所厌恶。


    只有管理者真正理解技术,真正对团队成员了解,相互知根知底,才能制定出一致认同的目标和标准。通常讲,目标设定要让开发人员“跳一跳够得到”。如果不是对他的能力十分清楚,不知道他的兴奋点在什么位置,又怎么能够设定出正确高度的目标呢?高度要很好地量化,首先要知道目标应该设在哪里,然后量一量,知道这个地方的目标的高度是多少。这样才能得到最佳的量化目标。这样得到的量化目标和标准才是可管理的。


    何谓可管理的?就是这个设定不会流于形式,或者权谋,而是确确实实能够激励和帮助开发人员不断提高,从而实现整个团队能力和生产力的不断提高。


    记者:在大公司和小公司实行绩效考核有什么区别吗?


    刘青焱:大公司和小公司的绩效考核与绩效管理区别非常大。


    大公司层级复杂,甚至跨地域、跨市场,所以常常采用矩阵式管理结构,层级和汇报关系复杂。所以对于大公司,绩效管理尤为重要。因其沟通成本很高,所以量化要更强,以此减少层间沟通的信息变形。


    因而大公司的绩效管理很容易出现过度量化、过度追求数字的问题。因为对于一家庞杂的大公司,唯一的一般等价物就是钱。所以大公司的CFO就时常出任CEO。


    两个团队绩效分数相同的人,可能实际能力差距巨大。所以无法再管理细节的CEO最终管的,就是钱。


    在此情况下,如果我们过度追求数字,对销售团队是没有错误的,但是对开发团队就是灾难。过度追求数字,质量就会下降,开发人员就会沮丧,出现问题就会互相指责,最终带来的后果就是团队的分崩离析和产品的失败。不要被世界500强的光环所掩盖,它们之中如此失败的案例比比皆是。


    所以大公司里,要从组织架构上把追求短期利益的团队(例如销售)和追求长期利益的团队(例如技术研究)划分开,分别实施不同的绩效管理方法,从而在制度上尽力确保公司短期利益和长期利益的平衡。


    小公司由于团队人数少,层次简单,等级壁垒小,沟通成本低,所以技术管理者应该多用沟通的方式代替过度量化的数字,应该把目光集中在个人目标和公司目标的一致性上。因为对于小公司而言,应该是每一个人,包括程序员,都十分清楚公司的目标以及方向。每一个人都十分清楚自己的工作对公司的未来有着至关重要的影响。


    小公司因为存在更大的生存压力,因而更注重短期目标和一致性目标。小公司资源是更加紧缺的,这也就意味着,小公司不太可能从结构上保障短期和长期的平衡。这就对一个技术管理者提出了很高的要求。因为和销售型团队比较,技术性团队更需要这种平衡。


    一支团队要在一家公司里生存,就必须有数字。一个团队要在一家公司里长久生存,就不能过度追求数字。因为只有长久的公司里才能有长久的团队,而短视的公司是不会长久的。在这一点上,一个技术管理者应该做好平衡的艺术。有效地运用绩效管理这一工具,帮助技术管理者做好这种平衡。


    无论大小公司,技术管理者都需要秉承一个理念,把技术人员当作管理者来管理。即,充分认识到程序员的工作具有很强的自主性和创造性,传统的管理生产者的方法是不合适的。技术管理者重要的管理目标之一应该是团队成员的长期成长,并通过这种成长实现团队生产力的提高,从而更好地支持业务目标的完成。从这一点上讲,绩效管理,正是团队整体生产力持续提升的重要管理工具

    展开全文
  • 关于绩效考核

    2008-05-13 12:58:00
    最近,公司为了能够更公正客观地评发季度奖,又开始搞绩效考核了。为什么说“又”呢?答案是:公司以前已经搞过绩效考核了,不知道几次,反正至少一次吧。我知道的那次是因为大家反映要填的表很繁琐,所以搁浅了。...
  • 医院绩效考核管理平台建设方案

    千次阅读 2020-05-05 14:12:49
    为进一步深化公立医院改革,推进现代医院管理制度建设,2019年1月30日国务院办公厅就加强三级公立医院绩效考核工作,发布了《国务院办公厅关于加强三级公立医院绩效考核工作的意见》(国办发〔2019〕4号)(以下简称...
  • 小型软件公司的绩效考核 http://vipnews.csdn.net/newscontent.aspx?pointid=2009_02_05_134301856...由于我正好在一家小型软件公司里负责绩效考核工作,有一些成功的实践经验,所以特此在这里与大家交流一下我的心得
  • 2020年6月9日,国家卫健委发布了《关于采集二级和三级公立医院2019年度绩效考核数据有关工作的通知》,要求参加2019年度绩效考核的二级公立医院,于2020年7月1日—8月15日期间,将2017年—2019年的住院病案首页数据...
  • 如何给程序员做绩效考核

    千次阅读 2015-02-24 22:54:30
    绩效考核的五种死因 程序员作为企业开发力量的最核心资产,无疑得到公司从上至下的一致关注。开发是个智力密集型产业,程序开发的特点是,付出相同时间的情况下,两个开发者之间的产能会相差十几甚至几十倍。软件...
  •  工作所在的部门启用了新的绩效考核制度,也开始了我参与对测试人员的工作进行绩效考核这一管理活动,第一次的考核结果让我有很多的感想,因此今天把它记录下来,也许突然有一天回头看这一感想,又会是另外一份心情...
  • 绩效考核谈起

    2016-01-19 10:50:41
    每到年底,各个公司都会有一个保留节目——绩效考核。公司今年发展迅速,领导不够用了,来,提拔一些新领导吧。这些新晋领导平均工作3年,平时工作还是有条有理,颇有心得,但是做起绩效考核来就有些头疼了,于是私...
  • 关于开发工程师的绩效考核

    千次阅读 2019-08-12 18:36:49
    总结一下看过的一些关于开发人员绩效考核的资料~~~ 考核的目的不仅是要衡量每个人的绩效,更重要的是让大家自我提升时有一个依据,更好的规划自己的职业发展。 我觉得运动员的考核做的是最好的,考核方法符合SMART...
  • 今天我来介绍一下在Devops体系中对项目团队效能方面的考核指标! 度量指标的选择 在度量Devops团队效能方面,避免采用像代码行数、故事点数这种面向过程、局部的度量指标,而是采用像部署频率、前置时间、恢复时间...
  • 开发部程序员绩效考核办法

    千次阅读 2015-02-24 23:24:24
     对软件开发的过程所产生的软件项的质量和过程进行定量的评价,用评价的结果指导软件的开发过程,不断地提高软件开发质量水平,并依据度量记录来考核软件开发人员的工作绩效。 2、工作内容   市场调研 需求分析 ...
  • One question I’ve seen posed a few times in the past several months is whether performance really is a moral or ethical concern, or if that’s ... 在过去的几个月中,我已经看到一个问题,那就是绩效是...
  • 烟草局绩效考核系统打分模块开发笔记  开发一个绩效考核系统,其难度、复杂度不在开发一个功能复杂的权限系统开发难度之下。作者这里把原始设计以及一些技术细节公布出来,希望能和大家一起交流学习。  背景:...
  • 优秀课件笔记之绩效考核管理

    千次阅读 2008-03-21 12:15:00
    第六章绩效考核管理绩效考核是组织HR管理的核心职能,是HR战略性激励的基本工作内容之一。第一节绩效考核概述一.绩效考核定义绩效(PerformancefceraoPmrn)通常理解为一定时期企业员工个人工作成绩表现,团队运作...
  • 小型公司如何对开发人员进行绩效考核(1) 组织模式,工作如何量化,决定于公司的组织结构,以职能型组织机构替代项目型组织机构。分职能经理(正在有权的人),项目经理(需求分析和设计人员)。职能经理可以对管辖的人员...
  • 绩效考核表模式 定义绩效分析 “绩效分析”有很多定义,但我认为最有用的定义之一是: 一种测量驱动的方法,用于了解应用程序在负载下的行为。 此定义的优点在于,它引起对测量的关注,这是整个过程的关键,...
  • 近几个月,我常和一些朋友讨论如何在小型软件公司中对软件开发人员进行绩效考核的问题,发现很多朋友都为此问题而烦恼。由于我正好在一家小型软件公司里负责绩效考核工作,有一些成功的实践经验,所以特此在这里与...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,793
精华内容 1,917
关键字:

绩效考核小程序