在新崗位工作的這段期間其實讓我的工作模式改變的跟之前截 然不同
以前在某補習班當 IT 以及 遊戲公司當 RD 的時候...每每開始一個程式或是架構變更專案的開始都只是簡單的規劃
通常不會很詳細的去進行 SA & SD ，有的話也大概就只是很簡單的幾張 Paper 而已 (意思紀錄一下的感覺 Orz)
在新崗位工作的這段期間其實讓我的工作模式改變的跟之前截 然不同。以前在某補習班當 IT 以及 遊戲公司當 RD 的時候...每每開始一個程式或是架構變更專案的開始都只是簡單的規劃，通常不會很詳細的去進行 SA & SD ，有的話也大概就只是很簡單的幾張 Paper 而已 (意思紀錄一下的感覺 Orz)
這可能跟台灣的資訊環境有關係吧，當我開始要寫第一份「完整又詳細」的 SA 時，心裡真的有錯愕以及碎碎唸了一下：「寫程式都沒時間了還要用這種 SA 啊！還有 SD ～那程式寫的時間呢？」。正當不知道如何撰寫的時候，撰寫文件非常有經驗的專案經理 **豪哥** 親自指導我，以下是我們的對話 --
================= 對話分隔線開始 =================
豪：「SA主要是給 User 看的文件，每一個介面都要解說，功能欄位也都要詳細說明，尤其是下拉選單，裡面的選項也都要一一列出。」
才剛開始聽到我就已經六神無主了...一向是 IT 與 RD 的我要撰寫的這樣的 Document 會吐血吧@@，但他又追加的跟我說了一個更重要的觀念
豪：「SA的用意除了要給user看以外，其實最重要的是在系統開始進行開發之前可以避免細節的地方遺漏了，例如說：今天你設計的DB欄位有五個，如果突然想到一個功能的時候，以前的作法都是直接在DB插入一個新欄位，那程式是不是都要改過了呢？」
我：「對啊！以前在撰寫的過之中，總會突然想到一兩個 idea！但是 DB 又必須新增欄位，老實說，應用程式小還 OK 啦！但是大的話...我有改兩個 DB 欄位改快一小時的經驗」
想起以前撰寫程式的時候，通常都是馬上動手，並沒有經過縝密的規劃就寫，當一個功能寫完了以後回頭審視就會發現「這裡似乎加這一個功能也不錯」的想法浮上心頭。好吧...在加入一個功能吧..這時候的作業程序為：
-
進入 SQL 管理界面
-
對要修改的資料表插入一個欄位
-
修改程式，將 SQL 相關的程式修改語法
-
進行測試
以上這四個步驟是想到一個功能的時候所必須做的流程，程式的規模小就算了，如果遇到相關page很多的程式...慢慢改吧，人力與時間就浪費在上面了 = =a
豪：「所以寧可多花一些時間規劃一番，也不要後面在浪費人力修改 ^_^」
我：「那這樣說來，網路設備中附上的說明書或是 PDF 的User Guide也可以說是 SA 文件嗎？」
豪：「那可以說是 SA 了啊~ 只是比較沒那麼詳細而已，但是拿他們來作入門藍本其實是 OK 的啦~」
我：「感謝指導！我知道怎麼開始了 ^^y~ Thanks~」
================= 對話分隔線結束 =================
經過這一次撰寫 SA 之後，我發現有以下的好處：
-
可以仔細審視 UI 的排列與設計，不用等到事後在修改
-
可以將功能性完整的考量到，將使用者以及系統功能寫的更完善
-
不用在浪費時間作新增欄位與修改程式這種浪費時間的功夫
-
以後系統要修改的時候，不用仔細拼命的思考以前事怎麼寫的
-
接手系統的人相對的也輕鬆
-
節省教育訓練的時間
可見不管是 IT or RD ，事前規劃與分析都是很重要的，也許寫文件事很枯燥又乏味的事情，但是依照文件的制定來進行，會比後面要花更多時間修補還要來的更值得！除了系統 & IT架構的規劃要良好以外，你的人生是否也有了良好的規劃了呢 ^^b ？
P.S (非廣告)可以參考一下 Vigor (居易) 設備的說明書，針對介面他們都有詳細的說明，想入門 SA 或是不知道 SA 意義的可以參考看看~記得！！！！是參考，不是說該文件就是 SA 唷！