也许我们可以从West女士那里学到一点什么。问题不只是你有什么，还要看你怎样包装它。除非你能够与他人交流，否则就算你拥有最好的主意、最漂亮的代码、或是最注重实效的想法，最终也会毫无结果。没有有效的交流，一个好想法就只是一个无人关心的孤儿。
作为开发者，我们必须在许多层面上进行交流。我们把许多小时花在开会、倾听和交谈上。我们与最终用户一起工作，设法了解他们的需要。我们编写代码，与机器交流我们的意图；把我们的想法变成文档，留给以后的开发者。我们撰写提案和备忘录，用以申请资源并证明其正当性、报告我们的状态、以及提出各种新方法。我们每天在团队中工作，宣扬我们的主意、修正现有的做法、并提出新的做法。我们的时间有很大一部分都花在交流上，所以我们需要把它做好。
我们汇总了我们觉得有用的一些想法。
知道你想要说什么
在工作中使用的更为正式的交流方式中，最困难的部分也许是确切地弄清楚你想要说什么。小说家在开始写作之前，会详细地构思情节，而撰写技术文档的人却常常乐于坐到键盘前，键入“1. 介绍……”，并开始敲入接下来在他们的头脑里冒出来的任何东西。
规划你想要说的东西。写出大纲。然后问你自己：“这是否讲清了我要说的所有内容？”提炼它，直到确实如此为止。
这个方法不只适用于撰写文档。当你面临重要会议、或是要与重要客户通电话时，简略记下你想要交流的想法，并准备好几种把它们讲清楚的策略。
了解你的听众
只有当你是在传达信息时，你才是在交流。为此，你需要了解你的听众的需要、兴趣、能力。我们都曾出席过这样的会议：一个做开发的滑稽人物在发表长篇独白，讲述某种神秘技术的各种优点，把市场部副总裁弄得目光呆滞。这不是交流，而只是空谈，让人厌烦的（annoying）空谈。
要在脑海里形成一幅明确的关于你的听众的画面。下一页的图1.1中显示的WISDOM离合诗（acrostic）可能会对你有帮助。
假设你想提议开发一个基于Web的系统，用于让你们的最终用户提交bug报告。取决于听众的不同，你可以用不同的方式介绍这个系统。如果可以不用在电话上等候，每天24小时提交bug报告，最终用户将会很高兴。你们的市场部门可以利用这一事实促销。支持部门的经理会因为两个原因而高兴：所需员工更少，问题报告得以自动化。最后，开发者会因为能获得基于Web的客户－服务器技术和新数据库引擎方面的经验而感到享受。通过针对不同的人进行适当的修正，你将让他们都为你的项目感到兴奋。
选择时机
这是星期五的下午六点，审计人员进驻已有一周。你的老板最小的孩子在医院里，外面下着滂沱大雨，这时开车回家肯定是一场噩梦。这大概不是向她提出PC内存升级的好时候。
为了了解你的听众需要听到什么，你需要弄清楚他们的“轻重缓急”是什么。找到一个刚刚因为丢失源码而遭到老板批评的经理，向她介绍你关于源码仓库的构想，你将会拥有一个更容易接纳的倾听者。要让你所说的适得其时，在内容上切实相关。有时候，只要简单地问一句“现在我们可以谈谈……吗？”就可以了。
图1.1 WISDOM离合诗——了解听众 What do you want them to learn? What is their interest in what you’ve got to say? How sophisticated are they? How much detail do they want? Whom do you want to own the information? How can you motivate them to listen to you?
你想让他们学到什么？
他们对你讲的什么感兴趣？
他们有多富有经验？
他们想要多少细节？
你想要让谁拥有这些信息？
你如何促使他们听你说话？
选择风格
调整你的交流风格，让其适应你的听众。有人要的是正式的“事实”简报。另一些人喜欢在进入正题之前高谈阔论一番。如果是书面文档，则有人喜欢一大摞报告，而另一些人却喜欢简单的备忘录或电子邮件。如果有疑问，就询问对方。
但是，要记住，你也是交流事务的一方。如果有人说，他们需要你用一段话进行描述，而你觉得不用若干页纸就无法做到，如实告诉他们。记住，这样的反馈也是交流的一种形式。
让文档美观
你的主意很重要。它们应该以美观的方式传递给你的听众。
太多程序员（和他们的经理）在制作书面文档时只关心内容。我们认为这是一个错误。任何一个厨师都会告诉你，你可以在厨房里忙碌几个小时，最后却会因为饭菜糟糕的外观而毁掉你的努力。
在今天，已经没有任何借口制作出外观糟糕的打印文档。现代的字处理器（以及像LaTeX和troff这样的排版系统）能够生成非常好的输出。你只需要学习一些基本的命令。如果你的字处理器支持样式表，就加以利用（你的公司也许已经定义了你可以使用的样式表）。学习如何设置页眉和页脚。查看你的软件包中包含的样本文档，以对样式和版式有所了解。检查拼写，先自动，再手工。毕竟，有一些拼写错误是检查器找不出来的（After awl, their are spelling miss streaks that the chequer can knot ketch）。
让听众参与
我们常常发现，与制作文档的过程相比，我们制作出的文档最后并没有那么重要。如果可能，让你的读者参与文档的早期草稿的制作。获取他们的反馈，并汲取他们的智慧。你将建立良好的工作关系，并很可能在此过程中制作出更好的文档。
做倾听者
如果你想要大家听你说话，你必须使用一种方法：听他们说话。即使你掌握着全部信息，即使那是一个正式会议，你站在20个衣着正式的人面前——如果你不听他们说话，他们也不会听你说话。
鼓励大家通过提问来交谈，或是让他们总结你告诉他们的东西。把会议变成对话，你将能更有效地阐明你的观点。谁知道呢，你也许还能学到点什么。
回复他人
如果你向别人提问，他们不做出回应，你会觉得他们不礼貌。但当别人给你发送电子邮件或备忘录、请你提供信息、或是采取某种行动时，你是否经常忘记回复？在匆忙的日常生活中，很容易忘记事情。你应该总是对电子邮件和语音邮件做出回应，即使内容只是“我稍后回复你。”随时通知别人，会让他们更容易原谅你偶然的疏忽，并让他们觉得你没有忘记他们。
提示10： It’s Both What You Say and the Way You Say It 你说什么和你怎么说同样重要 除非你生活在真空中，你才不需要能交流。交流越有效，你就越有影响力。
电子邮件交流
我们所说的关于书面交流的所有东西都同样适用于电子邮件。现在的电子邮件已经发展成为公司内部和公司之间进行交流的主要手段。它被用于讨论合约、调解争端，以及用作法庭证据。但因为某种原因，许多从不会发出低劣的书面文档的人却乐于往全世界乱扔外观糟糕的电子邮件。
我们关于电子邮件的提示很简单：
- 在你按下SEND之前进行校对。
- 检查拼写。
- 让格式保持简单。有人使用均衡字体（proportional font）阅读电子邮件，所以你辛苦制作的ASCII艺术图形在他们看来将像是母鸡的脚印一样乱七八糟。
- 只在你知道对方能够阅读rich-text或HTML格式的邮件的情况下使用这些格式。纯文本是通用的。
- 设法让引文减至最少。没有人喜欢收到一封回邮，其中有100行是他原来的电子邮件，只在最后新添了三个字：“我同意”。
- 如果你引用别人的电子邮件，一定要注明出处。并在正文中进行引用（而不是当做附件）。
- 不要用言语攻击别人（flame），除非你想让别人也攻击你，并老是纠缠你。
- 在发送之前检查你的收件人名单。最近《华尔街日报》上有一篇文章报道说，有一个雇员通过部门的电子邮件散布对老板的不满，却没有意识到老板也在收件人名单里。
- 你的电子邮件——你收到的重要文件和你发送的邮件——加以组织并存档。
如Microsoft和Netscape的好些雇员在1999年司法部调查期间所发现的，e-mail是永久性的。要设法像对待任何书面备忘录或报告一样小心对待e-mail。
总结：
l 知道你想要说什么。
l 了解你的听众。
l 选择时机。
l 选择风格。
l 让文档美观。
l 让听众参与。
l 做倾听者。
l 回复他人。
相关内容：
l 原型与便笺
l 注重实效的团队
挑战：
l 有几本好书讨论了开发团队内部的交流[Bro95, McC95, DL99]。下决心在接下来的18个月里读完所有这三本书。此外，Dinosaur Brains[Ber96]这本书讨论了我们所有人都会带到工作环境中的“情绪包袱”。
l 在你下一次进行展示、或是撰写备忘录支持某种立场时，先试着按第20页的WISDOM离合诗做一遍。看这样是否有助于你了解怎样定位你的讲话。如果合适，事后与你的听众谈一谈，看你对他们的需要的估计有多准确。
