本文转载自微信公众号「木东居士」，作者木东居士 。转载本文请联系木东居士公众号。
为什么你的数据仓库项目推进不下去?
0x00 前言
最近很多小伙伴都来找居士咨询类似的问题：
- 我的数据仓库规范设计的很好，为什么大家却不执行?
- 数据仓库规范推着推着，感觉项目就凉了，不能持续?
- 老板看不到数据仓库的价值，不再投入人力了。
不同的团队会面临不同的难题，今天居士简单聊一下这几年自己亲身经历以及帮助一些小伙伴解惑后的一些感想。
废话少说，直接上正题。分为三个角度讨论：
- 体系搭建
- 业务理解
- 沟通管理
这三个角度，也是我认为一个每一个数据仓库项目负责人要具备的核心能力。下面分别从这三个角度进行分享。
0x01 体系搭建能力
说句心里话，大部分互联网公司的数据仓库，其实是不需要特别复杂和专业的数据模型的。
因此，大家要先有足够的信心去认为，你按照设计出来的数据仓库体系，是能cover住大部分业务场景的。此处可以去参考居士之前的数据仓库文章。
那么，为什么还要提这个体系搭建能力呢?
这里想强调的是，你对于数据仓库整体的规划和思考能力。切记不要纸上谈兵，搞一堆什么模型，什么分层，其实没有什么用的，不能真正解决问题的设计，都是假的。
抛开这些模型之类的乱七八糟的角度来看，居士举几个例子，这些例子其实能解决你很多问题，而这些方案带来的效率提升，就会让你能感觉到数据仓库的带来的价值。
记住一点，不要指望一种表设计能满足100%的需求，如果有，请告诉我。
一、Bitmap表
举个例子，用户活跃Bitmap表。
表结构：
- ds：日期
- uid：用户id
- day_act_bitmap：01010010101010，1表示当天活跃，0表示某一天不活跃
这么一张表，在day_act_bitmap字段里面存放用户的历史活跃情况，能满足绝大部分关于活跃统计的需求。
如果感觉不够，再在里面补充几个维度，再加个周活跃，年活跃，这不就ok了?
二、用户维度行为宽表
表结构：
- ds：日期
- uid：用户id
- 场景1的活跃次数
- 场景2的活跃次数
- 场景3的活跃次数
这么一张用户维度的宽表，又能帮你满足一大波需求
三、业务统计大宽表
类似前面的，不再解释了。
这种设计还有很多，就不一一列举了～
这些设计都不是多么严谨的模型设计，但是很有用，也能解决很多问题。大家可以把这些小trick整合到数据仓库模型设计中。
有了真正能解决业务需求模型能力之后，就是如何让大家执行了。特别是规范制定后大家不遵守该怎么办?一般有下面几种方式：
- 制定可执行的规范，一定是可操作的，不要搞太虚的，比如大家可以思考一下，自己的数据分层设计，能否明确两个层次的的具体差别是什么?能否做到可以不用思考按照规范就能确定分层
- 通过流程&管理手段保证执行
- 化系统化强制执行，不遵守不能建表，不能写入数据
具体用哪种方式就看具体的场景了。在大部分团队的前期，居士推荐前两种结合。
0x02 业务理解能力
抛开业务设计的数据仓库模型，都是在耍流氓。
这一块有挺多想说了，想了想也不知道该说什么了。简单聊一下换位思考吧。
假设你是一个业务产品经理。
假设你是一个数据分析师。
假设你是一个推荐算法工程师。
回过头看一下自己的表结构设计，靠谱不，合理不。
如果体会不到，就去找一些关系好的同事，看看他们在你的数据基础上做了多少工作才能让数据可用?多听一下吐槽。
为什么要做这些?
当你的用户对你的产出不满的时候，你做的东西是没有价值的，没有价值的东西是不能长久的。
所以，具备良好的业务理解能力是保证你的数据仓库项目能顺利推进下去的核心动力。
0x03 沟通管理能力
前段时间做过一次分享，提到了一个观点：如果一个项目失败了，90%的锅都应该在项目经理这里，而这90%的因素里面，至少有90%是因为沟通问题。
根据沟通的对象，可以把沟通问题划分为下面几个方面：
- 向上沟通
- 向用户沟通
- 向成员沟通
思考一下：
- 你多久和老板同步你的项目进度?
- 你多久暴露一次你的项目风险?
- 你的用户和老板是否认同你的项目价值?
- 你的项目成员是否能从你的项目中收益?
- 你的项目成员是否愿意跟着你干事情?
- 你是否定期组织项目团建?是否定期画饼?
- 你的项目有成果了，是否带上了项目成员?
- 你是否有请外部的数据仓库专家来进行授课? 相信我，专家意见，尤为重要!
上面这些是大部分同学的数据仓库项目推进不下去的过程中会遇到的问题。
抛开上面这些容易看到和关注的点，还有下面这些内容大家是否考虑到?
- 你的数据仓库项目，是否损害某些相关方的利益?
- 你的数据仓库项目，是否从某个侧面在diss某些同学的设计不合理?
如果考虑到了，该如何去解决?是否有经验?
以上都是沟通问题。
关于管理的问题暂时就不多提了，参考项目管理即可，关于项目管理的内容大家可以去考一个pmp的证书，证书没什么用，主要是学一些东西，再结合互联网的特色应用起来即可。
0xFF 总结
总结一下吧，从居士的角度来讲，当你的数据仓库项目推进不下去的时候，优先考虑的是沟通的问题，良好的沟通能解决大部分的困难。
优秀的业务理解是决定你的成果能被其他人接受的可能性。
最后，适当且合理的体系搭建能力，能助力你显得更优秀。
