(這篇文在幾年前(2002)我曾發表於【程式設計俱樂部】, 那裡有許多回應, 有興趣的可以去看看-->這裡這裡)




給MIS新鮮人的建議




這篇短文,希望能對正在就學中的學生或有志於MIS 工作的社會新鮮人提供一點幫助

建議一:多注意龍頭大廠的動向
  資訊界的產品生命週期很短,各個資訊大廠無日無刻不在新的技術或標準上鑽研,而這些 東東往往決定了你的所學在未來的投資報酬率,因此我們最好能持續性地觀察他們;抽象 如公司願景(Vision)、市場策略(Strategy),具體如主力產品、各版本特性、系統架構( infrastructure)、獲利(或虧損)狀況等;以上所提的,不一定要深入研究,但最少要有 概念;閉門造車是技術人員的通病,能在學校時期即培養寬廣的視野對未來必有助益。


建議二:低階難懂的技術勿放棄
  所謂的低階,非LOW LEVEL,而是指”核心”(kernal)的技術;雖然在Windows interface 中,處處強調 User Friendly 或WYSIWYG (所視即所得)的觀念,但,那是對 使用者(User) 而言;資訊人員最好能撥開軟體中的層層包裝,直探核心部份!以Linux 而言,只會X-Windows 是不夠的,透過 Command 才能發揮所有功能;寫網頁的人不能只 玩玩 FrontPage 或 DreamWeaver ,想作出商用網站不能不學HTML、ASP、CGI等;玩硬體 的人最好也要會組合語言及電路學;學網管則對各種安全認証機制不能陌生....... ;這些低 階的(其實是進階的)技術,因為艱澀難懂,很多人因此望而生畏,列為拒絕往來戶; 可惜的是,這種高進入門檻的技術,才能讓我們建立最正確的觀念;同時這種Know-How 因其 為核心,不容易改朝換代,投資效益也是最高的;去看看國內的程設界行情吧!是寫VB的人 搶手還是搞Firware、Driver的人熱門?

  想強調的是,解決一個問題,最好試著從多個角度去思考,不要太依賴既有的Solution, 實務上的可能性是千變萬化的。


建議三:培養閱讀英文Paper 的能力
  不管如何,現有的軟體大多為英語系國家所開發出來;雖然很多外商的台灣子公司或有志 人士致力於中文化,但以量而言畢竟仍佔少數,只有大家常用的軟體有中文的介面,何況 即使是那些軟體,輔助說明的部份仍以英文為主;有學過MS Visual Studio 中任一套開 發工具(如VB,VFP)的人就知道,它的Help 係存在MSDN 的光碟中,其中包含了數百MB的 使用說明及範例,而且99%都是英文的!即使大如微軟,亦只能針對使用者介面部份作中 文化,所以當程式設計師碰到問題時就要具備閱讀基本英文資料的能力了。
  資訊人員英文不一定要出類拔萃,但對常用的專用術語絕不能陌生,如Protocol (網管常 遇到)、inheritance(OOP領域)、Multi-tier(主從架構設計領域)等,在 survey solution 時常會看到,即使看不懂Paper 中逐句的意思,但起碼要理解整篇的大綱。有很多人告訴我:看到英文就暈了,他們寧願自己不停地try & error,或是上網到處求救,就是不肯花幾分鐘看看這 些文件。英文的文件或書藉有個好處,就是它"大部份"都寫得較中文資料淺顯,不嫌煩瑣 地說明每個步驟,只要花點心思,自然就能克服恐懼感;撇開這些,好的英文畢竟能為你 的身價帶來加分的效果,希望大家不要再 Say "No!" 了


建議四:建立分析、溝通及管理方面的正確觀念
  資管系的學生都修過"資訊管理"、"系統分析"、"系統設計"等課程,這些課程大部份偏重 於理論的介紹,就算書中或教授舉了許多實務上的例子,對於無工作經驗的學生還是體會 得有限吧!因此囫圇吞棗、臨考前死背者比比皆是,到了畢業後就還給老師了。倒是技術 面,因為新軟體、新名詞一直出現,感受到的壓力是直接的,因此大多數的人都會再進修 。

  除非您立志終生於研發或專業職的工作,否則我建議上述那些Priority 排到後面的課程 還是要投入心思,因為它會幫助我們建立正確的"Sense";這個 "Sense" 或可解釋為「處 理工作上一些沒有標準答案問題的直覺」。

  舉例來說,一家公司剛來了兩位無經驗的程式設計師(A &B),都被指派了相同的練習題( 或許是幾支簡單的維護與報表程式);當完成後就以下項目評分:(滿分為五顆星)

                      A       B
        寫作速度         ★★★★★   ★★★
        正確性          ★★★★    ★★
        測試項目是否齊全     ★★★★    ★★★
        USER 操作介面友善程度  ★★★     ★★★★
        效能(Performance)     ★★★     ★★★★
        程式碼結構化程度     ★★★     ★★★★
        程式碼中的註解說明    ★★      ★★★★
        總分           24      24


   同樣是24分,誰的表現較好呢?

  我比較傾向於給B較好的評價;以前三項A領先的項目分析:A在Coding 上的經驗較豐富, 可以快速上手,對於任務也可以如期交差,通常主管會依賴他來快速完成專案。但就觀念 而言,則B有進一步成為SA 或PM 的潛質,為什麼呢?介面的 Friendly 及效能考量,代 表他能為使用者著想(程式正確並不代表使用者會樂於使用!);程式碼的結構化及註解, 將為團隊合作(別的PR.接手維護他的程式)及共用性帶來好處。這些觀念通常在程式撰寫 的Know-How 中較少被人提起,但長期而言它們卻是影嚮系統成敗的重要關鍵!

  我接觸過一些優秀的 IT 人員;憑著多年的磨練,他們大多對於架構及實作一個系統駕輕 就熟,但使用者或同仁的評價卻非很好,其中之一的原因,在於他們忽略或不重視某些 "隱性要素" (Invisible Factors),造成系統品質不良,而這種觀念的養成,在學生時代 能多接觸一些相關理論是很有幫功的。

  以上是個人就工作上的經驗,提供給晚進的一點建議,當然諸如:「虛心求教」、「建立 人脈」、「慎選行業」等,不但適用於資訊業,我想放諸求職上無不正確,因此就不多提 了;另外,以上或因個人環境而有不適用之處,也請各位自行拿捏了。
創作者介紹

A little IT experience/study/share garden

cbw0731 發表在 痞客邦 PIXNET 留言(0) 人氣()