不要永遠套用以往的成功經驗分類：管理

開發軟體系統的最怕的就是技術不斷地更新，工程師的專長不一，使用的開發工具習慣不同，形成後續開發的負擔。

一個系統要可長可久，除了隨著時代進步之外，核心技術也要隨時的檢討改變，不要進入了使用的最新的技術工具，寫出一大堆流水帳的程式碼，以ＭＦＣ的Wizard Application為例子，原本的用意是讓程式設計師很快的可以跨入寫應用程式的領域，可是我發現有很多程式設計師因應客戶的需求加強一個功能，就新增一個按鈕，然後把舊的程式碼剪貼過來修改，就交差了。

這樣固然可以達成任務，可是卻苦了後來維護程式碼的人，如果選定用物件導向式的語言來開發，表示你可以利用繼承、封裝與多形等等優點，而各種語言的特性要把客戶的需求先抽象化之後，分析可以歸類的元件物件之後，再行具體化的開發。

所以說，你把寫程式當成寫日記或者是寫流水帳的話，你永遠沒有辦法出日記精選或者是做公司帳款財物的分析工作。

而這個分析的工作是每一個寫程式的人必須要去思考的，分析的過程可以參考以前的系統，也可以參考以前成功的經驗，但是，就僅僅是參考而已。

有了一兩個系統專案的開發經驗，到底可不可以把成功的經驗完全的移植，答案永遠是否定的，我們聽到太多說，以前我就是這樣做的，客戶使用的情況非常滿意，而且後續的改版也非常的快速。這就是我非常害怕的心態，如果考慮當時的環境與現在的環境，有太多太多的不同的，例如：客戶群不同、使用電腦的使用習慣不同、系統的大小不同、系統服務的層級不同、使用的開發工具不同、頻寬不同......可以舉的項目實在太多，而最另人沮喪的答案，時間永遠都是不同的。

成功的經驗雖然重要，但是創造另一個成功才是真正重要的事情，試著接納別人的想法，你會發現你所寫出來的程式彈性很大，也很容易改善，不會被別人隨便講一講需求更改，你又要花一兩天去把之前的程式碼修改一番，這樣的系統才經得起考驗的。

撰寫規格文件的重點分類：管理

一個好的系統除了要有良好的架構之外，他的價值有一大部分是不斷的維護系統而符合需求，貼進客戶的實際需要，這個中間修改的過程除了人的因素之外還有設備的更新，作業平台的轉變所造成的種種變因，所以留下規格文件供未來的人來參考改進非常的重要。

文件撰寫的重點並不是要寫的通順或是像寫小說文章一樣來湊字數，所有的開發文件林林總總，我們這一次討論的重點放在軟體系統規格的部分，由於程式設計師總是覺得寫程式看程式碼就好了，但是如果過了一年之後，你回去看你的程式碼你還會有印象嗎？更何況是別人要看你的程式碼了，其實規格文件的重點只有幾項，就是系統平台、程式碼架構、傳輸協定、檔案(資料庫)架構、模組流程等五大項，有了這些文件，往後的人員只要花個幾分鐘看一下，就可以很容易的維護別人的程式及系統了。

系統平台：其實是最好描述的，只要說明作業系統是Windows95/98或者是Linux、AS/400等等，然後使用的開發工具是VB/ASP或者是Visual C++,BCB 等等，最好要把版本號碼或是一些比較特殊的程式庫也要列上去。

程式碼架構：這一項通常會被大部分的人所遺漏，很多人是靠開發工具所提供的整合環境來分類，固然是很好，但是每個人應用的專案檔案（*.DSW,*.DSP,*.IDE 等等）並不會相同，也就是說你好不容易整理好的專案檔，也寫了一大堆說明文件，但是只是給你自己用而已，這部分最好還是要寫辦法製成文件分享給所有的人。

傳輸協定：無論是區域網路、網際網路的協定，或是單機自己內部傳遞資料一定有傳輸的協定，最普通的當然是TCP/IP了，而現在WEB Server或是EMail Server 的普及很多系統都應用網路七層協定的更高層來傳遞資料，這些都應該說明清楚，如果系統出來問題才知道如何查詢，而Windows系統內的訊息傳輸，也算是傳輸協定的一種，而兩個模組之間的Function傳遞也是，如果是重要且獨立的元件模組，應該要特別的強調才是。

檔案(資料庫)架構：除了關聯式資料庫比較容易寫出規格之外我們經常應用到的設定檔(Config)，例如*.INI的檔案，還有為了系統效能或是儲存資料、交換資料所儲存的資料檔案，應該都要有格式的說明，以及生成時間版本號碼的資訊，有了這一個規格表，即時是程式碼不見了，我們都可以很容易的重寫出部分的模組，而不用經常得去猜去破解一些資料檔的格式。

模組流程：是最早最早結構化資料分析的時候必須具備的流程圖，但是在物件導向的程式開發，我們經常會把流程圖隨著物件化而簡化，但是也僅僅是改良罷了，他的精神就是輸入與輸出的前後順序一定要清楚的表達出來，雖然現在的程式系統應用了很多訊息是觸發的事件來處理或是多執行緒的程式處理，一個良好的流程圖也可以表現出一個系統的邏輯性，有助於找出系統需要改進的地方，與如何維護的方向。

做文件並不是主管或者是某一些人的責任，應該是所有的程式設計師應該培養要定期製作的能力，除了可以有良好的溝通方法之外，也可以重新檢視一下自己的系統架構，把自己的能力向上提昇。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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