怎么看待工作量化

[zhang14964]

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

[mm163]

自以为是的 xx 越来越多

[sogwsc]

我们排计划 每个点要精确到 0.1 个工作日 结果就是计划排出来的时间很短 实际要延期
我是觉得没啥意义

[lzlee]

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

[jin7]

逼你加班

[Meltdown]

量化是必须的，但是考验制定标准的人的水平

[Mark24]

不是计件工作，很难衡量工作量。

软件发展这么多年了，预测开发截止时间，依然是世界难题。

或者说，根本也不需要量化它。

很简单，据个例子——你怎么量化领导的工作呢？他们不干活，代码、BUG 数都是 0，一直在开会，所以他们的价值是 0 么？

[jones2000]

直接走人，换地方。 开发这个东西很难量化，项目前期还可以更具你的页面或功能数量化。后期重构，优化，代码加注释等这些精益求精的活没办法量化，而且后期这些东西会比前期更消耗时间，因为还要把前期做过的东西更好的抽象成类，封装等，这些花时间比较多。

[james122333]

很难量化阿 如果前期一堆坑 中期又塞一堆烂东西进去 找新的人进去 不管如何绩效绝对不会好看
前人也就达成这东西只能前人维护的目的 后人又管不了事不能重构那更糟糕了 这种事情就是初期容易量化 后期困难 多了很多因素 无谓的沟通更多了 事情变复杂了 跟对象概念一样 弄不好就失控了

[james122333]

最后无可避免公司就会官僚化 奴化

[me876]

说一说搞量化的弊端：

五年前端开发一个页面功能需要 2 小时，1 年前端开发同样页面功能要 2 天，到领导眼里会变成五年前端打酱油，工作量不饱和，多多分配任务，反正不给你闲着的时候，1 年前端工作很充实，再接再厉。

他们忽略了五年前端花了多少时间和精力这些隐形成本才能如此提高效率，如果提前干完了活就不停歇的分配新任务，五年前端又哪来的空闲时间做积累，为之后的任务提高效率呢？

抛去一切中间过程，问题的本质是：在指定时间范围内，领导需要从开发那里拿到成果。

为何不约定一个时间范围，比如一周内五年前端完成 10 个页面开发，1 年前端完成 3 个页面开发。这样做可以达到双赢：
- 领导到时间拿到成果，省去管理成本，有这时间去做个足疗不香吗！
- 开发人员也为自己奋斗，提前开发完成后，剩余的时间可以休息，可以充电，它不香吗！

那么又有个新问题，如何为每个员工分配工作量：
答：多劳多得，任务全扔到任务池中，开发人员自行接任务，多接一个任务，多赚一分钱。有点赏金猎人的味道。

[me876]

从第一次工业革命开始，前辈们的努力都是为了提高生产效率，解放劳动力。

但 21 世纪以来，大型企业的管理无不是为劳动人民增加桎梏，各种规矩人为的拖慢生产效率。

[aydd2004]

我个人的经验 公司管理的工时量化就是瞎扯 没人待见这玩意 但是自己对自己的工作还是得有一个起码的把握 不需要精确到小时 但是至少也要到天

[lewis89]

量化这个过程的成本远高于工作时间的成本