這篇文章是投稿 ZDNet Taiwan 的文章原稿,由 ZDNet Taiwan 以〈軟體開發的難處 SA該如何解決?〉、〈為何SA很難落實簡單設計〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯,內容可能與 ZDNet Taiwan 約略有所不同。

今(09)年初,應中山大學資管系主任鄭炳強教授的邀請,到他們學校做了一場演講。由於筆者與鄭教授原先並不認識,是透過台科大資管系主任李國光教授聯絡到筆者,因此,鄭教授邀請我在演講前先與他碰面、共進午餐,並且藉這個機會交流彼此在軟體工程方面的心得。

在那次午餐約會中,我們聊到了系統分析專業這個議題。鄭教授表示欣賞筆者寫的〈展現系統分析專業的七種能力〉,還曾在課堂上向他的學生推薦這篇文章…與鄭教授交流互動的過程中,也讓筆者得到不少收穫,回到台北後,一直想找機會分享這些收穫。

由於我一直想找機會回應那篇文章的讀者意見,也就是ZDNet讀者對於那篇文章的前半段〈怎樣才是專業的 SA?〉的一些留言,筆者發現這次行程的收穫,正好可以讓這篇文章有一個很好的起點。

軟體專案開發的四個困難

在言談之間,筆者可以感受到鄭炳強教授對台灣軟體產業發展很關心,但他對一般軟體從業人員忽略軟體工程的基本修煉卻很憂心。

他觀察到人們往往熱衷於追求新技術,而總是忽視軟體工程的基本原理。他還指出軟體開發與一般產品開發有著一個根本上的不同;也就是知道開發方法還不夠,更必須了解方法運作背後的原理。因為不了解原理就不能針對問題進行正確的分析與設計,更不用說可以有辦法順利地解決問題。

這也就是軟體專案比其它專案還要困難的地方,他認為軟體專案開發主要有四大困難,也就是溝通的困難、問題本質的困難、整合的困難、以及團隊合作的困難。後來筆者在他寫的書中看到更為清楚的對照;亦即「電腦對人腦、答案對問題、程式對系統、個人對團隊」。

More about 管理資訊系統站在資訊系統的企業觀點來看,資訊系統是企業為了因應環境挑戰而發展出來的解決方案[1],所以系統分析師必須找到可以解決真實世界的問題的解決方案,這是屬於解決方案的結構化範疇。然而,這意味著系統分析師必須比系統使用者更了解他們的問題,這些問題多半是半結構化,甚至是非結構化的,因此困難的是如何讓結構化的解決方案領域、與非結構化的問題領域進行溝通。

因此,建置一個可解決使用者需求的資訊系統,系統分析師必須要能發現藏在需求背後的真正問題,否則開發出來的系統往往會很難解決系統使用者的問題。正因為如此,系統分析師不能只考慮到技術層面,也不能把問題只是簡化成系統使用者所提及需要的功能,而必須將它們放在一起,統合思考以形成能夠相互協調的系統。如果想要達到上述目標,光靠個人單打獨鬥當然不夠,而是必須藉由團隊合作的力量。


圖1:問題領域與解決方案領域

該相信誰的專業?

所以,從軟體專案開發主要的四大困難的觀點來看,我們就能輕易瞭解專案成敗的關鍵真的不是 know how,而是在 know why。

這從〈怎樣才是專案的 SA?〉的回應中也可以看到。系統分析專業並不在於使用什麼開發方法,而是在於當開發方法碰到了阻礙或挫折時該怎麼辦?如果系統分析師沒有問為什麼的能力,不去弄清楚 know why,將很難克服上述的阻礙或挫折,使他們所熟悉的理論及方法可能無助於解決實際碰上的難題。

例如有位一路走來的 SA,留言提到他很怕遇到一種人,這種人會主張把系統設計得簡單點,但大多數卻習慣先把使用者需求簡化或忽略困難的部分。結果使得系統在後面的開發變得愈來愈困難,或是使得系統效率不彰。

還有一位訪客提到,台灣中小企業老闆普遍的觀念是「資訊系統應該是要配合他的需求而開發,而不是為了配合系統來改變公司」三不五時會表現出他們的官大學問大。遇到這些情境,系統分析師該相信誰的專業呢?

筆者相信以上是許多系統分析師經常碰到的問題。在軟體開發過程中,不同角色的意見常常是分歧的。如果系統分析師無法適時、有效地處理這些衝突,根本就很難施展出可以解決問題的專業。那麼系統分析師該如何有效處理軟體開發過程不同角色的歧見所產生的衝突呢?筆者認為解決衝突的關鍵不在系統分析師的設計才華、或是技術能力如何,也不在他所懂的領域知識有多少。

雖然這些能力確實在軟體開發過程中非常重要,但如果忽略了結構與非結構的隔閡,那麼即使擁有上述才華、能力與知識還是沒有辦法把心思放在對的問題上,而無法發展出適當的解決方案。

筆者曾在〈系統分析專業的七種能力〉提出系統分析師該如何思考與學習的方法以展現其專業。然而,從〈怎樣才是專業的 SA?〉的留言卻可以發現,許多人對系統分析專業的疑惑出在忽略「結構與非結構的隔閡」,使得系統分析師陷入了過度簡化設計與過度工程化,也就是所謂過度設計的兩難情境。

簡單設計並不容易

在觀念上,很多人都知道要把系統設計得簡單點,但實務上設計要做得簡單卻非易事。誠如那位一路走來的 SA 讀者所言的,許多主張把系統設計得簡單點的想法,最後多半變成簡化使用者需求或忽略困難的部分,使得後續開發或系統效能遭遇到瓶頸。

筆者很能夠體會他對主張把系統設計得簡單點的恐懼,事實上,筆者經常看見許多一開始強調設計簡單,到最後卻因為沒辦法適應變化而得修改或重寫,如果上述改變又牽動到系統架構,那更是使得問題變得更複雜。由此可知,簡單設計並不容易,簡化使用者需求或是忽略困難部分的設計,不能算是簡單的設計,而是過度簡化的設計。

筆者認為簡單設計代表設計的簡明與單純,簡明是指設計概念清晰,使人容易理解,同時也是讓系統分析師用來發現,有效解決問題的一致性概念。至於單純則是採用直接而純粹的實作,以避免不必要的複雜度,集中心力解決最重要的問題,不把時間浪費在無關緊要的事情上。

只有做到設計的簡明與單純,才不會因為無法善用設計的彈性來突破系統的限制,或是為了沒有必要的彈性而增添無謂的複雜度,否則將會使開發過程碰到困難甚至是失去控制。簡明和單純就如同天平的兩端,讓問題領域的重視變化與解決方案領域的強調秩序能夠相互激發出智慧的火花,形成穩定的動態平衡,而不是讓一端牽就另一端

很多系統分析師習慣地以「做的事情很簡單」視作簡單設計的認定標準,大概是因為基於設計解決方案的思考慣性,加上受到「簡單」的刻板印象。

殊不知簡單設計必須以解決問題為前提,忽略或過度簡化問題所做的設計,通常是無法滿足問題領域的現實需要。這種迷思特別是在導入新技術或開發方法時更容易看見。以為新工具或方法會讓開發過程變得更簡單而更有效率,結果反而卻為了遷就新技術或方法,使簡單的問題複雜化。

其實筆者並不是要否定新技術的價值,只是認為簡單設計的關鍵並不在技術、工具或是方法論,而是更需要思考與實踐的紀律,用來跨越結構與非結構的隔閡。透過思考,系統分析師才能弄清楚系統的最主要問題,知道如何將設計變得更簡單;而唯有實踐,才能驗證自己的想法是否正確而且能對解決問題產生效果,以力圖設計的完善。

「本質」的誘惑

雖然說系統分析師需要紀律以思考問題、以及實踐解決方案,但實際上要做到真的很不容易。筆者從實務的觀察中發現,很多系統分析師在設計過程中,都很容易受到本質的誘惑而更加深了結構與非結構的隔閡。

所謂的本質是指不管環境如何改變,但仍然會有不受環境變化衝擊的觀念或方法。筆者並非否定設計本質的價值,只是覺得「本質」這個詞很容易讓人們陷入迷惘。設計能力愈強、或是經驗愈豐害的人,愈容易受到本質的誘惑而迷失方向;一旦你愈堅持你所相信的設計本質,你就會愈容易忽視思考問題的存在。

在軟體設計社群裡,「本質」是個很容易被濫用的名詞,筆者認為系統分析師應該要謹慎地看待這個名詞,以免受到它的誤導而弄錯問題。筆者曾經在 plurk 看到生魚片提到,從 OO 的本質下手的心得,指出搭配重構與設計樣式再行體會,讓他更認識 OO 是什麼。我當時則提醒他當心設計本質很容易讓人弄錯真正存在的問題。

對於我回應生魚片的看法,cloudy 提出他的觀點。他認為設計本質是不會變的,只是在不同問題領域中,設計概念的資料與行為會有所增減。筆者倒是認為問題的存在會決定事物本質的不同,例如訂貨系統中的車子、與租車系統中的車子,在設計上是屬於完全不相同的概念。前者是達成交易的商品,而後者則是用來提供服務以收取租金的生財器具,真正販售的商品是租車服務而非車子本身。

如果同樣以「交易為中心」的設計模型,都存在這種本質的差異,那麼對於其它無法用交易解決的問題領域,更是難以讓系統分析師找到不會因為環境改變而受到影響的設計本質。因為,當存在的問題不同之時,對相同的事物會產生完全不同的意義。換句話說,設計本質並非固定不變的,而是因應系統所要解決的問題而改變。

其實,筆者也很難避免受到本質的誘惑,以自己過去開發過的銀行影像系統為例,一開始按照自己設計的經驗來建立設計模型,很自然地會將資料進行正規化的處理,對影像文件擷取交易的設計觀點。

但問題是這個系統與以往的專案最大的不同是,它並不需要處理交易的部分,而是由工作流程系統處理交易完成後,再通知影像系統以進行影像資料的存取。隨著使用者需求的變化,調整功能時卻發現交易的設計反而讓問題變得很複雜。這時才發現,以交易為主的設計本質並不適用於這個系統,而是重點在於如何讓使用者建立查詢檢索條件,方便讓他們找到需要的資料。

交易在此系統並不代表交易事件實際的發生(有沒有發生對此系統並不重要),而只是代表影像查詢或檢索的某一種條件限制而已。由此可知,想要找到對系統真正有用的設計觀點,並非針對事物的真實情況(本質)來建模,而是因應事物在問題領域中所表現的價值或意義(存在)來建模。

筆者認為,系統分析師應抱持開放的心胸,體認到軟體設計本質的未定論;存在並非由固定不變的本質來所彰顯,而是藉由創造本質的過程來體驗問題的存在,設計其實是「本來無一物,何須染塵埃」。

學而不思則惘,思而不學則殆

開發本質的不同常會導致設計爭論,例如強調以資料與程序為本質的論點,經常會批評用物件導向開發的設計典範。主要批評物件導向要寫更多的程式難以管理、以及開發出來的系統運作效率太差等弊病。

More about 黑天鵝效應當然,某些以物件導向開發的系統確實會出現以上的問題,但如果改成程序導向的開發方法就沒有問題了嗎?顯然這樣的想法是忽略了「沉默的證據」[2]之存在,沒有人用不同的開發方法開發同一個系統,所以我們很難確知在某一個專案裡,用程序導向開發是否不會出現更為棘手的問題。

從相反的角度去思考,強調物件封裝、抽象化、繼承就是軟體設計的本質嗎?這些原則是為了降低複雜度,增加元件的彈性與再用性而產生的。不過,如果這些設計原則找不到具體可以解決問題的實踐方式,那它們就毫無用處,只能代表系統分析師還體會不到設計的本質;這個時候,他想解決的問題多半並不是系統真正的問題,所以未來必將付出為了沒有必要的彈性而增加複雜度、以及系統效率不彰等代價。

由此可知,設計典範沒有優劣的問題,我們也很難找到可以因應在各種狀況下最棒的設計,只有是否正視問題而發展出適合的設計

沒有放諸四海皆準的開發方法,所以系統分析師不該以為他相信的設計本質可以解決所有問題,而是應該開放自己的心胸,停下來思考自己可能忽略的問題,並且與跨領域的知識進行交流與學習,以期將所知學及所知進行組合與內化。

如此一來,代表結構與非結構的兩種領域,將不會因為扞格而產生格格不入的衝突。總之,系統分析師應該調和問題領域的知識與技術領域的應用,使其達成穩定的動態平衡,再加上「系統分析專業的七種能力」,那麼系統分析的工作必然會勝任愉快。



附註  
  1. 周宣光譯,2000,《管理資訊系統-網路化企業中的組織與科技》,東華書局。[]
  2. 林茂昌譯,2008,《黑天鵝事件》,大塊文化。[]
     

3 Responses to “結構與非結構的隔閡-從軟體開發專案的四個困難談起”

  1. [...] 因此測試驅動開發可以讓開發者立即用最簡明而單純的設計完成開發工作,好處是讓開發者知道自己在做什麼,而非浪費時間在做沒有意義或無關緊要的事。但任何一開始簡明而單純的設計,在系統不斷演進及需求不斷改變之下,也可能會使架構或設計愈來愈複雜而變得難以維護。這時候單靠 TDD 的簡明與單純也可能沒辦法容納這種複雜性,而是要運用 Refactoring 來增加設計的彈性;也就是在不改變系統功能的情況下,改善系統設計的結構,使它可以因應未來增加需要的功能。 [...]

  2. [...] 因此,對於一些勇於實踐冒險精神的創業家而言,他們的成功是因為承擔風險而獲得的報酬,然而,不要忘記可能不乏有人和他們做了相同的事而失敗的例子,只是這些多半是「沉默的證據」而讓人不得而知。 [...]

  3. [...] 軟體專案的管理者應該注意,造就行為模式的結構一旦產生,人人都做自己以為正確的事,實際上卻造成完全相反的結果。這時候要領導專案團隊的正確方向,需要系統化思考,才能認清結構,以打破錯誤的行為模式。分工的迷思會讓管理者建樹不見林而沒有把穩方向。鄭炳強教授說過軟體開發有四大困難,亦即「溝通的困難、問題本質的困難、整合的困難、以及團隊合作的困難」,當我們思考「電腦對人腦、問題對答案、程式對系統、個人對團隊」時,如果單純的以為團隊合作就只是分工的話,那誤會可就大了。管理者必須以系統的角度來看整個軟體開發過程,而不是具細彌遺的微觀管理呀。       Posted by jim yeh 品質文化, 問題解決, 專案團隊, 生活感觸, 系統思考, 職場, 開發流程, 領導 Subscribe to RSS feed [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">