TL 日日谈:绩效结果有分歧-接手项目烂盘子怎么办


绩效异议

李健

咨询个问题,如果评价标准不健全的情况下,绩效有异议大家都怎么处理?

德胜

将标准列出来,让他自己做个自评。把其他人的贡献列出来,给他看,让他自己评价是不是比别人做的好?所以主要还是要看产出,看贡献。

李健

还有一个问题,有什么机制或者流程,可以限制技术leader的打分?比如技术评审,有问题的话,大家都会走申诉流程,可是绩效没有类似的机制保障。那我能不能这样理解,绩效基本上就是boss想怎么打就怎么打,只要投诉到他那里的案例是少数的,那么他随便找到一些可以用来和你比较的人就可以了吧?

朴喵

绩效考核,考核的核心是什么?是既定时间内的产出,不是能力,绩效是可以浮动的,不是常值。绩效不好不是对个人能力的否定。如果对绩效不满,就要看他纠结的点是什么,是觉得自己能力被否定?还是产出被否定?一般员工不从这个维度思考,但是主管是知道的,需要沟通。

李健

如果绩效表里面打分项没有出现问题,你只是看着这个员工贡献少,你依然会给这个员工打低分吗?

朴喵

对呀,在目标制定清晰,员工认可的情况下,产出没有达到目标,这样绩效不可能再给打高的。没有标的,容易扯皮。

李健

如果目标产出达标了,而你只是看他不爽,并且没有对于团队贡献的考核项,这个背景下你会打低分吗?

朴喵

那我觉得这是主管的问题,目标制定和考核,出现了双标。自己的问题自己负责。

李健

员工申诉的流程是什么呢?自己怎么负责?绩效已经打出去了,HR连工资都给你算好了,恨不得就差发放了。

朴喵

不清楚你们怎么个流程,我们公司会有绩效确认这个环节,如果不服,可以申诉。

李健

不过,可能实际场景下,如果绩效出现了问题,大多数人会选择离开吧。因为除了年终奖,走仲裁有点不划算。所以这个问题只能指望TL自己良心了, 但是TL单方面主管来定高低就有点扯了,除非主管评分的权重在50%。

Chis

小公司,没有绩效考核…..只有大家印象和产品印象。关于考核bug数量,其实也有问题。一般来说,复杂模块bug比较多,简单模块bug比较少,即使是厉害的人去接了复杂模块很有可能产生的bug比不厉害的人接的简单模块多。所以对于bug率的参考,管理者要心里有底。

德胜

拉出去,吃个饭,喝个酒, 聊聊喽。员工真的不能理解就算了,绩效本来就有高有低的。是人,就会有主观意识。那你打高了,给别人打低了,别人一样难受

曹仁

绩效难打基本都是前期绩效目标没有明确好吧,参考之前他自己设定的绩效评分标准去打分还会有意见吗?

朴喵

申诉流程没有的话,只能看主管的个人发挥了,真犯错了,敢不敢认错以及如何补救,确实是个难题。要根治,只能在前期不犯错,尽可能做到公平公正清晰,后期补救真的是个无底洞,酒水钱也挺贵。

李健

所以,我认为这比较考验TL对于绩效的设计,是不是能否结合团队的主要问题、业务的主要问题来进行设计绩效。真的遇到这种问题,即便是TL自己反思,认错了,财务流程已经走完了。所以需要有流程阻断,并且需要给财务留出时间。

德胜

我基本会在打绩效前,和他们简单谈一下。

李健

至少你还能谈下去,我说的场景你可以认为是谈不下去了,TL找不出否定小哥的依据,人家里有理有据,绩效就是达标了。唯一的矛盾就是小哥有点刚,挑战了一把TL的权威,所以想和大家交流交流,这个KPI的设计有没有什么技巧。总不能每次都是线上无事故,需求无延期这些吧?这些虽然应该写,但是不一样的阶段,权重都应该会有一些浮动。

朴喵

跟业务聊,可以得出一部分业务规划;然后组内聊,得出一部分技术规划。然后拆解,细化,责任到人。

堂主

这些年还没出过因为绩效 review 的问题。绩效这个过程管理很重要,再一个是考评维度。考评维度要结合定级标准、能力模型、产出,量化要求制定不同阶段的目标和过程管理,最后绩效 review 只是个结果。绩效一看产出维度和结果,二看和过去自己比的进步,三看同级别之间对比。

李健

这些是不是KPI和OKR同时使用呢?

堂主

这只是工具,没那么重要,就好像纠结于 vue 还是 react。

李健

我理解OKR是工具,主要激发团队的潜力;KPI要这么玩,估计大家都会考虑到自身的风险吧?

堂主

有点形而上了。

李健

我理解从上到下,从下到上还是有一定区别的,不都是形而上的问题。和过去自己比、和同级别之间对比这两块,堂主有什么量化技巧吗?因为我平时也处理得不太好,所以权重不会太高。

棘手的项目

秦真

最近遇到一个棘手的项目,前同事(早已离职)给客户做的,代码写得很烂,逻辑混乱,根本没有code reivew,优化更不用说了,压根没有。客户最近有新需求,而且时间比较紧,要求尽快上线。现在的前端团队小伙伴已有7成的人员加入这个项目了,但没有一个对这个项目业务非常熟悉的,都是哪块遇到问题就去问客户,或者通过阅读这些晦涩难懂的代码来理解业务。所以,最近加班严重,上周甚至通宵加班,已有两个小伙伴申请离职了,各位大佬能给点什么建议改善下这个局面吗?

大飞

烂代码的主要原因,没人规范,没人管。

蜗牛

敢让人通宵,就得做好他们离职的准备。

Ashin

你们也是做私有化的吧,这种无解,走人确实是最好的选择。

wzn

这种问题,一般在前期,项目负责人得准备好备胎,随时能接手。避免一个复杂项目被一个人的垄断。

Sam

1.二手再转出去。2.找印度人外包。这类项目是外包性质,不是维护性质,只能靠人力。

Scott

不要怕把人做离职,过渡期就有过渡期的代价。公司通过这样的历程,也是要从中成长的,管理者亦如此。你如果继续在这个位置上做下去,就要在扛起来的同时,还要让你的老板以及你老板的老板明白,一个坑可以给公司带来什么代价,将来的项目又要怎么去做。不可以有破罐子破摔的想法。这样的现状,也不仅仅是薪资的问题可以解决的。这是整个研发能力,研发流程、工程师做事环境的问题。逃避不如面对,面对后就要往上层进行推动解决。

Ashin

碰到过一千多个接口的前端,无文档,基本无注释。接口可能还可以按图索骥,但是业务逻辑这条线谁能梳理出来?创业初期,很多人员参差不齐,只是赶工期,没有定规范,导致后续项目越来越大的时候,谁都不敢随便改,更不敢重构了。2B项目,一个项目稳定下来,说不定得大半年的时间,那成本基本都在百万以上了。

Chris

我这边也有一个类似的老项目,没人敢碰,前后端不分离,业务超级复杂,还往死里加需求,把项目弄得更复杂。产品的作用就是维护,市场提需求,就改。没有一个人了解里面的全部业务逻辑。最后最坏的处理情况,就是转移数据,整个项目都换过。我们就经历过这样的过程,从php全换成Java,不能维护的项目,全砍全换,本来就难维护了,干脆一刀切。

wzn

我们也有这样的项目,老系统,重构代价太大,公司也不同意。不重构又难受。谁都不想去踩雷。

发表评论

邮箱地址不会被公开。 必填项已用*标注

相关