只需要花点时间把事情写下来，这些后果都可以避免。当你的团队做了会改变你工作方式的决定时，把当时的日期以及决策背后的逻辑考虑写下来。以后，当有人问起“为什么那样做”或“为什么使用那个工具”时，你可以自信满满地回答了。

　　为将恼人的过程自动化做好准备

　　开发者经常会发现他们想将一些过程自动化。这些过程经常重复，而且会浪费宝贵的开发时间。然而，我时常碰到一些执行不那么频繁的手工过程(可能几个月一次)，这些过程会涉及一系列步骤，必须按照特定的顺序完成。如果没人愿意费点力气把这个过程写下来，那有很大的机会出现执行错误的情况，或者是执行中漏掉了某些步骤，浪费的时间甚至更多。此外，如果不先把这些步骤写下来，我们也没有切实可行的方式将这个过程自动化。

　　如果你发现自己正在执行的任务有多个步骤，而且这个任务有很大的机会要再次执行，请把这些步骤写下来。当再有人必须手工执行该过程时，能够节省时间，可能有你终于感到非常气馁，于是你将这个过程自动化了，而的行动也为那做好了准备。

　　作为后手

　　在敏捷项目中，正如敏捷宣言所述，我们更重视面对面的交流。这样交流需求是好的，因为不管是口头信息，还是非口头信息，都可以收集到。然而，交流的话可能被误解，更有可能被记错。任何一方都可能出现这种问题：开发者可能认为他们听到了，但是客户并没有说过，或者客户忘了(假定他们都是无意为之)他们曾让开发者选择某一特定方向。 这致使开发者后只是坚称某些行动是客户让他们做的，但到底是不是这样，却没有任何证据。在这种情况下，我的经验是，获胜的几乎总是客户，而开发者只能带着失意或者可能是被侮辱了的感觉走开。

　　看上去开发者并不希望发生这样的事。我们来看看，这种情况应该如何避免呢?我不知道……或许我们可以尝试一下把东西写下来?我们需要做的是在电话或面对面的会议之后写封邮件，用开发者的话描述一下，在他们看来，客户让他们做哪些事。这不需要多大力气，而且当“系统为什么要那样开发”之类的问题出现时，真是很好的跟踪证据。

　　使编写文档容易进行的一些想法

　　对大部分人来说，文档并不是自然而然的;而对大部分开发者来说，文档则完全是一种痛苦。然而，上面已经解释过，文档有其价值。下面是一些让写文档不那么痛苦的想法：

　　立即写下来。当碰到不喜欢做的事情时，我们中有很多人喜欢拖延。对于这类文档，可别这么做。好是趁热打铁，在你不需要停下来回忆的时候写下来更容易。一谈完，找个工作站或用移动设备把摘要写下来。

　　借助好工具。说到移动设备，有很多极好的工具，可以用来记事。早先，即便是简单的东西，我们也必须在wiki上找到一个合适的地方，并使用某些不那么直观的标记语言将它写下来。现在，我们有了无所不在的Evernote和OneNote，还有很多类似的工具;还有博客和微博(在你的项目中，使用Twitter是不可能的吗);如果其他所有的工具都不行，还有电子邮件呢。找出你喜欢的即可。

　　保持简短。每次讨论的文档不需要很长。即使不能使用Twitter，也可以假装在使用——让信息简明扼要、切中要害。在140个字内你能说些什么，使得描述的内容足够有用，同时又能让人快速抓住要点?文档被不止一次阅读的可能性与其长度成反比。

　　把它记到你能再次找到的地方。如果需要的时候找不到，那记下来也没什么用。把它记在看上去明显的位置(比如，放在建立好的项目文档仓库中，和代码放到一个地方，或者放到发给所有团队成员的电子邮件中)，能以电子方式搜索的地方比较理想。不要只是将其记在团队办公区的白板上(尽管除了将其记在可以长期保存的地方，你还想使用白板)。你可能想把信息记在多个地方，看看在哪里能找到……你甚至可以内容能够被找到的地方收集一些指标，以此来决定好的保存位置。我知道，对某些人而言，这可能有点疯狂。

　　写文档需要成为习惯

　　正如我上面所说，将项目中日常出现的小事写成文档并不是自然而言会去做的。你必须强迫自己这么做。我知道你宁愿编写代码，但是一定要让自己这么做;我保证物有所值。如果一有事发生，你能让自己跳到记事系统，这很快会成为老习惯了。那时你会惊讶，以前不记文档是怎么过来的啊。