Josh Berkus谈软件咨询行业的基本原则

Josh Berkus是关系型开源数据库PostgreSQL的核心开发成员，同时担任一家PostgreSQL咨询服务公司的总裁，他最近 分享了自己在软件咨询行业的经验，列举了一些基本法则。

1. 技术层面的问题只是管理方面问题的一种表现形式，如果某个公司在生产的软件中存在长期无法解决的问题，那么可以预见到，这个公司在管理管理业一定存在长期没有解决的问题。
2. 不要对以下三种情况抱有幻想：足够的项目时间、慷慨的客户、准确完整的文档说明。
3. 有大约一半的项目是会长期存在的，所谓某些“临时的、一次性”的项目通常可能会延续若干年，事实上，现在还有不少创建于上世纪70年代的产品还在顽强的生存着。所以，我们要为这些可能会长期存在的产品做好计划。
4. 某些低质的客户会坏掉你的公司，软件咨询业的成功要求你必须有能力识别那些恶劣的客户，能够躲开他们，或者在他们浪费你的时间和精力前终止与他们的的合同。永远躲开他们，即使你能得到补偿。
5. 不要考虑你能做什么，而要关注客户是否愿意为你的想法和服务付账，而且有足够的耐心等待结果。
6. 在时间和金钱的换算上要使用对数运算，比如，削减20%的时间需要2倍的资金，而削减30%的预算需要4倍的总时间。
7. 请记住：所有的预估都是乐观情况的，比如一个全新的软件开发所花费的时间可能是你预期的3倍，而费用则是预算的2倍。
8. 以下三件事情，你永远都没有足够的时间做完：软件规格文档和原型系统、说明文档、代码维护。
9. 所有存在业务逻辑的软件里都有一些奇怪的东西，它们可能是一些事务或一些数据，阻碍你梳理好业务流程。这些问题是无法数据集成的原因之一，也是不少麻烦事情的起因。
10. 不要说是重构：客户永远不会为代码整理工作付款，即使这是他们需要的。想办法找个其它的名词来代替“重构”，以此来让这种工作能够完成。
11. 你拖延越长的时间去重构，重构就会用掉你越长的时间。开发期主要原型和方案上的调整尤其致命。
12. 一定要签合同，即使只是一天的工作。同样，使用你自己的合同，而不是客户的合同，让一个真正的律师为你写一份合同。这是值得的。
13. 如果客户花大量的时间在合同细节上纠缠，那么项目真正实施过程(或付款过程)估计就会很困难。如果客户在一些含糊其辞的条款上坚持不让步，那他们就是打算利用这些条款。
14. 客户的记性很差：不管和他们签订过什么，他们总会忘记几天前答应过什么。备案所有的需求和变更，并备份。
15. 永远不要答应一个固定的承包价。除非完全相同的任务你之前做过一次。
16. 第三方参与者都是没能力的：当一个任务依赖于，甚至只是部分的依赖于一个第三方厂商的生产速度、文档或产品质量，当这些不在你的直接控制中时，永远不要接受一个固定标价或成功才付款的合同。当有数据交换或需要修改别人的代码时，不要接受固定标价，永远不要。
17. 客户都是门外汉：永远不要让客户决定你的开发工具、合作商或工作环境。或者，要为放弃这些权利收取额外的报酬。
18. 所有的会议都要收费，否则你半辈子的时间都要用于参加这些会议。
19. 储备足够的资金：通常，如果一个客户意外的延迟了一个月付款，那所有的客户都可能这样。永远储备能支撑60天的资金。
20. 严重延迟的项目永远不会竣工。通常，任何一个项目，如果它超出了预定的工期150%，那它就是有严重的管理上的问题在永久的阻拦它完工。

读者的评论也很有意思。

Vijay：我同意大部分观点，但是对于第8条的第3小项我不能赞同，当你提供咨询服务时，你应该设置自己的质量标准，并明确地把可读性和可维护性的代码写进去。

Rich：我把第15、16条归结为“永远不要答应固定报价”。Josh对此回复说：事实上，你可以通过对自己非常熟悉的任务提供固定报价来增加收益。固定报价意味着你可以开发内部工具来加快任务进行，而按小时收费则不行。而且，我们估计按固定10小时收费的任务通常花费了6-12小时，而平均为8小时，这就意味着我们多赚了2小时的钱。因此，固定报价用于你可以非常自信完成的任务。

无独有偶，在项目预估方面，37signals的创始人Jason fried在“Rework”一书中也提到了类似的观点：

预估的都是垃圾。我们都是蹩脚的估算师。我们自以为能预测一项任务会耗时多久，但实际上我们一无所知。我们把一切都看成按最佳方案进行，意识不到现实中总难免有突发事件会耽误进度。现实世界并不会与所谓的最佳案例情境相吻合。我们在评估项目时间时，错的不是一星半点——而是大错特错。这意味着如果你预计要花6个月时间，你可能已经谬以千里了：我们要说的不是从6个月拖到7个月，而是从6个月拖成1年。 解决方案就是：把大项目分解成小任务。越小的任务越容易预计。你可能还是会犯错，但错得肯定不会像预测大项目那么离谱。如果某个任务所用的时间比预计的长两倍，那么最好把它从长达数月的大项目拆解成耗时几周的小项目。不断地把你的计时范围拆分成小块。不要妄自揣测某个任务大约需要30个小时以上的时间来完成，直接把它砍成大约6-10个小时的小任务。然后一步一个脚印地努力前进。

您可能也会喜欢