软件管理和软件开发文档的关系？(转自CSDN)

jiangtao: 
观点1: 
 
文档固然重要，但精细到什么程度就有待大家一起探讨了。目前大部分都是为了文档而文档就失去了意义。对于文档我更倾向于写个大概，具体细节开发的时候不断请教。如果要等到全部细节都写出来，工作量实在太大了。实际上也很少有光看文档就可以明白的，还是需要当事人讲解的。讲解容易，写出来就难了。这两种方式哪个成本更高，就不太好说了。 
企业文化氛围是为了企业利益最大化而建立的。企业文化着眼的是企业的长远目标，而你所说的利益则是短期目标，谁该服从谁？一个好的企业文化，会充分调动员工的积极性和热情，这远比流水线式的生产方式效率来的更高。员工不是你多给几个钱就会为你卖命的，更多的是靠企业文化，组织行为去不断的感染他。 
以前对印度那种要求员工把自己每天的工作完全记录下来，精确到分，最后把软件开发精确到小时，非常羡慕。同时这种方法也严格的限制了人的创造性和热情，是问有几个人愿意在这样的企业工作？企业应该更加人性化一些，多为员工想想，员工才会为你奋斗，发挥出潜在的热情。企业可能损失一些利益，但他可以留住宝贵的人才，为今后的发展铺平道路。 
 
观点2: 
你说的不错，我现在在国外工作，我们的开发是精确到一刻钟的，因为每个人有一张作业纪录。 
我一开始也不习惯这种方式，但是慢慢的适应了，呵呵，当你的工作量和钱直接联系在一起时，变自愿的遵守这种游戏规则。但是，它的缺点也如同你说，很容易抹煞个人工作热情。说实在话，中国人没有多少能从心底赞同，我们大多数人喜欢很自由的工作方式: 你给我一份时间表，我到时候给你结果，怎么干是我自己的事，但是在这里行不通！为什么？资本家在工作时间内是绝对不愿意让你有自由自在的时间的，他让你填表的目的就是分析工作量，以便更加合理的压榨你。你敢不接受吗？ 
 
说正题，文档有很多种，我现在的开发是很详细的。但是，详细不意味着复杂，而是简洁。这里：简单-〉复杂-〉简单 的过程。给我的开发文档，没有太多东西，但是你想要的全有，而且特细致。如果你还不明白，接下来便是沟通了。 
 
我在学写文档，的确，我发现想写出一份好的文档非常难，没有一定经验和水平是无法写出好文档的，别指望你的秘书，新员工能做这个，一切动手自己试试就知道了。但是，一旦文档成型，你所获得的好处远远超过你的付出。再写别的文档的成本很低。 
 
在开发中，没有文档的约束，以我的经历来看，程序员往往会觉得老子天下第一。。。。最后一团糟。 
mach: 
文档只是用来管理和沟通的手段而已，真正重要的是隐藏在其背后的管理方法和开发过程。 
过分注重文档的重要性是盲目的，一个真正有效的开发过程要兼顾开发的规范性和团队的创造性，在这两个方向上走极端都是行不通的：没有规范会导致混乱，抹煞创造性会降低开发效率，最终的结果都是导致企业利润的降低。 
qingrun: 
同意mach兄的看法。 
但是，在我的感觉上，文档应该适合软件开发过程相匹配一种表现形式，管理和技术是一个层面的，文档和开发过程是第二个层面上的。 
我个人的看法如下： 
1、文档是记录软件开发过程的一种重要手段，她是基于软件开发过程的一个非常重要而且是必不可少的表现形式； 
2、文档与软件开发过程的关系就像项目中管理与技术的关系是十分类似的： 
以前有人争论过管理和技术哪个更重要的问题，在我看来：过于注重技术会造成开发过程的人为因素过重，失去了有效的项目可控性。而管理过重的时候，会造成技术人员很强的失落感，影响开发人员的士气，乃至于项目延期，无人愿意承担责任。 
而文档和软件开发过程也有类似的关系，过于注重文档，形式化太强，会造成大量的时间浪费，最终项目延期和经费的利用率降低等结果。而只注重过程忽视文档，则会造成项目失去了可控性，因为没有可以用于追踪的有效记录，也就无法检查项目的进展状况，造成项目的失败。 
3、文档应该注重实用，根据不同文档的用户来制定文档的内容，同时根据项目的不同调整文档的结构、数量、种类以及侧重面。 
目前只考虑到这么多，欢迎大家来参与！^&^ 
szfanke: 
我想这仍然是一个软件开发过程定义的问题，开发文档属于开发过程中的一个元素，过程定义好后，就应该严格的执行。而对开发文档的具体要求，我认为是有办法做到与开发效率不相冲突的。在软件开发的不同阶段做不同的工作，写不同的文档，可以更有效的记录工作的成果。 
 
为什么很多人觉得写文档烦锁且降低工作效率，我想和几个方面的因素有关： 
 
一是将文档编写作为一种任务集中起来写，没有分阶段的将文档作为一种工作成果及设计和开发的辅助工具。 
 
二是大多数开发人员照搬参考资料或其它的文档模板作为标准，却并没有理解哪些是要写的、哪些是不要写的或如何写，导致很多文档并没有起到实际的作用、很多章节没有实际的内容。我想文档模板应该根据自己项目的实际情况来定义，哪些文档需要写哪些不需要写，文档内包含哪些内容和章节都可以有所取舍，目的应该是做到言之有物，简洁明了的将所有问题说明清楚。 
zxl_l: 
很多人觉得写文档烦锁且降低工作效率,我认为主要是先已编码开发后补文档,文档并没有对系统开发起到实际的作用产生的。对于能给开发起到实际作用系统设计、分析文档谁都不会认为是多余的。 
arfayr: 
文档其实是一种客观的约束工具 
 
什么东西清清楚楚的写下来，才能够凝固下来，才能作为依据 
 
开发中的文档，真的很重要，一个管理的好的开发团队和一套好的文档格式 和套路是密不可分的 
 
谁愿意提供这些文档？嘿嘿，欧肯定第一个伸手 
 
目前所在的团队还达不到这一点 
spell: 
文档是设计者思路的书面化，是衡量设计者对系统了解深度的一个重要依据。 
试想，1.了解需求阶段：若在用户（客户）验证设计者所了解情况的正确性时，若无文栏预先交与客户，那要花多少时间去解说你的考察结果啊！再说了客户也没那么多时间去听设计都的长篇大论。 
2.设计阶段：若无详细的文档，向程序员当面讲解用去的时间要远远大于程序员自己阅读文档而只对其讲解不理解的部分用去的时间. 
3.维护阶段：维护人员不一定是设计者....... 
当然还有很多因缺少文档引起的不便，所以文档非常重要！！！ 
（欢迎批评） 
dreammaster: 
我个人对于文档与软件工程管理的一些看法： 
 
我认为软件工程的管理与文档是密不可分的，所以在软件项目初期的文档在管理中就显的更为重要，在我过去一个公司，每一步项目的进展，都包括着各种各样的文档的验收，及每个员工为自已工作证明的签字，文档是初期阶段的一些阶段性成果，有时会成为里程碑，后期也许代码中的文档量少了一些，但测试，用户手册也进入项目，文档是其管理的核心内容。 
 
我并不是想过度强调文档的作用，有良好的管理，才会有良好的文档，管理力度不够的话，文档出会变的象是例行公事，不能真正表现文档应该的作用。 
 
良好的代码规范是一个好程序员的必要求，有好的文档习惯，则程序员会长一个阶层，也许有人认为代码过于死，没必要如些，其实不然，软件也是产品，他有自身的规格与规范，你不遵守，则造出来的是一个不合格的产品，不合格当然不意味着不能用，有时电视外形稍有点小的话可能不会有什么影响，但却是这个规格电视的不合格产品. 
jnwen: 
1.文档一定要评审，要有人签字，有专人管理,要打印件，而不是电子版。 
2.软件要测试，测试人员一定要看文档。 
3.任何更改必须有更改通知单，有审批，没有就坚决不改。任何更改要有更改记录和补充测试，哪怕是一个数据的更改。(我经常被程序员要我出更改通知单搞得很恼火:)) 
4.进度要求不是不写文档的理由。如果来不及写文档和测试，那就不做更改。 
5.通过配置项管理，确保软件版本和文档要一致。任何更改要同时更改文档和程序，并有相关测试。 
6.每段程序、模块经过测试后固定下来后，放入管理库。在软件正式运行前，格式化硬盘，重新从管理库装入软件，而不是用现在硬盘上的软件，以保证不是开发版本，有些程序员很害怕这一点。文档也是如此。 
7.在一开始就明确在每个阶段应该出的文档，作为评审前的必要条件。一开始就给出文档的标志和编号。 
ablg123: 
不错，真不错，我看到了中国软件行业的星星之火。 
 
　　有人为了文档而文档，这算什么，我见过把系统分析和设计当作“用rose画图”这样简单的事。 
　　我认为具体问题应该针对特定情况具体分析，微软的文档不要求写得很细，这样能充分发挥程序员的聪明才智，不过前提是“微软的程序员都是训练有数的绝顶高手”。 
　　如果前提条件不一样，没钱聘请高水平的程序员或管理上不完善，没有能力留住高水平的程序员，或不能提供条件让高水平的程序员充分发挥才能，只有一些没有创造力的程序员或对开发软件的知识掌握得不是很好，不知道什么样的软件该怎么做的人，项目必然会一团糟。 
 
　　对于类似于体力劳动的工作相对脑力劳动来说，必须加强监督，否则资本家的利益就会受影响。而脑力劳动除了监督之外，更多的则是调动员工的积极性，这是对待高级员工和象"coder"一样的人的区别。 
 
　　“生活依旧像在如磐的黑夜中航行，所以，依旧俯身划浆”，让我们共同为中国软件行业的崛起而努力！！！ 
ckwangfg: 
看了软件管理和软件开发文档的讨论茅舍顿开！！！ 
我们公司做开发的只有几个人，所做的项目基本上是比较小的,以前的管理全部是通过口头交流,所谓的软件管理只不过是开发人员随手将程序的一些要点做一些记录．一旦公司的核心开发人员离开以后，由于没有相关的开发文档，整个项目就将搁浅和延误。 
我现在致力于建立公司的软件管理规范和各种技术文档规范，结合公司的实际情况，不可能完全采用某个标准。整个过程要充分考虑到规范的实用性和可操作性，我没有这个方面的实际工作经验，希望得到大家的帮助，和大家进行深入的交流。 
MY Email:ckwangfg@21cn.com 
mobbs: 
不到万不得已，我是不要求团队成员写文档的，实在烦人。 
但是 
1. 在需求阶段，我要求有详细的use case和activity diagram。 
2. 在设计阶段，我要求有详细的activity diagram，sequence diagram和class diagram。 
3. 对测试（之所以不说测试阶段，是因为我要求Test和Code同步），要求有测试用例（足够了）。 
4. 对Coding，多写注释。 
其它的文档，不写也罢。人手不够，没办法。 
taopi2001: 
所谓文档可以说是将程序员心里的想法用文字表达出来，将抽象的思想具体化，其过程也是程序员本身对于自己所作工程的理解上的一个深入。要说这种工作其实不一定要专职的文秘来做，一般程序员也是可以胜任的。当然，作程序员的文科功底一般好像都不怎么样，不过其实经过一段时间的训练，是没有问题的。学写文档对于增强自身思维的条理性、逻辑性、整体把握能力等都很有帮助。 
说到编程和写文档，就让我想到了在大学本科生中参加过的全国数学建模竞赛。我国的数模竞赛现在已经是大学生中规模最大的竞赛了。三人一个小组，标准的分工是一人负责总体思想，如模型的总体结构、算法、采用方案等，一人负责编程，第三人负责论文的写作。其宗旨在于创新和团队精神。但是光靠这两点是不可能获得全国大奖的。要评选靠的是论文的水平。有的论文其中的建模和算法其实一般（相比较其他论文），但是写作上很有特色，遣词造句非常得当，涉及专业的地方运用专业的术语及思维方式来阐述，让该领域的专家也认为有一定的专业深度，而另一方面，又要注重尽量避免用生硬、绕口的词句，凡是涉及专业的地方，都尽量用通俗易懂的话进行解释，这样即使是一般大学生不用很费劲也能看懂。另外还要从论文的整体架构上考虑，内容的选取，表达的方式、顺序，采用的口吻，行文的特色，格式的规范等。而精 
确时，对于每一个词字都要斟酌好久，完全的从读者的角度考虑，来写好论文。 
当然数模的关键还是在于创新，要有其闪光点的论文才能有机会被选出来，而与同等深度的论文比较时，就是看写作的功底了。不过这是题外话，:)。 
我刚开始学习UML，也说不出什么专业的东西，只能就自己的一些经历谈谈。写这些的目的在于——写一篇好的文档并不是一件容易的事，需要一定的专业素质和文学修养，但我相信一般程序员经过正规的训练是完全可以办到的。 
以上一点拙见，仅供参考。 
TechSupport: 
我们应当区分两种文档： 
 
1。纯粹内部技术文档： 开发工作本身需要。 开发者写草稿(VISIO)，制作(排版， 
内部技术部门主页，POWER POINT 演示制作。。。)交文秘人员完成 。 
 
2。外部用户文档：用户使用手册，培训教程等，这类文档要求与开发人员思维完全 
不同，让开发人员自己写不符合软件工程要求，免于其难 。让文档人员(文科中文， 
外文毕业)以用户角色理解后完成更合适。专业人员只需校对。 
 
可惜国内不少公司还是让开发人员一手承担软件全部文档。 
 
目的： 开发人员------文档人员-------文秘 。精明的老板知道让开发人员承当文 
档人员和文秘的工作是多么浪费。 
tianxinet: 
高质量的文档对项目管理非常有益，PM可合理的明确开发流程中各阶段的时间节点，籍此改善对软件开发过程的控制，比如里程碑的检查、Release时程等。 
同意“不能为了文档而文档”。其实具体到一个项目，高素质的PM、RD、QA（良好的技术素质、清晰的思路、协作意识）并不需要太多的文档来规范，也能较好的保证开发时程和品质。但不能期望每一个参与开发人员都具备很好的素质，这时文档很必要。 
当然，从管理的角度出发，任何情况下文档都是必要的。 
yangzhenhai: 
收获很多,我一开始是在香港一家公司打工,文档是从香港发传真过来,很清楚. 
我做了快一年,才知道项目是给谁用的,但是发过去的程序不用测试就直接给客户用.以后就再也没有这种好事了,没一家公司正规的写文档,写也是八股. 
有没有好的文档格式共享一下,我知道格式是个形式,不过有时考虑不全,可以提示以下.反正形式和内容也不矛盾!