频繁反馈了解客户需求

北大青鸟大学城校区logo 北大青鸟大学城校区
招生简章校园环境师资力量就业明星招生问答软件工程师北京大学学历学员项目联系我们 报名通道

免费在线咨询通道>>

免费在线报名通道>>

北大青鸟报名电话
当前位置:北大青鸟 > 北大青鸟精神 >

频繁反馈了解客户需求

标签:   分类:北大青鸟精神

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

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

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

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

几年前的一次数值分析课上,老师要求venkat使用一些偏微分方程式模拟宇宙飞船的运行轨线。程序基于时间的坐标点.计算出在时间升t+&的位置。

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

缩小点之间的间隔(就是&的值),再运行计算程序,误差就会减少。这时,估算的位置就和实际位置很接近了。同理,你的客户的期望就像宇宙飞船的实际位置。软件开发的成功就在于最后你离客户的期望有多近。你计算的每个精确位置,就是一个给客户演示目前已经完成功能的机会,也正是得到用户反馈的时候。在你动身进入下一段旅程的时候,这些反馈可以用来纠正你的方向。

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

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

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

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

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

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

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

Andy如是说

维护项目术语表

不一致的术语是导致需求误解的一个主要原因,企业喜欢用看似普遍浅显的词语来表达非常具体,深刻的意义。

我经常看到这样的事情:团队中的程序员们,使用了和用户或者业务人员不同的术语,最后因为“阻抗失调”导致bug和设计错误。

为了避免这类问题,需堆护一份项目术语表.人们应该可以公开访问它,一般是在企业内部网或者wiki上。这听起采似乎是一件小事情——只是一个术语列表厦其定义。但是,它可以帮助你,确保你真正地和用户进行沟通。

在项目的开发过程中,从术语袁中为程序结构——类,方法、模型,变量等选择夸适的名字,并且要检查和确保这些定义一直符合用户的期望。

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

切身感受

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

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

跟踪问题

随着项目的进展;你会得到很多反馈反——修正、建议、变更要求,功能增强,bug修复等。要注意的信息很多。随机的邮件和潦草的告示帖是无法应付的,所以,每有一个跟踪系统记录所有这些日志,可能是用Web面的系统。

平衡的艺术

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

一些客户.也许会觉得没有时间应付每天、每周甚至是每两周的会议。毕竟,他们还有自己的全职工作。

所以要尊重客户的时间。如果客户只可以接受一个月一次会议,那么就定一个月。

一些客户的联络人的全职工作就是参加演示会议。他们巴不得每隔l小时就有一次演示和反馈。你会发现这么频繁的会议很难应付,而且还要开发代码让他们看。缩减次数,只有在你做完一些东西可以给他们演示的时候,大家才碰面。

演示是用来让客户提出反馈的,有助于驾驭项目的方向。如果缺少功能或者稳定性的时候,不应该拿来演示,那只能让人生气。可以及早说明期望的功能:让客户知道,他们看到的足一个正在开发中的应用,而不是一个最终已经完成的产品。

若有疑问请拨打北大青鸟咨询热线:010-80146691或点击免费在线咨询!
  • xml地图 网站地图 招生简章 合作企业 学员项目 联系我们
  • 关闭窗口