需求分析篇：五年B端乙方产品生涯，总结的工作方法与工具

编辑导读：在进行需求调研之后，就要对这些需求进行分析。 将需求落实到纸面上，再将它细化成具体的流程、功能、权限等。本文作者总结了自己的工作方法和工具，与你分享。

16年入行产品，从产品小白到助理到专员到产品经理，一路走来，遇到过苦难挫折，但也收获了方法，提升了能力。从事产品工作以来一直在乙方工作，做过政务项目，也做过B端产品。通过几年的工作总结出了一些可复用的工作方法与工具，希望分享出来能够帮助到入行不久或想要入行的朋友们，也希望经验丰富的朋友们能够多多指教。

首先介绍一下我从事工作的背景：主要负责G端项目需求调研、产品设计、系统培训、优化迭代工作。我将工作流程分为七个阶段进行简单介绍：需求调研、需求分析、产品设计、开发测试、上线试运行、项目结项、上线运行。本篇文章将介绍第二个阶段需求分析。

第一阶段文章需求调研篇：http://www.woshipm.com/pmd/4597524.html

需求分析阶段我们需要做的工作是：

• 整理并理解客户需求，与客户确认需求；
• 将客户需求转换为产品需求，包括确定功能信息机构，业务流程等；
• 评估需求价值，确定设计方案；

需求分析阶段我们的产出物是：

• 需求确认单；
• 业务流程图；
• 状态图；
• 功能结构图；
• 信息结构图；
• 权限表；

需求分析阶段我们的工作流程是：

一、分析前-确认需求

需求分析前最重要的工作就是确认需求，将需求落到纸面上。做G端项目，需求变更的频率一直是居高不下，为了尽量减少变更，我们分析前需要再次进行确认，并让客户签字。签字的最大好处就是让其重视起来，检查自己提出的需求是否合适。进行需求调研时大多是聊天的形式，所以客户说出需求并不完全准确。当你拿着一沓需求确认单，让他签字时，他就**非常认真的查看，这个时候往往**发现很多需要增减的需求。

以下是我司采用的需求确认单，仅供参考。

对于涉及业务较广的项目，建议每个业务块采用一份需求确认单。

二、分析中-流程、功能、信息、权限

1. 分析需求，梳理业务流程

因G端项目大多业务流程化较重，所以每次进行需求分析我都**从业务流程入手。需求调研时我们已经了解了业务的整体流程，但其中的细节还需继续深挖，尤其是一些异常分支。

最近接触的一个项目管理项目中，客户给到的需求是：“对于不是我们单位管理的项目，需要进行项目登记，我们审核通过后，要在项目库可以看到。有的项目可能在提交给我们审核前**内部先审一下，这个在平台中也要提供。”

注：客户的单位属于该平台的运营方。

根据客户的描述我们可以很迅速的画出以下流程图，有时甚至可以直接在现场和客户确认。

上图确实可以将客户的需求表述清楚，但还没完全转换为产品需求，在梳理一个流程时我们需要知道谁在什么时候做什么事情，对应的就是用户角色、节点、操作。为了完善这三个元素，我们又画了如下流程图。

这个流程图可以明确表达出某个用户角色在某一节点需要做什么样的操作。这样就可以了么，不，还没有结束。因为它只表达出了正流程，并没有表达出在“审核”节点和“审批”节点若没有通过该如何处理。这个时候我们就**发现审批不通过驳回时可以逐级驳回也可以驳回起点，两种方式均可行，那么该采用哪种方式呢？这时我们就要回归业务，与客户沟通他们实际的业务都是怎样处理的。虽然我们在需求分析前已经和用户确认需求了，但那时确认的都是整块的业务需求，并不细致，在实际分析的过程中遇到问题也需要及时与客户沟通。

⚠️这里需要强调一点，我们遇到问题时，不要每个小问题都去找客户确认，可以将一类业务的问题收集起来，一起与客户确认。如果总是因为一个小事情就去找客户，时间长了他**很烦的，这对我们后续开展工作非常不利。

和客户确认后，实际业务中，只要申请不符合标准都**驳回给申请人，那么完整的流程图如下：

至此项目登记的流程图梳理完成。

涉及审批流的业务自然离不开状态，每次梳理完流程图之后我都**直接将状态图一并完成。所谓状态图就是描述一条业务数据从开始到结束经历的不同状态，还以项目登记为例，其状态图如下：

2. 分析需求，梳理项目功能架构

当业务流程清晰之后，功能架构就很容易梳理了。首先，需要根据业务流程拆分功能模块，由以上流程的出项目登记模块有：新增申请、提交申请、审核申请三大功能，既然有新增就要有删除、编辑。所以项目登记的功能结构图如下：

以上示例中只是某个系统的一个小模块的功能架构，一整个系统的架构就是要将每个小业务模块的架构整合起来再加上基础支撑模块，如：个人中心，消息管理等。

3. 分析需求，梳理项目信息架构

完成了功能架构接下来就是信息架构啦，日常工作中很多小伙伴都将信息架构和功能架构放到一起，我最初也是适用的这种方法。信息架构和功能架构拆开或是合并只是工作习惯不同，大家可以适情况而定。我是感觉将其分开更清晰，方便查缺补漏，所以**分开来搭建功能架构和信息架构。在G端工作中信息架构重要的组成部分就是甲方爸爸给到的业务申请单，所以大家在调研时一定要记得要一份线下的业务申请单哈。项目登记信息架构如下（只是作为示例参考，实际信息架构要比这多很多）：

4. 分析需求，梳理权限表

G端业务还有一个特点就是涉及部门较多，一个流程可能涉及7，8个部门，每个部门的职责又相同，这个时候清晰的权限划分就显得尤为重要。经历过多个政务项目后，我也总结出了一个比较通用的权限表分析给需要的伙伴。

图1为模块权限表，可以用来表示某角色是否可以使用某模块。

图2为操作-状态权限表，可以表示某角色在某状态下是否可以进行某操作。对于涉及状态多、角色多、操作多的业务，这种权限表可以很清晰的表示出来并且不**遗漏。

三、分析后-整理分析材料

当我们完成需求分析工作后，还有一项工作就是整理材料，同步给项目组成员。许多大型项目涉及人员较多，产品小组就****过3个人，这个时候同步需求材料就变得尤为重要。当负责每个业务的产品都完成需求分析后，需要将分析材料同步到在线协作文档中，做到实时同步，当然这期间若业务间有数据交换的要及时沟通，并且得有一个产品负责人掌控全局，了解每块业务的关键节点。

本文由@与尔同愁 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议