集團的種子培訓計畫

聽起來不錯，應該是學 GE 的，不知道要推薦誰去上課!!!

職場不變的對話內容分類：職場

1.
開發單位：請告訴我哪個產品線投入更多資源是最值得？
業績單位：當然投入Ｂ產品線不錯，可是Ａ產品及Ｃ產品也都很好，Ｄ產品線也不能放棄。
2.
業績單位：請問我明年可以在哪個產品線加強行銷？
開發單位：我們的產品都很好，所以都可以，但是資源不夠，所以Ａ產品要給我兩個月的時間；Ｂ產品要多給我ㄧ些人；Ｃ產品要在測試完整點。
3.
業績單位：請給我多一個產品來賣
客服單位：舊的問題請馬上改善
開發單位：到底是哪個比較重要？
4.
下屬：請給我們明確的目標指示，不要變來變去。
老闆：目標不是年初就定義好了？但市場再變，所以我們要趕快應對。
5.
老闆：這樣做就對了，不是給你們很多時間了？怎麼做不出來
員工：別人削價競爭我們沒有競爭力。

程式設計師的工作慣性

這次要討論的主體可能跟創新的關係很小，請容許我離題。一般來講年後換工作的風潮在各個行業都會發生，我們來分析一下程式設計師工作的型態，這些分析可能在各行業都可以適用。

首先，我面對到程式設計師換工作的主要原因大部分是認為原來的工作創新度不足，使用的開發工具比較舊，原系統已經不做大幅度開發，只作例行性的維護，缺乏新鮮感，種種的跡象顯示很難獲得成就感，或者是無法獲得大家的一致的認同有價值。

但是，這時候程式設計師的確是一樣的忙碌，每有忙著救火，卻得不到掌聲，如果你正式處於這種狀況，你第一個想到解決的辦法就是換工作吧！然後原公司可能會在找一個人頂替你的位置，而你接觸新的工作，同樣的狀況兩年後又發生一次，這是一個無法解決的惡性循環。

問體出現在哪裡呢？我想並不是技術能力的不足，而是錯估了處理問體所花的成本，接專案的人總認為有一個洞，把他補起來就好了，哪知道有很多洞要補，而且補了洞還不一定知道是不是會產生另一個洞，所以需要從系統架構上的問題去了解，然後再來解決。

第二，可能是在系統整合上的問題，現在的系統大部分是採用開放式的架構，大家協同把所有的子系統放上去，第一次整合測試沒問題，第二次也沒問題，測試過後就上線了，但是系統運作的時間久了之後，有的子系統因為檔案讀取失敗，資料庫沒有正常運作，或者是當初沒有考量道的錯誤，造成平常操作人員的困擾，因為程式設計人員也換過了好幾代，文件不齊全，原始程式碼沒有說明，導致無法找出問題點。

這一類的程式設計師總覺得自己在接爛攤子，接愈多包袱愈大，最後只好選擇丟掉，其實，要解決整合的問題，別無他法，就是程式設計師或者操作人員下去做分析，詳細的一步一步的把錯誤訊息找出原因，然後把問題發生的狀況紀錄分析，然後看是要改程式來解決，或者是從作業流程去改變，這個以目前用 Excel 來做應該都綽綽有餘了，這個過程可能隨時都在做，但必須密集的去分析解決。

最後，可能跟資源的整合或是分開有關，公司會資源整合一定是有某些產品的收入不合經濟效應，所以一個人本來負責一個產品或專案，但是可能一個人變成負責兩樣產品，如果程式設計師還認為事情是Double 的話就錯了，可能剛開始的時候是這樣，既然負責了兩件事情，就要把程式碼變成一份，這樣慢慢地就變成一件事情了，不然比較差的方法就是安排事情的重要程度來處理。

另外最重要的想要換工作除了是被挖角跳槽之外，其實也有景氣循環這一回事，景氣不好的時候，開發新功能新產品的事情是比較少，維護程式系統的事情比較多，認清楚你的專長是在開發新系統還是在維護系統，在搭配業界的景氣循環，才不會永遠在景氣循環或是過年的時候換工作。

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

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

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

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

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

了解自己想要做的工作，換一個工作雖然不是一定要做一輩子，但是總要待久一點比較好，所以工作的環境以及內容非常的重要，千萬不要沒有一點的主見，或是想說公司派什麼工作就做什麼，就程式設計的領域來說就非常多種，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幾天幾夜沒有休息，有時候寫不出客戶想要的系統又睡不著，有時想出一個很好用的架構，老闆又不以為意，程式設計師真的如此命苦嗎？

注重系統開發的所有流程

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

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

架構的討論與分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

程式開發人員的工作風險與動機分類：職場

剛剛投入程式開發工作的人，總有滿腔的熱誠，想要把開發的系統做到非常完美，但是現實世界中，沒有一項事件是完美的，往往遭遇到許多的挫折，我們從程式設計師的工作動機來討論，並且說明他們的工作風險，讓大家更了解程式設計師的心路歷程。

一般的程式設計師並不在乎短期的工作時間，在乎的是下列三大項，一是成就認同，二是技術成長的可能性，三是工作本身的興趣，我們觀察一般的程式設計師的個性，其實發現他們比一般人還要『內向』，而內心的世界往往比外在的世界要大，要觸發這些動機並且平衡所有角色的工作並不容易。

成就認同，軟體開發的程式設計師喜歡工作，激發開發人員最好的方法就是提供一個環境讓他們可以很容易專注在最喜歡做的事情上面，對於一個專案或產品要給所有權的概念，這樣自然會產生參予感，而他們總是充滿了野心，所以工作時程總是訂的特別短，所以目標的設定非常重要，當然這些目標不能太過複雜與多樣，要用程式設計師的語言來設定目標，而這個設定目標就是一種被認同被肯定。

技術成長的可能性，程式設計師的開發環境是持續變化的領域，為了能夠生存下去，必須每天學習一點東西，今天做的這個工作有可能有一半會在兩年內過時，想想這個行業的自然現象，所以為他們成長的激發是非常重要的組織內功能，一個組織要提供專業課程的補助，給予上課或是讀書學習的空間與時間，購買專業書籍的補助，分配程式設計人員擴展技術的專案，給予新進人員一個顧問（輔導員），如果一個組織內部無法提供這幾項機制的話，程式人員的開發動機會隨著時間，而熱忱慢慢的降低，相對的給予資深的程式開發人員很多的技術地位提昇與技術管理顧問的工作也是一種成長。

工作本身的興趣，我想這是所有工作者都要具備的，但是對於程式設計師來講，要十分的投入並且去培養的，不能時常被打斷的工作環境也非常的重要，如果我們在一件工作的任務認同上給予重視的話，他們就會比較關心他們的工作，而對於工作的回饋會完完全全的反應在興趣上面。

如果一個組織能提供這些環境，程式設計師的風險還是非常大的，可能你的專案一夕的需求改變，我們要花十倍的資源去修改甚至重新設計，一個設計良好的系統，有可能一個顯示的錯誤，被批評的非常不可用，品質的保證好像是測試人員的事情，但是終究是透過程式開發人員來修正的，上面敘述的三大動機也可能因為工作環境的改變，使用技術的改變與成就認同的改變，讓程式開發人員面臨強大的壓力。

或許呆伯特的出現，就是要減低這些風險壓力吧!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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