王辉的博客

是什么让我对未知世界始终充满热情?

技术管理者的成长中,有两个因素的比例会发生变化:技术和管理。起初,技术占主导地位,比如 Tech Lead 会花时间做架构设计,写代码。接下来,从管理一个团队,到管理多个团队,技术的比例会降低,管理的任务会增加。技术就像功夫一样,一旦停下来,就退化了。保证下属,特别是 Tech Lead 下属工作的质量,作为管理者,要学会借助外力

Tech Lead 接受一个新项目,经过一段时间的努力,敲定了解决方案。管理者要求 Tech Lead 把他的方案展示给其他团队里的 Tech Lead 做审查,收集不同方的意见,完善方案,就是所谓的借助外力,保证质量。

管理者也可以亲自上阵做方案的可行性分析,然后拍板做决定。可这样做有好几个缺陷。一是管理者本身的技术洞察力会退化,所做的决定会有片面性。二是,管理者会耗费时间去查看具体的事务,占用自己的时间不说,还很有可能成为团队进展的瓶颈。最后一点,管理者如果幸好采纳了 Tech Lead 的方案,下属的积极性不会受到影响。而一旦管理者开始发表自己的看法,引入自己的理念,对原有方案进行修改的话,就会导致方案执行过程中,下属因为执行的不是自己的想法,而有所保留主动性。相反,像【影响力】中说的那样,一个人更容易被和他有着相同背景的人影响, Tech Lead 更容易采纳和他们有着相同身份的人的意见,而并不觉得被人强加了不属于自己的想法。

因此可见,借助外力,不仅可以节省管理者自己的精力,使解决方案更加完善,还可以确保方案的执行过程中下属保持高昂的积极性。如何才能借好外力呢?

首先,找到合适的 Tech Lead 圈子。不同的 Tech Lead 有不同的优势,要想得到贴切的意见,必须要有的放矢。作为管理者,要刻意的去培养这个圈子。当别的 Tech Lead 收集意见的时候,管理者自身和下属要积极的贡献想法。礼尚往来,当你们需要审查的时候,别人也来帮助你们。

其次,要选择好时机,不要等到万事俱备才找外力。要在设计初期,几个大方向明确下来的时候,征求别人的意见。此时的意见是最具有价值的,它们可以帮助 Tech Lead 砍掉不靠谱的分支,把精力集中到最有潜力的大方向上。如果拖得时间太长,越晚整合别人的意见就越麻烦。

最后,要保证在展示解决方案的时候,有态度,刻意的制造辩论点。我见过一些 Tech Lead ,在展示自己方案的时候,缺乏故事的带入性,一个人像念经一样,让别人不知道如何提意见。要想收集到有用的反馈,Tech Lead 要讲清楚所面临的的挑战及其背景,然后态度鲜明的讲解为什么你采纳了当下的选项,而拒绝了其他的。有取有舍,才能有辩论点。

技术管理者,随着管理任务的增加,技术投入的减少,必须学会从,事必躬亲做事情,到排兵布阵管事情的思维转变。只有这样,才能真正发挥团队合作的威力。

2021年5月26号,Contentsquare迎来了软银领投的E轮融资。此轮的5亿美元让Contentsquare成为了法国历史上单次融资最高的科技初创公司。

自2018年加入Contentsquare以来,我经历了公司的疯狂生长。就拿我们大数据组来说,三年间,团队由十人增长到了四十人,翻了三四倍。我想利用这个机会分享一下在Contentsquare的工作体验,希望能对大家的职业规划有所帮助,也希望更多朋友能加入我们!

拥抱未知

2018年,我怀揣着宝贵的七年工作经验,离开了Murex,告别了这个有着三十年辉煌历史的行业领头羊。拥抱未知是我迈出这一步的最大动力。

就像寻找全局优化一样,拥抱未知给了一个跳出局部最优解的机会。既然是未知,这么一跳也伴随着风险。就像退火算法里描述的那样,我们要注意拥抱未知的时机。

一是要确定找到了局部最优解。这样可以保证,我们有一个稳定的上升期来提升自身能力。如今我仍十分感念在Murex的七年,在那里,我打下了牢固的基础,从算法数据结构,到JVM调优,再到分布式系统的设计,直到如今,我还在享受着这些基础带来的红利。然而最后的一两年,任务开始变得缺乏挑战,学习的速度也慢了下来,加上组织结构的不稳定让我找不到自己的位置,我感觉我离局部最优解近了。

这时,业余时间学的Scala成为了我进入Contentsquare的敲门砖。当初最吸引我的是Contentsquare架构的高扩展性。每签一个新客户,比如宜家,沃尔玛,这个架构就得收集该电商平台上所有的用户体验信息。这些新的挑战,让我看到了找到下一个更优解的机会。

退火算法的第二个特点就是,越是初期,越鼓励去拥抱未知,而到最后温度降下来的时候,就不要轻易乱跳了。这里给我的启示就是,越是处于职业发展的初期,就越不要瞻前顾后,年轻人有更多尝试犯错的机会。

给大家推荐一本书,【赖以生存的算法】,其中有讲到通过探索与利用进行优化。

保持开放

高速发展的公司,项目不断,但是项目的质量参差不齐,有的核心,有的边缘。边缘的项目,也可以有预料不到的收获,也可以成为未来的核心。保持开放的心态,一是可以把握更多机会,二是可以证明自己,赢得信任。

进入Contentsquare,我的第一个任务就是一个没有人愿意接的烫手山芋,我负责的是Redshift数据库关闭后的扫尾工作。新来的我,抱着开放的心态,欣然接受了挑战。这期间,虽然不是意气风发的定义未来的架构,但是因为老方案盘根错节,让我结识了公司里几乎所有的产品和研发团队。

接下来,有两个项目,一是从 Elasticsearch 迁移到 Clickhouse 上,这是公司上下的明星项目,因为它可以大幅缩减开销,提升性能。还有一个小项目,是把电商网站的历史静态资源爬下来进行会话重放(Session Replay)。当时我收到的任务是做会话重放,彼时的边缘成为了下一个核心。对这个架构的了解让我参与了对竞争对手的收购,因为他们的优势就是会话重放。

点点积累,让我证明了自身的能力,渐渐赢得了决策者的信任。后来的机会越来越多,能第一时间参与到核心项目中,还打开了转型管理的大门。

开拓者

在大公司里,有很成熟的做事办法,责任划分清晰。而在一个疯狂生长的初创公司里,流程还没有定下来,新的挑战就来了。我最大的体会,就是要主动的做一个开拓者,不要等着有人把路线图给你画出来,因为没人知道下一步往哪走。

2020年我接手了一个项目。在产品做了一半的时候,产品经理决定离职,留下了一个烂摊子。产品可行性没有验证,大家对同一个数据有不同的理解,性能上有超时问题,代码还没有测试,项目经理和工程师都处于崩溃的边缘。这个时候,没有人会告诉我应该怎么办。如何从困境中走出来?

我采用的策略就是,不能停,也不能全盘推倒重来,要做小的可见的改变,即便每次走的只是一小步,也要继续往前走。让大家对数据有一致的理解,使我们选择的第一小步。像做应用题演算那样,一步一步的给所有的人解释最终的数据是如何计算出来的,在达成一致后,写测试,发布!就这样,团队的前进微弱势头保留了下来。一边艰难的往前走,一边挽回崩溃的队员,一边等新来的产品经理。等所有人员都配备齐全的时候,问题也还没有结束,新来的产品经理,虽然热情洋溢,但毕竟是新人,还得陪着她收集产品需求,查漏补缺。

初创世界就是一个 VUCA (volatility 波动, uncertainty 未知, complexity 复杂 and ambiguity 模糊)世界,有的人来了发现适应不了,做了几个月就走了,我没看到哪个团队能把整齐的队形保持一年以上。这是成长的痛,抱着开拓者的心态,挺过来,也就慢慢成熟了。

写到最后

最后的一次E轮融资,创造了历史。但就像Netflix里【Formula 1: Drive to Survive】那样,每个赛车手都尝试着在赛车崩盘之前把速度提到最高。在这种环境之下,团队既欢欣鼓舞,又如履薄冰。今天走的越高,可以再上一层楼,也可以摔得很痛。所以最好的心态不是憧憬或担忧明天会怎么样,而是踏踏实实的把当下的事情做好,享受当下自己的成长,享受和团队同进退的豪迈!

什么是自律?

【少有人走的路】是老友和我探讨管理技艺时推荐的一本书。作者斯科特,开篇写道:自律是一个解决人生问题最主要的工具,也是消除人生痛苦最重要的方法。

在工作中,我们会遇到困难,找不到答案,忍受未知的痛苦。这些困难,有的单枪匹马可以克服,有的需要多人合作。比如说软件里发现了一个 Bug ,可能是工程师误会了产品的需求,也可能是写错了代码。作为工程师,要先界定问题,这其中少不了东寻西问,其次是修改 Bug ,遇到复杂的技术难题,很可能一筹莫展,就像我当初没经验,内存泄露卡了我好几周。

幸好,我们不孤单,可以问经验丰富的同事。有的人,忍受不了未知的痛苦,向别人提问的时候,或是缺乏耐心,或是推卸责任。这样的放纵提问,不会帮助他们成长。相反,自律的提问者,主动要求自己以积极的态度去承受痛苦,解决困难。在回答者的眼里,提出问题是他们的起点,解决问题是他们的目标。自律的提问者通过克服困难获得成长,对得起回答者的时间和经验。

为什么要自律?

如果开口就能得到答案,摆脱未知带来的痛苦,为什么还要做一个自律的提问者?

最主要的原因,是自身无法进步。没有经过困难的历练,无法成长,只能依赖别人,没有任何一个团队愿意花时间去培养一个止步不前的人。

另外一个重要的原因,包容是有限度的。我们在【包容的回答者】中倡导回答者要给提问者足够的耐心,用力去体会他们的痛苦。这意味着回答者要高度集中精力听问题,做有背于本能的换位思考。提问者每消耗一次回答者的包容,就像在储蓄罐里取了一次钱,长期以往,入不敷出。如何存钱呢?自律的提问者,自己先做好换位思考,给回答者创造最佳的回答姿势,让他们自然的答疑解惑。

如何学会自律?

如何做一个自律的提问者?我想从一个团队管理者的角度出发,把这个问题转换成:如何培养自律的提问者?

  1. 培养成长型思维:拥有成长性思维的人,相信有志者事竟成,承受痛苦的能力强,不会轻易在困难面前低头。
  2. 给予足够的包容:【少有人走的路】里,斯科特说,自律的动力是爱。父母的珍视让孩子懂得珍惜自己,懂得选择进步而不是落后,懂得追求幸福而不是自暴自弃。他们将自尊自爱作为人生起点,这有着比黄金还有宝贵的价值。同样的道理,回答者的包容,让提问者学会奋进,不辜负师长的耐心和关爱。

成长性思维

应用到提问者身上,我们可以通过推迟他们发问的时机来培养成长性思维。下面是在遇到困难的情况下,一个人会在不同阶段提出的问题:

  1. 你说怎么办? 把问题抛给别人,缺乏耐心,逃避困难。
  2. 你说这是为什么呢? 没有逃避困难,开始思考,但是没搞明白原因,可能是能力的不足,也可能是惰性导致思考的不够深入。
  3. 你说这个方案可行吗? 搞明白了原因,思考的比较彻底,有一个方案,在执行之前征求别人的意见。
  4. 我建议考虑方案甲,抛弃方案乙,你看呢? 思考既彻底又全面,考虑了多个方案,并有所取舍,征求对最终方案的意见。

这个由浅入深,由点及面的过程,体现的是一个人和困难的搏斗情况。提问越早,表明做出的努力越少,提问者往往受固定性思维所困,认为自己克服不了困难。提问越晚,说明和困难的交战回合越多,对自己的心智磨练的越多,他们是成长性思维的受益者。

举个例子,我有一个刚入职的同事,发现入职培训里很多东西都没有顾及到。他问了我一个第三阶段的问题。他说,我发现入职培训里没有讲到如何从头到尾的上线一个服务,我想写一个教程,教大家如何写 API 、文档、测试,如何部署到云上,你看这么做行吗?

收到这个问题,我感到欣喜,不仅帮助他推掉其他任务让他完成这个教程,而且还特别骄傲的把他的成果分享给了其他团队。

如此,层级越高,满足感推的越迟,承担的责任越大。可就像斯科特说的那样,自律的人除了要推迟满足感,承担责任以外,还要保持平衡,并非处处都要达到最高层级。

如果遇到紧急问题,比如生产环境下服务器崩溃,要尽快问大家怎么办,集思广益迅速解决问题。即便不紧急,也未必走到最后,万一费尽心思的方案有瑕疵?万一有其他更重要的事情需要处理?自律的提问者,要勇敢的面对困难,但也要审视解决问题的最佳时机和最佳方案。

给予包容

成长性思维的培养需要循序渐进。职场新人能力经验有限,即便是职场老炮,如果受固定性思维所困,提出问题的时机都会偏早。作为一个经验丰富的过来人,回答者要包容,不能把这些问题看做是蠢问题,伤害提问者的自尊心。但这也不意味着,回答者有义务解决他人的问题,像亲密关系里说的,一方有多少牺牲,另一方就有多放纵。回答者可以通过引导,指出方向,让提问者自己找答案。具体的做法,就像我在如何做团队的教练里说的那样,保持好奇,耐心倾听,少直接回答,多反问,启发思考,感兴趣的朋友可以细看教练的习惯。

写在最后

学习是人的天性,从娘胎出来的孩子,还没来得及好好的看上这世界一眼,就得学着喝进第一滴奶。接下来,我们学习翻身,正坐,爬行,直立,走路,说话,阅读,写字。哪一样不是莫大的挑战,可我们没有放弃过。

这一切,一是我们拥有突破自己的天性,甚至有人到生命的最后时刻还在努力着超越自己。二是,每次跌倒,都有一双充满爱的手把我们扶起,给我们力量。

我坚信,每一个人都有智慧去克服困难,做一个自律的提问者!每一个人都值得尊重,对身边的人做一个包容的回答者!

当我第一次思考蠢问题的时候,我关注的是蠢问题的定义:什么是蠢问题?。后来一位读者反馈到,“给蠢问题下定义没什么意义。应该放下我执,想问就敢问,得到答案比面子重要”。我这才意识到我的做法是非常片面的。尤其是回想起【改变问题,改变人生】书中说到的学习者心态以后,我才恍然大悟,哪里有什么蠢问题,只有因为评判而错失的学习机会。当我们被冒犯而把问题当做蠢问题的时候,就进入了批判者模式,走上的是互相指责、伤害的羊肠小路。而怀着包容的心态,一个学习者,走的是一条通往理解、进步的康庄大道。

作一个包容的回答者,特别是对于决定要带团队的人,至关重要。因为我们常常面对的是新人的提问,我们在回答问题的时候,很自然的就会出现地位上的差异。在这种差异下,包容的回答者,既可以培养他们的自信,又能保证他们的发展。

所谓的蠢问题

下面是几个容易被当做蠢问题的问题,让我们看一下批判者和学习者分别是如何应对的。

没经思考的问题

有一次,一个新来的同事问,“如何在Github里创建一个仓库?”

作为评判者,特别是一个日程满当当的评判者,可能会被惹恼,心想,“这么显而易见的东西,难道你不知道答案吗,我都怀疑你是怎么通过的面试”。如果我们因此说这个问题太蠢,自己生气不说,提问者的自尊也会受到伤害,他可能觉得自己太笨,能力太弱。

换成学习者,我们心里可能会这么想。这个答案对我很明显,可他为什么没明白呢?是我的经验比他多很多吗?还是这个人没有思考?还是他真正想问的是另外一个问题?

与其说这个问题蠢,不如反问一下,这个问题你是怎么思考的?你真正的需求是什么?后来才明白,他真正关心的是创建仓库的注意事项。幸好没有给他一棒子打死。可别说,我们创建仓库还真不是点个按钮那么容易,为了保证仓库的私密性和明确的责任团队,仓库的创建被自动化了,申请人需要创建一个PR,提供必要的信息,通过审核后,才可以得到想要的仓库。

问了又问的问题

又有一次,是一个初涉职场的年轻毕业生,“Tech lead和技术经理有什么差别?”这个问题他在不到两周的时间内问了我两次。

当一个问题被问了第二遍的时候。我们的批判者思维特别容易被激活,这是一个非常让人恼火的事情。难道我第一遍讲的事情都被当成啤酒喝了吗。

而深呼一口气,转换成一个学习者,我们会想,这个问题我第一次已经给他讲过一遍了,是他忘了吗?还是我第一次没有讲清楚?还是问题有了新的进展,他有了新的想法?这时候我们可以说,这个问题我们上次讨论过一次,可能是我当时没有讲清楚,你是有了新的想法了吗?这时候你很尊重别人,他很有可能说出新的想法,也可能是问题太复杂,真的需要解释好几遍才行。

上面这个问题,后来我解释了第二遍。再后来,各小组经理开会的时候发现,很多人都有这个疑问。被解释了好几遍,并且真正和Tech Lead以及技术经理共事后,人们才会真正明白其中的区别。由此看来,重要的事不仅要说三遍,而且还得通过实践的检验。

问错人的问题

还有一次,一个产品经理,问我们一个后端工程师,“如何激活一个功能开关让她测一个新功能?”

我们对所问的事情一窍不通。作为批判者,我们也可能被惹恼,说你问问题之前,为什么不了解一下我呢,这个问题和我一点关系都没有啊。拜托你能不能在问之前,先了解一下谁是干什么的。

而作为学习者,我们会心想。是有人给他推荐错了人吗。还是说我们公司里缺少对团队职能的介绍,所以他才拿了这个问题问了错的人。我们可以反问他,对不起,我在这个问题帮不了你,有可能是有人给你提供了错误的信息,我不是这方面的专家,你是怎么找到我的?这时候,这个人会把他如何来的讲清楚,我们就有了一个提升团队职能介绍的机会,可以帮助更多新人找到对的人问问题。

回到这个无辜的产品经理上,人家注重的是功能,怎么能分清那么多的前端,后端,全栈工程师的职责。她的问题恰恰可以督促团队澄清每个人的责任范围。

不清楚的问题

另外一次,是一个家政阿姨,我本来问她善长做什么菜,她问我,“你家最近的地铁站是哪里?”

听完了她的提问,我们都不知道她在问什么?或者知道她在问什么,却不知道她为什么这样问。作为批判者,我们会说,我根本不知道你再问什么,你能想好了再问吗。

而作为学习者,我们会想,她的问题不清楚啊,我不知道她在问什么,是不是他来的太急了,还是她之后还有其他的问题。她真正的目的是什么呢?这时候,我们可以反问,“对不起,我没搞清楚这个问题,你能具体的解释一下你的目的吗?“。这样可以引导提问者找出她所面临的真正的挑战。

这位阿姨,问位置,其实想优化自己的行程,在她看来,如果离的太远,我做的菜再好也没用啊,我犯的起从城东头跑到西头做一个红烧茄子吗。

学习者心态

通过上面的几个例子,我们可以看出,要培养学习者心态,一共可以分为三步

  • 接纳问题:不管问题有多么的让人恼火,我们都要避免心智被本能控制。当你的思维被评判者绑架的时候,要像邢捕头那样,想想为什么,世界这么美妙,而我如此暴躁。意识到批判思维,有助于把学习者找回来。说到接纳,我想起了非暴力沟通让我学会了接纳,有异曲同工之妙。再延伸一下,明白正念概念的朋友,会发现这里用的正是此技术。
  • 分析问题:接纳之后,我们就创造了深入认识所提问题的机会。造成这种局面的原因有可能是什么呢?是提问者的原因,还是回答者自身的原因?这时候我们可以用一种尊重别人的方式,问对方几个问题,确认之前的种种猜测,搞清楚问题的来龙去脉。
  • 解决问题:前后脉络都清晰的时候,我们知道了对方真正的目的,根据提问方,我们可以选择回答,也可以选择通过提问的方式去引导。当然了,如果是老板在问问题,我建议最好不要去引导。

我相信,这种心存公允,谦虚好奇的处理方式,对提问者和回答者都大有益处,因为它会在团队里,催生尊重、信任,鼓励大家共同学习、进取。

这里我们对回答者提了很多要求,他们付出了很多的耐心,给予了很多的包容,去营造双赢的局面,作为提问者,我们如何做能对得起这份耐心和包容呢?更何况人非圣贤,包容也是有限度的,我想我们很有必要去探讨一下如何做一个自律的提问者,特别是我们在现实生活中会在这两个身份之间来回转换,真正的可持续长期健康发展,来自于包容的回答者和自律的提问者。

什么是设计方案?

解决一个复杂的问题,一般要经过几个不同的步骤。其中最重要的是问题发现阶段,分析阶段,和构建交付阶段。在分析阶段,工程师们研究哪些方案可以解决客户需求。一个设计方案,不代表已经有了可以上线的代码,虽然在验证方案的过程中,有可能会写一些代码。设计方案,是分析阶段的成果,它告诉大家

  • 真正需要解决的问题是什么?
  • 为什么要现在解决?
  • 如何解决?

为什么要写设计方案?

有始有终的团队,在每个阶段结束的时候,会审视目标是否达成。对于分析阶段,他们会查看设计方案的好坏,来鉴别工作成果。而有些团队,射出去的箭,还没看是否击中大雁,就迫不及待朝大雁跑去。没写设计方案,就撸代码,一是沟通效率低,二是容易在项目后期发现设计上的缺陷而进入令人焦虑的赶工模式。

写下来一次,随时随地用

口头交流,眉飞色舞,固然爽快,可是口说无凭,什么也留不下来。结果,嘴皮子磨烂,一遍一遍得给不同的人讲你们的方案。这里我们要学习Java的设计理念,写一次,哪哪都能用。把设计方案写下来,有助于和团队里不同职能的人沟通:

  • 产品经理: 保证对问题一致的理解,并且知道方案的优势及其劣势,不会到后期发现劣势而导致意外
  • 项目经理:阐明方案所做的假设以及可能出现的风险,帮助在项目执行过程中追踪这些风险
  • 团队成员和其他团队负责人: 收集大家对方案的看法,接受大家对所选方案的挑战,保证你的方案凝聚了各种思维的光辉
  • 老板:当成汇报,帮助老板看到你们的成果,并且给他提供一个管中窥豹的机会,让他看到你们整个团队的合作质量
  • 质量工程师: 说明你们要构造的是什么,帮助他们写出好的测试
  • 团队的新人:帮助新人获取知识,所有的设计方案积累起来,就是一部团队发展史,帮助新人了解大厦是如何一层一层建起来的

真正的学习来自于清单检查

曾有人问一位智者,你是如何成功的?智者答,正确的决定。人又问,如何做正确的决定?智者再答,经验。人仍不解,如何获取经验?智者说,错误的决定。

犯错,大家都难以避免,而有的人错了再错。真正的学习来自于错误到经验的转化。写下来你的设计方案,按照积累的清单,逐条检查,能保证方案质量,虽然不能保证不犯新错误,但至少同样的错误不犯两遍。如果你什么都不写,只是口头说说,就达不到清单检查的效果。

其实清单检查不仅仅适用于设计方案,任何形式的写作都可以从中受益。秋叶在他的《写作七堂课》里也介绍了写作清单的重要性。

如何写一个好的设计方案?

不幸的家庭有各种不幸的理由,而幸福的家庭,都是相同的。好的设计方案里应该都包含下面的这几点。如果你熟悉JDK里JEP(java enhancement proposal),你会发现下面的这些关键点在JEP里也能找到,我也是受了JEP的启发。

目标

解释你们最终想要获得的成果。目标的缺失,或者模糊的目标,说明没有真正看到问题的本质,没有真正领会用户的需求。这样做的风险是解决一个根本不存在的问题,竹篮打水一场空。

动机

动机是对目标进一步的解释,特别是对现状的解释。你之所以有目标,是因为你不满意当下,在现状和目标之间有差距。这个差距是什么?为什么我们现在必须缩短这个差距?

描述

动机回答的是为什么,描述回答的是如何做。这里要解释如何一步一步的实现解决方案。一个准确完成的描述会告诉读者你问题的复杂度。

风险

你的方案可能无法考虑到所有的限制因素。就像分布式系统里的CAP理论一样,网线拔掉的时候,是各自为政,还是坐等网线插好。解释方案的限制因素,打好预防针,防止惊吓。

测试计划

如果知道怎么测,那么表明你知道成功是什么样子。相反,如果你不知道怎么测,表明你没有想清楚你究竟要的是什么。

替换方案

上面解释的都是被选中的方案。不要小瞧那些被砍掉的方案。写下那些没有被采纳的,可以证明你们想的足够全面,也可以解释你们是如何做决定的。所谓的决策,归根揭底,就是做取舍的方式。

结语

新冠疫情改变了我们工作的方式,越来越多的远程工作,去中心化的办公室,让人们很难一直保持同步,对于那些队员分布在不同时区的团队,更是雪上加霜。写下来你们的设计方案,保证大家朝着同一个方向前进,比以往任何时刻都更重要。你从这篇文章里学到了什么?像以往一样,欢迎联系我。

文章更新版本 放下我执,从此没有蠢问题

在做绩效评估的时候,一个队员说他有件难事,是问问题,他害怕别人嫌弃他的问题蠢。结果,分给他的任务,有时候效率慢,有时候走错了方向。我问他为什么害怕问问题?他说缺乏自信,害怕自己的蠢问题耽误别人的时间。我又问他什么问题是蠢问题?他说蠢问题,就是答案在别人看来很明显的问题。听完他的回答,我也陷入了沉思,到底什么样的问题是蠢问题?

当一个问题被问了第二遍,并且提问的人在问第一遍的时候已经表示明白了,这时候,我会觉得这个被问了两次的问题,是一个蠢问题。为什么这么说呢?因为我想传递两个信息给我的队员,一是鼓励他问问题,二是提醒他没懂千万别说懂了。

任何问题,如果是第一次问,就不是蠢问题。这样就会给他吃下一颗定心丸,让他对所有好奇的事情,都可以肆无忌惮的发问,不管这个问题的答案有多明显。更何况,如果回答问题的人,拿的是高额的工资,答案对他来说本来就应该很明显。之所以要鼓励他问问题,是我察觉到,这个队员在成长的过程中,大概遇到了一些对他打击比较大的事情,可能有人给他说过伤心的话,“这么简单的问题你都问,你为什么没有自己搞明白呢?”。这么残忍的话,肯定给他留下了心理阴影,导致他对自己缺乏自信。

问题问了,别人也解答了,这时候一定要真正懂了的时候才说懂,千万不能迫于压力说自己懂了。有的时候,特别是当着很多人的面提问题的时候,旁边的人都表示听懂了,而就自己没有懂,是不是我傻?!这时候你可能会迫于压力,说自己也懂了。结果你并没有懂,当你再问的时候,肯定会引起对方的反感。遇到这种情况,我一般会有两个策略。首先,我会追问一下,说自己没有听懂,你能不能再讲一遍。如果你追问,其实这时候压力不在你身上,而是在回答者的身上,因为他会想是不是讲的不清楚,大部分人都享受做老师回答问题的感觉,所以会重新组织自己的语言,给你再讲一遍。其次,如果再讲一遍还有没有懂,并且感觉到浪费大家的时间了,我会说,“对不起,实在没有懂,我想私下再想一想,如果不懂我再来找你”。这样一来,给自己留了后路,当我真正再来找的时候,也不会显得我缺乏对回答者的尊重。

什么是蠢问题?根据场景,所面对的人,以及我们想传递的信息,大家可能会有不同的答案,欢迎大家写信或留言告诉我。

为了完成同一个目标,团队需要不同职能的人合作。干大数据这一行,我就拿大数据团队来说,我们有个团队,它的任务是找到客户网站里最应该被修复的Javascript错误。团队里有产品、项目、研发经理,前后端、数据、机器学习、质量控制工程师,设计师。有的时候,我觉得这很奇妙,都说隔行如隔山,这么多不同背景的人竟然能拢在一起做一件有意义的事情。奇妙之外,也有挑战,特别是交流受阻的时候,毕竟大家受的教育,擅长的领域都不一样。跨职能团队能高效合作,最关键的就是说别人能听懂的话。

什么人会说别人听不懂的话

有的人不是故意让别人听不懂,只是他们没意识到,沟通的好必须要说的人说的明白,听的人听得进去,少一样都不行。这些人通常都特别认真,你给他说听不懂,他会重新给你解释。

还有的人是懒,懒的解释,他们觉得解释等于浪费时间,应该有专人做培训的事。我团队里就有这样的人,他给新来的产品经理介绍现有功能。解释过后,别人还是不懂,他就觉得浪费时间了。产品经理应该找其他的同事搞明白之后再来找他。

再有就是不懂装懂的人。他们生怕被发现不懂,就用华丽的辞藻,缥缈的概念给自己打掩护。话绕老绕去,就是不往关键的地方说。我之前一个同学本来邀请大家去参观他家的大别墅,可去的路上给我们饶了几十个弯,说是离家远,等真正看到他的大别墅的时候,发现根本就是平房几间。

最后一种,就是骄傲的人,说别人听不懂的话,是为了炫耀自己懂的东西很深奥,听不懂是因为太弱,这样他会感到一种把别人比下去的优越感。

为什么要说别人能听懂的话?

说别人能听懂的话,表示对别人的尊重。只有互相尊重,才能营造信任的氛围。外地人和你聊天,用你的家乡话问候你,说明别人在乎你,对你做好了功课。你有了被人重视的感觉。接下来就会觉得这个人是安全的,你可以信任他。如果一个团队里, 大家互相不尊重,觉得对方做的东西很低级,那这是一个互相鄙视的团队,一个缺乏信任的团队。如果产品经理,不想着把客户的需求解释清楚,觉得工程师是一伙骄傲自大的家伙,只会沉浸在代码里,那就不要期待着工程师能做出来符合需求的东西。反过来,如果一个工程师,觉得产品经理就嘴上厉害,动不了真刀真枪,就不乐意把代码关联到业务上,就不要期待着产品经理能带来有用的客户反馈。

说别人能听懂的话,有利于提升工作效率。有些话是能推动项目进展必要的话,有些话是无用话。像在沃顿商学院的《运营管理导论》中介绍的那样,提升效率,就是减少浪费。在生产产品的时候,工人们在工位上的移动,都是浪费,因为他们在移动的时候,是没有产出的。不清晰的话,无用的话,浪费的不仅是说话的那几分钟,它还会有放大效应。因为讲的不清楚,就给团队带来不确定性。人们会它把不确定性当成一种威胁,会牵扯更多人,更多的时间去消除这些不确定性。如果这种不确定性,是真实存在的,比如不知道什么方案能解决用户的痛点,那么需要迭代把它们变得清晰。但如果这种不确定性,是因为工程师对一个项目经理说要用一种非常纯粹的函数式编程方式把错误给Log下来,那么这种不确定性,就是人为制造的不必要的恐慌。

如何说别人能听懂的话?

说别人能听懂的话,要了解别人擅长的领域,倾听别人的需求,提升自我的表达能力。

首先了解对方擅长的领域,熟悉别人圈子里的话。我转行做了研发经理的时候,发现和产品经理的对话更多了,在团队过渡期的时候,产品经理可能都不到位,比如说离职了,这时候自己也得学会扮演产品经理的角色。作为研发经理,你对产品经理知多少?我找到一种了解别人的框架,总结下来就是:在达成同一目标的时候,你们各自的专注点是什么?你们各自的贡献是什么?搞明白别人的贡献,你就找到了别人擅长的领域。产品经理擅长的领域是解释为什么我们要做这个项目,为什么它能满足客户的需求。在这个领域里,他们的日常语言主要围绕在客户,需求,痛点,项目的动机上。明白了这些后,我慢慢的学会了他们圈子里的话。

其次是倾听,搞明白别人的疑惑。当一个人需要解释的时候,那个人本身就处于弱势地位。他可能怀疑,自己的能力才足导致听不明白。如果你火上浇油,又给人解释了一通不相关的东西,只会让人更加迷惑,更加怀疑自己的能力。让别人充分的表达出他们的需求,他们的目的,他们认为最重要的东西,他们所期待的细节的数量。这让你不仅显示出你对别人的尊重,而且能让你有的放矢,增加沟通的有效性,减少无用话。

对别人做足了功课,传递了你的尊重,明白别人的需求之后,接下来就看你能不能把你擅长的东西,用简答易懂的话说出来,最简单的话,莫过于现实生活中大家都在经历的事情。比如说你在优化缓存,缓存有什么用呢?应用到生活中。缓存就像一个电冰箱,与其每次跑到超市买东西,你把超市的东西存在冰箱里,每次用的时候,去冰箱里找就好了。生活能手,会把最常用的东西放到冰箱里,大部分时间都能在冰箱里找到想要的。这是因为学透了,可以关联类比了,可以把知识从一个专业领域,翻译到一个大家都能听懂的生活领域。我给大家一个挑战,看你能不能用大白话讲清楚乘法的交换律,为什么甲乘以乙等于乙乘以甲?

结语

说别人能听懂的话。往小里说,能展示你对知识掌握的熟练程度;往大里说,能代表你是一个什么样的人,它能彰显你的谦虚,对别人的尊重,对别人感受的照顾。上面说了这么多,对你最有用的东西是什么呢?

0%