知识吧 知识资讯 如何写一份「不坏」的需求文档?

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

需求文档是产品经理最重要的产出物,它的撰写占据了许多产品经理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. 功能描述标准化

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

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

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

A. 用户可以在页面顶部向下滑动触发加载功能,每次加载获取下一页的内容,加载失败时,toast 文字提示:「加载失败~」。

作为对比,我们看另一份功能描述 B

  1. 触发方式:在内容列表顶部,用户通过从上向下手势触发滑动触发,滑动区域超过 1/6 屏幕生效,滑动过程显示滑动进度 icon,具体样式和动效以 UI 为主。
  2. 加载内容数量:每次加载,均可获取 50 条内容。
  3. 加载内容规则:将下一页未加载的内容,按照内容的与用户算法匹配值排序,展示匹配值最大发布的内容。
  4. 网络异常处理:网络异常状况下,执行加载功能后,Toast 提示「网络异常,请更换网络后再试」,并显示加载前的内容。
  5. 网络异常:无网络,弱网络,均视为网络异常。
  6. 请求超时:若服务器5秒内未返回数据,Toast 提示用户「服务器忙,请稍后再试」,并显示加载前的内容。
  7. 内容数量不足:加载时,若下一页内容超过 0 条,但小于 50 条,则返回所有的内容。
  8. 下一页无内容:加载时,若下一页内容数量为0,则Toast 提示「无最新内容,我们再加急生产中……」。
  9. 非正常加载:若是非正常加载,仅视为一次加载,加载过程中,Toast 提示用户「马上出现你想要的内容」。
  10. 非正常加载定义:监控用户加载频率,两次加载的间隔时间低于1秒,即视为非正常加载。

通过 A 与 B 两段功能描述,我们清楚看到 A 遗漏 8 点功能点,还有 1 点功能描述不清晰,这意味着开发和测试人员就一个功能,得和产品经理沟通 9 次以上。

功能描述标准化的最大好处,是减少产品经理和开发人员的信息差,减少反复沟通确认,让开发人员更多时间专注在功能落地。

功能描述如何标准化,在后续「功能描述篇」进行详细阐述。

03 最后的话

在文章最后,我们总结全篇核心内容:

  1. 需求文档的本质是:需求方,产品经理,开发人员之间需求和解决方案的「信息传递工具」。
  2. 产品开发主要沟通问题,是「信息差」+「多人沟通」导致信息不同步,容易做出无用产品。
  3. 高需求文档水平的方式是标准化,指「文档结构化」,「绘制标准化」,「功能描述标准化」。

后续的想法,希望通过 5-6 篇阐述需求文档的文章,帮助大家减少一点时间在需求文档和沟通上,

然后,2023 年多一点时间让自我成长。

作者:晓东同学;公众号:在地球的产品笔记

本文由 @晓东同学 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议

本文来自网络,不代表知识吧立场,转载请注明出处:https://zhishiba.net/1617.html
上一篇
下一篇

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

返回顶部

Warning: error_log(/www/wwwroot/www.zhishiba.net/wp-content/plugins/spider-analyser/#log/log-1501.txt): failed to open stream: No such file or directory in /www/wwwroot/www.zhishiba.net/wp-content/plugins/spider-analyser/spider.class.php on line 2900