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

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

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

保持開放學習的心態

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

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

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

真正的團隊合作意義

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

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

不要限制自己的未來

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

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

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

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

注重系統開發的所有流程

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

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

架構的討論與分析

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

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

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

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

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

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

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

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

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

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

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

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