背景:

为适应不断变化的业务形态,各大公司纷纷提出中台战略,强调虚拟小团队的重要性,推动组织形态从树状固态结构向网状液态结构变革。虚拟团队依据非常具体的业务建立,周期短,人员变化快,传统的“上级命令-下级反馈”的管理方式变得成本极高。

基本问题:

人员在复杂协作网络中的节点重要性评价

基本假设:

  • 工作群(或其他因任务而存在的人群聚合体)是协作的一种表现
  • 单个人员的时间是固定的,通过工作群对外联系(链接)
  • 单个人员间对外链接的强度与链接数成反比
  • 多个人员之间的链接,由多个工作群产生关系叠加形成(将所有工作群视为平等关系)

使用pagerank算法得到人员在复杂协作网路中的重要性

  • 人员类比网页
  • 人员之间的联系类比网页之间的链接

需要考虑的问题:

  • 因为角色的不同,在协作网络中的重要性表现不同
  • 因为级别的不同,对协作的实际影响不同
  • 因为入职时间的不同,影响链接数

对策:

  • 相同类型的角色做对比
  • 相同级别的角色做对比
  • 相似入职时间的员工做对比

使用场景:

  • 同一个人员在时间维度的上重要性动态变化,描述成长曲线
  • 同级别的人员,在相同时间区间中的数值,作为工作重要性的参考
  • 相似入职时间的员工,描述成长速度

潜在场景:

  • 提供另一个维度的人力成本定价
  • 为新加入的人员设定默认值和重要性成长目标

只是一个思路,有资源有时间有兴趣的可以算算看结果

OFO的押金问题是最近几天的一个热点事件,有些朋友提出了使用区块链技术的解决方案,我想换个角度来思考,就是设计一个“云押金”服务,核心逻辑是:“信用不够,押金来凑”

金融是基于信任的生意,当红的创新都是通过技术和数据,让陌生人尽可能块且成本低的方式形成共识,达成合作。我们还有一种古老的形成共识的方式,就是“押金”。

信用与押金的比较

大数据征信有诸多好处,但是我想提一些缺点:

  • 形成信用的成本高
  • 有个人隐私泄漏的风险
  • 增信困难
  • 机构之间信用模型差异大,难以迁移

押金完美规避这些问题:

  • 货币是人类共识
  • 现金是匿名的
  • 增资容易
  • 同一个货币无差别,不同货币可交易

押金的缺点

押金是对风险的估价,多个合作就要多个押金,缺点是资金占用成本高,且收到押金的一方有挪用可能性,监管难度大。

“云押金”对押金模式的修正

“云押金”将一笔资金放在金融机构的账号中,锁定金额。在需要信用或者押金时,授权服务提供方可以在违约情况下划扣押金。多个服务提供方可以获得对同一个押金账号的授权,在押金不足以覆盖风险时,云押金金融机构要求补充押金,同时拒绝新服务方接入,通知其他已授权服务方。到这里,还是只是一个常见的“保证金”模式,并没有降低资金占用,下面要开始组合式创新了:

  1. 提供云押金金融服务的机构,可以在用户授权的情况下,使用押金做投资,比如接入相对安全的货币基金,让押金增值,为客户带来收益
  2. 使用区块链技术,让服务使用信息上链,部分解决隐私问题,通过智能合约来处理违约扣除等情况
  3. 由于货币无差别,用户押金可以在多家机构之间迁移,同质化竞争迫使云押金提供商提高服务水平
  4. 押金是集中的,金融监管的难度变低,也容易形成标准化的技术服务和金融服务

进一步推演,以降低个人押金金额为目标:

  1. 形成类似支付宝“相互保”以及“水滴保”这样的互助机制,极大降低金额,分摊押金风险,代价是“押金”是有损失的,可以通过投资回报来弥补
  2. 引入真正的保险来保证云押金的安全,同时降低押金金额,保障需要押金的服务提供方的利益
  3. 形成信用+云押金的混合模式,“押金不够,信用来凑”

“云押金”金融服务商的收入

实际上,银行是比较适合提供这样的服务的,所以商业模式非常清晰,可以收取服务费以及投资收益。

远景

让信用+云押金的混合模式,结合区块链技术被市场广泛接受后,带来一个直接后果,就是在海量的交易中,信用和个人数据会被更准确定价,为信用在个人之间的交易形成基础,在这个远景下,人人有信用,信用可定价可交易,信用押金自由配比互换,陌生人交易费用更低,交易又会刺激市场更重视信用,正向循环。

price-of-huya-stock

基本假设

头部主播的相关情况,可以看作网站大盘的基本状况。通过长期观察头部主播的数据,近似获得直播服务主营业务的收入情况,在财报发布之前,做多或者做空直播概念股,也可以用来评估非上市直播业务发展是否健康。

数据准备

  1. 取某一周 7 天,各直播网站的 top 1000 主播ID
  2. 将 7 天的主播打赏金额相加,取 top 1000,目的是减少误差
  3. 跑得到的各网站 top 1000 主播,在2018年全年中,每一天的打赏数据,包括

    • 打赏次数
    • 打赏粉丝数
    • 主播出勤天数

数据清洗

  1. 自充值识别
  2. 更换房间或用户名的主播识别
  3. 排除个别主播跳槽的小概率事件影响

数据分析

  • 主播相关,分析头部主播的捞金能力、流失情况、粉丝构成是否健康

    1. 各网站 top 1000 主播,在2018年中,每天获得打赏金额总数
    2. 各网站 top 1000 主播,在2018年中,每天活跃的主播数
    3. 各网站 top 1000 主播的流失情况

      • 流失的定义,在2018年11月1日至统计当天,期间没有上线的主播数
    4. 各网站 top 1000 主播,打赏的粉丝数

      • 单个粉丝打赏金额的分布
      • 与上月相比,每月新增的打赏粉丝数
  • 粉丝相关,打赏不集中到少数人的更健康

    1. 各网站,每天打赏的笔数
    2. 各网站,打赏粉丝去重总数
    3. 各网站,单个粉丝全年打赏金额的中位数
  • 推广投放能力,网站获取新流量的投入,近似拉新能力

    1. 各网站APP,在应用宝、360手机助手、小米应用商店的排名,取统计当天(有历史的数据更佳)

数据结论

采集到了某一周虎牙 top 1000 主播的打赏情况,不同主题的主播收入构成差异比较大,头部主播集中了主要的收入,从各直播服务的收入总量看,陌陌、快手、抖音领先比较明显,虎牙和斗鱼主播量级差不多。

采集和建模都在优化之中,数据积累的时长也不足以用于观察趋势,就只公布一下虎牙头部主播的一些数据,后续继续分析。

huayatop20

现状说明

已经有北京、贵阳、上海、广州、天津、杭州、深圳、海南全境实施了限牌政策,这些省市的购车难度加大,催生了一个购牌租牌的地下市场,看起来还相当活跃。

通过假结婚过户车牌的方式,时间成本非常高,在这里就不做探讨,主要聊聊长租车牌的地下市场是怎么运作的。

北京2019年会实施更严格的限制外地车牌上路的政策,预计地下购牌租牌市场会更活人,目前可以获知的租牌方案主要有以下几种形式:

年限价格要求风险控制
3年3万-4万持牌人持行驶证+高额三者险车辆抵押给用车人
5年5万左右持牌人持行驶证+高额三者险车辆抵押给用车人
20年(买断9万-10万正常用车人持有牌主身份证(20年有效期)
二手(买断)取决于牌主身份证有效期正常用车人持有牌主身份证

由于车辆会过户到持牌人名下,对双方来说都存在一定风险

  • 3-5年的租约形式,持牌人会保留机动车行驶证,保证在租约结束后可以取回车牌,同样的,车辆抵押给用车人,也保证了持牌人无法处置车辆,保障用车人财产安全。
  • 20年买断的模式,通常持牌人都是离开北京或是长期不使用车牌,所以会提供一张20年有效期的身份证给用车人,方便车辆购买保险、过户及报废,通常不要求抵押(解抵押需要双方到场,难度大)。虽然这张身份证会挂失,但依然存在身份证被滥用的风险。

改进可能

不足之处主要体现:

  • 现存的地下市场中,中介承担的是居间撮合的角色,风控手段单一且存在风险
  • 费用通常需要一次付清,加上车款,给一些刚需用车带来经济压力

改进模式实际上可以简化描述为:

融资租赁回租模式+P2P租车

  • 引入融资租赁公司,实现对车辆的融资购买及控制
  • 引入P2P租车服务,实现持牌人和用车人的租车协议
  • 引入资方,提供购车资金

模式如下:

地下租牌市场改进说明

增加的几个公司实体,目的是提供信用服务和资金服务,让无信任关系的持牌人和用车人达成协议。由于公司实体通过融租协议控制了车辆,且利用外部资金方提供了融资服务,分别维持跟持牌人和用车人的联系,在信息中介、助贷、贷后管理、保险、保养等多个点都可以提供服务获得利润。

改进模式的缺陷

  • 改进仅存在可能性,合规性不足,依然是地下产业
  • 用车人逾期,需要处置持牌人名下车辆,存在瑕疵,需要其他协议
  • 缺乏合理的贷款场景,且金额较大,对资金方而言有监管风险

其他

车牌供给受限实际上是路权供给稀缺的表现之一,在道路使用率是否达到了最有效率很难评估,很多经济学家是比较支持通过拥堵费来解决的。改进地下市场的交易模式是个脑洞,如果把本来是商品的不当商品来看待,就会产生其他的“市场”来解决问题。如果从供给曲线来,地下市场的车牌供给量会随着价格上升增加,车牌变成了一种可被免费获取的资产,参加摇号的人数和电动车排号的人数只会越来越多,其中用车需求更强烈的人,更难得到车牌。

政府是否可以提供一种年付租金的车牌来调节车牌供给呢?

基本上在抄袭《笨办法学python》和《io语言手册》

练习0. 准备工作

练习1. 第一个程序

练习2. 注释和“#”井号

练习3. 数字和数学计算

练习4. 变量

练习5. 更多的变量和打印

练习6. 字符串和文本

练习7. 还是赋值、拼接和打印

练习8. io语言的基本概念-原型

练习9. io语言的基本概念-都是对象

练习10. 读写文本

练习11. 读取目录中的文件名

练习12. 复制文件

练习13. 再来聊聊原型、对象和方法

练习14. return返回

练习15. List列表和map散列

练习16. 操作字符串

练习17. if条件表达式

练习18. 其他条件表达式

Io语言入门

结束