“打工人”的自我修养 - 如何在 30 秒内把“问题”讲清楚

为什么要把问题讲清楚

假设你正在吃炒面，突然收到 Boss 打过来的电话，问你线上出现的故障是怎么回事，这时的你会是什么状态？以第三方视角，大概有以下几种情况：

• 你懵了(半天没声音)：线上什么时候出问题了？大脑一片空白，我是谁，我在哪？

• 你支支吾吾：也收到到了线上问题告警，但还没来得及看，不知道说什么

• 你口若悬河：有初步的想法，直奔细节，Boss 时不时打断你，以确认你在说什么

• 你条理清晰：有分析，有重点，有解决方案，Boss 频频点头(嗯，...)

假如你是 Boss，你会喜欢哪种情况，我相信没人会质疑(如果你质疑了，那本文不适合您)。假如你觉得吃饭更重要，那本文也不适合您。

既然已经达成一致(都喜欢他/她条理清晰)，那我们继续。

工作中的任何一次对话都是一次机会，沟通本身传达的核心信息无非是"态度+能力"，态度方面你是不是有意愿做，能力方面你是不是 hold 住。

通过把"问题"讲清楚，把握每次与他人建立连接的机会，传递你的价值，也让路越走越宽。

本文如何布局

对有迫切意愿把"问题"讲清楚的同学，建议按本文走完"想清楚"-"讲明白"-"要资源"这个流程。

注：为什么是这个流程？是按讲前->讲中->讲后的逻辑，各环节再挑出最重要的点形成流程。

• 想清楚

你要做什么(传递什么价值)，如何说受众才能更容易接受，你期望的结果是什么(拿到资源)。

注：《孙子兵法》中提到“先胜后战”的思想，白话意思是“先想清楚，能胜才打”，对应到本文，即是"只有把问题想清楚才能讲清楚"。

• 讲明白

决定要去讲，该如何讲怎样才能讲明白。如果讲了半天，对方表示没听懂，双方都尴尬。

• 要资源

在规划节点前完成项目，需要哪些支持。其一用于划清事项边界，其二用于确保项目交付。

想清楚

准备工作(不打无准备的仗)，第一步是把问题想清楚

祭出 5W2H 模型，说明如何想清楚"问题"。

而其中，又以 Why、What、How 最为重要(个人认为)，我们展开来说。

为什么讲(Why)

语言沟通可用于不同目的，就工作而言，本题可拆解为以下三个问题：

传递了什么价值(受众为何会买账)

听众只会从自己的视角判断你的话对他是不是有用，否则他不会对你的话感兴趣，也不会再有下文，所以首先需要回答的是你的话于他而言传递了什么价值。一般有以下两类：

1）收益是什么(做这件事的好处)，投入多少资源，对现状的改善有多大(ROI)；

2）风险是什么(不做这件事的坏处)，需明确影响面与发生的概率，损失有多大；

为什么是你(创新点在哪)

如果受众对上述的价值认可，那么接下来的问题是"为什么是你"(而不是别人去做这件事)，这时就是展示你专业性(能力)的时候，可从两个方面入手：

1）对问题的理解程度，表明你在这件事情上是不可替代的，没有你可能会走偏；

2）自身的成功经验，表明你完全有能力做这件事，让对方放心(人们倾向于通过一个人的过去去预判一个人的未来)。

核心诉求是什么(你需要什么资源)

价值讲清楚了，你做也没问题，所以你打算怎么做？当然这里不是真的问你打算怎么做，而是说有没识别到问题的边界在哪(边界定义是有效衡量一个人是不是真正可以把事情做好的重要手段)，而体现边界的直接指标即是你需要哪些资源，一般来说，资源可包括：

1）内部资源，可以投入多少人力和设备，以怎样的形式支持等等

2）外部资源，有哪些角色需要参与进来，在哪些环节参与，起到什么作用，产出是什么等等

注：上述三问在时间有限情况下可能只会到第一问(最重要)，但其他两问也要做好被问的准备

讲什么(What)

一定要有中心思想(切中要点)

反映的问题要切中要点，避免别人听不懂你在说什么，否则那就完全是在浪费时间。所以该如何切中要点？

先分析下什么是要点

要点，一定是受众最关心的点，通常情况下为当前团队优先级最高的事项(可能是亟待解决的问题，也可能是创新方案，...)，而这个事项可能是你以为的，也可能是他(/她)认为的，沟通的第一步是要对齐要点(就问题本身达成共识，否则就是鸡同鸭讲)。既然要点可能存在分歧，那么该如何对齐要点？

如何做到对齐要点

这里通常有两种做法是：

1）自下而上：看到了 A,B,C,...，然后进行分类，总结共性(抽象)，进行问题定义。

举个例子，你是一名 SRE 同学，发现最近线上故障不断，于是你去统计故障产生的原因，并对原因进行了分类(变更导致、漏测导致、需求不合理导致、代码 BUG 导致、...)，然后你抽取的共性是线上发布流程有问题，到这里问题定义就清楚了：通过对近期多起线上故障进行分析，发现故障的主要原因分别是(类型:百分比)xxx(分类)，而根本原因是流程不规范导致(抽象)。

在进行自下而上分析要点时，有两个注意事项，不然受众不会投入关注度(也基本相当于浪费时间，除了对你有些印象)

• 突出重要性

把事情往大了讲，结合事项在上下游中的位置，在战略大盘中的地位，可带来的短期与长期收益等。就稳定性的例子，可以说：稳定性问题已成为平台 SLA 的主要阻碍因素，制约了多个 xx 创新项目的按期推进，是目前团队 Top1 待解决的问题。(仅供参考)

• 问题可量化

上面的重要性提供了定性描述，受众会进一步问，这样说的依据是什么(有没有事实 &数据，潜台词是你是不是在为了个人利益而瞎说)。

可从自身/纵向/横向三个角度：自身谈分布情况(上面的例子中可描述不同级别的故障个数；不同原因的百分比)；纵向谈趋势，如稳定性事件上涨环比；横向看对比，相较其他团队是否倒数。

注：这种做法一般是用于汇报一些可能老板没有发现的问题

2）自上而下：Leader(/合作伙伴/用户/...)在多个场合明确提出

这种情况是否比较明确要点是什么？答案是不一定，因为他(/她)提出时可能是一个大致的概念，我们的任务则是找到他们真正关心的点是什么。

就上面稳定性问题的例子，如果他(/她)只看到出了稳定性问题，而不知道具体是什么问题，那么上文自下而上方法的结论也是可行的(分类 &抽象 &定量)，但如果他(/她)已经知道稳定性问题的主要来源(如变更)，那么再谈稳定性问题如何产生(主要来源)的效果几乎为负值。

这时该怎么办？这里的主要解法是角色带入，假如你在他的位置你最想听到什么，如果对方也是"理性人"(对问题进行系统化分析)，那么你们的思考路径应该是大同小异，这时可以下探一层，给出下一层的要点(如变更中哪些是开发同学导致的，哪些是产品同学导致的，......)。

再说如何切中要点

对齐要点之后，再谈你的核心解决思路(观点)是什么，解还是不解，如何解，达到的效果是什么。让受众对你的信任度进一步提升(把事情交给你的关键)。

就稳定性问题的例子，可以说：近期线上稳定性问题主要是变更导致的，我认为解决问题的核心在于提升发布流程的规范性，可通过在各环节设置强卡点(明确的准出标准)的方式解决。

对方如果有兴趣会继续展开问各环节如何设置卡点，标准如何定，由谁去执行，价值如何回收等等。

在明确讲什么后，接下去就是你打算如何讲。

如何讲(How)

这里有个常用的套路是讲故事，用于引出真正想说的内容(价值点)。

我们来看个例子(“精卫填海”)：在中国古代，有一个名叫精卫的小鸟。她为了填平东海而不断往海里投石。精卫为什么要填海呢？相传精卫本是炎帝神农氏的小女儿，她生前与大海无冤无仇，但是却不慎溺水身亡，如此与大海结下仇恨，化身为鸟终身进行填海的复仇事业。

不管这个故事有没有吸引你，它至少勾起了你的注意(为什么呢)，再看电影(只要是说故事)的套路也是这样，挖一个坑在下一个情节中填上，再挖一个坑，再填，再挖再填，直到电影结束，甚至在电影结尾时也挖个坑，为续集做准备(如“盗梦空间”结尾的陀螺一直没有停下)。

故事的标准结构是：交代背景(S) -> 制造冲突(C) -> 勾起疑问(Q) -> 给出答案(A)。

对应到“精卫填海”中的例子(更清晰的展示故事的结构)，可表示为：

对应到上文稳定性问题的例子，我们可以这样说：

近三个月线上故障同比上涨 20%(背景-S)，而导致故障的主要原因是线上变更(占 50%)(冲突-C)，我们该如何解决线上变更导致故障的问题(疑问-Q)？我认为......(答案-A)。

接下来就是如何把"我认为"部分的内容讲明白。

注：你也可以采用不同的结构来表达不同的风格，此处不再赘述。

讲明白

把“问题”讲清楚，让受众愿意支持你

结论先行(突出中心思想)

注意力是稀缺资源，我们需要在前三秒内点题，抛出结论(中心思想)。

有些同学喜欢倒叙、插叙、随机、甚至把主题隐藏在字里行间等方式，如果你是在解决问题，就事论事而言，不建议过于迂回，从信息的提炼程度来说，正常情况下，它一定是金字塔形式，也即是说你的一级结构是你直属 Leader 的二级结构，是你直属 Leader 的直属 Leader 的三级结构，所以几乎不用考虑说他(/她)听不懂你在说什么。

如果你说了一段话后，受众问你"所以呢"，那这就是典型的没有做到"结论先行"，在具体实操方面，该如何做到“结论先行”？需确保以下两个要点：

• 层次性

每个层级的结论都是一个中心思想，可以继续拆分，直到最下面一层(事实/数据)。类似于系统的嵌套结构，系统-子系统，每一层都可以向下延展，直到最基础的现象。

值得注意的是，搭建出的结论金字塔结构一定是可以做到可以在不同层级间自由切换，不然基本是逻辑不自洽，一个重要的衡量标准是能不能回答出任一个细节问题。

• 说三点

如果<=两点，八成是没有考虑清楚->完备性不足，如果>=4，八成是提炼程度不够->有冗余，所以说三点是较为合适(/稳妥)的做法。

如果结论的支撑点不是三点，可以参考下上面的论述(当然也不是绝对的)。

就上文的稳定性问题而言，给出如下样例(仅供参考)：

近三个月线上出现的多起稳定性事件主要是由于流程不规范及稳定性意识不足导致，可从以下三个方面治理：

1）提升审批同学的作用，对线上变更进行强管控(Check 变更内容/变更三板斧执行到位/...)

2）提升测试同学的作用，(通过制定测试准出标准及确保测试路径覆盖率/...以)降低漏测率

3）定期进行稳定性宣讲以提升团队成员稳定性意识，减少由于低级 BUG 导致的线上问题

做到逻辑严谨(具有说服力)

他(/她)为何会质疑你

在抛出结论后，如果对方可以立马质疑你，基本上说明你的表述逻辑有问题：要么是下层要点不足以支撑中心思想(纵向问题)，要么是论证过程没有处理好(横向问题)。

对纵向关系，做到以上统下

纵向问题一般是论点(中心思想)和论据(支撑点)对不上，诸如论据不充分(缺失关键论据)、论据不相干(没有也能得出结论)、甚至论据矛盾(支持相反的结论)等情况，这种只能通过逻辑训练逐步改善([微笑])。

但就基本面而言，至少需要保证问题(论点)和答案(论据)的一一对应。比如你需要进行一次线上内存 OOM 事件处理方案及规划的分享，如果只分享了处理方案，而没有提规划，听的同学也会一脸懵。

采用演绎法(而非归纳法)进行论证

归纳法为什么不能进行论证的理由很明显(如果你看过辩论赛，会发现无论一方辩手举什么例子，也无论举了多少例子，对方辩手总会找到反例，然后他/她就无话可说了，所以采用归纳法进行论证基本是在浪费精力和时间)，它无法给出建设性的指导意见，也不能形成有效的结论(当然这里是指一般情况->很容易被反驳)，所以我们在进行论证时应采用演绎法。

在方法层面，有标准演绎法(三段论)与一般演绎法(What-Why-How)两种类型。

• 大前提-小前提-结论

大前提一般是不成文的约定或风口，以稳定性为例，近期发生了多起线上事件，大 Boss 非常重视；小前提则是你的具体行为，比如你的发布没有经过评审；而结论就是一个操作是不是被允许，比如你的线上变更行为违反了红线，不准执行，否则后果很严重(Boss)。

注：理论上，演绎法的大前提来自于归纳法，是有可能不成立的(圣诞节的火鸡可以说明这种大前提可能是无效的)，但实操层面，"理性"人(考虑 ROI)不会质疑你的大前提(如果它已经达成共识)。

• 问题-原因-解决方案

这个套路是工作中处理与汇报工作的常用思路，其中又以原因分析最为重要，找到原因基本上问题就已经解决了一半，而原因又分直接原因和根本原因，找到根本原因从源头解决可起到事半功倍的效果，常用的根因分析工具是 5Why 法，探求问题根源。

对应到上面稳定性问题案例：

平台的稳定性 SLA 未达到，其中 50%的 Case 是线上变更导致，而线上变更问题主要是流程不规范引起，具体包括测试用例不全(、/...等，不再展开)，而测试用例不全的主要原因是测试同学编写测试用例阶段依赖于开发同学(开发同学说测什么就测什么)，不能独立开展测试，所以解决方案是通过执行测试规约方式确保测试同学可根据业务设计测试用例(确保不漏测)。

表达全面而清晰(容易记)

如何做到不遗漏

谈到不遗漏(保证全面)，其隐性的前提是你的目标是什么。就稳定性的例子，SLA 是四个九还是五个九，需要做的事可能完全不同，比如四个九的时候通过告警值班机制及时处理线上问题就行，而五个九则需要做到多活实现故障自动恢复。所以在考虑如何做到不遗漏(全面)问题前，需要明确你的目标是什么。

而要做到分析问题不遗漏，推荐的工具是 MEMC(经过无数人检验)，但在实操层面要做到“相互独立，完全穷尽”几乎是不可能的(即便是一级结构是 MEMC，二级结构也很难做到，即便是二级结构是 MEMC，三级结构很难做到，以此类推)，但是不是不需要 MEMC，当然也不是的(毕竟要做到尽可能的全面)，那应该如何做？我总结了三点：

• 一级结构分类(尽可能)做到是根源性的

所谓根源性，一定是导向目标的主要因素，有直接的因果关系。

以稳定性的例子，线上事件主要是变更(50%)导致的(假设其他原因是代码隐藏 BUG 导致)，如果一级结构中提到变更风险管控(三板斧 &变更军规)和提升代码质量(CR&代码扫描)，没人会质疑，而如果提到做好流量防护(限流降级)则会被挑战。

• 一级结构分类(尽可能)做到是相互独立的

方式一：逻辑拆分，对于一个断言，要么真、要么假，以线上变更为例，代码回归率>90% 则允许发布，否则不允许发布；

方式二：结构拆分，基本面可用内部、外部方式，以稳定性为例，外部因素主要是线上变更、不确定性流量冲击等，而内部因素主要是隐藏 BUG、资源不足等；

方式三：其他。回归拆分的目的：拆分方式是否有利于达到目标。稳定性为例，可以按角色分类(产品/测试/研发，主要职责是什么)，也可按流程拆分(变更前/变更中/变更后)，关键在于是否达到目标。

• 一级结构分类(尽可能)做到是完整的

所谓完整性，就是少了这些要素不足以支撑目标完成，而再增加一些要素，投入产出比不高。

稳定性为例，假设目标是 4 个九，而稳定性治理策略是：

1）线上变更强管控(100%三板斧) -> 变更期间需控制线上事件(如果发生)的影响面

2）做好流量防护(应对不确定性流程冲击) -> 避免由于上游业务突增流量压垮当前服务

3）确保 7*24 小时 OnCall 轮班机制 -> 有问题及时处理，避免爆炸半径扩大

检验标准：尝试去除任何一项都无法完成 4 个九的目标，而尝试增加一些项(如进行架构高可用升级)则相对 4 个九的目标有些过度用力。

注：这里仅提到了一级结构，当然不单指一级结构(也指二/三/四/...结构)，只是一级结构是根基性的，一旦一级结构有问题，其他层级的价值一般也不大。

有个问题是如果都按照 MEMC 方式是不是得出的结论都一样？答案是否定的。

其一，每个人了解的信息是不一样的，结论自然可能不一样；其二，即便是了解到相同的信息，由于切分方式不同，抽象层次不同，得出的结论也是可能不一样的。

这里的启发是如何更好地使用 MEMC 工具以达到目标，还是要多看，多想(读万卷书，行万里路)，与君共勉。

还有个问题是每次搭建 MEMC，有点耗时耗力，是否有更高效快速的方法？答案是有的。

如用于商务环境分析的 3C 框架(看市场.客户/看竞对/看自己)、用于指定营销策略的 4P 框架(产品/价格/流通/广告)、用于咨询行业的鱼骨图等。

如何让受众记住你的观点

发布会(/或其他宣传场合)上，大佬在即将结束进行总结的时候，一般都会说一句"本次分享如果总结成一个点那就是......"，可以说任何一次与他人的沟通都是在传递价值，那么该如何更好的传递你的价值？我总结了两点：

• 先讲重要的事

此时需要先回答的是你的受众是谁，同样一件事，诉求点不同，关注点自然不同。向领导汇报工作，老板关注进度是否符合预期；向客户推销产品，客户关心对他(/她)有什么好处；向同学安排任务，他/(她)关心个人成长点在哪；等等。

重点是需要通过换位(角色带入)去思考他(/她)关心什么，然后在讲三点时，考虑第一点说什么。

以向老板汇报稳定性工作为例，如果第一点是通过加强流程规范性减少变更导致的线上事件，老板会觉得问题不大，而如果第一点说通过代码扫描工具识别出现有代码中的不规范点以初步提升代码质量(减少代码隐藏 BUG)，老板估计会懵掉(和线上事件问题解决有多大关系？)，即便说提升代码质量也是降低线上稳定性问题的策略之一。

• 包装你的观点

一句话形象化表达你要做什么，价值是什么。(作者不太擅长，学习中[😊])

稳定性为例：通过线上变更规范化与风险巡检事项处理保障平台稳定性，达到 SLA4 个九的目标(短期价值)，为平台能力标准化与后期商业化奠定基石(长期价值)。

要资源

你需要 Boss 给予哪些支持

如果 Boss 已经完全支持你的方案，那么到这里重点来了，你怎样表明自己是可以(顺利)完成项目的？没错，通过要资源。

识别出为了完成项目需要哪些资源(哪些部分是你已经有的，哪些是必须求助 Boss 才能获取到的)，而需要老板支持的资源一定是用于保障交付质量和交付节点的：

关于交付节点：哪些资源一定要给到才能确保推动进度，提前识别风险，避免项目掉地上；

关于交付质量：哪些环节的资源可能存在共用，给不到位就无法达到质量预期；

往拿到结果的方向去推动，大胆要资源；如果由于外部不可抗因素导致最终无法交付，也要通过项目管理表说明资源的使用情况，证明资源没有被浪费。

以上，“打工人”的自我修养-如何在 30 秒内把“问题”讲清楚。

如果本文对您有帮助，欢迎关注并转发～

免责声明：本文言论仅代表个人观点。