這樣做真的正確嗎？

在以前那家公司的時候也是，現在這家公司也是。

使用者手冊之類直接面向客戶的資料，總是作為項目中每個程式員在趕進度的同時隨隨便便弄出來應付任務的工作副產品，的集合。

我來說說我作為一個程式員的切身體會吧……

每次項目開始，其實我總是把精力集中在編碼實現和測試上，在這之前分一部分在設計上（儘管很可能是拙劣的設計）。我最關心的是如何按照需求實現出來，並且盡量少出bug。做完這一步，其實人就已經鬆懈下來了。寫個什麼東西給使用者看這樣的事，總覺得提不起勁頭去做。
究其原因：
1. 思維從程式員轉變到使用者的障礙——我現在是使用者了，我希望看到什麼樣的使用說明書？或者儘管我不清楚我想要什麼，但至少清楚我不喜歡什麼樣的說明書？
　　 聽起來很不錯的主意，但實際上自己知道是騙自己的。總覺得應該有更好的辦法。
2. 出於項目進度的考慮——有這份時間的話，我作為一個程式員，是不是可以用到檢查bug，或者試圖加入一點新的特性來讓程式更易用、看上去效果更好？

總結起來的話，就是覺得自己分內的事情是把程式做好，如何寫一份通俗易懂的使用者手冊並非自己的核心職責，是附帶的任務，不得不完成的。

這還沒算上每個人的語言風格、思路都不太一樣的情況下寫出的東西最後整合後讀起來是個什麼感覺……

舉個實際的例子，就是泛微。老實說，他們的使用者手冊，我讀起來感覺不順暢不說，還常發現很多錯別字。
再舉個例子，我一個大學同學，在中石油底下的一家軟體公司工作，他們常年在做全國各地的石油企業的ERP項目。聽起來很牛B很專業吧？那麼使用者文檔怎麼樣？不怎麼樣，他發給我，我看過。真的不怎麼樣。word文檔寫的，格式什麼的慘不忍睹，我甚至懷疑他們的客戶企業實際用的話會不會有人真的去查它。

這方面我覺得日本一些電視遊戲公司做的很好。CAPCOM, KONAMI, KOEI， 買到他們的遊戲，我開啟封裝，看說明書時那種感覺，沒買過遊戲，沒認真看過，是不會理解得把。

Anyway, my point is:
反觀實際，相當大部分由程式員製作的使用者手冊品質並不高。
有專人負責的使用者手冊品質一般還不錯。