度量数据是人工凭感觉录入的,产生的偏差如何解决?

先抛出我的观点:由人工凭感觉录入而产生的数据偏差,不需要解决。我们分几个层面,来剖析这个问题:

1、估算本就是一项不靠谱但不得不做的工作。

估算的目的是在不确定性的环境中寻找确定性,通过利用接近事实真相的数据,以降低目标达成的风险。然而,只有当事情真实发生了,才知道偏差有多大,但此时我们已比之前更接近目标,估算活动也早就过时,已然完成了它的使命。

2、估算再不靠谱,它也是一门方法论。

常见的估算方法包括:专家判断、类比估算、参数估算、三点估算、自下而上估算等等。而"人工凭感觉录入"的前提,就是假定了录入人员具备对该专业领域评估的经验,所以可以认为就是一种专家判断的估算形式。即:基于某应用领域、知识领域、学科和行业等的专业知识而做出的,关于当前活动的合理判断(PMBOK 第六版)。

3、估算也是有成本的,要控制好收支比。

精益思想认为,只有满足客户需求的产品或服务才是有价值的。我们在价值创造过程中的活动,可以分为三种类型:有价值的、没有价值的(参考:精益生产之七大浪费)、无价值但有必要的。只有减少无价值但必要的活动,以及消除没有价值的活动,才能实现价值最大化。估算就是一项"无价值但有必要"的活动,它并不能直接创造价值,但可以通过它规避风险来提升获得价值的可靠性。

4、度量什么,就会得到什么。

在管理学界,有一个知名的古德哈特定律(Goodhart's law),即:当一个政策变成目标,它将不再是一个好的政策。当我们把度量手段当作管理目标后,被管理的一方就会揣摩管理者度量的意图,并竭尽全力让数据倒向管理者所期望的效果(原因可能是出于应付、讨好、恶意、上级施压、自我保护、善意的谎言、无意识的先入为主等),于是,度量结果就丧失其原本所具有的信息价值了。

5、目标刻在石头上,计划写在沙滩上。

在确定性越强、重复性越高、经验积累越充分的场景中,我们对偏差的容忍度越低。比如,在建筑施工领域,就明确地在不同交付阶段分别采用概算、预算和决算来评估单位工程所需的费用。但在动态变化且从未有人涉足的领域,任何预测到头来都是令人沮丧的,最显著的例子就是软件业。我们不应指望在评估环节就预见一切,然后舍本逐末地追求估算的准确性,而应该关注:① 估算对象与历史经验的相似性,考虑使用类比估算;② 估算持续偏差的稳定性,考虑使用参数估算;③ 多人群策群力共同参与,实现三点估算。

6、估算是一项主观性很强的工作。

每一项所谓"凭感觉录入"的数据,都是当事人用来衡量"他本人达成目标的可行程度"。众所周知,每个人的步长(行走时两脚间的距离)都不一样,因此,可以采用"谁估算、谁执行、谁负责"的工作原则,没有人能代替得了当事人参考自身能力对问题的评价的主观性。

综上所述,偏差因主观所引起,客观就存在,不需要解决,也难以解决,甚至切勿解决。

本文整理自《研发效能100问》,原作者 费解

相关推荐
lunzi_08265 天前
【开源治理】05-把流程翻译成门禁:开源治理嵌入 DevOps 流水线实战
供应链管理·devops·开源治理
程序员老赵5 天前
服务器没有桌面?Docker 跑个 Chrome,浏览器就能远程用
docker·容器·devops
宋均浩5 天前
# pytest 的 5 个 fixture 骚操作,我用了 3 年才学会
devops
睡不醒男孩0308235 天前
云原生运维实战:高并发架构下的云原生可观测性、韧性降级与自动化干预体系
数据库·kubernetes·高并发·prometheus·devops·sre·缓存调优
爱学习的程序媛5 天前
DevOps 深度解析:从文化理念到落地实践
运维·devops
至乐活着6 天前
Docker Compose多服务编排实战:从零搭建Node.js+MySQL+Redis全栈应用
docker·微服务·devops·容器编排·compose
热爱运维的小七6 天前
深度解析|应用性能 + RUM + 拨测:现代 IT 运维的可观测性“铁三角”
运维·it运维·devops·apm·rum·网站拨测
A.说学逗唱的Coke6 天前
【大模型专题】AIOps + Loop 工程:从智能告警到自愈闭环的实战指南
运维·人工智能·devops
平头老王6 天前
CI/CD流水线设计 — 第1章:常见误区
ci/cd·自动化·devops·持续部署·持续集成
龙智DevSecOps解决方案6 天前
拥抱 Java 21 与 Spring Boot 4:Apache Grails 8 核心新特性与平稳升级指南
程序员·研发效能·jrebel·开源资讯