最近读了徐峰老师的《有效需求分析》，有一种相见恨晚的感受。自开发转做产品以来，就没接收过产品系统学习的我，这本书完全可以帮我提供了产品日常工作的“术”。可以很好的引导我们产品工作的思考方向。
本书注重介绍产品工作核心部分，需求分析。 从宏观的需求愿景价值分析，需求干系人、业务需求分析及流程设计、业务场景识别、到站在管理者视角洞察 管控点需求识别、以及业务数据报表、 产品维护需求等非常全面。
0、业务驱动的需求思想
（1）、澄清问题
a、原始需求是什么层次？方案级、问题级
b、想要解决谁的、什么问题？
c、用户现在遇到这个问题会采用什么样的解决方案？
d、这个问题中有需要进一步细化和明确的概念吗？
（2）、了解背景
a、根据实际需要细化以下内容： 场景（功能）、术语（数据）、环境（质量）
该需求谁使用？什么时候使用？具体怎么做？
有需要澄清的业务术语吗？它们的格式是什么？
不做谁生气？多久生气一次？为什么？多久用一次？
（3）、建议并确定解决方案
要解决这个问题有哪些可行的解决方案？
这些方案的实现成本分别有多大？
你觉得哪种最合适？（解决问题/成本合适）？
该解决方案对用户而言有什么优缺点？
有其他需要挖掘的需求吗？
1、目标/愿景价值需求
什么是价值需求？简单来说，“整个软件系统为客户解决了什么问题、创造了什么机会”，对系统而言，最关键的干系人有哪些，各干系人对系统的关注点，有哪些担心（阻力点）“三个本质性问题。 需求 = 预期 - 现状
目标的三种描述方式 ： 定性描述、 定量描述、场景化描述。
定性描述
就是从总体属性、趋势、宏观的角度来说，如“”全面提升客户服务质量、“全面提高沟通效率”，这种方法的描述只是指出了一个模糊的方向，无法有效地界定系统的范围。
定量描述
从微观的角度来说，会使用具体的、精确的数据描述。最典型的就是SMART原则：具体的（Specific）、可衡量的（Measurable）、可实现的（Attainable）、有相关性的（Relevant）、有时限性的（Time-based）
例如“通过系统的业务受理时限自动提醒等功能，在系统正式投入使用后的3个月内，将客户因业务办理超时而引发的投诉从每月100笔以上降低到5笔以内，从而提升客户服务质量。”
场景化描述
用故事场景来描述用户的期望，
例如“大幅度减少甚至避免客户因业务办理超时而引发的投诉，以提升客户服务质量”。
定性描述通常是空洞无物、无法验证的，因此应该避免采用。定量描述最精确，易于验证，只要有可能都应该做到这种程度，但有时会难以达到。折中的方案，即场景化描述，它真实、易于理解、可以验证，同时感染力强，是一种值得推广的做法。
目标/愿景分析步骤
（1）访谈“问题” ：通过对关键干系人的访谈，识别预期与现状的差距。
（2）研讨“机会”：通过与领域专家、技术专家，用户代表的交流，寻找潜在机会。
（3）定义问题/机会：描述问题、机会，以及它影响谁、产生什么结果。
（4）分析问题并确定解决方案：深入分析问题，然后确定策略级的解决方案。
提炼 “一句话目标”
要点在于业务态、价值态，以 “措施 + 效果”的结构描述
例如：基于安全库避免物资脱节，为门店扩张奠定后勤基础。
2、干系人识别、分析
如何识别干系人？
1、根据目标识别关键干系人
首先要收集客户的组织架构，然后再根据目标、愿景判断
2、根据风险识别其他关键干系人
分析干系人需求？
他期望通过系统解决什么问题？
我们可以为他开展业务、实施管理提供什么支持？
阻力点： 他担心系统会带来什么样的负面影响？应如何解决？
3、业务子系统划分
最典型的业务子系统的划分策略就是按“部门职能” 进行划分，而部门职能最典型的就是产、销、供、管四个部分。
划分之前，可以先画出与系统有关的组织架构图，然后根据组织、部门之间的相近度，划分出各个业务子系统即可。
4、业务流程识别、分析
信息系统的核心价值之一是支持业务，而业务支持的核心是对业务流程的固化、优化和重构。
什么是业务流程
企业或组织的核心价值在于响应外部客户的服务请求，通过一系列的协作满足服务请求，为客户带来价值，同时为企业/组织带来价值。
什么是端到端流程
（1）完整，所谓端到端，实际就是服务请求从提出到满足的全过程。
也就是判断一个流程是否完整，应该站在服务请求的立场，判断服务请求是否满足或者被拒绝。
（2）边界，识别业务流程时涉及两种边界。一是职能边界，也就是跨越了我们未涉及的业务域； 二是系统边界，也就是不属于系统关注的部分。
识别管理流程
管理者为了控制业务开展、规避风险、控制结果，都需要采取一些管理措施。
最典型的包括三种：一是用于事先预防的管理流程； 二是用于事中控制的审批、规则；三是用于事后分析的报表、数据分析。
管理流程的识别可以从以下几个角度来思考
（1）业务上线类的审批控制；
（2）人、财、物、资源的管控
（3）进度和异常的控制
判断业务流程优先级
评估业务流程优先级时，可根据是否为主营业务、发生的频率高低来进行综合评估。
业务流程八要素
五个基本要素 分工、活动、协作、产物关系、分支
三个管理要素 审核、规则、异常。
流程优化 ，最典型的策略有四个，俗称“ESIA”
（1）E（清除无效)：找到流程中不产生效能的、浪费的、低效的环节，然后想办法清除
（2）S（简化高频）：对频率最高的环节进行优化，流程效率将上升。
（3）I（整合依赖）：将相互依赖的环节整合在一起，提高效率。
（4）A（自动化烦琐）：把人做起来麻烦的事让电脑来干，提升效率。
5、业务场景识别、分析
（1）明确进度要求
系统最晚何时要交付？
为什么有这样的要求？
可以分阶段满足吗？
（2）明确资源支持
用户方的指定接口人是否明确？
是否应要求客户成立专门的项目小组？
是否应要求客户提供场地、设备等方面的资源支持？
（3）明确预算要求
用户有明确的预算限制？
可接收的预算范围是多少呢？（用户财务情况相关）
涉及的业务范围有多大？同类系统建设的投入额通常在什么范围？竞争对手的报价呢？
（4）明确技术选型约束
有相关技术规范对技术选型做出明确要求？
有相关法规对技术选型做出相应的限制？
（5）明确部署环境带来的约束
遗留系统会对系统的实现产生相应的约束吗？
服务器、终端、网络选型会对系统实现产生约束吗？
法规对系统实现会有哪些潜在约束？
用户的文化、使用环境、社会环境对实现有约束？
系统的生命周期会对系统实现产生约束？
（6）明确开发环境带来的约束
开发团队能力构成会对系统实现带来约束吗？
开发工具、环境会对系统实现带来约束吗？
用例、用户故事等是现代需求分析技术，它们的精髓在于“用户视角”，在于“业务场景/使用场景”。 切勿将功能作为用例。
用例
用例的粒度： 用例即业务场景，而一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。
用户故事的本质
用户故事，是一种轻量的、有效的用户需求描述方式，它希望用户或用户代表以 “作为xxx（角色），希望通过系统xxx(解决方案、功能要求)，以便达成xxx业务目的、套解决的业务问题”
用户故事
业务场景分析
（1）描述业务场景
该业务场景中，用户要实现什么样的业务目的？
执行该场景有什么前提条件？结束前需保证何状态？
除场景执行者之外，还有谁关心它？关心什么？
（2）细化业务场景的业务步骤
最典型的、用户预期内的业务步骤是怎么样的？
针对各个步骤，有哪些潜在的变化情况？
针对各个步骤，有无异常情况？异常如何处理？
（3）遍历步骤分析困难、导出功能
在各个业务步骤、变化及异常情况下会遇到何困难？
针对这些困难，系统需要提供什么样的功能支持？
是否存在不能按以上步骤处理的情况？
这种情况需要系统提供什么样的功能支持？
（4）识别环境与规则
用户操作环境有何特点？
人员、业务量、峰值业务量、业务密集度如何？
用户有什么特点？
有什么相应的业务规则？
有什么实现约束？
（5）分析实现方式，完成初步交互设计
需要哪些界面？
界面需要哪些功能元素？
它们是如何流转的？
界面需要哪些数据元素？
6、管控点识别与分析
信息系统的核心价值之一是支持管理，而管理支持的核心是通过管理流程事前规避风险，通过规则和审批事中控制风险，通过数据分析做事后优化。
（1）标识管理者
系统涉及哪些管理者？
他们是管理型（管理他人、团队、职能）还是经营型（管理业务、业务群）？
（2）标识管控点
管理者类型？ 管理型、经营型
管理型（事务、进度、异常、员工、绩效指标）
经营型（客户、产品/服务、财务、效益）
（3）分析所需指标
需要哪些角色的信息？
不合预期的情况如何识别？
可以归纳成哪些指标？
（4）分析实现方式
根据数据获取特点选择方法
可以从固定数据源用固定条件分析数据（分析所需的报表）
可以基于固定数据源、但查询条件无法固定（分析BI需求）
针对的数据源需要重新梳理查询条件也不固定（分析数据挖掘与数据仓库需求）
管控点框架
7、业务报表分析
业务报表分析的重点在于厘清报表的使用场景、报表的内容，以及输出的相关要求。
谁使用，涉及报表生成者、报表阅读者两种
为什么用，报表的业务意图，实际上可以追溯到在“管控点识别与分析”任务中所标识的管控点，但由于实现一个管控点通常会需要一组报表，甚至要借助BI，数据挖掘手段。
使用频率，使用频率决定了性能要求，越常用的报表，用户肯定对其速度要求越高，如果很难写出 “必须XX秒内响应”，可以写出使用频率。
8、维护需求分析
系统投入使用之后，运行维护阶段所需提供的辅助功能，主要包括 配置、运维、升级迁移及其他三方面。
配置性维护场景
第一种典型维护场景就是 “各种配置”，以应对变化带来的影响。
标识配置性维护场景就应该从变化入手，系统会遇到什么变化呢？
从里到外主要有以下几个方面：
（1）用户群变化，使用该系统的用户发生改变，职位、权限发生改变，因此，要维护用户、角色、权限，相应地需要一些配置功能。对于权限而言，核心包括功能权限、数据范围权限、分配权限的权限。
（2）流程变化，企业的流程总会根据自身在发展过程中关注点的改变而不断进行调整，以满足阶段性管理目标。因此，如何有效应对流程变化对系统带来的影响，是需要提前考虑的。
（3）数据变化，如何应对未来数据项的增加，数据构成的调整与变化，需要提前考虑的。
（4）法规变化，有时会涉及法律法规的要求，应该考虑若法律法规变更，如何应对。
运行阶段维护场景
这方面可以从“正常时”、“故障时”两个角度展开分析。
（1）正常时，一是对运行状态的监控， 二是数据备份。
（2）故障时，故障定位、排错、故障恢复及应急措施的支持
补充其他维护场景
典型的其他维护场景包括运行前的初始化、系统升级、迁移时所需的支持。
（1）系统初始化，在系统第一安装、部署时需要提供什么样的工具支持，如安装、初始化配置、测试工具等。
（2）系统升级，系统在升级时需要提供什么样的支持，如远程升级、自动化升级、版本检查等。
（3）系统迁移，每次升级时，是否需要对原有系统进行数据迁移，是否需要支持双系统并行运行等支持。
网友评论