C端产品经理经常谈及明确目标用户、用户细分、用户画像等词汇，在B端产品中，明确干系人工作与C端产品的用户细分工作相似，但在B端产品中干系人又不仅是系统的用户。

干系人种类

干系人主要包括：出资者、使用者、评价者。

出资者通常不是产品经理来搞定，由销售人员或企业高管来直接对接，出资者在实际执行中不会直接向产品经理提需求，而是经由销售人员或企业高管来转达需求。通常出资者如果有需求的话，也都是定性需求，如系统可以提升业务效率、系统安全性应该有保障等，很少会出现具体的、定量的需求。

使用者同C端产品的用户类似，是未来会直接、间接使用系统的人，此处采用的描述是系统而不是软件，因为如果产品采用私有化部署的方式，干系人中不仅会包含软件的使用者，还会包含系统的运维人员，运维人员会提出一些系统的部署、维护方面需求。

评价者主要指会提出一些验收标准但又不使用系统的人，如法务、采购、财务等部门人员，有时他们还会具有一票否决权。

干系人细分

对上述三类干系人，进行干系人细分，细分的方式通常不像C端那样花俏，通过需求、用户行为、态度、价值观等角度进行用户细分，B端的干系人细分方式一般是通过岗位来细分，如使用者中，销售经理、销售主管、运维人员等。

二、需求采集

C端产品的需求大部分来源于如下途径：竞品分析、用户访谈、用户行为观察、问券调查、用户反馈、可用性测试、数据分析，其中一些需求采集途径和B端产品是通用的，如用户访谈、问券调查，但也存在不适宜用到B端产品中的需求采集途径。

例如C端产品利用数据分析来进行用户的需求采集，在B端产品中，软件开发公司有时是拿不到数据的（如私有化部署的系统），没有办法去进行数据层面的剖析。另外更重要的原因是数据分析花费的人力、时间成本较高，多数情况下，系统验收完毕之后，首款已到账，此时已没有动力去帮客户进行高成本的数据分析，只有客户提出系统更改需求后才会去进行版本迭代。

再例如竞品分析，B端产品的竞品轻易情况下是试用不到的，即使通过某种途径试用了竞品，不同客户之间的需求也存在差异，B端产品中，通过模仿竞品来设计产品是轻易走不通的。

B端需求采集途径

B端产品的需求采集途径主要包括：干系人访谈、问券调查、业务体验、原型演示、中期演示等。

干系人访谈配以问券调查是需求采集的主要途径，可以是一对一的聊，有时也会采用需求调研会的方式来进行。

业务体验是高时间成本的方法，但也是最好的方法，如果可以把产品经理置于业务人员的角度去体验一段时间，一个优秀的产品经理是完全可以培养出业务人员的用户视角，否则单靠想象让产品经理具备B端业务人员的用户思维，是一个高难度的事情。

原型演示不容忽略，设计好原型后让干系人进行确定，避免开发出的产品与干系人设想的不符。如果有条件可以采用高保真原型，高保真原型可以让干系人进行可用性测试，若只采用线框图就让干系人来体验，在心理层面上，体验时的重视程度会有所降低。

很多项目在开发完成之前是有中期演示的，中期演示一来可以让干系人确保开发进度是如期进行中，二来也对产品功能的偏差可以做出及时调整。中期演示后需要做需求变更是一件高概率事件，干系人在项目开始时往往想不全的全部的需求点，在经历时间的发酵后，在中期演示后会进行添补。

三、深入分析需求

深入分析需求是对干系人的意图不断揭示和判断的过程，虽然是B端产品，但干系人也是真实的实体个人，此时和做C端产品的需求分析类似，用户在需求采集阶段只会告诉你what（即表达他的需求是什么），有时还会告诉你他所设想的how（即设计方案或解决方案），而不会主动告诉你why（即需求的产生原因是什么）。

产品经理的本能就是在需求采集和产品设计时，获得what后可以继续深挖why，进而得出how。在此C端产品的需求分析方法论在B端产品中是可以直接借鉴的，如可以运用苏杰的“Y模型”，“5W2H分析法”等需求分析方法论，即如何通过what导出how。

由于B端行业差异很大，每个行业、岗位的用户思维都不是轻易具备的，很难站在干系人的角度思考，所以对于B端产品经理来说，学习对方工作领域的知识，理解业务极其重要，需要具备将对方的语言工程化，将抽象的需求具体化的能力。这一点说起容易，做到还是有一定难度的，可能某个B端5年的产品经理，跨行业后都没有该行业内1年的产品助理更加懂行，所以通用的需求分析方法论很重要，深入行业也很重要。

控制需求

C端产品讲究按需求的优先级排列，排列方式如KANO模型的基本型、期望型、兴奋型、无差异型、反向型需求，或四象限法则的紧急重要、紧急不重要、不紧急重要、不紧急不重要。到了B端就没那么多排列方式了，只有一期，二期，三期可以进行争取，和客户去提什么是MVP原则，通通不起作用，想把客户的需求安排滞后，销售经理都不会同意。

B端产品在需求控制方面，需要做到识别错误需求和识别超出范围需求。错误的需求包括技术上无法实现的、逻辑不符的、无实际意义的需求内容，避免被干系人的天方夜谭带跑偏。在判断需求是否超出范围，需要先严格执行合同或者标书中的标准，但有时合同签署的会比较空泛，就需要在需求采集阶段先同客户共同明确项目目标，以目标为基准判断需求边界，在客户提出跨越边界的需求时及时指明。

四、需求整理

需求整理需要对每一类细分的干系人，找出一个（觉得有必要可以找多个）最具代表性的人选，进行干系人画像。例如我们采访了3个销售经理，选择了一个最具代表的销售经理，将所有销售经理的需求内容都整理到该干系人画像表格内。画像信息可以包括基本信息、干系人关注信息、其他信息。

（1）基本信息：主要包括岗位、代表、角色、岗位职责、系统使用频率、影响程度（对项目的影响程度）、联系方式等。

（2）关注信息：主要包括需求点（可以标注需求实际来源）、阻力点（例如领导的需求，加入监管功能，对员工来说就是负需求；业务部门的易用性需求，对安全部门可能就是负需求）、重要程度。

（3）其他信息：包括便于站在干系人角度思考的信息，如教育背景、所学专业、对信息化的理解程度等。

示例：

岗位（销售经理）、代表（销售经理A王某）、角色（使用者）、岗位职责（市场拓展、客户关系管理）、系统使用频率（高）、影响程度（高）、联系方式（13988888888）。

需求点1（新增客户关系），重要程度（高）。需求点2（避免同一客户被多个销售同时联系，该需求来源于销售经理B李某），重要程度（中）。

教育背景（大学），所学专业（通信工程），对信息化的理解程度（理解程度较高）。

五、软件设计

在软件设计方面，B端产品和C端产品的差异性就相对较大了，B端产品不会像C端产品一样，设计时讲究简约设计，让用户“不等不想不烦不学”，花大力气请UI同事进行页面美化。

B端产品经理在经历了和干系人的若干次“美好”沟通之后，交互上能把尼尔森十大可用性原则都遵循了，就算是有良心的产品经理或UE设计师了。界面美化方面，B端产品多数情况下都是在套用模板，很少会动用UI设计师来定制化界面风格。

B端的软件功能设计，本质上就是对数据的输入、加工和输出的过程，操作上通常是在围绕数据的“增删改查”来进行，再配以相应的规则和约束条件。在软件需求说明书中，产品经理会以模块用例和原型的方式进行表达。

模块用例一般包括背景描述、用户、前置条件、后置条件、主场景、扩展场景、规则等内容。

5.1 背景描述

背景描述是不用多说的内容了，无论B端产品还是C端产品，为什么要增加一个功能，即使是拍脑袋想出来也需要给出一个合理的解释。可采用“用户-需求-收益”的模板来描述背景，例如作为销售主管，希望添加销售机会管理模块，这样就可以动态分配销售机会给有具备优势的销售经理。

5.2 用户

用户是指具有操作特定模块权限的人员，一般会用有UML的用例图来表达。例如，CRM系统中，销售主管具有销售机会管理权限，而销售经理没有该权限。

5.3 前置条件

前置条件指需要满足什么条件下，用例才可以被执行。

例如，销售主管分配销售机会的前置条件为“存在未分配销售机会的客户”，如果添加这个前置条件，就表明系统对“已分配销售机会的客户”，销售主管不可以再进行分配销售机会操作；如果不添加这个前置条件，就表明销售主管可以对所有客户分配销售机会。不添加这个前置条件的不好之处在于，如果销售主管已分配某客户给销售经理A，几天后又重新分配给销售经理B，若销售经理A未及时查看系统，会存在两个销售经理同时在联系同一客户的情况。

若一个系统为不可采用游客方式访问的系统，只有登录后才可以进行所有的操作，那么“已登录”可以不用写到前置条件中。

5.4 后置条件

后置条件是指用例执行结束后的系统状态，系统会有哪些变化。例如，销售主管在完成指定客户分配后，该客户状态需要从未分配变更到已分配，对应的销售经理账号下，跟踪客户的数量需要相应增加。

5.5 主场景

主场景是软件的主要执行流程，也见称为“基本路径”。根据二八法则，主场景数量虽然会少于扩展场景的数量，但主场景的使用率一般会占到80%以上。例如新增客户关系中，主场景就是按照规则将客户关系输入完整，点击保存按钮。其中客户关系输入的内容可以采用原型展示，也可以在“5.7规则”中描述。

5.6 扩展场景

扩展场景是主场景之外的分支，也见称为“扩展路径”。例如在用户登录中，主场景是用户输入用户名、密码，点击登录，验证成功，进入系统。扩展场景是如果用户密码输入错误，或者用户忘记密码的处理流程。

5.7 规则

规则是指用例用到的业务规则、逻辑算法等。例如在搜索查找客户时，模糊查找的规则是什么。

5.8 非功能性需求

非功能性需求是指产品为了满足用户的业务需求而必须具备的除功能之外的特性，其和功能性需求是相辅相成的。非功能性需求是软件产品的必备部分，但非功能性需求却常常被忽视。

有些非功能性需求产品经理和开发人员会达成一种默契，即使不提明确的需求内容，也会按照大家的共识来开发交付。但如果客户有特别强调或产品经理认为有必要特别提出的非功能性需求，需要定量、详细地描述出来，不可出现理解偏差或模糊性描述。

非功能需求中，常见的错误就是模块性描述，例如采用定性描述，写高易用性、高安全性类似的描述。其二常见的错误是无根据定量，拍脑袋写标准，例如所有查询请求需要在3秒内响应完成。

在定义非功能需求时，可以套用SMART原则，即有具体明确的指标（Specific），指标是可测试，可证明，可以衡量的（Measurable），目标是可以达到的（Attainable），与功能性需求具有一定的相关性，可以说明问什么会存在这个非功能性需求(Relevant)，明确的截止期限（Time-bound）。

按照卡尔·魏格斯在《软件需求》中的定义和划分方式，非功能性需求分为外部质量需求和内部属性需求，具体描述如下：

外部质量

易用性：当在某时某地需要系统服务时，系统服务能够被有效访问的程度；用户对系统的学习、记忆和使用的难易程度；

可安装性：正确安装、卸载和更新安装应用的难易程度；

完整性：防止系统数据错误以及数据丢失的程度；

互操作性：系统与其他系统或者其他组件互联或者交互数据的难易程度；

性能：系统响应用户输入或者其他事件的快慢程度以及可预见性；

可靠性：在故障发生之前，系统正常运行时间；

健壮性：系统如何应对非预期的操作； 

安全性：如何防止系统被破坏性损坏；

防护性：系统如何阻止对应用及其数据的未授权访问；

内部属性

有效性：系统使用计算机资源的效率；

可修改性：维护、修改、改进以及重构系统的难易程度；

可移植性：使系统能够在其他操作环境中运行的难易程度；

可重用性：在多大程度上能够把组件使用在其他系统中；

可扩展性：随着用户数量、事务、服务器或者其他扩展，系统能够随之适应的难易程度；

可验证性：开发和测试能够对软件进行验证以查看软件是否已正确实现的便利程度。

写在最后

关于需求文档的编写，在实际工作中，不同团队会有适合自身的特定模板，有的团队要求细节描述详细，有的项目团队可能要求描述简单即可。其实文档的内容和模板都不是主要的，表达清晰、无模糊性、可做出来才是项目的首要任务。每种编写规则都无所谓对与错，适合团队的方式才是最好的。