16.使用演示获得频繁反馈

“这不是你的过错,问题出在我们的客户——那些麻烦的最终客户和用户身上。他们不停地更改需求,导致我们严重地延期。他们一次就应该想清楚所有想要的东西,然后把这些需求给我们,这样我们才能开发出令他们满意的系统。这才是正确的工作方式。”

阅读 ‧ 电子书库

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

你时常会听到一些人想要冻结需求。但需求就像是流动着的油墨是,现实世界中的需求就像是流动着的油墨。你无法冻结需求,正如你无法 Requirements are as fluid as ink冻结市场、竞争、知识、进化或者成长一样。就算你真的冻结了,也很可能是冻结了错的东西。如果你期望用户在项目开始之前,就能给你可靠和明确的需求,那就大错特错了,赶快醒醒吧!

没有人的思想和观点可以及时冻结,特别是项目的客户。就算是他们已经告诉你想要的东西了,他们的期望和想法还是在不停地进化——特别是他们在使用新系统的部分功能时,他们才开始意识到它的影响和可能发生的问题。这就是人的本性。

作为人类,不管是什么事情,我们都能越做越好,不过是以缓慢而逐步的方式。你的客户也一样。在给了你需求之后,他们会不停地研究这些功能,如何才能让它们变得更好使用。如果,你觉得自己要做的所有工作就是按照用户最初的需求,并实现了它们,但是在交付的时候,需求已经发生了变化,你的软件可能不会令他们满意。在软件开发过程中,你将自己置于最大的风险中:你生产出了他们曾经要求过的软件,但却不是他们现在真正想要的。那最后的结果就是:惊讶、震惊和失望,而不是满意。

几年前的一次数值分析课上,老师要求Venkat使用一些偏微分方程式模拟宇宙飞船的运行轨线。

程序基于时间t的坐标点,计算出在时间t+8的位置。程序最后绘出来的轨线图就是如图4-1中的虚线。

暂无图片

我们发现,估算出来的宇宙飞船位置远远地偏离了它的真实位置。万有引力不是只在我们计算的坐标点上才起作用。实际上,万有引力一直起作用:它是连接的,而不是离散的。由于忽略了点之间的作用力,我们的计算不断引入了误差,所以宇宙飞船最后到达了错误的地方。

缩小点之间的间隔(就是δ的值),再运行计算程序,误差就会减少。这时,估算的位置(如图4-1中的实线)就是和实际位置很接近了。

同理,你的客户的期望就像宇宙飞船的实际位置。软件开发的成功就在于最后你离客户的期望有多近。你计算的每个精确位置,就是一个给客户演示目前已经完成功能的机会,也正是得到用户反馈的时候。在你动身进入下一段旅程的时候,这些反馈可以用来纠正你的方向。

我们经常看到,给客户演示所完成功能的时间与得到客户需求的时间间隔越长,那么你就会离最初需求越来越远。

应该定期地,每隔一段时间,例如一个迭代的结束,就与客户会晤,并且演示你已经完成的功能特性。

如果你能与客户频繁协商,根据他们的反馈开发,每个人都可以从中受益。客户会清楚你的工作进度。反过来,他们也会提炼需求,然后趁热反馈到你的团队中。这样,他们就会基于自己进化的期望和理解为你导航,你编写的程序也就越来越接近他们的真实需求。客户也会基于可用的预算和时间,根据你们真实的工作进度,排列任务的优先级。

较短的迭代周期,会对频繁的反馈有负面影响吗?在宇宙飞船轨线的程序中,当δ降低的时候,程序运行就要发费更长的时间。也许你会觉得,使用短的迭代周期会使工作变慢,延迟项目的交付。

让我们从这个角度思考:两年来一直拼命地开发项目,直到快结束的时候,你和你的客户才发现一个基础功能有问题,而且它是一个核心的需求。你以为缺货订单是这样处理的,但这完全不是客户所想的东西。现在,两年之后,你完成了这个系统,写下了数百万行的代码,却背离了客户的期望。再怎么说,两年来辛苦写出的代码有相当大部分要重写,代价是沉重的。

相反,如果你一边开发,一边向他们演示刚完成的功能。项目进展了两个月的时候,他们说:“等一下,缺货订单根本不是这么一回事。”于是,召开一个紧急会议:你重新审查需求,评估要做多大的改动。这时只要付很少的代价,就可以避免灾难了。

要频繁地获得反馈。如果你的迭代周期是一个季节或者一年(那就太长了),就应把周期缩短到一周或者两周。完成了一些功能和特征之后,去积极获得客户的反馈。

阅读 ‧ 电子书库

清晰可见的开发。在开发的时候,要保持应有可见(而且客户心中也要了解)。每隔一周或者两周,邀请所有的客户,给他们演示最新完成的功能,积极获得他们的反馈。

切身感受

项目启动了一段时间之后,你应该进入一种舒适的状态,团队和客户建立了一种健康的富有创造性的关系。

突发事件应极少发生。客户应该能感受到,他们可以在一定程度上控制项目的方向。

阅读 ‧ 电子书库

平衡的艺术

1 当你第一次试图用这种方法和客户一起工作的时候,也许他们被这么多的发布吓到了。所以,要让他们知道,这些都是内部的发布(演示),是为了他们自己的利益,不需要发布给全部的最终用户。

2 一些客户,也许会觉得没有时间应付每天、每周甚至一个月一次会议,那么就定一个月。

3 一些客户的联络人的全职工作就是参加演示会议。他们巴不得每隔1个小时就有一次演示和反馈。你会发现这么频繁的会议很难应付,而且还要开发代码让他们看。缩减次数,只有在你做完一些东西可以给他们演示的时候,大家才碰面。定性的时候,不应该拿来演示,那只能让人生气。可以及早说明期望的功能:让客户知道,他们看到的是一个正在开发中的应用,而不是一个最终已经完成的产品。