如何优雅解释java又长又臭还流行
好了，这是标题党
我真正想写的是 信息熵 这个概念。什么是最好的编程语言，够程序员们吵上一辈子，java在很多人心里有这样的的刻板印象：
庞大、复杂、啰嗦、框架重、开发效率低、性能差……
如何优雅且不容辩驳解释java的优势呢？可以从信息熵的角度来解释，换个角度把“啰嗦”这个缺点变成“利于协作”这样的优点。
信息熵：信息的基本作用就是消除人们对事物的不确定性。信息熵是系统有序化程度的一个度量。
——引自百度百科的信息熵条目
定义看起来简单，但是用来赞美java还不直接，还是用语言的例子来解释：
中文就是一种信息熵很高的语言，有时候言简意赅，有时候容易误解，一词多义的现象非常常见。
甲：这是一点意思
乙：这是什么意思？
甲：就是意思意思
乙：这样就没意思了
上面的对话到底是什么意思？不在中国语境下，很难理解。语言中通常增加很多冗余信息，用来降低歧义和误解，达到准确沟通的目的。针对java而言，它的“啰嗦”带来了一个非常大的好处：提供确定性
- 项目人员众多，水平参差不齐，重框架提供了质量控制
- 啰嗦的语法，方便相互理解对方的code
- ……
总结起来就是方便协作，质量稳定，工时稳定，对输入资源要求不高
“啰嗦”就不能优雅吗？
啰嗦也可以优雅，白居易的诗老妪能解，童子解吟，如此平易近人，可以用信息熵低来解释，也就是在诗歌中增加了很多冗余信息，比如著名的《琵琶行》，也有用词的重复，但却是名句。
……，大弦嘈嘈如急雨，小弦切切如私语。嘈嘈切切错杂弹，大珠小珠落玉盘。间关莺语花底滑，幽咽泉流冰下难。冰泉冷涩弦凝绝，凝绝不通声暂歇。别有幽愁暗恨生，此时无声胜有声。……
重点是对细节的描述，将不同阅读者带入相似的场景，获得相似的体验。同样的，看高手的代码是不是也有这个感觉？
为什么一个产品经理要评价java？
同样的逻辑，还可以用来解释下面一些问题：
- 如何优雅解释PRD又长又臭还要写
- 为什么会议结论要反复确认
- 为什么同一个事情，要多次沟通
- ……
决策引擎的简明产品设计说明
决策引擎是什么？
决策是思维过程和行动过程结合的复杂过程，包括三个阶段：
- 抽象出对象特征，识别对象
- 通过规则或模型，诊断对象
- 根据诊断的结果，选择行动
决策引擎应当是承载业务思维过程和行动过程通用化工具集。在实际业务场景中，通常指支持第二阶段的工具，输入是一组对象及抽象出来的对象特征（即是变量），输出是针对对象的决策、标注、排序，被业务系统与映射到具体的业务行动中。
举例：
申请信用卡时候碰到的决策过程就符合这个结构：
- 将客户的基本信息输入，抽象出各中变量，如年龄、职业、收入、社交等
- 通过规则及模型，给出批准或不批准，批准多少额度的结果
- 选择后续行为，通过制卡/拒绝/需要补充资料的行动
什么样的业务需要决策引擎？
业务复杂性带来高决策成本和决策风险，需要决策引擎工具（本质上是效率工具）支持。符合以下特点：
业务链条长
- 决策场景多样化
- 参与角色多样化
- 业务对象多样化
决策引擎产品设计的原则？
通用工具适应个性业务
多样化决定个性化
决策场景多样化
- 人工干预 / 规则 / 模型 是个性的
- 外部限制条件是个性且动态的
参与角色多样化
- 决策标准和行动是有差异的
业务对象多样化
- 特征是复杂多变的
- 抽象成特征的方法多样的
工具属性决定通用化
- 本质上，决策引擎实现的是对业务对象的决策、标准、分类
- 结构上，工具可简化为规则、模型、人工干预三大模块（统计可作为附属模块）
角色化
- 决策过程中，不同角色权限、决策点、决策成本和收益、行为不同，输出结果应可回溯、可解释（机器学习模型有难度）、可修正救济
- 不同角色在不同决策场景下，需要获得的信息和使用的规则或模型也不同
服务化
- 提供接口层方便嵌入复杂业务流
- 不同决策的内容不同，可根据输出结果包装为不同小工具，作为服务输出
如何评估决策引擎产品的质量？
工具的质量评估：
- 服务稳定可靠
- 基础工具可灵活装配
- 方便部署
- 面向不同用户
决策引擎的实际应用？
金融风控决策引擎简明示例
| 营销阶段 | 贷前管理 | 贷后管理 | |||
|---|---|---|---|---|---|
| 服务 | 客户意向分析服务 | 申请反欺诈服务 | 信审服务 | 授信额度管理服务 | 贷后风险管理服务 |
| 规则 | 反欺诈规则组 | 风险预审规则 | 增信规则 | 风险规则 | |
| 自动化审批规则 | |||||
| 业务模型 | 客户识别模型 | 反欺诈模型 | 信审评分模型 | 行为分析模型 | 逾期预警模型 |
| 收益预估模型 | 收入模型 | 失联预警模型 |
决策引擎里的规则工具元素
实际业务中，规则引擎服务是决策引擎的核心之一，规则引擎包括一系列工具元素，像乐高一样组合成不同的规则服务：
- 规则/规则集
- 决策表
- 决策树
评分卡
- A卡（Application scorecard），常用于用于信贷审批
- B卡（Behavior scorecard），常用于贷后管理
- C卡（Collection scorecard），常用于催收管理
- 决策图
- 自定义函数与方法
怎么理解决策引擎里的模型
给模型一个简单的定义：
模型 = 算法 + 数据结构 + 参数值
针对模型的主要工作就可以分类如下：
- 调整算法
- 调整数据结构
- 调整参数，要求有良好的反馈机制，让业务结果反馈回模型
错过独角兽，不是“眼瞎”，而是读书太少
讲两个与我自己有关的“瞎眼”故事
一、打车APP
多年以前，从杭州来京办事的朋友润宇，提到自己公司在孵化一个打车APP，问我们怎么看，我当时的回答是这样：
1、从北京来看，高峰期打不着车，是因为的哥们都在各种偏僻的地方停着躲开拥堵不赚钱的时段，他们在挑活，而不是找活，供给不足，调度也就没有价值
2、做打车APP的项目很多，让的哥们安装难度太高，没有行政手段可能没戏
后来的事情大家都知道，资本开启的补贴大战，打车软件不只在做出租车调度，而是在做出行市场，供给一侧有海量的私家车进入补充。对了，那个杭州的打车APP叫做快的打车。
二、互联网电视
还是多年以前，我去小米面试，面试官是王川。王川问到怎么看小米电视（刚出第一代产品），我当时的回答是这样：
1、小米电视是硬件产品，用户的更新率低，一二线城市的年轻用户会倾向于购买更大品牌的，比如设计口碑更佳的索尼
2、电视是满足内容消费的，版权是竞争的关键，小米没有内容。硬件和内容都不占优，竞争力不强
王川讲解了他对小米电视的理解，回应了我的回答，获益匪浅，有一个说法印象比较深刻，“内容的问题，我花10亿能不能解决？”。面试结束时还问我，工资和期权会多要哪部分？我的回答是工资（实际上只是觉得周六要上班这一点接受不了），面试结果可想而知。
后来的事情大家也都知道了，小米的产品以一个生态的方式覆盖了生活的方方面面，专注在单个产品上，容易盲人摸象，看不懂更大的商业。
类似的故事还可以讲出来好多个，作为产品经理能经历变化万千的互联网世界非常幸运，而这两个故事我想说的是，互联网产品的竞争，从一开始就不是一个APP或一个硬件那么简单，背后的商业模式更值得去理解，我们每天在迭代的“产品”，是业务的载体，是产品的一部分。在遇到突然火起来的服务时，还是想想：
1、那些久经沙场的高手和饥渴的资本，不会投入一个不能盈利的领域的。新生事物困难多，否定太容易。承认自我认知的狭隘性，是接近真相的第一步
2、商业模式如何才可以逻辑自洽？如果找不到商业模式，说明超出了自己的知识框架，需要高人指点
如今做了好几年金融相关的产品，接触到了远比过去复杂的新零售业务，学会了从更丰富的角度看待商业和商业的阶段性策略，越发觉得知识结构对商业理解的重要性，也越发敬畏言简意赅的基本原则，技术、资本、政策、时势都深刻改变着产品，过去的自己，不是“眼瞎”，而是读书太少。
旧门店新业务——传统渠道入场互联网金融的思考
由来
不久之前，跟一位在传统领域多年的老兄，聊到了传统零售商入场开展互联网金融业务的话题，有了一点自己的思考，记录下来。
优势
这位老兄有非常难得的渠道资源：数以千计的门店、以万计的一线员工、数千万的注册会员以及长期积累下来的品牌。
- 门店的积累。选址多在人流集中的商业区，线下获客成本比较稳定。这类门店可以列为稀缺资源，新供给比较难。门店也提供了成熟的消费场景。
- 销售员工多且具备一定销售技能。虽然从细分领域起家，但是也尝试过跨界，还有不错的成绩。
- 注册用户积累时间长。很早就意识到了会员制的好处，虽然注册提供的基本信息较少，但是从售后服务中，获得了更多的消费信息。
- 品牌。作为一家年头较长的上市公司，客户信息度高。
误区
有几个误区在闲聊中被反复提起，并不是只有互联网从业人员才会注意到
- 迷信大数据。很多传统领域从业者，被各种大数据概念绕进去了，认为大数据可以替代传统的风控手段，在业务启动时，基于经验规则的方式，有效性远高于所谓大数据风控。长期来看，积累能够支持大数据风控的数据，以及建立能消化海量数据的技术和风控团队，都需要极高资金投入和时间成本的，是大玩家的战场。
- 信息错位。互联网金融领域所需要的客户信息，如信用、收入、工作等，通常不是传统渠道会员信息覆盖的（虽然复购率不低，售后信息完整）。注册会员数量虽大，金融信息密度依然非常小，需要外部数据补充。
- 控制感过强。传统领域从业人员对业务全流程的控制感非常强，希望没有盲点，容易出现用“信任”取代“专业”的情况，跨界人才稀缺和金融（尤其是风控）专业性较高，让识别人才变得非常困难。在计划开展业务时，与不同背景的人和团队多接触，才可能降低这种风险。
建议
对于这种想利用自身优势，入场互联网金融的传统渠道，有下面几点建议
- 流量换能力。前面也说过建立自己的金融团队有较高的资金和时间成本，为了更快开始尝试业务，可以同时接入多家金融服务提供商，尝试多种金融业务，通过流量合作来换取合作方的金融变现能力，建立金融业务认知。必要的时候，可以通过投资和收购来获取这些能力。
- 小样本测试。从自己的存量客户中，取出少量，交给不同的金融团队或者方案提供商来验证客户质量，也可以评估出来客户信息的缺失比率以及风控成本，结合获客成本（并不建议将边际成本视为零，而是用原有商业模式下的成本）估算投资回报率。同时可以评估合作方的技术实力和专业程度。
- 强渠道。优先引入高成长的合伙方而不是成熟强势的合作方，保持渠道的强话语权，在商业场景和业务流设计上，强化线下门店在获客和风控上的作用，用自身品牌覆盖合作方品牌，避免客户被合作方掏空。
- 资本合作。获得投资和投资都可以建立起共赢的关系，加快业务进度，时间成本是最大的成本。
- 建立防火墙。通过比较复杂的公司结构和业务结构，在本品牌和合作方业务之间，建立起防火墙，减少新业务对原有品牌的冲击。
新空间
线下渠道有店面优势，在金融和新零售的场景下，可以成为这些业务的“新空间”，变成一种平台化共享资源，减少消费金融和新零售新兴企业重复建设门店的投资，让新业务发生在“旧门店”里，旧瓶装新酒。