软件项目顾问的20法则
jopen 12年前
英文原文：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 年起他就生活在旧金山。
- 技术层面问题是管理层面问题的折射：如果一个公司在它的软件中有长期解决不掉的问题，我必然能证明这个公司在管理工作中有长期没有解决的问题。
- 三种情况你永远遇不到：
a. 慷慨的工期；
b. 爽快付款的客户；
c. 精确完整的文档说明。
- 有一半的应用项目都是长寿的：“临时、一次性”的项目应用通常会延续数年，如今仍然有诞生于上世纪 70 年代的代码在运行。记着要为这些长寿的情况做计划。
- 低劣的客户会毁掉你的生意：你的成功的一半来自于有能力识别那些劣质的客户、能够避开他们或在他们无休止的消耗你的时间和资源前终止和他们的合同。永远避开他们，即使他们能给你带来补偿。
- Ask Not What’s Possible：问题不是你能做出什么，问题是客户是否有愿望为它出钱，有多大的耐心去等待。
- 在时间和钱的换算上使用对数运算：例如，消减 20% 的时间需要双倍的预算资金。消减 30% 的预算需要四倍的总时间。
- 所有的预估都是乐观的：一个新的应用软件的开发会耗用掉三倍于你预期的时间，2 倍于你的预算。反之亦然。
- 你永远不会有足够的时间应付三件事：
a) 软件规格文档和原型
b) 说明文档
c) 代码维护
- 所有有业务内容的应用软件里都会有一些不伦不类的怪物，它们可能是一些事务或一些数据，抗拒你所有的把它纳入定义好的业务流程中的努力。这些怪物既是完美数据集成无法实现的阻因，也是至少 30% 麻烦事端的来源。
- 不要说是重构：客户永远不会为代码整理工作付款，即使这是他们需要的。想想办法找个其它的名词来代替“重构”，以此来让这种工作能够完成。
- 你拖延越长的时间去重构，重构就会用掉你越长的时间。开发期主要原型和方案上的调整尤其致命。
- 一定要签合同，即使只是一天的工作。同样，使用你自己的合同，而不是客户的合同，让一个真正的律师为你写一份合同。这是值得的。
- 合同签订过程可以当作项目开发实现的一个石蕊测试。如果客户花大量的时间在合同细节上纠缠，那么项目真正实施过程(或付款过程)估计就会很困难。如果客户在一些奇怪含混的条款上坚持不让步，那他们就是打算利用这些条款。
- 客户的记性很差：不管和他们签订过什么，他们总会忘记几天前答应过什么。备案所有的需求和变更，并备份。
- 永远不要答应一个固定的承包价。除非完全相同的任务你之前做过一次。
- 第三方参与者都是没能力的：当一个任务依赖于，甚至只是部分的依赖于一个第三方厂商的生产速度，文档或产品质量，当这些不在你的直接控制中时，永远不要接受一个固定标价或成功才付款的合同。当有数据交换或需要修改别人的代码时，不要接受固定标价，永远不要。
- 客户都是没品位的：永远不要让客户决定你的开发工具、合作商或工作环境。或者，要为放弃这些权利收取额外的报酬。
- 所有的会议都要收费，否则你的半个生命的时间都要用于参加这些会议。
- 储备足够的资金：通常，如果一个客户意外的延迟了一个月付款，那所有的客户都可能这样。永远储备能支撑 60 天的资金。
- 严重延迟的项目永远不会竣工。通常，任何一个项目，如果它 150% 的超出了预定的工期，那它就是有严重的管理上的问题在永久的阻拦它完工。 来自: 外刊IT评论