一、组织
……
二、沟通
……
三、文档
找某个人、某个部门要一个“需求确认书”或者“产品设计书”等等变成了整个事情的目的，找他们签字画押成了这一目的的保障。所有这一切的手段背后，我们在维护着最基本的那个组织需求：确保我们做内容是对的，至少做的流程是对的；至于别的对不对，那是决策和沟通本身出了问题，而不是我们“做”得对不对的问题。由此，我们把自己做成了“机械”，我们保障了形式和内容的“正确”，而不考虑结果是否真的正确。
回顾整个问题：文档其实本质上是对沟通的确认，而并非沟通本身。然而在上面的例子中，我们的种种作为，却把这个因果倒转了过来。我们用文档替代了沟通，所以真正的沟通没了，沟通的正确性没了，只剩下了文档的正确性。
UML的根本问题就在这里：（它的推动者，在多数情况下，）孤立地强调了文档的正确性，而忽视了背后的真正问题——沟通。所以我常常的建议是：
- 找到对方；
- 交流、交流、交流、交流（我的意思是会议、扯皮、邮件、吃饭以及骂仗等等一切形式）， 直到双方真的明白对方的意图；
- 然后决策：妥协、一致，或者是保留意见；
- 最后将上述结果记录在案。
这个过程才是沟通；而文档，只是对其结果和关键过程的记录。
这才是团队可以依赖的沟通。
