我所理解的需求文档

需qiú文档是产品经理曰常工作输出最重要的文档,需qiú文档是在写什么?应当包hán什么内容?

nòng清这个问题,首先要明确需qiú文档的读者是谁,读者要从需qiú文档中获取到哪些内容,读者的不同影响到需qiú文档的X形式,而X形式又依赖于产品经理自身的xí惯,不可一概而论。

以下是我理解的需qiú文档该是什么样子的,抛砖引玉,供大家探讨。

需qiú文档最重要的读者首先是产品经理自己,无论是需qiú实现前用需qiú文档讲述需qiú的实现思路,实现时按需qiú文档进行设计、研发、测试,还是需qiú上线后回顾需qiú文档进行复盘总结,都是依照产品经理写的需qiú文档。其次的读者才是负责需qiú实现的设计师、研发人员、测试人员以及其他产品经理。

按我的xí惯,需qiú文档会包hán以下五个部分的内容。

一、需qiú变更曰志和版本迭代记录

第一部分是需qiú变更曰志和版本迭代记录。需qiú从提出到最终上线,中间必然经历一些需qiú变更或方案调整,因而需要有变更曰志来记录这些变更。

需qiú变更曰志并不只是写需qiú新增或减少了哪些功能,而是更仔细些。

例如:需qiú中的A功能点,原来打算用方案一实现,但考虑到资源、现实场景的X,改为用方案二实现,这个也要写,虽然从结果上看仍然是实现了需qiú中的A功能点,但从过程上看,方案一到方案二的转变,是产品经理思考的升级,也是对资源X更深的考虑。

此外还应记录清楚需qiú是因什么原因变更,变更前后是什么样子,可能会产生哪些影响,以便后面查找细节。

而版本迭代记录,除了包括对需qiú中功能的版本迭代,还应包括产品经理对这个需qiú思考路径的迭代。

需qiú中功能的版本迭代,这个大家比较熟悉,不赘述,主要想说明下产品经理对需qiú思考路径的迭代是什么?为什么要这么做?

之前提过,产品经理很大的工作是在做决策,因此决策质量很重要,而决策质量需要X不断地优化决策思考路径来提高,产品经理应该记录自己对需qiú的思考过程,对过程进行不断总结和优化。

另外,将这些思考的过程展示出来及与其他同事讨论,可以跳出自己固有的思维模式,兼容并包。

所以我一直认为产品经理在处理一个需qiú时,其思考路径、决策依据应该公开X,能够让所有参与需qiú的人都能够可查看、可探讨(来自瑞·达里欧,有兴趣的朋友可以去看看他的《原则》)。

那么,我输出需qiú变更曰志和版本迭代记录的过程是怎样的呢?

按我的xí惯,在输出一个需qiú文档的时候,会先按当下我能考虑的情况先写一个Beta版,这时候我将它命名为V0.7版本,然后隔一天我再重新思考,看自己昨天写的需qiú文档,这时能发现很多不足的地方,那就从头开始改一遍,标明需qiú有哪些变更,这时的版本是V0.8版本。

下一步找其他产品经理向他讲述一遍这个需qiú文档或在组内X一次需qiú评审,综合意见,再修改一遍,标明需qiú有哪些变更,这时的版本是V0.9版本,最后再找开发测试设计的同学进行需qiú评审,从开发测试设计的角度对需qiú的实现做一遍修改,标明有哪些变更,形成最终的版本V1.0。

这样下来,一份需qiú文档能够包hán产品经理对一个需qiú实现方案完整的思考过程,其中不仅有自己思考的升级,还有从研发、测试、设计等各个角度对实现方案的调整补充,是zhēn对这个需qiú,在当前的资源X、背景约束下最好的实现方案。

有了需qiú变更曰志和需qiú版本迭代记录,不仅可以做到需qiú的实现逻辑实现思路可溯源,完整记录整个需qiú从被提出到上线多个版本,期间的产品思路、实现逻辑有了哪些变化,产品经理可时常回顾拿来参考,产品团队可zhēn对大的需qiú做zhēn对性复盘,也可X给后来接手工作的产品经理了解需qiú的完整迭代过程。

二、背景&方案&价值

背景、方案和价值,是需qiú文档的核心,是任何需qiú在进入到实现阶段前一定要想清楚、一定要反复探讨的部分。

需qiú是背景下的需qiú。这里的背景,需要写明白的内容可包括但不限于当前产品所处行业的现状,产品/功能模块所处的状态、目标,开发团队的资源X、技术X等。

最开始做产品经理时,体验其他产品的一些功能,不免吐槽,这里怎能这样做?应该那样做啊,要是我的话一定能比他做得更好,诸如此类。

到后来做产品的经验见长,才明白任何一个需qiú都受限于当时的背景状况、资源X,抛开这些背景谈实现都是扯淡,产品经理要做的是在当前背景下,找到最jiā的实现方案。因此,梳理需qiú背景是产品经理对当前资源现状的考量,是实现需qiú的第一步。

方案是背景下需qiú的实现方案。既然需qiú会受到资源现状的X,那么方案也必然有所不同,甚至可能会有折中妥协,会有不完整的方案。有时需qiú本身就是试验性质的,是为了快速测试效果,那么在方案上选择一些实现简单、开发难度较小的方案也就不足为奇了。

在写方案时,可以按照「用户-场景-问题-方案」这个框架简要写明实现方案,也就是什么样的用户在什么样的场景下遇到了什么问题,X的解决方案是什么——这里要qiú方案要经过提炼,能够X一句话说清楚。

价值是指实现这个需qiú能够带来什么样的价值,包括用户价值和X价值,用户价值是指实现这个需qiú能够给用户带来什么样的价值,例如提升用户的使用体验等;X价值是指实现这个需qiú能给产品的X带来什么样的价值,例如提升用户留存或者提升X收入等。

需qiú不一定要同时X用户价值和X价值,也不一定两个价值都需要为正(例如带来很大的X价值而牺牲很小的用户价值也是可以的),具体需要依据产品当前的状态来考虑,但不能带来价值的需qiú一定是有问题的。

此外,在思考需qiú能够产生什么价值时,同时要思考的是以什么数据指标来评估这个价值,也就是需qiú上线后效果的好与坏要有量化的指标。不一定所有的需qiú都能够找到量化的效果指标,但一定要尽量找到这个指标。只有需qiú的效果能够被衡量,产品才能够往更优的方向迭代。

三、X逻辑&liú程说明&功能需qiú详述

第三部分主要是需qiú实现的部分,我把它划分为X逻辑、liú程说明和功能需qiú详述。

X逻辑部分描述的是需qiú中涉及到的数据liú向和用户liú向,特别是需qiú涉及到多个系统时,数据和用户在系统之间如何交互的(这部分的内容偏复杂,后面再单独写下我的理解)。

目前zhēn对X逻辑部分,我主要的输出是多通道的泳道图来描述系统间的交互。这里应该特别注意的是在说明数据liú向时要兼顾考虑正常liú程和异常liú程,以及在说明用户liú向时要考虑清楚需qiú边界。

此外,需qiú的复杂程度不同,可能还会包hán页面liú程图、页面结构图等。

功能需qiú详述就是常说的原型。

我目前的xí惯,在需qiú文档的早期版本不喜欢输出高保真的原型,而是倾向于用低保真原型加X描述的方式来说明需qiú中的功能实现。

功能需qiú详述以需qiú中的页面为单位,分为原型图、需qiú说明和交互说明三个部分。

原型图对需qiú涉及的每个元素进行标注;需qiú说明zhēn对原型图中的标注进行X说明,包括字段逻辑、按钮逻辑、页面逻辑等;交互说明则是zhēn对一些非逻辑的交互进行说明,例如某些字段、需要突出显示,页面变化时需要怎样的特殊效果等等。

四、相关文档的X

曰常工作中,时常出现想要找需qiú的某个相关文档时,四处搜索,浪费很多时间的情况,为此我形成了一个xí惯,就是把需qiú文档作为一个所有相关文档的X。如埋点文档、设计稿、接口文档、测试用例文档、开发相关的链接、上线后的数据等,都以链接的形式整理在需qiú文档中,这样每次需要找需qiú的相关文档,都可以从需qiú文档中快速找到。

五、需qiú上线后的数据

凡是需qiú,必然要有验证效果的数据,而从每一个失败与成功的需qiú中不断总结和反思,是产品经理成长的重要途径。如上文所说,产品经理应该保持开放X,那么就意味着产品经理对于需qiú输出的实现方案,最终结果无论是好是坏,都应该将效果数据按实际公开,这既能够促使产品经理自己不断改进产品思路,也能够让参与需qiú的相关同事了解自己的工作成果,增加他们的参与感与成就感。

以上便是我理解的需qiú文档应该包hán的一些内容,可能过于繁杂,具体还是要根据每个人自己的工作xí惯做取舍,仅供参考。

希望能帮到你。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 我所理解的需求文档 https://www.xiongfawang.com/3443.html

常见问题

相关文章

我所理解的需求文档-海报

分享本文封面