這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤？〉、〈如何在系統異常前發現錯誤？（下）〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。 前一陣子有兩個與資訊系統失常有關，而且眾所矚目的新聞事件，也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜，在系統上線之後才發現系統無法正常運作，造成系統使用者的困擾，同時也會讓人對系統可靠度與穩定度失去信心，而增加系統的失敗成本。 雖然平心而論，想要事前預料系統可能發生的問題，並加以預防或因應其實並不容易，因為開發系統，尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前，就能夠發現問題並採取適當的行動來解決它，應該就能減少系統的失敗成本。因此，看到戴爾與台北捷運內湖線的重大系統異常，讓筆者想探討如何在系統失敗前發現錯誤，以避免系統失敗的巨大損失。
早上在 News 98 聽到陳鳳馨評論吳德榮提前退休的新聞事件，她提到吳德榮說：「人們理盲又濫情，說也沒用」對此，她表示人們理盲又濫情她同意，但吳德榮自己何嘗不是理盲又濫情呢？然而，聽完陳鳳馨的評論反而讓人更困惑，或許同人應該好好思考一下，弄清楚到底是誰理盲又濫情。
朋友的分享讓同人看到，她的主管用一些不大精確的語言來讓她感覺問題不大。比如說用「c++、vb 都只是工具而已，不管你用那一種工具來開發系統，其實都不會有太大的差異，所以我們大可不用擔心」的說法，正是用不精確的語言來表達不當的概念，這其實是相當要不得的簡化。
系統分析師該如何思考與學習的方法以展現其專業。然而，許多人對系統分析專業的疑惑出在忽略「結構與非結構的隔閡」，使得系統分析師陷入了過度簡化設計與過度工程化，也就是所謂過度設計的兩難情境。
根據筆者軟體專案開發的經驗顯示，團隊成員能力不足或是其心態有問題的情況並不多見，多半是專案經理無法讓團隊發揮實力。所以當專案一再出現相同的錯誤時，專案經理應該先思考是不是自己的領導能力出了問題。
最近某位開發者和同人討論需求規格的問題，但他的反應卻讓人感到困惑，不知是他的理解能力有問題，還是面對問題太過情緒化？以下是我們對話的內容。 開發者 D 君問同人：「規格好像沒有提到欄位空白該如何處理？」 同人回答：「沒特別說明就是代表將該欄位填入空白。」 D 君說：「為什麼不是未指定欄位內容呢？」 同人說：「如果是那樣，該欄位不應該在交易訊息中出現；但如果該欄位的內容是空白，那就應該不指定訊息欄位的值。」 D 君說：「不過，從交易訊息的定義來看，那個欄位是必要欄位，不可能不出現。」 同人說：「所以那個欄位是必要的，訊息中沒有指定值就代表欄位要填入空白。」 D 君說：「那規格應該交待這個細節？」 同人說：「不需要，規格文件不寫語法而只會記載語意，因為語法是屬於 common sense，沒必要詳盡記錄在規格文件中。不然，如果連 common sense 都要寫在文件上的話，那是否意味程式設計者也不需要懂程式語言了，反正文件上都會寫。」 D 君說：「我知道了，你的意思是說我沒有 common sense！」 同人說：「如果你覺得我那裡說你沒 common sense，請明說我可以向你道歉，否則你這種情緒化的言論，只會讓人感到不舒服！」 D 君：… 同人將這件事寫在噗浪上，有噗友認為這類的開發者能力不行，沒什麼產值卻會製造問題。不過，在此事我所看到的問題倒不是開發者能力，而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通，這才是我認為最可怕的事情。
最近正在閱讀《領導的黃金法則》這本書，在第 2 章〈自己才是最難領導的人〉中，同人讀到「領導是信任關係，而非權力關係」這句話。從過去在職場的工作經驗來看，我認為這句話還真是至理名言。 領導他人是發揮我們的影響力，讓別人去做我們希望他去做的事情。相信很多人會以為自己無法有效領導他人是因為權力太小與位階不夠，無法讓人聽從我們的指揮。但本書的作者麥斯威爾卻認為，領導最大的挑戰就是領導自己。 麥斯威爾認為無論領導者帶領什麼人、或成就什麼事，領導自己一直都是領導者遇到最大挑戰。他指出歷史上功業彪炳的領導者，總以為他們是天之矯子；但如果我們認真檢視他們的生命，不難發現他們自己總需要經過一番掙扎。這就是「自己才是最難領導的人」的原因所在。 麥斯威爾分享他對領導自己的親身體會，他認為領導者應該力行學習服從、培養自律精神、磨鍊堅忍精神、追求負責精神等行為來領導自己。特別是在追求負責精神方面，他指出「領導是信任關係，而非權力關係」，因此領導者必須比別人更早自我「校正」。 儘管絕不自我膨脹是艱難的課題，但無論如何，不管領導者位階多高、掌握多大權力都必須力求做得對。領導者除了為自己負責之外，更得為追隨受自己領導的人負責，這樣的領導才值得受到他人的信任。 看了麥斯威爾上面的觀點，同人想到過去看到那些運用位階或權威的領導者。表面上看起來好像他們是威風八面，但其所表現出來的行為卻是領導無方。
從事軟體開發的工作中，同人也常觀察到一些開發者不懂藏拙的智慧，意欲表現自己很有能力，但卻總是被人看到他們虛有其表的黔驢之技。我們當然很希望這樣的人，不要出現在工作經驗當中。但很不幸地，世事總是難以如我們的預期，如果不幸在工作碰到這樣的人，我們應該如何自處呢？
新政府團隊似乎想要在就職典禮的活動上，改變舊制以發揮新創意，營造出耳目一新的感覺。但實際上卻反而把問題複雜化，造成一團混亂。這讓筆者想到在軟體開發過程中，也經常出現同樣的情況。改革的困難正是考驗著領導者的領導能力，他應該如何領導團隊來進行成功的改革呢？
在現實世界中，通常很難找到不僅懂得軟體開發的技能，又同時具備問題領域知識的人才。而且軟體開發專案本身存在時程與成本等限制，多半不允許系統分析師花太多的時間與成本學習問題領域知識。因此，要期待系統分析師學習問題領域知識是不切實際且又不符合經濟效益的做法。 系統分析師要如何展現出系統分析的專業，才能整合問題領域與解決方案領域的知識，有效地提出具體可行的問題解決方案？
最新迴響