軟件項目顧問的20法則

    英文原文：20 Rules of Software Consulting

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

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

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

           a. 慷慨的工期；

           b. 爽快付款的客戶；

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

3. 有一半的應用項目都是長壽的：“臨時、一次性”的項目應用通常會延續數年，如今仍然有誕生于上世紀 70 年代的代碼在運行。記著要為這些長壽的情況做計劃。
4. 低劣的客戶會毀掉你的生意：你的成功的一半來自于有能力識別那些劣質的客戶、能夠避開他們或在他們無休止的消耗你的時間和資源前終止和他們的合同。永遠避開他們，即使他們能給你帶來補償。
5. Ask Not What’s Possible：問題不是你能做出什么，問題是客戶是否有愿望為它出錢，有多大的耐心去等待。
6. 在時間和錢的換算上使用對數運算：例如，消減 20% 的時間需要雙倍的預算資金。消減 30% 的預算需要四倍的總時間。
7. 所有的預估都是樂觀的：一個新的應用軟件的開發會耗用掉三倍于你預期的時間，2 倍于你的預算。反之亦然。
8. 你永遠不會有足夠的時間應付三件事：

           a) 軟件規格文檔和原型

           b) 說明文檔

           c) 代碼維護

9. 所有有業務內容的應用軟件里都會有一些不倫不類的怪物，它們可能是一些事務或一些數據，抗拒你所有的把它納入定義好的業務流程中的努力。這些怪物既是完美數據集成無法實現的阻因，也是至少 30% 麻煩事端的來源。
10. 不要說是重構：客戶永遠不會為代碼整理工作付款，即使這是他們需要的。想想辦法找個其它的名詞來代替“重構”，以此來讓這種工作能夠完成。
11. 你拖延越長的時間去重構，重構就會用掉你越長的時間。開發期主要原型和方案上的調整尤其致命。
12. 一定要簽合同，即使只是一天的工作。同樣，使用你自己的合同，而不是客戶的合同，讓一個真正的律師為你寫一份合同。這是值得的。
13. 合同簽訂過程可以當作項目開發實現的一個石蕊測試。如果客戶花大量的時間在合同細節上糾纏，那么項目真正實施過程(或付款過程)估計就會很困難。如果客戶在一些奇怪含混的條款上堅持不讓步，那他們就是打算利用這些條款。
14. 客戶的記性很差：不管和他們簽訂過什么，他們總會忘記幾天前答應過什么。備案所有的需求和變更，并備份。
15. 永遠不要答應一個固定的承包價。除非完全相同的任務你之前做過一次。
16. 第三方參與者都是沒能力的：當一個任務依賴于，甚至只是部分的依賴于一個第三方廠商的生產速度，文檔或產品質量，當這些不在你的直接控制中時，永遠不要接受一個固定標價或成功才付款的合同。當有數據交換或需要修改別人的代碼時，不要接受固定標價，永遠不要。
17. 客戶都是沒品位的：永遠不要讓客戶決定你的開發工具、合作商或工作環境。或者，要為放棄這些權利收取額外的報酬。
18. 所有的會議都要收費，否則你的半個生命的時間都要用于參加這些會議。
19. 儲備足夠的資金：通常，如果一個客戶意外的延遲了一個月付款，那所有的客戶都可能這樣。永遠儲備能支撐 60 天的資金。
20. 嚴重延遲的項目永遠不會竣工。通常，任何一個項目，如果它 150% 的超出了預定的工期，那它就是有嚴重的管理上的問題在永久的阻攔它完工。
    來自: 外刊IT評論