軟體專案中可再利用的東西很多，不只是程式碼。它們有：SRS、SDD、WBS、產品結構與型態項目、測試個案、時程綱路圖、各種計畫，還有軟體度量與估計…。其實就是組織裡所有以往的工作結果，都可以再利用。其實組織訂定的過程、生命週期模型無一不是再利用過去的東西。甚至所謂的“專業分工”也都是“再利用”，它再利用“人”過去的經驗。

當然任何東西在“再利用”之前，首要條件是要把它做出來啦！。當我們在軟體專案中沒有可資再利用的東西，就問問我們自己：過去我們有真正地完成軟體工作嗎？過去我們真地把需求分析做完了嗎？軟體設計做完了嗎？專案管理計畫書完成了嗎？型態識別我們做完了嗎？測試文件與異常問題報告呢？…

可憐啦，什麼都沒有。有的盡是一些自欺欺人，唬人的垃圾。

以前不知也就罷了，現在知道了，還不回頭就…。不講了，真誠地

祝福大家 都有 金不換！

周茂松 敬上

我們是小公司,小到常態編制剩我一人,程式也都賣不到百萬等級,我也不是資訊管理出身,所以看不懂SRS、SDD、WBS、等專業名詞,但我深切知道reuse重用的重要性,因為平常都是在接專案,如果做過的東西沒有提升reuse的百分率,那每個專案可能就會變成每個坑,所以不同的系統,像會計,進銷存,公務薪資,貿易等不同體值的系統,仍然可以做到90以上的重用率,意思是不同系統有90%相同的程式庫,只有少數差異才需編寫個別的程式庫,所以完成不同類型新專案速度就會很快.而且主系統也很小.因為系統完成快,所以就有必較多的時間整理文件.

我們是將幾乎全部的商業邏輯都以存到資料庫的方法來處理系統,因為是資料庫而不是程式庫,所以可以編寫維護資料庫的方式來為維護系統邏輯.大部分客戶要擴充或修改商業邏輯的場合,只需打開文件,加以編修即可符合客戶所需.

文件除商業邏輯以外,個別專案的function,UI介面,database table,stored procedure等資料也可自動匯入,這些都必須進行管理,系統才會透明化.主要目的是方便後勤與交接,不然要回想過去做過的事,或看同伴走過的痕跡都會很辛苦.另外系統文件多了,未來也有機會變成業務用文件.

我們也建立後勤網,個人認定這也是文件之一,將客戶的原始需求post到論壇,分析與解決過程也記錄起來,就可以有系統的管理專案細節.同時等著有機會時交接給新人.

想招兼職文件人員,幾次登老半天都無人響應,而招募過的員工,不管全職或兼職,要求他們依論壇公告標準化程序行事,都還是有困難,包含UI排定規則,資料欄位命名規則等,都像青年守則一樣只被用來喊喊而已,我想原因可能是大部分員工都喜貪圖方便,並與不認同文件重要性有關,畢竟要體會出文件與自己的切身關係很難,加上平常無書寫文件習慣,要將思考的內容表達成文字都變成困難重重.這跟他們進來前滿口答應可以配合寫文件,登論壇,再驗證其表現,我想文件的本質與付出都超出他們所能預想空間與能力範圍之外了.程式可以一天產出一千列,但說明文字卻寫不出來,最後伏留下一千列的盲點.


所以我的文件幾乎都我自己在看,流程圖也自己在畫,說明也自己在打,不錯,在這邊看到有人認同文件重要性.雖然文件的內容與對象跟我做的可能不一樣.
我的文件網與後勤網,歡迎大家有空時光臨.

寫文件不能找兼職的人員，而且需要受過相關的訓練，寫需求文件、設計文件、使用者手冊、維護技術手冊，各有不同的側重與技巧，因為這些文件的閱讀者都不相同，他們的技術背景也不同，所以就算要找兼職的人，找工讀生絕對是行不通的。

規定與要求要能夠落實，其實需要審查、稽核及教育訓練，甚至於獎懲制度的配合，才能進而形成習慣及文件，這個部分又需要管理者的管理技巧了。

文件在短期看不到被使用的需求，因為不會被詳實製作與及時維護，久而久之，當文件使用的需求發生時，卻又發現文件與產品不一致，這種情況，又需要建立嚴謹之組態管理才能進一步解決了，以定期的組態稽核確保文件與產品的持續一致，才能在最需要(需求變更、軟體功能提升等情況)的時候，提供最正確、完整、一致的相關資訊。

----------------
引文: