在翻譯《軟體工程與 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》回去看呀! (shame on me ^_^ )
廢除考績制度
將員工排等級,正顯示了管理者的失職。在考績制度下,所有人的目標都是討好上司。結果將會導致士氣低落,品質受損。因此把員工評等分級,分門別類,對於改善工作並沒有任何幫助。
錯誤的企管教育-數字化目標與結果導向管理
數字化目標會導致扭曲和作假,尤其是當系統根本無力達到目標的時候,更有此可能。每個人都會設法達成被分配到的配額(目標),但卻並不對由此所導致的損失負責。(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),而是指在初期就應該審慎規劃、分析主要風險、以及做好架構面的考量。把一開始的路鋪好,以後會走得更順。
---------------< 書摘結束 >-----------------------------------------------
購買本書
書名:戴明的新經濟觀
作者:W. Edwards Deming
譯者:戴久永
出版:天下文化
---------------< 書摘開始 >-----------------------------------------------
美國人的問題在於教育以及如何發展重視學習的文化。(p.8)
注:台灣也是啊!Orz
顧客不會發明
大家都說要符合顧客的期望。事實上,顧客的期望乃是由你與你的競爭對手所塑造,顧客學得很快。(p.9)
注:例如,是顧客要求軟體廠商發展即時通訊軟體,還是廠商先開發出來,人們覺得好用才開始普及?
高階管理者該為品質負責
公司產品的品質,不可能高於高階管理者所設定的品質水準。(p.20)
注:如果主事者與開發人員在軟體開發方面的理念不一致,或者不了解開發人員為何要這樣做,以及那樣做對品質有何影響的時候,開發人員恐怕很難得到上頭的認同與許可,去做他們認為該做的事。因此,主事者必須對軟體開發的本質、概念、與實務作法有一定程度的了解,才能將開發的方向導正,並確保軟體的品質。所以,結論就是.....不只是開發團隊成員,各位現任(或未來將升任)的軟體公司主管、CIO、專案經理們, 請務必也買一本《軟體工程與 Microsoft Visual Studio Team System》回去看呀! (shame on me ^_^ )
廢除考績制度
將員工排等級,正顯示了管理者的失職。在考績制度下,所有人的目標都是討好上司。結果將會導致士氣低落,品質受損。因此把員工評等分級,分門別類,對於改善工作並沒有任何幫助。
錯誤的企管教育-數字化目標與結果導向管理
數字化目標會導致扭曲和作假,尤其是當系統根本無力達到目標的時候,更有此可能。每個人都會設法達成被分配到的配額(目標),但卻並不對由此所導致的損失負責。(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),而是指在初期就應該審慎規劃、分析主要風險、以及做好架構面的考量。把一開始的路鋪好,以後會走得更順。
---------------< 書摘結束 >-----------------------------------------------
購買本書
沒有留言: