程序员文档写作能力(三)-如何处理好微信、邮件、开会时的话术
2022/2/3 20:16:31
本文主要是介绍程序员文档写作能力(三)-如何处理好微信、邮件、开会时的话术,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
简介
前面第二篇中我详细列举了写文档的虎头、猪肚、豹尾的大三段式。这是一种手法也是一种技巧。实际上这种方法论同样适合在平日工作中在工作群里发微信、邮件来往、开会时的报告甚至一些企业内部“PK会”。特别是像领导报告时这种手法用的特别多。
而这一篇要讲述的内容比第二篇还要难,因为大三段里这种设计文档少则万字、动辄可以写到10万余字。微信、邮件、甚至开会可没有那么多文字和时间让你去这样详细描述,因此很多人就会想那这个没法写也没法用大三段式呀?
其实不然,同样适用且大三段式就是发源于这种“小通讯”、“短通讯”而来的。
留意的人看完三段式, 是可以发觉所谓的三段式是一种“构文思路”,它的内容是可以千变万化的。它的宗旨在于:
- 重要的要先说;
- 有风险要提早、越早、越快说;
- 让别人(一定要包括非技术且是“老百姓”层面的人)一上手就get到你的点;
- “如果别人不信”,喏,有文字、有数字、还有图;
- 总结一下。有没有困难?需要什么额外支持?
这是大三段式“背后”的核心思想。围绕这个思想、运用这种思想并把它应用在微信沟通、邮件、PK会议上我们不说你会无往不胜至少可以让你成为非常有信任感、说服力的人。
“虎头”在微信、邮件、开会时的应用
很多人看过一部电影叫“不要抬头”,莱昂纳多·迪卡普里奥和大表姐主演的。
里面有一段内容让我特别有感受。那就是当莱昂纳多设演的兰德尔博士和他的学生-大表姐发现一颗直径在5-10公里的天体在6个月后就要撞上地球后,国家小行星防御部门安排了他去见总统。
整部片是一部嘲讽片,它用现实手法嘲讽了各种人群以及这些人群所具有的”通用弱点“,而这一段是嘲讽“说话不接地气”的技术人员的。里面是这样表现的:
当兰德尔博士空等了一天第二天好不容易才见到了总统,总统说你只有20分钟时间。于是兰德尔博士掏出了笔记本,那上面都是各种天文学公式然后照着本子开始说:
“根据观察以及P轴的计算、并且参考了偏移植小于0.1 。。。“
总统和总统助理马上说了”对不起,我有点莫明奇妙了。。。我不知道你想表达的是什么?你想对我说一件什么事呢?”
哎,上述情景相信很多人都熟悉。事实上总统给了20分钟已经算给很多时间了,一般在大点的企业内领导让你汇报或者在会上你需要争取到一些资源时用于发言的时间如果你用了超过3分钟还没说清,好点的领导会说:下次再说吧。脾气不太好的基本上就是直接开喷的,和这个总统其实是一样的。
你不能怪总统,总统就是领导,领导一般都是业务型领导,为什么是业务型领导?业务来钱,这没办法。要想以后自己做领导你是技术出身请先从”软实力“入手然后你以后做到这种大领导位置(到时你也是业务型领导)你就可以去体量技术人员的汇报,当然到时你也会体量”总统“为什么听了第一句就不要听第二句话了。
让我们自己作为兰德尔博士事后反思一下,你想要表达的是什么?
重要的事情先说、结果前置先说、有问题先说同时请你说”人话“
兰德尔博士就是没有经过培训的技术人员的典型作风,他一开始说这么多无非想告诉”你“,他的数据是对的、结论是经过权威的、计算是无误的、公式是公认的。
而这个事情的结果是什么”一个直径5-10公里的天体100%机率会在6个月后击中地球“。
那么这件事的影响面是”全人类+地球物种90%以上会在那一刻被毁灭“。
这些才是“重要信息“,为什么这些信息不直接就说出来呢?这就是”虎头“啊,先声夺人抓住听众的第一感觉、吸引听众继续听下去。
大家放在工作中想一下,经常会有这样的事发生。生产发生一些事故,不大,都是小问题。而领导很关心于是就会经常在工作群里问:
”哎,这件事怎么回事?“
90%的人选择不回答,技术特别好的那个人回答是这样的”没有使用对象池、finally块里没有关闭、这个代码不符合XXX设计模式、业界一般使用XXXX,然后就是BLA BLA BLA一堆“,写了可能有150多字,写完字不算还附上5-6个图。
此时,你作为领导当你得到的第一回复是上述这种内容,请你想想,so what?
领导要问的是:为什么?怎么办?要多久而己!
无非就是“原因->能不能解决->需要多久解决“,有了这个回答后领导通常还会再关注的问题是”以后同样问题会不会再犯“。
好,你非旦没有回答上述这些层面,还说了一通理论,so what!!!
对不对?
接地气的回复例子
“领导,10:01-10:05APP白屏、卡顿这个问题是资源没有关闭导致了内存泄漏,从而卡死了服务器,导致请求不响应。目前外部流量已经降下来了,因此10:06就已经恢复了。此次出问题的是在用户模块的查询积分处因此此处代码打一个补丁,预计30分钟内紧急发布”。
领导继续问了“这样的问题我们系统还有吗?”
继续回答“有的,很多。因为最早的写法上没有作好代码Review、设计Review。因此在其它模块内访问外部或者不同模块间的服务互访处都有这种泄漏。这次补丁上完后我们会予工作日排期,批量查出这种不良写法然后改掉。全部改完按照优先级分三批上线,因此:需额外的三周时间“。
领导此时心里有数了,这个问题搞大了,但不能怪下面呀,因为企业内部的叠代或者是代码都是一期一期的人,早几年那一期的过错是不能放在现在这一期的人身上的,唯一需要关心的就是”以后不会再犯了,同时希望这种大规模修改不会影响太大“。于是他最多再会问一句:
”好查吗?难改吗?“
接地气的回复又来了”不难改,批量查即可。这种改动对现有业务逻辑影响无。每个开发改完自己要多测测,再交由测试去好好做回归进行双重保证即可,改完了后以后这种问题就不会再发生了“。
此时一来一去,其实是不会超过5分钟的来回交涉时间的,领导于是会在群里加一句”引起重视,作为最高优先去做,测测干净,别急,给4周吧,这个问题不要再有了,以后把这种列为代码规范“。
这件事就结束了。
来分析上述我黑色加粗的这些文字,我们可以看到此处有着明显的大三段式构文思路:
- 虎头,上手说原因,并且总结成业务领导、”普通老百姓“听得懂的话;
- 虎头,告诉领导这个问题还在继续影响业务系统呢?还是已经暂时好了但以后还会继续复现;
- 猪肚,此处因为是短信、微信、甚至邮件或者”作战会议上“,你可以表达的内容不能也不允许太多,因此浓缩自己的文字、去除细节、什么finally块什么try catch close统统舍去,但是又要说清是什么问题引起的;
- 豹尾,响应着领导在发生这种事的心里“以后还会不会再有”。直接“重新点回虎头”,告诉他会有,一直以来团队在这块知识点上疏忽了。然后总结一下并且提出“我需要额外三周,同时需要测试配合,这件事测试工作量不比开发小的,因为全改因此要走全回归”才能保证万无一失;
看,典型的标准的大三段式构文,只是它难在因为是“短通讯”,因此你要高度浓缩、压缩你的文字。
这块非常有难度,难在什么地方呢?
短通讯中文字的提练
推敲的故事,大家初中或者是高中语文都学过:
唐朝的贾岛是著名的苦吟派诗人。苦吟派是为了一句诗或是诗中的一个词,不惜耗费心血,花费工夫。
贾岛初赴举,在京师.一日于驴上得句云:“鸟宿池边树,僧敲月下门.”又欲“推”字,炼之未定,于驴上吟哦,引手作推敲之势,观者讶之.时韩退之权京兆尹,车骑方出,岛不觉得止第三节,尚为手势未已.俄为左右拥止尹前.岛具对所得诗句,“推”字与“敲”字未定,神游象外,不知回避.退之立马久之,谓岛曰:“‘敲’字佳.”遂并辔而归,共论诗道,留连累日,因与岛为布衣之交。
有时一个字是可以代表一句话的。你要浓缩文字提练文字,是需要作到以下几点的:
- 对这件事的本质,你已经理解到非常透彻,这是技术人员的本职工作;
- 了解了本质后,把技术语言按照“技术是用来普惠大众的”这种思路翻译成“人能听懂的话”;
- 由于是短通讯,因此高度浓缩你原本“冗长”的文字;
以上第2点要求技术人员把自己想成“用户”那就是业务型领导、业务型人员,放下所谓的“架子”,心态要非常平,因为技术就是服务于大众的。
以上第3点,嘿嘿,这边就是我说的最有难度的地方了。一点不夸张的告诉大家,我真的用了近7年时间去重读了论语、背了400多首唐诗、宋词、元曲。并且对每一首诗讲点什么、后人用白话的点评都去看了。当然,我承认本人资质愚钝,一般人用2-3年就可以达到我需要花费7年的时间,只是大多数人没有“领悟”到这一层而己,一旦点透即“拨开云雾见天日”了。
你们应该可以看到,为什么我的博文很多人说留有“古风”,甚至还有人说“我是剑客“?那正是因为我在文字中经常各位看的人可以发觉会有用”亦。。。所云。。。然。。。不谓。。。不为。。。大相径庭。。。“甚至标点符号都需要在事后讲究。
因为有了上述我说的”放下架子,态度端正“后,因此我才能意识到需要这么去提练文字,那么一开始是不可能也不存在说:我意识到了我的行为就会马上发生改变,这不现实的,著名的10,000小时大脑训练论是绝对的真理,因此就是逼着自己去看、去读、去补习这方面的内容。
你会发觉在一开始的一段时间,你回复、发言特别慢、特别累。慢慢的,你会发觉,你的回复、发言会越来越快,甚至达到了大脑里碰到类似的这种回复是毫秒级的响应。
这就是持续的训练最终变成了肌肉反应的的客观定律。
看看外交部发言,我们的女发言人反应快吧?外国记者故意挑事,不需要多于1秒钟然后我们的发言人怼上一句“I can't breath",怼到全场暴笑、怼到那个外国记者无地自容。
这是经过训练的。普通人没人提醒、没人点醒是不知道的。因此我在这边点醒各位,这不是天赋,而一种训练方式、一种肌肉反应,完全可以靠后天通过重视,关键还是需要重视,是完全可以自我训练得出来的。
短通讯中忌讳的点
回到最开始出了生产事故那段沟通中去,“不接地气”的工程师的回复中我有提到过,说了一大段后连续放了几张图。
这个绝对是大忌。
不要以为猪肚不就是为了“图个丰富”吗?
嘿嘿嘿。。。各位静下心来仔细想一下请(仔细想一下请这种习惯请你戒除而使用:请仔细想一下,要不然你永远无法写好“文档”、说好话),图是用来做什么的?
我告诉大家,连续的放图这种至少在前面还加了有一段BLA,而实际太多太多情况下,领导在群里问,然后有人什么都不说,直接给你上个5-6个图的。是不是?是也不是?(此处我在偷笑)。
哎呀。。。这直接放图什么都不说,你要说明什么呢?图片代表什么呢?而且还放的是代码截图、监控的细节截图。。。你让“老百姓”们怎么懂呢?
你要说什么那就说就是了么,放什么图呢?
不是说不要放图,图很重要,一图胜千言!!
图片的正确用法是什么
来看一个图片用的好的例子:
- 用虎头控制在15个字内上手把问题说清;
- 用30个字控制你的猪肚,然后当在猪肚内需要证明你的论点时来上一句:如下图,此时你可以贴上一个图;
- 此时倘若你有进一步的图例来证明或者“深挖”问题。那么请你再来一句“进一步探索后原来此处也有问题”,那么就请你再加上一句:如下图,再贴上第二张图;
这事就这么搞定了。
这是图的正确用法!
发语音
这个已经不需要我多说了,太多软技巧培训里已经说过了。微信的主要用处就是“短通讯”,你连着发了3个语音。一是不利于留档存证、二是别人有可能正在开会根本不可能去听你发了什么、三是文字的感觉是直观感受便于第一时间掌握你要表达的内容同时对于“观看者”可以有一种“俯览全局”的感觉,他不仅仅看到你发的还能同时看到其它相关的信息(这是符合现代人大脑依靠眼睛收信信息来同时处理、理解事情的“并行处理能力”的一种习惯,大脑可比CPU的并行处理能力强太多了),语音给人的感觉就是“单线程、独占式”非常不利于工作信息的传递特别是要紧信息的沟通。
这就是微信群中忌发语音的root cause。
说到这边我也给大家提个建议,发微信时不要上手给对方来一句“你有空吗”,或者更吓人的是“我有一件事要和你说一下,你有空吗”。
碰到我会直接回复“没空”。
你有事?有事你就直接说呀。。。不是吗?呵呵呵!这个梗也很好笑同样也属于没有经过专业的软技能训练过的人士们会这么用微信。
狂刷屏
一份邮件来回3次,如果此时你CC的是你的leader,或者大领导,他就会觉得烦。你们有时间这样来来回回,又不是在异地而是在同一个办公室里,为什么不能当面快速沟通一下呢?
同样的,在微信群里如果你没有掌握好短通讯里的“猪肚”的浓缩式写法,就会连续发上4-5条微信语句。这种就叫“刷屏”。
刷屏一个是干扰了大众的视线、其次就是一件事如果你不能一句话说清或者是带着因为。。。所以。。。因此。。。结果而是无结构化的连续3-5段甚至有人10个字一段话刷上个10几句,这种就是干扰视线,在别人看来就是“你想清楚一次性发完不就好了吗?”。
是不是这种感觉呢?是不是碰到过这种情形呢?要改进吗?
BLA技术细节
短通讯、邮件、开PK会,注重的就是:
结果/结论、处理好了吗、需要多久、需要什么帮助。
BLA细节不是说没必要存在,BLA细节这种是属于一个技术人员的本职工作。要BLA,你应该把BLA BLA BLA,你500,5,000个BLA到你的设计文档中去、BLA到你的自我POC、实验中去,这个才是水平。但是在短通讯里BLA技术细节对事物的推进是没有任何进展的。
首先我们说过了,领导一般是业务型领导。开会时的受众绝大部分是“普通百姓”。因此你要把这些BLA的东西转换成它最终会演变成的结果或者是Options来让大众可以“理解”。
这种手法,我们又把它称为“善意的掩藏一些细节”或者说了更好听一点叫“突现出问题的本质不要去用过程化的语言干扰决策者的视线”。
大家想一下,在上述这种生产事故沟通过程中,你说什么设计模式、什么数据库版本、什么finally?你想表达的本意、本质是什么?
不就是:没有遵循规范、没有好的设计和代码Review导致了团队copy代码不动脑最终在某个点暴露出了问题这件事吗?
因此我们要“突现事务的本质”,说白了点就是“前人不注意、技术管理失控、无Review制度“导致了最终必然结果的发生。
我建议各位去看一部片叫”杰伊比姆“,同时去看一部纪录片(也可能这部纪录片已经找不到了)或者是一本书叫”《狮城舌战》的决赛实录(视频+文字)“。
无论是电影还是书里,在双方辩论时,你有15分钟时间,而你要辩论的主题竟然是一个存在了上千年的历史文化问题,此时反方会BLA一堆细节。正方如果被”带入到了这些无谓的细节中“去后会陷于永远没有结论的”互相BLA“,这种手法其实会有聪明的人故意施展的,这就叫“搅混水”,“放烟雾弹”,反正就是让你不舒服、就是不让你Win。
因此无论是法庭辩论还是会场PK,善意的掩盖掉你的BLA。要BLA,技术团队内部去BLA,BLA了多了有助于解决方案更完善。而在这种”结论性、或者引导法官作结论“型问题时:
- 自己不BLA,多说结论避免别人”用你的BLA然后来反BLA你“;
- 不要陷于别人的BLA,善于抓住BLA的本质,直接以结论一句话否定对方的BLA;
比如说狮城舌战里我们经常看到一些反方”JP、SG、TW选手“会举一些所谓的”反例“故事挑事,而中方选手抓住了别人的BLA中的一些细节直接就回怼了一句话”你说的这些以及你的感受反证了你不了解这件事物的本质,皮之不存毛将焉附“!或者是“你的这种说活是在偷换话题,我抗议”
这种手法属于“一票否决”,“一句否定”。
在坐的有裁判、有领导、有大领导。不要以为领导真的不懂技术,你以为一个万人公司级别的抬头带“O”的人都很蠢?嘿嘿,我告诉你们,这些人都是综合型人材,都懂的。
谁在强词夺理、谁在“转移视线”、谁在混搅视听,大多领导一句话都能听懂和看懂的!
忌把网络用语、火星语、无厘头式的“用词手法”带入到工作微信、短信、邮件和日常开会沟通中去
这一块也是绝大部分人缺少专业、职业的训练导致的软实力上的“缺点/弱点”。
90年代受“无厘头电影中相关句式”影响太多,如我刚才在上文中出现过一次红色加粗字体故意让大家自己体会一下同一个含义两种“句式”带来的感观上的区别:
还有人喜欢用这种句式“这样做就没问题了应该,这个问题三周就解决了应该可以”。
仔细看这两句句式:
- 什么叫没问题了应该?为什么不好好说成“应该没问题了”;
- 什么叫“应该可以”结尾?有话不能好好说吗?”这个问题三周就可以解决了“读着多顺口?
这不是说:why so serious的一个问题,同志们。
这更不只是态度问题,如果只是态度问题领导或者大都数人是不会正面或者背地喷你的,这是什么问题大家有没有深层次的去想过?
这叫“逻辑思维出了问题”,这个很严重啊!搞技术的人讲究的就是“思路清晰”,你们看,技术论文、好的博客、书藉都是贯穿着“因为。。。所以。。。然后。。。因此。。。结论”,我们称这种叫“闭环”式的结构的,虎头、猪肚、豹尾也是讲究的“闭环”。
你倒好,好好的文字描述来一个“开包原则”,哈哈哈哈,这边我又要说了”诺兰式的开放式结局“。
如果你是在亲朋好友间沟通可以这样沟通。但我也不赞成这种沟通手法,如果你是在撩MM时用这种手法那没人管你。
但是工作、正事是严格讲究”逻辑思维“的。
碰到好点的领导会说:小张啊,你这句话不符合逻辑。
碰到严格点的领导会说:你在说得什么无厘头东西,严肃点好不好。
工作职业讲究的是”专业“,当然不排除个人创业以及一些极端情况,这不属于我们讨论范围我们这还是做的”大众化、普惠式“技能传授。
最后说一下邮件类通讯的写法
邮件也同样属于短通讯,它可以比微信稍稍富丰和内容多一点。但也不易于太多。
邮件更正式,但是邮件的来回次数控制在<3次,如果这份邮件的来回有多于2次以上的可能存在的话可以在最后一次回来的邮件中加上一句“希望找一个你有空的时间我们一起开一个会快速讨论一下”。这种话术。
邮件内容不宜过长,如果内容很长涉及技术细节类的,可以在邮件中附上Word、PPT、Excel文档。
一份邮件,最长的控制在200字已经了不得了。邮件中如果需要也是可以附上图片来进行说明的,同样参照使用微信通讯手法中的“先说问题、重要的事”+“如下图”这种手法来表述。
邮件一定记得要有这样的基本内容存在,否则这不是一份合格的邮件,因为邮件和微信都代表着一个人的“态度”和“给别人的第一印象”。
因此,邮件内要有:
- 标题;
- 主送人,旁观人-CC(按照职级大小);
- 尊称,如果你和这个人关系一般可以用Dear John,如果你不太认识或者只是知道有这个人可以用Hi John。用刘德华新年祝福歌曲中一段话叫“礼多人不怪”(每次唱到这一句我喜欢唱成人多礼不怪,哈哈,竟然很少有人听得出来我这句唱错在哪);
- 正文内容;
- 落款,落款一定要有如:Your Sincerely或者Best Regards By 某某某;
- 最后记得,千万记得要有你的签名如:XXXX部某某某,手机:130000000;
把任何工作中的微信、邮件当作是一次交付来对待,这是态度。
有了这个态度,剩下的就是依靠你自身的修练了。
语文。。。。。。重要不?
文言文是瞎教你学吗?
大家回想一下,每一门基础教育从小学到大学,都有其重要意义。
因此,学无止镜,结束今天的篇章。
这篇关于程序员文档写作能力(三)-如何处理好微信、邮件、开会时的话术的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-11-23Springboot应用的多环境打包入门
- 2024-11-23Springboot应用的生产发布入门教程
- 2024-11-23Python编程入门指南
- 2024-11-23Java创业入门:从零开始的编程之旅
- 2024-11-23Java创业入门:新手必读的Java编程与创业指南
- 2024-11-23Java对接阿里云智能语音服务入门详解
- 2024-11-23Java对接阿里云智能语音服务入门教程
- 2024-11-23JAVA对接阿里云智能语音服务入门教程
- 2024-11-23Java副业入门:初学者的简单教程
- 2024-11-23JAVA副业入门:初学者的实战指南