如何让你的话不被别人忽略：说透厉害关系

2017-04-24 本文已影响138人文远时间

我有时会发现一个很奇怪的现象：在公司开会的时候，明明自己说的话是正确的，但大家就是没有回应。过了一会儿，另外一个人表达的观点和自己的观点几乎一样，大家就纷纷表示赞同。为什么？

当时我还百思不得其解，现在想来，可能有如下三个原因：第二个人是大家更信任的人，在第二个人说同一观点时大家已经想明白了，第二个人的表达力比我好。

前两种原因，如果我们分析下去，对于我们自己的提高可能没有益处，因此本文只关注于第三个原因。

【工作越认真，越容易犯错】

我们仍然拿黄石公和张良的故事举例：

黄石公考验张良，分为三步：让张良给他穿鞋、第一次五日之约、第二次五日之约。

假设这是工作中的一篇文档，上下游两个部门依靠这篇文档来衔接工作。下游部门的人拿到这篇文档后，他要去执行“让张良给他穿鞋”、“第一次五日之约”、“第二次五日之约”这三个步骤。到最后一个步骤“第二次五日之约”时，他发觉有两次五日之约，这是明显的重复，于是他就做出一个决定：不做第三步。

执行者又发现，“让张良给穿鞋”这一点太难做到了，因为他怕引起张良的反感，因此他想到了另外一个方法：为什么不能向张良的邻居打听一下呢？于是，执行者就这么做了。

最终执行者犯了两个错误：少考察了一个方面，使用了错误的方法而得到虚假的信息。

这两个错误必须解释一下：为什么少考察了一个方面？执行者会这样想：给我的那份文档没有告诉我要考验什么方面，它只是告诉我要做三件事而已，而我发现第二件事和第三件事明显是重复的，就把第三件事去掉了，因为我工作认真负责才会做这种纠错。

第二个错误：为什么使用了错误的方法而得到虚假的信息？执行者会这样想：我发现文档中“让张良给穿鞋”在执行时有困难，会引起张良的误解，于是换了一种方式：向邻居打听，这种方式能够得到更全面的信息，同样是因为我工作认真负责才会做这种纠错。

这么看来，执行者工作越认真，就越容易犯错，这岂不是一个悖论？问题到底出在哪里？

【错误的本质是什么】

这件事的本质是：执行者使用一种有一定自主权的方式在工作，他期望的任务描述是目标式的，而交给他的任务描述却是指令式的。

表面上看，任务描述是“黄石公考验张良，分为三步：让张良给他穿鞋、第一次五日之约、第二次五日之约”，这里边是有目标的：“考验张良”，但这个说法并没有把目标说清楚。

每个人都有天生的纠错能力，例如一个字打错了，他能根据上下文判断出这是个错字。执行者在执行三个步骤时，发现了一个“错误”，他启动了自己的纠错系统，他的知识范围就决定了他断定这肯定是个错误，就像他断定1+1=3是个错误一样，因此他没有丝毫的怀疑，当然不会去找别人确认这是否是一个错误。

看明白了错误的本质，我们该如何解决？

凭直觉我们想到一个方法：让执行者忠实地按照文档中说的步骤去做，也就是指令式的工作方式。但问题来了，执行者如果这样做事，就变成了一个按照固定程序操作的机器人，当文档中有错误的时候，就会执行错误，如果还有下游执行者，那么就会一路错下去，最后那个错误会滚成一个巨大的雪球，雪球破裂的时刻很可能是惊心动魄的！

这么看来，纠错不行，不纠错也不行，难道就没有办法了吗？

【解决办法】

其实是有办法的。错误的根源是：文档风格与执行者工作方式的不匹配。为了解决问题，我们只想到了改变执行者，结果是不可行，其实我们还可以改变文档风格，从如下几个方面改进：

一、让纵向层次拥有无须解释的关联，是因为下层给上层呈现的是结果而不是实现。

我之前的文章《一样东西能让你的表达力熠熠发光：层次感一样东西能让你的表达力熠熠发光：层次感》中，【改造的精妙之处】部分有一个核心思想——“纵向层次拥有无须解释的关联，是因为下层给上层呈现的是结果而不是实现”，它能解决执行者的第一个错误，本文不再赘述。

二、要点明问题的“陷阱”。

如果我们已经知道了某些方法会有问题，一定要在文档中注明，例如“考验张良不能看别人怎么说，而要亲自看他怎么做，这是人性”。如果你注明了这些，别人还怎么会忽略？注明“陷阱”实际上是一种融会贯通的思维方式，也就是说，我们把一个问题的前因后果都说清楚了，大家一下就能明白！

三、亮出底线。

其实本文开头的任务描述中，有一个藏得很深的技巧：直接亮出底线！“让张良给他穿鞋”这句话就表明了底线，如果张良连给一个陌生老人穿鞋都肯做，他还有什么事情不肯做，这足以说明张良“对老人的恭敬之心”。这比如下这种长篇累牍的描述强得多：

让张良给他穿鞋。不能只让张良给老人倒一杯水，不能只让张良捶背…。

一定有人以为：这个例子只是虚拟的，实际工作中的事情和这个完全不一样。其实这种观点就是被表象蒙蔽，而看不到事物的本质。其实表象和本质之间，还有很多的话题可讲，请关注我的后续文章。

我相信：我的解决办法，不单单是针对文档，讨论问题、写代码都可以，凡是与人沟通的地方都有可能派上用场。

【软件开发领域】

你写了很多代码，注释很规范，误以为自己的代码能做到“前人栽树后人乘凉”的效果。实际上，你的注释大多是关于如何做的，而不是为什么这么做。这样的后果就是，“后人”看不懂你的代码，而擅自把那些看不懂的代码删掉，他经过测试没有发现问题。但是，问题总是被客户发现，发现之后，那些代码还得再找回来，也许他还会在周末给你打电话来确认你的代码。

所以我的建议是：

一、可以省掉“函数内如何实现”这类注释。

让函数之间的调用关系，满足“下层给上层呈现的是结果而不是实现”，通过函数名来体现，同时把代码中的每个逻辑段都抽象成函数，这样就不再需要“函数内如何实现”这类注释了，因为“如何实现”可以通过命名良好的函数名来了解。

二、注释内容要写外部特性、外部约定。

函数是给别人用的，注释必须要从使用者的角度来写，而不是把自己具体做了什么写上去，因为“具体做了什么”与“我为使用者提供了什么”一般情况下是有本质区别的，对于使用者来说尤其如此。

三、注释内容要写采取当前方案的原因、限制等。

由于不少公司以“敏捷开发”的名义省略了设计文档，或者设计文档只是个用标准格式编写的、和代码没什么关系的东西，所以代码注释中的设计成分更加重要。

而这个设计成分如果写成了“具体做了什么”，时间一长，就需要更新，而人是有惰性的，没有什么人愿意去更新注释。

而这个设计成分如果写成了“采用当前方案的原因、限制”，即便很长时间过去，需要更新的概率依然很低，因为这些注释是高层的设计思路，轻易不会做修改。

更为重要的是：这为后续修改代码的人提供了指导，他不会删除那些他认为无用的代码，因为注释中已经提到了这些代码的作用。

----------结束----------

作于2017-4-22。