SERU-需求捕获
2021-04-26 15:02:24 8 举报AI智能生成
SERU-需求捕获是一种系统化的方法，用于确定、记录和跟踪项目或产品的需求。这个过程通常包括与利益相关者的讨论，以理解他们的期望和需求，然后将这些信息转化为具体的、可度量的目标或特性。SERU-需求捕获可以帮助团队确保他们正在构建的产品或服务满足用户的需求，同时也可以帮助避免在项目后期出现重大的变更或修订。这种方法强调了需求的重要性，并提供了一个结构化的方式来管理这些需求，从而提高项目的成功率。
作者其他创作
大纲/内容
二、 需求捕获
需求捕获常见问题
捕获范围不足：认为客户要求就是软件需求，不注重对业务知识（业务事件、业务实体、业务规则）的捕获，从不主动问为什么
缺乏计划性：无准备（没有预先对问题、时间、访谈人员进行计划），捕获过程随意、走过场，造成需求捕获的时间利用率低
缺乏科学性：将宏观层次问题与微观问题混在一起，没有做到定向、聚焦
捕获对象不明确：很少主动找到合适的被访谈者，而是客户占据主动
捕获手段不足：认为只有用户访谈和调研会议才是有效手段，却忽略了在不同场景下可以通过组合不同的捕获手段达到更好的效果
要解决的问题
计划性：体现在捕获对象、问题、时间的计划
科学性：体现在如何有效的选择合适的捕获方法
需求捕获的策略
需求捕获应该主动的：问题的关键在于需求分析人员是否善于掌握主动权，是否能够根据每次访谈的对象制定相应的计划
需求捕获应该是聚焦的：善于聚焦访谈话题是需求补货人员成功的关键
破解需求的冰山模型：善于将三层用户需求都挖掘出来
用户意识到的问题：用户通常遇到的困扰或者能够设想到的功能
无意识的需求：充分理解用户的工作场景，具体的方法就是加强对业务知识的捕获
未梦想的需求：需要需求分析人员充分理解业务并选择合适的技术方案，创造出用户未梦想到的功能
破解阻碍需求捕获的心理现象
言过其实心理
用户说出或提出的流程或需求过于理想化、规范化，无法真正落实或实施
用户在表述时通常十分肯定，讲述十分顺畅，没有什么打断（因为创造不需要思考，回忆才需要）
验证：访谈结束后再找一个相关的用户进行访谈，如果获得的信息不相同，就说明遇到了问题
差异展现法：将不同用户代表的访谈结果进行整理，在系统开发开始前展示给中高层管理人员，就如何解决达成共识
瓶颈分析法：在流程执行过程中的瓶颈进行分析，例如：时间瓶颈、人员瓶颈等，以避免流程无法顺利运转起来
越俎代庖心理
在企业中，往往“懂得越多的人就越忙”，而有些企业中会有一批不算太忙（同时也懂得不多）的人经常会在需求捕获时侃侃而谈（不论是不是自己负责的流程，都会津津乐道，按照自己的理解、想象进行肯定的描述），为需求捕获带来很大的负面影响
如何避免/改善该现象？
识别正确的被访谈者
正确分为两层含义
问题的层次是否正确：高层问宏观，中层问脉络，基层问细节
用户代表是否正确：根据当前问题所针对的业务环节是由谁负责的，谁就是最佳用户代表。执行者往往就是回答问题的最佳人选
实际情况：捕获过程中很难找到正确的人，或者他没有足够的时间
继续访谈“越俎代庖”类人群，并将访谈结果按照“业务脉络”进行分类，将不属于此类人群的部分标识出来，并确定谁是“执行者”
在后续访谈安排对“执行者”的访谈，由于有了一定基础并整理出部分问题，时间可以大大减少
如果“执行者”连访谈时间都没有，就通过需求验证的手段来参与，或是文档、评审会
非正事心理
被访谈者没有将这次访谈当做是一件优先级很高的事情
潜在因素
客观因素：办公室或者非正式环境是一个很容易受干扰的环境
主观因素：非计划的事情通常会被看做是低优先级的事情
解决策略
访谈应尽量避开办公室
提前做好一段时间的访谈计划（访谈人、访谈要点），由对方统一安排
抗拒心理
主要发生在基层，因为信息化系统对基层而言效益并不明显，而且还经常会使其工作量增加，且带来培训负担，就会使得基层对信息系统的敌意转化成对需求分析师的敌对
化敌为友：弄清楚原因，缓和基层对信息系统的敌对情绪，倾听对方抱怨是有效手段之一
推卸责任心理
信息系统在企业中并没有被广泛认同，很多人会抱着“事不关己高高挂起”的心态
工作场景介绍：和用户聊从事哪些工作，是如何进行的，然后逐步过渡到存在什么问题、困难等，就会得到需求
不要忽视对变更可能的捕获
“变更可能”是需求文档中一个很重要的组成部分，在需求捕获时要加强这方面的意识，对于大概率发生或可能发生的变更要在文档中具体描述
解决策略
先收集所有可能的变更类型
最严谨的办法就是对历史项目、当前项目的变更进行分析、归类，并进行排名（参考帕累托图）
最实用的办法就是和开发人员进行一次访谈，了解他们最惧怕哪方面的变更，哪些变更会导致比较高的工作量
最笨的办法就是“前车之鉴后事之师”，在项目中不断的总结哪一类的变更较多，在后续需求捕获过程中引起重视
再对获得的最常见、最可能出现的变更类型整理出一些需求捕获时可以使用的问题
案例
需求协商
在需求捕获过程中经常会遇到需要协商的地方，例如：需求的必要性、优先级、互相让步等，都需要需求分析人员与用户进行“沟通谈判”，保证需求范围不蔓延或为项目争取时间或利益
策略
找到解决方案背后的问题
用户通常会说：“我想要...、我希望...、我觉得...”等，告诉需求分析师想要按照自己想法实现的东西，更偏向说“解决方案”，而不会直接说出“问题”，这对于需求捕获过程显然会造成障碍
善于问“为什么？”搞清楚用户为什么想要这个东西，才能知道用户的解决方案是否合理，并且问题与解决方案一般都是一对多的关系，要坚信选择解决方案的最佳人选是需求分析师，用户代表需要做的是将问题说清楚
共赢性谈判
需求分析师和用户在项目中都会有自己的利益和立场，且是不同的。有时只有抛开立场，追求满足大家的利益诉求，才能更好的进行需求捕获
抛开双方立场的核心在于问出对方的立场，搞清楚对方为什么一定要这样做，了解对方的利益诉求，就又可能找到折中的方法
转化技巧
将未知问题转化为已知解问题
将不熟悉的业务场景转化为熟悉的或者转换成已经实现的产品解决方案
相对重要转化为相对次要
用户有意或无意地不指定优先级，或将所有的优先级都定义为最高级时，将上一层次领导提出的、他也知道的需求来比较，如果该需求不是很紧急，通常他自己就会放弃。如果这个需求对方一定坚持，那就说明该需求是不可或缺的
转换关注点
核心在于利用事物的多面性，引导用户代表向有利于需求分析师的关注点进行思考，从而为自己赢得机会，关键技巧在于“创设场景，让用户从你引导的角度去思考问题”
隐喻
多打比方，用用户熟悉的事物来解释技术的问题。隐喻能使沟通更加顺畅，建立良好的沟通基础
需求捕获的主要方法
6种常见的需求捕获方法
用户访谈
用户访谈的特点
优点
直接有效，形式灵活，交流深入（有文字、声音、图像）
缺点
占用时间长：访谈人数较多，且语言交流会占用大量的时间
信息存在片面性：用户代表容易各执一词，导致收集的信息无法代表所有用户的想法，从而导致需求偏差
用户访谈的类型
高层管理人员
对高层管理人员的访谈结果是对访谈中层管理人员的指导
目标：探讨系统的目标及范围
中层管理人员
对中层管理人员的访谈结果同样是对操作层访谈的指导
目标：理清需求的脉络信息
操作层
目标：填充需求的细节
技术团队
对技术团队的访谈是在需求分析师无法确定技术是否可行或是实现成本是否过高时进行的
目标：论证解决方案的可行性
用户访谈的时间计划安排
访谈时长
一次用户访谈的时间应该控制在1小时之内，如果时间不够用可以中场休息或安排下一场访谈
4个阶段
开场白
任务：陈述预先的理解
占用时间：5-15min
说明：聚焦本次的话题，明确访谈的范围与层次
预先计划问题
任务：寻求提前计划的问题的答案
占用时间：25-30min
说明：主体工作，保证问题不遗漏
即兴问题
任务：扩大、补充需求信息量
占用时间：20-30min
说明：不宜过度扩张，注意话题聚焦
总结
任务：总结访谈内容，进行需求验证
占用时间：5-10min
说明：需求分析师向被访谈者叙述需求结果，保证理解正确
注意事项
避免“非正事心理”，提前计划预约并避开办公室或易受干扰的环境
用户访谈的记录工作
快速记录，每当访谈者陈述完一段话之后，就用自己的话简要的复述一下，保证达成双方共识，有必要的情况下可以进行录音
用户访谈的沟通技巧
制作访谈问卷并事先发送给被访谈者
在访谈之前整理一份访谈计划，罗列出要问的问题，然后预先发给被访谈者，以便对方能够更好的做相关的资料准备
21原则：发送访谈计划时，遵循时间规则：2天前、1周内
把握语言节奏
交流模式：问问题，听取回答，反馈理解，少说多听
说话占时比：需求分析师说话时间应控制在访谈时间的1/3以内
表达要点
简洁明了说明问题：沟通使用短句
不要问长问题：将长问题拆解为多个递进的问题，同时避免多个问题一次性问出
有效结合不同的问题类型
问题类型
封闭式问题（判断）
半封闭式问题（选择）
开放式问题（简单）
优点
让被访谈者感到更自在、更感兴趣，访谈者也容易措词
能够获取到更丰富的信息，允许更多的自发性
缺点
容易产生太多不相干的细节，访谈过程容易失控
可能需求花费大量时间才能获取到有用的信息
容易让需求分析师看上去没有准备，并可能让人觉得没有实际的目标
使用时机
访谈过程中，开放式问题尽量作为访谈的问题主题
访谈开场或出现僵局时，使用封闭式或半封闭式问题来缓解
在需求使用封闭式问题时，尽量转化为使用半封闭式问题，减少用户诱导
善于安排问题出场顺序
针对不同的场景结合使用不同问题类型的问题调节沟通氛围
金字塔结构
当被访谈者需要对这个话题进行预热时，采用金字塔结构
想结束当前话题时，采用金字塔结构
漏斗结构
当被访谈者对当前话题有情绪，需要自由的表达情绪的时候，采用漏斗结构
菱形结构
金字塔结构与漏斗结构的结合
注意沟通的细节
善于使用“模型”进行沟通（但不要过于注重形式，浪费时间且容易给用户带来压力）
善于倾听、注意访谈礼貌，避免传递不友好的情绪给用户
说话语气平和、情绪和善
不随意打断用户的话题，如果一定要打断，及时将话还给对方（你刚才说到...了）
注意力集中，目光注视用户
不懂就问：在沟通时很容易有业务术语需求分析师不了解，这时要勇于张嘴问“你刚才说的是什么？”
善于察言观色：用户在沟通时的面部表情、语气、肢体动作等都可以反映出有效信息
用户语气极快，逻辑清晰
用户对该部分工作做十分熟悉
用户描述的信息可能是理想化的制度
语速较慢，中间有很多停顿
用户对该部分工作不熟悉
传达的信息不经常考虑，可能不是直接负责人
描述的业务信息很容易多变，需要注意
突然改变语气、脸色
话题比较敏感
涉及公司政治、利益或个人利益
不要遗漏问题
将预先计划的问题记得问完并逐一得到解答
在结束的时候应该询问“你认为我还应该了解什么问题吗？”、“你有什么问题要问我吗？”等
用户访谈计划
计划时间、人员
提前与用户方联系人联络，让用户房联络人进行访谈人员、时间安排，
制定访谈安排计划，表明：访谈主题、要点、期望部门、备注
计划内容
针对不同层次的访谈对象，针对性的执行访谈内容与问题
高层
罗列出部分问题、机会点
准备相关的项目实施案例
列举部分潜在解决方案
中层
罗列出相关的业务事件清单
收集与业务事件相关的信息资料
准备一些业务事件的关键问题点
准备一些相关的管理控制点
操作层
罗列出相关的业务活动
针对业务活动的问题点、需求点
罗列出相关的业务实体、规则
技术
罗列出要解决的问题
整理出理想的解决方案
标识出关键的疑问点
用户调查
目的
用户调查是与用户访谈相关的一组技术，可以很好的解决用户访谈带来的需求片面性问题，对于需求捕获而言，采用先访谈、再调查的方法更加合适
使用时机
片面性矛盾比较突出的时候使用
片面性突出的主要原因
存在大样本用户：在操作层尤为明显，由于人数较多不可能一一访谈，就需要使用调查进行补充
存在跨地域用户：岗位相同、人数不多但散布于不同区域，需要解决的问题也是不尽相同的，就需要通过调查事先捕获矛盾点、差异点
用户调查问卷设计要点
注意问卷的篇幅与布局
不宜过长（20分钟以内，应该在1-3页之间）
问题按照从易到难进行排序
问题排列注意业务逻辑相关性，不要有太大的跳跃
注意问题类型的选择
尽量避免使用封闭式问题，此类问题具有很强的诱导性，用半封闭式问题代替
C现象：将大样本结果放在半封闭式问题的中间（人的从中心理）
D现象：如果用户问卷答卷大量落在D选项，就应该判断是否是由于Ｄ现象（大部分人认为最后的实在最好的）心理干扰了调查结果
D现象：如果用户问卷答卷大量落在D选项，就应该判断是否是由于Ｄ现象（大部分人认为最后的实在最好的）心理干扰了调查结果
应该有一定比例的开放式问题，尽量让开放式问题跟随在相关半封闭式问题之后
开放式问题要保持简单，给用户留下1-2行的空间即可（太长用户容易产生压力）
用户问卷的分析要点
筛除无效问卷：白卷或答案大量相同的问卷应该筛除
对问卷人进行分类：按照问卷者的职位、年龄段、从业时间、地域等方面进行分类，对每类人填写的问卷进行数量统计
文档研究
目的
数据需求通常比较琐碎、趋于细节信息，因此用户不会都记在脑子里，这些信息通常都在文档资料中
缺点
文档的量通常都很巨大，需求分析师容易掉入“文山书海”不能自拔且文档可能有“信息滞后”
使用要点
注意文档的“历史性”带来的信息过时，在收集资料时尽可能让用户正在使用的、带有真实数据的样本
不要让用户一股脑的将资料塞给需求分析师，要主动标识出用户应该提出的文档，具体做法：根据流程分析的结果标识出各个业务活动所要处理、传递的表单、产生的数据、依据的文档与规定，形成列表提供给用户
原型法（情节串联板）
目的
强调借助原型来加速需求捕获过程
优点
对用户友好，有界面、交互，对用户界面前期就进行了评审
缺点
花费时间较多，使得需求捕获速度大大降低
使用时机
用户对信息系统是没有直观认识的，在用户无法理解时，需求捕获人员就可以通过情节串联板技术来帮助用户消除盲区，达成共识
不过尽量对那些业务很复杂或者很重要的部分进行
不过尽量对那些业务很复杂或者很重要的部分进行
使用要点
以业务场景为线索
罗列出业务事件清单，并针对每一个业务事件（场景），按照业务流程将这些工作的业务步骤列出来，让用户带着业务线索来审视系统的操作过程，看看是否合理、是否满足需求，让用户思考起来
注重交互过程
交互不仅指单个页面的静态或动态效果，用户更多关系的是界面的流转过程、交互过程
现场观摩
优点
百闻不如一见，能够对需求与业务流程建立直观的认识
缺点
消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真
使用时机
需要对复杂流程建立更深入的了解时、在对关键任务理解不清晰时、在很多东西用文字表述不清时，都是使用现场观摩技术的最佳时机
使用手段
任务示范：要求用户针示范如何执行特定的任务
优点：易于发现异常的、关键性的任务
缺点：容易“示范”失真（领导在场时，可能不是日常执行情况），耗时
使用要点
避免失真，进行时不应大张旗鼓地进行，容易出现“观摩”失真、“示范”失真的现象，客户会受到这些信息的影响，而呈现出一些理想化的状态
努力总结出整个任务的步骤、找到脉络，这可以借助于“任务卡片”，不要走马观花
有条件的情况下，建立可重复观摩的场景（将观摩的过程录制下来，以便其他开发人员在需要的时候能够继续观摩）
当学徒：与用户在一起通过用户指导完成一些工作来学习，适用于用户无法详细解释他们在做什么、如何做
联合开发
优点
客户、开发人员直接的头脑风暴，是击破需求盲点的关键手段
缺点
成本高，缺乏控制就是一次闲扯大会
使用时机
双方对需求都还有盲区的时候是使用该技术的最佳时机
项目启动初期：对系统的目标和范围可能会比较模糊，一起来讨论，使得目标和范围更加明确，为需求工作、开发工作指出方向
关键主题域：在系统中经常有一些很关键的部分，它是整个系统的价值核心，这时组织此类的活动也可以有效地提高需求的质量
使用要点
会前有准备
准备工作
理念上达成共识：所有参与联合开发的人对这项工作引起重视、积极参与（可以通过正式文件或争取高层领导的认可等形式进行）
确保真正的stakeholder参与：确保与议题直接相关的人员参加，不要有一些关联的都请
准备好相关资料：要使得会议更加聚焦，就必要保证所有参与者提前阅读过相关资料，因此要事先收集好相关资料，并按照“21原则”分配给大家
准备好后勤保障：会议后勤保障越专业，就越能够引起参与者的重视，使得参与者更专注、积极（茶水、投影等）
会中有控制
控制不是指选一个职位高的人来做会议的支持人，会议要控制的是气氛与进度，要学会使用会议组织技巧
会后有总结
切忌形而上学的会议总结，对软件开发没有指导意义的总结都是废话
总结方法
尽量安排一位会议纪要员进行参与者观点记录（会议纪要员必须有技术背景和良好的理解能力）
按照议题分类将参与者的观点以条目式的形式记录下来
将记录下来的观点罗列出，由参与者对其中价值比较低的进行筛除，将剩下来的观点进行分类整理
对每一类观点进行优先级投票，将生成结果发给参与者
需求捕获的记录工具
任务卡片
适用场景
适合业务活动级的信息收集与整理
主要要素
基本信息
任务
该业务活动的命名，要使用业务术语（用户要能理解）
目的
该业务活动的工作意义，说明的是意图而不是动作
触发
进行该业务活动，系统要判断的前置条件
前提
触发该业务活动的时机、场景，说明了业务前提
频率
任务发生的频率是（属于非功能性需求）
关键情况
一些十分特殊的场景，系统需要进行专门处理
子任务
该业务活动的具体业务步骤，相当于用例的基本事件流
任务变体
该业务活动的变体与异常处理，相当于用户的扩展事件流
问题点
在子任务和任务变体栏中增加问题点描述，通常是引出解决方案的要点
方案示例
针对问题点，系统需要实现什么功能，以便验证这些解决方案是否能够解决用户提出的问题点
场景说明
适用场景
用户或者需求捕获人员很难总结出子任务、任务变体，因此就需要对任务执行过程进行抽象
主要要素
让用户将任务执行过程描述清楚记录下来，然后由需求分析师根据这些信息来抽象整理出子任务与任务变体
小结
主动
计划
科学
0 条评论
下一页
