转岗之初
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脚本，交付工作量如何评估。
- 人员管理
- 考勤制度，如请假、加班、忘刷卡等。
- 人员技能清单。
- 业务交付阵形。