「好產品不一定能賺到錢」並不是一項迷思。其實它告訴我們一項真理：人想要靠開發出好產品而賺到錢，除了需要有能力把產品做出來之外，還需要其它因素的配合；把各種可能的因素加在一起，我們通常會通稱它叫機運。
最近讀到一篇文章〈不要盲目的 BDD / TDD，我對寫測試的看法〉，看完作者 XDite 反對不論如何都要導入 TDD 的理由，讓同人想提出我對這篇文章的看法。
要認識系統開發的複雜性，這並不是一件很容易的事。不過，忽略它會讓我們和湊熱鬧的外行人一樣，從他人系統失敗的經驗中只能看得到表相；以為這只是犯了離譜的技術或方法論的錯誤。
短期來說，高層管理者所不願承擔的壓力加諸在專業人員身上，他們總是無力反抗而必須默默承受。但長期讓專業第一線的工作人員一直承受壓力，而不懂得適時激勵來增加專業人才的士氣，總有一天將會令專案付出慘痛的代價：損失重要的專業人才。因此，對於專案管理者而言，這是值得關切的問題。
這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤？〉、〈如何在系統異常前發現錯誤？（下）〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。 前一陣子有兩個與資訊系統失常有關，而且眾所矚目的新聞事件，也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜，在系統上線之後才發現系統無法正常運作，造成系統使用者的困擾，同時也會讓人對系統可靠度與穩定度失去信心，而增加系統的失敗成本。 雖然平心而論，想要事前預料系統可能發生的問題，並加以預防或因應其實並不容易，因為開發系統，尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前，就能夠發現問題並採取適當的行動來解決它，應該就能減少系統的失敗成本。因此，看到戴爾與台北捷運內湖線的重大系統異常，讓筆者想探討如何在系統失敗前發現錯誤，以避免系統失敗的巨大損失。
早上在 News 98 聽到陳鳳馨評論吳德榮提前退休的新聞事件，她提到吳德榮說：「人們理盲又濫情，說也沒用」對此，她表示人們理盲又濫情她同意，但吳德榮自己何嘗不是理盲又濫情呢？然而，聽完陳鳳馨的評論反而讓人更困惑，或許同人應該好好思考一下，弄清楚到底是誰理盲又濫情。
解決問題的關鍵就是正視「人不是完美的」事實。同人是工程師出身，我很能體會工人希望早點把事情做完早點走的心態，對擾鄰後果的嚴重性他們可能沒有明顯的感受，而不是故意不去配合。所以以為訂下工作時間的規則以為他們會遵守，其實是太天真了。而那位媽媽的辦法正是對人性弱點的積極管理，不去假設人們一定會照你的方法去做事，而去思考我們的對策。看在同人的眼中，實在是令人激賞呀。
同人看 Kenming Wang 這篇文章覺得怪怪的，倒不是不贊同他對寫好使用案例好處的觀點，而是覺得強迫新手去做我們認為有價值的東西是很危險的。
是否代表系統開發追求速度與彈性，就必然犧牲文件與流程呢？同人認為這樣看就太過簡化了，系統開發的彈性並不是忽略系統文件與流程，而是只重視有實質效益的一切事物，當然包括文件與流程。
世界愈複雜，我們就更需要簡單。簡單讓我們看清楚事物的脈絡，掌握重點，以協助做出選擇，並在適當時機採取行動。然而，簡單其實是困難的，因為要做到簡單，意味著我們必須清楚事物的全貎，行動必須要更有原則。尤其是在複雜多變的環境當中，簡單不能只靠直覺，而是有紀律的思考與行動。 那麼，用有紀律的思考與行動，以做到簡單，我們該怎麼做呢？前一陣子，同人閱讀了《越簡單越有力量》，我覺得這本書的觀念與方法，剛好可以提供我們複雜世界簡單之道的思考方向與指引。
最新迴響