预计阅读本页时间：-
10.让客户做决定
“开发者兼具创新和智慧，最了解应用程序。因此，所有关键决定都应该由开发者定夺。每次业务人员介入的时候，都会弄得一团槽，他们无法理解我们做事的逻辑。”
在设计方面，做决定的时候必须有开发者参与。可是，在一个项目中，他们不应该做所有的决定，特别是业务方面的决定。
就拿项目经理Pat的例子来说吧。Pat的项目是远程开发，一切按计划且在预算内进行着—就像是个可以写入教科书的明星项目。Pat高高兴兴地把代码带到客户那里，给客户演示，却败兴而归。
广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元
原来，Pat的业务分析师没有和用户讨论，而是自作主张，决定了所有的问题。在整个开发过程中，企业主根本没有参与低级别的决策。项目离完成还早着呢，就已经不能满足用户的需要了。这个项目一定会延期，又成为一个经典的失败案例。
因而，你只有一个选择：要么现在就让用户做决定，要么现在就开始开发，迟些让用户决定，不过要付出较高的成本。如果你在开发阶段回避这些问题，就增加了风险，但是你要能越早解决这些问题，就越有可能避免繁重的重新设计和编码。甚至在接近项目最终期限的时候，也能避免与日俱增的时间压力。
例如，假设你要完成一个任务，有两种实现方式。第一种方式的实现比较快，但是对用户有一点限制。第二种方式实现起来需要更多的时间，但是可以提供更大的灵活性。很显然，你有时间的压力（什么项目没有时间压力呢），那么你就用第一种很快的方式吗？你凭什么做出这样的决定呢？是投硬币吗？你询问了同事或者你的项目经理吗？
作者之一Venkat最近的一个项目就遇到了类似的问题。项目经理为了节约时间，采取了第一种方式。也许你会猜到，在Beta版测试的时候，软件暴露出的局限让用户震惊，甚至愤怒。结果还得重做，花费了团队更多的金钱、时间和精力。
开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。你不需要自己给业务上的关键问题做决定。毕竟，那不是你的事情，如果遇到 了一个问题，会影响到系统的行为或者如何使用系统，把这个问题告诉业务负责人。如果项目领导或经理试图全权负责这些问题，要委婉地劝说他们，这些问题最好还是和真正的业务负责人或者客户商议（见习惯4，第23页）。
当你和客户讨论问题的时候，准备好几种可选择的方案。不是从技术的角度，而是从业务的角度，介绍每种方案的优缺点，以及潜在的成本和利益。和他们讨论每个选择对时间和预算的影响，以及如何权衡。无论他们作出了什么决定，他们必须接受它，所以最好让他们了解一切之后再做这些决定。如果事后他们又想要其他的东西，可以公正地就成本和时间重新谈判。
毕竟，这是他们的决定。
让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的言语，向他们详细解释遇到的问题，并让他们做决定。
切身感受
业务应用需要开发者和业务负责人互相配合来开发。这种配合的感觉就应该像一种良好的、诚实的工作关系。
平衡的艺术
第3章 记录客户做出的决定，并注明原因。好记性不如烂笔头。可以使用工程师的工作日记或日志、Wiki、邮件记录或者问题跟踪数据库。但是也要注意，你选择的记录方法不能太笨重或者太繁琐。
第4章 不要用低级别和没有价值的问题打扰繁忙的业务人员。如果问题对他们的业务没有影响，就应该是没有价值的。
第5章 不要随意假设低级别的问题不会影响他们的业务。如果能影响他们的业务，就是有价值的问题。
第6章 如果业务负责人回答“我不知道”，这也是一个称心如意的答案。也许是他们还没有想到那么远，也许是他们只有看到运行的实物才能评估出结果。尽你所能为他们提供建议，实现代码的时候也要考虑可能出现的变化。
