不仅游戏，所有提供虚拟产品的场合都需要应用“造物者”思维模型，制衡各方利益，引导体系演进。我曾负责设计过一个复杂云服务产品的计费策略，深有体会。

　　简单介绍一下，这个云服务主要用于对上千张表、上P的数据进行复杂的计算。典型的一次计算任务，往往占用上万节点几十个小时，说耗费的存储、计算和下载流量成本超过几十万元。麻烦在于，系统不是独占的，往往有上百个用户的不同计算任务混在一起。

　　如何计费？常规思路往往从技术实现角度拆分，把一次计算任务占用的进程、内存，以及中间IO交换的数字都拿出来，分摊到对应的CPU、内存、网络设备和磁盘的折旧成本去。然后再加上一定的利润率。

　　然而，想深一点的话，这种计费策略并不好：

　　1> 从用户角度看：“运行时间”这个变量用户失去控制。海量数据的分布式计算有特殊之处：很可能第一次运行用10分钟，重跑一下，调度到另一个节点，就用了12分钟。相同的计算任务，有时收1块，有时收1.2块，用户疯掉了。

　　2> 从平台角度看：如果技术团队优化了底层系统，把计算速度加快1倍，收入就少了50%。这会让平台方丧失优化动力。

　　于是退回原点，先定义什么是好的计费策略：

　　1. 基于统计，简单可解释：基于统计；尽量简化；输入参数用户可控；

　　2. 可预期，可重复：实际运行前就能算出花费；同样的任务重跑，价格不变；

　　3. 正引导性：各个角色做好事（优化自己的代码）不受惩罚，最好获得奖励。

　　一个例子是手机话费：两个人面对面手机通话，与一个在城南一个在城北通话，实际成本肯定不一样。如果运营商按照通信链路经过了几个路由器、几次转发来计费，用户就晕倒了。所以手机计费策略采用阶梯的、区域的、分时的模型，符合上面3条原则。

　　最终的计费模型主要由“输入数据量 * 复杂度”组成，其中“复杂度”是一个简单的阶梯表，完全取决于用户计算作业的难易程度。（更多参考 http://wangleheng.com/2014/07/odps_meter_money/）

　　几乎同时，谷歌公司推出了同类产品Google BigQuery，计费方案和我们几乎一样。他们甚至在官网上贴了一篇BLOG，详细描述了计量计费模型的“设计哲学”。大家彼此完全独立思考，得出的方法论和最终模型却殊途同归，这很有趣。

　　总而言之，无论是复杂云服务、电子商务平台……都需要谨慎设计利益策略：尽可能简化规则，保证统计公平性，对“好事”建立正反馈。必要时，不妨参考经典电信服务的计量计费策略。

　　这一期4个思维模型都和投资者有关，重点都是建立模型并遵守纪律。如果在复杂背景下进行跨领域博弈，这都是好工具。然而，大多数人不是职业投资者，最好弄清楚模型的适用边界，保证独立思考，以防东施效颦。

　　亲身经历，作为创业企业的联合创始人，我就有几次郑重提醒自己的CEO：你负责融资，和VC打交道很多，似乎被他们的模型“过训练”了。

　　举个例子，这些年很多风险投资人都在强调“网络效应”的概念：不仅仅企业和客户存在买卖关系，客户之间也能互相连接，进而增加系统粘性。对资本而言，这种生意可以通过烧钱进行催化，最终通过网络规模建立垄断。很多投资机构把“是否有网络效应”写入模型，以决定标的估值。

　　“网络效应”的思路适于 toC 基础服务。进入其他领域，例如 toB 企业级服务，情况就变了：

　　1. 从业务逻辑而言，企业不太可能因为同业或上下游的公司在用某个软件，就非用它不可。甚至恰恰因为是同类企业，所以存在关键需求的差异：竞争对手强调品牌营销，我强调供应链降成本……这意味着，对手的软件供应商未必合适我，应该寻找符合自己战略的解决方案。toB 采购更强调“标杆效应”：供应商的方案与企业本身的策略一致，且已有成熟的落地案例。

　　2. 从产品逻辑而言，“网络效应”本质还是增加迁移成本。但并非只有这一条路能增加产品粘度。大多情况下，做好功能和服务，解决客户问题，让他没有离开的动力，就够了。尤其是toB 场景，没有企业会乱折腾，轻易迁移软件系统。

　　回到投资者的角度。他们喜欢建模，简单点说，就是外行总结过去的成功经验，以筛选更多投资机会。模型就意味着抽象概括。投资者有机会多次下注，只要掌控概率就够了，创业者却是All in，因此必须洞察每个关键细节，细节是魔鬼。

　　淘宝免费，不符合“产品必须收费”的陈规；京东做物流，不符合“尽量做轻”的陈规……随后，投资人跟随成功创业者修改了自己的模型，然后又对下一代创业者说：“你必须XXX，我才投你”。

　　总结一下，专业人士要相信自己在客户现场获得的洞察，不要屈从陈规俗见，不要被投资界的模型过分“驯化”，导致动作走样。我们最该从巴菲特和索罗斯那里学到的，正是独立思考本身。

一、背景

　　阿里云目前占国内云计算市场50%以上，全球三强，近几季度保持高增速。

　　然而2010年常见说法是：百度擅长技术，腾讯擅长产品，阿里擅长运营。阿里的技术形象并不吸引人。

　　如何从电商公司转型为数据公司？这期间，我恰好在阿里云大数据团队做产品经理，分享一点“转型者”的亲身体会。

二、做了什么

1. 明确“数据为王”，巧妙包容原有主力业务

　　2010年马云在国外讲演，“我们的云和别人不一样，核心是数据。”今天看来，他在试图解释“大数据”概念，此时big data这个词还没有在美国诞生。阿里内部很早建立共识：判断一件事是否重要，标准是“数据”。

　　“数据为王”的战略与“让天下没有难做的生意”企业使命不矛盾。同时新的价值体系能包容原有业务：什么业务能产生含金量最高的数据呢？淘宝、支付宝……因此原有主力团队也会兴奋的加入进来，重新从数据的角度讲故事。

2. 用各种方法保护新业务

　　早期阿里云不成熟。广为人知的事是2012年内网几千层楼的帖子，对王坚博士万炮齐轰。当时公司做了几件关键的事：

　　1> 把阿里云和其他团队隔开。（如果微信团队没和总部隔开会怎么样？）

　　2> 培养生态系统。团队被反复强调的纪律是，如果客户在做同样的研发，不要抢饭碗，往后退，一直退到没人愿意做的苦活累活。只要他们愿意迁移到云上来。

　　3> 最难的时刻动用组织手段。例如让陆兆禧当CDO（首席数据官），内部都知道老陆已被定为下一任CEO。

　　最终，发动所有协作力量，把主要数据和业务都迁移到了云上。

3. 构建数据中台，上云没有回头路

　　业务上了云，如何保证局面不后退？最关键的是建立数据中台。前台业务产生的核心数据，全部收拢到一处。业务只有留在云上，才能获得基础设施和关键数据的支持。具体内容媒体报道很多，搜索“5K项目”。

三、结论

　　阿里云是一次成功转型。个人认为以下因素是关键：

　　1> 明确“数据为王”的新价值体系，巧妙包容原有业务；

　　2> 用各种手段保护新业务，建立协同；

　　3> 建立数据中台，让业务没有回头路。

　　转型的复杂性要高于初创。要谨慎设计，要耐心推进，要在艰难时刻顶住压力。