怎么看待工作量化

[zhang14964]

基于绩效考核改革，上头要求前端工作量化 比如 "一个列表页，多长时间能做完，一个功能效果，多长时间能做完"

[noble4cc]

这么多年了没人能量化程序员的工作量

[neoblackcap]

严格的量化是不可能的，每个人工作能力都不一样，这个量化的结果就是不准确。
程序员的工作既像工人，也像作家。有搬砖的活，也有需要灵感技术的活。
不量化会导致大家磨洋工，量化到极致跟绩效挂钩也会导致工作进度估计不准确，消磨志气。
量化实在是一个技术活。

[o0]

感觉这个不是工作量化的问题，而是如何应付上级。
一般喜欢把时间稍微说长一点，最终也能“提前”完成目标，但架不住一次又一次的压缩时间，最终被压到真的无法完成的时间，然后没有完成目标，就被定义为“不上进”。

[wangxiaoaer]

既然这样，各位大佬平时的 KPI 是怎么计算的呢？

[f056917]

如果做的比量化标准好，会涨薪吗？做的不好会降薪吗？

[libook]

基于大量经验做评估，如果团队从一开始就采用这种方式的话，几年后应该能形成一个工作量化的共识，至少技术经理可以根据每次完成工作的反馈来不断调优对工作量的评估。这种评估方式的特点是同一个工作不同人因为能力不同，所以所花时间也是不同的，所以可能不能直接反映员工绩效情况。

另一种方式是敏捷开发里的 story point，算是一种建立团队工作量化共识的方法论，经过磨合之后，团队内所有成员都能对每 1 点所代表的的难度产生共识，一个任务不管谁做点数都一样，但每个人因为能力不同能在单位时间里完成的点数不同，由此通过点数来对比不同员工的能力差异。

我觉得企业发展到一定程度，一定会直面“每个人究竟值多少钱”的问题的，基于任务的规模来评估绩效总好过按代码行数做绩效，如果你对绩效改革有发言权，可以去了解一下 360-degree feedback 和 Peer review，另外做绩效方案和企业当前情况也是有关的，比如如果企业冗职太多，想要优化投入，可能就会引入正太分布这种很变态的方法来强制末位淘汰。

[luckyrayyy]

前端按页面和功能点吧，只能大致量化。我一般先按照比较自信的时间进行估计，然后乘以二...

[iugo]

可以一定程度上量化, 但必然导致行政工作消耗时间:

一个列表页，多长时间能做完

1. 是否包含分页?
2. 是否包含每页行数可选?
3. 是否包括自选列功能?
4. 数据来源是否单一?
5. 数据是否需要额外渲染? 比如 0.1 = 10%
6. 是否需要排序?
7. 哪些列排序?
8. 正序倒序?
9. 数字是否需要右对齐?
10. 是否有选择导出功能?
...

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

[ChoateYao]

我们都是先写需求技术分析方案，然后再确定开发时间。

有需求技术分析方案，评估出来的时间，不会差太多，技术难点也知道。

但是这个方案占据的时间，不知道你们公司给不给。

[leafre]

效率低，是不是做完了就能光明正大的摸鱼了

[zsc8917zsc]

一般是最低单位 0.5 天，有几个功能乘以几个 0.5

[luozic]

性能问题 安全问题 扩展问题 维护问题 咋算？ 还量化？

[Eugene1024]

需求搞明白才好出计划，不能肯定对不上

[ClericPy]

如果有一个算法能识别各种语言代码的信息熵就好了, 至少比某某大公司平均每人每年多少行代码要有用的多...

[guyeu]

做功能之前肯定是要排期的呀。。这也算是量化么

[sun019]

基于结果来考核吧，但是这个涉及到项目组的问题，复杂些了，但是是最合理的。
一个项目多久能做完肯定是技术负责人和开发人员同步完需求后商量下评估出来的。

[mseasons]

量化结果：做页面一个 task 、美化页面一个 task 、优化页面一个 task

[xy2020]

这么做量化的，我不是没见过，但能执行落地并持续、有利于管理的，我还真没见过。
软件研发管理最有效的就是量化管理，但绝不是这种量化方法。

[royan]

典型的外行（上头）指挥内行（码农）

[liuxingdeyu]

之前一个 600 行的超级大接口函数，被我搞成好几个即使行的功能函数和一个接口函数，该咋给 kpi，里面用暴力循环怎么算，用贪心 dp 怎么算。。。