最近与客户的PO同学一起对刚刚做完的一个项目做了一下回顾。这个项目的目标设定、结果以及度量很有启发。因为涉及一些业务机密，所以不会十分具体说明是什么业务。
项目的背景：
针对原有系统的客户结算方式作出调整，因为
- 原来的结算方式对于客户有风险
- 同时增加了维护成本
项目启动前期：
在该系统第一个版本时，PO同学取过销售数据，通过数据来看按照该结算的需求并不多，因此搁置了这个功能。但是系统上线后，发现出现了有很多这方面的需求，而且都是大客户。PO获取了不少这方面的数据。决定要启动该结算项目。
目标
项目启动前，与PO一起讨论的第一个问题就是，这个项目的目标是什么？因为客户是一家商业公司，每个团队做的事情，都要跟钱相关 (IRACIS, Increase Revenue, Avoid Cost, Increase Service)，从字面上来看，该结算方案肯定不是一个目标，它只是一个方案。分析了要解决的问题后，很容易就找到了项目的目标。
- 减少与竞争对手在尤其是二线城市的市场份额差距
- 提高销售量，尤其是在二线城市
- 降低编辑成本
度量
我们原来的作法是收集数据，然后分析数据，通过数据来支持新的功能点。这种做法会有几个问题。
- 确认偏见 (Confirmation Bias)。在《黑天鹅》一书中，Nassim Nicholas Taleb讲到，人们如果“认为”一件事情是真的，他收集到的一切证据都会为这个论点服务。但是回想当初，在第一期项目时，收集数据证明我们不需要该结算方式，但是半年后我们发现并不是我们当初想象的那样。
- 数据与目标无关，也会导致新作的功能其实对于实现业务目标并不重要
有了目标之后，相应的需要设定一些衡量指标来证明我们开发的功能确实在帮我们实现目标。而且要注意的是，在此之前，团队很少预设度量，而且是针对未来数据的度量。更多的是根据过去的历史数据去分析，相当被动。因此我们的度量要是：
- 跟业务相关的
- 针对未来数据的度量
- 要衡量影响而不是产出（也就是做出来的功能）
我们一起为结算项目的目标设定的度量包括：
主观度量
- 客户满意度
- 销售满意度
客观度量
- 合同，套餐数量 – 这可以反映客户是否有意愿跟我们签约或者续约
- 消费量 – 反映该功能是否能够帮助消费者下决定购买点评的团购
结果与数据分析
该结算功能于八月份上线，PO同学于十月份针对最初设定的度量指标做了验证。
主观度量
- 销售满意度，符合预期
通过电话访谈三地的三个销售，该功能都能够解决他们手头的一些问题，甚至一个销售提到“该结算功能对销量帮助很大。销售还推荐了一个成功案例。”因为这个功能，在与某竞争对手在某一重要商家竞争中，成功扭转了竞争劣势。
- 客户满意度，符合预期
我们是通过合同数来推算的，合同数量同比增加50%
- 维护成本下降，我们是通过合同数来推算的
通过合同数与套餐数的变化推断出来，尽管合同数量增长，套餐数量下降20%
客观度量
- 合同数量增加 ，符合预期
- 套餐数量下降 ，符合预期
- 销售量提升，不符合预期
为什么销售额没有像预想那样提升？
针对这个问题，PO同学进一步分析了数据。有几个原因：
绝大多数新合同都是在九月份签的，是新合同，而我们对于销售额是从八月份开始的
下一步计划，进一步监控收集数据
新合同客户与旧合同客户重合不多，其中一个重点客户刚刚上线。
意外的收获
最初结算方案中有三个“很重要”的功能，分别是：
- 开发票
- 打款短信通知
- 旧合同数据迁移
该结算方案上线后发现基本没有对于这几个功能的Complaint，很好的消息，我们可以先不做了。
