预计阅读本页时间：-
16.使用演示获得频繁反馈
“这不是你的过错，问题出在我们的客户——那些麻烦的最终客户和用户身上。他们不停地更改需求，导致我们严重地延期。他们一次就应该想清楚所有想要的东西，然后把这些需求给我们，这样我们才能开发出令他们满意的系统。这才是正确的工作方式。”
广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元
你时常会听到一些人想要冻结需求。但需求就像是流动着的油墨是，现实世界中的需求就像是流动着的油墨。你无法冻结需求，正如你无法 Requirements are as fluid as ink冻结市场、竞争、知识、进化或者成长一样。就算你真的冻结了，也很可能是冻结了错的东西。如果你期望用户在项目开始之前，就能给你可靠和明确的需求，那就大错特错了，赶快醒醒吧！
没有人的思想和观点可以及时冻结，特别是项目的客户。就算是他们已经告诉你想要的东西了，他们的期望和想法还是在不停地进化——特别是他们在使用新系统的部分功能时，他们才开始意识到它的影响和可能发生的问题。这就是人的本性。
作为人类，不管是什么事情，我们都能越做越好，不过是以缓慢而逐步的方式。你的客户也一样。在给了你需求之后，他们会不停地研究这些功能，如何才能让它们变得更好使用。如果，你觉得自己要做的所有工作就是按照用户最初的需求，并实现了它们，但是在交付的时候，需求已经发生了变化，你的软件可能不会令他们满意。在软件开发过程中，你将自己置于最大的风险中：你生产出了他们曾经要求过的软件，但却不是他们现在真正想要的。那最后的结果就是：惊讶、震惊和失望，而不是满意。
几年前的一次数值分析课上，老师要求Venkat使用一些偏微分方程式模拟宇宙飞船的运行轨线。
程序基于时间t的坐标点，计算出在时间t+8的位置。程序最后绘出来的轨线图就是如图4-1中的虚线。
暂无图片
我们发现，估算出来的宇宙飞船位置远远地偏离了它的真实位置。万有引力不是只在我们计算的坐标点上才起作用。实际上，万有引力一直起作用：它是连接的，而不是离散的。由于忽略了点之间的作用力，我们的计算不断引入了误差，所以宇宙飞船最后到达了错误的地方。
缩小点之间的间隔（就是δ的值），再运行计算程序，误差就会减少。这时，估算的位置（如图4-1中的实线）就是和实际位置很接近了。
同理，你的客户的期望就像宇宙飞船的实际位置。软件开发的成功就在于最后你离客户的期望有多近。你计算的每个精确位置，就是一个给客户演示目前已经完成功能的机会，也正是得到用户反馈的时候。在你动身进入下一段旅程的时候，这些反馈可以用来纠正你的方向。
我们经常看到，给客户演示所完成功能的时间与得到客户需求的时间间隔越长，那么你就会离最初需求越来越远。
应该定期地，每隔一段时间，例如一个迭代的结束，就与客户会晤，并且演示你已经完成的功能特性。
如果你能与客户频繁协商，根据他们的反馈开发，每个人都可以从中受益。客户会清楚你的工作进度。反过来，他们也会提炼需求，然后趁热反馈到你的团队中。这样，他们就会基于自己进化的期望和理解为你导航，你编写的程序也就越来越接近他们的真实需求。客户也会基于可用的预算和时间，根据你们真实的工作进度，排列任务的优先级。
较短的迭代周期，会对频繁的反馈有负面影响吗？在宇宙飞船轨线的程序中，当δ降低的时候，程序运行就要发费更长的时间。也许你会觉得，使用短的迭代周期会使工作变慢，延迟项目的交付。
让我们从这个角度思考：两年来一直拼命地开发项目，直到快结束的时候，你和你的客户才发现一个基础功能有问题，而且它是一个核心的需求。你以为缺货订单是这样处理的，但这完全不是客户所想的东西。现在，两年之后，你完成了这个系统，写下了数百万行的代码，却背离了客户的期望。再怎么说，两年来辛苦写出的代码有相当大部分要重写，代价是沉重的。
相反，如果你一边开发，一边向他们演示刚完成的功能。项目进展了两个月的时候，他们说：“等一下，缺货订单根本不是这么一回事。”于是，召开一个紧急会议：你重新审查需求，评估要做多大的改动。这时只要付很少的代价，就可以避免灾难了。
要频繁地获得反馈。如果你的迭代周期是一个季节或者一年（那就太长了），就应把周期缩短到一周或者两周。完成了一些功能和特征之后，去积极获得客户的反馈。
清晰可见的开发。在开发的时候，要保持应有可见（而且客户心中也要了解）。每隔一周或者两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
切身感受
项目启动了一段时间之后，你应该进入一种舒适的状态，团队和客户建立了一种健康的富有创造性的关系。
突发事件应极少发生。客户应该能感受到，他们可以在一定程度上控制项目的方向。
平衡的艺术
1 当你第一次试图用这种方法和客户一起工作的时候，也许他们被这么多的发布吓到了。所以，要让他们知道，这些都是内部的发布（演示），是为了他们自己的利益，不需要发布给全部的最终用户。
2 一些客户，也许会觉得没有时间应付每天、每周甚至一个月一次会议，那么就定一个月。
3 一些客户的联络人的全职工作就是参加演示会议。他们巴不得每隔1个小时就有一次演示和反馈。你会发现这么频繁的会议很难应付，而且还要开发代码让他们看。缩减次数，只有在你做完一些东西可以给他们演示的时候，大家才碰面。定性的时候，不应该拿来演示，那只能让人生气。可以及早说明期望的功能：让客户知道，他们看到的是一个正在开发中的应用，而不是一个最终已经完成的产品。
