一将无能 累死三军

你说的，我上家公司都有弄过，包括评论下的也有，比如把需求或者 bug 包装成任务点，领导评估，让大家自由竞争（甚至想过把需求拆分分给外包做），增加奖金池和扣钱池，但是没用大家基本上都达不到期望，你扣钱人家就跑，或者少干活，而且评估很难达到标准，高级开发可能需要 1 小时，那中级开发可能就需要半天，后续还增加了量化代码，但是也没用，很多代码写车轱辘话就行，你说开会评审，那很多时间都会放在开会上了，全是面子工程，其中还有很多波折反正持续了半年。后续的结果就是制定规则的领导自己走了，底层的换血太多，人员不稳定，业务波动太大，老板给上压力。 我的建议还是多换位思考，平时多沟通，很多规则只是只是为了缓解老板的焦虑和有一些书面上的提高给资方看的。如果整个产品线不赚钱，那就说明方向就不对，商业模式走不通，只能砍掉。正常赔钱，如果产品线在盈利线上，那就得缩编优化人员，实际上就是降本增效，裁员，而不是靠这些绩效去管人，学校几十年的存在都不能改变一个人，何况这些绩效，如果人员确实不对付，裁换人是最快的。 你现在的处境和我领导差不多，需要承上启下，实际上两头都不讨好，我的建议还是多跟领导沟通，这样那样是没用的，效果不大，至少他后面执行了有问题，你也说了，对下面，有些事情只要不是太过分都放一下，大家基本上都是打工人也是同事。关系闹僵了反而工作不好推进。

还有加班，我上家也是，加班就是态度，你不加班就是态度不行，到后面也是磨洋工，国内的这个加班文化，我是见一次骂一次，我得骂到我死之前，我还得骂，包含餐饮，制造业，所有的行业都是这样靠加班去赚那些辛苦钱，老板也考加班去看那些态度，都是什么鸟人，除开特殊行业必须保持 24 小时，必须分配 2-3 班倒，福利能到位，大家怨言还能少一点

对于你们这种小团队要以主观评分为主，量化为辅。 主观上： 你和他的协作上下游关系对其进行打分，你的主观评分要占据主导。 量化上： 一是对业务结果的影响程度，比如 UI 改进前后版本用户转化率、留存数量、体验问题投诉数量，PPT 提案通过成功率。虽然主要功劳未必在他，但是他必须从对公司最有价值的事情中受益，这样有利于团队利益最大化。 二是交付效率。比如响应速度、交付时间与预期偏差、返工率、规范一致性等。这个体现了 UI 好不好用。

看到通过代码行数来衡量绩效就头皮发麻，后果就是一行能搞定的要拆分成五六行，然后每行都加注释

所有人吃大锅饭，一样的绩效。这就是最优解，没有比这更好的。

给每个任务设定分数，完成一个加分， 最后比较分数排行榜 最后可以喜迎离职裁员倒闭

@EthanV2 感谢，尝试和领导沟通过。 我们团队的评判标准的结果应该是如何的，是每个产品线每年做了几次迭代，还是我们保障、支持了多少项目，或者我们可以在此基础上有哪些创新的产品、新产品的开发。但是领导并不正面回答这些问题，觉得我们现在做量化，或者说把绩效中的一部分拿出来做量化，是制度推行人往前走，制度要求、规范人的行为。 只能说，我努力尝试沟通、提出新的方案，用最终团队一季度或者一年的成果，来作为总体的评判，但是领导可能也有他的考虑吧。

@sillydaddy 感谢，我会慎重考虑并再持续沟通的，不过，领导可能也有他的考虑。我只能尽可能压缩这种数字标准在绩效中的比例。