這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤？〉、〈如何在系統異常前發現錯誤？（下）〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。
前一陣子有兩個與資訊系統失常有關，而且眾所矚目的新聞事件，也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜，在系統上線之後才發現系統無法正常運作，造成系統使用者的困擾，同時也會讓人對系統可靠度與穩定度失去信心，而增加系統的失敗成本。
雖然平心而論，想要事前預料系統可能發生的問題，並加以預防或因應其實並不容易，因為開發系統，尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前，就能夠發現問題並採取適當的行動來解決它，應該就能減少系統的失敗成本。因此，看到戴爾與台北捷運內湖線的重大系統異常，讓筆者想探討如何在系統失敗前發現錯誤，以避免系統失敗的巨大損失。 Read the rest of this entry »
上個禮拜在噗浪河道上看到馬總統抱怨「好人沒好報」的新聞，提到馬以南爆料說馬英九在寫給她的 email 提到「做了好多好多事，卻還要被罵！」的心路歷程，最後一句話是「哼！好人沒好報」，她看了以後回信給馬英九「放心啦，好人一定有好報，只是時候未到」。
同人看到這則新聞的第一個反應是，總統在救災過程中受到批評，心裡面會產生一些情緒是人之常情。因此透過 email 中將這些情緒發洩出來，跟家人訴訴苦以免情緒積壓而損害身心健康，我認為是很自然的一件事。只不過，馬大姐把這些用來宣洩情緒的對話，在公開場合中公開，似乎只會為她的弟弟帶來麻煩，顯然她又失言了！
不過，除了馬以南的失言之外，同人認為這則新聞更重要的意義是，讓我們看到領導者應該如何面對批評。在現實上，領導者所碰到的難處是，不管領導者碰到問題怎麼做，他都很難做到沒有人批評。因此想要成為優秀的領導者，其實無須太在意外界的批評，而是應該將這些批評轉化成更積極正向的領導作為。
就像在《領導的黃金法則》中，作者約翰‧麥斯威爾提到「當你後面被踢一腳，你知道你已超越在前」。 Read the rest of this entry »
台北捷運木柵內湖線又發生系統異常。同人昨天晚上搭捷運，我一向習慣坐第一節車箱。列車才自中山國中站離站沒多久，就看到前面不遠處有一台列車停在那裡，隨車人員連忙打開控制箱將列車停止。等前面列車駛離之後，才將列車停靠至松山機場站，並請大家下車。然後，在廣播中播放因為系統異常而導致全線停駛的訊息，並且請大家改搭其它交通工具。
到了候車大廳，站務人員表示請趕時間的乘客可以直接出站。同人看到排隊處理悠遊卡出站手續的人實在太多，於是同人聽從站務人員的建議直接出站，而沒有處理悠遊卡的出站手續。但這樣一來，不能用悠遊卡坐公車，身上又沒零錢，只能期望捷運站的免費接駁公車。但沒想到花了一個小時等捷運接駁車，卻都還坐不到內湖線的接駁公車，發現捷運公司的免費接駁車的調度，還真是離譜。 Read the rest of this entry »
Kenming Wang 在〈寫好使用案例 (Use Case) 有什麼好處？〉中提到寫好使用案例的好處。文章提到有位其中一位較為資深的程式開發人員在他在工研院授課時表示感覺不到寫好使用案例有什麼好處。這問題讓他思考許久後回答，他認為寫好使用案例最直接的關鍵是，影響整個專案開發流程的節奏。
這篇文章分享他對寫好使用案例對專案好處的看法，他總結使用案例的好處是族繁不及備載。並提到越大規模的專案，更能感受到開發節奏的順暢度。再加上 “漸進循環 (incremental and iteration)” 的開發模式，會越形容易謀和在系統開發期間，人與事的種種。
不過，Kenming Wang 在文章最後提到以上的論述不能說服那位程式開發人員，因為程式設計人員多半以局部或個別的角度來看系統開發，所以使用案例寫得好不好，對他們沒差。只有像專案經理或軟體架構師以專案整個全局來看時，才會有明顯的感受。
但他認為不需要去說服那位程式開發人員，並引述 Martin Fowler 在《UML Distilled》一書中曾經說過的：「你只能強迫新手們這麼做。過了幾年後，他們會突然恍然大悟，然後腦袋彷彿重生！」這句話來說明他對這位程式開發人員意見的看法。
同人看 Kenming Wang 這篇文章覺得怪怪的，倒不是不贊同他對寫好使用案例好處的觀點，而是覺得強迫新手去做我們認為有價值的東西是很危險的。 Read the rest of this entry »
本篇文章是投稿至 ZDNet 的文章，已由 ZDNet 以〈領導力 決定專案成敗〉與〈團隊關係 左右專案發展〉兩篇文章刊出。文章原稿未經 ZDNet 編輯，加上同人在文章刊出後修改原稿，其內容與刊登的文章有些差異。
繼「新官上任三把火」之後，馬政府團隊又在國慶大典發生意外狀況。位置安排出問題、加上安檢嚴格，引發部分參加大典的民眾不滿。例如資深藝人和僑胞發生搶位置狀況，還有一對位置被佔走的僑胞夫婦，居然還被工作人員趕出場外，真是又委屈又生氣。
看到這則新聞，筆者關心的並不是主辦單位碰到這些意外狀況該怎麼辦，而是好奇為什麼座位安排的問題會重覆發生？其實像座位安排並不是什麼困難的問題，不需要動用複雜的技術，只要用簡單的 Excel 試算表就不會有太大的問題。
如此看來，座位重覆的問題不太可能是技術的問題，筆者看到相同的錯誤一再發生，我會懷疑問題不是出在技術上，而是因為管理的關係，使得團隊一再出現相同樣的行為模式造成錯誤。
可能是因為領導者的領導能力不足，使得團隊成員的能力處處受限而無法施展。如果真是如此，那麼與其討論技術細節，還不如討論該如何領導讓團隊充分發揮能力。因為，就算今天我們知道如何可以解決座位安排出現錯誤的問題，領導能力不足，明天團隊還是很有可能在別的地方出現錯誤，造成其它的意外狀況發生。
筆者相信不管是那一種專案，管理上的領導能力不足都會造成相同的錯誤一再發生。就像筆者在軟體專案中所觀察到的情況一樣，專案經理的領導能力不足，使得團隊成員把精力浪費在沒有意義的事情上，以致於對專案目標的達成並無太大的助益。
當然我們並不能否認，團隊成員的能力出現了問題，或是他們不夠盡力，也可能會出現同樣的現象。不過，根據筆者多年軟體專案開發的經驗顯示，團隊成員能力不足或是其心態有問題的情況並不多見，多半是專案經理無法讓團隊發揮實力。所以當專案一再出現相同的錯誤時，專案經理應該先思考是不是自己的領導能力出了問題。 Read the rest of this entry »
本篇文章是投稿 ZDNet 文章〈親愛的 User，為什麼我不懂你？〉的原稿，並分為上下兩篇刊登。原稿未經 ZDNet 編輯，其內容可能會與刊登的內容有約略的不同。
很多人都知道溝通對專案的重要性，透過溝通，開發者可以瞭解使用者的需求，並據以實現。然而實際上，專案的溝通卻常會因為種種原因而出現問題，除了無法實現使用者需求之外，還會造成使用者的抱怨以及不愉快的使用經驗。
無論建築或是軟體開發，溝通不良都會造成專案的失敗。如同 ZDNet 副總編鍾翠玲所觀察到的現象，建築師無法了解使用者的需求就相當於軟體系統架構師或專案經理不了解使用者的作業流程或習慣，結果就是建造出不合用的建築或軟體系統。
鍾翠玲從災後學校重建的實例中看到建築師與校方的溝通上出了問題，她認為這是因為校方沒有積極地參與設計的緣故。我們很難知道這是否是實情，但如果在軟體專案碰到同樣的現象時，筆者不一定會認為是因為使用者缺乏積極參與。從筆者的專案經驗顯示，即使使用者積極參與設計，開發者還是會因為與使用者之間存在觀念溝通上的藩離，而聽不見使用者的心聲。 Read the rest of this entry »
面對時代的快速變遷，企業如何能在嚴峻的企業考驗下，擁有企業競爭優勢，創造企業的價值並達成預定的目標？相信許多人都會同意，在專業分工日益精細與複雜的今日，要成功地達到企業目標，專業經理人的能力是非常重要的。
專業經理人必須具備什麼能力呢？同人認為大致可歸納為兩方面來看，專業經理人必須創造企業的績效。如果企業沒有績效可言，企業就很難在競爭激烈的環境下存續，更不用說達到企業目標了。另一方面，專案經理人也必須經營團隊。因為在專業分工日益精細的今日，企業成功已非單打獨鬥就可以竟其功，而是必需發揮團隊合作的精神，才能得以創造最大的組織績效。
要創造績效，專業經理人必須發揮他的影響力，領導員工做正確的事（do right thing）來追求企業效能（effectiveness），這就是「天行健，君子以自強不息」的處事之道。同時，要經營團隊，專業經理人則必須管理團隊，讓員工能夠把事情做好（do thing right），以追求團隊效率（efficiency），這便是「地勢坤，君子以厚德載物」的待人之道。
而從易經的哲學思維來看，待人與處事的基本精神在於易簡之理，正如同《繫辭傳》中的所說的： Read the rest of this entry »
對於一個以專案開發為主的組織而言，組織的研發能力是非常重要的核心能耐。一個有研發能力的組織可以讓組織在多變而複雜的環境中，快速應變與創新，如此才有所謂的競爭優勢可言。
照理來說，組織研發能力應該可以藉由組織的專案經驗累積而慢慢培養，因此應該讓研發人員積極參與各項專案，以讓他們從實戰經驗中提昇研發能力。但實際上，當研發人員忙碌於各專案時，組織的凝聚力卻在無形之中被削弱了，長久下來卻對組織研發能力卻有著不良的影響。
近兩年來，同人觀察到身處所服務的部門便有這樣的問題。 Read the rest of this entry »
在經歷了在兩性戰國論壇與黑米討論串之中的幾場辯論，同人發現要在對話中清楚地陳述自己的看法，澄清彼此在觀念上的差異，其實並不是一件容易的事。過程中，持與我們不同論點的人往往很難暫緩自己的想法，去聆聽我們真正想要表達的真正重點，即使我們不斷地澄清自己的想法，卻常還是會發現個人的想法還是會被曲解。
有時候，對同一件事情，人們很習慣會加入個人的情感及主觀的信念而推論出自己對事物的看法，同時對他人的不同聲音，會從他的話語中片面地抽取我們想要的意義，而斷章取義的結果往往是造成雙方在觀念上的無法溝通。
同人所經歷的那幾場辯論正是一直上演著這樣的情境。在許多人的眼中看來，表面上是我藉題發揮，抓住對方論點邏輯上的缺陷不放；但在另一方面，我所看到的卻是這些人在討論事情的時候，沒有認清楚我真正想要談論的重點。
他們以為我正是藉由打擊一方的論點，來突顯對方一定是錯的而堅持我自己的主張，但他們對我個人的批評卻著實令人感到疑惑：他們似乎看不到我的訴求，認定他們所想的就是真理，我發現大家是如此堅信自己的觀點，以致無法深入地思考對方所提出的看法。
在兩性戰國論壇中，網友亞言提到了真理愈辯愈明，她認同我說的「針對誤會解釋清楚就沒問題」的觀點。看了她的評論，透過自我省思，同人回顧與大家爭論問題的過程中發現，我原來希望透過對話而促成共同思考的動機，到最後卻演變成各自捍衛個人立場的辯論大會，顯見在這方面，我要學的還很多。 Read the rest of this entry »
莫齋在兩性戰國論壇中，對〈如何滿足加薪的願望〉的討論發表看法，她提到：
從另一個角度看，商業利益都是有獲得有付出，雙方對彼此獲得和付出的期望不同時，衝突和不滿就開始累積了。
剛好同人的碩士論文的研究主題剛好就是探討組織團隊衝突的議題，探討軟體專案之組織信任、參與影響力、衝突管理與群體績效之關連性。當我把我的論文送給我部門的事業群副總時，他告訴我，我的研究主題很有意義，因為組織會發生的事就是這些；而我之所以訂立這個研究主題，主要也是因為工作上的體會。在工作過程中，衝突難免會發生，包括我自己也不例外，我自己就直接和我所參與專案的負責人有正面且嚴重的衝突。從這一方面來看，我的畢業論文，也可視做我的現身說法。
從我的工作實際體會與研究結果發現，衝突很難避免，而且衝突很少也不代表團隊績效有助益，有時候組織呈現一言堂的現象，會降低團隊的決策品質，這對團隊績效的影響往往是負面的。衝突管理的重點是團隊間彼此信任的存在，以及成員積極參與及影響決策的能力，因為這些可以增進衝突解決的滿意度，同時也產生對團隊績效有直接的關聯。
此外，值得一提的是，從我的研究中發現，團隊的成立時間愈長與成員的積極參與有正向的相關，但成員的團隊年資卻對成員的參與影響力有負向的相關。 由此研究結果研判，團隊合理的運作制度應該才是使團隊成員積極參與的重要關鍵，而讓成員在團隊中工作太久缺乏新的剌激，反而會使他缺乏積極參與的動力。
我一直相信，每個人對於組織有不同的目標及期待，會產生意見歧異是必然的，然而，會發生人際衝突最大的問題並不在於此，而是在於我們不允許存在與我們不相容的看法，基於此種信念，會開始採取阻擾對方的舉動與興起不滿的歧異，這才是衝突令人難以處理的地方。所以，要開放我們的胸襟才有可能真正地化解歧異，尤其是在異質性的組織或團隊，能否互助合作以發揮綜效或是惡性競爭以交相攻擊，就在我們一念之間了。 Read the rest of this entry »
