《有效需求分析》(前10章)阅读笔记
有效需求分析(前10章)
前言
需求分析思想:
需求分析最重要的是思维方式,要站在用户的视角展开,即“业务驱动”思想,关注问题而非方案。
以变更/优化型需求为例,针对用户提出的需求,首先要判断是方案(直接告诉你做什么)还是问题(告诉你他实际想解决的问题)。第一步就是澄清问题,2W1H,明确谁的,什么问题,并知道遇到该问题当事人目前是怎样解决的,若有概念的不确定,需明确;第二步了解该需求具体的使用情况,2W1H(谁,什么时候,怎样做),业务术语澄清,并了解该需求的使用频率及满足不了的后果,涉及到哪些人;第三步,提出建议,分别列出可行方案,成本比较,提出建议,对用户而言的优缺点等,并可简单问一下有无其它类似需求。
第1章 目标/愿景分析
首先说明预期高于现状才会产生需求;进而在预期与现状的差距中寻找问题和机会以确定目标;并提示在目标描述时应避免空洞无物、无法验证,可以采用场景化描述法,将目标真实、易理解、可验证、有感染力的描述出来。 接下来以具体案例说明如何分析目标,访谈问题、研讨机会、定义问题和机会、分析问题并确定解决方案,每个步骤都提供了具体步骤和方法。 最后以问题卡片的形式,指导大家如何进行实际操作,非常实用。
第2章 干系人识别
干系人是项目中涉及到的所有人,而我们在做需求分析时需要识别出关键干系人。
首先,根据目标识别关键干系人,可通过客户的组织架构去分析,在该过程中需要注意的是,干系人的影响度和与项目相关度要综合权衡,来正确识别关键干系人,从而正确认识需求的优先级。
其次,根据风险识别其他关键干系人,比如基层用户、具有一票否决权的专家、研发人员等根据具体风险,都有可能成为关键干系人,但绝不是关键干系人越多越好。在涉及基层用户时,可以采用“预期管理”策略,上线前降低预期,创造上线后部分超预期的效果;在有专家参与时,若因专家的过度参与使项目受阻,需要从专家的关键需求入手,做充分沟通,找到双赢的解决方案。
最后,生成干系人列表。
第3章 干系人分析
识别出关键干系人之后,接下来就要选择合适的代表进行调研,分析他们的关注点、阻力点,以及满足关注点、避免阻力点所需的功能、非功能需求。而阻力点,也就是对干系人带来的负面影响,很容易别人忽略。
首先,选择干系人代表,要具有代表性(能够覆盖各种差异的干系人)和典型性(能代表比较大比例的同类干系人),从职业角色(组织中的位置和核心工作职责)、个人特点(专业背景、职业经历,以了解其管理偏好、思考逻辑等)、联络信息(联络方式、工作时间、沟通方式偏好,以便选择最合适的沟通时间和形式)三方面了解信息。
其次,访谈干系人,分析关注点。采用“分而治之提问法”制定出访谈提纲,列出要访谈内容。可以基于KPI、工作主题、工作阶段三种角度进行分解。同时在分析关注点时,不仅要关注干系人希望通过系统解决的问题,还要关注系统可能给其带来的负面影响,描述分析结果时,从why(关注点/担心点)、how(功能需求)两个方面来描述。令外在写why时,要把握三个写作要点:一是从业务角度写,二是要以结果态写,三是必须体现价值。
最后,干系人关注点整理。有时干系人的关注点存在冲突,我们需要识别冲突并提出解决方案。并建立“干系人档案”。
第4章 业务子系统划分
对于比较复杂的系统,为了控制业务分析的复杂度,通常要对系统划分为各个子系统。在划分过程中我们要跳出技术实现角度划分的思维定式,从业务角度进行划分,才能更好的与用户沟通,提升用户的参与度。
首先,根据系统特点,选择合适策略,进行业务子系统的划分。相对复杂的新系统,可选择业务/职能分解(内部管理系统)、产品/服务分解(外部服务系统)、双维度划分(复杂业务系统)、关键特性划分(计算机域系统)等不同方式;业务简单,用户群单一的无需划分;原系统基础上做二次开发的,明确新增哪些子系统,对原有子系统的影响,原有子系统需做何修改即可。记住划分不是目的,而是手段。
其次,标识接口,确定关系。所谓“哪里有分解,哪里就有接口”,在已划分子系统的基础上,明确本子系统需要其它子系统提供什么服务;能够提供给其它子系统什么服务;这些服务谁提供,谁使用;哪些是现有的,哪些需修改,哪些需开发等。
再次,通过层次图(强调纵向分解)、构件图(强调横向功能,服务调用关系)、数据流图(强调横向数据交换、共享关系)等,将各子系统及之间的关系呈现出来。
最后,通过文档将分析结果记录下来。
第5章 业务接口分析
所谓“哪里有拆解,哪里就有接口”,划分完子系统之后,就要对彼此间的服务关系(业务接口)进行分析。进入正题之前,先区分两个概念:业务接口和系统接口。这是不同的概念,一个业务接口可以由多个系统接口实现;内容不同,业务接口分析,只明确why(用途与业务价值)、what(交互过程)及约束,不涉及how(解决方案)。业务接口分析步骤如下:
首先,明确接口的用途与业务价值。需厘清三个问题:
1.哪个子系统合适实现该接口;
2.哪些子系统会用,实现什么价值;
3.使用频率是怎么样的。
其次,细化接口的交互过程。在该过程中,会用到两种工具,一是时序图,呈现出接口的交互过程,二是数据词典,细化的定义出每次交互过程中数据包的构成情况。
接下来,确定接口设计约束。首先看客户的技术管理部门是否要求使用特定的数据,通信协议,或者遗留系统带来的限制;其次对数据传输、数据查询,加解密方面的性能要求进行分析,除此之外,还应考虑系统的部署环境,使用者特点等带来的设计约束。
最后,形成记录文档。
第6章 业务流程识别
企业或组织的核心价值在于相应外部客户的服务请求,通过一系列的写作来满足服务请求,为客户带来价值,同时为企业或组织带来价值。也就是说业务流程的起点是这些外部服务请求。
6.1 端到端流程
- 完整:所谓端到端,实际就是服务请求从提出到满足的全过程,也就是判断一个流程是否完整,应该站在服务请求的立场,判断服务请求是否满足或者被拒绝。
- 边界:识别业务流程时涉及两种边界。一是职能边界,也就是跨越了我们未涉及的业务领域;二是系统边界,也就是不属于系统关注的部分。
第7章 业务流程分析优化
做好业务流程分析,首先要了解两个方法:
7.1 分层业务流程
业务流程正常可以分为三层,第一层组织级流程,描述部门间的关系,供决策者阅读;第二层是部门级流程,岗位间协作关系,供管理层阅读;第三层是个人级流程,描述一个岗位的工作步骤。判断原则有两个:一是 是否与协作无关;二是 是否不是独立可汇报的单元。
7.2 业务流程八要素
五个基本要素:分工、活动、协作、产物关系、分支
三个管理要素:审核、规则、异常
第8章 业务场景识别
识别业务场景,目的是让用户产生共鸣,实现“用户为中心”的需求获取与理解,具体技术表现为用例和用户故事。
用例即业务场景、使用场景,比如同样是增删改查,不同的用户就会有不同的使用场景,比如图书管理员需要新增图书时可能有两种情况:办理图书入库、办理遗失图书返库,那我们如果简单定义成新增图书就不如定义成办理图书入库、办理遗失图书返库更容易被使用者接受。
用例也是有边界的,那么多大才算是合适的用例呢?我们把这个边界称为粒度。实际上一个用例就是一个完整的业务场景,应该是独立的、可汇报的、可暂停的单元。在一个信息系统中,业务流程是指不同岗位之间通过协作满足外部服务请求的过程;而业务场景则是以某岗位为主完成的、相对独立的、可以汇报的业务活动。因此,从某个角度而言,粒度是由组织分工决定的。
用户故事,就是让用户或用户代表使用固定格式描述其需求,具体格式为:“作为xxx(角色),希望通过系统xxx(解决方案、功能要求),以便达成xxx业务目的、要解决的业务问题”。如果用户故事过大,还需要明确粒度的标准,对故事进行拆分。
第9章 业务场景分析
识别出业务场景后,接下来就是进行场景分析。
先站在用户的角度,对场景进行描述;
然后采用“场景——挑战——方案”的过程进行分析。
一般先从用户视角将场景进行细化,形成事件流,然后站在用户角度逐条分析会遇到哪些问题,最后针对问题,寻找解决方案。
第10章 管控点识别与分析
信息系统的核心价值之一是支持管理,而管理支持的核心是通过管理流程事前规避风险,通过规则和审批事中控制风险,通过数据分析做事后优化。
在数据分析过程中,首先要明确“数据≠信息”,分析数据后,不妨多问为什么,从而挖掘出用户所需要的信息,比如,大家查询当日天气情况,实际是想了解如何穿衣等等。判断数据的完整性,需要明确想要获得的信息具体是什么。
管控点识别即通过数据分析实现的管理意图。比如一个考勤系统,可以通过业务报表来继续挖掘用户的深层需求,比如统计员工迟到情况,其实是为了评估员工积极性,找到该管控点,然后再从积极性角度分析,还有哪些报表可以反应该管控点,可以就此问题与用户进行交流。
好看请赞,养成习惯:) 本文来自博客园,作者:靠谱杨, 转载请注明原文链接:https://www.cnblogs.com/rainbow-1/p/15672364.html
欢迎来我的51CTO博客主页踩一踩 我的51CTO博客
文章中的公众号名称可能有误,请统一搜索:靠谱杨的秘密基地