l

2010年6月6日 星期日

再論 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 還不強,真的是太超過了。

沒有留言:

張貼留言