這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤？〉、〈如何在系統異常前發現錯誤？（下）〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。
前一陣子有兩個與資訊系統失常有關，而且眾所矚目的新聞事件，也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜，在系統上線之後才發現系統無法正常運作，造成系統使用者的困擾，同時也會讓人對系統可靠度與穩定度失去信心，而增加系統的失敗成本。
雖然平心而論，想要事前預料系統可能發生的問題，並加以預防或因應其實並不容易，因為開發系統，尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前，就能夠發現問題並採取適當的行動來解決它，應該就能減少系統的失敗成本。因此，看到戴爾與台北捷運內湖線的重大系統異常，讓筆者想探討如何在系統失敗前發現錯誤，以避免系統失敗的巨大損失。 Read the rest of this entry »
本文於 2009/07/22 經 ZDNet Taiwan 部落格文章專區轉載。
在 facebook 看到舜平學長提到「求快求彈性忽略系統文件的後果，找了兩個小時的BUG」讓同人想寫一篇文章來談談系統開發的彈性。
舜平學長說求快求彈性，忽略系統文件重要性的後果就是使用者說沒空寫文件，如果這時我們也沒有將系統重要資訊記錄下來，那麼就算是自己也會因為時間一久而逐漸淡忘這些資訊，結果使得系統的維護變得更加困難。
雖然以上的現象在台灣是開發者經常碰到的問題，但那是否代表系統開發追求速度與彈性，就必然犧牲文件與流程呢？同人認為這樣看就太過簡化了，系統開發的彈性並不是忽略系統文件與流程，而是只重視有實質效益的一切事物，當然包括文件與流程。 Read the rest of this entry »
這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈軟體開發的難處 SA該如何解決？〉、〈為何SA很難落實簡單設計〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。
今(09)年初，應中山大學資管系主任鄭炳強教授的邀請，到他們學校做了一場演講。由於筆者與鄭教授原先並不認識，是透過台科大資管系主任李國光教授聯絡到筆者，因此，鄭教授邀請我在演講前先與他碰面、共進午餐，並且藉這個機會交流彼此在軟體工程方面的心得。
在那次午餐約會中，我們聊到了系統分析專業這個議題。鄭教授表示欣賞筆者寫的〈展現系統分析專業的七種能力〉，還曾在課堂上向他的學生推薦這篇文章…與鄭教授交流互動的過程中，也讓筆者得到不少收穫，回到台北後，一直想找機會分享這些收穫。
由於我一直想找機會回應那篇文章的讀者意見，也就是ZDNet讀者對於那篇文章的前半段〈怎樣才是專業的 SA？〉的一些留言，筆者發現這次行程的收穫，正好可以讓這篇文章有一個很好的起點。 Read the rest of this entry »
本周一同人在新公司 on board，公司事先訂好餐廳為我舉行迎新聚餐。在這場聚餐當中的一道菜，讓大家開啟談論品質流程的話題。 Read the rest of this entry »
本篇文章是投稿至 ZDNet 的文章，已由 ZDNet 以〈領導力 決定專案成敗〉與〈團隊關係 左右專案發展〉兩篇文章刊出。文章原稿未經 ZDNet 編輯，加上同人在文章刊出後修改原稿，其內容與刊登的文章有些差異。
繼「新官上任三把火」之後，馬政府團隊又在國慶大典發生意外狀況。位置安排出問題、加上安檢嚴格，引發部分參加大典的民眾不滿。例如資深藝人和僑胞發生搶位置狀況，還有一對位置被佔走的僑胞夫婦，居然還被工作人員趕出場外，真是又委屈又生氣。
看到這則新聞，筆者關心的並不是主辦單位碰到這些意外狀況該怎麼辦，而是好奇為什麼座位安排的問題會重覆發生？其實像座位安排並不是什麼困難的問題，不需要動用複雜的技術，只要用簡單的 Excel 試算表就不會有太大的問題。
如此看來，座位重覆的問題不太可能是技術的問題，筆者看到相同的錯誤一再發生，我會懷疑問題不是出在技術上，而是因為管理的關係，使得團隊一再出現相同樣的行為模式造成錯誤。
可能是因為領導者的領導能力不足，使得團隊成員的能力處處受限而無法施展。如果真是如此，那麼與其討論技術細節，還不如討論該如何領導讓團隊充分發揮能力。因為，就算今天我們知道如何可以解決座位安排出現錯誤的問題，領導能力不足，明天團隊還是很有可能在別的地方出現錯誤，造成其它的意外狀況發生。
筆者相信不管是那一種專案，管理上的領導能力不足都會造成相同的錯誤一再發生。就像筆者在軟體專案中所觀察到的情況一樣，專案經理的領導能力不足，使得團隊成員把精力浪費在沒有意義的事情上，以致於對專案目標的達成並無太大的助益。
當然我們並不能否認，團隊成員的能力出現了問題，或是他們不夠盡力，也可能會出現同樣的現象。不過，根據筆者多年軟體專案開發的經驗顯示，團隊成員能力不足或是其心態有問題的情況並不多見，多半是專案經理無法讓團隊發揮實力。所以當專案一再出現相同的錯誤時，專案經理應該先思考是不是自己的領導能力出了問題。 Read the rest of this entry »
昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結構上的問題。其實那篇文章除了結構問題之外，同人也在該篇文章內容中，發現了一些值得探討的問題，因此想在這篇文章發表我的看法。
以該篇文章內容而言，同人認為值得探討的有兩個地方，一個是程式語言一直再改變的迷思、另一個則是作者建議讀者，儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念，而第二個問題就是嚴重的偏見了，值得讓人進行思辨以建立正確的觀念。 Read the rest of this entry »
在寫作的時候，很多人喜歡以條列要點來表達觀點。一般而言，條列要點要比平舖直敍還來得簡明扼要，它顯示了作者的重要論點、並讓讀者可以決定是否要仔細閱讀的依據。然而，文章條列要點要寫得好可不簡單，它需要更多的思考。否則即使文章洋洋灑灑地羅列了許多的要點，卻還是讓讀者不知道文章重點在那裡，呈現出觀點的空洞化。這都是因為寫作缺乏「概括性論點」，條列要點沒有展現作者的思考脈絡所致。
例如同人過去在〈畫龍要點晴〉中，就指出兩篇很有價值的文章，因為缺少了「概括性論點」而使文章失色不少，讓人覺得非常可惜。今天，我在 ZDNet 的名家專欄中，又看到〈必須面對的真相─五大程式設計迷思〉也同樣少了「概括性論點」，讓人覺得該篇文章不知要表達什麼重點。同人從空洞的論點背後，看到作者的思考似乎還沒有完成。 Read the rest of this entry »
在網路上發章文章，同人很重視讀者的留言，因為讀者的回應，可幫助我們改進文章的內容。有道是「泰山不讓土壤，故能成其大；河海不擇細流，故能就其深」當我們懂得接納各種不同的聲音，對自己的學習與成長也會有很大的幫助。不過，同人對網路上出現讓人感到莫明其妙的留言，卻也時常深感困擾。
它們與文章內容沒什麼關係，卻混淆文章訴求的重點，而大部分這種留言多半是匿名者的批評。回應這樣的留言很辛苦，但為了清楚表達自己的想法，過去同人還是會設法回應這些留言。
然而，最近看到同人在 ZDNet 發表的文章，又出現了與文章主題無關的匿名者批評。我突然發現自己不想再浪費青春在那上面，於是表達無法和匿名者討論下去的想法，結果匿名者居然回應了下面這一段話：
你想針對人討論嗎？還是想針對內容討論？如果是人，那就可以免了。既然留下名字，也不見的是本人，那為什麼那麼在乎是誰？
同人不想和匿名者討論就是在乎說話的是誰、是對人不對事嗎？非也，問題並不是我們在意留言者的姓名，而是躲在匿名後面隨便放話，顯露出對他人的不尊重，我們當然不需要浪費時間，與匿名者做沒有意義的爭論。
再和匿名者扯下去，討論的失焦勢必沒完沒了，因此，對他的質疑同人也不必要去加以反駁。因為接下來可能會進行辯論「他沒有不尊重他人」、「尊重他人不需要留下名號」等諸如此類的問題。這些問題跟文章更加無關，所以沒有必要配合他演出失焦及離題的戲碼。
然而，為什麼同人會認為在匿名後面隨便放話，就是不尊重作者呢？這可從匿名留言者、留言內容、及個人成長三方面來看。 Read the rest of this entry »
本篇文章是投稿 ZDNet 的文章原稿，並以〈專案不確定導致焦慮與迷失〉與〈專案不確定性導致焦慮與迷失(下)〉兩篇文章刊出。原稿未經 ZDNet 編輯，其內容可能會與刊登的文章內容有約略的不同。
專案經理常會面臨天人交戰的情境。當專案「計劃總是趕不上變化，變化總是比不上老闆的一句話」之時，許多專案經理總是會擔心專案無法如期完成或害怕資源不足，而拒絕或延後專案變更的要求。但這樣的行為，卻往往造成工作成果無法符合專案實際需要的結構性因素，而使得專案的失敗機會大為增加。這對於具備智慧及膽識的專案經理而言，當然並不會樂見專案發生這樣的事情。
筆者前一陣子看到喲哪桑在〈換了屁股，我也換了腦袋〉的分享，提到他在時間緊迫的情形下，接受了專案的功能變更要求。那個變更要求原來是由他所提出，當時前任專案經理以時程緊迫為由而答應延後處理，而一直到他接任專案經理仍然還留在原處。但他認為他不能任由「行為造成結構」的情形發生，於是決定不要再讓這個專案變更要求再次拖延下去，並在當下對專案進行變更。
筆者認為喲哪桑的作為令人激賞，並且覺得那篇文章值得推薦。其原因並不是因為他針對專案變更做了什麼樣的決定，而是欣賞他在決策過程中，展現出面對自己的勇氣與解決問題的思考。不過，卻有其他讀者對那篇文章抱持相反的意見。
某位網友對喲哪桑的分享，批評他是靠感情衝動來管理專案，甚至用了「發瘋了你」、「不適任該離開的時候」等情緒性的字眼來指責喲哪桑的不是。他指出喲哪桑的文章所傳達的意念，實在有不可思議的謬誤，並且擔心那篇文章會透過 ZDNet 的報導，將不正確的知識與觀念誤導一般社會大眾。
然而，他對這篇文章的批評卻使人感到困惑，那位網友認為喲哪桑文章傳達的意念有不可思議的謬誤，但看在專業人士眼裡，這樣的觀點又何嘗不是相當嚴重的偏頗呢？筆者認為他的觀點傳達的意念本質上是一種面對不確定性的焦慮感，進而對改變的抗拒而產生無知的迷惘。
身為專案經理固然不應該因為個人一時的感情因素而使專案陷入危險之中，但在對專案缺乏可供客觀評論資訊的情況下，只憑專案經理接受專案變更的決定，就加以批判其決策感情衝動是否真的恰當？專案管理並不是神學或是玄學，而是屬於管理科學的範疇。因此，如果有人要批評某個專案經理是用感情衝動來管理專案，必須提出具體的事實根據，否則那只是無憑無據的推論而已，而這樣的推論多半只是源自於自我的偏見與扭曲。 Read the rest of this entry »
本篇文章是投稿 ZDNet 的文章原稿，並以〈新官上任三把火〉與〈新官上任三把火(下): 建立團隊的創新文化〉兩篇文章刊出。原稿未經 ZDNet 編輯，其內容可能會與刊登的文章內容有約略的不同。
新政府能否為台灣開創新局還有待觀察。但從馬蕭辦公室與府院籌辦五二○就職典禮，卻出現許多的問題，加上當天的慶典南北奔波，被稱為有史來最複雜的就職典禮看來；新政府團隊似乎想要在就職典禮的活動上，改變舊制以發揮新創意，營造出耳目一新的感覺。但實際上卻反而把問題複雜化，造成一團混亂。這讓筆者想到在軟體開發過程中，也經常出現同樣的情況。
許多主導專案改變的領導者總是新官上任三把火，認為專案應該要進行改變以展現出自己的決心與魄力，因此要求團隊改變開發流程。然而，專案時間與資源的限制多半很難讓團隊有足夠的時間來調適或熟悉改變後的開發流程，結果總是令專案團隊倍感艱辛。
改革的困難正是考驗著領導者的領導能力，他更需要懂得如何讓團隊發揮創意與執行力來實現改革的目標。領導者應該如何領導團隊來進行成功的改革呢？筆者認為從領導者的價值觀、流程方法的改變、以及團隊的創新文化這三方面來看，我們可以從中體會到專案成功改變的箇中三昧，以助於掌握改革重點，有效地組織資源來幫助團隊實現改革目標。 Read the rest of this entry »
