「SA 需不需要懂 "領域知識(Domain Knowledge)" ？」的迴響

由：Kenming Wang

Kenming Wang — Thu, 02 Dec 2010 21:38:37 +0000

>不一定要是專家，但知識領域還是要建立到能夠與專家對話阿！
>到最後你還是得從專家手上推敲出「噴子」的資料，無論你是從專家手上學到，還是事前先把資料準備好，最後都是要建立的。

yes, 這是我所認同的，在與領域專家的溝通過程中，本來就需要對該領域的專業術語能有共識與基礎的了解。

我所謂 SA 具備 "與領域專家溝通的能力"，對領域術語的定義與解讀，這些是在溝通過程中會建立起來的。

領域的關鍵知識，我比較主張 SA 不太需要花功夫與心思去學(除非你想當該領域的真正專家)；重要的還是在於：解讀與快速捕捉精要 (essential)的能力。

由：JonesLai

JonesLai — Thu, 02 Dec 2010 07:49:45 +0000

不一定要是專家，但知識領域還是要建立到能夠與專家對話阿！

不知道「噴子」為何物，如何能溝通，「噴子」的抽象、封裝、介面、相依！？

到最後你還是得從專家手上推敲出「噴子」的資料，無論你是從專家手上學到，還是事前先把資料準備好，最後都是要建立的。

由：Kenming Wang

Kenming Wang — Sun, 31 Oct 2010 12:28:57 +0000

以前我的老師用了一個相當有趣的比喻來說明 SA 與 Domain Expert 的角色。小孩子要能生出來，總是需要先生與老婆的結合才能生下來，而不是一個人就能擔負生小孩的責任。 ^^

溝通不是在於兩者的須具備共通的知識，重點卻是在於 "合作"。這點在軟體開發中，為何會有各類不同專職的角色互補合作就可以知道的。

在國內的軟體業界諸多公司，的確幾乎都要求 SA 要能具備領域知識。但是相對來說，我個人所看到的 SA，卻幾乎沒有具備軟體分析的能力 (這可是很奇怪的現象)。

至於個人所主張 SA 不須具備領域知識，此點論點卻也不是空談，而是幾年下來，透過多年來在許多單位的顧問輔導，反覆的實證，更是證明此一論點。

如果有興趣討論這個議題，歡迎利用假日(星期六)來中國生產力中心找我，早上上完課後，一整個下午我可以陪你討論諸多軟體設計與開發的許多議題。 ^^

由：Vincent

Vincent — Tue, 19 Oct 2010 10:24:54 +0000

從溝通理論來看，兩個個體之所以可以溝通，是因為具有共同的知識，這雙方都擁有的共同知識是能夠溝通的基礎。如果SA完全沒有Domain Knowledge，而domain expert也不知道SA在做什麼，這個溝通的過程必然會非常辛苦。這是為什麼SA必須有domain knlwledge的原因 — 為了有效溝通，而不是為了變成domain expert直接提供解答。
現在的企業已經不像上個世紀那麼強調專業分工，而是強調多能工。因為在跨領域的工作場域中，太極致的專業分工造成的專業本位主義，溝通障壁一旦出現，企業就無法敏捷的對外在變化做出反應。
某些軟體工程學派認為，SA不必然需要了解後面接下來的軟體設計在做什麼，就如同SA不必然需要具備domian knowledge。你認為這真的行得通嗎？

由：Kenming Wang

Kenming Wang — Tue, 15 Jan 2008 17:10:19 +0000

Hello psy:

"SA應該明確的知道軟件的價值" ，這句話好！！ ^^

由：psy

psy — Tue, 15 Jan 2008 10:50:56 +0000

我觉得SA必然是软件设计专家，而领域建模是从软件设计角度对业务领域专家级认识，所以SA也必然是一个角度的领域专家。
在做领域分析时业务对象的领域专家固然重要，但是operator同样重要。一个完整的业务系统需要包括各种细节，而业务领域专家是不能提供这些的。
SA应该比业务领域专家更有价值，因为SA可以在系统分析业务领域的基础上帮助业务领域专家完善业务流程。
SA应该明确的知道软件的价值。

由：Kenming Wang

Kenming Wang — Sun, 11 Dec 2005 21:24:21 +0000

Hello nick

其實，我這一篇文章發表出來，就知道會有許多不以為然的批判。

不過，藉此思考 SA 該具備什麼樣的基本功夫、所擔任的角色與定位 …等，提供另類的參考。 ~_^

由：nick

nick — Fri, 09 Dec 2005 10:05:10 +0000

『軟體設計，也是一門專業的領域，而這一門領域，其門檻絕對不會來得比其它領域還要容易，對工程、管理、邏輯、心理、藝術等等，均需用心研究思考與學習』。有所感。