认真请教应该如何做绩效量化

[xyzlucky]

首先介绍一下背景：我是一个产品经理，下面有一个产品助理和一个 UI 设计师。我司规模还算不大不小，但是软件研发的团队人数比较小，只有十几个。

我的工作说起来就是，正常产品经理要做的比如：产品规划、不同产品的迭代计划、具体功能的产品需求文档、画原型这些，是都在负责并且持续做的。 同时我也要做售前的工作，比如对接我司销售给方案评估、硬件配置评估、报价、偶尔写一些方案。 还要做培训和运营，因为我们软件产品还挺多的，所以每个产品都有自己的一套资料体系（产品介绍 PPT 、一指禅、白皮书、用户手册等等）。比如今年就做了好几场大的培训，面向不同群体的培训，PPT 的材料都会根据培训对象做各种调整。

最近领导提出要我们每个月的绩效都要有量化指标，比如，研发是一个月内提交多少次代码、代码行数等。 领导的思路是所有量化指标，都要用研发内部自己写各种小工具（开发中），来统计这些量化数字，从像 git 、禅道等拉数据作为量化依据。

但是我确实不知道应该怎么用同等类型的思路来定义产品和 UI 的量化标准。产品我还能努力编一编，比如我一个月写了几条需求（但我觉得挺扯的）、我要在多少时间内响应销售售前的问题（我觉得更扯了）。除此之外我也想不到产品还有什么可以用类似的数字来量化。

主要是 UI ，在每个产品我都已经定好了设计风格并且都不是新产品的情况下，很难说让 UI 一个月画多少张设计稿，我们也没有那种需要做海报之类的这种工作需求。 最近他最多的是帮我把各个 PPT 做一些风格优化，但是撑死也就七八个 PPT ，优化完了就算结束了。也很难说要用什么数量上的标准。

所以真心向各位求教，产品经理和 UI 各位都是怎么做绩效量化呢。感谢各位

[sillydaddy]

可以打分啊。
工作质量，你来打分。
工作产量，你来打分。
主动性，你来打分。
。。。
然后提供申诉机制。

所有的，都是你来打分，你是领导，当然门儿清。你的领导如果要求必须「客观」，那你就说「我的评分就是很客观公平的」。再说还有申诉机制。

[leyfung]

我们是 禅道任务工时量化，所有岗位都上禅道

[christmasin2015]

这是非常典型的：试图用上个世纪工厂的计件流水线思维，来衡量智力工作成果；
例如：单位时间内学术论文产出高就是绩效高、加班时长等于工作态度；

我们这里的主要绩效标准（ ToB ）
产品:一个月一次的竞品商业分析汇报、现有产品商业数据分析汇报；重点在商业变现而不是监工。
研发：系统使用次数和“稳定性”数字；重点在持续迭代与长期稳定而不是“孕妇催生”；

PS:UI 岗位在软件领域是很纯粹的辅助岗位，重点可以放在工单满意率之类的人文指标上

[xyzlucky]

@sillydaddy 对，之前我们是打分的。但是领导说，要有实实在在能看到的数字，比如 PPT 有多少页，写了多少份 PPT ，这种。
比如，下个月的计划是写 10 条需求 / 做 10 个页面设计，那么数量到 10 ，能拿这部分 100% 的分； 8 个，就有 80% 的分

[wqhui]

不做工作量的量化，做质量的量化。比如说上下游的满意度、沟通的难易/充分程度

[venglide]

看目的的，如果是想兼顾汇报和团队/个人发展，基于任务做量化会比代码量，提交什么的靠谱一点。整体框架以 PMP 为指导，同时参考主流协同软件（ jira ，禅道，飞书好像也有统计）。如果只是想着压榨员工，强推代码量评估什么的，建议跑路。

[sillydaddy]

@xyzlucky #4
变通一下就可以。比如说，你把给员工打分，换成给任务打分：
A 任务，难度系数 0.8 （包含了一个很难的特效），任务量 10.5 （约需要 10 张 ppt ），创新弹性 2.0 （特效可好可差，无法明确规定，全在员工自觉）。

做完之后根据员工实际做的情况打分就行了。注意以市场的平均水准作为评估基准（或者以当前员工的当前工资所期望的水准，作为 100%的评估基准线，比如超过了基准，就是 120%，不足就是 90%，千万不能看以前的成绩逐渐加码）

说白了还是打分，只不过给他标注上具体的数据依据。这些依据可以查证、对比，哪怕让他请第三方的去评估。

但是绝对不能只靠那些依据的数字，比如页数什么的，否则就像楼上说的，成了造就论文工厂那种激励制度了。

[94]

> 比如，研发是一个月内提交多少次代码、代码行数等。

制度不合适，不充分反映工作性质。拍脑袋的 213 领导要上线了。

[fredweili]

不做，没意义，做的好不好大家都很清楚，工作的难度和对客户的重要性又能怎么量化？

[zw1one]

一将无能 累死三军

[LaGeNanRen]

典型的用流水线监工思维来管人，格局就到这了

[EthanV2]

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

[EthanV2]

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

[showonder]

对于你们这种小团队要以主观评分为主，量化为辅。

主观上：
你和他的协作上下游关系对其进行打分，你的主观评分要占据主导。

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

[passworderror]

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

[LandCruiser]

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

[dajj]

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

[xyzlucky]

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

[xyzlucky]

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

[xyzlucky]

@showonder 嗯嗯，我觉得也是这样，所以只能在后面沟通的时候，尽量压低所谓量化在绩效中的占比。感谢