我有时会发现一个很奇怪的现象：在公司开会的时候，明明自己说的话是正确的，但大家就是没有回应。过了一会儿，另外一个人表达的观点和自己的观点几乎一样，大家就纷纷表示赞同。为什么？
当时我还百思不得其解，现在想来，可能有如下三个原因：第二个人是大家更信任的人，在第二个人说同一观点时大家已经想明白了，第二个人的表达力比我好。
前两种原因，如果我们分析下去，对于我们自己的提高可能没有益处，因此本文只关注于第三个原因。
【工作越认真，越容易犯错】
我们仍然拿黄石公和张良的故事举例：
黄石公考验张良，分为三步：让张良给他穿鞋、第一次五日之约、第二次五日之约。
假设这是工作中的一篇文档，上下游两个部门依靠这篇文档来衔接工作。下游部门的人拿到这篇文档后，他要去执行“让张良给他穿鞋”、“第一次五日之约”、“第二次五日之约”这三个步骤。到最后一个步骤“第二次五日之约”时，他发觉有两次五日之约，这是明显的重复，于是他就做出一个决定：不做第三步。
执行者又发现，“让张良给穿鞋”这一点太难做到了，因为他怕引起张良的反感，因此他想到了另外一个方法：为什么不能向张良的邻居打听一下呢？于是，执行者就这么做了。
最终执行者犯了两个错误：少考察了一个方面，使用了错误的方法而得到虚假的信息。
这两个错误必须解释一下：为什么少考察了一个方面？执行者会这样想：给我的那份文档没有告诉我要考验什么方面，它只是告诉我要做三件事而已，而我发现第二件事和第三件事明显是重复的，就把第三件事去掉了，因为我工作认真负责才会做这种纠错。
第二个错误：为什么使用了错误的方法而得到虚假的信息？执行者会这样想：我发现文档中“让张良给穿鞋”在执行时有困难，会引起张良的误解，于是换了一种方式：向邻居打听，这种方式能够得到更全面的信息，同样是因为我工作认真负责才会做这种纠错。
这么看来，执行者工作越认真，就越容易犯错，这岂不是一个悖论？问题到底出在哪里？
【错误的本质是什么】
这件事的本质是：执行者使用一种有一定自主权的方式在工作，他期望的任务描述是目标式的，而交给他的任务描述却是指令式的。
表面上看，任务描述是“黄石公考验张良，分为三步：让张良给他穿鞋、第一次五日之约、第二次五日之约”，这里边是有目标的：“考验张良”，但这个说法并没有把目标说清楚。
每个人都有天生的纠错能力，例如一个字打错了，他能根据上下文判断出这是个错字。执行者在执行三个步骤时，发现了一个“错误”，他启动了自己的纠错系统，他的知识范围就决定了他断定这肯定是个错误，就像他断定1+1=3是个错误一样，因此他没有丝毫的怀疑，当然不会去找别人确认这是否是一个错误。
看明白了错误的本质，我们该如何解决？
凭直觉我们想到一个方法：让执行者忠实地按照文档中说的步骤去做，也就是指令式的工作方式。但问题来了，执行者如果这样做事，就变成了一个按照固定程序操作的机器人，当文档中有错误的时候，就会执行错误，如果还有下游执行者，那么就会一路错下去，最后那个错误会滚成一个巨大的雪球，雪球破裂的时刻很可能是惊心动魄的！
这么看来，纠错不行，不纠错也不行，难道就没有办法了吗？
【解决办法】
其实是有办法的。错误的根源是：文档风格与执行者工作方式的不匹配。为了解决问题，我们只想到了改变执行者，结果是不可行，其实我们还可以改变文档风格，从如下几个方面改进：
一、让纵向层次拥有无须解释的关联，是因为下层给上层呈现的是结果而不是实现。
我之前的文章《一样东西能让你的表达力熠熠发光：层次感一样东西能让你的表达力熠熠发光：层次感》中，【改造的精妙之处】部分有一个核心思想——“纵向层次拥有无须解释的关联，是因为下层给上层呈现的是结果而不是实现”，它能解决执行者的第一个错误，本文不再赘述。
二、要点明问题的“陷阱”。
如果我们已经知道了某些方法会有问题，一定要在文档中注明，例如“考验张良不能看别人怎么说，而要亲自看他怎么做，这是人性”。如果你注明了这些，别人还怎么会忽略？注明“陷阱”实际上是一种融会贯通的思维方式，也就是说，我们把一个问题的前因后果都说清楚了，大家一下就能明白！
三、亮出底线。
其实本文开头的任务描述中，有一个藏得很深的技巧：直接亮出底线！“让张良给他穿鞋”这句话就表明了底线，如果张良连给一个陌生老人穿鞋都肯做，他还有什么事情不肯做，这足以说明张良“对老人的恭敬之心”。这比如下这种长篇累牍的描述强得多：
让张良给他穿鞋。不能只让张良给老人倒一杯水，不能只让张良捶背…。
一定有人以为：这个例子只是虚拟的，实际工作中的事情和这个完全不一样。其实这种观点就是被表象蒙蔽，而看不到事物的本质。其实表象和本质之间，还有很多的话题可讲，请关注我的后续文章。
我相信：我的解决办法，不单单是针对文档，讨论问题、写代码都可以，凡是与人沟通的地方都有可能派上用场。
【软件开发领域】
你写了很多代码，注释很规范，误以为自己的代码能做到“前人栽树后人乘凉”的效果。实际上，你的注释大多是关于如何做的，而不是为什么这么做。这样的后果就是，“后人”看不懂你的代码，而擅自把那些看不懂的代码删掉，他经过测试没有发现问题。但是，问题总是被客户发现，发现之后，那些代码还得再找回来，也许他还会在周末给你打电话来确认你的代码。
所以我的建议是：
一、可以省掉“函数内如何实现”这类注释。
让函数之间的调用关系，满足“下层给上层呈现的是结果而不是实现”，通过函数名来体现，同时把代码中的每个逻辑段都抽象成函数，这样就不再需要“函数内如何实现”这类注释了，因为“如何实现”可以通过命名良好的函数名来了解。
二、注释内容要写外部特性、外部约定。
函数是给别人用的，注释必须要从使用者的角度来写，而不是把自己具体做了什么写上去，因为“具体做了什么”与“我为使用者提供了什么”一般情况下是有本质区别的，对于使用者来说尤其如此。
三、注释内容要写采取当前方案的原因、限制等。
由于不少公司以“敏捷开发”的名义省略了设计文档，或者设计文档只是个用标准格式编写的、和代码没什么关系的东西，所以代码注释中的设计成分更加重要。
而这个设计成分如果写成了“具体做了什么”，时间一长，就需要更新，而人是有惰性的，没有什么人愿意去更新注释。
而这个设计成分如果写成了“采用当前方案的原因、限制”，即便很长时间过去，需要更新的概率依然很低，因为这些注释是高层的设计思路，轻易不会做修改。
更为重要的是：这为后续修改代码的人提供了指导，他不会删除那些他认为无用的代码，因为注释中已经提到了这些代码的作用。
----------结束----------
作于2017-4-22。
我的相关文章：
《快人十倍的秘诀：一个初学者和一个资深者的对话：融会贯通续》
《一样东西能让你的表达力熠熠发光：层次感一样东西能让你的表达力熠熠发光：层次感》
