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