智慧芽（Patsnap）工作生涯的总结

前言

距离离开智慧芽已经接近一年，因为待得时间比较久，想着能够给自己沉淀一些什么，无论是对业务还是技术，并记录下来，回过头来想，能够陪伴公司一起成长是非常难得的一件事。

个人规划以及想法

回头看，我在毕业之初就有进创业公司的想法，原因可能有多个方面，一个是地点，我本是苏州出生，当年的苏州确实没有什么可选择的互联网公司，第二个，大学的时候并没有很成熟的去想很多工作后的事情，导致大学也没有在专业方向走得太远，这块可能是一流大学与一般大学的差距，从小到大，读书其实还算顺风顺水，除了高考，当然，当时也觉得没什么，同样是大学，用现在的话说是“佛系”的。

很早的时候，也问过自己你希望过什么样的生活，我那时候清晰得记得回答是有起落的生活，经历过困苦后得到的体验，以及思考后得到遇事的从容。

记得跟第一家公司老板聊过一个话题，跟他聊对于成功的定义，只记得当时还说我是需要生活工作保持平衡感的人，能将家庭照顾好也是一种成功；再跟他聊延迟满足感，还举了一个小孩吃糖的例子，我说我绝对是一个能做延迟满足感的人；

现在想来也是矛盾，或许是幼稚的，没有经历过，你根本不了解自己，或者人本就是多维的。听到一句话 “人生一世，认定一条路，不畏惧，不退让，一直走到尽头，是件幸事”。

自己在工作中是一个什么样的人？我也说不清，有一次公司员工培训中，有一个小活动是让给对方贴标签，最后我却是被贴最多的，最受”欢迎“吧，可以参考：

对于工作，疲惫感或者解决途径，我认为的：

做的事情是自己想做的，喜欢的
组织架构或者职位层面的变动
新的产品业务线

我在公司的经历：

13-15 ：开发
16-18 ：转管理（偏业务）
18年中 - 现在：管理（偏技术）

我认为对于一个人两三年，应该是基于之前的经验会有沉淀和想法了，因此是需要转变的，

聪明的人很多，但有些聪明的人是为己者聪明，有些是为及者聪明。

关于组织架构

公司级别的，非经历实际决策理解考量可能缺乏战略性的思考，一直是在数据团队，因此主要也是关于本部门的经历，

13-15年阶段

5，6个人左右，公司层面也没有职级且明确的定位；暂且都做为数据工程师吧，基本上是一带一，一半有经验的，一半新人；

15-17年阶段

数据部门由10人以下扩展至40人左右的团队，推行scrum，大团队下分几个小组，

scrum team 人员构成：1个 scrum master，1个 PM，2个 QA，4个 DEV 具体职责划分：

PAD：负责亚洲区域的专利数据，同时兼顾citation，family，docdb，reference等的处理
PGD：负责欧美区域的专利数据，同时负责法律，转移，诉讼等数据，以及图片处理
NPD：负责非专利数据，主要为商标，公司数据等，同时兼顾翻译服务
DQ：负责关注数据质量，包括人名，分类号等整体性质且能够用统一逻辑的清理，处理不了的特殊case再分发到各区域负责人（PAD/PGD），另外一些后处理的服务，merge，address，claim count等部分指标计算
DC：大多没有开发背景，主要负责人工校验，标注的工作，family，litigation的标注，测试，也包括业务组的任务监控，成本报表，调研BI工具的使用。

18年

我希望的数据部门岗位，职责以及分工定义

商业分析，数据分析结合业务数据的展现报表 BI ---> 数据分析师
基础平台，运维 --> 平台研发工程师，开发运维工程师，架构师
基于平台的业务ETL团队 --> 数据工程师， java开发工程师
数据质量团队，定规则，标准化，这里包括人工数据的处理 --> 数据质量工程师
顾问团队和技术商量调研 --> 产品经理，顾问对外方向 , 产品按职能方向细分

职位间可以轮岗，形成良性循环，一般来说从数据工程师熟悉业务做起，也同时能够节省招聘的困难(招完全符合的人需要机遇的，招聘+培养是健康的模式)。

我提出成立DP：平台组，统一管理处理平台，以及平时业务中抽象出来的技术工作

新成立BD(Big Data)：NLP，ML相关工作，从ans，address等问题入手

19年

我理解的数据部门岗位

按职责视角：数据开发（爬虫解析存储，应用），数据质量（质量规范，监控模型，智能报警），数据运维（集群运维，任务管理，问题排查，日志，监控，资源审核），数据安全，数据管理（数据资产管理，数据字典，血缘关系等），数据服务（数据传输，API，发布等），数据集成（采集，结构化，数仓，应用）

按团队：数据平台 (基础服务，数据仓库)，数据运维（集群管理，任务管理），算法团队，数据运营（可视化方向，数据大屏等，指标，报告分析，账单分析），数据安全（权限控制，数据合规，数据加密），数据开发（数据爬虫，数据ETL，数据集市），数据分析(对接各种BI分析需求), 数据质量

算法团队：数据挖掘（领域知识，风控，用户画像），计算机视觉（识别，分割，内容理解，推理），算法平台（Spark/MR , TensorFlow,PS Based,MPI），搜索(NLP-分词，实体识别，句法分析；知识图谱，排序，打分，评估)，推荐（排序，策略，评估），其他（语音，图算法）

新成立Content : 原来DC划分过去，原来scrum里的产品划分出去；

新成立数据检索质量团队: 原先scrum里的测试划分出去。

20年

数据部门可以涉及到的岗位职能方面：

数据业务部门
数据产品部门
数据基础服务部门
算法部门
搜索部门
数据质量部门
数据安全部门
数据平台部门 - 对接外部数据消费
数据标注部门 - 模式合作管理

新成立SA : 原来的BD，Search，中国RD合并

后面其实变化不大，就不赘述了

当然合适的结构一定是以实现公司当前实情以及战略目标去设计的，没有正确与否以及固定的答案。

如何理解组织和战略？如何通过组织来引导成功？

业务发展迅速，只有对事情本质理解变深了，不仅有烟囱式的业务，也要有内部的技术岗位，考虑老员工的技术和业务能力沉淀，通过组织架构变动，产生新的岗位，将现有人才盘活了，并补充新鲜血液，避免流水线式作业。

关于技术迭代

这里就只提一些关键节点以及做了什么，没有细节

2013下半年

autoframe(Spring MVC)：最原始版本的数据任务管理可视化工具

storm：对接autoframe的数据管道，公司现有服务器。需要为每一个国家分配solt，随着国家的增多，机器资源会不够。

httpsqs：队列中间件。

VPS + monitor ：购买了大部分的VPS用来爬虫使用，分美区及欧洲区。因为供应商不稳定，以及任务需求，需要不停换供应商，以及临时购买扩机器，再取消，一个机器独立IP，一般会保留10到15台，所以需要专门的机器管理，以及供应商管理。同时VPS本身网络，磁盘使用都需要统一的监控管理，包括部署。

Ftp+Tor：最初版本的代理系统。

Gridfs & Mongodb：文件存储 & 数据库

Crawler，Parser：主要的服务，爬虫服务（spring，按国家配置注册），解析服务（工厂模式/反射）。

2014

Gridfs数据迁移至s3

Mongo硬件切换成SSD，大字段拆分，master slave到shard ， oplog同步

下半年AWS技术栈的调研，Mongo利用AWS的机器自建，考虑数据处理pipeline迁移上云

2015.7

AWS EMR的调研 , 将爬虫部署至hadoop阶段，利用spot instance做伸缩；

数据从mongodb所有迁移至dynamodb , dynamodb中美数据的同步（自研）

s3源文件的管理(存储结构格式的演变)：大概经历两个阶段，第一阶段以PN号为维度，第二阶段以Id为维度

autoframe第二版（脱离storm，单纯服务+队列解耦，bootstrap）

2016.5

Crawler，Parser服务重新设计：

Crawler对请求头做了封装，简化每个爬虫重复写header以及get，post逻辑的包装，提供一些通用的组件，多种代理模式的支持等；期间拆分了python爬虫的项目，调研过scrapy等，针对非专利数据(后来的npd小组雏形)。
Parser项目改成ETL结构，Etractor , Transfer , Load分别可重载实现逻辑（模板模式）

对数据库进行分层架构，raw data及production data等，通过merge服务做规则筛选合并

原先的autoframe升级为admin(任务配置模版化，统计，报告，detect服务等)

2017

为了提升性能，将美区图片同步至中国，使用Tsunami-UDP；

为了提升网站查询性能，包括对接solr等，以及对于dynamodb能支持batch query，做了一些列表以及映射的优化

专利家族产品发布（规则+实时+纠错）

citation，reference等服务的拆分独立

数据分层merge服务重构，主要目的模块化，统一逻辑剥离，包括消息发送，号码标准化一类的工作等

2018

应对自定义分析的需求，AWS athena的应用（针对项目人工处理，离线）;

metabase，superset简单报表开发

原先的admin升级为DPP，前后端分离，VUE+Spring boot ; 适配公司其他业务团队场景，应用调度分离，支持多语言，开放api接口，自动重试，告警统计等支持

2019

DPP升级（权限、数据安全、监控、BI工具对接等）

data lake的实现（dynamodb至parquet的转换），支持T+1离线数据分析能力

数据同步（多类型，多模式-常驻、一次性、裁剪，多区域）

2020

DPP迁移至EKS，项目代码CI/CD打通，配置与apollo打通；

数据源收集利用kafka采集层（更多源接入），适配dynamodb connect和s3 sink，增加监控；

mongodb对于dynamodb协议的适配器

data catalog（元数据管理），规则引擎开发（数据质量巡检）

数据的理解

以上总得来说能看得到的技术点，其余很多是业务工作

在这么多年间，以上的技术以及组织架构支撑了数据范围，数据量，数据更新及时性等的扩张，专利，商标，法律，化学，生物，新闻，文献等等。

很多已经找不到数字印证，这也是后面我想提到的，随之导致外部能看到的都是印象很粗浅。另外数据业务上发展的里程碑，很多的统计数据不够标准，导致报告都是除开新数据业务外，都是覆盖率，修正质量数目等等的提升，甚至还会有前后不一致数字的困扰。这些都是源于对数据的理解不够深。相对于外部的人来说，光看数字体会并没有很大的触觉，怎么样以数字真正来说话，解释数据变更，产生的背景以及涉及的工作，需要花很大的力气。

业务向，数据阶段来说，可以有如下的里程碑：

2013 --> 2015 专利数据扩张阶段
2016 --> 2018 业务数据进一步扩张（商标，法律，诉讼，化学，生物，discovery等）上云环境阶段
2019 --> 2020 开始有数据分析的工具以及理念，文化的萌芽
2021 --> 20XX 下一步的阶段是什么？数据和AI，模型怎么结合？数据支撑AI？AI如何反哺数据各个阶段？

PS : 现阶段确实能看到在AI领域还是有不少应用，包括图文对照，自动摘要，分类等，但我这里要说的更多的是怎么在工程上衔接数据和算法团队，以及训练及标注；另外对于数据生产团队本身呢。

所以数据的发展阶段，从大的方向来说，可以统一为几个阶段

数据储备
数据分析/运营
数据决策
数据创新赋能

数据储备阶段我们已经走了很久，公司数据的下一阶段要往数据运营的体系走，现在业务诉求对分析要求越来越高也是个契机，机遇很重要。另外不是一刀切，每个阶段，对于旧的阶段，要保证对等规模的持续运作。

那么，怎么理解我这里定义的数据运营

主要表现在：

用数据说话，用数据反馈过去工作
用数据来指导未来工作
形成数据闭环产出->过程->(指标)衡量->质量->产出

事情层面，聚焦在：

整个公司数据汇总
数据的动作透明
数据质量
数据安全(补充)

所以我们现在做的事情都有合理的解释，未来几年，事情也肯定都是落在这个框框里。而不是推各种概念，数据仓库，数据湖，数据中台，DataOps，DataMesh，数据质量（kylin，griffin）等等各种工具，每一项工具都不是解决问题的银弹，而是要内化，利用先进的理念组合去落地。

其实提到的一些概念，包括数据中台，DataOps底子内容是差不多的，由于理念导致的产品差异，前面侧重能力聚合，后者侧重运营，都能提供服务。对于本身数据中台的理解，也不仅是技术的事情，可以是一种技术架构，可以是一种组织架构，可以是一种数据理念。

以及数据工厂，怎么去定义1.0 和2.0 ，怎么拆解到下面的事情，业务上新增加国家，流程上哪里优化了？技术上做了哪些块的事情？需要哪些人员配套并且如何配合？

之前关注过一段关于数据驱动的，有本书我觉得不错， Qubole（一家主打分析产品平台公司）的 Creating a Data-Driven Enterprise with DataOps ，

我的理解：公司之前可以算作业务驱动，业务驱动到数据驱动的转型是以业务为载体，围绕客户为主体，数据为核心的一种产品增长策略；是属于自顶向下的设计，要有思想领导力的开拓者和培养播种文化的土壤，最后才是配套以组织架构的分工作为手段，控制期望，迭代前行，否则会变得口号化；

没有一个通用的模式，能走出适合自己的模式那将会是件富有成就感的事情。

需要遇到对数据有深度思考的人，能够觉得脑子闪光，带来新鲜度和变革跳出这个现有框架，改变整个配合的模式，又让我们觉得是合理的。

想重新定位团队，从哪些角度去整合数据部门。

重新定义Data - 改革

数据的过去现在未来
过去阶段储备阶段 - 这块内容永远是持续的
现在阶段我们要做并需要做好的数据运营（并且需要尽快过去这个阶段）
未来阶段我们需要集成机器学习的能力反哺过去的数据处理
岗位轮转

新入职的需要在业务线上岗位轮转

岗位职责定义

架构师的责任，尽量不要在业务里面做高级资深开发也能做的工作，跳出来思考问题

组织架构重新定义
小组之间如何合作

尽量小规模，人多是不利于决策的，但结果要透明

谈谈管理

毕竟也做了一些年的管理工作，小组到多个小组，定OKR，理解Scrum，绩效评定，年中面谈，任务规划，跨团队合作，跨国合作，外部客户合作，接触各大云厂商，接触最新技术实践，冲突管理，辞退等等，最近几年也作为公司“闻味官”面了较多的人，如何在完成公司级任务的前提下自省并进行自我团队的迭代升级。

仅记录点碎片化思考以及供自己回忆

我喜欢的团队文化

微信团队的思考模式

在和微信团队接触的过程中，我发现微信团队有个典型的共性，当我作为用户提出需求或是反馈问题的时候，往往并不会得到一个直接的答案。但是过一段时间，会看到我的反馈生效，但他们会用另外一种更好的方式实现。在这次演讲中，提到了微信需要什么样的人？「我希望我们团队，在每一个领域都有杰出的深入的思考者」。只有「深入思考」，才不会只为KPI做事。当一个团队，越盯着KPI去做文章，就会越短视，就越不可能做出好的产品，在大公司里尤其如此。微信团队，是某种意义上的长期主义者。

关于管理

对我来说管理者最需要且最先有的品质是：真诚。

管理是管人理事，理事是基本，这个也是新手工作以来专注于事情的成长，但在管理，也要兼顾管人，是指，知道每个人的能力，优劣势，安排合适的事情位置；激励手段，奖惩机制；招人；外部合作沟通，争取资源等。管理要能够做得好，必须两者协调，达到同样的脚步，可以一快一慢，但一定在有限度内，保持同一个节奏，甚至是需要慢的一方能更快一点追赶。否则，对于不同的位置，不同的管理场景，能达到的能力取决于慢的一方达到的程度。

最大的竞争是人才的竞争，古往今来，任何的事情，人才是事情成功与否的最大因素。领导会成为天花板，首先一定得理解，事情；吸引人才是第一步，怎么利用人才，引导人才是第二个挑战，第三是成就人才，这是我认为对人管理上做得好的标准。领导是掌舵者，不能成为掌权者，一定需要多和下属沟通，理解他们想做什么，因为他们才是最接地气的执行者，大部分是最有效有用的，作为掌舵者，需要做的是起好大的方向，定好事情的边界以及优先级，一定要有自己的理念，并灌输给下属，同时也包括外部环境的变化；基于此，领导需要转为服务者，需要协助他们排除干扰，提供资源，解决冲突，给大家打气并坚定信念。

领导的作用：让下属更好的做事，专注，有界限的控制事情。而不是迎合外部需求，外部满意了，内部痛苦不堪。技术驱动创新，必然是自顶而下的战略指导，支持，信任，否则只能是底层自我YY的过家家。

关于执行

计划有其必要性，但不应该为了计划而计划，计划不应该有太多细节，指明粗略步骤方向即可。更应该做好的是，定期归纳总结回顾，因为事情是螺旋式发展的，很多东西是在做的时候得到验证以及产生新的想法，回顾才能够有更多的细节，也同时能够明白真正到底是否做了多少工作。当然，回顾的周期是需要权衡的点，短了长了快了慢了都不好。

要想成就一件事，推行一件事，首先要熟悉环境，明确大家的做事方法，对理念的接受程度，下一步是推行理念，而不是直接做事情，理念先行，进而是执行力。

很高的层次看项目推进，混沌有序的才是常态

开发产品协调，最具有争议的事件，关键词：重构，自动化，框架（平台）。

关于能力

一个人的能力形态：

跳出表象看到本质 40%
理解了本质，如何有实施步骤 20%
落地 40%

站的位置越高，如何能看出能力。第一个是理解事情，知道有什么，这部分其实很多人都能够做到，也是说的能力，但是真正是不是理解了，能从后续的动作，特别是组织结构上来配合你的理念或者战略，包括部门职责定位，方向等来配合愿景，后续再不断调整跟进，做好各阶段的掌控，这块能跟上那才能够真正的懂并且是富有经验的。光喊口号是没有用的。

其他

不是说优秀的人让他干什么都行，什么活都可以接下来，反而应该发挥他们更多创造性的价值，对于不够优秀的人，要擅于发现他们的长处，做适合他们的事情，再根据意愿，有计划的培养。

当只有一个小组时，大家其乐融融，都当成自己的事情；当团队壮大，需要划分小组时，小组之间的工作界限要明确，当现任领导还在的时候，能够兼顾，同时允许部分容错；一旦换了负责人，那么两任负责人的理念不一定完全一致，这是由于人的精力，认识决定的，如果不重新定义给下面人划分职责，定位，那么会在底层慢慢造成影响，小组的目标，进而到每个人的职责，考核，事情推诿，合作对具体的事情较真，做着事情，但心里不一定认可的状态，这个影响都会是潜移默化的。

公司大了，必然会演变成利益共同体，同时又会阻碍人的创新。因为一个大点的项目，必须依靠各个部门的配合来完成，不管你要做什么，别人必然要分一杯羹，另外一个坏处是，对于优秀的人，不利于其发挥才能并创新，对于平庸的人更能够浑水摸鱼，并且这种模式当出现问题了也很难追责，因为都是大家配合的问题，但这种结果往往会令优秀的人内心得到伤害。

引言

最后引用一句名言来结尾吧，人生也是如此：

美国篮球名人堂教练John Wooden说过一句话：Be quick but don't hurry

Go Top

nexrol

Published