你们开发项目有没有都先写一下开发文档，程序猿（媛）们都来说说吧

[快乐起航2020]

各位大神，大师及各位小伙伴们，请问你们开发项目有没有都先写一下开发文档，程序猿（媛）们都来说说吧

我们公司不算是软件公司，只开发自己的项目，是程序开发完了，在写开发文档，请问一下这个正常么

[zbdzjx]

写文档？？？！！ 文档还没写完，很有可能老板的需求就变了！！！ 当然，我们写的程序是公司内部使用的，而且老板的思想多变，今天说的东西，很有可能明天就变了。

[快乐起航2020]

引用 34 楼 zbdzjx 的回复:

写文档？？？！！ 文档还没写完，很有可能老板的需求就变了！！！ 当然，我们写的程序是公司内部使用的，而且老板的思想多变，今天说的东西，很有可能明天就变了。

我们老板也有点多变啊

[罪人不釋之枷]

我們公司我是負責設計內部消化的程序，基本就是其他部門提需求，設計出格式，要求的功能什麽的，然後就是自由發揮了。 ……

[快乐起航2020]

引用 8 楼 devmiao 的回复:

你说的文档是用户文档么？因为似乎没有开发文档就搞开发实在难以想象。

是指整个项目的需求文档和使用书册 啊

[於黾]

一般只有需求明确,才能先出文档,后实施. 像我们做的一些配套项目和一些用户定制的功能,用户自己对自己想要个什么都说不清楚, 都是做出来看,然后不满意改,哪里能写出什么文档来. 很多时候连做完了都整理不出文档,太乱...

[walkeeper]

个人感觉是因为客户自己对需求的不确定性搞的文档会很难写，小公司的经理一般为了偷懒省事都不写的，客户要改啥就改啥，改的乱七八糟一堆BUG再加班折腾，总算折腾完了才去写文档……

[於黾]

引用 17 楼 walkeeper 的回复:

个人感觉是因为客户自己对需求的不确定性搞的文档会很难写，小公司的经理一般为了偷懒省事都不写的，客户要改啥就改啥，改的乱七八糟一堆BUG再加班折腾，总算折腾完了才去写文档……

没错,很多时候客户根本不知道自己需求的到底是什么,只不过是参观了别的地方,发现挺好,然后就想要个差不多的. 但是其实他自己的业务跟人家的根本不一样,即使做出来了,还是要各种改. 而客户一开始根本连自己的业务都不熟,都是摸索着在干,那软件也只能跟着他们摸索,干完之前都没法出一个完整的文档.

[莫_问]

引用 13 楼 sp1234 的回复:

其实写文档之前，项目经理应该先拿出“工具平台”设计草案来。而最终的产品肯定需要根据用户需求改变成百上千个部分，也能灵活应对。 比如说给你40万，让你用3个月做一个相当巨大的“一堆工作流”的业务处理信息系统。如果你先把所有的“增删改查”模式先找UI设计师定个初稿，然后决定做5、6个通用控件（UI 个性扩展完全可以用技术手段达到），而成千上万的界面其实都是因为配置数据的变化而自动变化的，那么3、4个人完全可以完成一个大系统，而且得到用户的充分肯定。 而如果让那些小作坊里的“简单功能分解”式的做法去做，找10个人（工资同样）做16个月可能最终也被用户骂得狗血喷头、拒绝验收。 我的亲身经历都是如此。但是小公司遇到后者的情况自然有独特的“猫狗之道”，具体是什么做法就不多谈了。 我的意思是，软件开发并不是一直都在“代码工人”在流水线上拼凑 csdn 上可抄袭到的一些程序。如果你们把70%的精力放在自己的平台、组件的设计开发上，那么一定时间之后，你收获的就是几套良好的“生成器系统”，你就获得了自由。 程序员也因为大多数时间是在开发这样的生成器系统，那么你写的“文档”的层次也是这个生成器设计层次的。这时侯你再来讨论什么“有没有先写文档”就更有意义了。 但是这要求，项目经理不是一个码农，甚至不是眼中只有单一的一个产品，而应该是一个长期发展的平台的设计思路。

你的回复太中肯了。。支持一个。

[whhmkj]

项目设计稿，项目功能静态页面，具体的功能需求分析文档，项目编码，项目测试，项目上线

[iniins]

计划经济时代可能比较普遍，市场经济时代……呵呵

[alex_my]

总是会缺这缺那的，加班都搞不完项目，哪有人写文档。

[於黾]

引用 22 楼 alex_my 的回复:

总是会缺这缺那的，加班都搞不完项目，哪有人写文档。

所以大团队和小作坊的区别就体现在这里了 大团队要协作,没有文档如何分工? 而像你我这样,每个人负责个小项目,改来改去的,有文档也没人看...

[娃都会打酱油了]

大团队和小团队的区分啊，团队大了，没文档工作没法开展，小团队，有文档没文档都一样，都能开展工作

[chen870201]

理想中的过程： 1）项目经理或指派人员到客户现场了解需求，谈限制、条件、方案； 2）项目经理带领设计人员做原型、概要设计、数据库； 3）客户确认原型（少部分看概要）； 4）详细设计； 5）代码实现； 6）编码Review，单元测试，集成测试； 7）用户测试； 8）交付。 实际的过程： 1）Excel+其他系统截图=原型； 2）编码； 3）单元测试； 4）交付（试用）。

[於黾]

引用 25 楼 chen870201 的回复:

实际的过程： 1）Excel+其他系统截图=原型； 2）编码； 3）单元测试； 4）交付（试用）。

实际的过程: 1.用户提出需求 2.内部探讨,写概要设计文档 3.用户确认,并回到1,如此反复多次 4.编码+测试 5.试用 6.用户需求变更,回到4,如此反复,直到用户满意

[於黾]

还有7.用户竣工验收,补写所有文档

[小灰狼]

引用 33 楼 effun 的回复:

楼主既然你问了这个问题，说明还是有心人。文档这种东西本来就没有哪条法律规定一定要的，但有一定比没有好。 1、需求文档可以减少和客户扯蛋。 2、概要设计文档可以减少项目经理和程序员扯蛋。 3、详细设计和代码注释可以减少程序员之间相互扯蛋。 4、说明书可以减少后续培训的口水。 当然，到底文档起不起得了作用，还有看写文档的质量，还有看文档人的水平，文档的多少取决于项目的大小，但不管多大的项目，开发前的设计文档是必要的，否则时间一长，就叫天天不应了。

有的时候，老板今天说个需求，明天就要看结果，这个文档怎么给？

[effun]

引用 37 楼 hemowolf 的回复:

[quote=引用 33 楼 effun 的回复:] 楼主既然你问了这个问题，说明还是有心人。文档这种东西本来就没有哪条法律规定一定要的，但有一定比没有好。 1、需求文档可以减少和客户扯蛋。 2、概要设计文档可以减少项目经理和程序员扯蛋。 3、详细设计和代码注释可以减少程序员之间相互扯蛋。 4、说明书可以减少后续培训的口水。 当然，到底文档起不起得了作用，还有看写文档的质量，还有看文档人的水平，文档的多少取决于项目的大小，但不管多大的项目，开发前的设计文档是必要的，否则时间一长，就叫天天不应了。

有的时候，老板今天说个需求，明天就要看结果，这个文档怎么给？[/quote] 加班 or 走人

[成都-狗蛋儿]

大多数国产，都只能1.0，要想升级，得重新来。。。

[快乐起航2020]

引用 39 楼 gdf87521 的回复:

大多数国产，都只能1.0，要想升级，得重新来。。。