Java微服务一份征服领导的需求文档(直接下载)

Java微服务一份征服领导的需求文档(直接下载)

上个月，群里面有一位朋友在报喜。说他按照我建议的方法编写产品需求文档和方案文档，结果领导非常满意。最让他高兴的并不是领导的表扬，而是他第一次拥有了“独立掌控项目”的感觉。

我常说，优秀的产品经理一定可以写出优秀的产品文档。原因在于，产品文档是产品思路的展现，同时，也反映了一个产品经理的职业态度。

那么，优秀产品文档的标准是什么呢？今天我们就以产品需求文档为例做一个简要的讲解。

01 需求文档要点

一份优秀的需求文档，必须符合3个要点，分别是：

• 结构清晰
• 深入业务
• 聚焦重点

1）结构清晰

结构清晰主要体现在三个方面，具体包括：

• 由总到分

优秀的需求文档，不会一来就讲具体的业务。而是首先从全局出发，先对企业业务进行概览性的介绍。

比如，首先介绍企业的组织架构、业务模式等，这可以帮助我们对客户需求的背景有更深刻的认知。

• 由高到低

和C端产品不同，B端产品的用户往往是一个结构化的群体，包括了决策层、管理层和执行层等，而这些角色面临的问题、对产品的诉求都存在较大差异。

优秀的需求文档，会全面调研相关干系人：从了解决策层的需求开始，逐步下沉到执行层。

• 由内及外

在移动互联网时代以前，大企业已经基本完成信息化系统的建设。当他们采购SaaS产品以后，就必然要求将SaaS产品与现有系统整合，从而提高全局效率。

因此，产品需求文档在梳理产品涉及业务流程的同时，也必须考虑到可能需要集成的其他系统。

2）深入业务

深入业务主要体现在两个方面：

• 究竟精神

对于大部分用户来说，他们毕竟不是专业的IT人士。因此，他们往往善于提出自己的期望，但并不善于结构化的梳理和表述需求。因此，如果产品经理简单的对需求全盘接收，往往只能看到需求的表面，而看不到需求的本质。

比如，采购员抱怨车间生产计划变动太频繁，导致采购计划不得不临时调整，增加了与供应商协同的难度。他们可能认为车间生产计划就应该在一定期间内强制冻结。但实际上，生产计划的不稳定可能有多种原因，比如，销售公司临时调整订单等等。这种情况下，车间根本就不可能冻结生产计划。

• 不止于需求

一般来说，SaaS产品主要负责对企业业务进行支撑。

比如，快消品企业希望管理销售人员的外勤拜访任务，SaaS产品就可以提供拜访计划、拜访任务等功能。

但是，对于企业来说，产品只是一种辅助手段，要实现“解决业务问题”的目的，往往还需要在管理、流程、策略等方面进行优化。

为了从根本上解决客户问题， SaaS产品经理不仅仅要熟悉产品设计，也要了解相关的管理知识和案例。

而这些知识和案例，在需求调研阶段就需要开始收集和梳理。

3）聚焦重点

什么是SaaS产品成功的标志呢？

从财务指标来看，是续费率和增购率；从产品指标来看，是核心功能的使用率。但是，从本质上来说，他们都只是结果指标。真正决定SaaS产品成功的，其实是“是否满足了客户的期望”。而客户期望又包括三个方面：

• 业务重难点

即客户购买SaaS产品，主要是为了解决什么问题。为了解决这些问题，又需要实现哪些关键功能，或者克服哪些关键障碍。

• 决策人期望

SaaS产品往往有具体的购买决策人，他们既然决定购买产品，必然是有其迫切想解决的问题。搞清楚这些问题，才有可能实现客户成功。

• 核心用户期望

决策层的诉求往往高屋建瓴、目光长远，但也因此缺乏对执行细节的关注。而SaaS产品毕竟需要落实到具体的操作层，因此产品经理也需要梳理和满足核心用户的合理期望，这样才能实现“上下同欲”，克服SaaS产品应用的障碍。

以上三个方面，都是需求调研的重点，需要在需求文档中进行阐述。

02 业务概述

优秀的SaaS产品经理，同时也是一个优秀的解决方案专家。因此，他在梳理需求时，并不会一开始就陷入需求细节，而会首先从整体上对客户组织架构、业务模式、整体流程进行梳理，从而确保产品方案的高度和整体性。

具体来说，业务概述又分为3个部分，分别是：

• 组织架构与岗位职责
• 整体业务简述
• 整体流程图

1）组织架构与岗位职责

梳理企业的组织架构与岗位职责，主要有两方面目的。

第一个目的是了解企业业务的分工与协作。

产品架构的本质，就是分工与协作。比如，为什么采购管理和销售管理往往是两个相对独立的模块？其实本质上是因为，采购和销售是两个高度专业的工种，因此企业往往会建立两个相对独立的专业部门。

我们一直说，产品架构要“高内聚、低耦合”，其实它也是反映了企业分工与协作的特点。

因此，了解组织架构与岗位职责，有利于正确的梳理产品架构。

第二个目的是调研功能与数据权限的管理需求。

分工往往就意味着功能与数据权限的隔离。比如，采购经理岗位和销售经理岗位，往往会分配不同的功能页面；而不同事业部的负责人，也只会分配对应事业部的数据权限。

当然，在实际业务中，功能与数据权限的隔离往往不会如此简单清晰。比如，某高级副总裁，可能会分管集团的HR部门，同时又分管一个独立的事业部。如果有类似复杂的权限管理场景，就必须有专门的多组织架构权限管理方案。

2）整体业务简述

虽然SaaS产品主要是对具体业务和管理的支持，但是决定这些业务和管理的，却是更深层次的业务模式、商业策略等问题。

SaaS产品经理要想对客户的业务和管理有更深入的认识，或者要想对客户更大的影响力，就必须了解企业的业务模式和商业策略。具体包括以下几个方面：

• 商业模式：客户如何实现盈利
• 产品种类：客户提供的产品与服务
• 行业地位：典型客户属于领先企业？还是追随企业？
• 销售网络：如何触达消费者以实现销售？
• 营销策略：如何促进收入增长？
• 销售规模：企业年销售数量、销售金额？
• 业务峰值：业务处理的高峰期

等等。

3）整体流程图

通过一个整体流程图对业务做一个概要的梳理，是非常有必要的。

一方面，通过梳理整体流程图，我们可以确保详细流程图不会遗漏；另一方面，整体流程图也便于内外部的沟通。不管是向高层汇报，还是和研发同事沟通，整体流程图都可以起到很大的帮助。

梳理整体流程图，还可以提高我们的大局观和整体感，并提高与高层沟通的能力。

03 业务详情

业务详情是产品需求文档的主体内容。

业务详情首先要与整体流程图对应，以确保没有错漏。比如，项目管理类SaaS产品的整体流程图，一般包括从立项到项目关闭的完整流程。那么，在业务详情部分，就需要分别对立项、项目计划、项目进度管理、项目关闭等各个主要环节进行详细阐述。

业务详情又主要分为三个部分：

1）业务规则

主要对业务管理规则和机制等进行文字阐述，比如销售价格核定逻辑、信用管控规则等等。

2）业务流程图

通过流程图对各岗位职责、协同关系进行阐述，也包括流程中产生的纸质单据，以及各流程之间的衔接等。

3）业务重难点

阐述各业务环节的重点和难点。这些重难点的解决，将在很大程度上左右客户使用SaaS的成败。

04 管理报表和系统集成

管理报表是决策层和管理层用于监控、分析业务的主要手段，因此必须在需求调研阶段进行明确。

同时，尽早梳理管理报表还有一个好处，就是提前检测SaaS产品的业务数据能否支持相关报表的出具。如果不能支持——考虑到决策层和管理层需求的重要性——则需要对产品功能及时进行调整。

除了管理报表，与第三方系统的集成也必须尽早进行调研。

05 用户期望

这是需求文档的最后一个章节，也是最重要的一个章节。

即便产品能够较好的支撑起相关业务，并且在稳定性、易用性方面无可挑剔，用户对产品的评价，可能仍然只有60分。

这里面的关键在于，“对业务正常支持”只能避免“客户不满意”；而只有满足了核心用户特别是决策层的期望，才有可能得到更高的评价，从而赢得客户的忠诚。

在调研用户期望时，越是牵扯面广的系统，越要注意不能遗漏。比如，对于业财一体化系统，我们既要了解财务部门用户的期望，也要了解业务部门用户的期望。因为他们任何一方对系统的态度，都能很大程度上左右企业使用系统的成败。

06 结语

我常说，SaaS产品经理要有结构化思维。那么，如何培养结构化思维呢？

以需求调研为例，如果你能按照本文的结构进行调研和文档编写，以及检查需求调研是否满足结构清晰、深入业务和聚焦重点等要求，那么就可以有效培养结构化思维。

最后需要说明的是，需求文档是方案文档的基础。

实际上，需求文档的结构和方案文档的结构，整体上应该是一一对应的。这样做的好处，就是让整个产品文档的思路非常清晰，这也是文章开始那位星友，为什么能得到领导认可的原因之一。