文档不是定心丸

在这个压力巨大的时代，因恐慌而心力交瘁的人实在是太多了，今天就遇到一位。
“老板们都不知道这是怎么回事，所以你必须写一份详尽的文档”
“不是有文档吗？”
“那些文档太多了，每种业务一个文档太凌乱了，需要一个总文档，能够一看就懂的文档”
“这个不太好写，这个如果在高层看很简单，就是两句话的事，没必要再写个文档。如果看详细内容，看这些具体的文档就可以了”
“这样不行，你得写一个能让大家看得懂的文档，要包含必要的知识，以及其他文档已经有的内容，需要包含进去，便于理解，又不至于太底层、太细节。老板们对这块不明白，一头雾水，感到恐慌……”
“我还是不明白你想要什么，没有办法写”
“@#￥￥%……&×*&^%$#@！……”
反复了半个小时也没有搞清除到底想要什么样的文档。最后，让他发了一个范本，打开一看，分明和我说的已经有的文档类似。看来根本就没有读已经写的文档就要求一个overall的文档，在其眼里可谓：“文档，多多益善也”。
不过其倒是道出了一个PM（Project Manager）们的状态：恐慌！当然他是托老板之名说出这个词的，好比去咨询一个难以启齿的病，总是托朋友之名羞羞答答地问一样，作为一个PM，承认自己对项目内容毫无所知也是难以启齿的。
为何恐慌？因为他不了解项目进行的内容，对下一步如何做完全没底。这种状态是可以理解的，“盲人骑瞎马，夜半临深池”，能不恐慌吗？
怎么办？只有两条路：
不懂就不懂，没关系，相信其他人能做好，授权给懂的人做就好了。
不懂就学呗，不需要成为专家，能听懂这些人说话，知道他们在做什么就好了。
第一种方式是一般老板们的选择，不懂没关系，组建自我管理团队，把具体行动决策权下放给真正做事的人，对项目观其大略，当好教练与做好后勤即可。对于软件项目，最了解情况的人是做事的人，他们做具体行动决策是合适的，因此自我管理团队是适用的。
但PM们就不能这么“偷懒”了，他们是具体的执行人，不能把自己本职指派给其他人。如果后退那说明他就是多余的人了，已经没有教练和后勤可做了，没有退路。于是只有一个选择，那就是：学！
如果能“知耻而后勇”，那也算是“善！”了，从项目一开始就这样，慢慢积累下来，应该很快就能大体知道项目的内容，基本了解技术构架，出现问题时知道是哪部分，说原因能大体明白，知道什么是重点……这样就会重新找会对项目的控制感，而不至于生活在恐慌之中。
可是怕就怕没有“后勇”，他们认为自己是Manager，不需要懂技术，只需要会用excel、power point、Project等办公软件就可以了，不用操心技术。于是没有下功夫来了解这个项目的一些必要细节，甚至连做什么都不甚了了。突然有一天发现自己不能理解其他人的谈话，不知道下一个item的前提、是否可行等时，意识到了自己已经不能使这几个办公软件吐出漂亮的文档，于是进入恐慌状态。
于是就出现开始的一幕，恐惧的心需要用文档来安慰。（治病救人之前不妨模仿《天下无贼》中的刘大盗问问：凭什么你可以不懂技术？！不懂技术的你何必居此是非之地？！）
文档真的能成为定心丸吗？一份文档能成为“速效救心丸”吗？
相信有一份文档能使你看完就明白所有关于一个项目的技术情况吗？我相信有的。百科全书式的大而全文档即可。
相信这份文档能在十分钟之内读完吗？呵呵，这个就看智商和阅读速度了，因人而异，不过我相信绝大部分人做不到。因此即使这是颗救心丸，它也不是速效的。
文档是什么？大学的时候软件工程书给软件的定义是：程序+文档。可见文档在软件工程里的重视程度，工作以后更是发现公司的开发流程里面更是以文档为主线，从初始的需求文档开始，经过“流水线”处理，最终的以文档包裹的软件就下线了。文档如此重要，于是也出现了过文档化的倾向。
由于软件代码不是人人都能读懂的，读起来也不直观，文档作为补充当然是很必要的，这个我是从来不反对的。但是好比中秋的月饼，豪华的包装剥去后，我们吃的是月饼，不是包装。对于软件，最终使用的是软件，而不是文档，即使是最终用户，在文档起作用的地方也一定是软件界面还不够友好的地方。因此，文档要讲究实效，不能为文档而文档。
软件开发过程中的文档按目标用户可以分为两类：
开发团队内部沟通的文档，包括各种设计文档等
对开发团队以外人员的文档，包括软件功能描述文档、用户手册等
对于开发团队来说，设计文档用于交流，既用于现时的横向交流，也用于将来的纵向交流。横向体现在让目前一起工作的人知道某一部分是如何做的，而纵向体现在记录功效，让后人能理解现在的设计，不至于随时间遗忘。从这两个方面来看，文档都是辅助开发人员理解软件设计。如果软件架构设计得清晰，代码写得易懂，这些文档为什么要面面俱到呢？毕竟如果文档和代码重复，也意味着一方改变，另一方也得跟着改，意味着要维护两份同样的内容，更不要提文档之间内容相互重叠的多份文档。除了给PM或老板们一个安全感，他们有什么用呢？
对于开发团队以外的人员，当然得有文档来告诉他们这个软件可以做什么，怎么做，毕竟他们不会来看代码，软件最终也要为他们服务，但这种文档也不能写多份，否则也有同样的问题，多份文档会极大增加文档的维护量。
因此，文档可不是“多多益善”的，没有即时维护更新的文档只会带来麻烦。
另外，又有多少人会真正读文档呢？没有数据，很怀疑。
PM们可能不同意我的观点，因为没有为他们定做的文档，能一颗见效，医治那颗脆弱的心。首先，不会存在这样的一份文档，能够仅此一份即可奏效，更不能即刻奏效。其次，文档不是不花钱的，是有成本的。这样的一颗药，只为一两个人制造，太不合算了，尤其是在资源永远匮乏的软件项目中。
如果不能下功夫啃一些设计文档，那颗恐慌的心恐怕只能继续恐慌下去了……