研發團隊合作必須了解需求分類：職場

團隊合作在各種組織上來講都一定是必要的，在開發軟體系統上更是重要，以前我總覺得只要重頭到尾完成開發的動作就可以了，把自己想成專家，但是經常開發出賣不出去的系統。

通常一個大系統很容易拆成很多很多的模組，一般很容易分配寫程式碼(Coding)的工作，分配好工作之後大家也都很容易的整合起來去找出缺點(Bug)，這些就是一般程式設計師定義所謂的團隊合作的方式，但是一個正確的產品並不是只要有良好的架構就可以的，他還要符合客戶使用的『需求』，而這個『需求』往往是程式設計師在團隊合作下被遺忘整合的事情。

需求對於一個系統或者一項產品像是靈魂一般，我們往往在系統分析的階段模組化後就被遺忘掉了，如果看看以往成功的產品的例子，可以發現程式設計師的解讀會完全的不同：

1.隨身聽只是縮小化的床頭音響，我們只要把床頭音響的模組縮小即可。

2.汽車的自動排擋功能，只是在排檔的過程加入離合器模組即可

3.太空梭只是把火箭與飛機的功能合在一起就好了。

4.數位攝影機只不過是數位相機加大的記憶體容量。

5.這個系統只要用現成的元件兜一兜就完成了。

這些工程師對於一個產品的價值往往評估的非常地低，這樣的判斷並沒有錯，他們忽略掉了一個成功的系統擁有很多方便的特性，有些系統花了幾萬行的程式碼在做出符合效率的Cache效能，有些系統在操作介面上下了很大的功夫，只要簡單的操作就秀出客戶要看的內容，這一些並不是理所當然的，是『需求』使然的。

擁有好的創意產品，即使沒有使用最新最快的技術，只要是符合需求，價格可以提高的非常多，這個才是成功之鑰。

閘道系統的應用分類：創新

閘道系統的應用在我們日常的生活無所不在，但是我們經常不知道，例如電話電信公司、電話機、傳真機、對講機、EMail伺服器、呼叫器甚至是我們現在常用的ICQ，都一定要有相關的閘道系統及產業的配合，而這種產業一定只要遵循相關的通訊規格就可以與別人溝通。

如果仔細想想一個網站也是一個很好的閘道器，入門網站也是某一種形式的閘道器，他們需要把內容的資訊流轉化成為營收，無論是利用廣告的收入或是收取上架費用導入流量的方式，都是閘道系統必須去轉換的核心價值所在，也是最基本的功能。

這是我想到一個閘道應用系統要開發必須注意的事項：

1.通訊協定的排列組合

充分的了解所有電信通訊或者是網際網路的應用特性，千萬不要自己創造一種新的格式，還記得SONY Beta錄影帶慘痛的經驗嗎？各種通訊協定如果可以找出最佳的應用方法，並且變成非常普遍為大家所應用的話，就是很好的閘道系統。

2.現階段的相關產業能夠變成通路

要創造一個新的通路非常困難，行動電話在台灣的通路是一個難得的異數，未來不太可能有相同的機會出現，我們在街頭巷尾看到的便利商店，或者是一個地方固定都有的水電行，甚至幫中小企業安裝電話總機線路的公司，都是現有的通路，一定要找出他們能夠容易上手安裝及應用的地方，因為只有這樣才能推廣的出去。

3.安裝及操作介面要容易使用

買電話機回家插上電及電話線就可以使用了，這個是一個閘道系統的重要目標，使用ICQ可能需要學習一下，但是他也提供了邊做邊學的功能，這個是目前所有閘道系統在推廣非常重要的一點，也是要給大多數人應用的機會點，但是如果你的系統是比較少數人要使用，價位也比較昂貴的，當然是可以不用考慮的。

4.一定要轉換產業價值

如果分析現階段所有的企業需求，大家會發現內容的開發以及被瀏覽的產業價值應該不會超過5%，其他還有資訊流、金流、物流的價值應該是佔非常多的比例，尤其是資訊流就應該佔有30%的比例，而現有日常生活的閘道系統應該還有很多創新的機會才是。

兩擔大蒜談創新分類：創新

有一個賣蒜的農夫，挑著一擔大蒜到北京城裡去賣，結果一天下來都沒有賣出，還碰到大雷雨，淋溼了一身。躲雨的地方剛好開了一家網路咖啡店，店裡的年輕人請他進店裡座，問他賣了多少？農夫說：一塊錢也沒賣出去，現在的人都到超市去買了恐怕以後都會賣不出去。 　他就立刻問這位農夫說：你的蒜頭有什麼特別？農夫很驕傲的說，這些蒜頭全部都是我自己種的，是用純天然的肥料，所以又大又漂亮。這位年輕人一聽，就說：我或許可以幫你！ 　他就上網打入「有機大蒜(organic garlic)」進行搜尋，幾分鐘後，就對農夫說：我已經把你的一擔蒜頭賣掉了，是一家德國的公司正在找用有機天然肥料培植的大蒜，他們還要買很多而且價格特別高。

我想創新並不是一個很大的革命，只是提高產品的附加價值，很多的軟體工程師在設計系統的時候經常是為了創新而創新，因為對手的軟體的一個小功能而做出更炫更誇張的功能，但是並沒有考慮為什麼要加這個功能，等到完成的時候，這個酷炫的功能使用者並不會經常的去使用到。

如果應對到兩擔大蒜的故事，這就是創新的時候沒有考慮到產品的附加價值的問題，當然我們要了解產品本身的核心價值在哪裡，並提高使用者對於我們核心價值的使用率，如果您是作一套語音辨識的輸入法系統，您就不應該把重點放在手寫輸入法的介面，應該想到語音辨識的應用範圍，並提昇使用者對於語音辨識的操作的方便性及應用功能。

如果是經營商業套裝軟體的系統，就應該考慮增加的附加價值是否可以增加營收，增加客戶購買的意願，提高客戶再度光臨購買下一版的功能，當然，軟體的收入模式有很多種，可以按使用次數計費，按使用時間計費，而目前最常用的模式就是第一次購買軟體的時候的費用，所以比較難達到附加價值增加營收的方法，網路帶來了一些的希望，透過網路更新軟體，透過網路傳遞更有用的訊息及資訊，來增加產品的附加價值甚至會反客為主，就是營收可能不再是第一次的軟體費用，而是每一次新增功能的費用，但是一套軟體系統的核心價值並不會完全的更改，反而更加的有價值了。

從上面大蒜的小故事告訴我們從產品的『附加價值』及『行銷通路』來改善產品創新的方向，一般的程式設計師也應該多多接觸行銷及業務推廣的層面，才能設計出正確創新的產品。

系統工程師的角色扮演分類：職場

一直以來我們一直討論程式設計師的特性與努力的方向，其實有更重要性的工作是由系統工程師來完成的，有些人可能不知道在小公司，研發工程師擔任了很多系統工程師的角色，於是系統工程師的地位就降低了很多。

在大型企業都有電腦室或是資訊室的設立，他們負責了公司上上下下的電腦系統的維護，大家對他們的印象也不是非常的好，通常電腦出了問題，要找問題找很久，要透過採購維修或是送修才能解決問題，而且不一定能解決問題，造成一般行政人員工作上的不方便。

我想要做好系統工程師的角色並不是只是單純的設備的組裝與維護，非常重要的解決問題的能力是要靠經驗及，邏輯推演的方法來執行，而解決問題只是一個資訊室或者IT部門最最基礎的工作之一，並不是這樣子就能擔任好的系統工程師，前十年(1990-1999)的系統工程師的主要工作大部分是PC的組裝與維修、網路的架設、伺服器的維護，甚至也負責電話線路及總機的系統，但是目前的PC電腦、伺服器及網路設備都非常的便宜及精良，所以部分的系統工程師也大部分擔任資料庫或是檔案的例行處理工作，譬如說備份、傳輸等等。

我想這些工作並不是操作員(OP)，而應該加入邏輯的思考，就像家電產品，大部分人買回家只是插上插頭就開始用了，並不知道裡面的運作方式，如果系統工程師也是這種心態的話，他的工作一定會隨著系統的不斷地創新開發被別人取代，系統工程師每天在操作的伺服器、資料庫，也了解裡面的運作程序，才能正確的抓出執行的問題，幫忙行政人員解決問題，系統在升級的時候能適時的提出正確的評估，幫忙計算成本及架構未來最好的操作模式，千萬不能有自私的心態，是不是我的工作未來就會縮減消失，每一個時代都需要系統工程師，只是運作的成本會隨著科技的進步而改變。

想想目前的系統工程師最熱門的應該是在網路的架設與規劃，前幾年著重在NT的伺服器，但是我想這些東西只是您平常操作的工具，現在免費的Linux也是一種網路的產品，這些東西一直出現，系統工程師的工作除了要了解這些系統的操作設定之外，基礎的理論是最好要熟記的，如果網路通訊協定的特性不了解，如何能正確的設定一個公司的環境呢?

系統工程師的路很長也很遠，不但要負責與研發人員溝通了解系統的運作，還要與行政人員周旋，還要不斷地學習成長，但最重要的還是邏輯的思考。

程式設計的具體化與抽象化分類：系統

以我寫程式多年的歷史來看，寫程式除了靠經驗的累積以及開發工具的使用之外，最重要的就是邏輯推演的具體化與抽象化兩個方向，這兩個方向若能互相契合，這個軟體系統就能把錯誤減到最低，而且跑起來也特別的順暢。

首先先想一想我們再解一道代數數學的題目時，總是用一些抽象化的方法，先盡量把因數分解、多項式的加法變成乘式或者除式，然後把就可以找出答案來，但是這個過程除非經過大量的死背經驗，不然很難想出這些抽象的方法，這也是大多數人代數學不好的原因，無法具體化答案。

PS. X^2+2X+1=16 →　(X+1)^2=16 → X=3 or -5

記得我剛學代數的時候，每當解不出答案的時候，就是硬寫了一個小程式，把代數的數值從零開始把代數值填入，利用電腦的快速運算，找出最接近的答案，甚至到了微積分的考試的時候，特別去買了一台可以寫 BASIC程式的計算機來找答案，雖然答案對了，但是解題的過程完全無法交代，所以還是被當掉了！

要寫出一套好的系統，抽象化與具體化的能力一定都要能培養，我看了很多的程式，只是在寫流水帳的程序而已，要什麼功能，就寫一個功能，要一個對話窗，就畫一個對話窗給使用者，到最後程式愈來愈大，雖然這個是具體化的結果，但是所有的程式都沒有模組化，前因後果也沒有考慮，當然系統就不好維護，要改一個程序的時候，甚至都沒有辦法修改，而衍生出一些Bug! 這時候就要適當的加入一些抽象化的概念，想辦法分類然後模組化或黑箱化。

我也看過非常抽象化的程式，每一個模組的分的很好，利用物件導向的程式寫出來，但是看程式就像數學的解題過程一樣，非常的刺激，但是維護起來卻十分的困難，要加一項功能，就要花很多的時間!

一套系統在開發的階段，不可能完完全全的仰賴客戶或所謂的系統分析師的紙上作業，實際在寫程式碼的時候一定會發生困難，利用具體化或抽象化的概念，不要讓自己困在中間，才能寫出一套好維護的系統。

系統架構的構思過程分類：創新、系統

創意的構思過程可以分為感覺構思→邏輯構思→多面構思→靈感構思 這四個過程，而我們往往在一個系統的構思階段便想了很久，做不出來，只要善用這些構思的方法，你很快可以把一個系統的架構畫出來，以便快速的完成一個雛形。

一般的軟體工程師往往會不滿現狀，想設計出一套完美的系統，我們在之前討論用最笨的方法來思考的時候，就是避免大家想的太多非必要性的功能，造成後續維護與發展的困擾，試著想想看當我們早上起床刷牙洗臉吃早餐一直到搭車上班，我們需要用很多的腦力去構思嗎？這就是反射動作，我們在做一項思考的時候，往往就是用感覺構思就已經完成了大部分的事情，可以說是反射動作的思考。

當我們找不到一項東西，譬如說是一本書好了，便要冷靜的回想，什麼時候用過這本書，書本可能放置的位置，從主題意義來想，用各方面的判斷與分析，是不是上大號的時候放在廁所，或是放在公司放在朋友家裡忘記拿回來了，這個構思的階段就是邏輯的構思。

如果找不到我們通常就開始全面的搜索，地毯式的找尋，把全家每一個地方翻過來找，我們在創意會議的時候也常常如此，把所有現有品牌或是競爭對手，把字典的字全部翻出來，一項一項檢討比較，這個就是多面的構思。

至於靈感的構思方法，是我們比較少用的，用不同的角度，在一個突發的狀況下想出一個靈感，好像寫文章文思泉湧，創意猛然向你撲來，這個就是靈感的構思，一般寫程式的時候也就是為什麼有時候去上上廁所休息一下，就會把Bug臭蟲抓出來的原因。

而據我個人觀察發現一般工程師在邏輯構思的階段就往往無法決定是要往哪個方向，無法決定用哪個方法來實作，這個當然是要問問別人的意見，如果無法很快的做決策的時候，一般來講都是先做了再說，當然不要做完了再來測試，要做到一半的時候就要想辦法測試，來看看自己當初想的方向有沒有錯誤。

再來工程師常常犯的毛病就是想的太多，設計一些很少會用到的功能，雖然是多面的思考，但是很少會用的上的，這一點需要做一些測試，來測試我們的程式碼，這一點也是我們目前為止很少做的品質管理工作，來評定我們的程式設計師。

當然撰寫新系統需要一些經驗，看看前人的程式碼是最快的學習方式，用上述構思的方法或許可以讓您更快的了解你的思考架構。

延伸閱讀：【創新】先把自己變笨，歸零的思考

軟體的技術累積性分類：系統

世界上所有的品牌產品一定有累積性的用戶，無論是日常的生活用品或者是工業性的產品，而這一點在軟體系統上更有說不出的使用習慣，無論是網頁的編排或者是產品的功能表設計，很少有第一版與第二版的軟體系統會變成完全不同的。

我們在系統創新的過程經常會忽略的就是舊有使用者的操作習慣或者是資料的相容性，一套產品除了不斷地創新改版之外，還要考慮之前的操作介面，還要在舊有的習慣下建立累積性，增加競爭者進入的難度，但是在增加功能與使用操作的安排上面，絕對要考慮的就是簡單性與合理性。

我們經常做的事情就是為了創新而創新，為了與別人有差異而創造出不需要的需求，陷入盲目的產品競爭，要跳脫這一類發展的盲點除了上一次所提的歸零的思考之外，就是累積自己的優點，所以我們在軟體系統的開發上面，除了要了解舊有的程式碼之外，還要知道哪些程式碼是我們的競爭優勢，是必須要被模組化重用的，這樣在未來的發展上我們才可以累積我們的優勢，而一般的程式設計師剛接到一個新的產品或是專案的時候，剛開始非常的痛苦，一個大系統不知道從何下手，要增加心的功能加了老半天，錯誤也一大堆，這時候應該適時的跳出來了解一下產品的特色與競爭優勢，進而分析哪些是我們累積的核心程式。

了解了這些舊有的習慣以後，要新增一個功能的時候第二個要考慮的簡單性與合理性，操作過與複雜的子功能，我們寧願把他放棄，因為不會有太多人會去使用它，除非是非常專業的需求，而這時候應該想到的是簡化操作與一些預設值的設立，幫使用者想好操作的參數，以前操作軟體系統的時候很害怕系統問我一大堆數字，結果光填完這些數字天就亮了，還不知道填的對不對。

每一個軟體系統累積技術的方式不一樣，如果是一般的網頁，除了連結的網頁樹狀結構不要亂掉之外，編排的方式也非常的重要，不要新增了一個連結結果一按了之後就回不來了﹔另外使用者的資料庫的維護也非常重要，不要一直讓客戶重複填寫註冊的資料......如果是一般的Windows程式，新增加的功能表的分類要與原來的操作習慣相仿，不要以前用滑鼠的功能，現在只能用鍵盤的鍵來操作之類的......

產品的累積性非常重要，如果您是做專案，要累積專案經驗的方式不一定適用，所以一個公司商業運作的模式一開始就一定要決定是要走產品化路線，或者是專案性路線，雖然其中有一些模糊的中間路線，確認您的目標才不會白做工。

先把自己變笨，歸零的思考分類：創新

所有的人類一定會有先入為主的觀念，如果要想出好的點子，好的系統架構，好的可行方案，除了團隊集思廣義之外，就是簡單歸零的思考，您會得到一個很簡單的結論，會設計出可用的系統，這就是先把自己變笨。

一般人經常犯的兩個毛病就是眼高手低與先入為主，總覺得一個市場已經有人先進去了，就看不到未來而想要避開他，或者是做一件事情如果先前已經有做過的經驗，就不會想回頭去做。

舉例來說，一個軟體系統的開發，如果一個資深的軟體工程師開發過了，他可能很少有機會去繼續維護或是加強的機會，因為他覺得他已經做過了而不會想花心思在上面，大部分的人會繼續追求更新的技術，更快速的開發工具，這一點屢試不爽，如果一段程式碼被同一個人看過三次以後，他就一定不會是這段程式碼的主人了!

也因為如此，程式設計的世界品質的掌握需要大量的人力，我們會利用一些檢查表格，一些流程來保證他的品質，而這一點剛好跟速度是剛剛好相反的，而這些流程剛剛好都讓大家覺得自己很笨，為什麼要做這一堆無聊的事情呢？除了與團隊溝通的功能之外，也是一個很好的歸零的思考！

設計一套系統的時候會想的很多，想要給操作人員使用者非常簡便的操作，但是只要利用很簡單的邏輯，拋開以前的包袱，有時候一套一天寫好的簡單工具程式，也可以讓使用者感覺到非常的貼心的。

當我們回頭不斷地review您以前的程式與當時的想法，試著把缺點一項一項的列出來，挑戰自己的主觀，有時候真的很難，放的下是唯一的解法，變笨，試試看！

程式開發的大循環與小循環分類：管理

一般的產品研發工作大概會分成兩個主要的工作時期，一是系統開發期，二是系統上線後的維護期，以一般的研發人員具有最大的挑戰的時期是第一個時期，但是往往挫折感也最大，而第二個時期看似平淡而無趣，但是經驗的累積往往是第二個時期，我們總會覺得開發期的包袱比較小，也要不時的用到創新的想法去構思系統的架構，但是第二個時期的維護期如果隨時利用『創新』思考，其中解決包袱的樂趣更勝於開發期。

如果把開發期到維護期想成一個研發的大循環的話，那麼最近幾年一直在推廣的系統雛形建置法就是把開發期分段的作法，先完成一小部份的系統，然後再與客戶溝通試者把系統的操作與結果先展示給客戶看，這樣可以減少系統開發失誤的成本，這個就是一個小循環，而系統的維護階段往往因為客戶的需要或者是架構效率上的不良而做改善的動作，這個也是其中的一個小循環，因此研發的工作往往就是這一些小循環的結合。

如何評估這些大循環與小循環的時期與績效的評估管理，一直是研發人員自我掌控的，也因為這些循環工作，即使有很多的標準文件，也會有累積性不容易交付下去，所以會造成兩種情況，一家公司往往要養一些人來解決一些老舊MIS系統的維護人員，然後系統的問題也不會變得更好﹔或者是一名待很久的研發人員覺得一直在維護期而沒有成就感，兩個循環累積的事情多了就覺得無法成長。

所以，解決的辦法除了分清楚大循環與小循環的時期之外，研發人員千萬要努力於自我的成長(不只是在技術工具的學習)，把這兩個循環都做好，不然絕對會有職業的倦怠，而老闆也要認清研發人員絕對要做好這兩個循環的時間分配，與重要性的安排。

軟體開發人員努力的方向分類：職場

觀察一般軟體開發人員已經有十年左右了，給我們一般人的印象是，有理想、自戀、不妥協，而偏偏在這個時代要完成一個好用的軟體系統，這三個優點恰巧成為團隊合作的致命傷，所以通常一個技術性高的研發人員常常被貼上為不合群的標籤，而技術性不怎麼強的人也因為團隊EQ特別高而常常會有錯誤的評斷。

如果我們簡單的把技術力與完成力這兩個面向的拆開來看，技術力指的是程式語言(C++,JAVA,VB...)的使用熟悉程度、系統架構分析的能力、開發平台的使用(OS,SQL Server...)、看見未來的發展等等，選擇對的技術方法可以在開發成本上節省不少時間及金錢，但是這些技術成本往往很難去評估的。

完成力這一個面向指的是品質的承諾、使用者的溝通介面、可被實踐應用的系統，這一個面向如果是大眾所使用的系統往往是利用大量的廣告行銷來塑造一個成功的產品，如果是一個專案的話，就是有一個專案經理來串連軟體開發的過程，跟廣告公司的AE，有異取同工之妙。

我觀察的程式開發人員往往在技術力不斷地提昇自己，但是並不會特別在完成力上面特別的努力，也是因為在完成力上面的努力成功無法很簡單的用數字來評量，也特別的看不出成果，他們或許已經覺得非常貼近客戶了，但是客戶無法那麼理性的使用開發人員所假想的系統，那如何要程式開發人員努力去學習完成性呢？

我認為有幾個方法，多多與人交談不要怕無聊，唯有相信別人的看法才有辦法改變自己的想法﹔培養神秘的第六感，不要一直用邏輯推理來想事情，世界上的事情有超過一半以上現在是無法解釋的﹔試著在合理的範圍妥協自己的程式架構，尤其是介面程式部分，雖然可能未來會證明你可能是對的，但是現在你的程式是錯的。

程式開發人員的技術力提昇的風險非常大，好不容易把Windows NT平台搞熟了，VB也用的很熟練，結果有可能一夕之間變成　Linux+PHP或者是C++ 的開發環境，所以，一定要保持隨時學習的心態，而解不光在技術的提昇，也要重視完成力的提昇。

研發團隊的創意管理分類：管理

最近的報章雜誌一直在討論的話題不外乎是不連續式創新（數位雜誌 12）、創新企業管理、廣告創意、即興創意、這麼多『創新』的議題被討論在各行各業之後，本專欄擬發行30期後改為比較實際的軟體開發的個案討論，希望大家多多支持，也給我意見，持續了半年的思考，我會繼續在軟體開發路上努力，隨時『創新』的精神仍會留著，只是希望不要被大眾媒體一炒作後，讓大家失去了理想。

我們重新思考了一下創意的定義，研發及表達可能有用的新鮮點子的過程，一般總認為是在一個人的身上去完成的，而這些點子必須是可執行的，可運用的並且在團隊中達成共識，這些過程，永遠少不了團隊的溝通合作，所以一個大企業，甚至一個小的工作室，基本的創意過程都是一樣的。一個團隊重要的創新過程應該注意下列的事項，去除共同合作的障礙、利用異質人員的排擠心理、整合性思考評估。
　
去除共同合作的障礙，一個團隊一定有不同角色的人，甚至同樣是程式設計師，他們的想法也會南轅北轍，如何破除成見攜手合作，必須去創造一個共同的研究主題，例如類神經資料庫，人工智慧等等，而在系統的開發方面，就不能以研發單位來自居，必須與客戶服務或是業務行銷單位共同思考，簡單地來講，要去除這些障礙就是單位之間的溝通與人員之間不能有高低之別，這樣才能共同努力。

利用異質人員的排擠心理，一個產品要賣的好是一個企業所有人努力的成果，所以一個有創意的專案，必須給所有人思考的機會，如果一項產品全由軟體工程師的角度出發，設計出來的系統常常操作十分的複雜，雖然架構上非常合乎系統設計的邏輯，但是一定不好操作，而一個完全由操作系統的作業員想出來的系統，雖然操作可能十分的便利，但是往往無法程式化或是無法做好事後的統計功能，如果要完成一個良好的系統或產品，事先一定要融合所有人放下所有的專業角度，一起來腦力激盪，藉由不同角色人員的排擠心理，摩擦出新的火花，雖然這個過程的風險極大，有可能每一個專業角色的人員，會覺得不受尊重，但是這是可以讓團隊有『創新』運作的辦法之一。

整合性思考評估選擇，一個好的系統要去執行，除了要有上述的異質人員的結合之外，要整合這些意見，說服每一個人為何要這樣執行是非常重要的，因為討論的過程中有很多人會僵持自己的想法，而不妥協別人的看法，如果是好的創意，應該要有一些選擇方案，並且在事後評估，一個好的創意發想是在執行之後，還能不斷地檢討，創新的過程並不是樹枝狀的結構一步一步執行，應該像是一團的雜醬麵，糊在一起的樣子。

一兩個人做事容易，創意的發想也很簡單，但是一個團隊要經營的好，這些創新的過程非常重要，不然我們研發出來的產品，很可能只會依照競爭者的腳步在後頭追了。

品質對於軟體系統的重要性分類：系統

看看市面上的書有大部分是教程式設計師如何應用工具，如何用 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...)，也有標準的認證伺服器，而安全性包括使用者的基本資料與歷來的交易資料，也包含了使用這一整套系統的權限，這個在系統開發之初就一定要考量的問題。

網路時代的軟體系統開發雖然也趨向標準化了，但是，一個系統的開發必須更謹慎的評估，才不會失去他的擴充性。

創意模型與軟體系統開發模型分類：創新

每一種行業或者是說每一種專業，都有所謂的『模型』，就是事情思考運作的模式，有所謂的商業模型、組織模型、營運模型等等，我們要討論的創意模型與軟體系統開發的模型如何整合在一起，是我們要不斷地學習的地方。

創意模型，思考過程與方法是最重要的，經常性的『跳脫』，有助於提供更好的解決方式，並且讓你更清楚你目前的阻礙在哪裡，要了解目前看事情的方法外，真的還有其他的替代方案存在﹔找尋『刺激』，把一貫的想法和對事物的評價分開了看，思考的過程或許要犯錯才能達到快速或正確的解決方法，人往往在說話之後，才會找到說話的理由，雖然接受刺激的心理不是很舒服，但是刺激之後的想法會穫得不少的改變，至於這些激發創意的這兩個過程與方法在運用的時候，心理面最好能分辨，而這些技巧要長時間的訓練而達成的。

軟體系統開發的模型，我們在第十期有做簡單地說明，就是瀑布式、螺旋式與壓縮扭曲後的開發過程，這些開發模型依照每一個專案或產品的不同會有不同的方法，如果隨著開發工具的不斷提昇，加上創意創新的組合，會有千百種不同的運作模式，而時間的因素是我們一直考慮不周詳的地方，也是軟體開發為什麼無法掌控進度的原因。

簡單地舉一個例子，如果有一個專案，是進出貨管理系統，我們一定要做使用者訪談的工作，但是系統分析師去訪問了兩次，發現使用者以往的工作流程過於繁複，有些是因為紙上作業或方便上司查核，或者是莫名的原因而做的流程，系統分析師會不斷地內心掙扎，到底是原來的過程如何改變呢？這時候用的方法往往是依照原流程『不變』，當系統完成之後，使用者會發現比原來的作業更繁複。

當系統分析師利用創意思考的方法，找到更好的運作流程而將資訊系統做了大改變，而且作業過程簡化後，將查核的功能自動的做進了系統，等到系統開發好了，也除錯到達一定的階段，這時候的使用者因為少了很多很多的步驟，掌控的資料量少了，變開始對系統不信任或者是有不安全感，往往會開始抱怨，這時候要改變的就是使用者的心態，或者是使用者對外溝通的模式整個改觀，雖然我們的例子過於極端，但是一套資訊系統的開發，真正的是影響到一個環境內的運作與思考模式的。

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

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

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

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

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

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

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

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

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

軟體開發的領域中有很多文件化的分析方式，例如從最早的資料庫系統(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)這本書拿出來研讀，再研究一下如何創意思考，其中有一個方法就是心智分枝圖，把問題寫在一張紙的中央，並且畫了一個圓圈，然後想一些分類的方式畫出分支，然後從這些分支中找出答案，這個方法雖然天馬行空，但是是很好找出這個問題的解答，或是相關的話題。

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

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

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

資訊導向組織與知識管理分類：管理

從十年前的硬體公司轉變為熱門的電子產業，到去年的軟體公司變成熱門十足網路公司，國外的產業分析師認為，未來所有的企業都是網路公司，這些轉變顯示產業的變遷，而這一時期的重點並不在是不是成為一個網路公司，而是調整企業組織的精神。

自從網際網路的興起帶動了即時訊息的革命，我們不用再透過傳統出版的流程，就可以很快的透過網路來溝通與獲知消息，傳統地域性的知識機構，例如大學，圖書館所扮演的角色可以完完全全的透過網路來傳遞，商業化之後的結果使得知識的傳播，流行的傳遞，大大地降低了成本，而知識的管理成為一個企業重要的生存價值。

軟體業在台灣往往是以承接專案為主，製作套裝產品的公司由於經營通路的成本過高，又有退貨的種種風險，所以並不是很好經營，但是透過網路與軟體委外的風氣，這兩種性質的公司不斷地會轉移經營的方式與建立起另一種的核心能力，這種能力就是資訊導向組織的管理方式，我們看一看一家醫院為例，為什麼能正常的運作，就是因為管理當局制定明確與簡單的共同目標，並且可以讓組織的成員轉化為具體的行動，由於醫院裡面都是專業人員，怎樣把目標訂立清楚就要靠院長的領導能力，而內部所有的人員都要負責傳遞訊息，明定傳遞訊息的責任歸屬是非常專業的組織重要的。

如果把醫院的資訊導向組織轉為目前軟體業的組織，我想要維持競爭力，或是維持能繼續生存的要素，就是經理人才的挑戰，大多數傳統公司的組織是非常的垂直或是非常的水平，但是一個組或者一個部門的主管管理非常多的人員，但是資訊導向的組別不能太多，一個組也不能非常大，大部份的經理人也要肩負部份工作內容，所以如何認定一個經理人合理的生涯規劃與共同的願景，甚至一個組織的團隊績效評定都是非常困難的，看過一些廣告公司甚至獨立出一個知識部門來處理經理人的定位，是比起大的系統公司有產品經理部門要好聽一點。

一進入一個大企業往往要填寫的表單多到另人困擾，但是這一些表單要做的只是最起碼的內部溝通，我們不要忘記這些表單的精神，只要組織中做好對於知識控管與應用的事情就足夠了，而這些經驗不是都從無生有的，是要從過去的人學到一些經驗，軟體工程師有大部份的人格特質是要自己來，不要用別人的經驗，有創新的想法卻缺乏溝通能力，比起醫院的專業分工管理，我看每個人都要有更多學習的心態，也就是知識的管理。

創造能開發創意的組織環境分類：職場

當組織由實質的環境轉移到虛擬的空間時，一切機會與挑戰也變得更加驚人，現階段很多人以為虛擬的空間就是網際網路，但是這個虛擬空間的原創者，就是遠在天邊近在眼前的『腦』，而網路空間的應用，只是啟發創意的輔助工具罷了！

我們觀察麥肯錫行銷顧問公司的運作模式，專案就是一切，專案小組是營業收入的來源，他們的小組成員每天的飛來飛去，可能上個月在舊金山，下個月就要進駐芝加哥其他公司的辦公室，因此他們強調的是『取得』的文化，投入奉獻的感覺，而不只是再作秀而已，麥肯錫從事的不是一種事業，而是一種專業，他們是『替』客戶做事，而是『和』客戶一起做事，而沒有非常明顯地訓練課程，工作中學習，就是一種非常好的訓練。

我們再觀察VeriFone公司，他們完全不設立總部，他們建立了一個全球龐大的資料庫，使全球的員工共同享有這個資料庫，使員工全都有天涯若比鄰的感受，由於實際空間的分散與通訊的結合，使得公司擁有迅速而附創意的驚人反應力，網路就是創意的催化劑。

軟體的開發，當然是一種專業，但是這種專業訓練工程師變的非常的死板，事事講求邏輯，這個邏輯是程式語言的邏輯，不是現實生活的邏輯，也不是客戶需要的邏輯，所以開發產品的時候往往會變成用自己的眼光來看事情，一個組織的所有不同人與環境要培養共同關心產品的責任。台灣的軟體公司因為人數少，所以溝通非常的迅速，產品的開發也能很快的貼近客戶的市場，但是往往要轉型成為大公司的同時，因為溝通的環節愈來愈多，造成轉型的失敗。

我們回憶自己的生活空間往往都是自我的舒適空間，在一個組織裡面，要激發創意，有兩個方式，第一個就是創造一個安全隨性自由的空間，並且能讓同事互相溝通的場所，即時能夠讓某些人出出洋相也沒關係的空間，第二就是要適著改變自己，也就是想辦法自己逃離舒適空間，這一項的成功就是要靠自己了。

軟體開發的核心技術？分類：系統

您曾經舊地重遊，發現就只是一年沒有回去，發現面目全非嗎？一套軟體系統，比較不容易有這種感覺，但是一個網站，經常會有這個動作，不斷地換版來吸引人潮，但是只要是服務的精神或產品的架構沒有改善，這種經常裝潢的動作，是沒有用的。

如果把軟體系統的開發拆成很多的面向來看，使用介面、管理核心、系統架構、危機風險、避免錯誤、對外溝通......等等，我們往往常會用工作進度的導向方式來管理軟體的研發團隊，而忽略的其他的過程，而其他部門看到軟體的問題往往就是舊的系統有問題、新功能未能趕上市場的速度等等，這些部門的互動之後，往往產生惡性的循環，有洞補洞，而補出越來越大的洞。

所以說，要快速的達成軟體系統的開發，最好能注意所有的面向，而一個成功的網站之所以吸引人潮，除了門面之外，背後的自動化管理系統，是最重要的一環，隨著網路服務的拓展要同步開發的系統，而一套運作良好的軟體系統要同時怎樣兼顧速度呢？除了撰寫程式碼物件導向化之外，上述的所有活動都要朝向物件化的精神----繼承重用，寫程式碼最簡單的是用別人的元件，但是，系統架構、避免錯誤、對外溝通要拿別人現成的，要拿別人現成的成果，必須花一番功夫消化吸收後，才能套用到一項產品或專案的開發程序，而這種開發的過程，就是一家軟體公司的核心能力 ，有人做會計進出貨管理系統，有人做汽車保養場的管理系統，都有各自的核心技術能力。

這些軟體開發的過程針對不同的產品，有非常不同的控制機制，為什麼一家公司可以生存重要的也是這些控制的過程，一個網站的使用介面重要，但重要的是他的內容方便使用，一套軟體系統除了畫面夠炫使用方便之外，重要是他的實用性切重要點。

開發軟體重要的創新，是以人為主的創新，開發系統創新在使用介面，也在使用的架構，但是也在團隊的合作與對外緊密的溝通，不同產品有不同的創新，多多觀摩應該是最好的學習做法。

網際網路對軟體產生的變革分類：網路

雖然過了西元2000年，觀察生活的週遭，您會發現小店面還是都用到的軟體系統都還在運作，例如：錄影帶ＶＣＤ出租業、洗衣店、汽車保養廠、租書店等等，這些行業用的大部份是PC加上DOS/Windows 作業系統，並跑一些小型的資料庫軟體。

對於這些小店家來說，要更新這些軟硬體設備要耗費的成本非常大，例如一台單機不上區域網路加上新的軟體系統，軟體程式設計的工作室報價可能就要報價20萬元（還不一定有賺喔），這些店家根本負擔不起，因此這些行業除了走向專業連鎖店之外，是否網際網路可以帶來更大的變革呢？

網路夢的背後我們經常看不到成本的支出，以目前專線24小時上網的成本來計算，若要符合基本連線的順暢性至少要有64K的速率，一個月的資訊傳遞費用就要5000-8000元不等，若要考慮要克服斷線帶來的不方便，那付出的成本可能更大了，再來是PC硬體與作業系統加上應用軟體系統的維護問題，一個店家每個月要付出的成本也是非常大但還好只是初期的建置費用，所以這也是為什麼現在所有的店家大部份都只用一台電腦不上網路的原因了。

如果從資料庫系統的維護來看，把資料庫集中化的管理雖然是最節省成本的，但是，網路的成本目前還是那麼貴的情況下，只好把所有的系統安裝在PC上面，然後每日或者是每週的將所有的資料做整理（轉檔）的動作在透過數據機上傳至總公司的做法是目前大部份連鎖企業的做法，展望未來若是網路的成本降低，上網路的家電又能降價到某一個程度之下後，或許，ASP行業才能真正的興盛起來吧！

如果以洗衣店為例，預測未來，是所有的洗衣店會共用一個網站的資料庫系統來建立與客戶的服務，還是會有一家大型的連鎖洗衣店負責收件配送服務，在物流、資訊流與金錢流方面，相信會有一個大的改變。

延伸閱讀：【網路】『應用軟體供應商』是軟體公司的契機

如何引發程式設計的興趣分類：職場

做一個行業或扮演任何一個角色的時候所能支撐這個工作的最大因素就是興趣，有些人在一個工作上可能忙碌地度過了幾年，還不知為何而做？

我曾經去拜訪一家證券期貨公司的老闆，他提到他要找的業務人員本身就是很喜歡操縱股票的人，除了有專業的基礎之外能夠把客戶的股票當成是自己的投資，才能吸引到想信賴業務員的客戶。所有想要做網路事業的人更是如此，要規劃網站就要找到每天都能分析各種網站的架構的人，要做一個專業的程式設計師就要每天研究舊系統的架構及寫法並想辦法跟隨新的潮流。

其實，一天到晚在電腦前面寫程式真的很容易缺乏興趣的，如果想一想客戶因為你開發的功能而減輕工作的負擔，或是創造一些更新的需求的話，而這些是幫忙別人所做的事情。為了自己，程式設計師更需要想一些方法來降低開發的流程，共同在一個團隊中努力。

程式設計師所擁有的工具是最多最完整的，如果用C++來開發程式，我們經常會陷入一個迷思，就要用C++來寫程式解決既有的問題，目前的Windows平台可以從網路上下載很多免費或收費的工具，這些工具只用能適用在我們的開發平台上，無論是自己建立的程式庫，或是別人開發的，能利用現有的資源來解決任何問題是程式設計師最要訓練並把它當成興趣重要因素之一。

小時後，經常遇到的作文題目是『我的興趣』，我想真的很難把『程式設計』當成是興趣吧！但是相信很多人把『玩電腦』當成興趣再寫，至於是玩什麼，範圍真的很廣。

網際網路架構的新思考分類：網路

一套系統往往要連接到後端的資料庫這是以往的 Client/Server架構，網際網路的興起帶來了新的架構，不只是3-Tier或是N-Tier，他的網狀架構，帶來了無限的創新方法。

我們舉最簡單的例子，如果我們撥號上網到某一家ISP去的時候，最簡單的帳號密碼認證系統往往連接到該ISP的資料庫去做檢查的動作，但是如果你到國外去的時候，如果你有申請ISP的國際漫游服務的話，您只要用原來的ISP帳號就可以撥上國外的ISP，並提供上網的服務，這個就是2-Tier延展成為3-Tier的一種溝通通訊模式。

如果說這種認證的類型不只是用在上網際網路的撥接服務的時候，我們上網看到某一個商品服務，想要立即購買的話，只要打入信用卡號碼或者是銀行的帳號，立刻可以扣款並且得到這些服務，這就是金流，如果我們還停留在以現鈔交換貨品或者是實體線路的思考模式，可能沒辦法達成創新的系統設計，因為網際網路把全世界打通了，安全性與可用性的落實，完完全全掌握在這些通訊協定與資料庫的同步上面。

HTTP通訊協定的CGI(Common Gateway Interface)加上超連結，我們可以把不同的資料透過網際網路來交換，以最簡單的廣告服務來說，以前的廣告公司要負責市場調查、行銷企劃、廣告設計製作、媒體購買，這些流程雖然還在，但是已經壓縮在一台廣告伺服器之後了。

HTML的超連結語言溝通了全世界電腦，往後的XML語言與種種分散式的應用程式，我們要走的路還有很長呢！

從結構化到物件導向分類：系統

幾年前，一套程式系統用的分析方式，往往脫離不了靜態的畫面顯示，動態的資料輸入，以及資料的處理運算功能，這三類問題的處理只要能夠被表列出來，就能夠架設並完成一套良好的系統，這個就是結構化的分析方式。

但是隨著需求不斷地增加，電腦速度不斷地提昇，大量競爭的商業環境，物件導向的演進，改寫了結構化的分析方式，就連最基本的電腦語言也帶入了這場革命之中，從1980年代後期，企業軟硬體委外(Outsourcing)的商業活動抵定後，這些系統整合的廠商無不想盡辦法把『重新利用』這個事當作最重要的目標之一。

結構化的分析是個良好溝通的開始，但是，他的維護成本過高，一個系統不斷地演進過程中，就要有一批人非常熟悉這一套系統，一個新進的人員，要從頭了解一套系統，除了要閱讀所有的文件之外，也要熟知所有改版的歷史過程，而物件導向解決了這個部分的困擾，只要熟知一個物件的所有溝通介面，就可以很快的抽換掉一個物件並更新他的功能，就跟PC硬體的DIY一樣，顯示卡壞了，拔掉插入好的就好了。

這其中的演進也並不完全沒有中間的過程，記得1995年起，非常興盛的Frame-Work的架構，這其中的代表是Borland的OWL，以及後來模仿的MFC，把一個程式拆成文件Document／顯示View的型式，只要依照這個模式開發，會節省非常多的開發時間，但是並非所有的系統可以適用的，所以後來出現的Delphi語言，就是以單純的物件，你知要把一些開發好的元件搭配起來，並協調使用的模式，就可以簡單的完成一個程式。

我並非推崇哪一個特別的電腦程式語言或使用工具，只是這些工具的興起開創了里程碑，所以，不要太在意您用的工具用BASIC一樣可以做到物件導向，用C++語言也可以做的非常不結構化，只要熟悉物件化的原理與結構，一樣可以朝向物件導向邁進。

下一個潮流是什麼？

如何踏入程式設計的領域分類：職場

其實，寫程式就好像寫文章一樣，有些人靈感一來文思泉湧，一下子就寫了兩三千字，甚至三天三夜不能罷休，中國古代的詩人，不也是這個樣子嗎？我們經常說李白是詩仙，喝了酒靈感就來了，但是，他之所以能成功的寫了那麼多詩詞，他的背後也有一段學習的歷程......。

經常觀摩別人的作品，我記得小時候到了作文課是我最討厭的課程，漫長的兩節課，第一節課總是寫不出任何東西，到了下課後玩了一下，第二堂開始也只寫了第一段，最後草草寫完一篇文章。這時候，我們最希望的就是能回家拿出作文範本，希望能找到題目相同，又同時祈禱老師沒看過這篇文章，抄襲的確是非常不好的行為，但是觀摩別人的作品可以有效的增加自己的功力，維護別人寫過程式是一個苦差事沒錯，但是等你看懂了，看完了幾個系統後，不知不覺得你的功力就大增了。

建立一些自己常用的proptype(原型)，寫文章最重要的畫龍點睛效果，就是字詞的點綴，苦背一些成語就是這個意思，但是寫程式著重的是邏輯，所以這些常用的原型，有人習慣是用別人的黑盒子（程式庫），有人是自己土法煉鋼，不管是怎麼應用，把這些proptype用的洽當好處也是要經過時間的驗證與不斷地修改。

不斷地重複檢討系統架構，有些文章是八股文，有些是新聞稿，有些是倒敘法，每篇文章的架構不同，所以要表達的意念也不同，一個系統或是一段程式也是一樣的，常常在心理或是紙上畫出你要寫的程式的系統架構有助於對整個程式未來發展與維護的方向，當你了解程式架構的起承轉合是怎麼一回事的時候，你就成功了。

觀摩作品，建立原型，檢討架構是我認為踏入程式設計的第一步，先選擇一種語言來學習或許是一個好方法。

『應用軟體供應商』是軟體公司的契機分類：網路

應用軟體供應商的英文全名為 Application Service Provider, 也是最近三個月來在軟體業被大家炒作的名詞，很多新成立的公司發的新聞稿也是以ASP的實踐者來推銷，或是以往的EDI也拿來應用在網路上，就變成了 ASP或者是WEB EDI，這麼多的名詞，我想簡單的定義一下什麼是ASP。

ASP簡單的講，分為兩種的供應模式，一種是租賃(Hosting)，另一種是委外服務(Outsourcing)。第一種的租賃模式是廠商投資購買伺服器主機及軟體系統，由ASP廠商負責企業資訊化的工作，這種模式行之有年，一家新的券商或是銀行的新系統要上線，ASP廠商往往進駐三個月到一年完成所有軟硬體系統的修改上線及教育訓練的工作，台電、政府機構等等的系統更新也是用這種模式上線的，這些傳統的ASP廠商有中華電腦、資策會、中國嘉通、凌群電腦......等等廠商，這些資訊化的案子營業額都不小。

市面上有一些大的套裝軟體，例如：會計進出貨系統，也可以視為一種小型規模租賃性質的系統，他幫助您在安裝及操作的過程能順利的使用，但是套裝軟體的服務往往不如包整套的資訊系統，因為他的服務成本過高，不容易達成客戶的特殊需求。

ASP的第二種模式應該是網際網路成熟後的變形，例如現在ISP的虛擬主機，就是簡單的委外服務，只要你付費並提供資料，您的資料就可以被全世界上網的人看到，進一步來說，以往的套裝軟體(會計系統，幼教光碟...)是否可以完全的委外呢?把所有的資訊主機放到ISP或者是ASP廠商的機房中，因為網路的通訊與伺服器設備的執行速度夠快，可以有很多公司共用一部伺服器來降低成本，而公司的MIS部門也因此可以節省很多的維護成本(就是人力)。

所以，委外服務(Outsourcing)應該是應用軟體供應商(ASP)主要的服務型態，不但可以有效的降低服務使用者的成本，也降低了ASP廠商的維護成本，在教育訓練的成本也有效降低的情況下可以說是雙贏的局面，這也是為什麼現今ISP機房雖然在虧損的情況下還一直不斷地擴充的原因吧！

軟體委外的服務可能在初期，ASP廠商要付出相當大的規劃執行人力，但是當很多很多的委外專案完成後，可元件化的服務，可節省的維護成本，可共用的資訊設備與溝通的成本都能快速的再接下一個案子，更能在創新活動上做更佳的變化。

軟體開發流程的壓縮與再造分類：管理

以往教課書教我們的軟體開發流程不外乎有市場調查→需求分析→系統架構→程式開發→測試除錯→正式發行，這一系列的開發過程長短不一，有些常的專案甚至長到二至三年，使得一個專案結不了案，或匆匆結案，造成品質不良或背離原來的市場。

西元1990年代，資料庫的興起後，把『需求分析』與『系統架構』的過程標準化了，很容易的做出一些系統雛形與客戶溝通後便可以順利地進行『程式開發』的工作，而且與當初規劃的市場並不會背離太多，但是到了現在網際網路的興起，各種軟體系統的產品生命週期大幅的縮短的情況下，一樣軟體產品的服務只要拖超過三個月，變失去了先機，要達成佔有率就是非常困難的事情。

因此，現在的軟體開發流程必須在『程式開發』到『正式發行』的流程做有效的壓縮，這一點在現在的開發工具發展已經開發到一定的程度時，特別容易達成，例如一大推的Script語言工具，不用經過編譯(Compiler)的過程立即可以做測試。再來，以往正式發行必須發行使用手冊，壓製光碟片與磁碟片，包裝散佈到各式的賣場，這些過程不斷地被壓縮，未來可能都會變成在網際網路上完成，『壓縮』並不代表說是流程的省略，而是一個產品服務團隊的配合要更加的緊密，能在更短的時間內完成所有流程。

以現今軟體開發的流程來看，市場調查的方式也引發了另一波的革命，還記得寒暑假在街頭上的工讀生在來來往往的人群中做問券訪問的畫面嗎？或者經常接到電話要問您看哪一台電視台的聲音呢？這些在產品開發過程中『市場調查』的流程中未來可能會被放置在產品服務的流程中，大家可以看看一些新聞網站的例子，在每一篇的新聞最末端都有舉辦一個評分的的投票，就是一個最好的例子。

這一波的流程再造的革命中，我們要更加注重『系統架構』的設計過程，在以往的專案中，軟硬體系統經常是不用改版的，或者是很久才會做一次改版的動作，但是在網際網路上，產品的生命週期縮短後，改版變為一個必要的過程，在不斷地改版過程，我們更要注重架構的長期發展。

延伸閱讀：【流程】軟體開發過程階段性目標與相容性做法