01 战略篇

为什么会写这篇文章?是因为做了一段时间的企业数字化工作,发觉不是所有的地方,都已经做好了一个数据平台,等你来大展身手。更多的时候,你是来到了一片荒漠之中,把过去那些已经做的比较成熟的事情,重新的再做一遍,就像游戏开荒那样。因此,如果快速度过0-1的过程,从1开始发挥自己的价值,就显得很有必要,这是一个战略问题。
其实,数据在没有积累到一定程度时,是很难发挥出它的智能价值的,也就是数据平台的发展,绕不过“看数”的阶段。只要业务成熟到一定程度,数据才能发挥出它的增值潜力。就像石油,我们都知道它是“工业的血液”,但中古时期的人们,除了战争,就无法有效的利用石油。但数据积累到了一定程度,就不能只玩数据本身。还是石油,能够分练出很多的有效产品,写很多的论文,但如果不能用在汽车、飞机上,就不能发挥出它的最大价值。
因此,在战略上,我们首先要重视0-1的过程,就要像军事那样筹备一场场的战役:“打仗,打的就是钱粮;数据,比的就是人力和机器成本。”如何在最短时间内,把石油精炼的体系给做出来,保证工厂能够长期稳定运行,是首要的目标。
毕竟,不论是做数据行业的人,还是用到的大规模机器,都是一笔不小的开支。
其实大多数的从业者,都心心念的希望能够做一个比较不错的项目,能够帮助客户或者用户挖掘出数据背后的价值,但现实却是,我们面临的往往是基础性的工作:看数。所谓的“看数”,大体就是一个数据产品的雏形,包括非常多维的数据分析、下钻等功能,再配合几个简单的分析模式,成型了。
但,做好一个数据平台,仅仅依靠自己的力量是不够的,还需要跟前端、运营、算法、分析师等岗位结合,把数据炮弹送给前方,仗才有的打。例如缺少了前端,平台的体验肯定是个问题;缺少了运营,平台推广不出去,直接价值就产出不来;缺少了分析师,指标体系做的就只是个空壳子;缺少了算法,智能肯定就谈不上了…… 所以,数据平台,更像是搭了个场子,欢迎大家都来使用,发挥群策群力的力量。
这就决定了,几乎没有什么平台,是一开始就做好了,都是先随着业务跑起来,再逐步的把基建夯实。但因为业务总是做不完的,平台也不会覆盖所有的case,因此最后都将迈向做业务的终极目标:提效降本
所谓:提效降本,简单讲,就是把尽可能多的业务过程,自动化掉,把人均能做的工作量、运营背负的KPI,用数据工程的力量,来提升一个档次。同时,我们所消耗的资源,不论是人力还是机器,要尽可能的小。
既然所有的价值,都要回归到“提效降本”上,其实是说明,这世界上本就没有那么多的价值去做,基础科学不突破,地球舰队再庞大,终归不是水滴的对手。

02 策略篇

讲完了战略,再讲策略,就是我们到底要做什么?
做什么,最好要有个参照物,假如你是一家互联网公司,阿里云就提供了大数据三件套:Dataphin + Quick BI + Quick Audience,这个是官网能够搜得到的。这三件套中,Dataphin用作数据开发与建模,Quick BI用于报表产品搭建,Quick Audience则是最基础的用户增长的产品化方案。
所以,既然是从0-1,那么这个参照物,就把数据从采集、加工、分析、应用的全过程,提炼的比较完整了。当然,如果是其他的行业,或者是策略有差异,那么也可以参照一些其他的参照物。
早年我们把美国的商业模式搬到中国,称之为“C2C”,今天的参照物,不过是进一步细化了“C2C”,把商业模式的借鉴,下放到了产品设计中。
因为产品设计,尤其是像数据产品,并不像商业模式那样,能够直接产生经济价值,因此对软件领域PAAS层的借鉴或者说是抄袭,就不会像SAAS那样敏感,甚至样子都可以一模一样,基本上不会对外的。
有了参照物,接下来,就可以着手把数据平台的样子,画一张草图出来了。这张草图里,一定要有如下的这么几个部分:
  • 开发工具;
  • 研发规约;
  • 协作流程;
  • 质量保证;
  • 报表工具。
五个注意事项 + 3个参照物平台,一个数据平台的框架,就清晰可见了。掌握了这些能力,搭建出一个可靠好用的数据平台,就只是时间问题了。
很多人会有一种误区,即做数据,我们要把整个流程都自己做,其实不是的。就像维度建模理论,能够把企业数据的“总线架构”给勾勒出来,但这并不代表你能够应对种种其他类型的需求,业务性的逻辑,还是交给工程组更合适一些。
因此,给数据平台划定一个研发的边界,是很有必要的,避免团队资源投入到大量无效的需求中去。或许1-100的过程里,个性化的需求需要去支持,但这绝对不是0-1应该考虑的。团队的研发协作,是有惯性的,如果一开始就掉进了需求陷阱里,就很难爬出来了,或者要退一层皮。
其实近年来,数据研发的岗位,招聘越来越难,一方面因为数据分析/算法岗太火,吃掉了绝大多数的增量从业者;另一方面,也是因为数据研发越来的越贴近业务,对于技术的要求有一种一言难尽的说法。要说面试造火箭吧,算法、架构都少不了,但实际的工作中,这些能力都被平台“赋能”了。因此,越往上走,就要求对业务的贡献越大,对业务的理解也就要求越深,技术长期不用,能力自然会退化掉。
但这只是1-100过程中,所必须面临的问题。在0-1的过程里,需要的东西还是很多的。

03 方法篇

讲完了策略,也就是数据平台目标的样子,接下来就是具体做事的方法了。简单讲,就是“轻重缓急”的选择。
如果我们画出完整的架构图,它大概是如下的样子:
在轻重缓急上,大体遵循:离线-->实时;模型-->报表;链路流程-->稳定性保障;单一工具-->多工具服务整合…… 这么几个原则。先做出可以使用的成果,在此基础上,再将架构图中缺失的部分一点点补充上,直到完成平台应有的样子。
这个过程要做的事情,其实是很多的,对抗“熵增”的具体技巧,就是工作经验所赋予我们的。
从这个角度上看,有两个“熵增”的最重要影响因素,需要控制住,即开发过程中的规范、维护需求迭代的协作方法。如何把规范做好,减少后期需要返工的工作量,同时控制需求不能无序增长,就是平台初建最重要的考量因素,而这些其实都与管理能力相关。
接下来,考量的是团队的分工,从框架、质量和建模等不同的角度入手,把整体框架搭建起来。这时候技术能力就很重要,例如实时能力选择什么技术方法,例如建模如何评价好坏,例如稳定性和质量如何在高速迭代中保持,等等。
当然,做过的东西,都要有所沉淀和输出,让后人理解我们这么设计的原因,同时遵循已经形成的规范,最好把影响力扩展到团队之外,吸引更多的人才加入。
所以,数据开发人才的三种能力:管理能力、技术能力(包括架构、代码能力)、沟通协作能力,就是具体需要学习的做事方法。

04 思辨篇

讲了这么多,从“提效降本”,到“参照物+规约工具流程”,再到需求的“轻重缓急”,基本上把0-1的过程讲述清楚了。
走完1之后,真正的挑战刚刚开始。今天我们大多数人倒腾的事情,也许只有本公司能用一下,一些业务看上去有价值,做起来是一坨屎,维护的人更是不想管它。
但,这都是表象。大公司的探索,是企业发展过程中都会遇到的问题,就像维度建模、数据治理、企业数字化这些理念,都是从大公司开始,扩散到了中小公司,最后普及到全行业。这也就是说,大公司的探索,会成为日后小公司借鉴的经验。从这个角度看,我们折腾的各种东西,各种不靠谱的产品,其实都是在为这个行业的未来提供借鉴的经验。
所以,与其把过多的精力放在需求合不合理上,不如多思考这些需求背后的考量。
比如做一款企业决策型产品,大多数人会抱怨领导需求多么不靠谱、领导怎么又变需求了。但如果深入进去,你会发现,企业决策产品,其实跟“炒股软件”很像。
炒股软件如何支持你做决策?大致有这么几个功能:资讯提供、交易功能、自选行情及实时变动。对应到数据平台上,大体就是报表展示、自助分析、实时更新,以及一些管理功能,比如一键沟通对应的数据负责人。
所以,做企业决策平台久了,转向其他的决策类平台,就很容易。
从这个角度上讲,扎根一个业务场景,其实是数据从业者拔高自己的关键,也是对抗35岁陷阱的基础能力。如果卷算法能力、编码能力,我们也许永远都卷不过年轻人,但要论行业经验、专家解读,这些小孩就稚嫩的很。
数据开发,只是我们从业的能力,而从业所积累的专业经验,才是我们的核心竞争力。
本文来源晓阳的数据小站,作者晓阳的数据小站
点击文末阅读原文,获取更多干货好文

觉得本文有用,欢迎转发分享,谢谢
<END>
大家都在看:
1、IBM数字化中台(PPT)
2、数据治理和数据管理、数据管控三者到底有啥关系?
3、主数据管理(MDM)项目建设落地方案
4、数据中台建设方案(PPT)
5、如何成功规划企业大数据资源战略?
6、企业级数据治理解决方案(PPT)
7什么是数据仓库,以及我为什么需要它?
8华为数字化转型与数据管理实践(PPT)
9、阿里巴巴数据中台实践分享(PPT)
10数据安全如何定级?
11、如何正确的认识和搭建数据指标体系?
12、华为的数字化转型与数据治理
13、元数据与元数据平台
14、数据治理已成为数据中台的必争之地
15、为什么85%的大数据项目总是失败?
数据学堂
欢迎扫码添加歪老师个人微信(data-school),邀请加入数据学堂数据专业微信群,与业内大咖一起识数据、存数据、管数据、治数据、用数据!
继续阅读
阅读原文