在成為SA之前….

前幾天, 一個案子上認識的客戶端Programmer透過msn問了我一個問題, 讓我想了很久, 思考之餘才生出了這篇文章.

記得我在某篇文章說過, 技術顧問不是一種身份, 而是一種狀態: 因為你在技術層面擁有了足夠的深度及廣度, 所以你成為一個可以當技術顧問的人. 事實上, SA(System Analyst)也是.

我常會跟同事或同行的朋友強調, 資訊科技中沒有什麼叫做定律, 這畢竟還是個非常年輕的領域, 一切都還在發展與進步中, 每一個曾被認為是圭臬的教條, 很可能很快的在新技術發生後, 變成不值一哂廢話. 這告訴我們, 不要被知識迷惑, 學習那些知識跟技能最重要的知道為什麼, 而不是把怎麼做變成SOP般的教條.

在Wikipedia裡頭有關於System Analyst的敘述, 裡頭列出了如下的幾個SA的工作內容:

• Plan a system flow from the ground up.
• Interact with customers to learn and document requirements that are then used to produce business requirements documents.
• Write technical requirements from a critical phase.
• Interact with designers to understand software limitations.
• Help programmers during system development, ex: provide use cases, flowcharts or even Database design.
• Perform system testing.
• Deploy the completed system.
• Document requirements or contribute to user manuals.
• Whenever a development process is conducted, the system analyst is responsible for designing components and providing that information to the developer.

喔, 有夠複雜的, 簡單的說, 一個SA作的就是, 從需求到藍圖之間, 從藍圖到專案完成之間, 幾乎所有的工作.

在很多大型的專案會拆的更細, 例如會有SD(System Designer)負責系統架構的設計, 會有UD(UI Designer)負責統整設計符合需求流程又同時易於使用的UI, 有DBA(Database Administrator)負責去規劃後端資料庫schema….等等. 但是其實這些都只是把SA從一個人變成一個小組, 實際在主導這些工作的, 還是一個Major/Chief SA在負責.

所以, 要成為一個SA, 門檻相當相當的高, 除了要熟悉「各種」系統, 更要熟悉「各種」語言, 熟悉「各種」資料庫, 甚至要會使用者行為分析, UI設計原則等等. 這還只是基本要求, 更深入的說SA還要具備良好且有效率的溝通能力, 技術判斷力(例如判斷什麼需求必須被擱置或拋棄, 什麼沒提出的需求必須被隱性的加入規格中), 管理能力….etc.

很多Programmer都把自己的下一步定義在SA, 但是往往缺乏對SA這個身份的認知. 某D是我遇過的Web Game Programmer, 他的目標是成為SA, 但是當我鼓勵他多接觸系統面的東西時, 他告訴我他只想寫Game, 其他部份他認為沒必要學; 某J是Java Programmer, 他的目標也是成為SA, 但是當我鼓勵他多接觸其他語言, 多理解一些各語言的特性與優缺點時, 他告訴我他覺得Java最好, Java是萬能的, 不須要學其它語言.

某D還在繼續寫Web Game, 用PHP寫了五年的Web Service, 但是他依然不懂REST是什麼; 某J換了幾家公司, 還在持續寫Java, 卻總搞不清楚他的程式為什麼效能總是不好. 但是他們的共通點是, 永遠都在抱怨主管不賞識, 不加薪, 不給機會讓他表現.

我的職涯之中, 做過各種身份, 在這個業界十多年的經驗與累積, 直到目前為止我都還認為我自己距離一個60分的SA至少還差一大截需要努力, 我實在想問問這些死守在一個領域, 單一平台, 單一語言的年輕後輩們, 你憑什麼覺得自己可以是個SA?

好吧, 那SA這種高度要求的艱難身份, 究竟該如何達到?

我能給予的建議是, 忘記自己熱愛的語言–去學更多語言, 忘記自己習慣的系統–去用更多種系統, 忘記自己對專業的堅持–去跟User做更深入的溝通, 持續的做, 然後當你不再為了怎麼成為一個SA而迷惑時, 你就可以是個SA了.

回到最開始的問題, 他問的是:「我想去IBM應徵SA, 你覺得有機會嗎?」

偉哉, 他只寫了三年ASP, 連個Paper Engineer必備的MCSE課程都沒上過啊….