摘录笔记——2024年4月24日

    有感而发,旁边一后端老哥最近跟他leader申请加人,否则项目存在延迟交付的风险。申请资源的整个过程十分曲折,我在旁听的时候都替他着急(哎==)。就,刚好看到大佬写的这篇文章,有些观点对自身还是挺有帮助的,现摘抄部分内容当做笔记吧~共勉。

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

前言

为什么要把问题讲清楚

Boss突然来一个夺命电话,追问线上出现的故障的原因?以第三方视角,大概有以下几种情况:

  • 懵了(半天没声音):线上什么时候出问题了?大脑一片空白;
  • 支支吾吾:也收到了线上问题告警,但还没来得及看,不知道说什么;
  • 口若悬河:有初步的想法,直奔细节,Boss时不时打断你,以确认你在说什么;
  • 条理清晰:有分析,有重点,有解决方案,Boss 频频点头(嗯,...)。

     显然更看好最后一种。工作中的任何一次对话都是一次机会,沟通本身传达的核心信息无非是"态度+能力",态度方面你是不是有意愿做,能力方面你是不是 hold 住。通过把“问题”讲清楚,把握每次与他人建立连接的机会,传递自身的价值,也让路越走越宽

一、想清楚

以5W2H 模型,说明如何想清楚"问题"。

总体而言,上图中Why、What、How 几部分最为重要。

1.1 为什么讲(Why)

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2 讲什么(What)

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

  反映的问题要切中要点,避免别人听不懂你在说什么,否则那就是完全是在浪费时间。切中要点的方式如下:

1.2.2 先分析下什么是要点

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

1.2.3 如何做到对齐要点

这里通常有两种做法是:

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

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

   在进行自下而上分析要点时,有两个注意事项,不然受众不会投入关注度。

  • 突出重要性

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

  • 问题可量化

    上面的重要性提供了定性描述,受众会进一步问,这样说的依据是什么(有没有事实 &数据,潜台词是你是不是在为了个人利益而瞎说)。可从自身/纵向/横向三个角度:自身谈分布情况(上面的例子中可描述不同级别的故障个数;不同原因的百分比);纵向谈趋势,如稳定性事件上涨环比;横向看对比,相较其他团队是否倒数。

注:自下而上的做法一般是用于汇报一些可能老板没有发现的问题。

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

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

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

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

1.2.4 再说如何切中要点

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

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

1.3 如何讲

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

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

   对应到上文稳定性问题的例子,可以这样说:近三个月线上故障同比上涨了20%(背景),而导致故障的主要原因是变更(占50%)(冲突),我们该如何解决线上变更导致故障的问题(疑问),我认为.....(答案)。接下来就是如何把"我认为"部分的内容讲明白。

二、讲明白

 既然决定要去讲,就要保证受众能听懂。

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

   在具体实操方面,该如何做到“结论先行”?需确保以下两个要点:

2.1.1 层次性

  每个层级的结论都是一个中心思想,可以继续拆分,直到最下面一层(事实/数据)。类似于系统的嵌套结构,系统-子系统,每一层都可以向下延展,直到最基础的现象。需要注意,搭建出的结论金字塔结构一定是可以做到在不同层级间的自由切换,不然基本是逻辑不自洽,一个重要的衡量标准是能不能回答出任一个细节问题。

2.1.2 说三点

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

    就上文的稳定性问题而言,给出如下样例: 近三个月线上出现的多起稳定性事件主要是由于流程不规范及稳定性意识不足导致,可从以下三个方面进行治理:

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

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

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

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

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

2.2.1 对纵向关系,做到以上统下

    纵向问题一般是论点(中心思想)和论据(支撑点)对不上,诸如论据不充分(缺失关键论据)、论据不相干(没有也能得出结论)、甚至论据矛盾(支持相反的结论)等情况,这种只能通过逻辑训练逐步改善。但是就基本面而言,至少需要保证问题(论点)和答案(论据)的一一对应。比如你需要进行一次线上内存 OOM 事件处理方案及规划的分享,如果只是分享了处理方案,而没有提规划,听的同学也会一脸懵。

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

    归纳法为什么不能进行论证的理由很明显,它无法给出建设性的指导意见,也不能形成有效的结论。所以在进行论证时应采用演绎法。

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

  • 大前提-小前提-结论

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

  • 问题-原因-解决方案

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

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

2.2.3 如何让受众记住你的观点

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

  • 先讲重要的事

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

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

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

  • 包装你的观点

一句话形象化表达你要做什么,价值是什么。以上述的稳定性案例为例:通过线上变更规范化风险巡检事项处理保障平台稳定性,达到 SLA目标(短期价值),为平台能力标准化与后期商业化奠定基石(长期价值)。

三、要资源

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

     如果Boss已经完全支持你的方案,那么重点来了,你怎样传达出自己是可以(顺利)完成项目的?没错,通过要资源。

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

  • 关于交付质量:哪些环节的资源可能存在公用,给不到位就无法达到质量预期;
  • 关于交付节点:哪些资源一定要给到才能确保推动进度,提前识别风险,避免项目延期

     一般是根据结果去推动,大胆要资源;如果由于外部不可抗因素导致最终无法交付,也要通过项目管理表说明资源的使用情况,证明资源没有被浪费。

参考文章:

https://mp.weixin.qq.com/s/XYiasfWaJ6rHNSch-ANBbA

  • 22
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值