10.让客户做决定

“开发者兼具创新和智慧,最了解应用程序。因此,所有关键决定都应该由开发者定夺。每次业务人员介入的时候,都会弄得一团槽,他们无法理解我们做事的逻辑。”

在设计方面,做决定的时候必须有开发者参与。可是,在一个项目中,他们不应该做所有的决定,特别是业务方面的决定。

就拿项目经理Pat的例子来说吧。Pat的项目是远程开发,一切按计划且在预算内进行着—就像是个可以写入教科书的明星项目。Pat高高兴兴地把代码带到客户那里,给客户演示,却败兴而归。

广告:个人专属 VPN,独立 IP,流量大,速度快,连接稳定,多机房切换,每月最低仅 5 美元

原来,Pat的业务分析师没有和用户讨论,而是自作主张,决定了所有的问题。在整个开发过程中,企业主根本没有参与低级别的决策。项目离完成还早着呢,就已经不能满足用户的需要了。这个项目一定会延期,又成为一个经典的失败案例。

因而,你只有一个选择:要么现在就让用户做决定,要么现在就开始开发,迟些让用户决定,不过要付出较高的成本。如果你在开发阶段回避这些问题,就增加了风险,但是你要能越早解决这些问题,就越有可能避免繁重的重新设计和编码。甚至在接近项目最终期限的时候,也能避免与日俱增的时间压力。

例如,假设你要完成一个任务,有两种实现方式。第一种方式的实现比较快,但是对用户有一点限制。第二种方式实现起来需要更多的时间,但是可以提供更大的灵活性。很显然,你有时间的压力(什么项目没有时间压力呢),那么你就用第一种很快的方式吗?你凭什么做出这样的决定呢?是投硬币吗?你询问了同事或者你的项目经理吗?

作者之一Venkat最近的一个项目就遇到了类似的问题。项目经理为了节约时间,采取了第一种方式。也许你会猜到,在Beta版测试的时候,软件暴露出的局限让用户震惊,甚至愤怒。结果还得重做,花费了团队更多的金钱、时间和精力。

阅读 ‧ 电子书库

开发者(及项目经理)能做的一个最重要的决定就是:判断哪些是自己决定不了的,应该让企业主做决定。你不需要自己给业务上的关键问题做决定。毕竟,那不是你的事情,如果遇到 了一个问题,会影响到系统的行为或者如何使用系统,把这个问题告诉业务负责人。如果项目领导或经理试图全权负责这些问题,要委婉地劝说他们,这些问题最好还是和真正的业务负责人或者客户商议(见习惯4,第23页)。

当你和客户讨论问题的时候,准备好几种可选择的方案。不是从技术的角度,而是从业务的角度,介绍每种方案的优缺点,以及潜在的成本和利益。和他们讨论每个选择对时间和预算的影响,以及如何权衡。无论他们作出了什么决定,他们必须接受它,所以最好让他们了解一切之后再做这些决定。如果事后他们又想要其他的东西,可以公正地就成本和时间重新谈判。

毕竟,这是他们的决定。

让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的言语,向他们详细解释遇到的问题,并让他们做决定。

切身感受

业务应用需要开发者和业务负责人互相配合来开发。这种配合的感觉就应该像一种良好的、诚实的工作关系。

平衡的艺术

第3章 记录客户做出的决定,并注明原因。好记性不如烂笔头。可以使用工程师的工作日记或日志、Wiki、邮件记录或者问题跟踪数据库。但是也要注意,你选择的记录方法不能太笨重或者太繁琐。

第4章 不要用低级别和没有价值的问题打扰繁忙的业务人员。如果问题对他们的业务没有影响,就应该是没有价值的。

第5章 不要随意假设低级别的问题不会影响他们的业务。如果能影响他们的业务,就是有价值的问题。

第6章 如果业务负责人回答“我不知道”,这也是一个称心如意的答案。也许是他们还没有想到那么远,也许是他们只有看到运行的实物才能评估出结果。尽你所能为他们提供建议,实现代码的时候也要考虑可能出现的变化。