先说结论：关注沟通中的名词。以下都是在说这一件事。
软件项目的最大损耗在哪里？我觉得毫无疑问，是「沟通」。软件项目，其实就是一个信息变换和加工的过程。不光项目前期的分析讨论是这样，连后面的设计，编码究其本质也是符号化的信息表达而已。这里面的信息交换尤其频繁， 沟通质量对项目的影响尤其大。
宏观上的沟通，更多是在项目管控范畴要讨论的问题。而从微观上看，如果把沟通场景聚焦到一个细微的问题讨论、逻辑澄清、方案建议上，个人的沟通能力和沟通技巧就直接决定了沟通的质量。
无论是以前做项目还是现在做产品，我都留意到一个极为常见的，绝大多数人都会有沟通问题，包括我自己。这个问题，就是——「名词含混」。
就我在我的工作中的大致观察，这个问题起码可以为日常工作中超过50%的低质量沟通、甚至是无效沟通负责。
随手举几个例子：
「上午那个问题你搞定了吗？」——上午讨论的那么多问题，你说的是哪个？
「把中间抽到的数据……」——中间抽到的什么数据？表结构？还是键值对？
「用户应该不知道这个吧？」——你说的是哪个用户？上游用户，还是下游用户？
「那个report……」——我们系统有8张报表，说清楚是哪张会死吗？
「按他们说的逻辑做。」——他们哔哔了那许多，都要做？
「你看这个设计可以吗？」——这么大一张图，你说的是哪块？
「数据抽取的那块逻辑，我想了想，好像还有点问题……」——你知道你所说的逻辑，拆分成代码有多少个部分吗？你特么说的是哪个点的逻辑？
「把那两个表拼接一下……」——…………
再往下写，肯定就是脏话了。
这样的对话，穿插在我的日常工作中，频繁出自于我自己和其他人的口。其基本模式就是：表达-对名词的追问-对名词的澄清-继续表达。（更甚，这个模式可能止于第一步之后，那后面一定有很多悲剧会发生。）
而很显然这样的模式应该被调优成这样：包含准确名词的表达。
专门留意之后，我会要求自己按照调优模式来进行所有的沟通。我能非常清楚地感觉到这个小小调整带来的沟通效率的提升，这意味着更少的沟通时间，更小的信息损失。所以我会推荐追求高质量协作的团队和个体都来注意这么一件小小的事情。
这的确是件小事情，不需要学习，都可以操作，效果也很明显。但它也是实实在在有花销的。
这个花销一方面来自于你需要打破既有沟通习惯的努力。你需要给自己设置一个「意识触发器」，每当谈到沟通内容的那些关键对象时，你都需要让它蹦出来，新开一个思维线程来处理你的表达。
花销的另一方面，来自于，你要寻找准确的修饰词来描述谈话对象。这比使用代词来得困难，也比使用简单名词来得困难。试试看：
1.把那个结果存起来。
2.把数据结果存储到下游表里。
3.把经过逻辑处理的数据存储到beforProcessing那个表里。
4.把通过之前Mapping界面处理后的结果数据，存储到Output步骤的beforeProcessing表里，作为Output的输入。
当然，第一种沟通方式也可能达成正确的结果，但这属于高难度动作，不但要对话双方有相当好的默契，能够把对方没有言尽的内容做恰当的变现[1]，还要求沟通当下的语境和工作环境中没有其他的类似对象给变现过程带来歧义。
而第四种从结果来看，会产生误会的可能性就很小了。但是，它的长度已经说明要在沟通当下把它输出出来是有阻力的，尤其对于许多惜字如金的理科生来说[2]。
但第四种方式所代表的，应该是标准。你应该根据你沟通的上下文，选取尽量向下靠的方式去做名词表达。我对沟通的态度，在之前那篇「冗余沟通」里已经说得很清楚——宁冗余，少不足。
解决名词含混的问题，也很简单：
1.（尽量）干掉代词。一旦你要说代词了，请启动你的意识触发器。
2. 修饰名词。尽量为简单名词加上足够的说明。以限定，消除歧义。
3. 换位。在你认为恰当的时间点，切换成聆听方的视角与上下文来解读。
这不需要学习，但需要练习。
––––––––––––––––––––––––––––––––
[1]这里取「变为现实」之意。
[2]尤其是程序员，用键盘敲出的代码来进行表达，对于许多人来说是他们喜欢的自我身份认同的方式。我也认同这一点。
