为什么你成为不了团队核心成员

简介: 为什么你成为不了团队核心成员

一、背景


之前我讲过一个《业务重要?还是技术重要?》,后来收到评论恢复,工作 3 年以上的同事大多认为业务和技术同等重要。作为一个数据人,我一直想讲业务比数据更重要,但一直怕遭到热衷技术同学的鄙视,这句话一直没敢说。其实,数据人都知道,现在很多大会包括老板,一直都在提“数据赋能价值”。作为员工,我一直对此深信不疑,我也一直在对团队内强调。


二、数据价值赋能价值


大家对数据赋能价值产生共鸣后,就开始寻找数据价值,当然,刚开始还是有部分同事不以为然,还是要靠领导者来趟路,给大家做一个“模范”。数据要产生价值,并不是数据越多越好。很多时候我们花费大量的时间来搞数据融合,解决“数据孤岛”,最后数据都躺在服务器上“睡觉”。


网络异常,图片无法展示
|


很多时候,数据人员不是很清楚如何把现有的数据做出价值。但是业务人员很多时候都清楚自己要什么,他们苦恼的是不会运用数据。所以很多时候,业务频繁的给数据人员提大量的需求,有些甚至是“无理”的需求。最终导致数据平台开发了很多指标,还是静静的躺在报表系统里,业务人员也许用过一次后就再也不会点开了。上面已经说了,业务人员很清楚如何实现数据的价值,那为什么不让业务人员自己来分析数据呢?于是我们开始建设数据分析平台,然后构建数据产品!一个个数据指标是静态的,但分析的理念和框架是动态的,通过提炼分析框架和业务目标进行数据泛化形成数据产品,才能让数据被真正用起来。


网络异常,图片无法展示
|


数据产品特点:


  •  数据产品要结合实际的业务场景
  •  数据产品方便业务人员操作
  •  数据产品要能够让业务人员自己构建,比如通过拖拽的方式。

也许,你会问了,有了自助分析平台和数据产品,业务就可以自己出数据报告,不用再让数据人员提数了,那么作为数据人员的你是不是瑟瑟发抖。


数据人员不会再花大量的时间和业务人员“砍需求”,而是专注数据应用场景,然后规划自己的模型。从数据采集到数仓规划和建模开发,包括数据资产管理都会从数据应用的角度出发来实施。期间,从前的“表哥表姐”还能抽出时间搞个数据挖掘和算法,从多维度探索数据,更大的挖掘数据价值(方便以后跳槽)。


三、数据挖掘工程师


关于数据挖掘,上面我们已经说了,数据的上层应用挖掘,这个需求随着数据处理流程日益完善,数据的应用已经从简单的多维统计分析,慢慢的向深层挖掘过渡。那么作为曾经只会 SQL 的数据工程师要重新拿起“西瓜书”了吗?


网络异常,图片无法展示
|


招聘网站,我们看到很多公司在招聘算法工程师,关于算法工程师招聘到公司具体做什么,我也了解过一些其他公司的(自己团队的算法工程师,我很清楚需要他们做什么)。通过了解一圈发现,很多公司招聘的算法工程师其实就是数据挖掘工程师。我理解真正的算法工程师是专注于数学工程化的,他们更专注于数据问题研究到极致,工作更加纯粹。除了头部 IT 公司,应该很少有公司在做真正的高精尖算法研究吧,然而作为数据挖掘工程师就需要了解数据。


数据挖掘工程师需要知道一整个数据到业务输出的机制或者说是系统,可能涉及到复杂的算法转化,也可能只是简单的规则转化,或者多个模型的转化组合输出等等,他是一个比较全面而概括性定位。


四、如何成为团队核心人才


1、熟悉业务


进入公司(新岗位)的第一步就是去了解部门限制处理的业务,数据都是从哪里来的,涉及哪些业务,我了解他们的系统。只有了解了你接下来面对业务系统,才能更好的“服务于”业务。


2、熟悉平台


了解部门平台架构,知道平台数据怎么接入的,如何存储的,怎么处理的。很多算法工程师,只知道要自己算法需要的特征数据,对数据仓库工程师提了各种需求,然后“静静的”等数据。数据来了以后,发现和自己要的有出入,就又来了一轮,大家都很痛苦。没有人比你自己更了解你需要什么数据,所以“自己动手,才是王道”。


3、帮助别人


帮助团队成员能力提升,“大家好,才是真的好”。其实进入到一个部门,每个人都有自己的优势,帮助别人提升能力的同时,自己也不断提升,团队也会获得更好的“绩效”,也帮助了领导“解忧”,自然会成为部门的“红人”。

目录
相关文章
|
运维 NoSQL 关系型数据库
带团队后的日常思考(十)
带团队后的日常思考(十)
|
缓存 运维 测试技术
带团队后的日常思考(九)
带团队后的日常思考(九)
|
监控 NoSQL 前端开发
带团队后的日常思考(三)
  参与制订业务方的BUG规范,业务方最近投诉我们技术部,在飞书群中提出BUG后,技术部没有人响应,认为我们的态度太冷漠。   后面我就提出任何看到的人,只要知道是谁负责的,就@那个人,大家都不要客气,这是第一步。
带团队后的日常思考(三)
|
缓存 监控 前端开发
带团队后的日常思考(二)
  经常在工作时被人小窗,这里的计算有问题,那里的表格没内容了等等,一开始肯定是懵逼状态,然后是根据症状一步步的摸索代码逻辑。
带团队后的日常思考(二)
|
存储 缓存 移动开发
带团队后的日常思考(四)
  这次公司有个五周年的庆典活动,但正好碰到两个APP的版本发布,以及三个测试老员工离职,只进来了两个新成员,其中一个恰好要休陪产假,那么测试组资源异常紧张。   虽然我们提前了整整一周提测,但一直到周五还有很多点没测到。测试组甚至想到了阶段测试,因为多个活动的上线时间不同,所以可以先测最先上线的活动,后面的再往后推,延迟测试,这是他们组的一个对策。
带团队后的日常思考(四)
|
运维 监控 NoSQL
带团队后的日常思考(一)
  由于公司规模并不大,因此一有事情就会拉个会议,例如需要大会、技术评审、汇报周会、突发会议等。一周中大概有20%~30%的时间会花在大大小小的会议上。
带团队后的日常思考(一)
盖洛普Q12在团队中的应用
周五给大家做了个盖洛普Q12的分享。
盖洛普Q12在团队中的应用
|
移动开发 自然语言处理 前端开发
带团队后的日常思考(五)
  他们组没有一个正式的组长,只有一个临时的代理组长,这种情况从我进公司到现在一直是这种情况,也是蛮奇怪的。   前几天,这个代理组长和其中的一个组员爆发了点冲突,我从旁观者对他们对话的理解就是,组员觉得他瞎指挥,他觉得组员无担当。
|
SQL 小程序 测试技术
带团队后的日常思考(七)
  最近被插入了一个需求,我们组经常会被插入各式各样的需求,因为之前负责的范围非常广。   这次的需求就和一个陈年接口有关,其实要修改的地方并不多,就是为一个请求多加一个参数。   但是比较麻烦的地方就是验证阶段,就是我在加上这个字段后,我得知道发请求的时候真的带上了。   根据URL地址反查到了页面代码,在本地启动项目,访问页面,直接报错。   调试陈年项目,这种情况是经常发生的,涉及的问题很多,例如内部接口不通了,数据库表结构变了,需要的数据记录本地没有等等。
|
缓存 运维 前端开发
带团队后的日常思考(八)
  最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。   那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。   在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。   UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。