千万别量化码农的工作，你会被喷的很惨

昨天看到有人问，怎么看待码农工作量化考核？

说他们公司基于绩效考核改革，上头要求前端工作量化，比如"一个列表页，多长时间能做完，一个功能效果，多长时间能做完"，为此还列举了标准，比如移动端页面，一个搜索框1h，一个首页4h，商品页5h，前端5小时出一份所有页面所需api文档，看起来都不用排期了...

不知道你们怎么看，我认为，严格的量化是不可能的，每个人工作能力都不一样，这个量化的结果也是不准确的。

这么跟你说吧，兄弟，这么多年了没人能量化程序员的工作量，到最后都是不了了之的居多。

这么做量化的，我不是没见过，但能执行落地并持续、有利于管理的，我还真没见过。

用大佬的话说，程序员的工作既像工人，也像作家。有搬砖的活，也有需要灵感技术的活。

不量化会导致大家磨洋工，量化到极致跟绩效挂钩也会导致工作进度估计不准确，消磨志气。

量化实在是一个技术活。

不怕你们笑话，我曾经也被工作量化搞得头大，自从执行绩效考核制度后，感觉自己每天的工作已经不是量化的问题了，而是演变成了如何应付上级。

不过上有政策，下有对策，码农兄弟们都懂的，前端按页面和功能点，只能大致量化。我一般喜欢把时间稍微说长一点，一般先按照比较自信的时间进行估计，然后乘以二...最终也能“提前”完成目标，但架不住一次又一次的压缩时间，最终被压到真的无法完成的时间，然后没有完成目标，就被定义为“不上进”。

但你说程序员的工作能量化考核吗？也不是不可以，可以一定程度上量化, 但必然导致行政工作消耗时间:

回到开头那位兄弟的困惑，一个列表页，多长时间能做完？

这里面包含了很多不确定的因素，比如：

1. 是否包含分页?

2. 是否包含每页行数可选?

3. 是否包括自选列功能?

4. 数据来源是否单一?

5. 数据是否需要额外渲染? 比如 0.1 = 10%

6. 是否需要排序?

7. 哪些列排序?

8. 正序倒序?

9. 数字是否需要右对齐?

10. 是否有选择导出功能?

...

如果要算时间, 就把这些需求都说清楚, 说清了, 就好算。

建议先写需求技术分析方案，然后再确定开发时间。有需求技术分析方案，评估出来的时间，不会差太多，技术难点也知道。

所以，量化的前提是明确需求，先把需求分细, 你的量化, 才会有意义。越模糊的话, 偏差会越大。

如果需求不明确，我就想问一句，下面这个90后前端妹子的工作怎么量化考核？

最好的办法，是基于结果来考核，但是这个涉及到项目组的问题，复杂些了，但应该是最合理的。

一个项目多久能做完，肯定是技术负责人和开发人员同步完需求后，商量下评估出来的。

土哥抛砖引玉，仅是一家之言，关于这个话题，你们怎么看？欢迎来评论区留言告诉我～

- End -