快捷搜索:

您的位置:环球彩票登陆 > 环球彩票登陆 > 产品小白的成长之路-分分钟完成100页PRD文档

产品小白的成长之路-分分钟完成100页PRD文档

发布时间:2019-10-19 20:11编辑:环球彩票登陆浏览(92)

    梳理逻辑顺序可以运用业务流程图、操作流程图等,根据逻辑顺序设计好的载体界面里的各元素、各功能就有了自己的空间顺序。

    具体角色的业务操作

    ② 图片

    紧接着描述对象B:我是谁:对象B;从哪里来:需要定义得到的或是怎样从别处调用来的到哪里去:要输出另一个对象C或执行不同逻辑条件得出不同的对象结果或过程状态或结束状态等。

    3.术语缩写

    “如图是一张以Blog系统为示例的信息结构图。信息结构图是一种接近数据库结构的图表,在罗列信息结构时,更多的是考虑信息数据,但是他并不是真正意义的数据库结构。信息结构图是提供给产品经理自己梳理信息内容的结构图,也是方便产品经理和服务端技术人员沟通数据结构的参考图,技术人员会根据这张图表的内容再结合产品原型或需求文档,然后规划和设计出真正意义上的数据库结构。

    以下是我写了多个产品需求文档后对产品需求文档的思考和理解,如有不当欢迎交流。

    本文中设计的PRD文档是一个J2EE的ERP系统,在项目前期没有做原型,然后项目因为成本问题最后落地,所以没有原型图展现。

    前置条件:参与或操作(执行)本用例的前提条件,或者所处的状态

    要做成一个产品要靠团队协作,团队当中还应该有一个参考点,在研发阶段产品需求文档就扮演了参考点的角色。这个参考点不光一人明白就可以了,还要向团队其他人说明白。

    思维导图

    当用户退出产品时(误操作、Home键、锁屏、自动关机),产品需要维持用户操作前的状态,当用户返回产品时仍可以恢复到之前状态,并继续使用。

    所谓合理的说明顺序,是指:能充分表现事物或事理本身特征的顺序,也是符合人们认识事物、事物规律的顺序。

    4.版本状态

    简要说明:简要的描述一下本用例的需求(作用和目的)

    产品是需要给到用户使用的,是一个客观存在的东西,这个东西呈现出来是有载体的。用户使用这个东西是有一定流程的,这个流程也是这个产品所具有的特性。对于软件产品,呈现出来的是界面这个载体。

    五、其他

    2、全局说明:主要讲解产品的全局性功能的说明,例如:网站产品的页面编码、用户角色、缓存机制等。举一个移动产品的“状态维持与恢复”的例子,如下:

    正确的顺序能正确地理清文章思路,能帮助读者理解。

    对产品的整体信息架构以及产品的业务流程进行梳理。

    “产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式,主要用于产品界面设计和研发使用。因为每个人的习惯和团队要求都是不一样的,所以产品需求文档没有统一的行业规范标准,无论以什么样的格式撰写产品需求文档,最终的目的都是让执行人员能够理解产品需求,根据需求完成产品。

    是谁和来自哪里之间的描述,就显得比较微妙了。能带来什么?又影响着来自哪里?要细细体会。要描述得再详细一点,可在“我是谁?”这一点增加用对应的手法,比如:结构图表达这个产品特性的描述,可在“来自哪?”这一点上增加背景内容——如,用业务流程图来约定范围,根据不同的目的来添加描述。

    本文结合自身经历过的一个WORD版PRD文档,从几个角度介绍一下PRD文档如何编写,不同公司不同项目所应用的PRD文档内容可能有所不同,理解PRD文档的本质,具体问题具体分析。

    文档主要功能是描述产品的功能需求。

    如果产品经理想过且理解了产品需求文档本身,运用这种方式是有助于理解产品的;是否理解了产品该用什么方式表达出来,产品需求文档就是这么一个方式。

    3.角色区分

    “原型设计的表现手法主要有三种:手绘原型、灰模原型、交互原型。从工作效率的角度考虑,我非常建议先通过手绘的形式快速在草纸上绘制出产品的原型,推演和讨论方案的可行性。当方案的可行性被验证之后,我们再根据个人习惯或团队要求,通过软件工具进行更深入的设计。

    图1

    根据不同产品及公司需要,这部分内容可能会有所不同。本文中实战案例中非功能需求包括安全性、统一性、实用性等原则。

    信息结构图中关于友情链接功能的信息数据只有“名称”和“链接”两个内容,但是在实际功能需求中,友情链接还有两个功能,分别是“显示或隐藏”和“是否新窗口打开”,这两个功能会在产品原型和需求文档中详细描述,但是在信息结构中是没有体现的,因为从产品层面上来说,这两个只是功能,并不是信息内容。但是在真正数据库中,友情链接的这两个功能分别也是有字段参数的,程序在读取该参数后便知道友情链接的属性,然后处理友情链接是显示还是隐藏,是新窗口打开还是本窗口打开。通过友情链接这个例子,我们就知道了在实际中数据结构和信息结构是不一样的,信息结构只是产品、层面的数据内容。

    空间顺序是表现,逻辑顺序是内在,交织融合到界面这个载体上,就呈现出产品的样子。

    1.文档目的

    产品需求文档

    就涉及到说明顺序。

    4.字段说明

    ① Word

    本文试图从书写说明文的角度来理解产品需求说明文档本身。以及尝试应用“我是谁?来自哪里?到哪里去?”三大经典哲学命题去认识产品,以及应用到描述产品需求中去,从而帮助更清晰、更有条理地认识产品,描述产品需求。

    1.业务流程

    无论是什么样的产品类型,无论从哪里入手,我们第一步都是先要罗列信息结构,因为信息结构图不仅是辅助技术人员创建数据库的图表,也是辅助产品人员进行产品功能规划的参考,只有对信息或数据的结构了解了,我们才能更好的设计产品。”

    先说概括,那概括的该怎么说呢。

    通过版本状态,修订人以及修订内容,让以后接触的人可以快速了解产品情况,同时对于产品需求变更有更明确的认知。

    在互联网产品和设计中,用例的使用越来越少,通常有了产品原型再加上功能流程图和功能说明文档就能够将产品需求详细的表述清楚,所以也没有必须撰写用例了。但是在大公司里,往往会追求产品流程的规范性,要求撰写用例,不过在敏捷开发的时候也会采用其它更有效率的方式,不一定非要撰写用例。”

    图3

    产品信息架构图,明确产品的信息架构。

    6、需求文档(PRD文档)

    来访者回答:“我是谁?来自哪里?到哪里去?”这三问好让保安了解来访者,并决定是否放行来访者进门。

    图片 1

    产品结构图是一种让产品经理通过思维导图的方式梳理思路的方法,通过这种方法可以明确产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素,逐步的将脑海里的想法明确梳理成结构。”

    以上这些根据不同要求,视情况而定地描述出来,相信整个团队人员对要做的产品需求都很清晰。说清楚后,就要去做清楚,做清楚也会涉及一个时间顺序的问题,功能是一个一个开发的,所以在需求描述时往往要加上开发的优先级。

    PRD文档的主要面向群体是研发,是在BRD、MRD文档之后,对产品需求的进一步细化,通过结构化的语音让研发更容易理解产品需要做的内容是什么。

    这是传统意义上的产品需求文档,主要有四个部分组成(具体根据产品要求进行划分),分别是:结构图、全局说明、频道功能、效果图。

    题图来自 Unsplash,基于 CC0 协议

    通常一个产品会包含多个功能模块,针对每一个细化的功能模块,又有具体的业务流程。

    在撰写功能需求时,我们需要考虑用户的流程,例如一个“完成”按钮,我们需要描述他完成后,系统要不要给出反馈提示(反馈提示是什么样的形式反馈,内容显示成什么,有没有内容需要调取数据库),或者要不要跳转页面(跳转到哪个页面,这个页面是其他频道页面,还是这个功能的子页面,如果是子页面就需要再描述这个子页面的模块及元素内容)。

    描述一个产品往往是这样:通过这个产品的什么功能内容给谁带来了什么?也如下图1。

    针对复杂的业务逻辑和业务流程,对角色进行区分,针对不同角色的操作进行需求描述。本文中基本所有功能模块都涉及到多人协作的业务流程,所以对角色的区分以及对不同角色的不同需求进行了详细描述。

    当我们通过Axure PR制作出产品原型后,实际上他已经是很完善的产品Demo了,因此我们只需要加上元素的标注,在标注中说明功能需求,这样导出的HTML文件相比Word文档更直观易懂,是非常高效的产品需求说明方式。

    图片 2

    业务流程

    一般采用文本、思维导图形式,目的是罗列出产品功能信息内容,主要是要清晰易懂,让技术人员清楚了解你的架构。

    一个产品细分出来就会有很多具体需求,各个需求之间先描述哪个呢?

    图片 3

    PRD文档要是一份详细的产品功能需求说明文档,是产品文档中最底层和最细致的文档,直入主题的功能说明文档。

    图片 4

    业务操作

    产品设计的最终表述的形式被称为产品需求文档(PRD文档,Product Requirement Document)。产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式,主要用于产品界面设计和研发使用。

    在研发过程中,产品经理经常会听到类似的声音“这个需求是怎么样的?”“这个数据是从哪里来的?”“这个需求要做成什么样?”,这些类似的问题所反映的是不是与“我是谁?来自哪里?到哪里去?”所反映的很类似。

    结合思维导图,对产品需求文档的整体框架进行了一个整理(再次重申,不同产品框架会有所不同)

    2、产品结构图

    一个功能模块所涉及的所有对象都描述完后,根据内在联系去描述下一个功能模块的需求。排版先后顺序和流程对应起来,再加上清晰的输入/输出以及下一步,会比较容易检查完整性。

    一、文档描述

    对于产品经理来说,原型设计是为了帮助我们细致的考虑方案,并论证方案的可行性,同时也是为了产品宣讲时让听众能够清晰直观的了解产品,避免抽象的语言描述导致听众理解困难和理解偏差。产品原型也是为了确保产品在执行过程中,是按产品经理最初设想的需求和期望完成的,因此产品经理的原型是没有很高的要求的,只要对方能够听懂看懂就可以了,所以使用手绘原型是最高效率的方法。”

    图片 5

    图片 6

    4、产品用例图

    截图一个产品需求文档中描述一个模块的模板,应该知道怎么用怎么描述需求了吧。

    六、实战案例

    后置条件:执行完毕后的结果或者状态

    用户要通过操作完成任务,就需要一个接一个界面来做载体让用户完成任务。决定这一个紧接着一个的界面出现的是这个产品的逻辑顺序,是这个产品特性的体现。而每一个界面里各元素各功能也是依据逻辑顺序来排布位置展现出来的。

    四、非功能需求

    ③ 交互原型

    紧接着描述下一个对象……

    七、总结

    对于图片形式的产品需求文档,我们只需要另外再描述一下全局说明,其他频道页面的需求直接以图片形式展示,这种方式相对于Word文档的纯文字更加生动易读并且直观。

    解决了具体需求中先描述哪个的顺序问题,就到了一个具体需求该怎么说的问题。

    图片 7

    图片形式的产品需求文档是基于效果图的说明文件,将传统Word形式的功能需求说明标注在效果图上,这种方式经常使用在移动互联网领域,实际上是图文形式的交互需求文件,只是在此基础上更深入的描述出功能需求。

    从上面所写的来描述一个功能需求,再看下图4:

    产品希望达到什么目标,满足用户什么场景下的什么需求。其实还是从用户、需求、场景的角度来阐述产品的目标。

    1、信息结构图

    图4

    3.业务说明

    1、结构图:①、信息结构图:辅助服务端技术人员创建或调整数据结构的参考文件;②、产品结构图:辅助设计和技术开发人员了解产品的全局结构。

    看下图3:

    本文中的截图以及产品需求文档,是一个真实案例。本人在深圳对某物流公司进行2个月的深度调研,通过和客户讨论、现场观察实际操作人员行为、征求业务人员意见等多种方式进行需求收集、整理、分析,最后整合出了一份长达100页的需求文档。该项目涉及功能模块很多,任何一个功能模块拿出来都可以形成一个功能产品。所以在参考的过程中,可以有选择的看。

    “状态的维持与恢复

    如何说明白?先说什么?怎么说?

    PRD文档通常有WORD版和原型版,前者顾名思义。后者则是在原型的基础上加入功能需求,给研发、设计人员更加直观的体现。

    用例图只是在总体上大致描述了产品所能提供的各种服务,让我们对于产品的功能有一个总体的认识。除此之外,我们还需要描述每一个用例的详细信息,这些信息应该包含以下内容:

    本文由 @画小六 原创发布于人人都是产品经理。未经许可,禁止转载。

    2.产品目标

    用例名称:本用例的名称或者编号

    一个功能模块往往又不只一个对象需要描述需求。而且,一个功能模块里面需要描述的对象,往往也类似于满二叉树上的节点,彼此也是有逻辑顺序的。

    产品的业务逻辑上有很多术语,也许是技术研发人员不了解的,通过术语缩写的解释,让研发人员对产品的业务逻辑更加明确,不会影响产品研发进度和内容。

    3、界面线框图(原型设计)

    具体到一个功能模块的需求描述时:我是谁:对象A或包含多个对象等;从哪里来:需要定义得到的或是怎样从别处调用来的等;到哪里去:要输出另一个对象B或执行不同逻辑条件得出不同的对象结果或过程状态或结束状态等。

    需求文档的撰写往往依据BRD、MRD文档的相关信息,对之前获取的需求、业务逻辑等进行分析整理,从而形成的一份提供给研发、设计人员参考的PRD文档。在编写过程中一定要根据具体情况具体分析,形式不重要,只要研发能看懂,文档能体现出来产品的整体需求,就是一份好的产品需求文档。

    3、频道功能:以频道为单位,页面为子项,分别描述频道、页面 及页面元素的功能需求。示例如下:

    哲学的作用是:为人们认识世界改造世界提供方法论的指导。

    业务流程图,明确业务流程,区分不同角色的业务操作。

    用例(Use Case)是一种描述产品需求的方法,使用用例的方法来描述产品需求的过程就是用例模型,用例模型是由用例图和每一个用例的详细描述文档所组成的。产品人员的用例主要是为了方便技术研发和功能测试时,让参与者更好的理解功能的逻辑。

    “我是谁?来自哪里?到哪里去?”这三大哲学命题,个人觉得对人认识产品、改造产品是具有指导意义的,适用于理解产品以及指导写产品需求文档。毕竟产品也是一个世界,而且似乎真是值得好好玩味的三点。

    产品信息架构

    “产品结构图是一种将产品原型以结构化的方式展现的图表,结构内容也如同产品原型一样,从频道到页面,再细化页面功能模块和元素。所以产品结构图是产品经理在设计原型之前的一种思路梳理的方式,并不是给其他工作人员查看的文档,通过类似鸟瞰式的结构图可以让产品经理对产品结构一目了然,也方便思考。

    先说大体再说具体,这已是大多数人的习惯。这个习惯体现了从概括到具体、整体到局部的顺序,也是描述产品需求的逻辑顺序。这里面可以看到曾经在学校时老师教写说明文的影子,所要描述的对象和目的不一样。

    提到需求文档,作为产品小白也应该会有些熟悉,作为产品经理必备三大文档之一(另外两个是BRD、MRD),日常工作接触频率肯定会很高。

    “用例描述文档基本上是用文本方式来表述的,为了更加清晰地描述用例,也可以选择使用状态图、流程图或序列图来辅助说明。只要有助于表达的简洁明了,就可以在用例中任意粘贴用户界面和流程的图形化显示方式,或是其它图形。如流程图有助于描述复杂的决策流程,状态转移图有助于描述与状态相关的系统行为,序列图适合于描述基于时间顺序的消息传递。

    已看见了产品的样子,要描述出来,角度也有点微妙。从整个界面到局部,局部中又从上到下从左到右,按照这种顺序来说明各需求描述,有利于全面说明产品需求的各方面特征。而且,这样安排合乎人们观察事物的习惯,易于理解也易于复查,是很合理的顺序。

    2.界面原型

    锁屏状态时,如果用户在产品中有下载任务时,仍然保持下载。”

    产品经理描述产品需求就像是:站在一个造物者去造物的角度来阐述所造之物。

    字段说明涉及研发人员在进行产品开发时的细节问题,一般会对数据字典,字段的类型,范围进行说明,方便研发人员进行产品研发。

    维持状态包括流程操作、信息浏览、文本输入、文件下载。

    对象之间的描述顺序,采用该产品所具有的逻辑顺序,这样会很清晰也有助于加深印象。

    三、功能描述

    4、效果图:效果图是由设计师完成的产品图,和实际开发完成的产品保真度一致。

    “我是谁?来自哪里?到哪里去?”是哲学的三大命题,上文也说过适用于理解产品以及指导写产品需求文档,似乎也真是值得好好玩味的三点。

    关于产品原型,我曾经看到过关于草图、原型图、高保真原型图的争论,其实在我看来并不一定要每页做到高保真原型图的境界。原型图做好在和研发、设计沟通过程中也会涉及到变动。在我看来,只要能表达清楚业务逻辑、页面流程、功能描述即可。不要一味追求高保真而忘记注重产品本身。

    ① 用例图

    先说什么?

    二、产品描述

    ② 用例描述文档

    图2

    1.整体流程

    产品需求文档的表现形式有很多种,常见的有Word、图片和交互原型这三种形式,文档内容通常包含信息结构图、界面线框图、功能流程图、功能说明文档。虽然产品需求文档没有标准的规范,但是有两项是必不可少的,那就是文件标识和修改记录。文档在撰写过程中,我们可以自行不断的修改完善,但是如果正式发布或交给团队其他成员后,一旦有了修改,为了文档的同步,我们就需要标注出文档的修改内容,备注修改记录,这样可以方便大家查看和了解改动的内容。关于文件标识和修改记录,格式都大同小异。”

    用户使用一个产品往往因为要满足多个需求,一个软件产品往往承载多个任务,各个任务之间可能独立且有联系。它们之间也是有着自己的逻辑顺序,体现出来可以是站点地图式的目录,也可以将一个站点任务分类为一个模块,视特性而定。

    图片 8

    用例图并不是画成了图形的用例。用例图包含一组用例,每一个用例用椭圆表示,放置在矩形框中;矩形框表示整个系统。矩形框外画如图所示的小人,表示参与者。参与者不一定是人,可以是其它产品、软件或硬件等等。某一参与者与某一用例用线连起来,表示该参与者和该用例有交互。

    图片 9

    针对业务流程,进行具体需求描述,细化业务需求。

    “活动大全”的产品结构依次是:产品 -> 频道 -> 页面 -> 页面元素 -> 操作 -> 元素。我们换一个角度观看示例,产品结构图实际上就是一种结构化的产品原型。这样做的目的就是梳理产品结构逻辑,让我们清楚的知道产品有几个频道,频道下面有没有子频道或者有多少个页面,这些页面里又有哪些功能模块,这些功能模块里又有哪些元素。

    在开发阶段,和团队人员说明产品需求描述,可以口头交流可以借助文本——一般是先说这个产品的主要功能,让程序员有大体的了解,然后具体到细节。

    通过上图可以发现,有些业务流程中会出现多用户多角色的情况。针对不同的角色在业务流程中的不同定位,对用户区分后,对具体角色进行不同需求描述。

    行为角色:参与或操作(执行)该用例的角色

    “我是谁?来自哪里?到哪里去?”到处都有其影子,也是哲学的三大命题。

    业务流程

    5、功能流程图(逻辑流程)

    要想用一个合理顺序给团队人员描述具体需求,那就得先弄清楚产品的逻辑顺序,同时设计界面来辅助理解。

    2.需求描述

    二者都理解后,写产品需求文档也就更得心应手。

    图片 10

    说了概括的后,再说具体的。

    总结:本文顺序:针对产品需求描述这件事,先说概括再说具体——概括的需求该怎么描述?具体需求与具体需求之间先描述哪一个?具体一个需求怎么描述?产品需求描述要说清楚要依赖的说明顺序,常见的说明顺序有:时间顺序、空间顺序、逻辑顺序等,在描述产品需求时离不开空间顺序和逻辑顺序。“我是谁?来自哪里?到哪里去?”哲学的三大命题,可以作为一个逻辑一个顺序去认识产品改造产品,好好玩味应该有新启发。

    门卫保安常通过三问——“你是谁?来自哪里?到哪里去?”来了解来访者。

    本文由环球彩票登陆发布于环球彩票登陆,转载请注明出处:产品小白的成长之路-分分钟完成100页PRD文档

    关键词: 环球彩票登陆 产品 更有 条理