提升需求技能发挥科技引领作用_第1页
提升需求技能发挥科技引领作用_第2页
提升需求技能发挥科技引领作用_第3页
提升需求技能发挥科技引领作用_第4页
提升需求技能发挥科技引领作用_第5页
已阅读5页,还剩12页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

提升需求分析技能发挥科技引领作用 提升需求分析技能发挥科技引领性作用【内容摘要】科技项目需求日渐旺盛,构建好业务、技术沟通的桥梁成为当务之急。本文通过平实质朴的语言,举例描述项目需求分析人员在与业务人员沟通的过程中,如何换位思考、挖掘业务本质需求,以业务思维掌握需求、以技术视角阐述需求,完成逻辑转化付诸开发;项目上线过程中循循善诱,引导业务人员迅速熟悉新系统的便捷功能,促进业务、技术深度融合,努力将科技地位从“基础性作用”、“保障性作用”成功提升到“引领性作用”!【关键字】科技项目,挖掘需求,循循善诱,深度融合,引领性作用目录一、项目需求获取全局观 -13-一、项目需求获取全局观项目开发初期,获取准确详实的需求是做好产品的基础。这就需要项目需求分析人员在与业务人员沟通过程中注意以下几个问题:1、业务人员需求阐述三阻力(1)易于放大需求:部分业务人员因为缺少计算机专业背景,对于软件产品设想的效果与实际不尽相符,这一点在需求变更过程中体现地尤为明显。需求分析人员需要掌握一定的谈判学技巧,欲擒故纵,适当描述项目的困难点和产出比,还原需求“本来面目”。(2)不解释需求背后原因:部分业务人员因为场合、身份、定位不同,可能会牺牲项目可操作性,提出较为宏观的方案。需求分析人员必须挖掘方案背后的本质需求,“仰望星空,脚踏实地”,将开发资源“用在刀刃上”。(3)需求零散、思考不足:相较于企业,国家单位中项目需求变更便捷简单,加上时间紧迫等原因,业务人员提出的要求有时缺少深思熟虑的机会。为避免重复工作、徒劳无功,需求分析人员可以协助业务人员分析项目需求,提高需求获取效率。2、尽量让业务人员“回忆作答”为避免主观臆断,能让业务人员回忆作答的,就不让其判断作答。判断作答过程中业务人员会考虑诸多因素,权衡利弊得失之后的答案与需求分析人员的初衷常常“差之毫厘,谬以千里”。“回忆作答”的措施包括构造具体场景让业务人员身临其境等。例如询问业务人员在不同场景下会进行的动作。如果结论一致指向“刷新朋友圈”的话,需求分析人员就应该意识到,如果从微信朋友圈推送一些科技方面知识,会大大扩展受众面和信息阅读产出比。3、优化需求问题提出方式需求分析人员必须认识到,让业务人员自身描述清楚需求是不现实的,因此需要联系心理学和历史学,优化需求问题提出方式。心理学是一门研究人类心理现象、精神功能和行为的科学,涉及知觉、认知、情绪、人格、行为、人际关系、社会关系等诸多领域,其目的是描述、解释、预测和影响行为;历史学包括“完全独立于人们意识之外的人类过往社会的客观存在及其发展过程”,“以史为镜,可以知兴替”。心理学和历史学在很大程度上可以帮助需求分析人员探知、理解业务人员心理,换位思考,挖掘项目深层次需求。(1)问题越细,得到答案的概率越高。遇到“量身定做”的要求时,“本软件与其他软件有什么不同”是将矛盾抛给业务人员的做法,而“本软件的优势和管理独到之处”的问法才能得到明晰需求。(2)理解业务人员心理。许多人喜欢在享用美餐前先拍照,这代表着骄傲需求超过了美食需求,值得借鉴的是,开发系统需要多从精神满足角度出发。(3)避免大、空、宽泛的问题。类似于“您的需求是什么”、“您对项目的期望是怎样的”之类的问题会让业务人员“无处着口”;遇到“增加可扩展性”的要求时,“往哪扩”是不负责任的问法,而“新的流程是否会产生变化”才是应该研判的。(4)选择不卑不亢的沟通方式。例如“为什么”的字眼携带否定含义,“想要什么样的结果”则相对平等;(5)适当“欲擒故纵”。可以在业务人员困倦或话语中断之时适当表达偏差的想法,在业务人员进行反驳的过程中掌握更为精确的需求。二、项目需求分析三层次want(方案级)、need(问题级)、win(人性级)图1项目需求分析三层次任何人提出需求的本质都在于“趋利”、“避害”,想要通过软件的开发便利自身工作生活。例如网银使用者通过用支付宝跨行转账省去跨行费用(“避害”)、用余额宝赚取利息(“趋利”);再比如微信使用者看到了出色的文章,但却因为专业性或冗长性看不懂、没耐心,使用微信“收藏”功能一方面没有错过好文章(“趋利”),另一方面又有充足理由躲避了研究该文章的痛苦(“避害”)。需求分析者必须理解业务人员需求,不满足于最初的“解决方案”,层层递进,询问到与IT、电脑无关的业务层面,从want(方案级)分析到need(问题级),进一步挖掘到win(人性级),为做好产品、发挥“科技引领性作用”做好铺垫。1、业务人员表示“新系统希望保持原界面不变”明确“界面不变”的要求只是want(方案级),清楚业务人员是想要“希望维持原操作习惯不变”的要求是need(问题级),而真正win(人性级)的需求是业务人员“抽不出大量时间耗在学习新操作上”。因此,本需求最终解决方案可使用“趋利避害”中的“趋利”,即找出原系统使用过程中最繁琐的地方,用系统新界面凸显的便捷功能打动业务人员,让业务人员认识到新系统的易用性,从而接受并使用新系统。2、库房管理人员提出发货时“增加可编辑功能”系统能够编辑将要发放的物品只是最初“解决方案”,本质上业务人员想要通过复制产品名称检查是否仍有库存,因此实现系统“自动判断库存量”功能则为win(人性级)需求和最终解决方案。3、商业网站业务人员提出“若合并订单则赠送积分”合并订单送积分只是最初的“解决方案”,本质上业务人员想通过赠送积分“减少物流费、降低成本”。“订单”不等同于“送货单”,如能合并多个订单为一个送货单才能真正降低成本,是win(人性级)需求和解决方案。4、腾讯(Tecent)的win(人性级)需求在需求满足层面上说,腾讯并非是“抄袭者”而是“创造者”,因为她将业务人员需求做到了win(人性级)。聊天对话框中的形象“袒胸露乳”,利用业务人员的羞耻心赚取购买虚拟衣物的钱财;给予会员相当多的特权,使得会员对于迥异年龄段的业务人员具有不同的吸引力;被他人强迫离开游戏房间后系统分出烂牌,使玩家心烦感觉不断持续,诱惑玩家投资充钻,etc。需求分析者在抓取win(人性级)需求后,可以主动创造出有利于项目实施的措施。如在中老年人群体中,“支付宝半价支付”的吸引力可能会让从来对电子产品不感兴趣的业务人员静下心来,逐步学会注册、登录、绑定、支付等操作,学会使用支付宝软件,达到项目实施目标。三、业务场景分析三要素问题(Why)、业务背景(Context)、解决方案(What)遇到小型、变更、优化类项目时,需求分析人员要澄清问题,清楚业务人员想要做怎样的项目(Why);构想项目运行场景、掌握业务术语、熟悉业务环境(Context);建议并确定解决方案(What)。1、问题(Why)进行具体问题描述,了解系统未开发时的情形,精确定义项目规模。2、业务环境(Context)初期设想业务场景,提前掌握项目相关术语定义,参考业务人员的描述迅速熟悉项目实施中的真实环境。3、解决方案(What)站在业务人员立场,设身处地,采用愈少愈好的技术术语与业务人员讨论项目实施后的场景,然后转化为开发语言。如从业务人员思维明晰“网上银行”分为借记卡、信用卡、基金等,而以开发逻辑转化之后的类别可能就会包括账户管理、基本交易、网上支付等模块。项目需求整理主要从价值主线、功能主线、细节等多个角度完成。结果如图一所示。值得一提的是,使用笔记本电脑进行现场整理或多或少会遗漏信息,建议采用忽略细节、笔绘草图的方法将工作重心放在问题细节上,并进行当场需求确认。图2项目需求整理图四、项目需求管理三技巧1、项目团队管理三层面项目需求管理之后不可避免地涉及项目团队的管理。团队管理主要分为三个层面:一曰人,二曰工具,三曰规划设计。人的管理包括外部召集优秀人才、内部施行绩效考核等;工具的管理包括采购管理软件进行规范化流程管理等;规划设计的管理指综合考虑诸多因素,对项目具体规划或总体设计。2、项目上线引导二方法(1)获取原项目“痛点”:痛点=持续性*厌恶度/可替代性“痛点”代表着项目使用时的非便捷、非人性化的功能模块。项目上线过程中,引导业务人员迅速熟悉、认可新系统是需求分析人员的职责。以原系统“痛点”为抓手,用情境串连在一起打动业务人员,就能获得业务人员对于新系统设计使用的认可。(2)项目预期管理:根据心理学规律,在管理预期之时,类似于涨工资策略,让业务人员“眼前一亮”多次的效果远远强于一次“喜出望外”的程度。因此可以通过抓取并实现业务人员的人性化需求点,让业务人员认可新项目。3、访谈提问三方式(1)分而治之:在与业务人员沟通的过程中,通过灵活巧妙的方式方法,将需求按照类别、层面分解为子模块,便于得到精准的答案。如把“增加便利性”分解为“业务流程”、“操作便捷”、“界面友好”等子模块。(2)表象、原因、决策:深入分析访谈内容,将有效信息归为表象、原因两类,通过原因还原表象,然后进行精准决策。例如业务人员想要提高通过软件提高“服务质量”,“对测量方式怎样要求”只看到了表象,“最近是否有投诉或私访”才是还原表象、精准决策的做法。(3)“一果多因”、“一因多果”思维:“一果多因”是多个原因导致同一个结果;“一因多果”是同一个原因可能造成不同的结果。例如,开会期间突然穿上外套属于“一果多因”,原因可能是温度较低、轮到自己发言、有事离开等等;感觉温度较低之后的举措则属于“一因多果”,结果可能会是调高空调温度、离开出风口等等。五、干系人的识别与分析1、干系人定义干系人指的是项目博弈过程中的“筹码”持有人,可能包括项目发起的出资人(业务部门)、拥有一票否决权的评价者(监审部门、财务部门、关务保障部门)、项目最终的使用者(一线业务人员)、其他(难以攻克的开发难点、难以保证的系统运维)等。只有在项目管理需求获取过程中认清项目干系人,尤其是关键干系人,抓住并运用好重要筹码,才能做好项目,最终发挥科技引领性作用。2、关键干系人分类(1)基层众:系统使用者往往是基层一线人员,基层的声音一定要多加考虑。如果考虑过少,项目上线的效果不免差强人意,甚至会导致众怒难犯的不良后果。(2)接口碍:业务与技术在融合、沟通的过程中存在磨合的过程,需求分析人员需要了解业务、掌握细节、发现问题、妥善解决。(3)假权臣:项目需求获取过程中难免会出现一些负面阻碍,如一些与实际不符的要求等。此时应通过赞美、转移要求重心、通过PPT方式实现要求等方式避免需求偏移。举例说明。项目需求获取时,得知项目发起人希望现场每一个窗口都能够做所有业务,但这样的要求引起了一线人员的抵触。此时可以一方面建议项目发起人通过中层管理者告知现场具体想法,让现场明晰新项目提出带来的良好效果;另一方面以通俗易懂的、一线人员易于接受的语言描述简化后的系统流程,提高一线人员期望值;最后待现场逐渐接受系统后上线运行,达到最好效果。3、干系人影响度分析图3干系人影响度分析六、架构流程设计双手段1、需求架构设计需求获取后,可通过图表形式进行架构设计。方式分为构件图(ComponentDiagram)、数据流图(DataFlowDiagram)、层次图(LevelDiagram)和列表(List)。其中,构件图主要用于描述各种软件构件之间的依赖关系,强调功能横向关系;数据流图从数据传递和加工角度,以图形方式表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,强调数据交换与共享;层次图侧重于表示系统在结构或功能方面的等级秩序,强调纵向分解;最基本的列表顾名思义,以表格为容器,装载文字或图表。图4架构设计呈现方式2、业务流程分析(1)分类:业务流程分析过程主要将流程分为4大类,即主业务流程、变体业务流程、支撑流程和管理流程。以会议管理系统为例。核心的主业务流程为业务人员从开会到结束的过程,延伸的变体业务流程为延续会议或变更会议室,辅助的支撑流程为业务人员在会议室内损坏了设备、欲投诉服务员等,控制事前事中事后的管理流程则为押金不足时的处理办法。项目需求分析过程中应以严谨的思维考虑现实中会发生的所有情况,无一遗漏。(2)优先级:根据优先级差异,将系统流程划归为主营、频率高的关键流程,主营、效率低的重要流程,非主营、频率高的有用流程,以及非主营、频率低的一般流程。流程是系统交付的最小单元,可以保证开发团队有效完成工作。需求分析时应以项目截止完成期限为依据,进行流程优先级的判断,抓大放小,完成分析。

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论