系統分析師需要學些什麼呢?當然系統分析師必須要懂技術,才能根據軟體需求提出最適合的技術觀點,也就是運用解決方案領域(solution space)的知識來把事情做正確。不過,如果系統分析師不懂問題領域(problem space)知識,將會很難導出使用者實際的軟體需求,以做出正確的事情。
通常系統分析師會透過訪談利害關係人來取得軟體需求,但如果系統分析師缺乏問題領域知識,很可能會在溝通過程中出現困難,使得所導出的軟體需求無法符合使用者需要。
然而在實際的軟體開發過中,要讓系統分析師同時兼顧解決方案領域與問題領域的知識是很困難的。在現實世界中,通常很難找到不僅懂得軟體開發的技能,又同時具備問題領域知識的人才。而且軟體開發專案本身存在時程與成本等限制,多半不允許系統分析師花太多的時間與成本學習問題領域知識。因此,要期待系統分析師學習問題領域知識是不切實際且又不符合經濟效益的做法。
如此看來,要勝任系統分析的工作,我們必須解決以上的困擾。但怎麼樣才是專業的系統分析師呢?而系統分析師的專業又是什麼呢?
系統分析的專業
知名的軟體設計顧問王克明曾經提出「系統分析師根本不需要懂領域知識」的觀點。他提到系統分析師所需要具備的知識與技巧是,如何與領域專家(Domain Expert)溝通,並懂得如何將其領域知識轉化為抽象的軟體模型。但他認為系統分析師並不需要懂領域知識,而是必須學會「純軟體」的技術,也就是如抽象、封裝、界面、及相依性分析等相關觀念。
王克明認為系統分析師的專業是專注於軟體設計根本的思考與學習上。基本上,筆者同意這樣的觀點,然而我也認為系統分析師不懂問題領域知識很難把系統分析做好。
筆者的實務經驗顯示,在未充分瞭解問題領域知識的情況下,想要依循封裝與抽象化的設計原則、落實界面與相依性分析的設計手法,這只不過是流於紙上談兵的空談而已。在這種情況下,系統分析師通常只能解決自己認為重要的問題,而不是利害關係人(stakeholder,通常是使用者)的問題,其所展現出來的只是軟體設計的專門技術,而不是可以真正解決問題的系統分析專業。
實際上,需求的不確定性會讓系統分析師們無法獲得到明確而具體的需求,而很難將利害關係人的問題轉化成抽象的軟體模型。問題不在於他們沒有專注於軟體設計的根本思考與學習,而是在於對問題領域不夠了解。雖然理論上可由溝通來加強系統分析師對問題的理解,但實際上卻常會因為對特定觀點的忽視或遺漏、以及知識令人難以掌握,而使得系統分析師無法獲取完整而具體的需求。
尤其是,利害關係人之間常常會對系統存在不一樣的期待與目標,以致於對問題形成不同認知。例如以策略層面會站在如何達成策略目標來看待整體企業流程,但不見得了解執行層面會遭遇的困難。但有時候為了解決實際作業層面的問題,就必須針對企業流程來進行調整。系統分析師必須對整個問題領域做全面性通盤的了解,才能找出最適當的解決方案,否則很容易因為遺漏某部分觀點而使得需求不夠完整。因此,要找到能夠同時解決所有人問題的具體需求其實是很困難的。
另一方面,知識的抽象性常會增添人們對它理解與掌握的困難度,除非我們能對它加以應用、重組、並親身體驗,將知識內化才能認識知識的真實面貌。
相信許多從事軟體開發工作的朋友都體認到,不管在技術上或是管理上花費多少努力,需求的不確定性往往難以去除。如果我們無法避免需求改變的發生,那麼我們就必須增進設計的彈性。當然許多設計建模方法、各種分析或設計樣式可幫我們提昇設計的彈性,但有時情況是:即使這些東西學得再多,如果無法適當使用,也難以用它們展現系統分析的專業。
專業為何無法展現?
系統分析師當然應該專注於軟體設計根本的思考與學習上,卻也應該了解,所謂的設計是為了解決真實世界的問題。如果不了解問題而單純專注於設計,那是不可能,也不等於專業。專業並不在於我們學了什麼技術,而是在於了解什麼問題該用什麼技術來解決。換句話說,一旦我們看不到問題,專業就無從展現。
筆者常發現有些人不能發揮系統分析的專業,其實並非技術學得不夠,而是學了很多的解決問題的方法,卻忽視問題本身才是最重要的。太執著於技術如何解決問題,卻忘了問真正的問題是什麼,以致於無法將所學與現實問題做有效的關聯,問題與方法變成兩條永不交會的平行線。當某人用某種技術設計出解決方案時,卻不知問題為何,那我們怎麼能相信他可以解決我們的問題呢?
當然筆者相信很多人在解決問題時,其實心中對事情存在著某種假設。
人們通常會對比過去經驗以做為解決問題的參考依據,總是會假設過去成功的解決方案在類似情境中也可以成功。但有時候,類似的情境所要解決的問題不盡相同,存在問題背後的基本假設與限制也不一樣。用經驗對比來取代思考的創新並非系統分析的專業。
在不同領域中,很容易因為價值觀或思考方式的不同而對事物產生執著或偏見。因此,如果想學習可以活用在跨問題領域上的系統分析,就應該學習整合不同觀點以創新價值。具體的方法又是如何呢?我們下次再談。
10.Programmer 於 2008/07/04 11:29 回應
Sorry, 更正上一篇, 不是對一樓發言人, 而是對7.Guest 於 2008/07/01 09:48
的回應
9.Programmer 於 2008/07/04 11:26 回應
一樓的發言人你好:有些情況在不同角色之下會有類似的處境!!!
像是中小企業主對 SA 的看法, 你的文章裡也表現出你對 Programmer 的看法....
相同的, 在下位的都被看輕了, 這不是好的配合方式, 我無意發起論戰, 只是希望人人能夠異地而處, 換個角度想想, 那麼大家就會合作的更好
8.inpines 於 2008/07/02 13:42 回應
感謝各位讀者的意見,讓我發現有一些值得探討的地方,我將會在後續的文章來分享我的看法。7.Guest 於 2008/07/01 09:48 回應
個人覺得,SA是可以不需要懂專業,懂專業的也是可以不懂SA,但這樣設計出來的系統往往都會變成不好使用或是彈性欠佳
主要因為SA如果不懂專業領域,很容易專注於流程的設計而忽略使用者便利
而只懂專業領域的,往往又不知道倒底資訊有什麼新的技術可以改善流程?
所以個人幾年的系統導入經驗覺得SA如果能兼具專業領域知識是最好不過
但偏偏專業領域的知識卻是最不容易培養
往往得耗用個三、五年甚至是十年才能可對於某個產業有個全面性的了解
只是到了這樣的工作資歷時,卻有都已經脫離SA或programmer的階段了
舉個例子吧,SAP雖然是全世界首屈一指的ERP專業廠商
可是台灣的鞋業卻甚少聽到使用SAP的ERP系統
這就是台灣的SAP顧問團隊鞋業的專業領域還不夠廠商信任(甚至是完全不懂啦)
當廠商不覺得顧問對自己的產業有足夠的專業時
他們所提出的各項流程改善建議又怎麼能被那些資深的主管與老闆們接受?
當專業與經驗相衝突的時候,往往就是系統導入無法再繼續下去的時候
這就是為何SAP、Oracle、JDE的系統導入也有不少失敗的案例...
個人覺得SA除了本身要有足夠的資訊技術底子外(懂UML或SA的分析)
在不容易培養或取得產業的專業領域知識情況下
可以考慮培養像PMP、ITIL之類的類似工業管理或企業管理的相關知識
主要是可以從一般企業管理的管理架構與運作方式去了解產業
應該會比較能加速對於產業領域的專業知識理解與吸收
降低傳統因過於偏SA角度的主觀意識來進行系統的導入
這樣企業的那些不懂SA的管理者(或Power User)才比較願意一起坐下來談
SA也才能取得比較核心的資料與想法,之後的系統走向也才能比較貼切使用者需求
個人覺得所有資訊系統最重要的一點
那就是只要使用者不使用,那系統再怎麼好用也一點用處都沒有
除非公司採用自動化生產而且所有數據都從機台上取得
問過很多ERP顧問,他們普遍認為資訊系統的導入往往「人」才是最重要關鍵
好的資訊系統至少要有三好才可能成功:
1.好的SA(或PM)
2.好的使用者
3.好的高階決策主管
而Programmer在現今那麼多好用的開發工具下,作用只剩怎麼寫出效能好的程式
當然並不是不重要,而是這個優勢可以用規格好的硬體取代
所以重要性顯得就不那麼的重要了
講那麼多...老實講以上普遍並不適用於台灣的中、小企業
因為大多數的中、小企業老闆普遍還是存在一個觀念
那就是「資訊系統應該是要配合他的需求而開發,而不是為了配合系統來改變公司」
三不五十就會冒出一句:「產業的資訊您有他懂嗎?」......只能無言∼
6.Rebecca 於 2008/06/29 10:25 回應
我是流浪SA,104網站上的職務,與相關IT的職務90%以上都要求須具備DOMAIN KNOW HOW,我個人倒是認為SA若能與一個邏輯清楚的POWER USER一同工作,才是最達到事倍功倍的吧~5.ZDNet編輯部 於 2008/06/27 13:35 回應
To 1F的讀者您說的很對,我們的確很希望具備SA, SD, Programmer, DBA, 甚至網路及系統管理洞見的專家, 和大家分享他的看法,或是有這方面困擾的人也表達他的意見。
如果您也有興趣,也可來信和我們聯絡:editor2003-tw (at) cnet.com。
編輯部
4.kj 於 2008/06/27 10:57 回應
學習"整合"觀點,笑~~又是一個天方夜譚!3.一路走來 於 2008/06/27 09:46 回應
我是SA, 見過也和很多的SA, 或是 SD 合作過. 我最怕聽到一種人... 喜歡說把系統設計得簡單點. 這句話雖然是對的, 但是我遇過的人, 大概 90% 以上, 是先把 User 的需求簡化或是完全忽略得先去思考難處理的部分, 就下手去規劃, 然後又再將系統分成數個階段... 第一階段都是主要功能, 簡化後的設計, 看似可以達到功能, 可是這種人,鮮少會繼續待在這個案子, 因為他簡化過後的東西, 未來進入後面階段時, 會發現, 根本搞不出來; 或是即便有辦法, 每次查詢卻得耗費大量系統資源去做大幅計算. 總之, 在後面接手的人, 都得費盡九牛二虎之力, 去搞.以後我看到號稱能讓新系統快速開發, 快速上線的人, 我都敬而遠之. 我比較喜歡跟敢說
"我的系統隨著每個階段能開發得越來越快" 的人合作.