业务|数据产品经理如何快速了解业务 sig|中金资本|观脉科技|融资

编辑导读：公司每天都有新员工加入和老员工离开，这段时间，新员工要面临接受一个全新工作的压力。作为一个数据产品经理，应该如何快速了解公司业务，做好新工作呢？本文作者对此进行了分析，希望对你有帮助。

文章插图
01 前言大数据行业每家公司对岗位内容和任职要求都有不同。即便同一个职位名称工作内容都有可能千差万别。最近部门调整，入职了几个新同学，笔者“有幸”交接出去部分工作，包括部分应用产品及采集sdk。虽然交接的新同学也从事多年的数据工作，但原所在部门及工作内容与当前差异依旧较大。面对不熟悉的公司环境、业务流程，堆积如山的交接文档。
在业务紧急运转的情况下，如何消化交接内容并快速衔接当前工作需讲求方法，笔者在近8年的工作里，岗位从分析师->数据产品->营销后台产品->数据中台产品，每次转变都能平滑过渡，下面我将自己在熟悉新业务过程中的关注点及经验通过这篇文章分享给大家。
数据产品进行业务熟悉的角度可以从两个方面入手：
1.本职工作内容
2.公司主营业务
02 本职工作内容接手新工作时最棘手的情况当属老员工离职。这种情况一般交接周期“较短”，平均2-3周内。如果恰逢对方认真负责，既能跟进完所有项目，也能作为一个合格的导师带你过渡；但还有一部分属于马上离职，于是事不关己高高挂起。交接过程三言两语，项目进度虎头蛇尾。一旦对方离职，自己无法在短期接手原本工作内就会陷入一个十分艰难的地步，他远走高飞，你水深火热。那快速接手当前工作需要关注哪些内容呢？
1. 掌握现有产品1）熟悉产品框架
系统中的每块功能都有其独特的场景意义，代表业务对其依赖的轻重缓急。熟悉产品框架要了解它的发展历程，包括但不限于：
立项背景：
立项背景帮助了解产品诞生的起因，需要解决的问题，产品发展的目标以及所要服务的业务角色。基于这些大前提，在短期之内可按照原来固有的路径进行发展迭代，可避免与相关配合人员因项目立意及产品结构差异过大等问题造成不必要的分歧。
Mvp版本：
Mvp版本的功能范围有助于了解产品诞生初期业务所关注的的核心问题，结合后期版本迭代记录可推敲出业务大致的发展路径。可着重查看产品文档中版本号为：beta、0.0.x、1.0.x、hotfix及优化版本等字眼的文档。
后续大版本：
后续每个大版本的需求范围及迭代频率不仅能反应出业务发展的紧急情况，同时有助于将产品功能进行归类分析。比如近期功能以优化为主还是迭代为主，可以推测接手时这款产品所处的生命周期。再比如可以粗略统计出每个模块迭代功能次数，迭代次数多的功能在熟悉过程中需要着重了解，代表该功能可能被业务重点依赖亦或是整个平台的核心，后期版本迭代或运营推广都会围绕此进行展开。
拆分产品：
拆分产品，包括功能架构，用户使用流程及数据流向等。这一步是对产品框架的全局了解，基于现有平台能力。短期可依赖过往经验或行业通用解决方案，为后续的产品迭代做基础性的规划。
梳理完整个产品的骨架，接下来要根据不同的“骨骼”位置，丰富血肉。
2）梳理文档内容
交接文档：
交接文档需要明确几部分信息：产品开发团队、各系统地址（包括测试环境）、各文档地址、跨多团队的对接流程、所支撑业务部门及相关对接人等。
需求文档：
需求文档（prd）可作为产品功能逻辑查询“字典“来用，但需要确认文档建设的完备性。完善的文档建设代表了所处产品团队的规范制度或历届该岗位同学的工作作风，如果文档建设极度混乱、缺失严重甚至历史文档都没有，就需要辩证思考一下自己与当前团队是否会有行事风格“冲突”。