需求分析书 概要设计书 详细设计书 数据库设计书

学生做东西时，必须养成的习惯！！

最好还是有份基本文档,这样对项目的功能点会确定的差不多

文档这个东东，要写，不然做东东都是做的人当时凭空想想，想这样就这样，想那样就那样，最后整理整个系统的时候就发现无比的痛苦，我们公司以前好多项目都是项目快做完再补文档，现在在老大的推动下，一定要按照开发流程来做，虽然很多人还是有些不习惯，但是毕竟是在做了，我想慢慢就会好了。
真正的编码工作量其实占整个项目的40%就已经比较高了，开头的需求设计文档是必不可少的。

哎..我在公司里,也写文档,都是开发完了在写需求,为了给客户看

我觉得这个要看情况而定，不过有一点是，文档一定要的，作为开发，验收，测试的依据。大家都想当然的做东西，你的系统变身人狼也就不远啦。
如果你们的团队很成熟，那有需求分析，和概要设计（一定要逻辑清晰，没有歧义，或者和需求分析合二为一），熟悉一点的人设计好数据库，下面就比较容易把握了，你心里知道下面的东西大家会做成什么样子。
如果你们的团队不太成熟，team leader就要辛苦点，把要规定的东西，注意的问题，都写出来，越详细越好，而且要时常跟踪，或者每天几分钟的站立会议（10人以下），组员汇报进度。

有时文档 还不如不写！嘿嘿！！有的东西是天天变

感觉文档是必须的，但这个必须的程度就要根据每个团队的情况来自己定义了。像某些皮包公司，让他们写文档不如杀了他们。。。而对于规模较大的公司，利用文档来规范项目开发过程、降低项目风险绝对是行之有效的方法，公司规模越大，文档就要分得越细致，反之亦然。

我现在做的项目就是因为文档不齐，问题非常的多，现在新的项目还没开始就写文档了。而且原来的PM（国外总部的）被所有coding人员（国内部）排斥了。新项目开始的要求就是把原来这个PM排除在外。o(∩_∩)o...
没有文档很多都是口头的，责任也都是推来退去，特别是管理人员，你都不知道自己还有多少东西没有搞定。

没设计
没文档
没过程
没规范

你怎么才能知道你手下的员工不是在磨洋工？

文档确实是重要且必须的，
制定和编写的过程，也是需求逐渐明确，责任清晰的这样一个过程。

至少在初期应该出个干货，
项目行进中，不断修改，

本人做国内项目，同一个需求经常被客户要求进行N次修改，

文档也需要进行N次调整，很痛苦，
但一些问题，也确实从文档里就可以发现的了。