王辉的博客

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

和我一起面试的同事提醒我,说有时候我提的问题,聪明的应聘者可以看出来答案。他建议我多问开放式问题。让我们拿这篇文章来研究面试官如何掌握开放式提问。

什么是开放式提问

所谓开放式提问,就是不同的回答者会给出和自身经历密切相关的答案。举例说,您曾经犯过的一个错误是什么?人犯的错误千姿百态。相反,封闭式问题的答案,选项有限。打疫苗的时候,会问最近有没有发烧,有没有高血压,有没有过敏史,有和没有选一个。

为什么要开放式提问

封闭式问题获取信息高效,可为什么面试官却青睐开放式提问?因为它不仅可以帮助面试官全面衡量应聘者的能力,而且让面试任务变得更加有趣一些。

开放式提问的最大威力是挖掘回答者的沟通能力。当一个开放式问题抛出去的时候,回答者大脑里,面对非常多的可能性。如何筛选有用的信息,组织信息的传递结构,让对方准确无误的明白回答,是回答者面临的一个大挑战。不信?可以试试这个问题,请讲讲你曾经做过的一个艰难的决定。

开放式提问还可以看出回答者的思想高度。有的人能从大局观着手,看清外部内部形势,从多个角度,多个层面,多个时间维度给你将清楚一个问题。而有的人,直入事情的某个细枝末节,让你迷失在他的世界里。

开放式提问可以让交流更加人性化。在一个疯狂生长的组织里,面试官每周要面对很多应聘者,如果问题都是封闭式的,面试官就成了一个复读机。开放式问题带来的是五彩斑斓的个性故事,给枯燥的面试任务增添了不少调味剂。

如何学会开放式提问

要学会开放式提问,一是问题不能过于宽泛,二是不要给出太多提示。

学会开放式提问的第一步是确定要评估的能力。开放式问题不是无边无际的问题,讨论的不是无穷无尽的宇宙,而是要有一定的引导性。这个引导性就是你看重什么?如果你想知道应聘者的团队合作能力,就问设计方案是怎么定下来的?如果看主观能动性,就问自主解决过什么问题?

定了方向,可以让问题有的放矢。然而,给出的信息也不能太多,面试者一定要培养耐心和好奇心。

我经常陷入一种半开放式提问的困境中。

起初提问是开放式的。比如说,这个项目成功的关键在哪里?有些回答者想了很久也不说话,有的给了我预想外的答案。我常常忍不住提示回答者从客户反馈上,项目管理的角度上想一想。而这些提示,不仅限制了对方的思考范围,而且传递了我想要的答案。

所以,要想开放,就要有耐心。对方需要时间去思考,就给他时间。要着急的不应该是面试官,而是应聘者,这是考验大家忍受空白的能力。其次就是要有真挚的好奇心。不要把自己的答案,强加到对方身上。也许你的答案很不错,但是别人可能有更好的想法。如果答案确实不如意,你想深挖一些,与其给提示,不如问应聘者有没有要补充的。

你呢,有什么学会开放式提问的妙招吗?

技术管理者的成长中,有两个因素的比例会发生变化:技术和管理。起初,技术占主导地位,比如 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理论一样,网线拔掉的时候,是各自为政,还是坐等网线插好。解释方案的限制因素,打好预防针,防止惊吓。

测试计划

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

替换方案

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

结语

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

文章更新版本 包容的回答者

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

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

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

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

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

0%