再論 Problem Domain vs. Solution Domain

6/6 21:08～22:50

前一篇『這不是髒話』還沒寫完，本集繼續。M小姐後來又提到：

[13:24:49] ­而且說那找一位好一點的分析師來有沒有幫助，還說沒幫助
[13:25:03] ­因為不了解 Domain Knowhow 太好的分析師來也沒用
­ [13:25:50] ­他們說要找懂 Domain Knowhow 深的系統分析師而不是只是很會系統分析的系統分析師

M小姐轉述她主管的看法，這就軟體開發或是做專案的人很典型的一種心態，認為只要找到所謂『domain know-how 』很強的人來分析需求，做出來的系統就沒問題。錯，錯，錯，連三錯。Teddy 的意思不是說 domain Know-how 不重要，相反地，domain know-how 真的很重要，但是實做的能力也同樣重要。用講的太慢，乾脆用唱的...不對，是用看的。請看下面這張圖：

Teddy 之前寫過一篇『Problem Domain vs. Solution Domain』，M小姐主管遇到的問題便是沒有弄清楚這個概念。先看看 problem domain（就是需求），所謂『domain know-how 』很強的人的就很懂問題領域，因此可以整理出很好的需求出來（寫出很符合各客戶所需的需求，甚至是客戶沒想到的都幫他考慮到了）。再看看 solution domain，以軟體開發而言，solution domain 就是軟體設計，實做，測試這些技術（姑且先把分析歸類為 problem domain 的活動）。

看看上圖的，一共可以分成四個象限：

• A：需求和實做都做對了，這也是我們開發軟體或廣義的說開發任何系統所要追求的。
• B：需求做對，但是實做一團糟。這比較接近 M小姐主管所希望的『找到 domain know-how 很強的人來分析需求』，但是卻不在乎如何改善 solution domain (如何改善軟體開發實做面的問題，例如自動化測試)。
• C：需求錯了，但是實做正確；結果還是白忙一場。人家要吃『素食』，結果你去買個『麥當勞』牛肉漢堡回來。
• D：需求錯，實做也錯。也許M小姐所負責的專案比較接近這個情況，所以才會（1）累積了600多的 bugs（實做錯）；（2）她的主管希望找到 domain know-how 很強的人來分析需求（需求錯）。 

經過 Teddy 一番分析，鄉民們應該就很清楚了，這個 Problem Domain 和 Solution Domain 的觀念真的是簡單到不行，可惜有些大官卻不是很了，或是有意輕忽 solution domain 的重要性。畢竟有許多雖然身處軟體業的主管們依舊把『開發軟體』簡化為只有『coding』，而他們又很瞧不起 coding。說實話，就算是把開發軟體簡化為只有 coding，也不可輕忽 coding。畢竟，軟體最後還是一堆程式，要對程式碼心懷敬意啊。

***

寫到這邊 Teddy 再附贈一個故事，話說當年（又是 10 幾年前的陳年舊事） Teddy 還是青澀少年時，曾參與一個用 Java 開發的『Intranet 進銷存系統』。當時參與的三個 programmers 都是沒有進銷存 domain know-how 的人，於是公司第一任總經理就找了他的一個朋友，就是所謂 domain know-how 很強的人來做分析。光是分析就搞了一年左右，寫了一本幾十頁的分析書之後就下落不明，剩下這三隻誤入叢林的小白兔，獨自與這份破綻百出的分析書以及無辜的客戶奮鬥。

經過 N 年之後，Teddy 已非當年的年幼無知的小白兔，也了解到這種『把文件丟過門』的方式是行不通的。很遺憾，講句不要臉的話，並不是所有人都和 Teddy 一樣有一直在看書與思考。很多公司的主管，還是抱持著 N 年前做案子的模式。要『慈禧太后』相信『洋槍洋砲』比『義和團』還要厲害真的不是那麼容易的一件事，就算是現在都快民國 100 年了還是一樣。

鄉民們想想『醫生』這個行業。醫生要看病，所以一定要懂 domain know-how，否則無法找出病因。接著，醫生還要提 solution，可能是做檢查，吃藥，開刀，或是其他治療方式。所以，醫生是 domain know-how 很強，而 solution 也很強的人（不過請注意，醫生的專業分工很細，每一科的領域很窄。但是軟體卻是包山包海，什麼領域都有。）。試想一下，如果醫生只有 domain know-how，他可能會告訴病人：『恭喜，您被診斷出得了胃潰瘍，至於如何治療不關我的事』。相反地，如果醫生只有 solution 很強（很會開刀好了），那麼醫生會告訴病人：『麻煩告訴我你想被切那一塊』... 這像話嗎。

軟體開發，需求是一直改變的，就好像是病人的病情隨時在變化，不可能看一次醫生（需求分析）吃固定的藥（solution）就 OK（這是傳統 waterfall 的作法）。在病人的病情隨時會變化的情況下，醫生與病人一定要隨時互動，才有可能掌握病情。想想 Scrum 的 sprint planning meeting，daily scrum，sprint，sprint review meeting，retrospective meeting... 精神都是一樣滴。丟掉傳統那一套分析師（架構師）做完需求分析就沒事的思維吧。

結論，講了那麼多了，再不懂這個觀念 Teddy 也沒沒轍了。

***

友藏內心獨白：M小姐的公司 F 1.0 版都做了 10 年了，domain know-how 還不強，真的是太超過了。