摘要:《軟體工程與 VSTS》延伸閱讀：戴明的新經濟觀（書摘）
在翻譯《軟體工程與 Microsoft Visual Studio Team System》這本書的過程當中，除了加深我對軟體工程與 Visual Studio Team System 的瞭解之外，另一個讓我收獲很多的，是每一章最後附的參考文獻。作者 Sam Guckenheimer 在軟體開發方面的經驗非常豐富，而從他引用的相關書籍和文獻來看，可以發現他不僅是軟體工程與 VSTS 的專家，對其他知識領域也涉獵廣博，包括心理學、科技管理、研究製造、經濟學......等等。透過這些參考文獻，也讓我發現了一些之前未曾注意到的好 書。舉例來說，書中對於一些專案管理和變異（variation）的觀念，主要是源自《戴明的新經濟觀》書中的理論。我也挺喜歡這本書，這裡就做個簡短的 書摘供大家參考（您也可以參考網路上的另一篇書摘）。
書名：戴明的新經濟觀
作者：W. Edwards Deming
譯者：戴久永
出版：天下文化
---------------< 書摘開始 >-----------------------------------------------
美國人的問題在於教育以及如何發展重視學習的文化。(p.8)
注：台灣也是啊！Orz
顧客不會發明
大家都說要符合顧客的期望。事實上，顧客的期望乃是由你與你的競爭對手所塑造，顧客學得很快。(p.9)
注：例如，是顧客要求軟體廠商發展即時通訊軟體，還是廠商先開發出來，人們覺得好用才開始普及？
高階管理者該為品質負責
公司產品的品質，不可能高於高階管理者所設定的品質水準。(p.20)
注： 如果主事者與開發人員在軟體開發方面的理念不一致，或者不了解開發人員為何要這樣做，以及那樣做對品質有何影響的時候，開發人員恐怕很難得到上頭的認同與 許可，去做他們認為該做的事。因此，主事者必須對軟體開發的本質、概念、與實務作法有一定程度的了解，才能將開發的方向導正，並確保軟體的品質。所以，結 論就是.....不只是開發團隊成員，各位現任（或未來將升任）的軟體公司主管、CIO、專案經理們， 請務必也買一本《軟體工程與 Microsoft Visual Studio Team System》回去看呀! ^_^
廢除考績制度
將員工排等級，正顯示了管理者的失職。在考績制度下，所有人的目標都是討好上司。結果將會導致士氣低落，品質受損。因此把員工評等分級，分門別類，對於改善工作並沒有任何幫助。
錯誤的企管教育－數字化目標與結果導向管理
數字化目標會導致扭曲和作假，尤其是當系統根本無力達到目標的時候，更有此可能。每個人都會設法達成被分配到的配額（目標），但卻並不對由此所導致的損失負責。(p.37)
注： 《軟體工程與 Microsoft Visual Studio Team System》書中也有舉出一些類似的例子，像是：程式設計師故意埋下很多 bugs，並由自己找出這些 bugs，以達到 bug 發現率的數字化目標。報表上的數字看起來是達到目標了，可是實際的產出和績效卻一點也沒有長進。
管理者其實應該專注於流程的改善，而不是設定數字化目標。(p.38)
採用成果導向的管理，帶來的困擾是更多而非更少。......以成果為導向的管理針對結果採取行動，也就是認定結果來自特殊原因。其實重要的是針對造成該結果的原因－－也就是系統－－下功夫。(p.39)
每一位管理者都認為自己是全力以赴。他們確實如此，而這也正是問題所在。他們的「最佳」，是立基於現行的管理系統之下，而這個管理系統，正如我們前面所指出，會引起難以估算的巨大損失。如果沒有外來知識的協助，管理者的努力只會把我們目前所陷入的坑愈挖愈深。(p.43)
注：Do the right thing. 往錯的方向努力，只會愈陷愈深，導致更大的災難。然而系統本身無法察覺自己的問題，需藉由外來知識（即作者專章介紹的淵博知識體系）的協助才能導正方向。
建立系統的觀念
如果說金字塔型的組織圖真的傳遞了什麼訊息給員工的話，那就是：每個人首要的工作就是取悅上司（以便得到好的考績）。......金字塔的組織圖確實具有破壞系統的作用，因為它促使組織的部門各自為政，形成個別的利潤中心，以致破壞了系統。(p.70)
讓人人了解自己的貢獻
「工作說明」（job description）不是描述動作、做這個、做那個、這樣做、那樣做，還應該增加說明工作的用處，以及工作對整個系統目標的貢獻。(p.73)
內在動機 v.s. 外在動機
將 個人、小組、部門、地區排等級，並發獎金給排名在前者，將會打擊所有相關人員的士氣，包括受獎者在內。......無論是小孩或大人，如果必須一直關心自 己的表現，以爭取好成績和獎狀，就不能享受學習的樂趣。.....如果必須與他人爭排名，沒有人能夠享受工作樂趣。 (p.122)
注：薪水固然重要，但興趣與工作樂趣更重要。若僅僅為了高薪而跳槽，很可能因此失去了一個很好的工作環境與發揮個人專長的舞台。
人員的管理
不准你爭辯的老闆，不值得你替他賣命。(p.139)
為求縮短開發時間，一般的作法是倉促地完成開發，結果卻發現個別部份無法組合起來，或是突然有更新更優秀的設計點子出現。於是一切再回到原點，重新開始。結果浪費時間，成本提高，最終產品也不如預期。 (p.152)
縮短開發時間的秘訣，在於多下一點功夫在最初的階段上，同時要研究階段間的相互影響。在愈早階段花愈多的努力，所獲得的利益會愈大。 (p.152)
注：軟體開發也是如此。倒不是說我們應該在初期就過度地分析或做過多的前置設計 (up-front design)，而是指在初期就應該審慎規劃、分析主要風險、以及做好架構面的考量。把一開始的路鋪好，以後會走得更順。
---------------< 書摘結束 >-----------------------------------------------
