怎么看待工作量化

• 資深大佬 : 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 怎么算。。。

• 資深大佬 : 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

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