驾驭（三）衡量_可执行指标VS虚荣指标

以在线教学网站Grockit为例：
一、精益创业与敏捷开发的关系
1、各司其职：精益创业负责作出高质量的商业决策，敏捷开发负责高效地开发出业务要求的产品。

2、能不能把认知循环引入敏捷开发？
不能。认知循环要在敏捷开发之前完成，把学习的需求引入敏捷开发会影响这个流程的生产效率。

二、出创期的Grockit：
1、Grickit的产品或者说服务：
线上教育

2、一开始Grockit采取的方法：敏捷开发方式中的一种严格形式——极限编程
根据敏捷开发的标准做法，Grockit的工作是按一系列的“冲刺阶段”（Sprints）展开的，每个阶段即为一个30天的迭代周期。每个周期中，法布德会写出一系列的“用户故事”（一种从敏捷开发中借鉴的技巧），对那个月里要做的工作按轻重缓急排序。法布德的“故事"是从顾客的观点描述产品功能特性，而不是用技术术语描述新功能的规格明细。这样的“故事”能帮助工程师在产品开发过程中关注顾客的认知。
每个产品功能特性都用简明的语言表述，不管你有没有技术背景都能读懂。根据标准的敏捷开发方式，法布德在任何时候都能随意重新排列工作的优先顺序。随着他对顾客需求的深入了解，他可以在有待撰写的故事列表，即所谓“产品列表”中，变动工作内容。这种方式有利于调整开发方向，唯一的局限是不能打断已经进入流程的工作。所幸的是，每次故事撰写的工作批量很短，仅为一两天。
3、但还是存在问题：
但我觉得，法布德和他的团队对公司的进展有所疑虑。增长的数字是否真的由产品开发促成？还是出于其他的原因，比如报刊上对Grockit的报道？当我和团队成员开会的时候，我问了一个简单的问题：你怎么知道法布德排列的优先顺序真的有道理？他们回答说：“这不是我们部门的事。法布德作出决定，我们负责执行。”

Grockit被一个在新创企业中老生常谈的问题困扰着：我们怎么知道优先排列哪种产品功能？如何让更多顾客注册和购买？怎么把产品宣传出去？

那些衡量指标（顾客总数、回答问题总数等）让团队感到自己好像在进步，但实际上却没有取得什么进展。有趣的是，法布德采取的方法表面上看起来和精益创业的认知阶段性目标非常相似：他们先推出一个早期产品，并建立某种基准线衡量指标。他们有较短的重复周期，每个周期都以改善顾客指标的能力来衡量。
但是，Grockit使用了错误的衡量指标，所以企业并未取得真正进步。法布德不满意自己对顾客反馈的了解程度。
三、改变
1、衡量指标的改变
一是公司从关注总数指标转向以同期群为基础的指标；
二是从事后再找因果关系，改为把每个新产品的发布当做一次真实的对比测试。

2、对比测试
所谓对比测试就是在同一时间向顾客提供不同版本的产品。通过观察两组人的行为变化，对不同版本的影响力得出推断。
如果你想要测试产品目录的设计，你可以向一半顾客邮寄新版，向另一半顾客邮寄旧的标准版。为了保证结果科学，两份目录中的产品应该完全一致，唯一不同的是版面设计是否奏效，你就要追踪两组顾客的销售数字。
尽管对比测试常常被当作市场营销的特有方法，但精益创业可以把这种方法直接融入到产品开发中。

3、通过对比测试Grockit发现以前执着于改善的顾客交流工具意义不大，后来测试了单人学习模式再后来推出了可以选择单人或社群学习的模式。找到正途啦。

四、看板
1、用户故事
以前的“用户故事”是法布德自己决定的“产品列表”。
新的系统规则中，用户故事在带来经证实的认知之前就不能算是完整的。用户故事会按四种开发阶段归类：尚在产品列表中、正在开发、完成（技术角度上的功能完成），以及处于验证的过程中。这里的“验证”指的是“了解这个已完成的用户故事首先是不是一个好的想法”。
2、看板规则
“看板”规则只允许一定数量的用户故事存在于任意四个阶段中。随着故事从一个阶段进入另一个阶段，它被填入下一个阶段的方框中。一旦方框填满就不能再接受其他故事了。只有当一个用户故事通过了验证，才能从“看板”上移除。如果验证失败，发现这个故事是个糟糕的想法，那么和它相关的功能就会从产品中删除。
3、以看板规则为基础，根据已验证（经证实的认知）的量来衡量生产效率
（以前的工作方式是到达“完成”那一步就OK,无需验证）
最初的结果总是让人沮丧：“已验证”和“完成”的方框都被填满，已没有可能开展任何新工作。开发团队习惯只用完成故事的数量衡量生产效率，这时感到动弹不得。唯一再开发新功能的方法，是调查一些已完成但尚未被验证的故事。而这常常需要投入产品开发以外的工作：即和顾客谈谈，查看对比测试的数据，以及其他诸如此类的事。
很快大家找到了一些巧妙。一开始工作的进展走走停停，产品开发那里可能已经完成了很多工作，但接下来需要进行大规模的测试和验证。工程师们要想办法提高生产效率，他们开始意识到，如果从一开始就考虑了验证工作，整组团队就会有更多产出。
举例来说，为什么要开发一个不在对比测试中的新功能？在短期内可能节省时间，但到了验证阶段，却要花费更多时间来测试。同样，工程师不愿开发他们不理解的用户故事也是出于同样的逻辑。在老系统中，工程师只负责开发，至于为什么要这么做乃是后话。而在新系统中，那种行为无疑阻碍了生产效率：没有清楚的前提假设，用户故事怎么被验证？

五、Grockit的假设测试（以“懒惰注册”的测试为例）

六、其他（一些激动人心的句子）
法布德和其他梦想家不同的是，他没有不管不顾，死抱着最初的理想不放，而愿意把理想放诸实验之中。
一支严谨的团队可能会使用错误的方法，但一旦发现错误，则可以迅速调转船头。更重要的是，一支严谨的团队可以把他们的工作风格贯彻在试验之中，并且得到有意义的结论。