当前位置: ManBetXapp > 百科 > 教育 >正文

需求文档怎么写

人气:404 ℃ /2023-03-02 01:51:28

很多产品新人入门产品时,最想先了解的都是如何画原型,如何写需求文档,今日小编就来和大家分享需求文档的写法,希望能帮到大家。

需求文档写的方法是:

1、需求背景与目标说明。得让别人知道为什么要做,要做到什么程度,用户检验功能完成情况。

2、特性列表。所谓特性,其实就是功能模块,把需要做的功能模块都罗列出来,主要用于明确需要做的功能有哪些,用图表体现更佳。

3、拆分标准。内部逻辑(不同的功能模块,不同的页面)、重要的特性单独列出。

4、主要逻辑。每个特性之下的操作逻辑,简单特性可以文字说明,复杂特性建议用流程图表现。帮助梳理逻辑,减少细节遗留。

5、特性功能点。补充每个功能点的相关细节描述,是开发,与测试工作的重要依据。

开发需求文档怎么写

如何写一份「不坏」的需求文档?

需求文档是产品经理最重要的产出物,它的撰写占据了许多产品经理50%以上的工作精力。然而在实际工作中,依然会存在着诸多问题,这是什么原因呢?应该如何解决?本文作者对此进行了分析,一起来看一下吧。

需求文档是产品经理最重要的产出物,没有之一。许多产品经理在实际工作中,需求文档的撰写占据了 50% 以上的工作精力,即使投入很多精力,需求文档依旧存在诸多问题。如:

  1. 需求理解不清晰,挣扎在开发人员提出各种问题和重新沟通确认。
  2. 解决方案没有形成闭环,缺少异常流程,重复返工需求文档;
  3. 追求高保真原型,大量时间和精力花费在原型设计和交互,后期修改原型的成本高。
  4. ……

出现这些问题的核心原因,是产品经理把需求文档当成一份开发交付文档,而不是当成「信息传递工具」,重点不在交付,而在于信息传递

01 烦人的信息差

产品研发的信息传递,指需求方,实施方为了解决需求,进行需求和解决方案的信息传递过程。

需求文档,是承接产品信息的工具,最核心作用,是实现需求方,实施方的信息统一,减少因为信息传递问题,带来的「产品无法解决需求」 的情况。

信息传递面临核心问题的是:「信息差」

信息传递本质是信息编码再解码的过程,需求方将想要传递的信息通过媒介进行编码输出,传递给接受者,接受者再解析理解信息的过程。

原始信息在传递环节会存在不同程度的损耗,导致需求方和接受方在信息上存在的理解差距的情况,我们称之为「信息差」

导致出现信息差的原因很多,例如:

  1. 需求方没有清晰表达能力(编码问题);
  2. 文本沟通,没有选择沟通效率更好面对面沟通(通道/媒介问题);
  3. 接受者对接受的信息理解出错(解码问题);
  4. ……

信息传递必定存在信息差,产品研发又存在「多人沟通」的常态化现象:

  1. 需求方,人数不定,通常为老板,用户,产品经理等;
  2. 产品经理,一般情况 1 人;
  3. 技术方,人数不定,通常为前端,后端,测试等。

「信息差」「多人沟通」形成双喇叭型结构的信息传递模式,在横向传输上,拉长信息传递链。

即需求方编码 → 通道传递 → 产品经理解码 → 产品经理再编码 → 通道传递 → 技术方解码。

传递每个环节按 20% 的信息损失,至少有 70% 的信息在传递过程中被损失。

类似综艺节目的传话游戏,几个人站成一排,每个人都听不到前一个人说的话,只能通过前一个人的口型和肢体语言,猜测对方说的是什么,然后再传话给下个人。

一般到第三个人时,传递的信息和原来要传的信息是天差地别的。

纵向传输上,产品经理即接收多个需求方的信息,也向多个技术方传递信息。

一方面,多个需求方存在着多个需求,需求方往往传递自己认为可行的解决方案,不擅于阐述自己遇到的问题或真实需求。

产品经理需要花费大量精力辨别每个信息传递背后的真实需求,一旦有所疏忽,容易误解用户真实需求,掉入「用户说啥,实现啥」的陷阱,投入开发成本,但没有解决用户实际需求。

另一方面,产品经理要向多名开发人员传递思考后需求和解决方案,开发人员侧重于解决方案的实现可行性和成本,很少主动理解需求方的真实需求,主动与产品经理,需求方同步信息,减少信息差。

每个开发人员对信息的理解程度不同,理解需求和方案容易出现误差,开发过程中,容易出现以下问题:

  1. 开发环节,开发人员之间理解差异导致方案差异,例如:前后端人员理解不一致,导致接口缺失,无法联调;
  2. 测试环节,开发人员完成功能与测试人员测试用例不相符;
  3. 验收环节,开发功能与产品经理预期不一致,产品功能无法满足需求。

出现上述问题,产品经理不得不重复沟通需求,花费大量时间促使所有开发人员达成信息统一。

02 标准化需求文档

需求文档是对产品开发的信息传递问题的解决方案,好的需求文档是能让所有人统一认知,从而提高开发效率的利器。

需求文档的好坏受限于产品经理能力和经验,高水平的产品经理属于小比例人群,所以我们不要求每个产品经理输出高质量的需求文档。

但,随着岗位和行业深入发展,产品经理的工作出现标准化趋势,意味着我们可以输出「标准化需求文档」,保证需求文档的下限,统一上下游对需求认知,减少信息传递过程的损耗。

标准化需求文档包含 3 个部分:文档结构化,绘制标准化,功能描述标准化

1. 文档结构化

按照产品经理的工作流程,我们将需求文档的作业流程分为 4 项内容:「需求介绍」,「解决方案」,「修订记录」,「其他事项」。

各项内容都有各个细项,会在后续章节进行讲解,不再赘述。

2. 绘制标准化

绘制标准化,核心掌握是流程图的绘制标准化和低保真原型快速输出。

产品经理在流程图上经常犯 2 个问题:

一是多数产品经理为非科班入行,很少掌握流程图的规范,容易绘制错误规范的流程图,被开发人员按正确规范误解。

产品经理不需要掌握流程图所有绘制规范,只需要掌握 10 个常用简单绘制规范即可。

二是不考虑异常流程,异常流程分为 3 大类:

  1. 全局型异常流程,指在系统全局都会出现的异常流程;
  2. 功能型异常流程,指在功能操作和规则上出现的异常流程;
  3. 业务型异常流程,指正常业务过程中,发生不符合预期的业务流程。

不同类型异常流程应用,我们会在后续「流程图篇」进行讲解。

产品经理在原型绘制上避免追求高保真原型和原型交互设计,需求文档的核心是传递需求信息,只要能达到目的,低保真原型和无交互设计都可以。

相仿原型和交互设计精细度越高,意味着我们投入原型设计的时间越多,理解和传递需求时间越少,本末倒置。

如何在极短的时间内输出一份低保真原型,我们会在后续「原型篇」进行讲解。

3. 功能描述标准化

功能描述是产品经理码字最多的地方,也是开发人员理解和落地功能点开发的根据。

开发人员在功能点出现理解误差的主要原因,是功能描述不标准,即遗漏功能点。

我们以信息流「下滑加载」为例,用户通过「下滑加载」功能获取信息,我们怎么写这个功能点?

搜索更多有关“ 需求文档怎么写”的信息 [百度搜索] [SoGou搜索] [头条搜索] [360搜索]
CopyRight © 2008-2024 ManBetXappAll Rights Reserved. 手机版