我的大数据之路 – 转岗半年的记录

11,452 views

我的大数据之路 – 转岗半年的记录

转岗之初

18年9月,转岗至新部门,主业是数据仓库类的项目。
部门主管安排我们几个一起转岗的同事,线下学习资料,比如大数据之路:阿里巴巴大数据实践数据仓库工具箱

喜接新项目

10月国庆节后,10号晚,到达深圳。
11号上午去部门报到,导师告知我将接手一个项目组,简称G。在我还在苦思项目G的含意时,导师通知我合作PM已到达会议室,合作项目带骨干过来开需求评审会,还好时间不久,差不多1小时讲了个大概。在我还在努力消化会议 内容时,合作PM小声告诉我,项目成员有一半已离职,让我做好心理准备。
这时,我的心思还全在如何才能承接新项目的事情上,对于合作PM善意的提醒,还没有完全放在心上。以我之前的经验看,合作员工,本来就不稳定,看不到就看不到吧,只要领导给预算,再招聘就是了。
没过多久,现实开了一个更大的玩笑。
和现有合作员工交流时,听到一个词,供应商切换。什么意思呢?私下里和合作行管以及部门其他同事交流,原来是说,10月份,部门正式启动供应商切换工作,原供应商X的员工,需要切换至Y公司,假如员工愿意到Y公司,那么一切好办,项目维持正常运转不成问题;假如员工不愿意切换,则Y公司承诺补充人员至项目,保证项目的正常运转。
合作PM通知我,项目组12人的编制里,只有BA(9月中入职),测试(6初入职),合作PM自己(6月入职),共3人决定切换至Y公司,其余人10月底后均打算离开项目。据了解,部门内的其他项目组,供应商切换时,人员保留的比例在80%,业务受到的冲击比较小。
听到这个消息,让还在努力熟悉项目的我,转瞬有崩溃的冲动。另外心里也有一个很大的疑惑,为什么这个项目如此特殊,项目成员的稳定性和平均水平差距有这么大。由于我是初来的新兵,这些问题不方便咨询,所以只好压下好奇心,先抓紧了解项目情况。
而项目的需求方,对项目的进展情况极其不满意,把我和BA请到他的办公室喝茶。
BA比我早到两个星期,中间还隔了一个国庆,其实不比我多了解多少。他表示非常理解我的困境,但爱莫能助。
现时内忧外患,为今之计,最重要的事情是要维持项目人员的稳定,维持项目的正常运转,好让我有时间和精力先熟悉项目。因此:

  • 第一,稳住项目组里X公司的人员,期望在Y公司人员到位前,多待一段时间;
  • 第二,启动合作人员招聘工作,要求Y公司马上补充人力;
  • 第三,内部求助,寻求领导的关注和支持,周知项目人员和交付能力存在的风险,并且协调周边项目人员支撑10月版本的交付。

经过几天的沟通,终于:

  • X公司人员承诺保证10月版本的正常上线,同时有3人愿意支撑项目到11月中旬;
  • Y公司负责人承诺尽快补人;
  • 部门内领导认可当前当前项目存在的风险,并帮忙协调开发人员短暂支撑项目交付工作。

就这样,10月的版本跌跌撞撞的完成了交付,我度过了第一关。

硬接项目

月初盘点项目人力:

  • Y公司在10月补充了3个人力,分别是2个DataStage开发人员,1个Java开发人员,1个BA;
  • X公司留下来支撑项目的3人;
  • 前期同意切换至Y公司的3人。

项目组已有10人,人员还算齐整。想来人力暂时不是问题,可以缓口气,考虑一下项目的事情。
X公司项目组的成员离开项目前,留下了很多交接文档,之前没有认真学习,现在终于有时间看,但由于没有数据仓库类项目的交付经验,不熟悉业务,不熟悉开发工具比如DataStage、ControlM等,结果看起来非常吃力,效率低、效果差。令人不爽的是,发现自己已有的知识和经验,和当前的项目匹配度不高。唯一的安慰是,当前项目使用的是Oracle和FI作为业务的交付平台,之前做项目时,对它们有一定的研究,看代码并不成问题,但也仅此而已。
好在学习的方式有很多,除了看交接文档,招聘面试也是一个好办法。一方面,作为技术面试官,和来应聘的小伙伴交流,在面试过程中趁机让小伙伴解答自己在参与项目过程中遇到的疑问;另一方面,参与综合面试,了解综合面试官的提问套路,顺便掌握数据仓库类项目的相关知识。在这个过程中,好消息是自己对数据仓库类项目的理解越来越丰富,坏消息是招聘工作的进展没有意想中那么顺利,材料写了一大堆,入职的人员却没有多少,时间可是一点都没有节省。

招聘工作进展不顺利的表现:

  • 面试时难以遇到合适的候选人。这可能和年关将至有点关系。后来和合作公司负责人力的同事聊天,依据她的经验,在年底换工作的面试候选人,通常要额外严格观察,毕竟年底了,一方面马上发年终奖,另一方面马上过年,换工作是大事,再急也不差这么几天。
  • 人员到位慢。面试通过的人员,入职最快至少需要3周,这意味着至少到11月20号左右,才会有新的人力补充到项目组,这时X公司的前项目成员已离开项目。在新成员加入前,只靠我一个人,毫无疑问无法完成全部的工作交接,而受限于一些不可说的原因,我已无法再保留X公司的前项目成员。这时只能挑重点,首先学习下游有需求的业务。
  • 已入职的人员,办公账号等资源迟迟无法到位,一方面影响工作交接、上手业务,另外一方面无法参与业务交付工作。
  • 已入职的人员,出于各种原因,还在以各种原因提出离职。

此外,项目组BA反馈,11月份需要休陪产假,按照规定为15天。虽然BA同学很负责,表示在休假前会完成业务方案设计和串讲,同时在休假期间愿意接听电话、澄清疑问,但这仍然意味着从11月中旬开始到11月底,项目组少了一个交付主力。现有项目组内的成员,是否能担起BA的职责,将是一个大问题。

不管怎么说,事已至此,只能硬着头皮做项目。当时采取了如下措施:

  • 10月底进入的开发人员,全部投入到子项目新需求的交付工作中,满足业务方11月版本的需求。
  • X公司支撑项目的前成员,一方面负责已有项目的运维支撑工作,另一方面给新入职的同事讲解业务,澄清疑问。
  • 我集中学习交接材料,一起参与项目交接,同时参与一部分运维支撑工作,期望快速上手项目。

好在合作PM熟悉IT项目的流程和规范,工作很主动,分担了很多压力。这样跌跌撞撞的完成了11月的版本,虽然子项目的需求出于各种原因没有上线,但至少没有升级为投诉。

火力全开

从11月中旬起,来自下游业务反馈的问题,集中爆发。

  • A项目反馈,由于某表数据缺失,影响系统推广,要求补数。事后查明一线业务发生变化,但未知会IT侧变更配置数据,进而导致前述问题。
  • B项目反馈数据缺失,影响业务推广。经分析,发现数据从18年8月中旬即在ODS出现漏数,导致向业务推送的数据量不足,数据内容不准确。此外,在配合下游业务分析数据时,发现原数据加工逻辑无法满足要求,推送的数据错误,引发一线业务人员的大量投诉。下游产品的运维和BA表示压力山大。
  • C项目在11月底要上线特性,验证数据时,发现其中关键字段的数值缺失,影响业务上线推广的效果。经检查加工逻辑,未发现问题,但数据确实存在大量的缺失现象。后来核对代码和前项目成员保留的文档,发现做奢求时,未按照业务要求对数据做初始化操作,导致历史数据中未增加业务需要的关键信息。
  • D项目在12月初,反馈业务数据不准确,要求给出解释。经补数后、启动对数操作,下游业务同事检查数据后提出疑问,经核对数据和实现代码后,发现原代码的实现逻辑不正确,导致关键数据缺失,这时距离问题引入到问题反馈,已有一年左右。

11月底,接到领导通知,要求:

  • 从12月开始,需要压缩项目人力。
  • 项目G需要迁移至南京,并且在19年Q1,进一步压缩人力。

这意味着:

  • 深圳刚组建的团队,需要在来年Q1完成调整和释放,其中大部分人入职时间还不足3个月。
  • 在南京需要重新组建交付团队,同时项目人力基线还需要缩减。

腹背受敌

由于项目人力未能及时到位,业务交接和交付效果差,来自下游的求助和投诉引起了部门领导的关注。
在汇报工作时,如意料之中,领导非常不满意。

  • 子产品经理看重的业务和模型梳理,没有启动。
  • 开发代表关注的架构和方案,没有成型。
  • 部门经理关注的长期规划,还没有时间思考。

这直接导致我的年底绩效不理想。

总结

在承接项目G之前,我只是作为技术负责人来承接项目,项目管理方面的工作只是参与,并作为PM带项目的经验。参与项目G之后,除了技术方面的压力,还要直面项目管理的压力, 现在想来,假如有机会重新来承接项目G,其实有很多事情可以做的更好。

业务和技术

  • 梳理任务清单,以及调度依赖关系。
  • 梳理DataStage JOB。
    • JOB的清单。
    • JOB和表的映射关系。
  • 事实表的设计。
    • 源表和源系统的清单。
    • 表的Mapping。
  • 梳理对外提供数据服务的清单。
    • 业务使用方。
    • 服务形式,如API或者是推送或者表集成等。
    • 数据时效性要求,比如可忍受的延迟时长。
    • 服务可靠性要求,比如可忍受的中断时长。
  • 业务全景图。
    • 上游业务系统清单。
    • 下游业务清单,以及现状。
    • 联系人。
    • 常见问题,以及处理手段。
    • 当前技术现状、时效性等。

项目管理

  • 项目管理
    • 需求管理。
    • 事件管理。
    • 项目计划。
    • 重要干系人沟通计划。
  • 项目规范
    • 项目交付件的定义和标准。
    • 项目归档包的规范。
  • 项目协作规范
    • 项目交付流程。
    • 各角色职责划分和说明。
  • 项目制度
    • 例会制度。
    • 晨会制度。
    • 关键角色日报制度。
    • 重要事件日报制度。
  • 工作量的评估方法
    • 基于DataStage开发JOB,交付工作量如何评估。
    • 基于Control-M开发调度,交付工作量如何评估。
    • 基于Hive开发ETL脚本,交付工作量如何评估。
  • 人员管理
    • 考勤制度,如请假、加班、忘刷卡等。
    • 人员技能清单。
    • 业务交付阵形。


若非注明,均为原创,欢迎转载,转载请注明来源:我的大数据之路 – 转岗半年的记录

关于 JackieAtHome

基层程序员,八年之后重新启航

此条目发表在 工作总结 分类目录。将固定链接加入收藏夹。