疯狂的订餐系统软件需求分析挑战之旅3

特别声明:
如需转载此文,请给出指向本网站的连接,如下:
作者:张传波
摘自:http://www.umlonline.cn
如不能按此要求,请不要转载此文。
 
1.4 没完没了的“新需求”
 
由于你的彻底而深入的需求分析工作,订餐系统进展非常顺利,很快就上线运行了!但问题也就来了,客户陆陆续续提出了以下问题:
1)要经过好几个页面才能进入订餐页面,不太方便,希望能在首页直接进入订餐页面。
2)一次只能定一天的餐,不太方便,希望一次能定多天的。
3)我有时选了一个菜,前台却说这个菜没有了!
4)能不能提供多家餐馆选择?
5)订餐标准才8元,现在物价都涨了,能不能提高一下标准?
6)能不能直接连到餐馆的网页上去看菜式?
7)能不能做口味分析和营养分析?
 
系统能用起来,问题肯定多多,没问题反而说明没有人用这个系统,所以有问题是好事,但问题多了又会让人很烦躁,改来改去没完没了啊,项目的成本也会持续上升。
你准备如何招架呢?在继续阅读之前,请你逐一分析上述问题并提出解决方案,要写下来奥!
 
下面我们来逐一分析上述问题。
 
1)要经过好几个页面才能进入订餐页面,不太方便,希望能在首页直接进入订餐页面。
2)一次只能定一天的餐,不太方便,希望一次能定多天的。
 


我们首先要思考,这两个要求背后的需要是什么呢?这两个问题都是在实际使用订餐系统中产生的,用户提出这样的要求无非是希望系统更加好用更加方便,订餐系统无非是要方便大家订餐、减少订餐时间,故这两个要求应该予以满足。
系统上线后,用户往往会提出很具体的修改要求,这些要求往往是易用性方面的问题,如:界面布局、操作方式、文字表达、排序条件等细节问题,这些问题不解决的话会降低用户体验,此类问题一般应尽量解决。
前 期对项目的需要把握得比较好的话,软件基本上是能符合用户的需要的,哪怕用户提出了一些易用性方面的要求,一般也是很容易修改的。不过谁也不能保证对需要 的理解没有偏差,有可能系统上线后才发现理解错了客户的真正需要,这时修改系统的话一般来说工作量会比较大,但原则上应该给予修改,双赢是项目的目标,客 户关键需要没有满足,项目不能算成功。
 
3)我有时选了一个菜,前台却说这个菜没有了!
5)订餐标准才8元,现在物价都涨了,能不能提高一下标准?
 
会什么会有选了菜但没有这个菜的问题呢?是软件的bug吗?
原来餐厅的菜单会定期更换,前台会及时更新订餐系统的菜单,但问题是餐厅修改菜单并不是很准时,而且修改后又不一定能及时通知前台,导致有时会出现员工按照老菜单订餐,但实际上餐厅已经修改了菜单的情况。
第二个问题是午餐标准的问题,明显不是系统的问题,但用户还是提出来了,他们难道不知道不是系统的问题吗?为什么还要对我们提出来?是不是希望我们向公司领导反应问题?
软件有些问题,并不是软件本身的问题,而是管理的问题。要用好一套系统,必须配套相应的管理办法,很多管理的问题软件是不能解决的。第一个问题,要改善的话则需要加强对餐厅的管理,让他们及时送上更新后的菜单;而对于第二个问题,则需要公司检讨订餐标准是否合适了。
项目组遇到客户提出这类问题时,不要因为不是软件问题就事不关己,应主动分析问题并提供适当的解决方案,很多问题只需要在管理上稍微改善一下,问题就可以立马解决。
 
4)能不能提供多家餐馆选择?
 
为 什么用户希望选择多家餐厅呢?有人喜欢吃辣菜,有人喜欢吃粤菜,有人想吃粥粉面,就算是同一个人也会今天喜欢这个明天喜欢那个,如果能有多家餐厅可供选 择,则更能满足大家的口味了。大家能吃到自己喜欢的午餐,更有利于大家做好工作,从这点看似乎这个要求是满足需要的,我们应该予以满足。
要 实现这点,软件自然要费点周折去修改,但问题远远没有这样简单,管理上会变得麻烦很多:前台需要从多家餐馆获取菜单,要管理多家餐馆;财务要对多家餐馆进 行结帐;更麻烦的是,有些餐馆要订餐数量多才会送餐,如果哪天某餐馆点的餐不够多,还需要选择了这个餐馆的员工重新订餐。这样复杂的管理,软件应该如何来 适应呢?
看来如果寄望通过修改软件来满足这个要求,就会陷入一个“无底洞”,似乎无论怎样做都难以满足要求。实际项目中,经常会遇到这类问题,这时一定要认真地分析:
  • 深入思考修改要求背后的需要是什么。
  • 如果要满足该要求,在软件和管理办法上需要做什么改变,代价有多大。
  • 如果不满足这个要求,影响会很大吗?
中午饭是工作餐,主要目标是方便快捷,员工哪怕吃不到最想吃的,也可以选择吃第二、第三想吃的,中午餐的预算也不可能很大,没有必要将午餐搞得很复杂很丰富,故这个要求可以不满足。
如 果我们再动动脑筋,还是有简单易行的办法来解决这个问题的:员工可选择在公司统一订餐,也可以选择自己解决,无论哪种方式都享受公司的午餐补贴,如果在公 司统一订餐,则只能选择一家餐厅。这样员工如果图方便,又觉得统一订餐的那个餐厅合适,就可以选择使用订餐系统来订餐;如果觉得想吃点别的,甚至是自己带 饭,那就自己解决呗,反正午餐补贴是照样享受的。
 
6)能不能直接连到餐馆的网页上去看菜式?
 
为什么有这样新奇的要求呢?订餐标准才8元,这样的餐厅会有网页吗?
有时候用户会突发奇想,提出一些新奇怪异的要求,这时候要思考他的动机是啥了。由于客观条件限制,或者技术上做不到的,要予以拒绝。
为什么会有人想去看餐馆的网页呢?有可能是某些员工想了解一下餐馆的信息,好方便他和家人平时去撮一顿,如果是这样的原因,那只需要告诉他一些餐厅的网址就可以了。
 
7)能不能做口味分析和营养分析?
 
口味分析的意思就是希望系统能根据平时你的订餐情况,自动推荐你下次点什么菜。营养分析则是根据你订餐偏好,分析你的餐饮是否合理。这两个功能实在是太高级了,如果真的要做,那么系统需要增加数据挖掘的功能,这可是高技术含量的噢!
那到底要不要满足这个要求?这个要求其实已经超出了本系统的需要了,可以认为是对之前需要的升华,目前就算不满足也不会影响客户当前的使用,但如果要实现的话会导致项目成本上涨,对于这样的情况,可建议客户考虑项目的“二期”。
 
系统上线了,客户给你的挑战就会陆续而来,上述几个问题是实际工作中常见的几类问题:
  • 对于符合需要的易用性方面的要求,应尽量满足。
  • 有些问题可通过改善管理办法来解决。
  • 有些问题需要同时在软件和管理办法上做工作来改善。
  • 客户一时冲动的要求,可另辟蹊径解决。
  • 客观条件做不到的、技术上做不到的,应予以拒绝。
  • 超出范围的要求,可引导客户做第二期。
 
1.5 领导“突发奇想”
 
你好容易满足了大家提出来的各类要求,这回到领导“突发奇想”了!
事情是这样的,领导发现尽管有了订餐系统,但有时候某些员工因为请假或者外出工作,不能及时在网住上订餐,中午回到公司时没有饭吃。领导就萌生一个想法,不在公司的员工能通过手机短讯来订餐就好了!
于是领导对你下达了要求,让你带领订餐系统项目组完成这个新功能。
 
请你先思考这些问题:
1)领导这个要求的需要是什么?
2)如果要做这个功能,人机是应该如何交互?
3)要实现这个功能,要增加什么设备?软件要怎样修改?
 
你开始挥汗如雨地干起来了,这个要求可不简单啊!
1)要购买发短信的设备,要研究这些设备的开发接口。
2)手机屏幕这么小,而且只能通过短信来交互,如何选菜单、定餐、取消订餐等细节都需要想清楚。
 
手机订餐功能终于做出来了,但这个系统还时灵时不灵,问题是出在软件、硬件,还是中国移动都搞不清楚,领导大发雷霆,这样的小事情,怎么搞成这样?!
 
后来有人提出来,不在公司的员工,打电话回公司告诉前台吃什么,不久搞定了?
顿时全世界一片哇然,你一屁股栽倒到地上!
 
领 导要解决的问题其实只是要方便不在公司的员工能及时订餐,而领导提出来的通过手机来订餐是领导自己提出来的一个解决方案而已。我们的客户往往就会直接将他 们想像中的解决方案提出来,从而让你忽略掉他的真正意图,当按照客户的解决方案去做的时候,往往不能命中真正的需要,费时费力又不讨好。当提出具体修改要 求的人是领导级人物时,项目组更加是手足无措,唯领导命令是从。
作为项目组,任务时候都必须比客户更加清醒,不要埋怨客户的变来变去,绝大部分客户是理性和聪明的,只是我们不够厉害,不能分析出客户真正之需要。客户其实不是出钱让你按照他的要求去做,而是让你处于他的角度,提出高性价比的解决方案,满足他的真正需要。
原文地址:https://www.cnblogs.com/garfield211/p/2263178.html