每次碰到跟合作廠商談我們的產品的時候，他們總會想比較產品的功能比較表，然後依照功能的多少來評比要投入的行銷資源。
目前我們的數位產品並不是一個成熟穩定的市場，如果拿功能多少來比較一個產品的好壞，似乎不是很準確的，其實經常拿 google 來比較，他推的服務也是很多，可是每一項服務都很擊中需求的，而功能都是最陽春最簡單。即使現在還不知道 google 未來的發展會怎樣，還是另一個泡沫化，但是化繁為簡的產品的確功能列出來都是最少的。
如果要比較功能，以上化繁為簡，可以說明為＂沒有繁雜的功能＂，好像說這個人唯一的缺點就是沒有缺的一樣的白痴。
為什麼大品牌都有獨特的魅力，就是知道什麼是客戶要的，而什麼是客戶不要的也是很重要。
最近在分配工作順序及進度的時候，發現我自己把有些工作分的太細，步驟分的太過繁複，導致大家覺得我很囉說。
系統分析做到多細才是好呢？描細的太完整，程式設計師寫起來固然輕鬆，可是有些在系統中不不是很重點的事情，會被分配到太多工時，反而忘記了重點。我們經常會聽到程式設計師說系統分析師完全不了解寫程式，但系統分析師就會罵程式設計師完全不懂客戶的需求。
其實，這兩個角色一直在我心裡面是一個很大的衝突，目前工作不會分工的那麼細，一方面要寫程式，一方面又要重視到客戶的需求，可是要花多少資源完成，全部都是一念之間。
我想目前為止，好像沒有一家軟體公司能同時做好專案的開發，又能做好產品的開發，因為這兩個軟體系統的核心技術與管理方式，是完全不一樣的，除非這專案與產品這兩個部門是分的很開的。
記得我進入第一家軟體資訊服務公司的時候，第一個考題就是這個問題，專案與產品的特性有何不同，現在想起來這個答案還真的很廣，以下是全球麥肯錫軟體調查的分析比較：
專案服務 軟體產品
複製成本 固定 趨近零
開發方式 分工開發 集中開發
地理特性 區域性 全球化
客戶關係 一對一 一對多
管理重點 1.人力資源 1.策略
2.技術研發 2.行銷業務
3.行銷業務 3.人力資源
4.策略 4.技術研發
如果依照這個分析表來看，專案型的軟體公司的核心技術必須非常重視人力資源的運用，而技術研發也是非常非常重要的，以國內的專案服務來看，雖然成交的金額非常大，但是一個系統經常要把軟硬體甚至維護服務通包，所以經常是很多公司分工處理，有時候可能得標的是外國的廠商，但是在系統上線或者系統維護的階段，其實已經轉包給其他的廠商了，而廠商間的相互聯繫支援並沒有很好的情況下，要結掉一個案子通常況日費時，導致成本上無形的損失。
也因為如此，專案服務的軟體開發公司通常非常的區域化，即使是像惠普、IBM這一類的公司，在世界各國分公司的專案管理也非常的本土化，無法全球化統一管理，經常有人說他們可以利用印度的人來寫程式，用美國公司來保證品質來接專案，我想這個是天方夜譚，不可能成功的，除非是產品型的軟體公司才能達成。
目前軟體產品來看，微軟的確在全球佔有數量最大的作業系統的佔有率，產品型的軟體公司可以透過行銷與策略來打擊對手，只要能夠把佔有率提高，就是產品型軟體公司的成功。
而最近兩年網際網路的發展，除了專案型與產品型的定義被打的模糊之外，大家對於客戶關係管理也愈來愈重視﹔ＡＳＰ的服務營業關係目前是定義在Ｂ２Ｂ的交易之中沒有錯，但是你接的案子是專案的ＡＳＰ還是產品的ＡＳＰ，是一家公司營運核心能力重要的判斷依據，我經常看到很多人分不清楚，就開始作ＡＳＰ的服務，導致目標不明確而失敗。
而客戶關係管理所投入的資源重要的是客戶的數量級與忠誠度的判斷，如果是專案服務，每一個新的專案就是一次的客戶關係的建立，要投入很大的行銷資源去經營，大體來說是不對的。
其實，所有的產業都是垂直結合的，而軟體公司的分類除了先用專案型與產品型分類之外，各行各業運作的情況真的不一樣，而軟體從業人員用程式語言或開發平台來分類，其實是非常不對的。
一般的軟體系統專案大部分會分為系統開發與系統維護不同的合約，所以開發期與維護期界定的很清楚，面對的問題與人更有不同，但是一個公司的產品是否在維護期或是開發期的界定，就沒有那麼的清楚，如果公司大一點，部門一多，要讓每一個清楚知道產品的開發階段，才能做好客戶的服務。
如果單純的從研發部門來看一個產品的生命週期，對投入這個產品的人，花費的力氣重心程度而言，是非常的不公平的。舉例來說，一個軟體系統如果他的生命週期是五年，前一年可能都在開發沒有任何業績，第二年開始有業績而且客戶的需求不斷，第三年的需求可能不多但是客戶要求降價賣出的數目也有比較多，第四年開始衰退想任何新的點子都無法拉高業績，第五年每多賣一套就要多賠一點錢。
以上面這種產品的生命週期來講，研發人員每一年投入的心力幾乎都一樣大，但是成就感只有在第二年而已，這時候就必須調整自己對於這個系統投注的心態，或者賦予這個產品新的生命。看看是要改變客戶群，調整新功能的開發，限制系統的大小，節省維護的成本......。
系統維護在一個大公司應該算是不小的成本，要如何把系統維護的成本降到最低，是一個系統開發的時候重要的課題，不要因為不同的客戶要求而把產品的架構弄亂了章法，這個是產品開發的最高原則。
就心態上而言，一個長期在開發新產品的研發人員，面對自己一手帶大的產品萎縮，總希望賦予更多的新生命，給他更長的生命週期。但是，如果客戶只能掏出一塊錢來買的話，你投入兩塊錢的資源就是賠錢，這時候研發人員就要開發不同市場不同產品線了。
而開發不同的產品，對研發人員來講就是全部重頭來過，平台、開發工具、系統架構會完全的不同，不能用以前的架構套在新的產品上面，壓力似乎非常的大，而這時候面對舊客戶的要求又要應付，因此很多研發人員在這個時候萌生退意，想想既然已經是全部重來了，乾脆換一個新跑道。
所謂『創業為艱、守成不易』這一句話是合起來講的，要同時守好舊產品的收尾工作，又要開發新產品，當然非常的不容易。我經常在與研發人員面談的時候，他們經常會講自己多麼厲害又開發了什麼架構什麼產品，但是問到為什麼要離開那個產品的時候，他們給我的感覺就是沒有成就感，無法發揮新技術......。
了解一個產品的生命週期，用不同的心態去面對，是非常重要的。
不可否認的軟體開發的程式設計師流動率很高，我想這個是全世界作系統程式開發人員供需不平衡所致，而台灣很多軟體公司因為一個高手離職，往往導致開發的時程受到很大的影響。
要如何解決這個問題呢？大部分想到的就是做好系統分析的文件，補足在開發過程修改的紀錄，而公家機關的做法往往是要求列印原始程式碼，但是我認為這個只是消極的做法，我想一個維護系統的公司倒閉，要較另一家公司接手，也是曠日費時。
最近看到微軟在宣傳新的平台，仔細地看清楚文件，原來這些都是兩年前的訂下的規格，目前只是重新包裝出來行銷而已（當然微軟也放棄掉很多自己訂的規格），而這兩年的期間我相信參與新平台的系統開發人員一定也是一直有更替，他們是如何延續當時的理想的呢？
我想有一個遠大的目標是不夠的，強制找出所有的系統模組的規則，並且認真的去討論內容，而且是讓每一個開發人員都了解為什麼要這樣做？不斷地演進我想這一句話說的容易但是做起來很難，光光開出一個規格一個模組就很難能讓所有的開發人員的意見相左了，還要去挖出對每一個模組要求的效率及通訊規格的一制性。
一個大的模組可能是一個人開發，但是大的模組裡面又有小的模組，比較難的是要求小模組之間的應用的正確性，人往往會有惰性，總覺得只要把要求的模組開發完成就好了，不管模組內部未來發展及維護的問題，我想即使是一個人開發，也是要依照上面的原則去思考系統的架構的。
而一個系統總是有歷史的軌跡的，面對一個新接手系統的人，一定要想辦法完全了解所有模組，為什麼要這樣子作？什麼模組是因為以前的電腦處理速度問題所做的最佳化？什麼模組是因為客戶專業性的重要需求所做的處理，我們往往會用現在的眼光去判斷以前的系統多麼不何時宜，系統架構多麼不好維護，但是總是沒有看到一個舊系統如何滿足客戶的需求及功能強大的優點。
系統開發不是水平分工的行業，如果光是靠資料庫就可以達成，或是靠建立一個網站就可以做好的話，這樣的進入門檻很低，也很容易在競爭的環境下被淘汰。所以，延續一個系統的強韌及不斷地開發是軟體開發人員先要了解的課題。
重要的技術有時候可以發展出一個個元件，賣給系統整合的廠商，例如網路上認證加密的技術、信用卡扣款認證的技術、網站的瀏覽客戶群的分析、防火牆的元件，以上種種的重要技術如果要一家軟體系統全部一次開發完成，非常的耗時間而且經常不能達到經濟規模，造成後續維護上的困難。我們從系統整合廠商以及製造軟體元件的軟體公司兩個角度來分析，如何達成元件整合的重要條件。
從系統整合廠商來看
應用元件來整合系統可以節省開發的時程、節省成本，而把人力應用在本身的核心技術與客戶需求的互動上面，但是缺點就是對於元件的應用是否完全符合系統的需求，這個元件未來的發展，還有元件供應商是否有完整而足夠的支援，更重要的是應用了這個元件會不會讓你自己的系統的核心競爭能力減弱、或者是提高，都要表列一個檢核表，千萬不要因為一時的貪快造成未來後續的開發的困擾。
我們已最簡單的Windows應用程式開發為例子，如果你的專案是一直不斷地換版的專案，不是一個會停止的專案，那麼在程式的介面上最好不要選擇你無法控制的程式庫(DLL,OCX)，因為作業系統一直不斷的開發，這種元件的相容性受到很大的挑戰，而原先的元件軟體廠商因為市場不夠大無法維護的時候，造成更大的困擾。
從開發元件的軟體廠商來看
製作一個元件非常的簡單，但是要廣泛的應用在所有的系統上，必須就要開放非常多的介面，這些介面同時又不能把核心的技術完全暴露出來，所以，介面的訂立非常的重要，而實用性更是重要，往往做的程式碼比特定需求的程式碼要多上五至六倍。
現在因為寬頻網路的盛行，帶給了元件廠商的另一個契機，就是可以把重要性的技術放在伺服器上面，利用遠端的管理方式，管理您開發的元件，或是遠端的換版，甚至做安全性的認證。
以往元件廠商的營收被侵蝕掉往往就是後續的維護包袱太大，所以很難有完整的發展，開發工具所附的元件如果沒有含原始程式碼，無法符合後續發展的彈性。網路時代，元件或許是一個值得投資的開發模式，目前的網路認證、網路調查、代發電子郵件，都是這一類的模式。
我們往往聽到很多的策略結盟的新聞，也有在賣場看到兩樣產品合在一起賣的比較便宜的案例，這些都不是軟體系統的整合，更談不上未來，只是為了提高產品的銷售量的一種手段而已，真正的產品或是系統的整合型態，主要可以分為三種，一是上下游的產品資料的垂直整合，二是系統介面的平行整合，三是重要模組的分工整合。
系統介面的平行整合
在十年前談到兩個系統的介面整合簡直是不可能的事情，都要透過前一種方式，垂直整合來達成，但是在現在作業系統的發展以及網路通訊規格的統一化，技術上已經沒有任何的困難，甚至還非常的方便整合，剩下來的問題就是兩個系統在整合上面政治策略的考量罷了。
最簡單地平行整合方式就是用不同的執行檔在同一個作業系統下執行，各有不同的執行檔，以及各自獨立的資料庫或資料檔案，而為了讓作業人員方便在兩個系統中間必須連接的功能，做一些介面或是功能上的連結即可，而這一類的整合如果是大眾化低消費的系統必須考量的除了功能的順暢之外，還有介面操作的一致性，甚至字型、對話窗的編排設計都要做完整的考量。
最好的例子就是我們常用的ICQ通訊軟體，大家可能在使用上沒有發現，這個系統在運作的時候是由很多的執行檔（ＥＸＥ）組合而成的，但是，使用上必沒有感受到不同，但是，可能是由兩個不同的部門開發出來的。要非常注意的就是效率以及整合度的問題了。
如果是利用HTML網頁來整合的系統，那可以用的方法就非常非常多了，我們在看瀏覽網站的時候最常用的就是用Frame框架的切割，可能左邊是Ａ公司的網站，而右邊是整合入Ｂ公司的資訊，這種方法是Netscape最先開發出來的語法，但是整合度低，廣告Banner Pageview以及著作權使用權的問題爭議不斷，所以一般大眾型網站很少使用，而應用在管理系統或是WEB電子郵件服務到是非常的方便。
還有一種用Javascript的含入功能
＜script language=javascript src=sURL＞＜/script＞
這種做法在通訊上就更上面提到的切割Frame的方式是一樣的，但是在畫面及介面的整合上比較漂亮，畫面上看不出來是兩個伺服器提供的資料，但是JavaScript在程式撰寫上比較繁複，這種方式廣泛的被應用在網路廣告的主機上面，來計算廣告的點閱率，並大量的記憶客戶瀏覽過的網站，盡量丟給客戶相關的廣告，以增加廣告效果。而這一類的整合的缺點若有一台主機伺服器出現問題，網頁上就會顯示不正常，必須要克服。
而微軟的IE瀏覽器上面，在版本4.0上面就新增了
＜IFRAME SRC=sURL .....＞＜/IFRAME＞
的語法，算是綜合上面兩個優點，讓不同網站伺服器畫面整合的好方法，唯一的缺點就是Netscape不支援。
至於這一類介面的平行整合必須要考量的就是安全性的問題，為了防止非法的連接使用，通常是使用參數編碼加密，透過使用者的瀏覽器來傳遞，但是若要嚴謹一點，這兩台伺服器就必須建了某種認證上的通訊機制，使用共同資料庫，或是即時的通訊規格，都是很好的方法。
我們往往聽到很多的策略結盟的新聞，也有在賣場看到兩樣產品合在一起賣的比較便宜的案例，這些都不是軟體系統的整合，更談不上未來，只是為了提高產品的銷售量的一種手段而已，真正的產品或是系統的整合型態，主要可以分為三種，一是上下游的產品資料的垂直整合，二是系統介面的平行整合，三是重要模組的分工整合。
上下游的產品資料的垂直整合
這一點在即時處理資料的網路年代特別的重要，以入門網站為例子，他們提供了很多很多的新聞資料，就一定要輸入大量的數位化資料，然後自動的編排入網頁成為內容或是讓客戶做全文檢索的查詢，因此透過什麼通訊協定來傳送資料就特別的重要。
目前一般應用到的大部分是ODBC的資料連結，有時透過TCP/IP來傳輸資料，或者應用WEB/FTP 伺服器來傳遞資料，而XML 也是重要應用的格式之一，當然用二進位檔案傳輸的效能是最好，但是資料的型態比較不開放，而同一個系統用DLL/OCX,或是兩個執行檔(exe) 之間的傳遞資料都可行，這些傳遞資料方法都必須考慮兩個系統達成溝通的最佳模式，而不是用最新的技術就是最好的。
而不同資料的傳輸方法與資料庫的整合都要有各種不同的專業領域分類的常識，要整合這些資料資訊，除了剛剛提到的通訊協定之外，資料庫的分類與整合也是重要的課題。
雖然資料庫是最常用於儲存資料的地方，但是，他並非是萬靈丹，不同的應用對於資料表的查詢或插入資料的效能不一樣，所以，上游的資料表不一定完全適用在下游的資料查詢，除了資料傳遞之外，對於資料庫的重新規劃也是整合的要點之一，如果單純的對資料表的建立View, Triger, Index 可以解決問題當然是最好，但是適當的用程式化(SP)的轉變格式是大部分的解決方法。
垂直的整合有一個重點，就是不要同時要做水平的整合，或是跨過兩個系統的垂直整合，這往往是導致整合失敗的主因，試想兩個系統的整合要討論的事情，重要的有傳輸介面、資料型態與呈現的專業分工領域之外，如果加入第三個系統來整合，他的難度變成非常的困難。
搞清楚兩個公司或兩個部門整合角色的扮演，才能正確的抓對了整合的方向，系統設計起來的權責區分才能做的好。
以我寫程式多年的歷史來看，寫程式除了靠經驗的累積以及開發工具的使用之外，最重要的就是邏輯推演的具體化與抽象化兩個方向，這兩個方向若能互相契合，這個軟體系統就能把錯誤減到最低，而且跑起來也特別的順暢。
首先先想一想我們再解一道代數數學的題目時，總是用一些抽象化的方法，先盡量把因數分解、多項式的加法變成乘式或者除式，然後把就可以找出答案來，但是這個過程除非經過大量的死背經驗，不然很難想出這些抽象的方法，這也是大多數人代數學不好的原因，無法具體化答案。
PS. X^2+2X+1=16 → (X+1)^2=16 → X=3 or -5
記得我剛學代數的時候，每當解不出答案的時候，就是硬寫了一個小程式，把代數的數值從零開始把代數值填入，利用電腦的快速運算，找出最接近的答案，甚至到了微積分的考試的時候，特別去買了一台可以寫 BASIC程式的計算機來找答案，雖然答案對了，但是解題的過程完全無法交代，所以還是被當掉了！
要寫出一套好的系統，抽象化與具體化的能力一定都要能培養，我看了很多的程式，只是在寫流水帳的程序而已，要什麼功能，就寫一個功能，要一個對話窗，就畫一個對話窗給使用者，到最後程式愈來愈大，雖然這個是具體化的結果，但是所有的程式都沒有模組化，前因後果也沒有考慮，當然系統就不好維護，要改一個程序的時候，甚至都沒有辦法修改，而衍生出一些Bug! 這時候就要適當的加入一些抽象化的概念，想辦法分類然後模組化或黑箱化。
我也看過非常抽象化的程式，每一個模組的分的很好，利用物件導向的程式寫出來，但是看程式就像數學的解題過程一樣，非常的刺激，但是維護起來卻十分的困難，要加一項功能，就要花很多的時間!
一套系統在開發的階段，不可能完完全全的仰賴客戶或所謂的系統分析師的紙上作業，實際在寫程式碼的時候一定會發生困難，利用具體化或抽象化的概念，不要讓自己困在中間，才能寫出一套好維護的系統。
創意的構思過程可以分為感覺構思→邏輯構思→多面構思→靈感構思 這四個過程，而我們往往在一個系統的構思階段便想了很久，做不出來，只要善用這些構思的方法，你很快可以把一個系統的架構畫出來，以便快速的完成一個雛形。
一般的軟體工程師往往會不滿現狀，想設計出一套完美的系統，我們在之前討論用最笨的方法來思考的時候，就是避免大家想的太多非必要性的功能，造成後續維護與發展的困擾，試著想想看當我們早上起床刷牙洗臉吃早餐一直到搭車上班，我們需要用很多的腦力去構思嗎？這就是反射動作，我們在做一項思考的時候，往往就是用感覺構思就已經完成了大部分的事情，可以說是反射動作的思考。
當我們找不到一項東西，譬如說是一本書好了，便要冷靜的回想，什麼時候用過這本書，書本可能放置的位置，從主題意義來想，用各方面的判斷與分析，是不是上大號的時候放在廁所，或是放在公司放在朋友家裡忘記拿回來了，這個構思的階段就是邏輯的構思。
如果找不到我們通常就開始全面的搜索，地毯式的找尋，把全家每一個地方翻過來找，我們在創意會議的時候也常常如此，把所有現有品牌或是競爭對手，把字典的字全部翻出來，一項一項檢討比較，這個就是多面的構思。
至於靈感的構思方法，是我們比較少用的，用不同的角度，在一個突發的狀況下想出一個靈感，好像寫文章文思泉湧，創意猛然向你撲來，這個就是靈感的構思，一般寫程式的時候也就是為什麼有時候去上上廁所休息一下，就會把Bug臭蟲抓出來的原因。
而據我個人觀察發現一般工程師在邏輯構思的階段就往往無法決定是要往哪個方向，無法決定用哪個方法來實作，這個當然是要問問別人的意見，如果無法很快的做決策的時候，一般來講都是先做了再說，當然不要做完了再來測試，要做到一半的時候就要想辦法測試，來看看自己當初想的方向有沒有錯誤。
再來工程師常常犯的毛病就是想的太多，設計一些很少會用到的功能，雖然是多面的思考，但是很少會用的上的，這一點需要做一些測試，來測試我們的程式碼，這一點也是我們目前為止很少做的品質管理工作，來評定我們的程式設計師。
當然撰寫新系統需要一些經驗，看看前人的程式碼是最快的學習方式，用上述構思的方法或許可以讓您更快的了解你的思考架構。
延伸閱讀：【創新】先把自己變笨，歸零的思考
世界上所有的品牌產品一定有累積性的用戶，無論是日常的生活用品或者是工業性的產品，而這一點在軟體系統上更有說不出的使用習慣，無論是網頁的編排或者是產品的功能表設計，很少有第一版與第二版的軟體系統會變成完全不同的。
我們在系統創新的過程經常會忽略的就是舊有使用者的操作習慣或者是資料的相容性，一套產品除了不斷地創新改版之外，還要考慮之前的操作介面，還要在舊有的習慣下建立累積性，增加競爭者進入的難度，但是在增加功能與使用操作的安排上面，絕對要考慮的就是簡單性與合理性。
我們經常做的事情就是為了創新而創新，為了與別人有差異而創造出不需要的需求，陷入盲目的產品競爭，要跳脫這一類發展的盲點除了上一次所提的歸零的思考之外，就是累積自己的優點，所以我們在軟體系統的開發上面，除了要了解舊有的程式碼之外，還要知道哪些程式碼是我們的競爭優勢，是必須要被模組化重用的，這樣在未來的發展上我們才可以累積我們的優勢，而一般的程式設計師剛接到一個新的產品或是專案的時候，剛開始非常的痛苦，一個大系統不知道從何下手，要增加心的功能加了老半天，錯誤也一大堆，這時候應該適時的跳出來了解一下產品的特色與競爭優勢，進而分析哪些是我們累積的核心程式。
了解了這些舊有的習慣以後，要新增一個功能的時候第二個要考慮的簡單性與合理性，操作過與複雜的子功能，我們寧願把他放棄，因為不會有太多人會去使用它，除非是非常專業的需求，而這時候應該想到的是簡化操作與一些預設值的設立，幫使用者想好操作的參數，以前操作軟體系統的時候很害怕系統問我一大堆數字，結果光填完這些數字天就亮了，還不知道填的對不對。
每一個軟體系統累積技術的方式不一樣，如果是一般的網頁，除了連結的網頁樹狀結構不要亂掉之外，編排的方式也非常的重要，不要新增了一個連結結果一按了之後就回不來了﹔另外使用者的資料庫的維護也非常重要，不要一直讓客戶重複填寫註冊的資料......如果是一般的Windows程式，新增加的功能表的分類要與原來的操作習慣相仿，不要以前用滑鼠的功能，現在只能用鍵盤的鍵來操作之類的......
產品的累積性非常重要，如果您是做專案，要累積專案經驗的方式不一定適用，所以一個公司商業運作的模式一開始就一定要決定是要走產品化路線，或者是專案性路線，雖然其中有一些模糊的中間路線，確認您的目標才不會白做工。
看看市面上的書有大部分是教程式設計師如何應用工具，如何用 Front Page,Visual C++, Visual Basic, C++ Builder... 或者是如何學習電腦程式語言，但是可能只有不到10本的電腦書籍教大家除錯(Debug)，教大家建立系統的品質，而一套系統的被頻價不好，往往就是一點點的小問題，而被大家獲的好評，往往也只是一點點貼心的設計。
上一期談過程式設計師的風險，如果加上大家對於程式設計的要求『品質』的話，這一份工作實在是非常的艱苦，所以有很多公司把除錯或品質的要求獨立出其他的單位（測試部門），但是往往成效不彰，或者是目標、成就感無法建立更增加程式設計師的負擔，其實品質建立的觀念是每一個人都要建立的，並不是只有程式設計師要負擔的工作。
舉例來說，如果程式設計師只是依照系統分析的文件寫出來一些功能畫面，而沒有加入對於系統來攏去脈的了解，往往少了一份『精神』，這個就是品質的一種，我們通常稱為一項專業領域的知識(Domain Knowledge)，例如汽車維修業，一套良好的維修作業管理系統，當然必須融入汽車維修業的專業知識，不然最簡單的來講，這個系統往往會犯了操作不通暢，查詢很慢或是不符合需求的毛病，而這個專業知識的建立就是一家公司生存與競爭力的所在。
其實一套系統的雛形開發真的非常容易，只要有些許的想法，就可以舉辦一場良好的展示，但是等到系統進入整合的階段，對於系統品質的要求就進入這個階段與狀態，往往程式設計師會覺得當初討論或系統分析就是這樣寫，他們設計的沒有問題，但是往往交付給客戶試用時，就是不對，照成整個架構必需重新翻修或者重寫。因此，如果我們能夠在程式撰寫的同時就用心的注重除錯，用心的詢問客戶的操作習慣，甚至要加入對於專業知識的判斷，等到系統完成時，就是一套良好的系統。
預估開發一套系統在品質方面的成本應該跟程式設計的成本是一樣的，如果要開發一套系統的要注重的三個面向是創新設計、維護能力、品質管制，每一個面向的專業知識都『一樣』重要，而品質方面就是，架構、除錯、測試這三個重點要抓的住。
延伸閱讀：【創新】創新力與執行力必須以專業為基礎
從無到有開發一套系統看起來看似簡單，但是一套系統要有計劃的開發，系統架構要方便於未來的維護與擴充，是系統開發人員最大的痛，本文簡單的說明一套軟體系統在開發之初或是在維護的時候要注意的幾個重要的課題，可以讓您更了解您的系統出了什麼問題？
一、資料儲存的型態、儲存的位置、使用方式
二、通訊協定架構與資料量、傳輸媒介
三、用戶端的操作介面與資料列印問題
四、配合用戶端必須有哪些伺服器
五、安全性問題，認證、加密......
首先，有很多人認為開發工具(如VC++,BCB,VB,Delphi...等)是開發一套系統要優先考慮的事情，我認為開發工具是團隊中重要的溝通工具，但是並非一整套系統的重要考量，因為寫程式碼、修改程式並非就是開發系統的全部。
資料型態，首先就一個系統的資料來講的話，大家想到的就是用資料庫來管理，但是如果您的資料是非常簡單的型態，或者是資料量並不是非常大，有時候用檔案的型態，倒是非常好的維護方式，程式撰寫容易，效率也比資料庫好，如果您的系統資料不會擴充的話，建議以文字資料檔案的方式來儲存，如果您認為您的系統前景看好，可管理的資料非常的多樣化，這時候選擇的資料庫系統也要十分謹慎，而資料儲存的位置是伺服器端或是客戶端，客戶端如何存取資料或是資料的加值計算統計是在哪一端，都要事先規劃。
通訊協定，大家第一個想到的就是TCP/IP，並非所有的網路傳遞都靠TCP/IP，網路理論中的七層架構中，我們要先了解一套系統的網路組成是如何的，當然利用比較公開或比較常用的通訊協定，可能未來的擴充性較高，但是必須先考慮資料傳遞的特性，例如大家常用的FTP傳檔的通訊服務，起始並不是很適合用TCP/IP，當您發現您傳一個大檔案的時候會愈傳愈慢，這就是TCP/IP的缺點，後來開發出來的續傳伺服器與續傳的用戶端軟體(GetRight)，就是要彌補這項的缺點，早期也有TFTP利用UDP/IP來傳遞資料，其實是不錯的解決方案，而通訊協定的確定包含一項重要的考量，就是資料傳遞的方式。對於近年來伺服器代理程式或者是路由器的轉傳遞資料，必須也要事先考慮到的。
用戶介面，這個關係到您的產品系統對於用戶的感受，也要視情況選擇開發的方法，如果用戶只有3-4個人，可能不需要太炫麗的外觀，只要針對使用者常用到的功能效率提昇並且考慮使用者操作的方便性就好了，至於您的系統如果是免費下載的Shareware，就要考慮到使用者必須如何學習你的程式與使用者使用操作的動機了，現在的系統很多應用到瀏覽器的介面，不失為一個良好的方式，但是如果考慮的前面所提到的資料量，用IE或Netscape經常在資料的傳遞上的效果不好，操作的便利性也不是很好，常常需要一問一答的方式，增加了使用的時間。這一方面雖然微軟也一直在推廣Windows視覺式的操作介面，但是滑鼠並非能解決所有的問題，我們必須同時考量到鍵盤快速的操作便利性。
伺服器端，我們經常接觸到的Mail Server, Web Server, FTP Server是標準的伺服器系統，但是這些伺服器資料的傳遞方式是否符合我們的需求，是否要另行開發是我們必須先考量的地方，現在有很多的系統都用HTML 當介面，然後對於WEB Server做操作，這一種方式的開發目前來看雖然非常的快速，但是客戶量的多寡，還有操作事項的複雜度，都是必須考量的，如果需要的話，必須是要開發一些中介自動化的伺服器程式來對使用這的操作在排程，否則在網路的傳遞(頻寬)，或是伺服器的負荷都是很大的負擔。
安全性，以前的封閉系統開發可能不會在資料儲存傳遞的過程中加密，但是隨著網路時代的公開化，現在我們有標準的加密通訊方式(SSL...)，也有標準的認證伺服器，而安全性包括使用者的基本資料與歷來的交易資料，也包含了使用這一整套系統的權限，這個在系統開發之初就一定要考量的問題。
網路時代的軟體系統開發雖然也趨向標準化了，但是，一個系統的開發必須更謹慎的評估，才不會失去他的擴充性。
您曾經舊地重遊，發現就只是一年沒有回去，發現面目全非嗎？一套軟體系統，比較不容易有這種感覺，但是一個網站，經常會有這個動作，不斷地換版來吸引人潮，但是只要是服務的精神或產品的架構沒有改善，這種經常裝潢的動作，是沒有用的。
如果把軟體系統的開發拆成很多的面向來看，使用介面、管理核心、系統架構、危機風險、避免錯誤、對外溝通......等等，我們往往常會用工作進度的導向方式來管理軟體的研發團隊，而忽略的其他的過程，而其他部門看到軟體的問題往往就是舊的系統有問題、新功能未能趕上市場的速度等等，這些部門的互動之後，往往產生惡性的循環，有洞補洞，而補出越來越大的洞。
所以說，要快速的達成軟體系統的開發，最好能注意所有的面向，而一個成功的網站之所以吸引人潮，除了門面之外，背後的自動化管理系統，是最重要的一環，隨著網路服務的拓展要同步開發的系統，而一套運作良好的軟體系統要同時怎樣兼顧速度呢？除了撰寫程式碼物件導向化之外，上述的所有活動都要朝向物件化的精神----繼承重用，寫程式碼最簡單的是用別人的元件，但是，系統架構、避免錯誤、對外溝通要拿別人現成的，要拿別人現成的成果，必須花一番功夫消化吸收後，才能套用到一項產品或專案的開發程序，而這種開發的過程，就是一家軟體公司的核心能力 ，有人做會計進出貨管理系統，有人做汽車保養場的管理系統，都有各自的核心技術能力。
這些軟體開發的過程針對不同的產品，有非常不同的控制機制，為什麼一家公司可以生存重要的也是這些控制的過程，一個網站的使用介面重要，但重要的是他的內容方便使用，一套軟體系統除了畫面夠炫使用方便之外，重要是他的實用性切重要點。
開發軟體重要的創新，是以人為主的創新，開發系統創新在使用介面，也在使用的架構，但是也在團隊的合作與對外緊密的溝通，不同產品有不同的創新，多多觀摩應該是最好的學習做法。
幾年前，一套程式系統用的分析方式，往往脫離不了靜態的畫面顯示，動態的資料輸入，以及資料的處理運算功能，這三類問題的處理只要能夠被表列出來，就能夠架設並完成一套良好的系統，這個就是結構化的分析方式。
但是隨著需求不斷地增加，電腦速度不斷地提昇，大量競爭的商業環境，物件導向的演進，改寫了結構化的分析方式，就連最基本的電腦語言也帶入了這場革命之中，從1980年代後期，企業軟硬體委外(Outsourcing)的商業活動抵定後，這些系統整合的廠商無不想盡辦法把『重新利用』這個事當作最重要的目標之一。
結構化的分析是個良好溝通的開始，但是，他的維護成本過高，一個系統不斷地演進過程中，就要有一批人非常熟悉這一套系統，一個新進的人員，要從頭了解一套系統，除了要閱讀所有的文件之外，也要熟知所有改版的歷史過程，而物件導向解決了這個部分的困擾，只要熟知一個物件的所有溝通介面，就可以很快的抽換掉一個物件並更新他的功能，就跟PC硬體的DIY一樣，顯示卡壞了，拔掉插入好的就好了。
這其中的演進也並不完全沒有中間的過程，記得1995年起，非常興盛的Frame-Work的架構，這其中的代表是Borland的OWL，以及後來模仿的MFC，把一個程式拆成文件Document／顯示View的型式，只要依照這個模式開發，會節省非常多的開發時間，但是並非所有的系統可以適用的，所以後來出現的Delphi語言，就是以單純的物件，你知要把一些開發好的元件搭配起來，並協調使用的模式，就可以簡單的完成一個程式。
我並非推崇哪一個特別的電腦程式語言或使用工具，只是這些工具的興起開創了里程碑，所以，不要太在意您用的工具用BASIC一樣可以做到物件導向，用C++語言也可以做的非常不結構化，只要熟悉物件化的原理與結構，一樣可以朝向物件導向邁進。
下一個潮流是什麼？
軟體開發工具不斷地創新下，這幾年的開發工具可以說是一日千里，稍不注意，你會發現很難與別人溝通，在剛剛踏入程式設計的領域的時候，我們往往會在意要學會C/C++或是要學會MS Windows 的程式設計，這一些技能在我的觀點來看，只不過是工具，要達成一個龐大的軟體系統，這些技能當然是不能或缺，但是，最重要的是要善用物件導向與資料庫的概念，將這些概念融入系統，或許因為大家開發的工具不同，不能利用物件導向的語言來開發，只要能融入這些概念，未來的發展性是無可限量的。
資料庫系統的工具程式語言，我們通常稱為『第四代語言4GL』，著名的4GL作業系統廠商有 Sybase, Orace, Microsoft......, 目前最新查詢語言的規格為 SQL-92, 對於資料庫系統中有關table, view, store procedures，交易異動及權限的管理是資料庫最重要的幾個特色，我們往往認為資料庫只是一個儲存資料的系統，其實經過統計後的資料才是重要的資產，如果是一家企業，透過對資料庫系統的設計，我們可以很容易得到即時的企業統計資料，如果是客服系統，我們可以很快的統計出客戶所要的服務，而不用透過不準確的市場調查或問券統計。
物件導向，我們很容易就想到所謂的JAVA語言，其實程式語言只是實踐物件化的工具而已，現在的VB, Delphi及JAVA 語言有融入也都有物件導向的語法，甚至上述的資料庫系統也都有所謂的物件化關聯式資料庫概念，有使用者自行設定的資料型態，有自定的函數與完整的物件關聯式型態擴充等等。現在的物件導向從早期的原始檔物件概念，一直到可執行檔的元件化(VCL, OCX,COM+) ，到現在的網際網路元件化概念(HTML,XML)，未來的連結性將趨向更開放的規格與通訊協定，簡單的例子，我們經常發現一個網站有JAVA applet程式開發的跑馬燈，這個跑馬燈的元件可能是A軟體公司開發給B網站公司，然後B將這些應用元件放在網站上應用顯示自己的資料，同樣的例子還有很多，有些是Server Side 的元件，有些則是Client Side 的元件。
了解資料庫與物件導向的概念後，我們設計一套軟體系統時要注意的就是應用的效率了，是伺服器的負擔比較重，還是客戶端系統的負擔比較重，通訊協定是否符合應用的環境，傳輸時間是否過久，客戶數目過多的時候伺服器是否會承受不住，客戶端的資料要如何取得，客戶端與伺服器的環境是否能配合......這些檢查點其實很容易評估，只要我們把附圖的各個連結點畫出來即可。
物件導向與資料庫理論應用已經是發展好一陣子的概念，要開發創新的軟體系統如果遵照這些理論規則來開發，系統的相容度很高，也很容易移植到不同的『平台』。
從個人電腦的演進歷史上來看，從大型主機UNIX在商業的應用，作業系統在其中雖然扮演極大的角色，但難免的他的價值是隨著主機一起販售的，因此的他開放性程度很小，APPLE個人電腦在西元八十年代席捲的個人電腦的市場，但是終究抵不過IBM以相容性的PC 硬體平台架構。
同樣的例子，微軟將作業系統視為一個開放性平台的架構下，在1995年推出Windows 95 後，這四年內，也置換掉我們對於產業價值判斷的標準，從硬體的生產應用中獲利轉為從軟體創造創新中獲利，通常我們買電腦週邊用品都會附贈一些應用軟體，例如買數據機送上網的撥接點數，但是現在有愈來愈多的遊戲光碟軟體，是購買軟體送玩具，當這個價值供應鏈變更成為，買軟體送數據機的時候，整個軟體價值就不一樣了。
大型主機『平台』的時代，是應用在電腦的大量快速的計算能力，而ＰＣ個人電腦『平台』的時代，只是將這些大量快速的計算能力普及化與個人化而已，到了作業系統『平台』的時代，我們才真正的把作業流程全面的電腦化，以往開發的軟體系統往往是特殊用途的商業應用，在作業系統與網際網路的雙重應用效果下，軟體系統才真正的被大眾真正的應用。
因此，現在大家在討論下一波的趨勢到底是什麼平台，我個人認為是網路服務的平台，這個平台是沒有實體的商品，現在炒的正熱的開放性原始碼(OSS)作業系統Linux，與Cisco的路由器OS，也只是掌握部分的關鍵，試問世界上真的有那麼多人懂得程式設計與網際網路應用嗎？
在這個網路服務平台之下，所有的價值在創造一個服務型態，以往傳統的價值鏈會在加值性的服務重大的變革，有人說知識專利權是一個非常重要的未來，但是這些專利的認定與規範，如果不能在政府行政單位下有效的管理，我想不斷地提昇自己的服務內容與策略合作，將自己與競爭者拉大距離，將是這一波網路服務平台的生存之道。
一套大的軟硬體系統，通常會有很多很多的周邊設備來做搭配，或者是有很多很多的介面，這些介面有可能是不同時期開發的，或是不同公司開發的，或者是搭配不同的周邊設備所開發的。
因此在軟體的開發上大家時常看不見的有下面兩點：
a. 核心程式的開發
b. 共通介面的制定
這些系統程式的開發往往因為在功能性無法看到成果而被其他的業務部門或客服部門感覺研發軟體程式部門沒有成果，這其中的落差研發部門要負起溝通協調的工作，並不是只是在功能進度裡摸索而已。
核心程式的開發需要完整而單純的邏輯及非常嚴謹的通用規則，共通介面就是核心程式與其他週邊介面所溝通的介面，制定這些介面的時候所慣用的就是通訊協定、檔案規格、函式功能等等，因此軟體系統就是靠大大小小的核心程式與共通的介面交互的運作著。
隨著時代的演變，可能這些系統的功能不足，正常的做法是我們一直加入大大小小不同的介面來搭配核心程式，或者新增一下核心程式的功能，但是，往往新增加的邏輯與原來的核心程式邏輯不符合，但是時間的壓力下，或者是維護人員不熟悉的情況下，我們就新增一大堆的例外處理，把核心程式的單純邏輯與通用規則給搞亂了，甚至是介面程式的定位也模糊掉了。
因此，若是這個軟體系統是要長期的維護開發的話，風險比較低的做法應該是在新功能加入前先評估核心程式是否要改變通用性邏輯，若是要改變才能因應未來的需求的話，我們可能要先建立一個階段性的檢查目標把新的核心程式的開發排入進度內，並且與舊的核心程式建立一些轉換的介面程式，慢慢的把舊的核心程式的重要工作轉給新的核心程式，在慢慢的將所以的介面程式轉換成新的版本。
在這個轉換的過程比較重要而瑣碎的工作，但是又不得不做的工作就是相容性，人類的世界總是同時存在著所有的新舊事物，這些事物是不是永遠都很協調的在一起呢？這就是相容性，一個軟體系統不可能永遠的存在，他必需要被人類運用他才存在，如果一套軟體系統在發展過程中背離了相容性，教育使用者將是非常艱鉅的任務。
