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

  • 崔康

2013 年 3 月 18 日

话题:语言 & 开发架构文化 & 方法

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 个小时的小任务。然后一步一个脚印地努力前进。

语言 & 开发架构文化 & 方法