真料來源：http://www.lifeparty.idv.tw/blog/archives/349
本篇文章是投稿 ZDNet 的文章原稿，並以〈怎樣才是專業的 SA？〉與〈系統分析專業的七種能力〉兩篇文章刊出。原稿未經 ZDNet 編輯，其內容可能會與刊登的文章內容有約略的不同。
對於很多從事軟體設計工作，對系統分析有興趣的開發者而言，常會關心系統分析專業能力的學習，以讓他們能夠在將來勝任系統分析的工作。
要成為系統分析師需要學些什麼呢？當然系統分析師必須要懂技術，才能根據軟體需求提出最適合的技術觀點，也就是運用解決方案領域（solution
space）的知識來把事情做正確。不過，如果系統分析師不懂問題領域（problem
space）知識，將會很難導出使用者實際的軟體需求，以做出正確的事情。
通常系統分析師會透過訪談利害關係人來取得軟體需求，但如果系統分析師缺乏問題領域知識，很可能會在溝通過程中出現困難，使得所導出的軟體需求無法符合使用者的需要。
在實際的軟體開發過中，要讓系統分析師同時兼顧於解決方案領域與問題領域的知識是很困難的。在現實世界中，通常很難找到不僅懂得軟體開發的技能，又同時具備問題領域知識的人才。而且軟體開發專案本身存在時程與成本等限制，多半不允許系統分析師花太多的時間與成本學習問題領域知識。因此，要期待系統分析師學習問題領域知識是不切實際且又不符合經濟效益的做法。
系統分析師要如何展現出系統分析的專業，才能整合問題領域與解決方案領域的知識，有效地提出具體可行的問題解決方案？其實在回答這個問題之前，必須要先認識到底系統分析的專業是什麼。
系統分析的專業
知名的軟體設計顧問王克明曾經提出「系統分析師根本不需要懂領域知識」的觀點。他提到系統分析師所需要具備的知識與技巧是，如何與領域專家（Domain Expert）溝通，並懂得如何將其領域知識轉化為抽象的軟體模型。他認為系統分析師並不需要懂領域知識，而是必須學會「純軟體」的技術，也就是如抽象、封裝、界面、及相依性分析等相關觀念。
王克明認為系統分析師的專業是專注於軟體設計根本的思考與學習上，因此 SA 很難有餘力把心思放在其它問題領域的研究上。基本上，筆者同意這樣的觀點，然而我也認為系統分析師不懂問題領域知識是無法展現系統分析的專業。
筆者從實務經驗中觀察到，在系統分析師未充分瞭解問題領域知識的情況下，想要依循封裝與抽象化的設計原則、落實界面與相依性分析的設計手法，這只不過是流於紙上談兵的空談而已。因為，系統分析師如果不清楚問題領域知識，他通常只能解決自己認為重要的問題，而不是利害關係人的問題。這樣做只是展現出他想要表現的軟體設計的專門技術，而不是可以解決問題的系統分析專業。
實際上，需求的不確定性會讓系統分析師們無法獲得到明確而具體的需求，而使得很難將利害關係人的知識轉化成抽象的軟體模型。其實根本的問題是在於他
們對問題領域不夠瞭解，而非他們不懂「純軟體」的設計技術。即使，表面上藉由利害關係人所傳達的觀念來加強系統分析師對問題的理解，但實際上卻常會因為對
特定觀點的忽視或遺漏、以及知識的抽象性令人難以掌握，而使得系統分析師無法獲取完整而具體的需求。
在軟體開發的過程中，利害關係人之間常常會對系統存在不一樣的期待與目標，而這些差異往往會形成對問題不同認知的各種觀點，這使得要找到能夠同時解決所有利害關係人問題的具體需求其實是很困難的。
例如以策略層面會站在如何達成策略目標來看待整體企業流程，但不見得瞭解執行層面會遭遇的困難。但有時候為瞭解決實際作業層面的問題，就必須針對企
業流程來進行調整。然而，這必須讓系統分析師必須對整個問題領域做全面性通盤瞭解，才能找出最適當的解決方案，否則很容易因為遺漏某部分觀點而使得需求不
夠完整。
另一方面，知識的抽象性常會增添人們對它理解與掌握的困難度。知識本身並不具有實體性，因此我們難以藉由感官瞭解它的存在。即使把它透過任何形式儲
存與傳達，我們依舊只能看到它外顯的表相，而很難體會與瞭解其內隱的本質，更不用說將它應用在問題領域之中了。除非我們能對它加以應用、重組、並親身體驗
其知識內化的過程，我們才能認識知識的真實面貎。
相信許多從事軟體開發工作的朋友都能夠體認到，不管在技術上或是管理上花費多少努力，需求的不確定性都是難以去除的。如果我們無法避免需求改變的發生，那麼我們就必須增進設計的彈性以因應需求的變動。當然許多設計建模方法、各種分析或設計樣式可用來幫我們提昇設計的彈性，但問題是即使這些東西學得再多，我們卻還是無法適當的使用它們來展現系統分析的專業。
專業為何無法展現？
系統分析師當然應該專注於軟體設計根本的思考與學習上，但卻也不應該忽略了所謂的設計是為瞭解決真實世界上的問題，如果不瞭解問題而想要專注於設
計，那是不可能可以做到的，當然也無法展現出系統分析的專業。專業並不在於我們學了什麼技術，而是在於瞭解什麼問題該用什麼技術來解決。換句話說，一旦我
們看不到問題，專業就無從展現。
筆者常發現有些人不能發揮系統分析的專業其實並非是軟體設計技術學得不夠，而是學了很多的解決問題的方法，卻對問題產生迷惘。他們太執著於提出最棒
的設計技術或理念，卻忘了檢討它們是否真的解決了問題，以致於無法將所學與現實問題做有效的關聯，結果使得問題與方法變成兩條永不交會的平行線。
任何人不管對那一種軟體設計技術產生執著，他都會很難展現出真正的專業，因此要展現專業必先對問題進行思考。如
果有人提出問題解決方案卻無法指出問題在那裡，這種說法是難以令人相信的。因為我們會質疑他在不清楚問題的情況下，如何能確知他的解決方案可以解決問題。
同樣的道理，當我們用某種技術設計出問題解決方案時，卻欠缺對問題的思考，我們怎麼能確信問題真的可以被解決呢？當然筆者相信很多人會這麼想，其實他心中
對事情是存在著某種假設。
人們通常會對比過去經驗以做為如何解決問題的參考依據，總是會假設過去成功的解決方案在類似的情境中也可以成功。但有時候，類似的情境所要解決的問
題不盡相同，其存在問題背後的基本假設與限制也不一樣，換句話說，今天我們所遭遇的問題很可能更複雜，而自己的假設其實是用過去已知的記憶來面對未知的未
來。用經驗對比來取代思考的創新，這其實並非系統分析的專業。
那麼我們應該如何展現系統分析的專業呢？筆者認為在想法上，我們應該用更創新的思考來突破知識的窠臼；在做法上，我們應該用更有紀律的行動來發展知
識。然而具體的方法又是如何呢？筆者認為要展現系統分析的專業至少應該掌握七種能力，接下來分別從創新心智模式與知識學習與轉化兩方面來提出我對系統分析
專業的心得與體會。
創新心智模式
系統分析師該如何創新心智模式以突破知識的窠臼呢？依照筆者在系統分析實務中所得到的體會，我認為系統分析師學習下列四項思考能力，將有助於對問題形成完整、清晰、與更具創造性的觀點。
探詢問題的能力
要掌握問題的關鍵，系統分析師必須具備探詢問題的能力。他不應該只問利害關係人系統該做什麼，而是要進一步反思為什麼他們需要做這些。當我們把焦點
放在質疑行動目標與方案背後的基本假設與信念時，將會促使我們對問題做更深入地反省與思考問題的本質，也會增進對問題的理解能力而提昇設計的決策品質。
有許多看似相互矛盾的觀點，在經過深入探索後，往往會找到其背後其實存在為人們所忽略掉，有助於形成可以達到彼此共識的一致性觀點。但唯有對事物採取質疑與探索的態度，才能從幫我們從不同的觀點中找到最有價值的知識。
展現想法的能力
想要與利害關係人進行心智模式的分享與交流，系統分析師必須要有能具體展現想法的能力。如果我們無法具體地完整呈現自己的想法，那就代表想法還不夠
清楚或完整，還需要進一步思考出更為清晰而完整的觀點。當彼此都清楚地表達自己的想法時，我們就可以相互比較與分析相互想法的異同所在，進一步地發展出更
為完善的觀點。
展現想法的能力也可用來增進相互的理解。我們可以試著用自己的表達方式來進一步詮釋對方的想法，讓他來確認我們是否真的理解他的想法。這樣彼此就能更進一步地就差異點來澄清觀點。
整合觀點的能力
系統分析的目的是為瞭解決問題提出具體的可行方案，這通常需要從組織或企業的各個層面來瞭解。一般而言，由策略層面提供策略目標、而管理層面則發展
作業流程以支援組織策略目標、作業層面則依據作業流程制定具體的作業細節。系統分析師必須分析問題，並整合各個層面的觀點，以更清楚而完整地掌握問題領
域，將會有助於發展出適當的解決方案。
藉由觀點的整合，系統分析師通常可以發現到更好的解決方案。企業組織現行的作業方式，經常會受限於企業環境本身的限制，但系統分析師可以運用技術創新的觀點來突破既有的知識框架，發展出更完善的作業流程或企業邏輯，進而為企業組織創造價值。
抽象思考的能力
抽象思考的能力可以降低問題的複雜性，增加設計應變的彈性，是系統分析不可或缺的重要能力。然而，具體的東西很容易掌握與理解，而抽象思考必須從各種不同情況中歸納出事物的共通行為，所以抽象性的觀點並非一開始就可以成形的，而是從問題的演化過程中逐漸浮現出來。
抽象化思考是要略除不重要的細節，只展現出最重要的觀點。其方法是從各種不同情境中，從具體觀點中找到它們存在共同的關聯、結構、或模式。筆者經常
發現到解決問題最具創意的見解總是出現在彼此互動的省思當中，在觀點相互激盪後才會讓我們發現全新的觀點，產生創造性的抽象思維，並讓人倍感驚奇與不可思
議。
知識的學習與轉化
假如創新心智模式可以讓我們突破知識窠臼，也就是更清楚地瞭解問題，做正確的事情的話。那麼知識的學習與轉化，就是為了讓我們針對問題來提出解決方案，用有紀律的方法來整合行動方案，來把事情做正確。
系統分析師該如何進行知識的學習與轉化呢？如同《SWEBOK》所提到的「需求流程在軟體生命週期中並不是的分離的前端活動；而是啟始於專案開始並
貫穿整個生命週期，不斷精煉的一個流程」在整個軟體開發生命週期中，系統分析與其它開發活動是交錯與反覆進行的；而系統分析師與利害關係人必須以漸進與反
覆的方式來進行知識的學習與轉化，以將不同領域的知識進行有效的整合。
因此，筆者認為系統分析應該掌握知識轉化的三部曲，也就是下列可以幫助知識學習與轉化的三種基本能力。
採用（adopt）知識的能力
系統分析師要提出系統可行解決方案的具體建議之前，必須要先對利害關係人所提出的觀點來進行認識，學習如何從中採用有價值的知識以解決真實世界的問
題。由於系統分析師與利害關係人通常來自不同的知識領域，從他們所表達出來的字面意思中不見得可以瞭解其觀點的意涵。因此除了必須與利害關係人進行對話，
並且把他們的想法記錄下來之外，通常還需要實地觀察與體驗，以求更具體地理解他們所要傳達的知識內容。這樣才能在未來將這些知識運用自如，這便是知識轉化
過程的第一步。
調整（adapt）知識的能力
在吸納並且可以靈活運用利害關係人的知識之後，系統分析師便需要將這些知識組合軟體設計的專門技術來產生創新的知識。畢竟系統分析師學習利害關係人
的目的並非只是為了在問題領域中應用而已，而是要整合技術觀點來為利害關係人創造價值。因此，整合技術解決方案領域的知識將可使得問題領域知識獲得調整，
來增加知識的價值。
熟練（adept）知識的能力
在系統分析師有能力調整問題領域知識以創新知識的價值後，就可以進一步地將過程中所學到的知識、經驗與技能加以熟練化，以期把知識進一步地內化成為
自己的專業。這樣就能夠在以後需要的時候，將自己所體會到的知識適度地發揮出來。當然系統分析師通常會在不同的問題領域中，不斷地經歷採用、調整、與熟練
的三步曲，轉化出應用範圍更廣泛或更深入的知識。
看完了這七種能力，相信讀者可以瞭解為什麼系統分析師往往會從參與不同領域的軟體開發過程中，讓自己熟悉非個人專業領域的知識。關鍵並不在於他們比
領域專家還聰明，而是藉由其系統分析的專業，創新心智模式與知識的學習與轉化，逐漸地將吸收到的經驗與知識整合內化成自己的知識。因此，系統分析最需要學習的關鍵技能，重點並不在軟體設計的專門技術，也不在問題領域知識，而在於跨領域的整合能力呀。
文章定位：
