51Testing软件测试论坛
标题:
银行测试人员谈测试需求
[打印本页]
作者:
lsekfe
时间:
2022-11-23 13:22
标题:
银行测试人员谈测试需求
今天呢,想用故事说话,先看看啥叫用户需求挖掘。其实看完故事之后,我自己颇为震撼,请看。
故事一:
100多年前,福特公司的创始人亨利·福特先生到处跑去问客户:“您需要一个什么样的更好的交通工具?”几乎所有人的答案都是:“我要一匹更快的马”。
很多人听到这个答案,于是立马跑到马场去选马配种,以满足客户的需求。但是福特先生却没有立马往马场跑,而是接着往下问。
福特:“你为什么需要一匹更快的马?”
客户:“因为可以跑得更快!”
福特:“你为什么需要跑得更快?”
客户:“因为这样我就可以更早的到达目的地。”
福特:“所以,你要一匹更快的马的真正用意是?”
客户:“用更短的时间、更快地到达目的地!”
然而,福特并没有去马场而是发明了汽车,很好的满足了的客户的需求。
故事二:
某富翁想娶老婆,有三个人选,富翁给三个女孩各一千元,请她们把房间装满。
第一个女孩买了很多棉花,装满房间的1/2。
第二个女孩买了很多气球,装满房间3/4。
第三个女孩买了蜡烛,让光线充满房间。
最终,富翁选了胸部最大的那个。
大家应该都听过这两个故事,告诉我们要通过现象看本质,从收集起来的数据中发现新的需求。就好比,你问女票情人节想要什么礼物,她们很可能会说“不用送了”、“随便吧”,但如果你真的照办的话,那就GG了...
所以,了解用户的真实需求非常重要!!! (敲黑板···)
一、到底什么是需求?
百度
百科是这么说的,需求(Demand) 是指人们有能力购买并且愿意购买某个具体商品的欲望。
在我的眼中,指的是人们真正想要解决的某种问题。
二、什么是
需求分析
?
我的理解是,对要解决的问题进行详细分析和深刻的理解,弄清楚产生该需求的根本原因和具体的要求,以及预期的结果。
三、需求来源于哪里?
可以分为老板需求、公司战略、用户需求、市场需求、同事反馈、竞品分析、头脑风暴。
1)老板需求:优先级最高,能满足尽量满足。但要积极思考老板提出这个需求目的是什么、有什么意图、要做些什么,结合数据和制作图表进行分析来确认需求的合理性。
2)公司战略:需求与公司战略不一致很危险,一致才能走的更远。比如在起步阶段,要关注核心功能的实现、在发展阶段,要进行功能扩展和完善、在迭代阶段,要注重用户体验。
3)市场需求:在特点的时间、地点、特定人群的共同需求。就像故事所说,人们都需要更快更方便的出行方式。
4)用户需求:最直接的需求来源,是产品功能的直接使用者。因为有时候用户也说不清楚,所以要多问为什么,要比用户更了解他们想要什么。
5)同事反馈:同事也是高级用户,在团队工作中不可缺少的一部分。比如通过EXCEL导出产品或
技术
参数的明细,便于核对,确保参数的正确。
6)竞品分析:知己知彼,才能百战不殆。为什么人家会有这个功能?有什么特色或吹嘘或借鉴的地方?
7)头脑风暴:放空思绪,碰撞创造性的创意。人们需要交通工具更快、更载人,那么头脑风暴可能想到交通工具的舒适性、豪华感、身份象征、全自动等等。
四、需求会变化吗?
个人认为需求会变化正确,需求不会变化也正确。
为什么需求会变化正确。因为在需求分析阶段不可能解决全部的需求问题,人们在考虑问题总有不全面的时候,俗话说三个臭皮匠顶个诸葛亮,最好的方法是将各方意见综合在一起,尽量减少遗漏的点。所以在设计&开发&测试直至交付客户,都在不断与客户沟通,纠正需求理解的偏差。通常适当的需求变更是可以接受的。
为什么需求不会变化也正确。以交通工具的需求举例,从古到今,人们最初依靠双腿,后来驯服了马、发明了自行车、三轮车、汽车、轮船、火车、飞机等等,其实说到底,是用户对解决方案的期望值在不断变化,而需求一直存在并且没有变化。
五、如何获取需求?
可以分为政策调整、动态资讯、行业数据、用户调研、客户反馈。
1)政策调整:关注行业相关的政策调整,并思考其对现有功能的影响。
2)动态资讯:关注行业资讯,思考行业动向和趋势,及对产品的影响。
3)行业数据:利用行业数据报告、行业数据统计工具获取需求。
4)用户调研:以用户为中心的设计方法论所进行的活动,要走到用户当中,深入了解他们在具体场景下的想法和感受。
5)客户反馈:了解用户在使用产品或某功能的时候,遇到的问题以及一些之前根本没考虑到的需求点。
露出来的冰山,就好比用户能清晰、具体、明确表达出的需求和想法。水面下的冰山,就好比用户无法表达的愿望或未知的需求。所以,获取到需求后做好需求挖掘,能让决策更有说服力。
六、需求讨论的小妙招
需求讨论,是需求分析中最重要的一环。对分析人员的理解能力、沟通能力、与人交往等各方面要求比较高。那么,有哪些工作是可以提前准备、且能提高会议效率、还能体现我们的专业度能提升在客户心中的地位呢?
1)对需求进行深度理解、运用我们的专业知识或借鉴其他项目组的做法,提供比客户的需求更加合理、可操作的解决方式。
2)弄清楚客户方有哪些决策,谁是需求提出者、谁是决策者、谁在支持我们,而谁 又自觉不自觉的阻碍我们。
3)对于领域专家,需要谦虚慎重、相互尊重、慷慨的交往。
4)要结识能够帮助我们的人并保持适当的谦卑,因为我们要依靠他们去学习业务知识和收集需求,为将来需求分析提供素材。
5)确定合适的时间、合适的地点、通过合适的形式与客户讨论,并至少提前1日发出会议邀请。
6)可以将业务人员划分为多个业务组或按模块划分,因为业务人员自身局限,不可能对全部业务领域的细节全面掌握。
7)讨论中尽量使用业务术语,因为客户不一定要懂得
软件开发
的术语。
8)提前了解客户的业务和目标,准备好讨论的侧重并列出疑问。比如换系统,那么了解旧系统,有利于交流可改进之处。
七、我的需求分析的方法论
可以分为三大部分,首先是需求梳理,其次是需求分析,最后是需求评审。
1)需求梳理
a)建立需求池(通过EXCEL表格或软件
记录
下收集到的idea或功能,并初步评估优先级)
b)评估需求的合理性(充分与客户沟通、结合同行业做法或实际业务场景,找出可实现且有价值的需求,过滤掉那些无意义或者是暂时可以不实现,无关痛痒的需求。那么如何区分需求是否有价值?那就得看需求分析人员需要对产品的愿景和设计理念的理解、以及工作经验围绕着最终实现的功能去筛选。当然,如果收集到的需求数据无法满足现有产品功能的设计,也可以提出新的需求。比如用户要做一套账户信息浏览交易,那么需求分析人员提提顺便通过EXCEL清单或PDF对数据导出的功能。)
c)需求的划分(看需求属于新增的功能还是先有功能优化,属于in-scope还是out-scope)
2)需求分析
a)对现有逻辑的影响(也要考虑潜在的影响,比如将来新增了客户证件类型的种类,现有需求会有什么样的影响,如何设计方法能更提高可扩展性、灵活性)
b)需求方案的设计(新的需求可能设计新的流程、新的功能,设计方案时要考虑系统的可复用性、可扩展性)
c)多角度思考(很多时候一个需求不是仅仅涉及开发和
测试
,当实现之后更要市场、运营等部门进行配合,所以要全面思考给处合理化的建议和方案。)
3)需求评审
a)完成需求文档的编写,内部评审通过后转用户方审核,并帮助开发和用户解答需求中的问题。
b)跟踪需求开发,测试和验收阶段的问题,确保按时交付并高质量的上线。
c)复盘整个需求,有什么样的收获、能尽善尽美的地方、或在哪个环节耗时比较多。
作者:
bellas
时间:
2022-11-25 14:12
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2