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:[email protected]
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:
收穫很多,我一開始是在香港一家公司打工,文檔是從香港發傳真過來,很清楚.
我做了快一年,才知道項目是給誰用的,但是發過去的程序不用測試就直接給客戶用.以後就再也沒有這種好事了,沒一家公司正規的寫文檔,寫也是八股.
有沒有好的文檔格式共享一下,我知道格式是個形式,不過有時考慮不全,可以提示以下.反正形式和內容也不矛盾!
觀點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:[email protected]
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:
收穫很多,我一開始是在香港一家公司打工,文檔是從香港發傳真過來,很清楚.
我做了快一年,才知道項目是給誰用的,但是發過去的程序不用測試就直接給客戶用.以後就再也沒有這種好事了,沒一家公司正規的寫文檔,寫也是八股.
有沒有好的文檔格式共享一下,我知道格式是個形式,不過有時考慮不全,可以提示以下.反正形式和內容也不矛盾!
