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

快乐起航2020 2014-08-02 10:08:56

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

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

...全文

871 40 打赏收藏转发到动态举报

写回复

用AI写文章

40 条回复

切换为时间正序

请发表友善的回复…

发表回复

快乐起航2020 2014-08-08

打赏
举报

引用 39 楼 gdf87521 的回复:

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

成都-狗蛋儿 2014-08-08

打赏
举报

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

effun 2014-08-05

打赏
举报

引用 37 楼 hemowolf 的回复:

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

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

小灰狼 2014-08-05

打赏
举报

引用 33 楼 effun 的回复:

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

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

於黾 2014-08-04

打赏
举报

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

於黾 2014-08-04

打赏
举报

引用 25 楼 chen870201 的回复:

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

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

chen870201 2014-08-04

打赏
举报

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

娃都会打酱油了 2014-08-04

打赏
举报

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

於黾 2014-08-04

打赏
举报

引用 22 楼 alex_my 的回复:

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

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

alex_my 2014-08-04

打赏
举报

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

iniins 2014-08-04

打赏
举报

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

whhmkj 2014-08-04

打赏
举报

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

莫_问 2014-08-04

打赏
举报

引用 13 楼 sp1234 的回复:

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

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

於黾 2014-08-04