数据侧新人如何度过试用期（总结比较实用的技巧）

前言

最近很多同学都已快到转正时期了，这里语兴给大家提供一些试用期通过，能landing建议，帮助大家顺利通过试用期。

新人挑战

刚入职的新人，对于新业务理解及技术框架变更（例如hdp到数据平台）都有挑战，这些其实也都不算什么，更大挑战而是接受一堆看不懂的历史项目及几十上百的“老”任务，同时需要快速熟悉这些老业务，并在新业务场景做出价值。另一种挑战则是上手变慢做不出业务价值，更多干历史dirty work去排查bug、帮业务取数等，最后发现啥也做了但啥也没做，导致试用期没啥量点从而不一定通过。

刚入职的新人，对于新业务理解及技术框架变更（例如hdp到数据平台）都有挑战，这些其实也都不算什么，更大挑战而是接受一堆看不懂的历史项目及几十上百的“老”任务，同时需要快速熟悉这些老业务，并在新业务场景做出价值。

另一种挑战则是上手变慢做不出业务价值，更多干历史dirty work去排查bug、帮业务取数等，最后发现啥也做了但啥也没做，导致试用期没啥量点从而不一定通过。

价值评估

之前也有同学问语兴为什么这么看重试用期产出价值，产出价值代表着你对部门未来是否可用，也同样评估每个同学绩效。

高绩效本质是你如何帮助老板去总结价值，或者说如何帮你老板解决向老板的leader汇报问题，也不是提倡大家完全拒绝dirty work（脏活累活），而是在什么时候做dirty work，如果为了快速了解业务或者手里暂时没需求可以适当接，通过试用期或者往后工作都可以完全及时接，因为有大把时间去搞。

试用期通常3（某里） or 6个月，3个月建议交付1个大型项目1个中型项目，6个月下来能适应并交付2大型项目或者1个大型需求2个中型需求，所以试用期时间比较珍贵，并在试用期确定目标去完成很重要（很多同学试用期不注意时间把握很快就到了述职）。

我们可以根据这些价值或者项目是否部门核心okr来定义一个项目价值，从而决定要做哪些，优先级在哪里，最好以业务价值为主（除非部门全力在搞治理和质量），当然大多数同学都是入职后老板直接安排需求，所以考虑优先级，以核心需求为主，非核心需求ddl前交付就可以，对于刚入职没有需求安排的同学需要你主动去找老板认领需求，或者看看部门内/业务侧有什么可以去做的。

大型需求评估：

需要投入1个季度的产品建设，需要业务支持的，核心场景用户标签资产建设，数据治理，某个数据域0-1建设并到支撑下游角度，用户标签画像体系建设等。

中型需求：用户标签宽表建设，某个专题分析数据模型支撑等。

小型需求：某产品功能上线跟版、简单应用层模型建设等。

数据项目价值（业务价值）如何评估（如果有业务方帮忙评估最佳）

1.用户增长/经营性分析/风险拦截

用户增长/经营性分析即通过数据仓库建设的数据模型帮助业务方带来用户增长，是数据仓库对业务的核心价值。

例如数据模型支撑了用户基础画像、用户在业务中全流程行为分析、用户在消费行为中表现情况等，通过数据模型帮助业务能够快速定位未来活动、未来业务走向等，为业务在拉新、促活、挽留等方面提供精准流量（而非原有广告投放导致流量较为广泛，定位不精准）。

在此处数据仓库帮助业务达到了用户规模增长，从原有规模增长到现有规模（例如5000万用户增长到8000万）、为业务新的经营分析场景，为业务带来规模性营收（例如金额收益增长40%+），对于数据仓库同学来说，可以从数据表中查询已知的增长规模，还需要和业务方确认增长的方向和其他数据。

2.数据质量/稳定产出

数据质量/产出稳定更多的价值在于提供的数据能让业务方使用的安心无忧，如果数据质量问题经常被业务反馈、每天都无法提供数据给业务因果难过，那业务方对于数据仓库的依赖会逐渐降低，丧失用数信心，因此稳定数据质量及任务产出也较为重要。

此处的价值可从原有数据质量问题触发情况与现有情况进行比对，问题触发降低了多少等（例如每个月下游反馈40-50bug 现在降低每个月下游反馈7个bug），任务产出这里也可以从基线/SLA破线无法交付次数降低了多少去评价（每周5次破线降至每周小于等于1次破线），同时还需要做数据质量问题质量可视化监控看板提供给业务方查看，并按照周/月形式进行定期邮件反馈。

3.查数/用数提效

查数/用数提效为业务方提升了更快的效率，能够快速找到并使用数据，在这里数据仓库侧需要对元数据维护、定制相关提效数据服务（数据资产门户、指标中心、ONE-ID等），通过数据服务以及元数据维护将查数/用数成本降低，将原业务方几小时查询及询问时长降低至分钟内自助查询定位（例如原来业务方自己找数据表查询指标要3小时，现在能够实现自助查询，并能再5分钟内定位），极大降低了成本，同时减少了数据仓库侧问题答疑次数，达到快速定位效果。

4.降本

由于数据仓库任务及数据表日积月累式增长导致计算及存储的费用不断提升，从而增加部门整体费用（例如计算/存储金额从3000万降低至2100万等），通过数据治理或数据技术架构更换，帮助业务降低整体支出，为部门节省整体开支。

5.熟悉组织架构

入职后建议除了快速熟悉业务和技术框架开发流程，也要快速熟悉自己上下游合作方（一般下游是数分/产品/策略/运营等，上游是后端等），这样方便后续不懂的能够直接对接，并且还能知道业务以后要做的东西。

如果是高价值项目甚至可以提前了解起来，无论是做新项目还是拾起原来的项目都能快速对接，业务还能帮你了解目前业务，加速熟悉业务。

入职第1周（M1W1）

day1：可能半天时间足够把全部权限开通，另外半天用来熟悉当前用的组件，可能非平台数仓熟悉起来较为麻烦，需要投入1-2天，如果有数据平台会了解起来更快一些，基本用起来体验一样。

day2-3：如果是p6+（4-8年）以上同学可能就要开始对接需求了（边工作边熟悉业务和开发流程），如果是p5（1-3年）同学可以继续了解开发流程及业务。

如何快速熟悉业务：

（1）找到内部文档沉淀，直接了解历史项目（文档有沉淀）。

（2）直接找业务/产品了解。

（3）扒核心代码，尤其是核心dwd层数据模型代码，快速了解到底层ods表以及dwd枚举信息等。

（4）体验公司/部门产品，自己变为用户去体验，通过使用产品，知道业务流程。

day4-5：继续接简单需求开发（加字段，数据同步，取数等），可以快速熟悉组件开发，同时了解业务，整个数据链路跑通，其实对于新人最有帮助的即接2周数据大盘的需求，或者各场景用户360标签的需求，这样可以快速找到核心数据表，了解核心指标标签来源和具体口径。

day5:通过我们第一周的对架构梳理做出一张架构图，对数据版图的认知做初当前数仓建设的情况，对业务理解可以画出对应业务流程图，作为这次周报的交付物，让leader看到个人自驱力，学习能力，思考能力，数仓版图、架构图看第一讲认识数仓，业务流程图可按照自己理解去画，也可以参考原来同事画的图去理解，在这里变成自己的产出。