不会提问不打紧,不敢提问才要命

4 评论 1387 浏览 2 收藏 21 分钟

进入职场后,职场新人常有的问题可能是不知道如何提问,又或者是不敢提问。这篇文章里,作者就结合他人在数据行业领域的提问做了案例分享,不妨来看看本文的讲述和分析。

最近在星球里回答了球友提出来的一些问题,我都给了回复,不经过在明确问题、探索问题的过程,对我启发挺大,特此来记录下感受和感悟。

缘起

最近新加入球友提的问题,有几次,我第一时间没看懂,甚至觉得有点奇怪。

怎么描述这种感觉呢,打个不恰当方便大家理解的比方,经过培训,我学会了做咖啡和做豆浆,并能解答如何制作这两款饮品的提问。

在我的视角里,球友的某次提问是:请问怎么用咖啡机做豆浆

比如,当被问到如何构建用户画像、标签体系,我会从经营分析的指标讲解到数据洞察需求,然后再讲解到标签,再往下拆解标签和指标的关系。

如果问,怎么做数据仓库/怎么给数仓分层,那就可以讲解事实表、维度,构建数据仓库的四个步骤,数仓分层的原因,任务调度,血缘依赖等。

经过长期学习和实践,我所掌握的知识和术语体系算是体系化的,不同场景的问题,可以用对应的术语体系结合案例讲解方法论。

而当不按我所理解的常理出牌的问题出现,一下子就把我给整蒙了,啊?这是怎么搭配到一起的?

不过,回答这样的问题反而能发现大家对于知识理解和学习的状态,或许,这才是大多数人刚进入新领域的常态。

通过沟通和交流,我收获了不少,分享给你们~

一、提问和解答的纪实案例

案例1

球友提问:

主数据和事实表的标签怎么打

听到这个问题我的反应是,嗯?主数据和事实表这俩好像不是同一个维度。这到底是要干嘛?问题描述所用的词和概念都错配了。

这位球友加入星球时,有聊过自己所处的行业背景、工作经历、工作内容,正在做数据资产管理。但是我还是得回到问题现场,通过沟通确认:引发提问的真实问题是什么以及提问的原因。我问,这个问题的背景是啥?球友回复到:

1、是在做资产管理,用标签,所以才问的ODS,

事实表,主数据我们是存在不同的库里面,ODS就会有来源业务系统、数据库类型这种标签,事实表就是多级业务域这种标签

2、现状问题怎么用这些标签已经设计了,无非就是淘宝那种多级目录筛选。

但目前考虑只在后台表存,不做标签管理系统

3、遇到的问题目前开发没做过标签管理,觉得这种关系挺复杂的。

我又想以后考虑设计标签管理产品,所以想提前把这个标签的模型想清楚,也就是标签怎么存储、后面管理标签怎么设计

经过沟通我才明白了,球友考虑的问题是多个领域结合的。更重要的是,这段的表述和我脑子里的概念、术语体系,没匹配上。如果我来描述,我可能会用【表的元数据】去描述,而不是【主数据、事实表的标签】我做了一些回复,如下:

挺有意思的问题。

主数据,事实数据,好像不能 MECE。我们来捋清楚这两个维度的概念。

先说事实表。

数据仓库里的事实表是指各个主体发生的行为事实记录。用户注册,用户登录,用户浏览,用户收藏,用户加购,用户下单,用户支付(更多的就不列举了),全都是用户这个主体发生的行为动作,都是事实我们可以对一些事实进行度量,也就是定义一些指标。

用户登录次数、下单次数,这是行为层面的度量。还可以从时间、金钱进行度量,比如,用户浏览时间,用户下单金额。当然,你也可以把度量换成另一个词,指标。主体和主体发生的行为,以及对行为的度量,就构成了所谓的事实表。

再说主数据。

主数据的概念,是基于信息交换保证数据的一致性而提出来的,可以理解为,向谁对齐,以谁为准。比如,一排人,站的前后位置,向右看的时候,跟最右边的人对齐,那么最右边的人所站的位置,就是其他人所有人的参考和标准。那万一,另排的标准定的定的是向左看呢?整个方阵,就可能对不齐了。

主数据,是大家协商以后,选定出来的。比如,用户信息,商品信息,订单信息,这些数据对不齐,不一致,公司连最基本的账都没法算了。大家一致觉得,用户信息表、商品表、订单表是很重要,要对齐的,就把它们定为主数据,确保数据的一致性,所有的系统用到这块数据,都要向主数据对齐。

可以看出来,事实表和主数据是有概念交集的,比如,用户注册事实表可能是一个主数据,各个系统都要使用用户最基础的信息,比如,手机号,性别,年龄,注册时间等。

最后,再说打标签。

打标签,是在一定程度上减少信息,用非常简单的标签词,来进行代指。比如,小红书上很火热的 MBTI ,I 人和 E 人,代指的内容很多,但是只要大家亮出自己的标签,那么能够快速给人一个感觉,你是性格开朗,还是性格内向。

但是,如果细究,你会发现,怎么量化这个开朗,有多开朗,就需要更加细致的事实案例来证明,比如,参加了多少次陌生人社交活动,主动加过多少人,主动发言的次数。对表进行打标签,也是一样的。核心是要看,标签用在什么场景,大家现在习惯用什么标签来定义表,以及找到这些表。

如果说是对表进行标签类目管理,可以考虑两个标签,是否主数据,是否事实表。业务域、业务过程、主题、所属分层,是可以给事实表的标签。主体类型,重要程度,是可以给主数据打的标签

我以为讲解完主数据、事实表的概念和区别问题就结束了,不过球友继续问如何打标签,然后我们继续探讨如何打标签。案例2球友继续补充问题:

针对最后两句中,提到的主数据和事实表的标签。这两类标签,相当于通过2个标签的取值来判定是否添加,这两类标签相当于跟这一个标签之间有关系了,这个关系算作标签树吗?还是仅仅是标签关系,或者是标签模型?在做标签定义的时候,要每个都单独定义,还是做成分叉树呢?

其实蒙了,问这干啥?怎么还提出来分叉树了…好在,我反问了下:对于标签关系,和标签树,你的理解是怎么样的?球友回复:

标签树,我理解就是一级标签、二级标签这种,比如,一级标签是表分层,值如果是事实表,二级标签就是业务域,三级标签是子业务域,但这个好像不太对;标签关系就是,标签只有一级,都是并列的,但业务域这种标签会跟表分层这个标签绑定关系,关系要单独建

我回复到:

如果标签不多,没有逻辑层面的层级分类关系,直接打平、打散,就好了。如果标签很多,可以按照维度去拆解和细分,构建标签体系树。

标签的分层、分级,跟组织架构类似,是有逻辑关系的。比如:事业部、归属事业部的一级部门、归属一级部门的二级部门这个跟数仓里面的业务域、子业务域其实也是类似的。关键是,怎么划分业务、子业务呢?仁者见仁智者见智了。

球友提问:

结构化标签体系树 跟 标签类目 应该是两个概念吧类目,应该是这个标签属于哪个分类,比如地址信息,下面会有国家、省份、城市,他们都属于地址信息这个分类下,但同时,国家-省份-信息 构建的时候是一个结构化的标签树。

听到这个问题,我又蒙了,这说了个啥问题呀,我怎么又没听懂?但我还是回复了,还给了建议(甚至还洋洋得意地举了微信标签作为案例)。

标签体系树、标签类目,在我个人看来,差不多。

我觉得,你不必过多纠结这些概念了,带入场景案例去思考才比较好,以及通过真实的案例去解释这些概念,才是比较好的学习模式。就好比,我问你,什么是标签。你能列举出来N个案例,那你大概理解标签了。

但是,如果你说,标签有3种,属性标签、规则标签、算法标签。那可能还是在套概念,那如果继续追问,什么是属性标签?如果你回答很抽象,给我举例并不是你在项目里经历过、在生活里经历过的标签,那就是没实战,还停留在概念套概念阶段举个例子,微信好友是可以打标签的吧~这种标签,是扁平化的标签,没啥逻辑关系的,对吧。

抛开标签,设置朋友圈权限的时候,是否对她可见、是否看他,是不是标签?其实也是。为什么要设置是否可见?因为有的人不想被其他人看到,或者不想看到别人的发。为什么要设置标签?因为可以批量地对这些标签里的人进行设置。发朋友圈,直接勾标签。

球友回复:

嗯,就是在想一个问题,比如,我拿到一个表,如果我定义2个标签 业务域和业务子域,我知道它两个标签的值,我未必知道这两个之间的关系。

还是蒙的,因为不太知道这个问题的场景是什么?我让 ta 继续展开说说(后面我才明白)球友回复了一张图:

比如这个,在类目基础属性下,有国家、省份、城市、县区标签,是平的,没有结构。标签存储的时候,就是四个标签。有另一个地方,才会存这四类值的关系-这个关系,我在创建标签的时候,可以不考虑,只要说明是从哪个值来就可以,在检索的时候,才会调用这个关系,去查。

我当时看了下,没细想然后回复了:是的。你可以去了解下层次维度。后来,又重新看了下问题,又捋了捋,举例说明了下。

之前让你看层次维度。层次维度里,典型的案例有两个:地区维度,时间维度。在创建标签,是可以不管标签的值是怎么来的,以及标签之间的逻辑关系是什么。

但是,如果要按照国家、省份、城市进行汇总统计的时候,必然要知道,国家-省份、省份-城市、城市-县区之间的层次逻辑关系,不然没办法判断标签值是否录入错误了。比如,有个人的这四个标签值是:中国、北京、北京市、海淀区,这个逻辑是对的。如果他的标签是:中国、河北省、北京、海淀区,那就不对了。那么按照省份/直辖市汇总北京、河北省这两个地区的指标(比如,人数)时,就会汇总错误。

二、我的感受和感悟

这么长的问题沟通过程能看下来,看下来不容易,感谢~!

不知道看完你的感受如何?

复盘来看,我觉得球友提出的这些问题,提得很好。在解答问题的过程里,也启发我不少,细讲一下。

1. 没有绝对的好问题,敢于提问就很好

如果你也是数据行业从业者,回顾下自己的学习过程,就能理解提问的难。在数据领域,抽象概念和术语体系本就很多,想提问都不知道怎么提。

我刚接触数据产品的时候就是这样,弄个元数据、元元数据/元模型、元元模型结果被弄得怀疑人生。我当时也是问了很多人,用各种方式提问,看了很多资料和案例,才稍微明白一点。

看了《学会提问》,我学会的不是提问的方法,而是批判性思考,面对问题要多思考,多探究,探究不下去了,就及时提问。

没有傻问题,胎死腹中的问题才是最大的问题。萦绕在你脑子里的问题,因为不敢提出来,所以并没有得到很好的解决,你对世界的感知依然是抽象的、模糊的,而不是一个一个具体的案例。

2. 不知道怎么说,那就带着别人一起看“现场”

从上面的案例里,你也可以看到,当我不知道球友到底在表达什么的时候,我都让ta展开说说,举例说明。当ta列举了案例和背景之后,我就大致明白到底说的是啥了。语言是抽象的,而且,很多人在被专业的术语、概念、流程教育、甚至是驯化以后,反而不知道怎么用最简单、最接地气、人人都能理解的方式进行表达了。

肚子饿了要吃饭怎么表达?用英文呢?I am hungry。如果用西班牙语、俄罗斯语呢?况且,英语要吃饭,还可以说 I need food,还可以说 I am starving(我快饿死了),不会用语言表达的时候,就用身体语言(Body Language)或许很高效。用手指指着嘴巴,或者做个往嘴里扒饭的动作,别人或许就懂了。

当我们还没有娴熟地掌握最贴切的名词、形容词来进行表达,对方不懂我们说的、理解不了是很正常的。作为咨询者,听不懂别人说的也很正常,既然听不懂,咱们可以直接到问题现场观察,反而能快速诊断发现问题。

3. 人生而不同,本不存在什么放之四海而皆准的话术体系

每个人都有属于自己的观察、理解、思考、表达习惯,只有通过学习、沟通和碰撞之后,才会矛盾、冲突之后,慢慢和其他人达成一致。

有的人能力超群且德高望重,则可以引流潮流,制定术语标准,但这毕竟是少数。多数人则跟随标准和潮流,为的是对齐,核心是提高沟通效率。

我也逐渐知道,当我没了解问题时就胡乱回答,大概率是答非所问,想要回答清楚,必须帮忙先捋清问题背景

4. 少扯虚头巴脑的概念,概念套概念,多讲案例,这才是真的懂了

在我不了解元数据,不了解标签之前,这些概念对我来说,就像是考试背的知识点。元数据是解释数据的数据,标签是从业务角度对数据进行的描述。

嗯,多看几次,然后呢?能解决实际问题吗?并不能。只有当你把这些概念用起来,结合工作、生活的案例理解清楚,你甚至可以不用知道这些概念的标准定义,直接上手解决问题,你就是牛的。

5. 面对提问,多点耐心,教人是重新学习的机会

教是更好的学,在这么多年的学习、教学过程里,我接触到不同行业的人,发过的内容也被不同的人Diss、Challenge(有很多人吐槽内容不行、很虚了,哈哈哈)

面对问题,不泛泛其谈,而是多积累问题和案例,多洞察自己同行解决问题时的情绪,时间久了,同理心也就出来了,玻璃心也少了,在咨询和帮助别人的过程里,我学到的知识就更多了。

当自己能把一个案例讲好,帮助一个具体的人弄懂一个非常具体的知识点(对方反馈,我终于听懂了),会非常开心。当然,如果这个提问能给我带来更多的价值回报,我会更有动力,人性趋利避害。

三、最后

1. 不是你脑子很乱,而是你想解决的问题很多

相对于信息爆炸的世界,语言所能表达出来的内容就像是沧海一粟,书到用时方恨少,尽力表达就好~

2. 不是你提问不好,而是别人不懂你的提问

没有蠢问题,而是没碰到对的人,或者对方没耐心了解你的真实问题。你是问题的负责人,不要因为被拒绝被否定就质疑自己,找到对的人提问~

3. 不是你不行,而是你没有踩上风口

这个世界是结果导向的,能抓到耗子的就是好猫,我们会面临很多问题,但是有这些疑问和问题并不是我们不行,而是没有合适的实践机会,保持好奇,等待机会~

让我们彼此尊重,一起探索有价值的问题。

专栏作家

Lee,公众号:数据产品小lee,人人都是产品经理专栏作家。关注直播、短视频和文娱领域、擅长数据架构、CDP及数据治理相关工作。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 没有绝对的好问题,敢于提问就很好。这说的不错,很多人都不敢提问,害怕被说,被谴责。所以选择不说,我觉得说出来真的很有勇气。

    来自安徽 回复
    1. 问出来就挺好

      来自湖北 回复
  2. ”面对提问,多点耐心“这个观点我非常认同/其实很多新人小白经常会在鼓起勇气敢问问题的阶段被打击,不是所有人都像博主这样能够一次又一次的详细解答。也许他们不是不敢提问,而是怕没人回答。

    来自广东 回复
    1. 是的呢

      来自湖北 回复