這書本不是為興趣而讀﹐而是因工作上的需要而讀。我在新的工程企劃中﹐
要領導一個得幾個新人的小組﹐負責開發計劃中的其一個子系統。
我出來做事這幾年來一直也是做細的那個。雖然在技術專長上受到肯定﹐
也做過些獨立完成的工作﹐但要話事還第一次﹐可以說毫無管理經驗。
我老細也是工程司出身﹐明白我適應上的難處﹐於是借了這本書給我看﹐
他說這是他的管理天書。這不是一般的管理書藉﹐而是特別寫給軟件開發管理。
雖然我們公司是做硬件不是做軟件﹐但在電腦搞鍵盤的工作性質也很相同。
這本書的適合科技公司的中下管理層看﹐熟讀書中的理論和應用實例﹐
可以增加幾個人至幾十個人團隊的工作效率。整本書有五百多頁﹐
反正計劃開始時很清閑﹐我在公司有空時看幾章﹐不到一個星期就看完了。
以前在大學時也有上過管理課﹐不過課本上的東西﹐早在畢業時還了給教授。
很多時候只記得大慨意思卻忘記細節﹐讀這本書正好重溫不少有用的知識﹐
這本書很有系統地由最基本的理論開始﹐由計劃議案﹐團隊組成﹐風險評估﹐
死線時限﹐對外對內的溝通方法﹐到市場部對開發部間的政治也有詳細解說。
書後的附錄還有一系列的工具箱﹐詳細列出有什麼管理手段可以增加效率﹐
並每種手段的優劣和適合在什麼時候用。每章隨了理論外還有生動的例子﹐
是作者跟據他多年的工作經驗改篇﹐我讀到的時候也有點身同感受﹐
那些情況好像似層相悉。
看這本書的最大收獲﹐是學懂了那套管理語言﹐才能夠有效地思考計劃的問題。
很多時候有直覺告訴我不對路﹐但沒有理論基礎就無法清楚地指出問題所在。
看完書我還可以現學現賣﹐引用書中的理論﹐告訴老細若計劃遲已經有延誤﹐
假話可以後來追上進度是不切實際。一個開發工程有三項要求可以互相交換﹐
一是省人手﹐二是多功能﹐三是快完成﹐但在三項中只可以同時選擇兩項﹐
若要三項全選則連是神仙也無能為力。對上老細的老細也是明事理的人﹐
為要保存原本的功能和死線﹐只好增加人。這本書只有一點我十分不認同﹐
就是作者好像常常有意無意提及加班。我認為加班不是應該是常態﹐
在趕死線前趕幾個星期沒有問題﹐計劃完了通常可以放回補了的時間。
一個職員如果在工時內做不完要做事﹐要長時間要加班趕工﹐
只可以說明這個人的能力出了問題。若他的能力沒有問題﹐
而是管理層不停把過量的工作硬塞給他﹐則是管理層的管理能力有問題。
但如果計劃剛剛開始時﹐就已經把加班計算入開發所需的時間內﹐
那這個計劃一定不能準時完工。這是妄想三個要求也同時想選擇﹐
如果死線不能改﹐就要多加點人手或減點功能﹐面對現實是成功的第一步。
這好本書我當然要還給老細﹐不過我認為這是一本很有用的參考書﹐
每次開計劃期也應該拿來翻翻﹐重溫一下基礎理論避免幹蠢事﹐
所以我自己上網買了本二手放在書架。若他日我升多一級有兩層手下﹐
我也會推薦這本書給剛剛升上去的小組長看。不過如果再升上去﹐
這本以開發工作實戰為主的書則沒有太大用了。行政人員才不會去理﹐
這些雞毛蒜皮的要落手落腳做的事呢。