本篇文章是投稿 ZDNet 文章〈親愛的 User,為什麼我不懂你?〉的原稿,並分為上下兩篇刊登。原稿未經 ZDNet 編輯,其內容可能會與刊登的內容有約略的不同。
很多人都知道溝通對專案的重要性,透過溝通,開發者可以瞭解使用者的需求,並據以實現。然而實際上,專案的溝通卻常會因為種種原因而出現問題,除了無法實現使用者需求之外,還會造成使用者的抱怨以及不愉快的使用經驗。
無論建築或是軟體開發,溝通不良都會造成專案的失敗。如同 ZDNet 副總編鍾翠玲所觀察到的現象,建築師無法了解使用者的需求就相當於軟體系統架構師或專案經理不了解使用者的作業流程或習慣,結果就是建造出不合用的建築或軟體系統。
鍾翠玲從災後學校重建的實例中看到建築師與校方的溝通上出了問題,她認為這是因為校方沒有積極地參與設計的緣故。我們很難知道這是否是實情,但如果在軟體專案碰到同樣的現象時,筆者不一定會認為是因為使用者缺乏積極參與。從筆者的專案經驗顯示,即使使用者積極參與設計,開發者還是會因為與使用者之間存在觀念溝通上的藩離,而聽不見使用者的心聲。
組織邊界的隔閡
傳統的工業經濟,由於講求大量生產,客戶無須與製造者溝通,因此沒有溝通的問題。但知識經濟強調的是可以符合不同客戶差異性的需求,因此開發者必須與客戶溝通以進行客製化的工作,然而組織邊界的藩籬卻經常增加了溝通難度。
軟體開發者與使用者所遭遇的問題常常不一樣,並且受限於環境、背景、專業、能力等因素,對問題往往會有不同的表達方式或認知,這也就常常造就了先天上的溝通障礙。
為了讓彼此的溝通更加順暢,資訊部門常會擔任開發者與使用者之間的溝通橋樑。他們與使用者處於相同的組織,會比開發者更了解使用者的問題;同時資訊部門也比使用者更了解資訊技術的專業,與開發者溝通會比較不會因為技術背景不同而產生認知上的落差。
然而實際上卻不盡然如此,開發者與資訊部門的溝通還是會讓開發者不見得可以正確無誤地聽到使用者的心聲,其中的原因之一是因為組織邊界是相當不容易跨越的。筆者曾經與石頭成、喲哪桑討論過這個議題,提出了我們各自的經驗與看法。
筆者認為開發者與資訊部門之間,存在對專案不同的期待與目的,使得彼此很難建立共同目標,除非彼此之間存在足夠的信任。在沒有足夠的互信基礎下,彼此之間很難達成共識,而造成了交易成本的增加。
石頭成認為開發者與使用者之間,交易成本的增加是因為資訊部門與開發者的專業經理並不是真的系出同門。他提出了資訊部門的出身科系以資管系居多,開發者的專案經理的出身科系以資工系居多的假說。他認為如果此假說成立,正代表了資訊部門與專案經理之間互相不知道彼此在想什麼。也就是說專案經理不敢承諾資訊部門提出的需求;資訊部門不肯為專案經理提出的功能背書,因此產生了龐大的交易成本。
喲哪桑則根據他的觀察提出了另一種可能的觀點,也就是研發人員與資訊部門心中的技術階級制度在作祟。他發現很多人常常覺得系統管理的階級,比做研發人員的來得低。他提到:
如果大家都有這種心態,溝通起來就好像走在地雷區一樣,有的RD會覺得自己為顧客恩賜的五斗米而折斷了腰,有的MIS更成了從自卑感而產生的自大狂,大家都是未爆彈,衝突隨時一觸即發。
其實從筆者與石頭成與喲哪桑的討論來看,不難發現開發者與資訊部門之間的溝通問題大致可分為彼此之間資訊不對稱的現象與利益衝突不相容兩方面來看,而依筆者的觀察,這兩方面的原因彼此之間會相互增長,正如下面的系統思考圖所展現的動態系統模型所示:
如圖所示,資訊不對稱的現象會因為利益衝突而不斷加劇,當甲乙雙方的利害關係是不相容的,那麼就會有一方會想辦法增加資訊不對稱的現象,而另一方則想辦法減少資訊不對稱的現象,因此,資訊不對稱的現象不可能會被消除,而且我們更可以推想得知,雙方鬥法的結果,引發衝突是必然的結果,差別只在於是否浮上枱面。
組織觀點的不同步調
因此對開發者而言,要聽見使用者的心聲,必先縮小組織邊界的隔閡。開發者應該要與客戶建立足夠的互信基礎,讓彼此能夠朝向共同的目標而努力,同時必須善用溝通技巧與問題解決能力來解決衝突。然而,如果這些開發者都做到了,是否就能夠跨越觀念溝通上的藩離呢?其實,這代表考驗才正要開始呢,因為觀念溝通上的藩離還有第二個成因,那就是組織觀點的不同步調,常讓開發者無所適從。
資訊系統的開發往往會牽涉到許多複雜的觀點,資訊系統本身本來就是在各種政治因素妥協下的產物。即使撇開工程技術觀點不談,社會技術觀點就夠讓開發者疲於奔命了。筆者觀察到在軟體開發過程中,業務流程與資訊整合常會因為觀念上的不同,而出現相互競爭的現象。
使用者最清楚業務流程,因此應該讓開發者與他們直接溝通需求,而由資訊部門扮演支援的角色。但這樣做的缺點是容易造成資訊整合的困擾,使用者心目中的理想系統,可能會與現存的系統有些不一致的地方,而造成整合的困難。但如果沒有進行整合,組織將會存在兩種不同的作業方式,而讓管理變得更複雜。
因此,如果考慮到資訊整合的問題,通常會讓資訊部門用策略的角度來看資訊系統開發,由他們來提出系統需求。但這樣做的問題是,資訊部門往往不能體會使用者的實際需要,使得開發出來的系統功能不見得會符合他們的需要,甚至要削足適履才能完成作業。往往為了遷就系統的設計,讓他們在系統操作上倍感不便,因而降低他們使用新系統的意願。
使用者與資訊部門觀點上的矛盾,突顯了在企業組織中,業務流程與資訊整合之間存在著步調上的差異,而這樣的差異往往會升高組織中同步化與非同步化之間的緊張關係托佛勒在《Wealth 3.0 財富革命》一書中提到時間觀的改變已對我們的生活產生一些影響:「許多重要的機構確實步調不一,同步化與非同步化的關係將愈來愈緊張,追求速度的趨勢並未改變,時間的安排愈來愈不規律,生產力與時間的關聯愈來愈小,每一刻都比前一刻更值錢,人類已有能力測量、探究、控制極大或極小的時間單位-這種種現象顯示歷史性的重大改變正在發生。」(張美惠譯,2007,〈新時間觀〉,p70,時報文化出版。)。
開發者的純潔心靈
這種同步化與非同步化的緊張關係,其實在軟體需求者的組織當中是隨處可見的。每個專案關係人對資訊系統總是存在不同的目標與期待,而開發者很容易聽到較有影響力或擅長掌控者的聲音,卻不容易聽到或是容易忽略那些受到壓抑的想法,但這些想法卻可能是專案成敗之關鍵所在。
在組織中,很少人會去質疑主流或具有權威性的想法,但主流想法常常是不合時宜,只是因為受到習慣領域的影響而根生蒂固。即使組織中有少數人會挑戰這些想法,但卻又常常會因為「政治因素」而讓他們受到排擠。然而,開發者可以有機會發現它們,讓組織出現轉變的契機,然而這必須保持開發者的純潔心靈。
如同筆者曾參與過的專案,有一位企業高層的告誡:「你們千萬不要被『業務流程』污染了『純真的心靈』,應該專注思考如何用資訊技術來創新流程」。使用者的心聲並不在業務流程,而是如何找到他們關切的問題,然後為他們創造價值。因此開發者必須用心傾聽那些微弱的聲音,才能聽見使用者的心聲,這個道理我想不管是建築或是軟體開發,應該都是一樣的吧!
現在的工作內容總是被「業務流程」污染著…
所有的工作流程和時程都要跟隨著「業務活動」
著實吃力….
主管們一堆幫不上忙得廢話…
「你自己要告訴我你需要甚麼資源幫助你的工作完成….」
見鬼了…真的提了
都說「有難處」「這個是你自己的問題」「這個你自己要解決」
….
牢騷發完了
但卻離題了 :p
自動引用通知: 同人的生活派對 » 可用性與可靠性的設計考量
天啊~
完全看不懂此篇文章到底要說什麼…
好像只是寫給行內人看的一樣啊~
難怪您的標題會是聽不到使用者心聲了。
連隨便過路的都看不懂你的文章的話…..
恩!好在我只是過路的啊~
使用者理論上應該最清楚自身的需求是什麼,以室內設計為例,一個對現時住家內部環境不甚滿意的使用者,找來設計師一起討論如何設計出真正令人滿意的設計,菜鳥設計師可能只會依照使用者提到的需求來加以設計,看似沒錯,但對於室內設計領域極度不熟稔的使用者而言,不見得很容易看到自己究竟想要的是什麼,幾句諸如「我想要改進收納的空間」不見得會產出令使用者激賞的設計成品。有經驗的設計師,以同理心去體會使用者提出的問題,自身模擬為該使用者,才能比較貼近使用者的角度來進行設計。
以資訊產業而言,藉由資訊科技的軟體產品來改進傳統作業流程,確實使用者應是最熟悉各流程細節的,例如流程中應包含報價試算單、正式確認訂單、撿貨、出貨、應收帳款、實收帳款、沖銷等等,但各行各業流程皆有出入,一套軟體產品如無較多可客製化選項,難以滿足多數客戶。再者,有些客戶自身的流程便已存在矛盾或是問題,阻礙了企業的進步與效率,即使依其現狀量身打照,充其量只是換套工具,把原有的人工換成軟體輔助,問題依舊存在。使用者可能知道問題的存在,但不見得確認該怎樣改進較好。
開發團隊普遍偏向邏輯與理性化,必須給他們明確的功能需求,然後他們就依此設計以滿足功能需求。對於需求本身不明確實,開發團隊就不易設計出使用者真正想要的產品了。
讓開發團隊的專案經理親身與使用者討論功能細節也許是較好的方法之一。
不過我覺得理想上每個部門裡若能都有一位較為通才的人,或者至少較擅長溝通與理解的人存在,應能達到較好的結果。也就是說,使用者裡有位較有程式概念與資訊技術概念的人;資訊部門有位較有使用者實際流程概念的人等。