文档，重要？不重要？有多重要？

环境决定一切....

最近一个项目，写文档的时间远大于写代码的时间，项目发布到集成测试环境后，代码基本上没太多改动了，文档倒是改个没停。

需求文档，设计文档，用户手册...，最难的是用户手册，这是项目的面子工程，直接涉及到集成测试的复杂度和代价，象我们这个WebService,天南地北的不知道会被谁用到，一个一个用户去解释实在招架不住，于是昨天改了，今天接着改....

我最近的项目也是如此，花在文档和设计上的时间已经奔3个月了

我觉得文档是相当重要的

但是过于追求文档而忽视开发人员的情绪也是管理上的失败。

文档也是一种程序。。。

开发人数越多
文档就应该越详细

“写文档的时间远大于写代码的时间”

是很正常的事。。。
就如同发射火箭一瞬
造火箭1年
研究10年

写文档让别人拿钱用了一生时间。。。。


刚刚看到的以前的贴子
http://www.iteye.com/topic/5876

用户手册当然重要。
辛苦做出来了，不就是希望卖得好吗。
用户手册是用户体验、用户服务的很重要的方面。

不过，看来，楼主的公司或者开发资源很丰富，或者对这个项目很重视，还专门拨给开发人员比开发更长的时间写用户文档，修缮项目文档。

现在多种软件过程都有这个问题，写“功能代码”的时间都只占少数


这可不是什么“面子工程”，这是实打实的“里子工程”，一定要做好。

补充一点，我们这个算个中间层吧，用户不是Business User, 而是上面一层Development team。所以这个用户手册实际上是WebService的描述文档，因为会被很多不同的Team用到，所以文档就比较重要了。我觉得如何向别人介绍一个服务，确实是件很讲究的事情。我们也用到了一些Third Party的服务，比如PayPal(贝宝)，他们提供的文档（包括client example project)就体现了他们的专业程度，让人蛮触动的。


至于需求和设计文档，因为都是长期的项目，人员来来往往的，环境又特别复杂，而每个项目又只是更大的一个项目的一部分。所以当一个新人进来的时候，很难指望旁边的人把什么都讲给你听，只有通过查看大量的文档来了解系统的历史和现状。虽然可以察看Code,但是要知道逻辑可能散落在好几个系统里面，或者在数据库中，或者配置文件中，或者有些让人很难理解的定制逻辑，实在还是希望有高质量的文档。

可能，国内大部分人都是在做新项目的开发，对承包方来说最好是早点完工收钱，反正又不要我维护，即使要我维护那也要另外记时收钱，文档的重要性就没有体现得那么明显。但对使用软件的企业本身来说，就不得不考虑维护的成本，不管是自己做还是外包给别人做，我觉得都需要好好验收下文档。

无法想象如果structs没有那么多的文档的话，是否还会流行。
最近用的框架正为文档少而苦恼呢。

写文档虽然有时候觉得狠枯燥累人
但一定要做
还必须得认真的做

我现在项目组的项目经理是一位大学里面的知名教授，言必称对象，整天自己趴在那边写文档，然后交给下面人开发。底下人也不敢去问他，因为他很会骂人，结果很多误导。概要设计、详细设计...其实都是一堆垃圾。开发人员谁也不会去看那个。典型的文档驱动开发。结果是项目一推再推，而那位教授，也把责任推给其他人，因为他是知名的。唉...

我认为有用的文档包含用户手册（这个相当重要，拿给客户直接可以看出你专业不专业）。还有一份比较简洁的技术说明或者业务介绍，每个新来的同事看这份文档就可以比较快速的，或者是有帮助的融入进来。