jim yeh on 六月 24th, 2011

要認識系統開發的複雜性,這並不是一件很容易的事。不過,忽略它會讓我們和湊熱鬧的外行人一樣,從他人系統失敗的經驗中只能看得到表相;以為這只是犯了離譜的技術或方法論的錯誤。

Continue reading about 從公共建設的系統失常看系統開發的複雜性

     
jim yeh on 三月 17th, 2010

短期來說,高層管理者所不願承擔的壓力加諸在專業人員身上,他們總是無力反抗而必須默默承受。但長期讓專業第一線的工作人員一直承受壓力,而不懂得適時激勵來增加專業人才的士氣,總有一天將會令專案付出慘痛的代價:損失重要的專業人才。因此,對於專案管理者而言,這是值得關切的問題。

Continue reading about 管理者如何面對專業受責難

     
jim yeh on 十月 26th, 2009

這篇文章是投稿 ZDNet Taiwan 的文章原稿,由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤?〉、〈如何在系統異常前發現錯誤?(下)〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯,內容可能與 ZDNet Taiwan 約略有所不同。 前一陣子有兩個與資訊系統失常有關,而且眾所矚目的新聞事件,也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜,在系統上線之後才發現系統無法正常運作,造成系統使用者的困擾,同時也會讓人對系統可靠度與穩定度失去信心,而增加系統的失敗成本。 雖然平心而論,想要事前預料系統可能發生的問題,並加以預防或因應其實並不容易,因為開發系統,尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前,就能夠發現問題並採取適當的行動來解決它,應該就能減少系統的失敗成本。因此,看到戴爾與台北捷運內湖線的重大系統異常,讓筆者想探討如何在系統失敗前發現錯誤,以避免系統失敗的巨大損失。

Continue reading about 如何在系統失敗前發現錯誤

     
jim yeh on 七月 21st, 2009

是否代表系統開發追求速度與彈性,就必然犧牲文件與流程呢?同人認為這樣看就太過簡化了,系統開發的彈性並不是忽略系統文件與流程,而是只重視有實質效益的一切事物,當然包括文件與流程。

Continue reading about 系統開發的彈性

     

系統分析師該如何思考與學習的方法以展現其專業。然而,許多人對系統分析專業的疑惑出在忽略「結構與非結構的隔閡」,使得系統分析師陷入了過度簡化設計與過度工程化,也就是所謂過度設計的兩難情境。

Continue reading about 結構與非結構的隔閡-從軟體開發專案的四個困難談起

     
jim yeh on 五月 8th, 2009

在台灣,品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外,以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」,讓開發人員認為品質是品質部門的責任,而品質部門則認為提昇品質不是他們的責任,以為最多只能做到知道產品有問題,而不知道如何改善它們,只能退回到開發人員那邊來解決。

Continue reading about 聚餐也談品質流程

     
jim yeh on 二月 6th, 2009

根據筆者軟體專案開發的經驗顯示,團隊成員能力不足或是其心態有問題的情況並不多見,多半是專案經理無法讓團隊發揮實力。所以當專案一再出現相同的錯誤時,專案經理應該先思考是不是自己的領導能力出了問題。

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

     
jim yeh on 一月 16th, 2009

昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結構上的問題。其實那篇文章除了結構問題之外,同人也在該篇文章內容中,發現了一些值得探討的問題,因此想在這篇文章發表我的看法。 以該篇文章內容而言,同人認為值得探討的有兩個地方,一個是程式語言一直再改變的迷思、另一個則是作者建議讀者,儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念,而第二個問題就是嚴重的偏見了,值得讓人進行思辨以建立正確的觀念。

Continue reading about 再談程式設計的迷思

     
jim yeh on 一月 15th, 2009

在寫作的時候,很多人喜歡以條列要點來表達觀點。一般而言,條列要點要比平舖直敍還來得簡明扼要,它顯示了作者的重要論點、並讓讀者可以決定是否要仔細閱讀的依據。然而,文章條列要點要寫得好可不簡單,它需要更多的思考。否則即使文章洋洋灑灑地羅列了許多的要點,卻還是讓讀者不知道文章重點在那裡,呈現出觀點的空洞化。這都是因為寫作缺乏「概括性論點」,條列要點沒有展現作者的思考脈絡所致。 例如同人過去在〈畫龍要點晴〉中,就指出兩篇很有價值的文章,因為缺少了「概括性論點」而使文章失色不少,讓人覺得非常可惜。今天,我在 ZDNet 的名家專欄中,又看到〈必須面對的真相─五大程式設計迷思〉也同樣少了「概括性論點」,讓人覺得該篇文章不知要表達什麼重點。同人從空洞的論點背後,看到作者的思考似乎還沒有完成。

Continue reading about 又見少了概括性論點

     
jim yeh on 一月 13th, 2009

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

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