5000字教你写ToB产品需求文档
编辑：[db:作者] 时间：2024-08-25 06:10:34
从各大招聘市场来看，B端产品经理需求日渐兴旺，越来越多的产品新人和C端产品转而投入了toB行业。在这样的大背景下，越来越多的产品新人须要学习如何撰写B端产品需求文档（以下简称PRD：Product Requirement Document）。
那么，B端产品PRD到底好不好上手撰写呢？
答案是否定的。最近，笔者在招聘产品演习生时创造了这样一种征象：大部分演习生的初作品都是环绕校园生活的C端产品，鲜有B端产品文档；纵然有一部分新人报名参加了一些产品培训，其作品也大多以C端为主。
这个征象从侧面解释了看重交互和用户体验的C端较好入门，由于产品经理本身就可以考试测验代入角色进行体会。而角色权限浩瀚、业务庞乱、流程繁芜的B端产品则为新人树立了一道无形的门槛，只有厘清和理解业务之后，才可能撰写出一份高质量的B端PRD。
因此，笔者想和刚刚入行B端亦或是头疼写文档的你分享自己的PRD框架，帮助你又快又好地撰写一份高质量PRD。此外，还会额外与大家分享2个非常实用的PRD撰写小tips，帮助你在担保质量和准确度的条件下，提升撰写速率。
话不多说，直接上干货。
一、我们为什么要写PRD？
PRD的实质是文档，而文档的实质只是大脑产物的一种承载形式。那我们为什么不可以利用口述、绘制草图等办法来进行沟通和信息通报呢？
并不是弗成，在产品初期和团队职员较为精简的情形下，有些公司会利用口述和手绘草图等办法进行沟通。但随着韶光的流逝和团队成员的壮大，这些办法不便于大范围传播和归档，而落笔有声的文档则可以肩负起记录、参照和流传的任务。
因此，当达到一定的产品和团队阶段，我们就须要通过PRD来担保多方目标和需求理解同等，让全体迭代有条不紊的运行。
那么，我们写产品需求文档是为了让读者理解什么呢？
首先，B端PRD的读者和C端有很大差异。
B端PRD的读者除了研发、老板之外，还包含需求方。不同于C端，B真个用户每每是较为明确的一些职位和角色，他们会直接将一些需求和问题反馈年夜公司的发卖或是客服团队。这就意味着，公司内的发卖部门、业务部门、客服部门等都会是用户or客户的传发话器，从而成为我们的需求方。
其次，只有明确了读者范围，我们才能写出他们真正须要理解的内容。在参考一些前辈的思路之后，我们须要向读者通报下列3个方面的内容：
我们在办理xx用户在xx场景下的xx问题；我们利用xx资源、提出了xx方案，并期望收成xx结果；实现这个方案给我们带来了xx代价（用户代价、商业代价、公司代价）。在上述3点中，上游的需求方（客户、发卖部门、客服部门等）须要重点理解我们在办理哪些用户的问题？场景是什么？大致的办理方案是什么样的？下贱的实现方（研发、测试等）则须要大致上理解用户的需求场景，并重点关注实现方案及迭代目标。
二、PRD框架及内容
前面向大祖传递了PRD的代价和目标，第二部分就来和大家细讲一下如何组织PRD的内容、每一部分的侧重点是什么以及若何才能又好又快地撰写一份B端PRD。
如下图所示，笔者的B端PRD框架整体分为三大模块：项目信息、需求&调研、方案信息。下面我们分别就3大模块进行详细先容。
1. 项目信息
一次迭代便是一个小项目。因此，这里的项目信息则是我们从项目经理的角度出发，向各方阐明本次迭代的总体方案、团队资源及职责、并对干系评审及变更做出记录。
1）迭代职员
按照不同职责列出项目迭代卖力人及成员，并明确各个成员的职责。
2）评审记录
用户记录需求评审的里程碑会议及结论。这里须要提醒大家一点，写需求评审记录时除了记录那些确定要做的需求之外，还须要记录确认不做的需求并只管即便解释决策缘故原由。
记录决策缘故原由是一个帮助我们回顾和复盘的好方法。依据几个月之前的决策思路，我们能很快回顾起当时的出发点，在比拟当前的实际现状之后，能更好地寻求发展和打破。
3）变更记录
用于记录迭代正式开始后的需求变更，便于追溯和复盘。个中，变更类型包含但不限于产品遗漏、逻辑设计毛病、研发评估遗漏、老逻辑影响、新增业务、临时方案赶工、版本拆分等等。
2. 需求&调研
利用金字塔事理，我们先和大家同步了项目的大致方案，让大家心里有了一个底。这一部分，我们就来和团队同步我们是「在办理谁在什么场景下的哪些问题」？
不同于模棱两可、千人千面的C端产品，B端产品每每有较为明确的需求方和用户。那么，我们还有必要向团队再阐述一遍需求到底是什么吗？
当然有必要。
一是由于实现方（研发、测试等）对需求不理解，我们有必要向他们通报需求场景，帮助他们更好设计和架构业务。
二是由于需求方口述出来的并不一定是客户真正的需求。客户每每会提出一个在他们认知范围内较好的办理方案，见告需求方“我们缺这个功能、我们想要这个功能、没有这个功能弗成”。但在真正理解之后，我们每每会创造客户真正的需求不在于此，可能通过别的功能还能更好地办理问题。
这就解释我们须要对需求方网络来的客户反馈进行二次甄别和挖掘，终极再到PRD中把问题背后的实质阐述出来，而仅仅照搬用户反馈则是一种极不负任务的行为。
如下图所示：在需求&调研部分，我们将整体的内容划分为调研信息和需求场景2大模块。
一次迭代的调研信息可以分为用户调研和竞品调研，如果还包含其他类型的调研（例如行业调研），可自行加入个中）。
1）用户调研
需求来源于客户。因此，我们要先通过调研客户来初步理解需求。调研报告的内容包括但不限于韶光、调研工具、调研数量、客户类型、调研结论、调研职员等，详细视实情而定。
2）竞品调研
心腹知彼，百战不殆。在动手实现之前，我们更须要对竞争对手的情形进行调研。竞品调研内容包括但不限于调研韶光、调研数量、竞品名称、调研结论等。
这里插一句，常常有人会问竞品调研有没有什么模版，须要做哪些事情？答案实在就一句话：调研只是手段，只要明确了调研目标，从而也就确立了粒度和内容。
3）需求场景
在通过问卷、访谈、不雅观察等调研手段之后，我们便能够初步归纳出用户的需求场景。当然，只有产品经理知道是远远不足的，我们还须要将这些成果同步给团队，担保让大家就需求场景的理解达成同等，即见告大家我们在办理xx用户在xx场景下的xx问题。
这里，笔者推举用户故事和用例图2种工具。
故事每每充满感情，更立体也更随意马虎打动人。因此，用户故事User story是从感性的角度出发，让我们向大家讲述一个范例用户的故事：他们是一群若何的用户、他们在什么场景下碰着了什么问题、他们的感情若何、现在他们是怎么处理这些问题的。
而源自于UML的用例图则更为理性。它能清楚地见告研发本次迭代中涉及到哪些角色、每类角色的需求及边界、不同需求之间的关系是什么等等。
通过第二部分的需求&调研模块，能够帮助团队成员在脑海里树立一个亟待办理问题的用户形象出来，我们能够知道他有哪些问题、也能考试测验感知他的感情。
3. 方案信息
方案指我们须要做哪些功能来帮助用户办理问题。从篇幅上来讲，方案信息是全体PRD的大头部分，也是新人最为关注的内容；但随着履历的增长，处于实现层的方案文档撰写能力将逐渐转化为一种根本能力，而不是竞争性能力。
可能有些人会对文档撰写不屑一顾，但笔者认为这是产品经理对外的第一张名片。产品经理本身是一种无授权的团队leader，我们须要通过递出一张张合格乃至精良的名片来建立团队影响力和信赖感。因此，一个好的文档撰写能力至关主要。
我们将方案信息划分为3大版块：方案方案、方案内容、埋点信息。
1）方案方案
在动手开工之前，我们先须要向团队讲清楚这一次我们大致准备怎么做。方案方案的内容包含但不限于分期方案、知足场景、需求清单（粗略版）、目标代价、衡量指标、风险评估等。
分期方案：B端客户的需求每每庞乱而繁芜，当我们面对的客户群体标准化程度较低、个性化需求较多时，可能会选择分期办理、小步快跑，先知足核心主流场景，再逐次完善分支非常场景。以是，当我们决定分期办理问题时，就须要提前向大家奉告清楚。目标代价：指该方案上线后能够为用户带来什么代价、给公司又能带来什么样的商业代价。衡量指标：常言之，无法衡量就无法优化。因此，我们须要明确出1-3个能够真正衡量方案代价的指标，便于我们未来进行优化和迭代。风险评估：指迭代上线前，须要对全体迭代可能遭遇或造成的风险进行评估，包含技能风险、用户体验变更风险、数据修复风险、并发风险等。笔者曾经有一次惨痛的迭代教训就和短缺风险评估有关。那次迭代是对原有的一些“糟糕”交互进行了优化，当时并没有考虑到是否会对用户原有利用习气造成影响，终极上线后，“收成”了一大批的负面反馈。如果能提前对此有所评估，大概就会考虑通过一键切换回旧版本等一些缓和性的方案来进行平滑过渡了。
2）需求清单
需求清单指我们须要知足哪些需求、各需求的优先级是什么样的。个中包含但不限于需求名称、需求描述、需求类型、所属模块、优先级等。
需求名称：指核心需求的简称、需求描述需解释详细的功能范围及内容。需求类型：分为功能、优化模块：指该核心需求所归属的业务模块需求优先级解释：P0-优先级最高的需求；P1-版本核心需求；P2-与核心需求存在关联关系的业务调度；P3-其他调度需求；T0-承诺上线需求（优先级分明，避免全部需求都为P0）。3）业务架构/流程
业务架构：描述业务的整体架构、业务模型、数据关系等（选写，视版本所需确定）业务流程：前后端通用的核心业务流程绘图标准：基本符合主流绘图标准，关系/条件描述清晰无歧义。关于业务架构/流程这里，笔者推举3种比较常见的UML图：活动图、状态机图、时序图。活动图：按照韶光顺序将活动的逻辑整理出来，与我们常见的流程图类似；状态机图：环绕一个事物的状态为中央来讲述流程；时序图：在描述流程时，能够清晰地定义角色的详细职责边界和通信交互；详细UML的先容，可以参考此前笔者写的这篇《一文办理产品经理对UML的全部疑问》。
4）页面解释
在描述好业务逻辑之后，就须要对页面中的元素、组件、交互进行一定的解释。C端产品经理每每会花费较多的韶光在于细节体验和交互之上，而B端产品则全然不同。
由于toB行业业务逻辑弘大、流程繁芜，产品经理的核心要务便是梳理业务和流程，交互和体验则更多是锦上添花的浸染。用一句客户的话来说“业务都跑不动了，细节做那么好有什么用？”因此，对付B端产品经理而言，我们要合理分配好文档中业务流程和交互体验上的精力。
在写页面注释这里，笔者为大家供应2个非常实用的小tips，帮助你在担保质量的条件下节约大量的韶光。
Tip1: 将重复逻辑创建为一个母版master
Axure中的母版可以大略理解为公共元件模板，将母版运用到相应页面中后，母版内容或样式发生变革，那么引用母版的页面内容或样式同样会随着变革，常用于制作页面头部或底部内容。因此 ，母版master常常被我们用于创建一些组件样式或标准页等，例如web端标准底页、iPhone6标准底页等。
但是，笔者这里要分享的是将一些重复性的逻辑也可以整理为母版。选中某段注释笔墨，右键点击创建母版Create Master，即可天生如下图所示的逻辑母版：
这样做有什么好处呢？
① 重复的组件或模块的逻辑注释只用写一遍，第二次第三次直接拖拽母版利用即可，无须多次重复撰写。
如上图所示，若一次迭代中有3、5处都须要显示这个冲突提示气泡，那么我们只需写一次，后续直接找到母版拖拽到页面里即可。
② 文档免不了要多次修正，那么当这些重复逻辑一旦被修正，我们就只能挨个去穷尽，而且很随意马虎涌现遗漏。
但是如果利用了注释母版，那么只须要在母版处一次修正，剩余引用母版的逻辑注释部分将自动变更。不仅减轻了事情量，更能帮助我们避免遗漏、担保重复逻辑的统一性。
Tips2: 将标准化组件的逻辑注释整理为元件库libraries
我们常常会去Axure社区及各大资源平台搜集各式各样的元件库lib，例如element、antd、iOS、Android的标准元件库等，方便自己在画图时可以快速进行样式引用。
而B端产品以PC端、Web端为主，样式整体较少（以表单、tab、列表等为主），同时相对较为标准化。因此，我们不仅可以将这些标准化组件的样式整理为元件库lib，也可以将这些组件对应的逻辑注释整理为元件库lib。
如下图所示，当我们页面中碰着一个下拉菜单的选项时，就可以直接拖拽元件库中对应的注释到页面中来。
通过提炼各种筛选组件、搜索组件、表单组件等的逻辑交互，不仅能够提升我们对前端组件的抽象理解能力，同时在撰写文档过程中也可以拖拽即用，能够大大减轻事情量并帮助我们避免逻辑遗漏。
5）埋点解释
埋点解释包含但不限于埋点人群、事宜、触发条件、对应业务代价、指标预测及后续方案等。这里就不展开讲了，但埋点的重点是一定要先想好埋点的目标是什么，然后再去规定对应指标。
That’s all～以上便是笔者对B端产品文档的一些思考和小诀窍。
本次分享的初衷是给大家供应一个思参考，最建议的办法是在积累一定履历后花1、2天做一个适宜自己业务和利用习气的模版及元件库。文档不是终点，而是出发点。善用工具，能够帮助我们开释大脑、留出更多的韶光进行思考。
本文由 @Neeko酱 原创发布于大家都是产品经理，未经容许，禁止转载
题图来自Unsplash，基于CC0协议
本站所发布的文字与图片素材为非商业目的改编或整理，版权归原作者所有，如侵权或涉及违法，请联系我们删除，如需转载请保留原文地址：http://www.baanla.com/rsq/151071.html
上一篇：电商进货来源工厂义乌批发地址汇总
下一篇：返回列表