當專案一再出現相同錯誤時

本篇文章是投稿至 ZDNet 的文章,已由 ZDNet 以〈領導力 決定專案成敗〉與〈團隊關係 左右專案發展〉兩篇文章刊出。文章原稿未經 ZDNet 編輯,加上同人在文章刊出後修改原稿,其內容與刊登的文章有些差異。

繼「新官上任三把火」之後,馬政府團隊又在國慶大典發生意外狀況。位置安排出問題、加上安檢嚴格,引發部分參加大典的民眾不滿。例如資深藝人和僑胞發生搶位置狀況,還有一對位置被佔走的僑胞夫婦,居然還被工作人員趕出場外,真是又委屈又生氣。

看到這則新聞,筆者關心的並不是主辦單位碰到這些意外狀況該怎麼辦,而是好奇為什麼座位安排的問題會重覆發生?其實像座位安排並不是什麼困難的問題,不需要動用複雜的技術,只要用簡單的 Excel 試算表就不會有太大的問題。

如此看來,座位重覆的問題不太可能是技術的問題,筆者看到相同的錯誤一再發生,我會懷疑問題不是出在技術上,而是因為管理的關係,使得團隊一再出現相同樣的行為模式造成錯誤。

可能是因為領導者的領導能力不足,使得團隊成員的能力處處受限而無法施展。如果真是如此,那麼與其討論技術細節,還不如討論該如何領導讓團隊充分發揮能力。因為,就算今天我們知道如何可以解決座位安排出現錯誤的問題,領導能力不足,明天團隊還是很有可能在別的地方出現錯誤,造成其它的意外狀況發生。

筆者相信不管是那一種專案,管理上的領導能力不足都會造成相同的錯誤一再發生。就像筆者在軟體專案中所觀察到的情況一樣,專案經理的領導能力不足,使得團隊成員把精力浪費在沒有意義的事情上,以致於對專案目標的達成並無太大的助益。

當然我們並不能否認,團隊成員的能力出現了問題,或是他們不夠盡力,也可能會出現同樣的現象。不過,根據筆者多年軟體專案開發的經驗顯示,團隊成員能力不足或是其心態有問題的情況並不多見,多半是專案經理無法讓團隊發揮實力。所以當專案一再出現相同的錯誤時,專案經理應該先思考是不是自己的領導能力出了問題。 閱讀全文 →

分類: CNet/ZDNet, 問題解決, 寫作, 專案團隊, 新聞, 溝通, 生活感觸, 組織, 職場, 領導 | 10 則留言

心安平安

己丑年大年初三,同人到法鼓山農禪寺拜「慈悲三昧水懺」,並在法會結束之後,看到聖嚴師父對 2009 年新春祝福的影片。聖嚴師父表示,法鼓山有今天的成果,完全是來自十方大德的幫助,讓他心中非常感恩。不過,感恩之後應該要發願,才能夠讓未來比現在更好,他希望法鼓山能夠培養更多優秀的人才,致力於宣揚佛法,讓心靈環保的運動可以一直延續下去,並希望能讓北派漢傳佛教發揚光大。

聖嚴師父對 2009 年的新春祝詞是「心安平安」,他認為過去一年的驚濤駭浪,代表 2009 年將充滿希望。對未來懷抱著希望,並好好地安頓的身心,生活就會因此而改觀,也就是「只要心安,生活就會有平安」 閱讀全文 →

分類: 佛法, 新時代, 生活感觸, 神話 | 發佈留言

訊息交易的抽象化思考

在〈開發者的 common sense〉的留言中,同人看到一些網友的批評。我發現這些批評顯示了有些開發者不擅於抽象化思考,而習慣於用經驗法則來取代思考。然而,誠如 Brooks 所言:「軟體的本質是複雜的,而不是偶然發生的」對治複雜度本來就是開發者的天職,而軟體開發的抽象化思考則是其用以統理複雜度的利器。由此看來,那些網友的批評著實令人為他們捏一把冷汗呀。

從路邊的垃圾桶與路人的留言,我們可以發現他們弄錯 common sense 的意思。他們認為 common sense 不能一概而論,因為每個人的 common sense 都不同。但這樣的觀點令人感到疑惑,如果每個人的 common sense 都不一樣,所以無法一概而論,那這種 common sense 還能叫做 common sense 嗎?

到底他們觀點上邏輯的矛盾,問題是出在那裡呢?同人認為問題並不是開發者的 common sense 不存在,而是忽略了開發者應該將經驗化成一般性的通用概念。舉例來說,軟體工程領域本身就是從實務發展出來的理論,其中許多概念就是開發者必須知道的 common sense,對開發者來說是合理的知識,也是他們都知道、無須解釋或加以論證的常識。

由此可知,如果開發者缺乏一般性的通用概念,那他碰到問題就很難舉一反三,自然也就難以掌握重點,而只能依據表相來處理問題,往往使得問題變得更複雜。oofunp 的留言就很像欠缺概念思考的開發者常見的反應,一開始以自己熟悉的技術來看問題,最後才發現自己對問題的理解是錯誤的。尤其「以為抽象化是將資料庫定義抽象化」的想法,更是整個弄錯抽象化思考的意義,結果最後他還是誤解了業務規則的意思。

同人前一篇文章所提到的業務規則,並非來自技術領域上萬用的設計,而是對問題領域經過抽象化思考後,所萃取而得到可以解決業務需求的重要概念。顯然 oofunp 的誤解是以技術的角度來看待抽象化思考,才會產生嚴重的觀念混淆。事實上,抽象化思考重視的不是技術實作,而是如何從實際問題當中萃取出重要的抽象概念,以增進我們對問題領域的瞭解,才能採用最適當的技術來開發軟體系統。

此外,過份強調技術經驗而輕忽概念性思維的開發者,很容易表現出自己對問題的盲目。就像 X files 留言的批評一樣,責怪同人沒有交待清楚是 XML 格式的問題,直到別人提出質疑才說明與列出參考文獻,認為同人缺乏部落格文章寫作的 common sense。但我的文章已經很清楚地提到是有關「交易訊息」語法的問題,難道他不瞭解交易訊息是 XML 技術的一般化抽象概念表述嗎?XML 只是實現交易訊息概念的一種技術,用以解決跨系統整合的問題。如果他要看到 XML 字眼才知道是訊息格式的問題,那改天換了另一種交易訊息的實作方式,我想大概他腦筋又要轉不過來了吧。

以上網友的三種批評,表面上看起來好像是不同的問題,但其背後都存在同樣的本質,那就是從交易訊息的問題中可見一斑,他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢? 閱讀全文 →

分類: 分析設計建模, 品質文化, 問題解決, 思考, 易經思維, 生活感觸, 編程技巧, 設計原則 | 9 則留言

開發者的 common sense

最近某位開發者和同人討論需求規格的問題,但他的反應卻讓人感到困惑,不知是他的理解能力有問題,還是面對問題太過情緒化?以下是我們對話的內容。

開發者 D 君問同人:「規格好像沒有提到欄位空白該如何處理?」

同人回答:「沒特別說明就是代表將該欄位填入空白。」

D 君說:「為什麼不是未指定欄位內容呢?」

同人說:「如果是那樣,該欄位不應該在交易訊息中出現;但如果該欄位的內容是空白,那就應該不指定訊息欄位的值。」

D 君說:「不過,從交易訊息的定義來看,那個欄位是必要欄位,不可能不出現。」

同人說:「所以那個欄位是必要的,訊息中沒有指定值就代表欄位要填入空白。」

D 君說:「那規格應該交待這個細節?」

同人說:「不需要,規格文件不寫語法而只會記載語意,因為語法是屬於 common sense,沒必要詳盡記錄在規格文件中。不然,如果連 common sense 都要寫在文件上的話,那是否意味程式設計者也不需要懂程式語言了,反正文件上都會寫。」

D 君說:「我知道了,你的意思是說我沒有 common sense!」

同人說:「如果你覺得我那裡說你沒 common sense,請明說我可以向你道歉,否則你這種情緒化的言論,只會讓人感到不舒服!」

D 君:…

同人將這件事寫在噗浪上,有噗友認為這類的開發者能力不行,沒什麼產值卻會製造問題。不過,在此事我所看到的問題倒不是開發者能力,而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通,這才是我認為最可怕的事情。 閱讀全文 →

分類: 分析設計建模, 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 衝突, 設計原則 | 10 則留言

「牛」來如何運轉?

走過充滿荊棘與磨難的戉子鼠年,令人充滿期待的己丑牛年即將來到。相信很多人對即將完結的這一年,應該感觸良深吧!原來期待穩定成長的豐收,卻因為環境劇烈的變化而讓人感到驚心動魄。

同人在〈戊子年新氣象〉中提到,今年是在不脫謹慎守成格局之下,充滿轉折與利於成長的一年。然而,回顧台灣這一年的運勢發展,連我自己都認為這樣的預測太樂觀了。

到底是那裡弄錯了呢?並不是星盤未呈象,而是同人沒有想到局勢的變化有這麼劇烈,雖然戊子年開春及 2008 年立春星盤,都顯示代表工作的六宮運勢並不好,但由於代表經濟發展的二宮還不錯,才會以為那是復甦的過渡時期,卻沒想到實情並不如我們想像的如此樂觀。

其實,仔細看到立春盤的分析提到「注意因應時代趨勢的轉變,政策的變化很可能會引發激烈的抗爭,犧牲者為了爭取權益將會造成衝突,這將是執政當局將面臨的重大挑戰。」這句話,似乎也是顯示政府因應企業裁員或無薪假的道德勸說。此外,戊子開春盤的分析提到整體運勢起落很大、以及投資要注意風險也都提醒今天不應該太樂觀。

戊子年木土呈三合相位,同人知道有人會認為那代表木星的幸運,會承受到土星的壓力與緊縮,而代表不幸運。以今年大環境運勢的不順遂,可能很多人會認同這樣的觀點,但同人一直相信「木為歲星,不福無道;惑為罰星,不禍有德」的觀念,吉凶不在於星體本身,而是人是否在適合的環境做出恰當的行為。

天星只是每年按照它既有的規律在運行,如果人們沒有在大環境不佳的時候磨鍊或充實自己,又如何在機會來臨前,做好萬全的準備呢?因此,換個角度來看,今年所面臨的挫折與困難正是讓我們用謹慎的態度來面對轉折,以期在有利環境出現時讓我們成長。

己丑年將到來,木星已經離開好事多磨的魔羯座,而進入代表創新與突破的寶瓶座,「牛」年來我們該如何轉好運呢?且讓我們來看看己丑年的開春時盤與 2009 立春時盤怎麼說。 閱讀全文 →

分類: 占星, 思考, 生活感觸 | 1 則留言

消費券能否勸消費?

消費券終於在本週日,也就是 1/18 早上 8 點開始發放。從領券比率高達九成以上,以及這幾天各賣場業績暴增的現象來看,消費券增加消費的效應已開始發生,但它是否能夠刺激民間多加消費,並進一步達到提振經濟的效果呢?同人從消費券開始發放時間的星盤來看,消費券對經濟景氣正面的影響應該是肯定的,但應該沒有所謂的乘數效應,主要的原因是來至心理面的影響。

09011808.png

閱讀全文 →

分類: 占星, 思考, 新聞, 生活感觸 | 發佈留言

再談程式設計的迷思

昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結構上的問題。其實那篇文章除了結構問題之外,同人也在該篇文章內容中,發現了一些值得探討的問題,因此想在這篇文章發表我的看法。

以該篇文章內容而言,同人認為值得探討的有兩個地方,一個是程式語言一直再改變的迷思、另一個則是作者建議讀者,儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念,而第二個問題就是嚴重的偏見了,值得讓人進行思辨以建立正確的觀念。 閱讀全文 →

分類: CNet/ZDNet, 分析設計建模, 問題解決, 學習, 思考, 編程技巧, 職場, 設計原則 | 2 則留言

又見少了概括性論點

在寫作的時候,很多人喜歡以條列要點來表達觀點。一般而言,條列要點要比平舖直敍還來得簡明扼要,它顯示了作者的重要論點、並讓讀者可以決定是否要仔細閱讀的依據。然而,文章條列要點要寫得好可不簡單,它需要更多的思考。否則即使文章洋洋灑灑地羅列了許多的要點,卻還是讓讀者不知道文章重點在那裡,呈現出觀點的空洞化。這都是因為寫作缺乏「概括性論點」,條列要點沒有展現作者的思考脈絡所致。

例如同人過去在〈畫龍要點晴〉中,就指出兩篇很有價值的文章,因為缺少了「概括性論點」而使文章失色不少,讓人覺得非常可惜。今天,我在 ZDNet 的名家專欄中,又看到〈必須面對的真相─五大程式設計迷思〉也同樣少了「概括性論點」,讓人覺得該篇文章不知要表達什麼重點。同人從空洞的論點背後,看到作者的思考似乎還沒有完成。 閱讀全文 →

分類: CNet/ZDNet, 學習, 寫作, 思考, 溝通, 生活感觸, 知識管理 | 發佈留言

三個不回應匿名批評的原因

在網路上發章文章,同人很重視讀者的留言,因為讀者的回應,可幫助我們改進文章的內容。有道是「泰山不讓土壤,故能成其大;河海不擇細流,故能就其深」當我們懂得接納各種不同的聲音,對自己的學習與成長也會有很大的幫助。不過,同人對網路上出現讓人感到莫明其妙的留言,卻也時常深感困擾。

它們與文章內容沒什麼關係,卻混淆文章訴求的重點,而大部分這種留言多半是匿名者的批評。回應這樣的留言很辛苦,但為了清楚表達自己的想法,過去同人還是會設法回應這些留言。

然而,最近看到同人在 ZDNet 發表的文章,又出現了與文章主題無關的匿名者批評。我突然發現自己不想再浪費青春在那上面,於是表達無法和匿名者討論下去的想法,結果匿名者居然回應了下面這一段話:

你想針對人討論嗎?還是想針對內容討論?如果是人,那就可以免了。既然留下名字,也不見的是本人,那為什麼那麼在乎是誰?

同人不想和匿名者討論就是在乎說話的是誰、是對人不對事嗎?非也,問題並不是我們在意留言者的姓名,而是躲在匿名後面隨便放話,顯露出對他人的不尊重,我們當然不需要浪費時間,與匿名者做沒有意義的爭論。

再和匿名者扯下去,討論的失焦勢必沒完沒了,因此,對他的質疑同人也不必要去加以反駁。因為接下來可能會進行辯論「他沒有不尊重他人」、「尊重他人不需要留下名號」等諸如此類的問題。這些問題跟文章更加無關,所以沒有必要配合他演出失焦及離題的戲碼。

然而,為什麼同人會認為在匿名後面隨便放話,就是不尊重作者呢?這可從匿名留言者、留言內容、及個人成長三方面來看。 閱讀全文 →

分類: CNet/ZDNet, 學習, 寫作, 思考, 溝通, 生活感觸 | 3 則留言

穩定的程式是偶然?

最近同人看到有一則噗浪提到「一個穩定的程式並非必然,而是偶然」在此噗浪的回應中,發送這則噗浪的噗友表達他對程式穩定性的看法。

先問自己一個問題,一個程式有幾個 Bugs?如果是不可數,那~~它的穩定是相對非絕對,所以穩定不是絕對的,也不是必然的。

同人覺得這位噗友的觀點很有趣,於是加入這則噗浪的討論。我問如果最開始的程式都是穩定的,那麼是什麼原因讓後來的程式變得不穩定?對這個問題,一些噗友提出了他們的看法,其中有一位噗友回應「是我的機器弄好的程式,跑到別人機器就不穩定了」,發送此則噗浪的噗友認為還蠻接近實際的情形。

他提到 Bugs 在自己的機器沒產生,在別人那邊可能會產生,問題可能是因為自己的機器有 Bugs,而不是別人的機器,他說假設機器不會出問題是會有副作用的。

那麼為什麼不在應用系統要運作的目標環境下直接開發程式呢?因為,嚴格來說,開發者不可能有完全一致的環境,因此開發者只能假設環境是不會改變。但實際上,在不同的機器上、甚至在相同的機器上,不同的時間可能也會出現難以預料到的變化,結果使得程式變得不穩定。

這位噗友認為,當我們愈信任一個系統,其實可能是一個災難,因此程式的穩定非絕對而是偶然,它是由一連串的偶然所累積而成的。同人發現這個觀點讓人很難反駁,在我過去程式開發的經驗中,並不乏遇到原來運作正常的程式,在不同時空環境出現問題的現象。正如同這位噗友提到的,作業系統與程式語言它們本身也都是程式,很難確保它們不會出問題。

相信很多人都曾遇到過,程式發生失常通常只因為一個令人難以捉摸的小錯誤,因此似乎真的可以說「穩定的程式是偶然的」。不過,如果穩定的程式真的是偶然的,程式的穩定就只能依賴運氣而不是人為努力,事情真的是這樣嗎?其實這位噗友太過強調環境變化的隨機性,卻忽略了適應環境變化,程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的,雖然演化的過程是偶然、但其最後結果卻是必然。換句話說,穩定的程式是偶然下的必然。 閱讀全文 →

分類: 學習, 專案監控, 專案規劃, 專案風險, 思考, 編程技巧, 職場, 設計原則, 開發流程 | 2 則留言