jim yeh on 八月 27th, 2007

在軟體開發過程中,需求變動往往會令開發團隊十分困擾,即使許多開發團隊在設計前做了許多努力,希望找到軟體的最完整需求,同時要求使用者確認下來,但最後卻還是發現需求變動終究還是不能避免。最近,同人在上班搭公車的時候,遇見了我目前所參與專案的前一任專案經理,他聽別人告訴他專案此階段已近尾聲了,客戶卻還一直在改需求,他向我表示,他很不能理解這樣的狀況。 怎麼現在還再改需求,那這樣向 power user 展示系統請他們提供對系統意見又有何用? 正巧此時他的站到了,必須下車,臨去之前我只得微笑著告訴他:"需求會變動是很正常的一件事",但我從他的眼中看到他疑惑,似乎是認為專案在需求確認後,不應該任由客戶變更需求。 同人可以理解這位長官的看法,站在管理面的觀點,需求變更會對專案造成不小的影響,既然之前雙方已經針對需求做過確認了,就沒有理由讓需求一改再改,不能因為客戶臨時產生一些新的想法,就要迎合他們改變需求。 不過,從另一個角度來思考,要找到軟體所有的需求,是一件很困難的事情。

Continue reading about 被遺漏的需求

     
jim yeh on 八月 24th, 2007

在人際溝通的過程中,我們聆聽他人的意見,並發表我們對他們意見的看法。不過,在彼此間充滿著歧見及情緒反應的討論中,我們常常無法靜下心來傾聽對方所要傳達的訊息。於是在聽從主觀的思想而忘卻聽從內心的客觀分析的狀態下,結果讓我們聽到的都是我們想要聽的部分,卻把不想聽的部分刻意忽略掉。 在這種情況下,我們試圖取得討論的主控權,卻無法參與共同的對話並促進集體思考的創造力,討論的結果往往會變成流於無謂的爭辯。最近同人正在閱讀《深度匯談》這本書,書中提到了在對話中必須先聆聽對方的重要觀念,並提供了一些方法讓我們可以藉由互相地聆聽對方而學習以共同的觀點來思考問題。 《深度匯談》作者威廉.伊薩克認為,我們的想法往往是基於過去經驗對現在情境所形成的推論,它並不是事實,事實是可以透過直接觀察得來的,而不是按照過去經驗推論而來的,這樣會造成個人的偏見。在對話過程中,我們必須堅持事實,依據過去經驗而做推論並不是思考,而是對回憶的反應。所以我們必須能將「依據經驗所做的推論」與經驗本身區分清楚,而書中提到了「推論之梯」,就是可以達成這個目的的工具。

Continue reading about 傾聽的技術

     
jim yeh on 八月 21st, 2007

我們通常會用「工程師性格」來形容那些不擅人際交往,卻能專注於某些專業技術領域的人。大部分的人認為工程師的理性多於感性,這種人雖然缺少生活情趣,不大會與人溝通;但他們實事求是、崇本務實的精神,卻是默默地問題解決者。最近同人向一位朋友提到,我對他印象中認為服務態度不錯的客服人員對我的服務態度覺得很不以為然,因為那位客服人員堅持他們的系統沒有問題,卻沒有了解為什麼我使用上會出狀況,我認為這個客服人員根本就沒弄清楚狀況,就急著斷言他們的客戶使用上沒這個問題,但難道我不是他們的客戶嗎?朋友認為,那位客服人員的反應是工程師性格的表現,所以他認為他還可以接受這種狀況。 先不管那位客服人員是否有工程師性格,同人在比對了朋友在使用相同系統所使用的操作環境後,馬上發現問題所在,該系統並未考慮 Firefox 的瀏覽器,而恰好我是透過 Firefox 來使用系統,於是造成中文的編碼問題,用 IE Tab 就很輕易地解決這個問題。 解決了我的問題後,同人向朋友表示,個人不喜歡這種工程師性格,我認為真正的工程師都會探究問題找答案。不過,朋友對此提出了不一樣的看法。他認為我要先思考一個問題,是否我也是有工程師性格,一般而言,這樣很容易與對方發生衝突。

Continue reading about 工程師性格

     
jim yeh on 八月 20th, 2007

要脫離思想的洞穴,我們必須審視我們的信念,是否忽略了我們不知道我們所不知道的事物而有所遺漏或偏頗。所以,多參考別人的觀點,學會讓自己從不同角度來看事情,這樣才能經得起理性的考驗。

Continue reading about 思想的洞穴

     
jim yeh on 八月 15th, 2007

在 OO 社群中,由人稱 GoF 所著的《design Patterns: Elements of Reusable Object-Oriented Software》[1]被認為是物件導向軟體設計的重要典範,但最近在 InfoQ中文站,有一篇文章的主題是 〈InfoQ: “四人帮”的设计模式经得起时间的考验么?〉,提到這本書最近被人質疑已經與時代的發展脫節,書中解決問題的方式已經可以由新的語言來做更好的處理,用書中的設計樣式[2]來解決設計問題還會增加不必要的複雜度。 這篇文章提到對設計樣式的反面意見主要包括了設計樣式是一種複雜性的表現形式、對設計樣式的樣板式代碼(boilerplate code)的需要,代表在設計思路上的問題,也就是開發者所使用的語言基礎結構出現問題的信號、以及設計樣式阻礙了《A Pattern Language – Towns, Buildings, Construction》這本建築架構思想的傳播,本書是被公認是激發了資訊科學領域內的設計樣式運動。 附註  中文版為由葉秉哲譯(2001),《物件導向設計模式》,美商普林帝斯霍爾國際出版。[↩]有關 design pattern 一詞,中文有兩種翻譯方式,設計模式與設計樣式,同人習慣用「設計樣式」來稱呼之。[↩]

Continue reading about 設計樣式已成明日黃花?

     
jim yeh on 八月 11th, 2007

本篇文章不談高鐵,而是從我所寫的〈從高鐵談大型公共建設軟體開發專案〉的上下篇的讀者迴響中,發現有一些值得探討的議題,在此做個整理。

Continue reading about 大型公共建設軟體專案後續討論

     
jim yeh on 八月 8th, 2007

高鐵售票系統出問題只是一個實際發生的事件,對同人而言,這單一事件的意義不在於批判對錯及追究責任,就如同三百公斤的豬是不是一頭肥豬,其重點不在答案本身,真正令我感興趣的地方是從高鐵售票系統的問題,是否能讓我們從單一事件中有效推論出不徧差的大型公共建設軟體開發專案的實際情形,到底是只有高鐵售票系統那麼誇張,還是每個大型公共建設軟體開發專案都是一樣,只是出包的地方不一樣?

Continue reading about 三百公斤的豬

     
jim yeh on 八月 6th, 2007

思考的可貴處並不在結論的是非對錯,其在於體驗思考的歷程。事實上,執著於是非對錯是沒有用的,因為隨著生活情境的轉變,對與錯、成功與失敗都不是恒常不變的,所以重要的是如何從過程中清楚自己的角色而讓我們的心智更臻成熟。

Continue reading about 未嘗知義的「不得於言,勿求其心」

     

本文係投稿於 CNet / ZDNet Taiwan 的上下兩篇文章初稿,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。 這篇文章引來不少爭議,有人認為同人是在為某些組織消毒,所以把同人當人假想敵,而有些情緒性的言詞批評與指責。也有人認為同人說高鐵售票系統未用資料庫技術就是問題所在,以為高鐵售票系統的問題就是迷信新技術。還有人認為,技術才是解決問題的關鍵,要用技術的角度來思考問題才是標準答案。 對於這些意見,同人認為別人的情緒是他的問題,我會寫那篇文章,並不想為誰辯駁,只是提出個人思考的觀點,所以要把同人當成假想敵,想激怒我,本人可沒那麼容易上當。至於看到迷信新技術的推論,實在令人大開眼界,不幸地,這個推論顯然是錯誤的,這就是只會用技術看事情的迷思呀。至於要用技術觀點來思考問題的意見,同人覺得再解釋都顯得多餘了,過去我已談過太多了,碰到沒問題症候群(Gerald M. Weinberg,1986)的患者,這次我選擇躲遠點,明哲保身呀;^)。 以下就是這篇引來不少意見之文章。 高鐵售票系統在上線後產生一連串的問題,除了媒體不斷地報導外,網路上也引起熱烈的討論。其中批評與指責多過讚美,同人對這些意見的感想是「外行人看熱鬧,內行人看門道」。我們是否能從他人的失敗經驗得到些許啟示;還是跟著湊熱鬧,把它當成茶餘飯後的話題,是很值得深思的問題。

Continue reading about 從高鐵售票系統談大型公共建設軟體開發專案

     
jim yeh on 八月 3rd, 2007

最近 ZDNet Taiwan 為同人開闢了「軟體開發見聞錄」的專欄,並將我所寫的〈從高鐵售票系統談大型公共建設軟體開發專案〉,分上下兩篇在此專欄發表。和上次我投稿的〈羅馬不是一天造成的〉比較起來,本篇文章引起了一些讀者的迴響,從這些讀者的評論看起來,似乎「高鐵售票系統」比較容易讓人感到敏感,而對我的文章有所指教。在看了這些對軟體開發見聞錄首部曲的意見,不禁讓同人深刻地感受到,態度實在是決定我們是否能深入思考問題的一大關鍵呀。 有讀者認為,大型公共建設軟體開發專案要讓大部分的人滿意,需要整體的合作與共識,例如"分包委外服務提供者"既然受人之託,就要忠人之事,若能做到的話,相信"做好關係人管理,達到同時兼顧所有關係人的期待"將不會是一項挑戰。 對於這個意見同人的看法是,在情感上,我認同”受人之託,就要忠人之事,就可以做好關係人管理”,但在理智及經驗上,卻往往發現事情往往會出乎我們意料之外。為什麼呢?人的問題太複雜了,除了資訊不對稱、利益的不相容所造成的代理問題外,還會有對方是否值得信任的風險決策、服務需求者與提供者雙方背景與專業的落差所造成的溝通困難等,都讓做好關係人管理這件事,充滿了變數,相信在實務上,對於參與過大型軟體開發管理者及開發者而言,以上是如人飲水,冷暖自知的呀。

Continue reading about 軟體開發見聞錄首部曲