[[67312]] 

Josh Berkus是著名的關系型開源數(shù)據(jù)庫PostgreSQL的核心開發(fā)成員。他還是PostgreSQL Experts Inc.——一個PostgreSQL專業(yè)服務公司的CEO，在加入到PostgreSQL開發(fā)團隊前，Josh Berkus曾參與各種軟件的開發(fā)，包括OpenOffice.org, Microsoft SQL Server, Oracle PL/SQL, 和 (shudder) COM+。他還寫過Perl。

在Josh Berkus多彩的生活中，它曾經(jīng)做過雕刻師、陶藝師、糕點面包師、勞動組織者、說客、法律助理、專業(yè)的募捐活動者等。他認為這些經(jīng)歷給了他更廣闊的視野，遠比在硅谷的生活重要，但也許這是在開玩笑。從1993年起他就生活在舊金山。
 

1.技術層面問題是管理層面問題的折射：如果一個公司在它的軟件中有長期解決不掉的問題，我必然能證明這個公司在管理工作中有長期沒有解決的問題。

2.三種情況你永遠遇不到：

a. 慷慨的工期；

b. 爽快付款的客戶；

c. 精確完整的文檔說明。

3.有一半的應用項目都是長壽的：“臨時、一次性”的項目應用通常會延續(xù)數(shù)年，如今仍然有誕生于上世紀70年代的代碼在運行。記著要為這些長壽的情況做計劃。

4.低劣的客戶會毀掉你的生意：你的成功的一半來自于有能力識別那些劣質(zhì)的客戶、能夠避開他們或在他們無休止的消耗你的時間和資源前終止和他們的合同。永遠避開他們，即使他們能給你帶來補償。

5.Ask Not What’s Possible：問題不是你能做出什么，問題是客戶是否有愿望為它出錢，有多大的耐心去等待。

6.在時間和錢的換算上使用對數(shù)運算：例如，消減20%的時間需要雙倍的預算資金。消減30%的預算需要四倍的總時間。

7.所有的預估都是樂觀的：一個新的應用軟件的開發(fā)會耗用掉三倍于你預期的時間，2倍于你的預算。反之亦然。

8.你永遠不會有足夠的時間應付三件事：

a) 軟件規(guī)格文檔和原型

b) 說明文檔

c) 代碼維護

9.所有有業(yè)務內(nèi)容的應用軟件里都會有一些不倫不類的怪物，它們可能是一些事務或一些數(shù)據(jù)，抗拒你所有的把它納入定義好的業(yè)務流程中的努力。這些怪物既是***數(shù)據(jù)集成無法實現(xiàn)的阻因，也是至少30%麻煩事端的來源。

10.不要說是重構：客戶永遠不會為代碼整理工作付款，即使這是他們需要的。想想辦法找個其它的名詞來代替“重構”，以此來讓這種工作能夠完成。

11.你拖延越長的時間去重構，重構就會用掉你越長的時間。開發(fā)期主要原型和方案上的調(diào)整尤其致命。

12.一定要簽合同，即使只是一天的工作。同樣，使用你自己的合同，而不是客戶的合同，讓一個真正的律師為你寫一份合同。這是值得的。

13.合同簽訂過程可以當作項目開發(fā)實現(xiàn)的一個石蕊測試。如果客戶花大量的時間在合同細節(jié)上糾纏，那么項目真正實施過程(或付款過程)估計就會很困難。如果客戶在一些奇怪含混的條款上堅持不讓步，那他們就是打算利用這些條款。

14.客戶的記性很差：不管和他們簽訂過什么，他們總會忘記幾天前答應過什么。備案所有的需求和變更，并備份。

15.永遠不要答應一個固定的承包價。除非完全相同的任務你之前做過一次。

16.第三方參與者都是沒能力的：當一個任務依賴于，甚至只是部分的依賴于一個第三方廠商的生產(chǎn)速度，文檔或產(chǎn)品質(zhì)量，當這些不在你的直接控制中時，永遠不要接受一個固定標價或成功才付款的合同。當有數(shù)據(jù)交換或需要修改別人的代碼時，不要接受固定標價，永遠不要。

17.客戶都是沒品位的：永遠不要讓客戶決定你的開發(fā)工具、合作商或工作環(huán)境。或者，要為放棄這些權利收取額外的報酬。

18.所有的會議都要收費，否則你的半個生命的時間都要用于參加這些會議。

19.儲備足夠的資金：通常，如果一個客戶意外的延遲了一個月付款，那所有的客戶都可能這樣。永遠儲備能支撐60天的資金。

20.嚴重延遲的項目永遠不會竣工。通常，任何一個項目，如果它150%的超出了預定的工期，那它就是有嚴重的管理上的問題在***的阻攔它完工。

英文原文：20 Rules of Software Consulting

譯文鏈接：http://www.aqee.net/20-rules-of-software-consulting/