数据少就撑不起量化管理吗？

很多时候在我问及为什么不做量化管理决策时，“我们没有那么多数据啊！”成了堂而皇之的理由。数据量不大就真的不能做量化分析？不能帮助管理者优化决策过程吗？答案是否定的，我们很多时候依靠直觉的判断其实是错误的。小的样本点也能给我们带来有价值的信息，一样能发挥重要作用。

五个数据的作用

 老习惯，理论之前，实例先行。
 华为有10万+软件工程师，如果任总想快速了解人均每月大致能写多少行有效代码，他的助理只需随机联系五个程序员，知道他们上个月提交了多少行有效代码。假设结果分别是220, 300, 250, 320, 275，那么她可以告诉任总：华为软件工程师当前人均每月开发代码行的中位值在220到320之间，可信度高达93.75%。对一些概率常识还有印象的朋友可以算一下，欢迎在留言处给出计算过程。

    在做CMMI评估时，这是我确认内部优秀实践常用的方法。有家国内知名IT企业，近2年在小范围里推广DevOps。他们没有花精力度量效果，评估组随机找了几个DevOps项目，查询它们几个关键交付数据，算出范围并和之前的基线做比较，仅用了一个小时的时间就拿到了数据并给出了投入产出比结果，帮助管理层判断是否值得在更大范围内推广。

记得多年前做度量培训时，我问大家只有五个数据的样本点是否具备统计意义（statistically significant），一半斩钉截铁的说数据量太少，不具备；另一半不发表意见。其实真正理解什么是统计意义的软件工程人员太少了，直觉往往是错误的。有时候少量的数据也能帮助我们获得有价值的信息，消除一些不确定性，帮助优化决策过程。
 

一个数据的价值


有次和某个组织EPG负责人聊同行评审，我问她，你们设计评审能发现严重设计缺陷吗？她愣了一下，说这个还真不知道。我让她联系下最近刚做了设计评审的设计人员，看看他们是否至少发现了一个严重设计缺陷，对方说这次评审没有发现任何严重设计问题。我告诉这位负责人，我说我有75%的把握判断，你们大部分的设计评审都没有发现任何严重设计缺陷。也就是说大部分设计评审打不到粮食，需要分析一下原因，要么改进方法，要么有些项目就不要做技术评审了。她怀着对我推论的严重怀疑，后面自己去项目里做更多了解，果然发现近80%的设计评审没有发现严重的设计缺陷。
  其实这里是一个“单点多数分析方法”：如果只有黑或白两种球，随机抽出一个黑球，那么就有75%的可能性，超过50%以上的球（大部分）是黑球。这个问题复杂些，欢迎在留言处分享你的证明。

 由此可见，某些场景下，即便一个点也能帮助我们消除一些不确定性。

3-5个数据就可以开始做基于基线的异常分析
 
估计许多做过CMMI四级、五级的朋友都看过“度量软件过程”一书，其中用XmR Chart计算基线、做异常分析成了绝大多数高成熟度组织建立、使用过程性能基线的标准套路。大部分朋友只记得如果要让基线达到稳定状态，大概需要45个点左右的数据。但很少有人记得作者曾强调，有3-5个点，就可以开始使用基线，随着数据的增加不断修正上下线，我把这个过程称之为“charting the chart”.我非常同意作者这样一个观点：在软件项目中使用控制图做统计过程控制，目的是通过异常点分析，识别出影响过程结果关键因子，帮助我们找到控制的关键点，改进点。稳定不是目的，控制好偏差实现过程价值最大化才是追求的目标。
 少量数据也能开启我们实现CMMI四级量化管理之旅，通过数据积累实现关键过程的有效控制，保证项目核心质量及其他关键目标的实现。


软件、敏捷需要灵活简便的度量


 今天，软件工程中VUCA（volatility,uncertainty, complexity and ambiguity –波动性、不确定性、复杂性和模糊性）达到了前所未有的程度，这也意味着“历史数据”的时间维度更加敏感，很可能去年的一些数据已经失去了参考意义。而我们需要关注的指标也需要不断变化，这就意味着度量也需要敏捷，需要新的指标的支持，需要重新实时收集、分析数据支持重要决策。在这种情况下，我们不可能指望收集到所谓“足够”的数据。
     我在一个有3年敏捷史的团队做过一个实验，在团队做估算时，先用前面两年的velocity数据规划版本、迭代；再用最近五个迭代数据作为依据完成规划，两者相比，后者和实际更加接近。

 
 数据少不是事，关键是度量正确的指标，使用恰当的方法，数据支撑的决策一般优于直觉驱动的决策。
因为直觉是有选择的，而数据是客观的。