提到维珍航空(Virgin Atlantic, Virgin America)大家常常会想到它大名鼎鼎的老板Richard Branson，它的帅哥美女乘务员以及标志性的红色。上次去美国乘坐维珍航空的经历，让我对Richard陡升敬意。

维珍航空的每个座位后面都有显示屏，坐着无聊就开始体验机载系统。点击到第五个按钮时，系统弹出了一个对话框：“对不起，这个功能还没有完成，请下次乘坐飞机的时候再次尝试”。

背后做了什么？功能很简单：一个计数器和一个日志，但是可以根据乘客的点击决定功能是否对客户有价值。

传统的开发团队和产品经理只关注于如何垒功能，甚至我听说有的公司以做出的功能数目作为绩效考评的主要度量指标，根本没有不在乎是否真的有人用。导致的结果是64%的软件功能根本就没有人用。新兴的以精益创业为代表的产品创新方法则不然，从一开始十分注重验证或者实证。通过到客户那里实证来获得第一手数据，从而决定功能实现与否。说白了就是“不见兔子不撒鹰”。

把验证和实现分离

在我见过的不少软件团队已经开始有意识地把验证和实现分离。实现方法通常是通常跟维珍航空十分类似。举一个例子，一次PO同学想要开发一个商铺有关的功能，主要是跟商铺打交道，但是说实话，PO对这个功能不是很确定，原因有两个：1 不确定这个功能是否有用，尽管竞争对手已经提供类似功能，但我们猜想很可能没人用；2 如果真有用，客户更喜欢什么样子的体验？不到一天时间就实现了一个弹出框、一句话、两个tracelog，直接上线。开始还会想是否在弹出框内提供选择或者让客户回答问题。其实根本没有必要，因为客户是登陆客户，作为签约客户，我们只需把它的ID记录下来，剩下只要给他们打个电话就可以了。

如果已经比较确定答案，是否还要验证？

当我跟团队介绍验证故事［这个概念］的时候，经常会有人问我这个问题，答案是NO。1928年R. L. Hartley发表了信息理论(Information Theory)，在信息理论中Hartley指出一个事情（一个事件）的信息量是它可能性（概率）的Log函数，所以［如果］可能性（概率）高和可能性（概率）低的事情（事件）对我们的信息量相对较低。而对我们而言，信息量最大的是可能性（概率）五五开的事情，［所以我们应该针对可能性（概率）接近于五五开的事情（事件）去做验证］所以我们最需要验证的是可能性（概率）接近于五五开的事情（事件）。

 

如何安排验证类的故事？

不少团队产品待办事项列表(Product Backlog)已经出现了验证性用户故事。通常PO也开始在为Backlog排优先级的时候考虑按照一定比例，比如在速率为60故事点的团队中，他们可能会有5点用于还清技术负债，另外的3~5点用于前瞻性的验证。

到哪里去了解更多如何去验证的方式方法？

意启(InnoLauncher)刚刚翻译发布了一篇很不错的关于如何去做验证以及客户访谈的文章“Validation Board – 走出办公室的利器”，强烈推荐。