以前分享的--从0-1搭建交付型项目管理体系流程-- 需求分析篇【宝芝林6】
从0-1搭建交付型项目管理体系流程（上）【宝芝林2】
从0-1搭建交付型项目管理体系流程--商业论证篇【宝芝林3】
从0-1搭建交付型项目管理体系流程-- 招投标 篇【宝芝林4】
从0-1搭建交付型项目管理体系流程-- 项目启动篇【宝芝林5】
非常受大家的欢迎，给大家带来了不少启发，很多小伙伴催更了，作者在繁忙的工作之余抽时间把后面的写出来了，分阶段的非常透彻说明了如何搭建项目管理体系-需求分析设计篇，今天就分享给大家，供大家参考。
从0-1搭建交付型项目管理体系流程--需求分析篇：
需求分析篇
大家好，我是宝芝林，今天跟大家分享的主题是项目管理流程中的需求分析阶段的内容。
一. 目标及作用
本阶段主要的目标是编写需求规格说明书，其里程碑事件为召开需求评审会，需要甲方业务相关负责人参与签字确认。
主要作用是根据甲方的业务目标和需求，进行需求调研、需求分析等工作，将业务需求转化为具体的软件功能需求，并形成需求基准。需要特别说明的，需求包括功能需求及非功能需求两类。
需求分析阶段工作成果和质量是后续软件设计和开发的依据，也是后续项目系统评估和验收的重要依据。需求分析的内容极大的影响着软件开发的成本、技术、周期、质量及客户满意度，在整个软件项目的执行阶段占有非常重要的位置。
二、公司现状及行业特点
2.1. 公司现状及团队特点：
公司业务模式是为银行、保险公司提供软件项目实施。采用的是项目经理责任制，因此对项目经理的定位和要求较高：
- 项目团队的灵魂和一号位
- 需要具备项目管理能力、团队管理能力
- 需要在需求分析或研发技术能力上有所专长
因此在实际的项目团队成员组成结构上，是项目经理+产品经理助理或预备技术组长来开展相关工作。这既是公司所处阶段、业务及组织结构特别决定的，也是快速培养团队成员需要的。
为了表述方便和清晰，项目核心团队成员仍旧分为项目经理、产品经理、技术组长三种角色去描述。在需求分析阶段职责如下：
- 事业部经理：监督及总指导
- 项目经理：主责，负责整体推进,必要时补位
- 产品经理：主执行，负责需求分析各种具体工作执行
- 技术组长：辅助+执行，负责提供必要的技术支持
各位小伙伴也可以根据各自公司的实际情况，对团队成员结构和岗位职责进行调整和裁剪。
2.2. 行业特点
银行、保险行业的业务及需求有自己独特的行业特定，我们从时代特点、项目类型、业务复杂度、项目干系人等多个维度进行分析，从而有助于后续开展需求分析工作。
时代特点：目前银行、保险行业的软件项目处于数字化转型的大周期内，并且以传统以金融产品供给为中心的体系向以客户为中心的体系进行转型
项目类型：
① 改造/优化类项目：基于现有系统进行升级和业务流程优化类；
② 新建类项目：可细分为有明确业务方案落地类项目和大方向明确但无具体落地方案类项目；
业务复杂度：银行、保险公司由于其行业特点，具有业务流程长、业务复杂度高和涉及多部门、多岗位的特点。
项目干系人：项目涉及甲方多部门、岗位，需要满足多部门相关利益及诉求，一般以项目集形式体现，涉及多个软件系统交互及多个供应商团队的互相配合。
2.3. 需求分析阶段常见问题
参照团队以往项目经验和业界先进理念，我们把需求分析分为需求调研、需求分析、需求设计、需求评审四个大的阶段，总结了以往项目中遇到的常见问题。通过团队特点、行业（项目）特点、常见问题，就可以指导我们形成可落地的需求分析阶段工作内容及流程。
三、工作内容拆解
需求阶段工作，我们将工作内容拆解为纯项目事务类工作以及需求分析工作。
3.1. 纯项目事务类工作
- 与甲方沟通需求分析工作方式、频率及流程；
- 制定需求分析阶段整体计划；
- 与甲方业务老师沟通需求调研详细计划；
- 沟通上下游系统进行需求沟通；
- 开展内外部需求评审相关工作；
- 了解甲方需求分析阶段各种线上申请流程及账号；
- 收集甲方需求规格编写规范及模板；
3.2. 需求分析工作
根据业界实践经验和理论，结合公司外部顾问及各项目总监的项目经验 ，需求分析工作细分为四个子阶段：需求调研、需求分析、需求设计及最终的需求评审。
１. 需求调研
利用各种需求调研方法，收集客户的需求，并将调研过程收集的资料进行汇总，为需求分析提供依据。
２. 需求分析
基于需求调研资料，对客户的需求进行分层、分类、归类、梳理，最终确认系统需要实现的功能。
３. 需求设计
根据需求分析的结果，结合项目的范围、进度、质量、成本等约束，形成最终的需求设计方案，形成详细的需求规格列表及需求规格说明书。
４. 需求评审
根据需要进行内部及外部需求规格评审，在需求层面尽量消除项目各干系人分歧，并最终推进需求规格说明书签字，确定需求基线。
本文介绍的需求调研-需求分析-需求设计-需求评审阶段划分的方法，经过实践对于200-500万左右的软件项目相对比较适用。
若实施更大规模的软件项目，譬如保险核心业务系统或银行核心业务系统建设，则需要对各个阶段进行更加详细的划分。
若为几十万左右的软件项目，则可以对相关阶段进行适当合并和裁剪。
大家运用一种方法或理论的时候，一定切记每种方法或理论都有自己的适用场景和边界，不能拿一个方法或理论适用所有的场景，需要做的是吸收其核心精华和思想。
四、工作流程及支撑工具
01
工作流程
需要说明的是，需求调研、需求分析、需求设计并不是完全的线性先后关系，它们是相互伴随、交叉进行的：
- 在前期更多的是进行需求调研相关工作，需求分析工作相对较少。
- 而随着掌握的需求信息越来越多，需求分析及需求设计的工作越来越多。
需求分析工作是软件项目中的一项专业领域，其涉及非常多的知识内容及方法论。在交付类软件项目实践中，项目经理需要对需求分析工作有比较全面的了解，这样才能更有效的进行相关项目管理工作。下面我们针对需求分析的各个阶段做一个相对概括性的介绍。
02
需求调研子阶段支撑工具及交付物
需求调研阶段主要目的是利用需求访谈、需求问卷、现状调研等手段和方法收集和记录客户的需求、期望、痛点和难点，从而为需求分析阶段提供的依据和材料。
需求调研阶段按照时间先后顺序，分为3个阶段：
- 调研准备阶段；
- 调研实施阶段；
- 调研成果整理阶段；
项目经理需要从全局上进行把控，制定整体的调研路线图和计划。（需求调研有多种方法，本文仅介绍最通用的用户访谈方法）
用户访谈方法
１. 调研准备阶段
① 项目背景资料汇总
- 甲方整体业务架构资料（组织结构、业务流程、业务功能、业务数据）；
- 本次项目所属数字化战略转型整体规划及咨询解决方案；
- 本次项目甲方的业务需求说明书；
- 本次项目招投标文档；
- 本次项目售前沟通及咨询资料；
- 本次项目的SOW工作说明书等；
- 本次项目涉及相关业务知识；
- 公司历史类似项目资料；
项目经理尽量收集以上资料，使得产品经理在详细调研开始前有一个整体的、全面的了解，从而提升专业性、增强客户信任感，提升沟通效率。
② 调研内容准备
项目经理与产品经理紧密配合，根据项目的实际情况确定访谈对象、调研顺序及编写访谈提纲。
对于银行、保险类软件项目，一般甲方会指定1-2位具体业务负责人和岗位专家进行需求调研。项目经理进行必要的干系人分析与协调访谈计划，在这里不做赘述。
在进行正式访谈前，项目经理及产品经理共同ReView访谈提纲，确保访谈提纲的质量。
这里提供一个小技巧：
* 一般来说访谈提纲中“确认”内容为主则说明准备较为充分；
* 若“询问”内容为主则说明准备尚不充分，需要进一步准备；
当然对于系统规模较大、业务链路复杂、需求尚不明确的软件项目，第一次需求访谈“询问”的内容会比较多，需要项目经理及产品经理根据实际情况灵活掌握。
2. 调研实施阶段（用户访谈）
需求调研有多种方法，本文仅介绍最通用的用户访谈方法。
在用户访谈的前3-5天，可以将访谈问题清单提供给被访谈人员，以方便其更好的准备相关资料。
在具体访谈过程中，项目经理、产品经理把控好访谈的节奏并做好访谈记录。
5W1H是需求访谈中较为通用的方法
- Why：为什么，要解决哪些问题（最重要）；
- Who：谁、责任人、岗位；
- What：做哪些操作，做什么；
- When：什么时候、触发时间节点、时效要求、顺序；
- Where：什么地点、什么场景、什么渠道；
- How：如何做、设计的流程、规则等；
项目经理、产品经理在进行访谈时要尽量挖掘出客户真正的业务需求，而不是业务老师有可能给出的“解决方案“级别的需求，要多问几个Why。
举个不完全恰当的例子，当一个人问你要一瓶可口可乐，可能他真正要解决的是口渴了的问题。
3. 需求调研成果整理
在需求访谈结束后，要对访谈内容进行整理和汇总，最终形成需求访谈成果。
需求调研阶段的原则是对客户需求内容进行“记录”，形成的资料避免加入产品经理个人见解，整理的资料需要保持“原始性”。
一般调研成果经过梳理后，以现状构成（业务现状、业务逻辑、业务流程、IT现有系统及功能）、访谈记录以及发现的各种表单（纸质表单、电子表单）来呈现和存储。
项目经理确保相关需求调研成果放入指定文件存储位置，方便后续及他人查找使用。
通过以上需求调研相关工作的准备和开展，给甲方客户留下专业的印象、办事认真的态度，从而保证整体上方向不偏、路线不错、切入点正确，为后续顺利交流和项目实施提供保证。
| 流程名称 | 需求调研 |
| 参与角色 | 事业部经理：指导、监督 业务及技术顾问：必要时参与或指导 项目经理：总责 产品经理：主要执行 技术组长：辅助执行 |
| 思考工具/过程产物 | 项目事务类工作清单 需求调研提纲 需求调研方法：用户访谈、原型法、问卷法、文档调研等 |
| 里程碑 及交付物 | 需求访谈成果 |
03
需求分析子阶段支撑工具及交付物
需求分析子阶段是对收集到的客户原始需求进行拆解、归类、梳理，最终明确系统最终必须实现的功能需求。
需求分析子阶段分为2个大的工作内容：分析需求及确定需求。
1
分析需求
分析需求是通过对原始需求从不同层次、不同颗粒度及不同的维度进行拆分、归类、梳理，形成最终的功能需求清单列表及各个功能的具体业务规则的过程。
- 高层到低层
- 粗颗粒度到细颗粒度
- 不同维度/多角度
业务运营
业务节点
2
确定需求
需求确定工作主要完成两项内容：①形成最终需求功能清单列表，②对需求功能进行优先级排序并确认核心业务功能主线。
1.形成最终需求功能清单列表及具体内容：
| 对比 | 合同及SOW阶段需求功能清单 | 需求分析阶段功能清单 |
| 颗粒度 | 粗 | 细 |
| 梳理程度 | 简要的梳理 | 详细的规划、梳理 |
| 功能内容 | 仅包含功能的简要说明 | 包含业务功能详细说明： 业务流程 业务原型 业务数据 业务规则 管理规则 涉及用户 |
项目经理及产品经理以合同及SOW工作说明书范围为依据，以满足客户真实业务价值为灵魂，以项目工期、成本、技术为限制条件，最终确定需要实现的系统功能。
- 补充需求：根据客户实际业务运转的需要，发现和补充客户未明确提出但必不可少需求，为客户业务提供真实价值
- 纠正需求：对客户提供的有歧义的、表述不清的需求进行纠偏，寻找到客户真实的需求
- 去除需求：对于经过分析不再需要的需求（特别是列入合同及SOW工作说明书中的需求）进行去除
目前的银行、保险行业的数字化项目建设所处的阶段，客户需要软件供应商提供的是有价值、可真正支撑其业务运转的数字化能力，而不仅仅是一堆系统功能。此时对项目经理、产品经理的能力要求较高，若能够达到这个标准和要求，会非常有利于项目顺利开展：
- 有助于减少后续需求变更的情况；
- 有助于技术阶段的概要设计和编码实现；
- 有利于项目验收阶段的顺利推进；
- 有利于商务上推进项目二期、三期的开展；
2.需求优先级排序及确认核心业务主线
在项目启动阶段，已经根据SOW中的需求功能制定了整体的上线计划，经过需求分析子阶段后形成的最终需求功能列表有可能发生改变。
项目经理、产品经理及技术组长根据实际情况重新对需求功能进行优先级排序，以及明确核心业务流程和相关功能。核心业务流程及功能是项目核心团队后续重点关注内容。
根据需要，项目经理与甲方项目及业务负责人进行沟通，进行相应的需求变更及项目计划优化调整。
需要特别注意的是在需求分析子阶段，项目经理及产品经理需要与涉及的上下游系统项目组保持充分沟通和交流，确保：
- 项目需求范围达成一致；
- 业务场景互相了解并达成一致解读；
- 上下游需提供哪些数据及格式达成一致；
- 各种业务术语及业务数据含义保达成一致；
因上下游系统项目组对项目需求范围、需求场景等理解不一致导致的需求返工和技术架构及代码修改是最常见的问题，而且往往会产生极大不利影响，需要认真对待。
| 流程名称 | 需求分析 |
| 参与角色 | 事业部经理：指导、监督（必要时参与） 业务及技术顾问：必要时参与或指导 项目经理：总责 产品经理：主要执行 技术组长：辅助 |
| 思考工具/过程产物 | 需求分析、需求确认 |
| 里程碑 及交付物 | 需求功能清单列表及具体内容 核心业务流程及功能 |
04
需求设计子阶段支撑工具及交付物
需求设计子阶段是在需求分析子阶段的基础上，结合计算机系统特点，参考行业的作业特点和甲方的相关设计规范和要求，形成最终需求设计方案，并输出需求规格说明书的过程。需求规格说明书是后续的技术设计、代码开发及实现、系统测试的输入和依据。
根据实践经验，需求设计子阶段不仅仅是产品经理的工作，还需要技术组长及项目经理积极参与和讨论，以确保形成的需求设计符合技术条件、项目进度和成本的约束。对于新建项目或复杂系统的需求设计，更需要业务/技术架构师的参与和指导。
一般来说银行、保险公司等甲方都有自己的需求规格编写规范和模板。下面以一个相对通用的需求规格说明书的内容为例，介绍如何进行需求设计相关工作。
需求规格说明书一般由以下几个部分组成：概述、系统整体方案、系统功能模块、非功能需求等；
１. 概述
概述介绍系统的背景、目标、范围、假设、约束等。
业务术语：是本系统涉及的业务术语定义及解释，若涉及的业务术语较多可以通过附件形式保存。
系统角色说明：本系统使用的角色说明。譬如保险公司客户、保险公司内勤人员、保险公司代理人等
2. 系统整体方案
介绍系统的总体架构、业务流程、功能结构等。
根据需要，其一般包括如下内容：
- 系统间拓扑图：展示本系统与上下游及周边系统的关系；
- 功能框架图：展示本系统整体的功能框架；
- 功能模块清单：列出本系统的功能模块及功能，并用需求编号标识；
- 公司组织架构：展示公司整体的组织架构及岗位规划；
3. 系统功能模块
介绍系统各个功能模块的详细描述、输入输出、界面设计等。
一般包括如下内容：
- 业务流程图：画出每个功能模块涉及的业务流程图；
- 具体功能说明：针对每个具体功能，进行详细描述和设计，包括原型图、字段定义及规则、功能规则说明和功能逻辑图等。
4. 数据设计
介绍系统涉及的数据的定义、来源、流向、存储等。
数据设计内容包括：
- 上游系统数据：说明系统从哪些上游系统接收什么样的数据及这些数据的来源和定义；
- 本系统数据：说明细神圣和保存什么样的数据，及数据的定义和存储方式；
- 下游系统数据：说明系统向哪些下游系统提供什么样的数据，及数据的流向和定义；
- 通用基础数据字典：系统采用的基础数据及其规范来源。如省市区编码、公司机构编码、保险产品编码等。
5. 非功能需求
非功能性需求是指软件产品除了功能需求之外，为满足用户业务需求而必须具特性，通常体现在系统的“质量”方面。针对银行、保险行业的特点，需要重点以下几个方面的非功能需求：性能需求、安全性、可扩展性与可维护性、可靠性和易用性等。
性能需求：综合考虑甲方现状系统的性能要求、行业通用性能标准、业务的现状及未来三年左右的预期发展，分析并提出系统的性能需求。如响应时间、并发量、吞吐量等。
安全要求：根据根据业务用户的类型、系统的运行环境、监管法规的要求，分析并提出系统的安全需求，如身份认证、数据加密、访问控制、日志审计
易用性需求：根据银行、保险行业的工作特点，设计合理的交互风格和页面布局，参考以下依据：
- 用户实际操作场景及习惯；
- 甲方现有系统的界面和风格；
- 甲方现有的UI规范和风格；
- 业界流行操作方式和设计原则；
- 设备的类型和特性（如PC端、手机端等）；
| 流程名称 | 需求设计子阶段 |
| 参与角色 | 事业部经理：指导、监督（必要时参与） 业务及技术顾问：必要时参与或指导 项目经理：总责 产品经理：主要执行 技术组长：辅助执行 |
| 思考工具/过程产物 | 各种设计图（框架图、流程图、分解图、用例图、原型图等） 工具：Axure、摹客、VISIO、UML |
| 里程碑 及交付物 | 需求规格说明书 业务术语一览表 |
05
需求评审子阶段支撑工具及交付物
需求评审子阶段是整个需求分析的最后一个环节，其关键里程碑是召开需求评审会议对需求规格说明书进行确认和签字。
其作用是项目各个关键干系人（甲方业务发责人、项目负责人、周边上下游系统项目团队负责人等）对需求方案的范围和具体内容进行确认，消除重大错误和分歧，达成一致，形成需求基准。
需求评审子阶段可以分为内部评审和外部评审2个大的阶段。
１. 内部评审
内部评审主要目的是在正式的外部评审之前，对需求分析的所有内容及最终的需求规格说明书做检查，尽量减少各种错误和歧义。其中每个参与人员的侧重点不同：
- 事业部经理、业务/技术顾问：总体上审查评估；
- 项目经理：从项目整体层面思考（范围、质量、技术等）；
- 技术组长：重点从技术视角思考，是否满足后续概要设计的要求；
- 开发骨干（可选）：首次正式进入项目，开始了解整体项目，协助查找功能中的错误及歧义；
- 测试人员（可选）：首次正式进入项目，以测试视角思考，为后续测试计划及测试用例编写做准备；
产品经理：需求规格的主要责任人，需对需求规格说明书进行全面的扫描，包括功能框架、业务流程、具体功能，尽可能修正错误及歧义。
2. 外部评审
外部评审会一般分为三个阶段：评审准备、评审召开、评审后
① 评审准备
充分的评审准备工作为需求评审顺利完成提供基础保证。
- 确定评审人员：甲方主要负责人，外部系统开发团队、测试团队（第一次介入项目）；
- 文档提前发出：提前4-5天提前发出，有问题迅速沟通澄清；
- 确认沟通重点：与参与评审各方沟通关注重点，如业务目标、上下游交互部分，存在争议及疑难问题；
② 评审阶段
项目经理组织召开需求评审会，此时项目经理/产品经理要能够把控全场节凑，聚焦核心业务流程，以及业务重点和难点。
③ 评审后
需求评审完毕，项目经理做好评审后续工作
- 会议纪要，正式邮件发出；
- 追踪需求文档签字确认；
- 问题及修改意见跟踪；
- 形成需求基准线；
需要说明的是，在实际的工作中，需要根据项目规模、项目重要程度等
根据需要进行多层次、分阶段的各种需求确认和评审工作。
需求评审工作的一般原则：
- 建立标准的评审流程、充分准备评审、精心挑选评审员；
- 正式与非正式评审结合、分层次评审、分阶段评审；
- 充分利用需求评审检查单；
- 做好评审后的跟踪工作；
| 流程名称 | 需求评审子阶段 |
| 参与角色 | 事业部经理：指导、监督（必要时参与） 业务及技术顾问：必要时参与或指导 项目经理：总责 产品经理：主要责任人 技术组长：辅助执行 开发骨干:第一次正式进入项目 |
| 思考工具/过程产物 | 自检清单、内部评审 、外部评审 |
| 里程碑 及交付物 | 需求规格说明书及签字确认 需求规格确认及正式邮件 |
05
需求分析阶段总结
需求分析的目的是收集和定义用户和客户对于软件系统的需求，包括业务需求、功能需求、非功能需求等。
需求分析的质量直接影响了软件系统的设计、开发、测试和发布的效果，也决定了软件系统是否能够满足用户和客户的期望和目标。
在整个过程中，项目经理需要从宏观及关键节点进行管理和支持，确保需求分析的顺利开展，为后续阶段的打好基础。
思考题
你们项目经理在需求分析阶段的作用和定位？
你们如何对需求分析阶段进行划分？
你们需求分析阶段有哪些产出成果？
你们是如何管控需求分析质量的？
你们需求分析常遇到哪些困难和问题？
-------------------------------
作者介绍：PMO前沿特约分享嘉宾宝芝林：
18年 保险、银行、政府企业级IT信息化建设经验；从事项目管理、业务解决方案咨询相关工作领域；擅长0-1搭建软件项目管理体系、团队搭建及管理；某保险行业软件公司担任软件项目交付部经理；
近期热文：大咖云集︱2023中国PMO&PM大会报名通道正式开启
北京、上海、深圳三地同步进行，两天近70位项目管理大咖专家齐聚一堂，交流分享。各路高手汇聚一处，互相学习。精心的圆桌设计，穿插各种活动和沙盘，让每个参会者不仅仅听到大咖分享，更能结识众多同行高手，拓展认知还能结交高人，共创更多发展新机遇！
近期热文：
- 从0-1搭建交付型项目管理体系流程-- 项目启动篇【宝芝林5】
- 从0-1搭建交付型项目管理体系流程-- 招投标 篇【宝芝林4】
- 从0-1搭建交付型项目管理体系流程--商业论证篇【宝芝林3】
- 从0-1搭建交付型项目管理体系流程（上）【宝芝林2】
- 不懂技术如何准确评估项目开发工作量？
- 图解通俗易懂Scrum敏捷项目管理精华
- 一文带你清楚知道项目经理都在干什么？
- 项目经理和PMO如何轻松搞定项目风险管理，附项目风险及解决方法表【静说】
- 华为成功的秘籍—以项目为中心
- PMI新人才三角如何构建自己的影响力？【洞见1】
- 一张图掌握项目管理的全过程
- Prince2项目管理所有精华看这篇就够了
- 优秀的PMO和项目经理如何进行项目进度跟踪？
- 一图掌握PMO的职责、定位、价值和体系架构，让你一文掌握PMO精华
- 百万年薪PMO&项目经理职场影响力是如何炼成的？【精华笔记】
- PMO&项目经理如何高效解决问题看这篇文章就够了