很多时候，新人技能并不局限于刚参加工作的年轻人，换一份新工作时，也能够根据一些技巧，来快速的熟悉和学习新公司的技术体系。
|0x00 初来乍到
对于数据技术而言，基础的技能有三种，一个是熟悉你所使用的数据平台和工具，一个是熟悉开发过程中的流程与规范，最后一个是熟练使用开发使用的语言。
对于数据平台和工具而言，一般情况下都是在Hadoop生态下做开发，但对于一些有特殊要求的团队，Spark和Flink已经得到了成熟的应用，这时候在熟悉平台的操作前，先通过官方文档，熟悉这种技术框架的设计原理，对于后续理解程序的编程方法，很有帮助。一些商业化的工具，比如ODPS是，在Hadoop上做的一些工具升级，熟悉这些工具的应用，对于工作熟练度提升，帮助也很大。
其次，任何团队都需要有相对应的操作流程和注意事项，因为这些经验大多是踩了坑，甚至是踩了很多坑之后才总结下来的，它一定不是你可以忽略的缘由。新人融入团队初期，想的并不是如何“争战功”，而是如何“活下来”，尽量避免了线上故障，才有更多的精力和能力，来实现更高层的目标。
开发语言相对而言不是非常重要的一环，比如大公司的数据开发普遍SQL化了，但Python或者是Java仍旧是需要做平台维护工作的一些岗位，所必须的技能，这里只要掌握如何快速学习一门语言的技巧就好。通常情况下，熟悉一门之前不熟练的语言，三天时间足够了。
|0x01 业务提升
当基础的数据能力掌握的差不多了，接下来就会进入一段比较痛苦的时期，也就是“业务熟悉”的阶段。
业务学习通常不是针对一个需求做了解，或者是过去的文档做整理，而是要针对一个知识体系，做全面的了解和熟悉。如今单纯的技术开发已经不能满足公司的要求，而掌握某些业务知识的开发人员，在日常工作中，竞争的优势会更大。
比如做营销相关的，互联网数字化营销有一套自己的东西，CPC、GMV之外，DPA/OCPX/OCPM这些进阶的术语，至少都要了解相关的知识含义。除此之外，在该方向上，公司有哪些产品、相关业务有什么黑话，多学多问一些，不至于做需求的时候感觉自己很“傻”，基本的话术都听不懂。
绝大多数公司不会有什么新人培养机制，大家的业务都在野蛮生长的时候，1-2年就是一个很长的周期了，招聘的目的也大多数为了快速补充劳动力，所以适应性的工作，还是需要依靠自己。
当对阶段性的知识有了一个总结后，可以试着自己把对于业务体系的理解写下来，不需要带太多的技术思考，只需要把业务的框架整理清楚，就算是成功。
接下来，我们就需要参加一次完整的需求开发周期了。
通常情况下的需求沟通过程如下，但很多非常“敏捷”的团队，通常口头讲讲也是有可能的。
第一步是产品需求的讨论，通常由产品经理发起，通过PRD来讲解需求的设计。
第二步是PRD的评审，通常由项目经理组织，对PRD的问题进行充分的讨论，并确定初步的项目排期。
第三步是技术方案的评审及排期的最终确定，需要有详细的技术方案设计、关键路径拆解和里程碑事件。
第四步是正常的开发节奏了，如代码开发、测试、补需求及上线的过程。
在这其中，我们需要能够对需求进行合理性的评估，并对存在疑问的地方提出自己的看法和设计方案，最后再根据需求提出自己的技术方案和相应的排期。
很多团队要求不光是能够完成相应的需求，还能够独当一面的负责，因此如何cover住整个“场子”，就需要你的专业知识来“镇场”。
|0x02 技能进阶
除了应对提倡的需求开发，接下来就就是考虑如何自我提升的问题了。毕竟，能够把需求做好只是完成了基本工作，而如果想要晋升的话，就需要在技术上作出一些突破，反过来赋能业务。
所谓的“赋能”，基本上就集中在两点，一个是“降本提效”，一个是“提升收入”。由于技术工作本身就是在一直做“降本提效”的事情，因此这种类型的贡献，也是比较“内卷”的，而且很容易讲不清楚对公司的贡献到底有多少。而“提升收入”，尤其是可以量化的目标，这种就会非常受到欢迎，权重也会更大一些。
除开我之前文章提到的四个可以提升的“技术点”，本文额外增加两个技能进阶的指引。
一个是数据建模的能力。数据建模是数据开发的一个基本功，也是区分于其他岗位的重要标志。但数据建模是一个长期的基本功，不仅需要对各种理论、方法论有掌握，更要求有实际的应用经验，毕竟这是一门“实践”出来的学问。因此，如果做不到“数据量足够大”，或者是“数据业务足够复杂”，那么即便是工作时间再久，技能上也不会有本质的提升。
对应到具体的工作，“数据量足够大”，可以对应到“大促”的业务场景下，当数据量极端到一定的程度，跑个简单SQL都需要计算很久的时候，你对于各种参数的应用、SQL代码顺序的问题、数据倾斜的理解，才能够更深刻的体会。很多时候，压力会给你动力，你会非常有把Hadoop底层、MR原理重新复习一遍的冲动，后续换新工作的时候，这些面试题对你而言就不仅仅是讲个方法了，你的经验会足够写一篇论文。
“数据业务足够复杂”，可以映射到“银行”、“业财”、“物流”这一类业务逻辑高度复杂、但数字化程度又不够高的场景上，你会对于“方法论”有一种别样的体会。别的不讲，如果一个业务横跨几个业务域、十几个业务过程、上百个业务细节，你会如何设计模型，又如何跟业务讲清楚数据结果为什么是正确的呢？这其实就是对业务的理解和抽象能力。像SAP做的工作，大多数非常标准化和逻辑严谨的那一部分，而更多的个性化、非标准的内容，则以“接口”的形式来介入主系统和做扩展。因此，从某种意义上讲，“微服务”也是我们设计数据业务系统的一种思路，其核心就是如何做好“严谨而标准”的核心组件。
另一个能力，就是数据技术架构的设计工作，其实不光是数据模型的建设，对于一些技术框架的设计能力，也影响了数据价值的产出。
举个最典型的例子，调度系统，当某个特定的业务场景有一些额外的要求，在正常的数据流程之外，加入跨时区、人工审批等节点要求时，通用引擎就无法满足我们的要求，而需要设计一些特定的调度规则系统了。
对于架构能力的培养，除了组内讨论和评审外，定期也需要有阶段性的文档产出，详细记录业务抽象的过程，以及完整的架构设计文档，包括了流程图、表结构定义、建模过程等内容。
最后，做好架构设计和模型设计的基础上，通用那么一两个标准业务场景，给到业务，“价值产出”的事情，才有实现的可能性。比如“数据埋点” + “AB测试”，感兴趣的就可以试着自己做设计。
|0xFF 自我提升
技术上的提升，永远是客观的方面，而如何去实现这些提升，是“主动”的，也是需要有良好的自我管理能力。
何为“良好的自我管理能力”？简而言之，有如下几个方面的体现：
一个是时间管理的能力，每个人的时间都是公平的，如何在生活的琐碎之外，为自己挤出提升的时间，并且能够在比较长的时间内稳定的提升，决定了工作5年之后，每个人的分水岭。
一个是自我学习的能力，学习总是痛苦的，而享乐是学习最大的对手，但如果一直让自己痛苦，也很难能够持续学习好。因此，自己要有改变自己兴趣爱好的能力，把学习变成一种享受的过程，至少是自己能够接受的方式，这个决定了你能不能持续的提升自己。
一个是沟通交流的能力，这也是一个老生常谈的问题，因为工作的圈子比较小，大家往往不会跟交往很久的人，做出一些改变。那么就寻找一些其他的方法，来多接触陌生人，改变自己打交道的方法和心态，久而久之，面对现在的同事，一样能够有不小的变化。
一个是自我总结的能力，定期的总结自己工作，与上级、同级和朋友交流，明确下一阶段的重点，工作不是为了他人而努力，是为了达成自己的目标而非奋斗。
最后，还是套用一句创业的老话：“成功的人都是相似的，失败的人各有各的理由”。共勉。
网友评论