想到啥写点儿啥，关于公司，关于数据，关于团队的一些想法，看法。
在创业公司工作是一件很有意思的事情，有乐趣也有挑战。
严格来说，这次是第2次在创业公司了，先说说第一次那短暂的经历吧。
互联网金融
故事发生在2015年，还记得那是个流火的七月，我们一行三人，顶着热浪走进了一栋大厦。跟未来的老板聊了一下午，主要是听他说，说公司的现状，说这个行业，说着未来的愿景，说着上市计划。“风口行业，可以试试”，“有实体产业，而且是大集团，可以”。就这样，我们入职了这家互联网金融公司-东虹桥金融在线。
集团是做电缆起家的，我们这家互联网金融公司也是依托于一家小贷公司，做了有5年了，我们属于小贷公司的线上平台，平台也是刚刚开始。我们入职后开始着手业务的梳理和数据平台的搭建，数据量很小，目前业务也简单，为了快，我们直接就使用MySQL来当数仓了，其中一个同事着手搭建Hadoop平台，后期迁移到Hive上。
以前对金融行业不了解，对这种互联网金融更是一脸懵，空的时候就研究下，发现我们公司的收益率由25%+，投资后还送加息券什么的。要知道那时候余额宝的收益率也就是8%、9%左右，这个让我很是震惊，投点儿？不敢，太高了，不投？这个羊毛不薅，对不起自己啊。
其实，一开始我对这个行业不太信任，收益太高了，高的吓人，后来持续关注了一下市场，和我们公司标的的投资情况，都是很快就满标了，还款也是按时的。差不多一个月后，我也开始薅羊毛了，羊毛党这个词儿好像就是这个时候出来的吧。
回来说重点，说说数据。对于当时的平台，只有两部分数据，1个是用户行为数据，1个是用户交易数据，所以我们也只做了：
- 平台指标梳理，明确指标定义
- 梳理构建基本维度：日期维度、区域维度、性别、年龄维度、投资金额段维度、投资次数维度、渠道维度
- 构建基本宽表
- 用户来源分析、活动效果分析、用户画像、用户积分模型
- 基于Echarts搭建数据可视化平台
在这家公司其实算是从零开始，搭建了基础的数仓模型，和一个可视化平台，关于分析也就是搞了个用户画像，然后基于画像输出了一个用户积分模型，给用户分级用的。
这家公司的创业氛围不明显，可能是依托集团的原因吧。当然，我们还会额外兼职些别的任务，公司是主打“互联网金融+电影”，所以有时候需要地推宣传，我们也会被派些任务。公司不仅投资拍电影，还搞演唱会，当时有很多的标的都是投资送电影票，送演唱会门票。
可惜啊，就是电影的原因，出现了问题，16年《叶问三》上映了，公司投资了，结果爆出来虚假票房，这是个导火线吧，后来集团下面的一家线下理财公司爆出来资金链的问题，出现大面积挤兑，烧着烧着，就烧到我们公司了，再然后，公司就凉了，再然后就开始裁员了，然后我们组就拜拜了。
历时9个月左右，互联网金融的工作截止，感觉以后不会再去这个行业了，金融这个东西，水太深，要去就去大公司，小的真心不推荐。
新零售
2015年是互联网金融的风口，2017年是新零售的风口，最明显的是无人货架的风口，一批一批无人货架公司站起来。
在这一年，我又走进了一家新零售公司“猩便利”，高管团队是阿里的、美团点评的，一出生就带着明星光环。记得是10月份来面试，当时公司还是在Wework，办公环境偏开放式的，很有趣，那没有前台，只有一个大吧台，第一次去有点儿蒙，这是个啥公司，给HR打个电话，就在沙发那等，看上班的员工来来往往的，端着咖啡在吧台讨论，热火朝天，欣欣向荣。
然后我就来这上班了。公司主营业务是“无人货架+无人便利店”，走的是即时消费。刚去的时候，数据组有几个分析师，本来也是奔着分析师岗位去的，但是说让我先把数仓搞搞，出于对这个行业，对这家公司感兴趣，依然来了，着手数据平台的整体搭建。
- 数仓从零开始
离线平台使用的是阿里云的Maxcompute，直接可以快速使用，省去了自己搭建平台的成本。当时公司的业务发展很快，9个门店+几万台货架，大大小小有几十个系统。
数仓这个东西一方面是业务理解，一方面是建模思想。
面临的挑战
针对这些挑战，我们考虑相应的解决方案，现在回过头去想想，很多地方当时做的不太好：
- 规范制定的太少，推动没有盯住
当时只是简单的制定了数仓的分层结构，任务和表的命名规则，任务开发规则等，还是有很大的灵活性，导致后期团队人员越来越多，全都自由发挥了；加上后期没有对每个人的开发内容做审核，更加剧了这种情况。
项目初期，定制详尽的规范，不断完善，并且制定相应的开发流程，做好审核工作。当然，这回耗费一定的时间成本，但绝对是值得的，不然后期项目一定混乱不堪，重构的成本更高。
- 没有忍心对历史项目进行重构
刚去的时候，数据分析师已经在做一些常规的取数工作，一些报表开发工作了，有一些日常的任务和表。开始想着历史的就算了，新的按照规范来就好，结果导致后来这些项目还不断的在使用，类似不符合规范的表也依然会出现（监督审核工作不到位）。
在和业务方沟通了通知机制，催他们完善表结构信息、ER模型，梳理完业务后，数仓模型也逐步搭起来。因为人手的问题（就我一个了解数仓），其他都是些分析师，所以我带着几个分析师一起搭建模型。
分析团队当时是这样的，按照业务线分成了货架团队和门店团队，老大的意思是让我分别花几周的时间带他们做。
一边熟悉业务，一边带着几个分析师搞dwd层，就是些明细宽表。记得老大总问我：“业务频繁变动，数仓该怎么做才能保持稳定”，是，创业公司嘛，业务迭代是快，老版本的表结构、业务流程刚梳理清楚，新版本要上线了，经常出现这种情况。
处在业务发展扩张期，这种情况很常见，所以我说的是，尽量只搭建相对稳定的模型，dwd层可以多处理些，集市层应用层可以临时处理。
按照我以前的经验来看，数仓的搭建流程是这样的：
- 梳理当前业务，梳理日常出数据的指标、报表，输出指标字典、维度字典
- 梳理库表模型，最先搭建可以输出上面这些指标和报表的模型，然后进行数据校验，切换使用的表
- 完善数仓模型
刚去的时候，我就说要梳理个指标字典，被否了，结果到现在也没有一个完整版的全公司指标。
第一版的数仓就在这个跌跌撞撞，不断摸索中进行着，后面团队进行了拆分，拆成了分析组和平台组，也招了几个了解数仓的人。
中间一段时间，我们有点儿走偏，为了配合做数据产品，我们花了很多的时间做数据需求，主要任务分布：
主要任务
我们就在完成这些需求的同时去优化数仓的表，这个过程很累，每天都很忙，忙的要死啊。由于团队分开了，老大不同，前面提到的问题更加剧了：
- 分析团队又搞自己的规范，和之前有些不一样，并且没有按照一开始的设计进行开发，对新员工的培训不彻底，导致平台的表越来越乱
- 团队内部沟通也欠缺，大家都在忙，每个人对接不同的业务团队，每人一块，很多人踩的坑没有及时分享，好多人重复踩；做的事情输出的模型也没有分享，导致每个人都有一套自己的逻辑。
这其实陷入了一个怪圈，恶性循环的怪圈，团队内部一定要多分享、多沟通
......
公司的发展，中间也出现过问题，就无人货架来说，最重要的就是“盗损”，开放式的架子，付款全靠个人自觉，这个本身就是不靠谱的，17年为了铺量，在几十个城市有铺货架，倒损情况非常严重。17年大量无人货架公司涌入，在18年初就出现了倒闭潮，这个时间窗口太快了。18年也是资本寒冬，年末各种公司裁员，我们也不例外。
总结
在创业公司做数据，还是很有趣的，可以接触到不同经历的人，学到很多的东西；
有试错的机会，可以放开手脚去做，只要你有想法；
可以锻炼自己的执行力、主动性；
有挑战，有机遇。
网友评论