專案與產品的核心能力分類：系統

我想目前為止，好像沒有一家軟體公司能同時做好專案的開發，又能做好產品的開發，因為這兩個軟體系統的核心技術與管理方式，是完全不一樣的，除非這專案與產品這兩個部門是分的很開的。

記得我進入第一家軟體資訊服務公司的時候，第一個考題就是這個問題，專案與產品的特性有何不同，現在想起來這個答案還真的很廣，以下是全球麥肯錫軟體調查的分析比較：

　　　　　專案服務　　　　軟體產品
複製成本　　固定　　　　　趨近零
開發方式　分工開發　　　　集中開發
地理特性　區域性　　　　　全球化
客戶關係　一對一　　　　　一對多
管理重點　1.人力資源　　　1.策略
　　　　　2.技術研發　　　2.行銷業務
　　　　　3.行銷業務　　　3.人力資源
　　　　　4.策略　　　　　4.技術研發

如果依照這個分析表來看，專案型的軟體公司的核心技術必須非常重視人力資源的運用，而技術研發也是非常非常重要的，以國內的專案服務來看，雖然成交的金額非常大，但是一個系統經常要把軟硬體甚至維護服務通包，所以經常是很多公司分工處理，有時候可能得標的是外國的廠商，但是在系統上線或者系統維護的階段，其實已經轉包給其他的廠商了，而廠商間的相互聯繫支援並沒有很好的情況下，要結掉一個案子通常況日費時，導致成本上無形的損失。

也因為如此，專案服務的軟體開發公司通常非常的區域化，即使是像惠普、IBM這一類的公司，在世界各國分公司的專案管理也非常的本土化，無法全球化統一管理，經常有人說他們可以利用印度的人來寫程式，用美國公司來保證品質來接專案，我想這個是天方夜譚，不可能成功的，除非是產品型的軟體公司才能達成。

目前軟體產品來看，微軟的確在全球佔有數量最大的作業系統的佔有率，產品型的軟體公司可以透過行銷與策略來打擊對手，只要能夠把佔有率提高，就是產品型軟體公司的成功。

而最近兩年網際網路的發展，除了專案型與產品型的定義被打的模糊之外，大家對於客戶關係管理也愈來愈重視﹔ＡＳＰ的服務營業關係目前是定義在Ｂ２Ｂ的交易之中沒有錯，但是你接的案子是專案的ＡＳＰ還是產品的ＡＳＰ，是一家公司營運核心能力重要的判斷依據，我經常看到很多人分不清楚，就開始作ＡＳＰ的服務，導致目標不明確而失敗。

而客戶關係管理所投入的資源重要的是客戶的數量級與忠誠度的判斷，如果是專案服務，每一個新的專案就是一次的客戶關係的建立，要投入很大的行銷資源去經營，大體來說是不對的。

其實，所有的產業都是垂直結合的，而軟體公司的分類除了先用專案型與產品型分類之外，各行各業運作的情況真的不一樣，而軟體從業人員用程式語言或開發平台來分類，其實是非常不對的。

如何走創新之路分類：創新

最近真的是不景氣，但是我好像沒有因此而停下來的機會，將近一個半月沒有寫新的題目，並不是沒有新的題目可寫，也不是忙碌的不可開交，而是我在思考，我寫的東西對讀友到底有什麼樣的幫助。

回到我當初寫這一系列文章的主題，當時可以說是網路公司紛紛成立燒錢的時候，大家對於新的商業模式，充滿了希望，也因此時時有新的話題，有新的創意出現，大家每天逛網站的時候，討論的是新的行銷方式，新的廣告技術，以及新的系統架構。

這一些新的事務對我們的衝擊非常大，經常以為世界就要變天了，傳統媒體就要消失的樣子，在技術上認為WEB服務將取代現有的系統，所有的通訊協定將被TCP/IP所取代，而所有的網站將會資料庫化，所有的文件將用HTML的型態來表現。

事實上，這些事情一直不斷的在發酵改變，但是舊有的軟體系統架構，舊有的商業模式仍然存在，但是大家會走的更有效率，更往節省成本的方式進行，目前大家總認為失業的問題是政府政策沒有跟上，是產業外移，或者是全球景氣不佳所致，其實，最大的問題，我想是產業ｅ化下的結果，所有的產品都往超大系統走，一次可以服務的人可以無限的大，所以平均成本就可以降的非常低，唯一要解決的就是服務品質的控管了。

創新要熟悉舊的系統架構，大家總以為創新要把舊的東西打破，把現有的系統打掉的意思，其實，真正在運作的系統都一定有存在的價值，相信在一個系統建構的當初一定有他的創新之處，也有他效能好的地方，這些好處，一定要保留住，而有些創新的想法只重視解決當前的問題，並沒有想到目前在運作的系統優點。

創新要多做別人不想做的事情，人的慣性總是安於現狀或是自己習慣的生活方式，這一點我們不得不承認，當你勇於改變的時後，改變的不只是自己，因為自己的改變也需要別人的配合，軟體開發絕對是團隊合作的事情，至於這個團隊有多大，就必須做好協調的工作，如果重視技術創新而不管客戶的需求，或是只管開發新客戶不管就客戶，這些都是不對的。

我們經常聽到一句話，我的工作已經做完了，剩下來是別人要配合修改的部分，雖然在一個軟體系統裡面我們會切開一些模組分組負責，但是團隊的個人並不是跟系統一樣都這麼理性去看待這件事情，而一個大的系統整合起來的時候問題出現在哪裡，並不是單一個人的問題，而是整體的問題，如果未來的路是大系統當道，我們就無可避免的要走整合的路，帳號整合，所有個人資料整合，使用方式整合，將是無可避免的事情。

創新也要懂得轉彎，不要以為改變就是創新，但是創新真的是要利用改變的力量的，有時候一個新的想法真的很好，但是客戶不知道改變的好處的時候，這時候就需要轉彎，可能要慢慢的來進行，尤其是一個系統的操作習慣，所以作任何事情，並不是做到百分之一百就好了，有時候甚至要做到百分之兩百，才能真正的把你的理念發揚給別人知道，而評估這些轉彎所需要的資源，應該是事前就應該想到的，也規劃好的。

創新沒有界線，沒有規則前例可循，我們經常會依照一些書籍或前人的經驗來思考事情，這樣並非不好，只是這樣只是幫助我們避免掉做錯的事情而已，如果要做對做好一件事情，就需要跳脫這一種思考模式，認真的與團隊對話，發揚創新的想法與做法。

創新要堅持，只要問問自己，我這樣的創新是對的嗎？是否符合真的客戶需要，客戶真的有節省成本，也有幫忙到他們嗎？只要是對的，持續不斷地創新才是生存之道。

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

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

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

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

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

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

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

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

找工作面談前的準備分類：職場

要找工作的時候一定會與未來工作的主管面談，而面談的時間通常只有三十分鐘到一個小時不等，要在短短地時間讓未來的公司決定要花三個月試用期的成本，一定要有相當的準備。

保持充分的自信心，工作與學校最大的不同就是付錢的方向不一樣，學校會教你如何做作業教你如何寫程式，但是一個公司其實沒有義務教你如何工作，雖然，很多公司都說有完整的教育訓練，但是記住一點，一家公司是付錢給你來工作的，不是付錢來請你學習的，如果面談的時候沒有自信心可以完成任務，那一家公司為什麼會請你來呢？還有記住有自信心不表示可以亂吹牛，如果不會的事情也不要說謊。

充分表達以前完成的工作項目及經驗，以前的經歷非常重要，無論是在學校的作業報告，或是前一個工作的經驗，最好事先可以把系統的架構、作業平台、系統需求、系統分析、程式模組等等準備好，面談的主管要問的時候，可以朗朗上口，表示你對之前的經驗非常的清楚，不是因為不適應，或是做不來才想要換工作的，而且，有了之前的工作經驗，你應徵的公司才知道你的專長，便於分配新的工作任務給你。

千萬不要說之前工作公司的壞話，因為可能主管也認識業界的種種情況，如何批評都是不好的。

了解自己想要做的工作，換一個工作雖然不是一定要做一輩子，但是總要待久一點比較好，所以工作的環境以及內容非常的重要，千萬不要沒有一點的主見，或是想說公司派什麼工作就做什麼，就程式設計的領域來說就非常多種，MIS管理、純Coding(未來使用的開發工具?)、系統維護工程師、專案分析或系統分析、系統測試，先定位好自己想要做的工作。

先詢問未來可能的工作內容，如果面談的經過非常的滿意，可以進一步的詢問未來工作的內容，但是千萬不要主觀的做判斷來回答應試主管，譬如說不喜歡這個工作之類的，因為你還沒有進公司，完全沒有判斷分析的能力。

了解業界的薪資水平不要提高也不要被壓低太多，堅定自己的想法，不要被主管一砍價就放鬆了，表示你對你自己的能力沒有相當的把握，也不要好高騖遠自己抬自己的身價，未來的表現不好，適用期不過就算了，傳了出去也沒有一家公司敢用你。不要問太多未來公司的配股計劃、教育訓練計劃、升遷計劃等等，顯得好像你只是為了錢為了學習而來，應該問的是公司的願景與競爭對手的關係等等，這樣讓別人覺得你已經與公司融在一起了。

保持愉快的心情去面談，不要緊張。

如何寫好履歷表？

最近似乎是求職的旺季，公司收到不少的應徵履歷表，不知道是年事已大，觀念比較古老，還是經濟不景氣，資方因為有經營的壓力，所以比較強勢慎選來應徵的人員，以程式設計師來講，目前的市場的供需應該還是不足，要寫好一份履歷表，對於求職的人應該非常重要的事情才是。

我一直對於職場的看法是雙方合不合適的問題，而不是誰求誰的問題，找一份適合自己的工作，比什麼評量都來的重要，尤其在系統軟體開發的行業，工作時間都很長，也非常的彈性，如果沒有強烈的興趣，我想涉入的程度不宜太多。

企業老闆找人會有很多的考量，剛畢業的社會新鮮人以及要轉換工作的人，真的比較不容易找到適合的工作了，這一點跟我當初退伍要找工作的情況一樣，我找了兩個月才找到工作，最後雖然只要是程式設計開發的公司，我就去了，但是中間除了面談履歷表我已經修改了好多版本，應對進退也是面談十幾家公司的經驗才抓出來的。

一、誠實的寫出過去的學經歷及成長的過程，由於應徵一個新的工作，老闆雖然有三個月左右不等的適用期，但是，要一個老闆在短短的半小時到一小時間的面談就要決定是否投資你這個人三個月，其實是非常大的風險，所以履歷表非常重視過去的經驗，即使是求學過程中比較不好的經歷，我想還是要誠實的寫出來，例如說重考、留級、暑修、休學等等，我想每一個人不是沒有缺點的，如果面談的主管發現你的履歷不完整而有疑問的時候，你還支支吾吾的講不出來，非常可能在品格分數上扣分很多。

至於經歷的話，老實講目前企業不太喜歡用每年都要換工作的人員，這代表著你明年無論如何還是會離開這一個新的工作的，所以如果你有很多三個月沒有過適用期，或者是做了半年就不想做的工作，可以不要在履歷表上寫出來的話，盡量不要寫，但是如果中間缺洞實在太多了，基於誠實的原則，我想也只有寫了。

二、寫上過去工作使用的程式開發工具及相關系統，開發工具的使用雖然只是工具，但是是進入一家新的公司能很快上手的保證，通常研發人員要真實的在公司發揮極大的效用，能夠真正的獨立作業，大概訓練時間都是半年以上，如果你可以縮短在三個月內就獨立作業，這樣老闆通然願意適用你啦！但是這兩年發生一個現象，就是大家似乎都去上過一些程式開發的教育訓練課程，大家寫的專長居然都是一樣的，大抵是SQL, VB, Delphi, C/C++, JAVA,　ASP, PHP3, HTML。

天啊！如果一個人都精通這些語言語法的話，我想應該是電腦莫屬了，有人會比較心虛，後面加一個括弧，略懂。這一類的人，以我的經驗來看，連JavaScript與 JAVA applet 中間的差別都分不出來才對，甚至對 Delphi 與 PASCAL 語言的了解也不清楚。

三、盡量先了解所要寄發履歷表公司的產品，然後寫作不同履歷表的版本，我沒有鼓勵大家造假的意思，因為每一家公司需要的人才其實不同，一般的應徵者很難在應徵項目上知道你未來的工作型態，與開發工具的應用，如果可以先去了解應徵公司的產品是用什麼工具及平台，還有大部分的架構，然後把你的專長欄，以及自傳的部分補上這一類的經驗談，這樣可能馬上就會得到面談的機會。

四、自傳一定要寫，但是不要太長，一般的人事主管一天要過濾的履歷表可能有百份以上，如果他只有半小時就要選擇可以來面談的人，那麼他只有15秒可以看一份履歷，另外有三秒是視窗開關及滑鼠操作的時間，有練過速讀的人15秒可以看到幾個字呢？所以自傳的第一段一定要學學新聞寫作，把人事時地物以及為什麼要到這家公司描寫清楚，而制式的履歷表表格已經把人事時地給表格化了，所以可以簡單帶過，為什麼想要這份工作以及想要進入這一個行業的動機，就非常的重要了。

五、不要寫一些官樣文章以及拍馬屁的話，例如：貴公司績效卓越，產品精良，管理制度健全，系統開發架構完美......，因為你根本還沒有進入那個工作，根本沒有資格講這些。

希望下一次能談談面談的技巧，如果有人要我幫忙審核履歷表的，可以寄到 a@writers.idv.tw，並且註明要應徵的公司及項目，我有足夠的經驗及時間的話，可以給大家一些意見。

系統維護與開發的交替分類：系統

一般的軟體系統專案大部分會分為系統開發與系統維護不同的合約，所以開發期與維護期界定的很清楚，面對的問題與人更有不同，但是一個公司的產品是否在維護期或是開發期的界定，就沒有那麼的清楚，如果公司大一點，部門一多，要讓每一個清楚知道產品的開發階段，才能做好客戶的服務。

如果單純的從研發部門來看一個產品的生命週期，對投入這個產品的人，花費的力氣重心程度而言，是非常的不公平的。舉例來說，一個軟體系統如果他的生命週期是五年，前一年可能都在開發沒有任何業績，第二年開始有業績而且客戶的需求不斷，第三年的需求可能不多但是客戶要求降價賣出的數目也有比較多，第四年開始衰退想任何新的點子都無法拉高業績，第五年每多賣一套就要多賠一點錢。

以上面這種產品的生命週期來講，研發人員每一年投入的心力幾乎都一樣大，但是成就感只有在第二年而已，這時候就必須調整自己對於這個系統投注的心態，或者賦予這個產品新的生命。看看是要改變客戶群，調整新功能的開發，限制系統的大小，節省維護的成本......。

系統維護在一個大公司應該算是不小的成本，要如何把系統維護的成本降到最低，是一個系統開發的時候重要的課題，不要因為不同的客戶要求而把產品的架構弄亂了章法，這個是產品開發的最高原則。

就心態上而言，一個長期在開發新產品的研發人員，面對自己一手帶大的產品萎縮，總希望賦予更多的新生命，給他更長的生命週期。但是，如果客戶只能掏出一塊錢來買的話，你投入兩塊錢的資源就是賠錢，這時候研發人員就要開發不同市場不同產品線了。

而開發不同的產品，對研發人員來講就是全部重頭來過，平台、開發工具、系統架構會完全的不同，不能用以前的架構套在新的產品上面，壓力似乎非常的大，而這時候面對舊客戶的要求又要應付，因此很多研發人員在這個時候萌生退意，想想既然已經是全部重來了，乾脆換一個新跑道。

所謂『創業為艱、守成不易』這一句話是合起來講的，要同時守好舊產品的收尾工作，又要開發新產品，當然非常的不容易。我經常在與研發人員面談的時候，他們經常會講自己多麼厲害又開發了什麼架構什麼產品，但是問到為什麼要離開那個產品的時候，他們給我的感覺就是沒有成就感，無法發揮新技術......。

了解一個產品的生命週期，用不同的心態去面對，是非常重要的。

系統開發延續性的重要分類：系統

不可否認的軟體開發的程式設計師流動率很高，我想這個是全世界作系統程式開發人員供需不平衡所致，而台灣很多軟體公司因為一個高手離職，往往導致開發的時程受到很大的影響。

要如何解決這個問題呢？大部分想到的就是做好系統分析的文件，補足在開發過程修改的紀錄，而公家機關的做法往往是要求列印原始程式碼，但是我認為這個只是消極的做法，我想一個維護系統的公司倒閉，要較另一家公司接手，也是曠日費時。

最近看到微軟在宣傳新的平台，仔細地看清楚文件，原來這些都是兩年前的訂下的規格，目前只是重新包裝出來行銷而已（當然微軟也放棄掉很多自己訂的規格），而這兩年的期間我相信參與新平台的系統開發人員一定也是一直有更替，他們是如何延續當時的理想的呢？

我想有一個遠大的目標是不夠的，強制找出所有的系統模組的規則，並且認真的去討論內容，而且是讓每一個開發人員都了解為什麼要這樣做？不斷地演進我想這一句話說的容易但是做起來很難，光光開出一個規格一個模組就很難能讓所有的開發人員的意見相左了，還要去挖出對每一個模組要求的效率及通訊規格的一制性。

一個大的模組可能是一個人開發，但是大的模組裡面又有小的模組，比較難的是要求小模組之間的應用的正確性，人往往會有惰性，總覺得只要把要求的模組開發完成就好了，不管模組內部未來發展及維護的問題，我想即使是一個人開發，也是要依照上面的原則去思考系統的架構的。

而一個系統總是有歷史的軌跡的，面對一個新接手系統的人，一定要想辦法完全了解所有模組，為什麼要這樣子作？什麼模組是因為以前的電腦處理速度問題所做的最佳化？什麼模組是因為客戶專業性的重要需求所做的處理，我們往往會用現在的眼光去判斷以前的系統多麼不何時宜，系統架構多麼不好維護，但是總是沒有看到一個舊系統如何滿足客戶的需求及功能強大的優點。

系統開發不是水平分工的行業，如果光是靠資料庫就可以達成，或是靠建立一個網站就可以做好的話，這樣的進入門檻很低，也很容易在競爭的環境下被淘汰。所以，延續一個系統的強韌及不斷地開發是軟體開發人員先要了解的課題。

系統分析、程式設計與品質測試分類：職場

最近，公司又在徵人了，原以為在不景氣的環境下找到適合的人才非常容易的，但是，事實上並非如此，好像比一年前更難找到合適的人。

在與程式設計師面談的時候，問問他們未來的生涯規劃的時候，他們總會說做做兩年的Coding工作，然後想往系統分析的工作領域前進，意思就好像是程式設計是比較低階的工作，系統分析是比較高級的工作。

事實上在業界並非是如此的，如果公司的規模大到一定的規模，可能會區分出來系統分析與程式設計不同的角色，有時候甚至連系統測試的部門都會出現，但是這幾種工作並沒有貴賤之分，簡單地來講，甚至薪資都是差不多的呢？有時系統分析師的薪水搞不好是最低的。

我想會形成這種錯誤的觀念應該是教科書上面的流程所教育的刻板印象，大家把系統分析想成了所有系統的決定權就在那一瞬間決定了，還有所有的模組分類都要在那一個動作做好，老實講，這是天方夜譚，其實系統分析師的工作定義應該是與客戶需求的接軌而已，有時候甚至對於客戶的成本控制都不在他手上，如果可以分析出所有的需求，然後客戶也同意如此的規劃，系統分析師就算達成他的任務了。

而品質測試工程師有時候會覺得無奈，總覺得有很多的責任要他們來扛，而他們所能控制修改系統的能力又幾乎沒有，我想這個也是對於工作角色定義不清楚所致，簡單的來講，測試工程師對於整個系統的演化結果及客戶的結構環境要有很深的認識，有些程式設計師總覺得測試人員實在是非常龜毛到不合理的地步，我相信有很多是測試人員對測試的方向，客戶需求扭曲的認知，這一點如果光靠系統分析師來定義並不是好的，應該由這三種角色的人共同討論定義的。

所有組織的角色扮演並沒有很明確的定義，如果您更了解您的工作環境及團隊是怎樣的，我想最好還是說清楚講明白。

程式設計師學習的方向(2)分類：職場

在十年前的任何一家公司，總認為程式設計師是所有電腦的主人，只要是操作電腦的任何小問題，都會呼叫程式設計師來解決問題，表面上程式設計師雖然是電腦的主人，實際上表示了電腦應用程式的操作介面與實際的應用有很大的出入，這些問題讓永遠關在辦公室的隔板內的程式設計師永遠想不透，為什麼使用者的頭腦一直不能轉過來呢？

問題並不完全在與使用者，大部分的問題是在獨立寫系統的程式設計師，因此團隊合作與討論，是程式設計師必要面對的重大問題，也是能不能往上發展的關鍵之一。

保持開放學習的心態

程式設計師總認為自己是最能學習的一群人，其實是要看角度而論，某些人在學習新的技術而言，是最快最能應用沒有錯，但是在與系統工程師的實際每日作業或者與客服人員，甚至使用者，往往沒有去深層的感受他們的需要，或是他們的操作習慣，想想看電話從撥盤式到按鍵式中間有多少的過渡期間，就知道操作介面習慣對使用者的重要性，而程式設計師往往面對複雜的系統架構，想改的更完美更結構化，往往會改變大量的操作介面，這一件事就是必須多多了解使用者的地方。

一個專業領域的程式設計師，也必須了解該項產業的專業常識，這個跟念傳播科技的記者有一點像，總不能跑醫藥新聞完全不了解醫院組織制度與醫藥術語，跑立法院總統府不知道政治角力與地方勢力吧？如果你要寫圖書館的管理系統，你就不能不知道，圖書分類與資料收集的基本常識吧！寫會計系統的程式設計師，就要了解應收應付帳款與財務報表的種種細目。

任何行業的專業領域常識不是一年就能完全熟悉的，大學的基礎教育都是四年，更何況實際在業界應用的比大學的理論應該學習的還要更多，如果你選定了一個專業行業要往下紮根，千萬不要一年兩年就轉換不同專業的程式設計，這樣會讓你的程式設計永遠在做一個循環，表面上你學到了不同行業的專業領域，實際上只學習到皮毛，而學習到的只是不同的系統平台與程式設計方法，或許有人會願意做到不同行業的學習，然後在選定一個行業來衝刺，這樣也是可行，但是時光就這樣淡淡地流逝了。

真正的團隊合作意義

團隊合作並不是把自己分配到的事情完成就好了，其他的事務就是別人的事情，雖然軟體開發有專案經理或是主任、組長的分配，但是程式設計師面對的不只是專案書面定義的介面而已，還有人與人的介面，把自己與別人定義好的介面做好只是做到六十分而已，軟體系統在整合測試，甚至是上線的時候，都會因為考慮的不夠周全而出現問題。

甚至是經驗良好的專案經理都會遺忘重要的過程，更何況一個專案一項產品的推展，永遠都是世界上唯一無二的系統，一個團隊進行的合作不是一個會重複的專案，所以只要每一個人多用一點心了解別人在做的事情，互相Cover對方的事情，這樣才能做到一百分的境界。

不要限制自己的未來

任何行業最怕的就是限制自己的未來，程式設計師目前看起來前途一片光明，一般公司最不會裁員的就是程式設計師，但是就是因為這樣，程式設計師往往就在自己的習慣領域裡面做事情，例如有人用C++寫程式，他就不會用ASP或者是資料庫的方式來解決問題，反過來說，有些人非常熟悉資料庫，往往他就不知道檔案系統或者是自行記憶體的配置來加速系統處理的效能，而這些事情往往決定了一個程式設計師的未來，人往往是把自己的未來限制在某一個領域。

廣義的來看，程式設計師也不一定要一直寫系統，他也可以有機會規劃一個系統，從各個角度去完成一件工作，系統工程師維護系統的角度，客服人員面對客戶的角度，業務人員與客戶銷售的技巧，這些都是要多方接觸的，不要認為角色的定位而不去接觸，如果程式設計師只是寫程式，那麼這一段路除非你有你夠專業的技能。不然，路會愈走愈窄，風險也愈來愈高，我認識的人也有如此的，但是要自得其樂並不是非常容易。"

程式設計師學習的方向分類：職場

程式設計師是一個辛苦的行業，很多公司的程式設計師加班沒有加班費，自己設計的系統有問題的時候，還要二十四小時待命，有時為了一個Bug幾天幾夜沒有休息，有時候寫不出客戶想要的系統又睡不著，有時想出一個很好用的架構，老闆又不以為意，程式設計師真的如此命苦嗎？

注重系統開發的所有流程

程式設計也是可以被規劃計劃的，只是因為寫程式設計軟體的彈性太大，所以忽略規劃的事項，任何一本系統分析入門的書都會講到系統規劃的流程，但是我們都沒有實際的去作完成每一個步驟，很快的就丟給程式設計師去作寫程式碼的工作。

其實，程式設計師自己應該負擔大部分的系統分析的工作，這個跟大家頭銜的認知有很大的關係，大家往往認為系統分析師是不用寫程式碼的，而程式設計師主要的工作就只是寫程式碼，所以中間的流程往往沒有確實的完成，而程式設計師寫出一個系統後，往往又是因為時間的因素，老闆想要搶時機，忽略了品質的控制，造成不可磨滅的失敗。

架構的討論與分析

一個系統一定會分成很多的模組，各種模組之間都有溝通的介面，我們往往因為維護了一個大的系統，不太敢去修改介面或是整個系統的架構，怕引發更大的問題，一個不斷開發中的產品，系統架構是非常重要的，如果一定要修改，一定要分析討論後進行，不要有鴕鳥的心態，除非該產品已經是夕陽產品，不會再有收入進來了。

各種平台與程式語言的了解

沒有一種永遠好用的程式語言，而且各種的應用都隨著市場及客戶的需求再改變，所以學習新的程式語言是必要的，更何況語言的本身自己都一直再演變的，學習程式語言千萬不可以只學習語法，或是只是會看的懂程式，要從原理根本的去學習，當然也不要一直學新的，就一直應用在新的系統上，造成後續太多的程式語言及語法存在一個系統，維護上的成本過大。

除了給自己未來更大的學習空間之外，只要是好用的程式語言都可以應用在未來系統上面，例如Ｃ＋＋剛出現的時候，我就看過有人在Ｃ的編譯器下寫出類似物件導向的程式碼，而那一段程式碼至今仍然不會退流行，程式碼的可透通性也很高。

創新就是改變，如何做好組織變革分類：創新

在軟體系統設計下，有人以為學新的技術就是創新、有人以為接觸新的產品就是創新、有人以為只要用不同的程式語言來開發就是創新，而反過來說，有人覺得維護一套舊的系統，過時的技術就無法創新了，其實這些都是不正確的想法，我認為比較正確的定義是，只要您做的事情是不會讓錯誤重複發生的，就是創新，這就是改變。

對於一般人來講，談創新容易，但是大家的認知不同，當企業要做組織變革的時候，太強調這種改變的好處，但是大家的前方總是一團迷霧，無法具體化的實行，更何況不變的好處或許更多，因為創新帶來生產力的提昇、企業收入的增加都無法具體而且快速的反應在公司的管理制度裡面，所以說，或許我們可以反過頭來列舉不變的好處與壞處，讓所有的人加入創新思考的領域。

如何把一個企業中組織變革的阻力化為助力，我認為有下列幾個方法，並不是一處可及的。

開誠布公，不斷地說明清楚創新的好處，並且試算變革出節省的成本與未來的展望，一般人會有兩極化的反應，一是更加的努力工作，大家以為多做一些工作就可以免於改變，另一種是消極的反抗，解決方法如下。

多聽聽別人的想法不要爭辯，通常一個創新方案提出來大家討論的時候，會有20% 的人欣然接受，而可能也有20% 的人嚴重的質疑可行性，另外剩下的60%可能沒有意見，所以如過這種創新方法是對的，而且有信心可以完成，我們應該多聆聽60%沒有意見人的想法，另外剩下反對的20%你可能做什麼都沒有用，試著用辯論的方式只會讓其他人有疑慮罷了。

進入探討的過程，只要大家有信心去做組織的變革，這時候的過程才真正的重要，往往一般企業忽略了這段時間的努力，造成失敗。這個探討是大家一起努力出來的，因為事情已經開始執行了，如果中間執行的不順暢，只要大家一起探討努力前進，不要想走回頭的路。

察覺並承諾，組織的變革並不能很快的看到成果，所以領導人要注意觀察這時候組織內細微的改變，只要符合當初創新的想法，就要給予鼓勵給予承諾，這樣的變革才能成功。

創新思考的幾項迷思分類：創新

創新就是使用新技術嗎？

如果以ＰＣ的硬體發展的趨勢，加上軟體技術的日新月異，很多人使用快速的軟體開發，導致所有的程式設計都想學新的技術，但是我們一定要回頭想一想，新技術有降低成本嗎？新技術對未來維護有方便性？新技術可以符合產品的需求？新技術對於軟硬體支援有相容性？新技術有制定標準規格？

如果這些答案的評估都是正向的，當然可以使用新技術，但是創新的要點並不是使用新技術，只是用了新技術可以比較容易達成創新的目的，所以即使通過了上面的檢驗，我們還是要先制定產品創新的規格才能繼續評估，是否使用新技術。

創新就是開發新功能嗎？

有人以為不斷地提供新的功能給客戶，就是創新。其實大大的不是，創新應該還是要符合客戶的需求，如果這個需求只是為了改版而改版，根本沒有符合客戶的最大使用功能來修改的話，可能不要改來的好，因為改了版本還要經過一段時間的陣痛期。

而有時候一項好的創新服務可能只是改了功能表的位置，按鈕的熱鍵設定，或者產品的重新包裝，甚至只是操作手冊線上服務的字眼，或者只是行銷計劃重新組合而已，所以，新功能可以是創新的一部份，但是並不是大部分。

創新就是與別人不同嗎？

我們經常為了與競爭對手做一些區別，會想出不同的操作方式，或是畫面的設計排列重整，有些時候是非常不好的，例如當大家已經熟悉跑馬燈是由右至左跑的時候，如果你跑一個由左至右的跑馬燈，一定沒有一個人會習慣的。

如果一個系統已經沒有創新的空間的時候，千萬不要在變花樣去想與別人不一樣，可以在系統的效能，系統的架構去想創新，抄襲別人的東西雖然想起來不好，但是如果要改變所有人的操作習慣，可能沒有人要使用你的產品的。

而與別人不同的地方應該是讓人更方便、更迅速獲得想要的內容、或是更能壓低成本的創新。

創新思考的幾個方法分類：創新

點子在你需要的時候就會有，不要想破頭。

我們經常聽人家說想到一個好點子是需要有第六感，或是有神來之筆，所以在思考的時候，千萬不能急躁，寫程式或是想事情的時候想不出解答，可以先放在一邊，搞不好在日常生活中，例如洗澡的時候、散步的時候、逛菜市場的時候，都有可能想到解答。

不過創新的點子是一定要經過耕耘的，並不是一蹴可及的，像一般我們熟知的大企業，時常注重創新的公司，無可避免地必須要有特別的部門，或是主管明確地犧牲效率或是其他的資源，以換取員工能夠誕生新的構想，他們不一定看到每一步的作業，不過必須尊重或是支持創新的成本。

阿基米德在洗澡地時候發現了水的浮力，而牛頓在樹下打瞌睡的時候發現了地心引力，為什麼這些故事都是發生在國外？

所有新的構想都是可以發揮的好構想。

並不是所有的創新構想一開始都是可以執行成功的，都是經過琢磨而成為可執行的點子，通常一個新構想被提出來的時候，聽起來都爛的不得了，可以直接丟到垃圾桶去，但是簡單的修飾之後，或是利用創意組合的方式，搭配另一個舊的構想，有時候會成為不得了的結果。

例如一個公司的核心產品，總會想要自己來做業務行銷的工作，但是如果是一個比較過氣的核心技術，有時候如果自己在繼續開發，也自己來賣的話，有時候因為包袱比較大，可能成本比較大，所以有些公司會把這一類的技術賣給競爭對手，反而是減低成本，而這種創新構想當然風險很大，但是也是一個新的構想，我們不能就此鄙棄這種點子。

客戶知道他們要什麼，他們有很多好的構想。

對於技術研發的工程師來講，去跟客戶拿點子簡直是天方夜譚，因為客戶會先指出你原先的系統產品，有哪些錯誤要修正，哪些不符合需求，而這種修改曠日費時，依照這種客戶訪談的前進模式，業績量雖不至於衰退，但也不會有大的成長。

所以跟客戶溝通，做問券調查，用緊密的篩選客戶真正的需求，這種方式一定不能想出好的點子，跟客戶可以用非傳統的模式，例如微軟就是偷偷地用攝影機紀錄客戶接收到新產品的安裝及操作的模式，而一般的飲料上市前的行銷會議，就是把個人的感覺辦的像經驗分享一般。

這些方法並非每次可以重複使用的，要取的好構想好點子，就要用不同的方法在準客戶中取的創新的構想。

整合的年代(3)--重要模組的分工與整合分類：系統

重要的技術有時候可以發展出一個個元件，賣給系統整合的廠商，例如網路上認證加密的技術、信用卡扣款認證的技術、網站的瀏覽客戶群的分析、防火牆的元件，以上種種的重要技術如果要一家軟體系統全部一次開發完成，非常的耗時間而且經常不能達到經濟規模，造成後續維護上的困難。我們從系統整合廠商以及製造軟體元件的軟體公司兩個角度來分析，如何達成元件整合的重要條件。

從系統整合廠商來看

應用元件來整合系統可以節省開發的時程、節省成本，而把人力應用在本身的核心技術與客戶需求的互動上面，但是缺點就是對於元件的應用是否完全符合系統的需求，這個元件未來的發展，還有元件供應商是否有完整而足夠的支援，更重要的是應用了這個元件會不會讓你自己的系統的核心競爭能力減弱、或者是提高，都要表列一個檢核表，千萬不要因為一時的貪快造成未來後續的開發的困擾。

我們已最簡單的Windows應用程式開發為例子，如果你的專案是一直不斷地換版的專案，不是一個會停止的專案，那麼在程式的介面上最好不要選擇你無法控制的程式庫(DLL,OCX)，因為作業系統一直不斷的開發，這種元件的相容性受到很大的挑戰，而原先的元件軟體廠商因為市場不夠大無法維護的時候，造成更大的困擾。

從開發元件的軟體廠商來看

製作一個元件非常的簡單，但是要廣泛的應用在所有的系統上，必須就要開放非常多的介面，這些介面同時又不能把核心的技術完全暴露出來，所以，介面的訂立非常的重要，而實用性更是重要，往往做的程式碼比特定需求的程式碼要多上五至六倍。

現在因為寬頻網路的盛行，帶給了元件廠商的另一個契機，就是可以把重要性的技術放在伺服器上面，利用遠端的管理方式，管理您開發的元件，或是遠端的換版，甚至做安全性的認證。

以往元件廠商的營收被侵蝕掉往往就是後續的維護包袱太大，所以很難有完整的發展，開發工具所附的元件如果沒有含原始程式碼，無法符合後續發展的彈性。網路時代，元件或許是一個值得投資的開發模式，目前的網路認證、網路調查、代發電子郵件，都是這一類的模式。

整合的年代(2)--平行整合分類：系統

我們往往聽到很多的策略結盟的新聞，也有在賣場看到兩樣產品合在一起賣的比較便宜的案例，這些都不是軟體系統的整合，更談不上未來，只是為了提高產品的銷售量的一種手段而已，真正的產品或是系統的整合型態，主要可以分為三種，一是上下游的產品資料的垂直整合，二是系統介面的平行整合，三是重要模組的分工整合。

系統介面的平行整合

在十年前談到兩個系統的介面整合簡直是不可能的事情，都要透過前一種方式，垂直整合來達成，但是在現在作業系統的發展以及網路通訊規格的統一化，技術上已經沒有任何的困難，甚至還非常的方便整合，剩下來的問題就是兩個系統在整合上面政治策略的考量罷了。

最簡單地平行整合方式就是用不同的執行檔在同一個作業系統下執行，各有不同的執行檔，以及各自獨立的資料庫或資料檔案，而為了讓作業人員方便在兩個系統中間必須連接的功能，做一些介面或是功能上的連結即可，而這一類的整合如果是大眾化低消費的系統必須考量的除了功能的順暢之外，還有介面操作的一致性，甚至字型、對話窗的編排設計都要做完整的考量。

最好的例子就是我們常用的ICQ通訊軟體，大家可能在使用上沒有發現，這個系統在運作的時候是由很多的執行檔（ＥＸＥ）組合而成的，但是，使用上必沒有感受到不同，但是，可能是由兩個不同的部門開發出來的。要非常注意的就是效率以及整合度的問題了。

如果是利用HTML網頁來整合的系統，那可以用的方法就非常非常多了，我們在看瀏覽網站的時候最常用的就是用Frame框架的切割，可能左邊是Ａ公司的網站，而右邊是整合入Ｂ公司的資訊，這種方法是Netscape最先開發出來的語法，但是整合度低，廣告Banner Pageview以及著作權使用權的問題爭議不斷，所以一般大眾型網站很少使用，而應用在管理系統或是WEB電子郵件服務到是非常的方便。

還有一種用Javascript的含入功能
＜script language=javascript src=sURL＞＜/script＞
這種做法在通訊上就更上面提到的切割Frame的方式是一樣的，但是在畫面及介面的整合上比較漂亮，畫面上看不出來是兩個伺服器提供的資料，但是JavaScript在程式撰寫上比較繁複，這種方式廣泛的被應用在網路廣告的主機上面，來計算廣告的點閱率，並大量的記憶客戶瀏覽過的網站，盡量丟給客戶相關的廣告，以增加廣告效果。而這一類的整合的缺點若有一台主機伺服器出現問題，網頁上就會顯示不正常，必須要克服。

而微軟的IE瀏覽器上面，在版本4.0上面就新增了
＜IFRAME SRC=sURL .....＞＜/IFRAME＞
的語法，算是綜合上面兩個優點，讓不同網站伺服器畫面整合的好方法，唯一的缺點就是Netscape不支援。

至於這一類介面的平行整合必須要考量的就是安全性的問題，為了防止非法的連接使用，通常是使用參數編碼加密，透過使用者的瀏覽器來傳遞，但是若要嚴謹一點，這兩台伺服器就必須建了某種認證上的通訊機制，使用共同資料庫，或是即時的通訊規格，都是很好的方法。

整合的年代(1)--垂直整合分類：系統

我們往往聽到很多的策略結盟的新聞，也有在賣場看到兩樣產品合在一起賣的比較便宜的案例，這些都不是軟體系統的整合，更談不上未來，只是為了提高產品的銷售量的一種手段而已，真正的產品或是系統的整合型態，主要可以分為三種，一是上下游的產品資料的垂直整合，二是系統介面的平行整合，三是重要模組的分工整合。

上下游的產品資料的垂直整合

這一點在即時處理資料的網路年代特別的重要，以入門網站為例子，他們提供了很多很多的新聞資料，就一定要輸入大量的數位化資料，然後自動的編排入網頁成為內容或是讓客戶做全文檢索的查詢，因此透過什麼通訊協定來傳送資料就特別的重要。

目前一般應用到的大部分是ODBC的資料連結，有時透過TCP/IP來傳輸資料，或者應用WEB/FTP 伺服器來傳遞資料，而XML 也是重要應用的格式之一，當然用二進位檔案傳輸的效能是最好，但是資料的型態比較不開放，而同一個系統用DLL/OCX,或是兩個執行檔(exe) 之間的傳遞資料都可行，這些傳遞資料方法都必須考慮兩個系統達成溝通的最佳模式，而不是用最新的技術就是最好的。

而不同資料的傳輸方法與資料庫的整合都要有各種不同的專業領域分類的常識，要整合這些資料資訊，除了剛剛提到的通訊協定之外，資料庫的分類與整合也是重要的課題。

雖然資料庫是最常用於儲存資料的地方，但是，他並非是萬靈丹，不同的應用對於資料表的查詢或插入資料的效能不一樣，所以，上游的資料表不一定完全適用在下游的資料查詢，除了資料傳遞之外，對於資料庫的重新規劃也是整合的要點之一，如果單純的對資料表的建立View, Triger, Index 可以解決問題當然是最好，但是適當的用程式化(SP)的轉變格式是大部分的解決方法。

垂直的整合有一個重點，就是不要同時要做水平的整合，或是跨過兩個系統的垂直整合，這往往是導致整合失敗的主因，試想兩個系統的整合要討論的事情，重要的有傳輸介面、資料型態與呈現的專業分工領域之外，如果加入第三個系統來整合，他的難度變成非常的困難。

搞清楚兩個公司或兩個部門整合角色的扮演，才能正確的抓對了整合的方向，系統設計起來的權責區分才能做的好。

漸進式創新法分類：創新

不斷創新，不斷思索變革之道，也就是要不斷地追求改善。

我想各位聽到「創新」，一定馬上想到龐大的研發費用、一批聰明絕頂的研發人員，NO！錯啦！「創新」並不是來自靈感、來自某幾個發明家。管理大師彼得杜拉克就曾說過：「創新並非來自天才，與靈感也不相干，而是來自辛勤、有系統的工作。」事實上，根據調查，創新的來源也是「漸進多於突破」、「學習多於發明」──取自某演講稿。

一般的程式設計師總會陷入一個迷思，就是只要做好維護的責任，或者是要重視新功能的開發動作，有時因為痛恨舊的架構，所以經常革命性的打掉舊有的程式碼重新再寫過一次，而有人就會有鴕鳥的心態，只是再舊的程式碼裡面加一大堆的特殊處理，來因應不斷出現的狀況，這兩種現象都是太過的做法，雖然都可以解決，但是都會出現很大的陣痛，革命型的做法容易導致客戶有一段的適應期 (debug)時期，時間一拖長，客戶就走掉了，鴕鳥型的做法容易導致一個系統的架構混亂，愈來愈不容易更動。

所以一個良好的系統演化，必須要靠的就是程式設計人員，對於一個系統的觀念是否能往正確的方向走，也是程式設計師的責任，不諱言的，良好的執行者所受到的鼓勵並不是短期間可以看的到的，系統創新的評比也很難在考績上面表現得出來。以下提供幾個漸進式的創新方法......

模組化是一個非常好的方法，只要把模組化當成你的工具，慢慢地將不適用的模組抽換掉，你就可以把系統架構簡單化，未來要加新功能的時候不用在東一個、西一行的加入程式碼來處理例外狀況了。

做紀錄檔統計效能，使用者如何操作系統最清楚的並不是程式設計師，也不是系統分析師，是程式系統的本身，您只要在重要的程式碼做一些紀錄，當然不能影響系統的效能，然後適當的分析這些紀錄，可以很容易的知道系統的瓶頸在哪裡，未來可以用什麼平台、什麼程式語言來開發比較好維護。

絕對不要特殊處理，特殊處理的程式碼就好像是滾雪球一樣，如果是一個大的斜坡，你就會越滾越大，講難聽一點，就好像是說謊一樣，你經常要說另一個謊，來掩飾前面的錯誤，如果架構不對，就要找時間勇於改善系統的架構，花了一個星期來改架構，總比未來花兩個星期來找出 Bug，然後可能賠上幾個系統不穩定的評價好的多吧！

經常在別人的工作報告上看到，了解XX系統的架構、修正XX系統的Bug，其實，這些字句都不應該出現的，除了目標不明確之外，要彌補之前的錯誤，就安排了一大堆的進度，真的非常浪費資源的。

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

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

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

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

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

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

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

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

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

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