被貶抑的猴性

人類擁有理性思考的能力,能夠分辦是非善惡,用理智來戰勝私欲,以展現出行為的道德。但世界上是否真的存在客觀而公正的道德標準嗎?最近 Mr.6 在〈猩猩也懂禮義廉恥?但道德本身也是猩猩?〉引用了《時代雜誌》的一篇報導,提到我們所自認的道德觀,本身其實也只是一種猴性。

Mr.6 提到科學家實驗證明,當一個人面對「人生難題」必須思考並做出可怕決定的期間,大腦出現剌激反應的部位,卻是主掌情感的區域。科學家認為這是本著人類同理心的緣故,而且這種反應似乎是與生俱來的,但同樣的反應,卻也可以在「沒有思想」的猩猩族群中觀察得到。而所謂會突然「做壞事」的人卻是由於「裡外之分」的排外性所招致而來的對抗現象。

因此,所謂「道德觀」其實並非得至於理性思考,而是來至於我們的個人情感。Mr.6 認為,道德本身就像猩猩一樣原始,根本就是「猴性」的一部份。道德本身也是某種「猴性」,「猴性」一點也不文化,一點也沒有智慧,是一個容易在不知不覺中被濫用的東西。

Mr.6 認為這是人類最根本的矛盾,當處於負面情境感受到所謂的猴性時,不優美的處理方式讓旁人無法警覺猴性的存在;而在一般的狀況下,對大多數的人而言,卻又對猴性渾然不覺,加深了彼此不必要的積怨與矛盾,其實大家都是共犯。他反而認為與其「追求道德」,不如去「避免猴性」。

既然科學家證實原來道德是「猩猩級」的東西,與其「追求道德」,我覺得比較有智慧的方式,是「避免猴性」。而「避免猴性」的方法卻簡單不過了。我覺得,其實就是永永遠遠的「正面待人」即可。從每個人開始。

上述的觀點點出了一個重點,那就是「道德」無法外求,這樣只不過會讓我們的善意遭到濫用,反而變成猴性的原始性格,藉由道德把個人的私慾包裝起來,這樣將使人禍比真正的野獸還可怕。道德必而是透過不斷地過濾心中的偏見、虛妄等雜質,在去除我執的過程中,才能真實體現出它的真實面貌。Mr.6 認為,要永遠正面待人,要正向思考,這樣就可以使我們不處於負面情緒中而以創造來取代批評。

稱讚與鼓勵得確比指責與批評還來得有創造力,貶抑會讓人難以從負面的能量磁場中脫困,降低生活品質,實在是損人而不利己的。然而,我們所處的世界本身就是堪忍的,不完美的,善與惡本來就是一體兩面的。沒有惡的存在,就無法彰顯善的可貴;要成就善,必須經歷惡的考驗。因此,當我們要別人「正面思考」時,不知不覺我們會不會也會陷入了指責與批判的陷阱中呢?

在 Mr.6 那篇文章的迴響中,李目白的留言就指出了這個問題。他認為對他人的批評,不妨抱持著對待不懂得欣賞自己的優點者,也應當給予誠摯的祝福,尊重對方的批評。他說:

我也很難理解有些人扔下的指導棋,竟然是要別人"別這想","別那樣想",指正文字數據引用上的謬誤是理所當然,若是對方以學說的方式來談一件事情到也還有論戰的空間。而今天人家只是提出一個觀點,批判必有其立場。

看懂對方為何而說,基於什麼立場去切入之前,只因對方沒講出自己想聽的東西,只因對方沒有談出自己認同的觀點,就直接否定掉對方的想法

而棉被俠也提到了,解決道德難題的重點還是在於要對原始的猴性有足夠的了解,而了解的過程需要自覺。他說:

隨時正面與自我做交鋒,保持隨時隨地的「自覺」與「覺知」的「過程」,才能開始瞭解所謂「猴性」,有足夠瞭解的前提,也才能選擇要與其「作朋友」還是要「揚棄」。

另外,有網友在 funP 回應了對這篇文章的看法,他認為不聽批評不就成了一言堂,他並舉了 Mr.6 近日所寫的另一篇文章為例,Mr.6 與一群創業家在「抱怨」印度工程師,所以他認為 Mr.6 這篇文章反而罵到了自己。

從上面這些人的意見中,同人發現 Mr.6 的觀點並不是錯了,而是有簡化問題之嫌。 閱讀全文 →

分類: 思考, 新時代, 生活感觸, 閱讀 | 2 則留言

當軟體專案計劃趕不上變化時

軟體專案在「收尾巴」之前,很多專案的利害關係人都會很樂觀地認為,軟體的問題可以在收尾巴的過程中得到修正。然而,當大家發現專案後期因為需求變更與軟體本身所存在的缺陷產生複雜的交互作用,使得軟體問題不斷地發散,才會發現,收尾巴?!這應該還沒開始吧!

對此,志威兄提到,從程式設計者、網站委外服務之業主、專案管理者之間,存在了觀點的差異。而他指出,讓專案順利及圓滿完成的解決方案就是找到一個稱職、有能力的專案經理。志威兄認為良好的專案經理除了具備相當的領域知識與時程控管能力外,最重要的就是溝通協調能力,他提到了:

他必須將老闆時長過於遠大的夢想,找到執行與實做的方法,更要能溝通協調把像在各星球各自為政、不同部門的理性嚴謹工程師與行銷、美工等創意人員,通通揉合在一起朝相同目標前進。也能夠事前就規劃好整個專案的時程,並且設定適當的check point,隨時掌控進度與各部門狀況。

事先做好規劃,按照時程追踪進度無疑是確保專案成功的基本動作,相信大家都能了解這個道理。但事實上,在軟體專案的開發過程中,要完全做到卻又發現窒礙難行,因為軟體開發本身存在著抽象性與變動性,要事前就規劃好整個專案的時程,恐怕只是個無法實現的理想。

然而,雖然「計劃趕不上變化,變化比不上老闆一句話」,但趕不上或比不上並不代表要放棄計劃,否則專案的成功也只是聽天由命的偶然罷了。同人認為,軟體專案要成功,關鍵不在於如何照計劃進行,而是要「計劃」當計劃趕不上變化時該怎麼辦。換句話說,當軟體專案管理者把計劃當成死的名詞時,他將不會成為稱職的專案管理者;稱職的專案管理者會把計劃當動詞,用以採取適當行動,才會讓專案走向成功。 閱讀全文 →

分類: 分析設計建模, 品質文化, 問題解決, 專案監控, 專案規劃, 生活感觸 | 3 則留言

迷途

我們的想法常常受到旁人意見的左右,他們的好心好意常會為我們帶來莫大的困擾。最近朋友 Jan 對她的星盤中缺少土象星座特質深感困擾,她擔心缺少「穩定度」是她的宿命,萬一這個特質難以透過後天發展,而將會使她無法出人頭地,這令他感到特別地憂鬱沮喪與難過。

Jan 在 blog 中的 Cbox 中的留言讓同人覺得疑惑,我認為「鍾鼎山林,各有天性」,Jan 如此介意缺少土象特質,想必她最近應該是發生了一些事情。

原來是 Jan 的一位老師給她的良心建議,告訴她要穩定個性。同時,其他業界前輩也提到,除了能力外,穩定性及工作能否長久也是重要考量因素。甚至有另一位老師告訴她,如果 Jan 可以表現得更積極,在工作上變得更穩定,那位老師將會介紹好工作機會給她。

這些意見無形對 Jan 產生了壓力,除了課業及考試壓力之外,還要改造個性,她不知道要如何才能讓能力在水準之上,同時更工作表現穩定。到底是按照自己的天性來發揮,或是避開會造成她變得不穩定的因素,還是努力發展自己沒有的土象特質呢?

我想 Jan 碰到人生的迷途了,我們常不知道該不該照旁人的意見去做。剛好昨天同人的姑姑搬新家,我開車前往祝賀。當我接近她家附近時,與導航者的溝通不清加上老婆的不明究理的意見卻造成我的迷途,我的迷途與 Jan 的迷途,大概可看做是一種巧妙的同步事件吧。 閱讀全文 →

分類: 占星, 思考, 新時代, 生活感觸 | 6 則留言

跨越遠端界面呼叫的藩離

在軟體開發的過程中,為了降低不必要的複雜度,開發者通常會採用設計與實作分離的開發原則。也就是在設計時,會針對使用者的需求來設計界面,讓設計並不涉及實作細節。直到了實作以後,才讓依設計的界面規格、以及實際軟體性能的考量來實作軟體系統。

不過,在使用者界面程式與應用服務元件不在同一個運行空間的情況下,彼此之間就會產生遠端界面呼叫的藩離。使用者界面程式如何穿透層層障礙與空間隔閡才能把呼叫要求傳送到應用服務元件呢?同樣的道理,應用服務元件又要如何才能把執行服務的結果傳送給使用者界面程式呢?

一般而言,遠端程序呼叫(RPC,remote procedure call)的協定是用來解決遠端呼叫的問題。在呼叫端發送呼叫請求訊息給遠端伺服器,然後根據呼叫端所傳送的參數將呼叫結果回傳給呼叫端。然而,對於各種不同的 RPC 的實作技術有著不同的調用協議,而且它們往往不能彼此相容。

可是這樣一來,在遠端呼叫的情況下,設計與實作就很難分離了。因為呼叫端的程式必須知道 RPC 的呼叫方式,它相依了 RPC 的實作細節。不同 RPC 的技術實作,會讓呼叫端必須更改呼叫的程式碼,因而產生了沒有必要的複雜度。

怎麼辦呢?同人在此分享個人的設計心得供大家參考 閱讀全文 →

分類: 分析設計建模, 設計原則 | 1 則留言

創業者的膽識

「只要找到好點子,就可以讓我開創出一番事業」,是許多創業者在開始創業時,深信不疑的基本信念。然而,最近獨孤木寫了一篇〈樂觀〉,提到創業者常以創業家自居,聽不進旁人對他的忠告,而直到自己碰到挫折以後,才會用較務實的態度來經營自己的事業,然後才能找到讓自己可以突破逆境的點子。他認為創業者未經失敗教訓的樂觀其實是一種無知:

我自己走過一遍,我現在的體會是,那不叫樂觀,那是無知。

要等到你好好去聽市場的聲音,然後客觀地去看待問題,然後朝著目標努力,不屈不撓地抱持希望,這才是真正的樂觀。

而在這篇文章的迴響當中,Ken 則提出了一些朋友的寶貴經驗,說明了有市場的創業才會成功,而沒有門檻的點子,不算是好點子。因為那樣很容易讓競爭對手模仿,最終將會演變成價格競爭的惡性循環。

從以上的觀點我們不難發現,創業並不容易,創業者必須面臨想法不被市場接受的風險、以及努力成果被競爭對手抄襲的風險。而真正敢面對未來的不確定性,有勇氣向困難挑戰,並具有突破困境智慧的創業者,才能成就自己的不凡,同人認為,創業成功最重要關鍵在於創業者是否具備足夠的膽識吧。 閱讀全文 →

分類: 思考, 生活感觸, 策略, 職場, 行銷 | 2 則留言

成就自己的不凡

「我們曾經想要好好地去生活,可是從來卻未曾真正去做」,這是我的一個同學曾經留給我的畢業贈言。而在日常生活中,也正如同學所言的,我們對生活、工作、乃至於家庭都會希望能按照我們的理想去做,然而實際上卻常因為某些因素,讓我們不去實現我們認為我們該做的事。

是理想不切實際,還是我們從來就沒有勇氣去實踐理想?雖然前者的可能性不能說沒有,然而,如果未曾親身體驗經歷自己的理念與想法,為何我們會知道它不切實際呢?當然,實踐的結果還是有可能是得到「理想不切實際」的結論。但一旦我們經歷這個過程,我們會真的知道為什麼它行不通,該做什麼或如何做才能行得通,而這些則是上天本就備妥的禮物,讓我們尋覓到屬於我們生命的桃花源地。 閱讀全文 →

分類: 問題解決, 專案管理, 思考, 新時代, 生活感觸, 職場, 軟體開發, 閱讀 | 4 則留言

傳遞智慧的火炬

志威兄 Aug 9 日前在〈技術創新的意義〉的迴響中提到:

「成就感」與「慾望」是人類向前進步的兩種動力,就像光與暗的兩面。不論技術、行銷,最終目的也都是為了幸福。要成功創業技術與行銷,兩者缺一不可。

同人非常認同志威兄的觀點,不論技術或行銷的最終目的都是為了幸福,因此要成功創業,技術與行銷兩者缺一不可。然而,志威兄運用光明與黑暗來比喻成就感與欲望的相對關係,倒是個有趣的比喻,也讓同人想到一些延伸觀點,也就是行銷與技術相互傳遞智慧的火炬。

如同志威兄所提到的,成就感與欲望是人類向前進步的兩種動力,就像光與暗的兩面。一方面技術帶來創造人類文明的成就感,另一方面行銷也關照了人性需求的欲望。因此,從志威兄的觀點來看,成就感與欲望是相互對待的,它們是一體兩面的。然而,從人類文明發展的歷程來看,技術所帶來成就與行銷所滿足的欲望卻相繼點燃了人類文明的火炬,傳遞了智慧的火光。 閱讀全文 →

分類: 思考, 生活感觸, 策略, 行銷 | 發佈留言

品質是檢驗出來的,還是設計出來的?

一般而言,軟體測試是為了提高軟體的品質,而因應軟體開發的不同進展,開發者常會採用不同的測試方法來控制軟體產出的品質。然而,前一陣子,James O. Coplien 提出軟體開發是宗教信仰驅動的產業卻指出了對軟體測試的質疑。

首先,Coplien 提到了做不做測試驅動開發(TDD,test-driven development)或是驗收測試是一個錯誤的問題,因為軟體開發應關注在品質上,測試所能涵蓋到的品質問題只是片斷而零散的,它是在軟體產業中所知當中,最沒有效率的方法。

然後,Coplien 用「宗教信仰」來批評 TDD 的追隨者,認為他們是盲目的而未加以審慎地思考它可能並不是最佳的實踐方法,同時對於任何的批評也會招致他們的情緒反應,他指出這已經變成一個宗教信仰的問題了。

Coplien 認為要用系統工程的角度來思考問題,也就是如何用最有成本效率的方式把工作做好,而新時代的敏捷運動卻一貫地脫離這些實務。他認為表面上加緊進行簡單的設計看起來很好,但一旦將這些設計放在一起卻會看到它們彼此是片斷而零散的。

不過,Coplien 的觀點在軟體開發社群中卻引來了不少的批評,有人提到對自己親身體驗到的成功所懷有的熱情是不應該與教條主義或宗教信仰混為一談的,更有人認為 Coplien 的觀點缺少事實根據,並且他的主張是懷有個人偏見的。〈软件开发社区“宗教信仰”之争风波未息〉總結這些批評提到:

Coplien 的核心觀點並沒有問題,只是選用了錯誤的論據進行了錯誤的證明。這也提醒我們要以冷靜理性的態度對待問題,否則便有可能在遠離一個極端的同時,走向另一個極端。

同人認為這個宗教信仰之爭是沒有意義的,甚至會覺得 Coplien 對軟體測試的批評讓我覺得很困惑,他想要表達的是什麼?他說要關注於思考而不要對新技術或熱門詞彙亦步亦趨,這個我同意,但從他的文章看起來,他似乎也不由自主地建立了另一個宗教信仰。

特別是「做 TDD,還是驗收測試?」這個問題更令我疑惑,這兩者明明是不同層面的問題,拿來比較有何意義呢?我不認為它是如 Coplien 所說的偽命題,相信應該還有更深的一層意義。

於是,同人換個角度來思考問題,驗收測試與 TDD 有何不同?一個是由客戶端來驗證軟體是否符合他們的品質要求,另一個則是開發者以測試驅動的方式來開發軟體系統。顯而易見地,這個問題的重點並不在測試,而是「開發者應該自己驗證程式,還是該仰賴客戶來幫你找程式缺陷?」。換言之,就是我們常聽到的一句話:品質是檢驗出來的,還是設計出來的? 閱讀全文 →

分類: 品質文化, 問題解決, 專案管理, 思考, 軟體審查, 開發流程, 閱讀 | 2 則留言

畫龍要點睛

在閱讀完了《金字塔原理》後,同人在閱讀上都會很習慣地去注意他人論點上表達的邏輯,希望能從其中欣賞或學習到一些不錯表達技巧以及有創意的文章舖陳的方式。而最近看到了一些文章,其所表達的觀點很有價值,其舖陳方式也相當順暢;不過,我卻發現它們並不是很容易閱讀。

問題不在於它們的用詞艱深難懂,而是缺乏明顯的論述主軸讓人一目了然讀到作者的中心思維,也就是缺乏《金字塔原理》這本書中所提到的「概括性論點」。就好像在畫龍忘了點睛一樣,即使畫作的畫工再精細,所畫出的龍的形貌再美麗,但缺少了眼睛的神韻,整條龍似乎就缺乏了展現翊翊如生的生命力一樣。所以畫龍要點睛,寫作也是一樣,缺乏概括性論點往往會讓讀者不容易抓不到作者想法的核心,自然就會阻礙了他們對文章觀點的理解。

例如,在〈張忠謀:大學生要做的十一件事〉中提到了張忠謀認為大學四年,大學生應把心思放在十一件事情上。這篇文章在 funP 獲得相當多的推薦,有人認為這篇文章很有實用價值。同人也認同此篇文章的價值,如果能夠完全吸收,其實對大學生未來生涯的規劃與學習是很有助益的;不過,我也認為這篇文章有一點美中不足,那就是一口氣列出 11 件事情,其實並不是一篇讓大學生很容易閱讀、理解、甚至吸收的文章。 閱讀全文 →

分類: 寫作, 思考, 溝通, 生活感觸, 閱讀 | 7 則留言

軟體開發者不應該自廢武功!!

本文係投稿於 CNet / ZDNet Taiwan 的初稿,並分為上下兩篇文章刊出,未經 ZDNet Taiwan 編輯,其內容可能會略有差異。

如眾所週知的,軟體開發專案具有高度不確定的特質。因此,為了降低需求變動的風險,在專案初期,軟體開發者往往會花費許多的心思,設計出具有彈性的軟體架構以適應未來可能的需求變化。大部分的開發者都了解軟體需求是不可能不改變的,但他們希望不管軟體需求如何變化,軟體開發的設計概念都不會因此受到影響或改變,如果可以做到這一點,軟體開發就會變得比較有效率,同時也能確保所開發之軟體的品質。

然而,現實總是和理想存在著一些落差的,專案的演變往往會超乎開發者事先的預期。尤其是當專案的驗收日期愈來愈接近時,專案可運用的資源也會愈來愈少,專案或許已不如剛開始時充滿了未知與不確定性,但相對地,專案的可變動性也愈來愈小。因此,在專案後期出現專案問題,或是需求的變動,相較於相同專案問題或需求變動在專案初期出現而言,會顯露出更為嚴重的危機與壓力的。

每個人都希望寧願事前多做一些風險管理,勝過事後的危機處理,而且後者的壓力是很容易讓做錯事的。然而,軟體易變的特質及專案環境的不確定性讓人難以捉摸,更不用說預測變化了,卻只能在事後才徒然留下「千金難買早知道,萬金難買後悔藥」的感嘆。但問題還是要解決的,到底軟體開發者在遇到這種危機時該如何處理呢? 閱讀全文 →

分類: CNet/ZDNet, 分析設計建模, 問題解決, 專案監控, 專案風險, 溝通, 系統思考, 設計原則 | 7 則留言