所謂的抽象化思維就是從不同觀點的互動中，經由演化而創造出全新的不同觀點；它既不是業務觀點也不是技術觀點，而是彼此交織之後產生有用的解決問題觀點。其實把抽象化當技術的繆誤，不單單只出現執著於業務觀點的情形，執著於技術觀點也會犯了相同的錯誤；以為堅守特定觀點就可以解決問題，然而這樣的繆誤讓我們缺乏解決問題所需要的彈性呀。
最近太陽進入同人命宮，也該繼續寫文章在網誌上發表了，不過同人最近碰到了一件事，讓我停下來正在寫作的文章，先來寫一篇分析這個事件時盤的文章。這個時盤是某個人在網路上在人後評斷是非的時盤。
在同人簡要地回覆學長的留言之時，其實在我心中對於「做好產品」有一些還沒表達清楚的觀念。想等到有空的時候再補充我的想法，雖然後來看到學長說他不再寫文章與人爭辯了，但這些觀念其實不是為了爭辯而產生的，而是為了對話以分享意義，所以我還是決定把它們寫出來。
「好產品不一定能賺到錢」並不是一項迷思。其實它告訴我們一項真理：人想要靠開發出好產品而賺到錢，除了需要有能力把產品做出來之外，還需要其它因素的配合；把各種可能的因素加在一起，我們通常會通稱它叫機運。
在今年過農曆年前，看到以前閱讀《溫伯格的軟體管理學（第二卷）：第一級評量》所做的筆記，引發同人想要寫一篇文章探討軟體開發團隊的官僚特性。但由於工作轉換及其它寫作計劃的原因，直到現在才有時間分享我對軟體開發團隊的官僚特性之心得。
最近讀到一篇文章〈不要盲目的 BDD / TDD，我對寫測試的看法〉，看完作者 XDite 反對不論如何都要導入 TDD 的理由，讓同人想提出我對這篇文章的看法。
要認識系統開發的複雜性，這並不是一件很容易的事。不過，忽略它會讓我們和湊熱鬧的外行人一樣，從他人系統失敗的經驗中只能看得到表相；以為這只是犯了離譜的技術或方法論的錯誤。
在公司高層這種態度和形成的公司文化氛圍之下，公司產品最後會變成「把做好的東西丟到牆的那一邊去」就不足為奇了。再加上以西方優越感產生文化的價值批判，在這種情況之下，QA 對產品品質的提昇有多少著力點呢？同事丙的離開做出了最好的回答。
在軟體開發的過程中，有沒有方法可以避免我們浪費心力在無謂的堅持上，然後用比較簡單而又有效率的方式來完成我們的工作呢？經過與同事上面的對話，同人想到運用到我在分享會中所提到的觀念與實務，可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來，也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。
最新迴響