在Google搜尋時, 剛好在網路上看到Tom Demarco於2009 IEEE 七八月刊的作品: Software Engineering: An Idea Whose Time Has Come and Gone? 很欣賞他連之前的自己都可以否定的勇氣. 我相信越有名, 要說自己以前是錯的越困難.
他在此文對於自己1982年寫的Controlling Software Projects: Management, Measurement, and Estimation(Prentice Hall, Yourdon Press出版),這本啟蒙軟工專案計畫與度量發展的重要作品, 重新評價:
"Do I still believe that metrics are a must for any successful software devleopment effort? My answers are no, no, and no."
還自己說這本書所傳達的message有誤:
"The book's deep message seems to be, metrics are good, more would be better, and most would be best. Today we all understand that software metrics cost money and time and must be used with careful moderation."
"The book's most quoted line is its first sentence: You can't control what you can't measure. This line contains a real truth, but I've become increasingly uncomfortable with my use of it. Implicit in the quote(and indeed in the book's title) is that control is an important aspect, maybe the most important, of any software project. But it isn't. "
他從專案的本質：一個投百萬可賺1.1百萬的案, 和一個投百萬可賺50百萬的案相比, 獲利能力低的案子相對需要較高的control才能成功, 來說明並非每個案子都要一樣的control程度. 那是否獲利低的案子反而要花更多錢跟時間去做measurement, 那利潤不就更低了. 這是做低獲利案的惡性循環. 也回歸到business model的問題, 為什麼要接這樣低利潤的案子?
另一方面, 他也提出人的品質是無法度量的, 你可以度量honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyty, humor, kindness這些嗎? 但事實上這些都深深影響到專案的performance. 所以DeMarco建議要做好專案就回歸人,時間和資源的管理. 在管理的方法上,雖然他很謙虛的說他沒什麼資格來建議軟體開發要用什麼方法, 不過他提倡agile的概念.
雖然他一再說度量, 可預測不是最重要的, 但仍相信軟體開發仍需要工程化, 但不要把on time和on budget當成最高準則. 那什麼是最重要的呢?
"The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business."
我相信這是DeMarco殷切想讓大家不斷去回歸本質想"為什麼我要做這個專案?", "怎樣才能把事情做好?" 而不要因為要達到某專家說的最高境界, 而投入大量資源只為生出很多度量報告, 但忘了去評估做這些報告之於"原始目標" 幫助有多大? 哪些是必要的? 又哪些沒有必要?
如果Google當初是選擇運用搜尋引擎的技術接專案的方式, 今天大概沒有人知道Google是什麼吧. 這應該就是DeMarco在這篇文章一直強調的what is important.
最後, 不相關話題, 但相關Mr. Tom DeMarco
推薦DeMarco "最後期限"的專案管理的小說 有深度又很有趣！
沒有留言:
張貼留言