軟體開發過程的重要性分類：管理

上週我們討論軟體開發的知識庫，大家反應的意見很多，我也深深地感覺到現在軟體業在開發的過程因為人力及時間的不足，所以經常日夜趕工，而造成非常多的惡性循環，這一次我們討論軟體開發的過程經常性會發生的錯誤，這些錯誤有必要讓各單位能充分的了解並互相配合。

一般在軟體系統開發最重要的就是開發的過程，我提出三點最重要的相關過程，不但是經理人每日要提醒自己的，也是程式開發者避免要犯的錯誤，第一是不紮實的系統規劃，第二是日夜趕工的開發方式，第三是品質確認。

不紮實的系統規劃：系統分析師往往是由資深的程式設計師來擔任，往往一個案子在開始開發之前，要經過需求分析、建構雛形、客戶訪談......，這些過程是不能被省略的，這些系統分析師或是專案負責人，往往會忽略掉這些重要的過程，而跳到直接撰寫程式的錯誤結果，如果我們無法在一開始的五個小時就做好先期的規劃與設計工作，未來可能會花五十個小時來彌補。

日夜趕工的開發：有一些公司有短期趕工方式來快速的建構核心及雛形，他們認為如果讓開發人員有足夠的動機，他們就可以克服任何困難，完成系統開發的工作，但是這種快速短期開發的過程往往不符合市場或者是客戶的需要，除非在日夜趕工之出就能規劃出目標來，不然往往會趕出一個短期不成熟的產品。

品質確認：在一個匆忙的專案最會省略的就是設計與程式碼的審查確認，只做表面性的測試，這一點大家總認為只要把這一些工作交給測試單位就完成了，但是測試單位知道程式碼在哪裡？他知道所有的設計細節嗎？這也是兩個單位溝通最多的地方，而不是只是把成品丟給測試單位，然後設計與測試兩個單位就開始反反覆覆的皮球丟來丟去，所以品質的確認不但要做到系統模組設計的確認，也要做到程式碼的審查。

上述的三點是我認為程式開發重要的三項工作，也是最容易忽略的三個過程，系統開發者最自負的也是這三個過程，但是這三個過程並非在自己的腦中流過，而是在一個團隊中確認的過程。

建立軟體開發的知識庫分類：管理

現在的企業非常重視學習與成長的環境，這兩個月有關企業知識庫的建立有很多的書籍及雜誌都在討論，但是至於如何建立知識庫的方法，往往過於概念性或者是針對大企業在討論......

軟體開發的領域中有很多文件化的分析方式，例如從最早的資料庫系統(Dbase)就把資料表，輸出表格，輸入表單做了做標準化的規格建置，讓系統的開發過程中的溝通，可以很容易的透過開發工具本身完成，而早期的結構化分析方式，也是強調要利用功能性的需求來分析一整套的系統，分析完成後只要照著表格來寫程式(Coding)，就可以完成，但是這些方式往往因為要有相當經驗的系統分析師來作業，開發時程況日費時，經常做出不可操作的系統。

所以現在的開發工具強調即視性(Visual)與物件導向，利用雛形法來減少開發錯誤的流程(但是不一定可以快速的開發)，而開發的過程中就一定要分階段的檢討模組的適當性與合理性，不斷地修正，而這個修正也是知識的累積，所以最好能把這些開發的過程分門別類，整理後隨時輸入一個大的資料庫，這個資料庫以傳統的二維的欄位(專案名稱、功能分類)已經達不到檢索的需要，因為不是資料量太大，就是找不到資料，所以我建議以增加一個使用的模型分類，例如是網路上的通訊協定，作業系統檔案，作業系統多工等等，用系統模型來建立這個資料庫的Index，可以有效的縮小檢索的範圍，也可以跨越不同的專案來學習相關的知識，但是這個Index很重要的是要隨時間來改變，要經常性的討論修正。

如果學習型組織擅長創造、取得、傳遞知識，而做達成這個目的就必須配合這些新的知識和見解而改變行為，我們建立的這個Index就是這個行為。

同樣的，如果沒有配合調整工作的方式，這些新的Index就只是創造了改變的可能性，而非真正造成改變。

用最簡單的方法分類：創新

開發軟體系統經常會有沉重的包袱，就是要維護以前的系統，所以我們的思考方式經常會被限制住，久而久之就會用舊的方法來解決新的問題，有時候會事倍功半，用最簡單最笨的方法有時後也是最好最具創意的做法，所以常常把自己的頭腦規零，有一定的好處喔!

舉一個簡單的例子，通常我們寫很多機房傳遞訊息的程式都想到就是用Socket來傳遞，然後用資料庫來記錄傳遞的訊息或是過程，光光這兩個包袱，我們就要先寫Client/Server的程式兩支，然後在設法要利用ODBC取出資料庫的資料然後傳給Server，中間牽扯非常多的關卡，如果有任何一個關卡出現了問題，整件事情就是失敗的設計，雖然這個系統的時效性及架構非常的好!

如果上面的例子是每日的批次作業的話，我們可以考慮用文字檔案的模式，產生要發送的訊息，然後透過FTP Server或者EMail Server來傳遞資料，雖然時效性不是最好，但是都是用現成的系統來傳遞訊息，只要系統夠穩定，應該是最快也是最好的解決方式，但是同時解決傳遞訊息的問題時，我們要考量的不只是程式設計或系統分析的方便性，還要全面考量到其他單位的系統維護操作，客戶服務或者甚至客戶本身是否會有影響到操作的問題。

現階段的軟體開發工具非常的多，程式設計師的困擾應該是在開發工具的熟悉度，我們應該利用開放的心胸各方面去學習，DOS的批次檔執行編寫也可以解決很多很多的問題，現在電腦應用系統，已經不一定限制在Windows 的作業平台了，學習任何一種電腦程式語言，一定要了解並且多方運用，有時候你會發現為什麼10分鐘可以完成的事情，以前的人要用10小時做完，只要有充分的理由，最笨的做法是有時候是解決問題最好的方法，您隨時要有革命的創新理念。

一個系統最有價值的地方我們通常是看的不清楚，現在流行成立新的網站，成立之初只要把同類型的網站複製一份過來即可，但是要成功的經營，一定要持續不斷地在核心技術以及自己的價值鏈上提昇競爭能力，簡單地突出自己的地位是很好的做法喔!

心智分枝圖分類：創新

有時候經常會忘東忘西的，跟朋友聊天也會時常忘記重要的關鍵，這個時候應該是應用分類的方式來記憶與創造一些新的思考方向，最近也因為工作的關係，回去看看別人寫過的程式，感覺獲益不少，雖然已經了解其中的運作過程，但是，所謂溫故知新可能就是這個道理吧！

於是今日把創意FORMAT(Business Beyond The Box)這本書拿出來研讀，再研究一下如何創意思考，其中有一個方法就是心智分枝圖，把問題寫在一張紙的中央，並且畫了一個圓圈，然後想一些分類的方式畫出分支，然後從這些分支中找出答案，這個方法雖然天馬行空，但是是很好找出這個問題的解答，或是相關的話題。

人的思考方式，思緒經常是變換不定的，由直線的思考方式來看，這種分支方式的思考模式有更大的空間，但不至於把討論的主題拋開，可以有效的拉回來，當我們開始思考的時候一個念頭會觸發另一個念頭，這種思考的模式有助於思緒的組織性與結構性，當你的腦海中有一些具體事件或是關聯的圖像的時候，都可以很快的畫在紙上，並且有效的作一些分類。

以前寫程式總是先在紙上或是心理構思完成後才開始動手寫，但是經常發現，寫出來的東西擴充性很差，不然就是錯誤一大堆，一直補東補西的修改，結果就認為這個系統是一個大怪獸，物件導向的程式語言的語法雖然避免掉了一些我們常犯的錯誤，所以應用這種心智分支的思考模式，可以預先把所有的問題先找出來，並想出良好分類的方式。

我們時常會落入自己工作習慣領域的迷思，總覺得自己是很重要的，透過這個簡單的訓練，或許也可以想想每一個人在分工合作的重要性。