三思而后言
文章来源: 狗的哲学2020-07-29 20:29:49

下午接到组长电话, 以为他要给我派新活,没想到他第一句话就是:“Thanks a million!”

我楞了一下, 为什么要用这么夸张的语言来谢我?我在工作场合, 从来没对任何人用过这句话。

“你刚才的报告棒极了!把活交给你, 我放心!”

其实这个报告,本应该是另外一个部门来做, 因为在这一领域, 人家是专家,更何况这个问题是人家提出来的。 可这些活总是被推到我们部门,我猜测有三个原因。 一是要花时间, 各部门的预算都比较紧, 能推就推;二是报告流程需要协调很多部门, 而这刚好是我们的职责;三是要在所有部门面前做报告, 面对那么多人的提问, 尤其是首席工程师, 肯定有压力。

有个同事说很多人都害怕做这个报告,因为所有部门代表都在现场, 肯定有回答不上来的时候。我当然有压力, 但不害怕,答不上来没什么丢人的,本来我的级别就低嘛。具体技术上的问题, 由各方代表接招就行。

以前做报告, 讲到最重要的幻灯片,我会说:“现在我暂停, 以让大家阅读, 提问。”以往,首席工程师常说:“好了, 我没问题, 继续!”

可今天, 首席工程师却说:“我不想阅读,你直接讲好了。 ”

我楞了一下, 赶紧说:“这张幻灯片里准备了很多细节, 首先让我简单总结一下。 原来是这样的。。。但是。。。因此。。。”

等我快速讲完后, 有人问了个简单的流程问题,首席工程师说:“我没有问题,其他人有没有问题或者顾虑?”

一片寂静,他说:“那好, 这份报告通过!谢谢你,Lily.  ”

我常出一口气。 这份报告我已经准备了好几周,在好多部门之间反复沟通,协调, 组长没有给出任何意见。当首席工程师说他不想阅读时, 意外的我有些着急, 还好, 我迅速阐述了要点。我理解他不想阅读, 尤其在累的时候。有时我收到很长的邮件, 也没有阅读的兴趣,所以我的工作邮件一般有3个层次:

  1. 首先用项目符号列表阐明要点。

  2. 粘贴最直接的证据截图,这样就能为对方节省寻找相关证据的时间。

  3. 但有些人想要亲自钻研,核实, 所以我把相关文件作为附件同时发送。

今天, 我很意外首席工程师满足于我的简单概括,这让我领悟到工作中的交流,不论是口头还是书面,都要分层次。 有些人没时间,没兴趣, 也没必要了解细节, 就开门见山说重点:“我认为应该。。。主要原因是。。。”

当然, 要提前做好各个层次的功课,防止有人会习惯性地连问5个为什么。话到嘴边要三思, 但一开始琢磨该说什么的时候,就要三思:“这话非说不可吗?我的逻辑有无漏洞?证据是否有力?说了对方会如何反应?我又该如何对答?”