展开

关键词

7、产品需求文档(PRD)的写作方法

所以,PRD文档,根据阅读对象,就不要去耍花架子了,用最平铺直叙最简单的话,把问题说的一清二楚就行,绕来绕去小心被程序猿们掏出斧劈成两截啊。 5、PRD文档的几种表现方式说到PRD文档,很多朋友之前看过版,都会不假思索的打开Word开始写作,其实PRD文档的目的在于把问题讲清楚,而不是用什么工具! 根据实际情况,能满足把问题讲清楚的方式大概有以下几种:– 文字式(Word…..最常见的)– 原型图式(Axure….推荐使用的)– 图片式(有的产品经理本来就是美术转交互转产品,所以他们擅长于此 ,有门槛的….)– 影像式也可以,就是太烧油了6、常见PRD文档包含内容文档说明、产品说明、全局功能说明、详细功能说明6.1 文档说明6.1.1 产品版本号 (1.26)-版本号 ( 1.26 ) – – 具体哪一个,看团队要求和默契程度6.3.3 UML > 用例文档 > 用例图与状态图 UML登场了(其实产品经理的PRD文档写作所涉及到的UML知识非常有限)– 中文名称:统一建语言– 英文名称:

2.1K92

做一个打破传统的PRD,让开发、测试点赞!

好面先熬好卤,好产品先写好PRDPRD可以说是产品经理工作中最常见、最高频的交付物。毕竟PRD是产品方案、设计思路、实现思路的综合体现和结果输出。 是产品研发的起点。 从理论上来说,一个PRD应该要明确产品的价值包含产品所有块的功能说明覆盖每个块在现实中所有应用场景应该遵循的处理逻辑严谨起见还要包含修订记录和修订标注。 目前市面上大多数项目管理平台都很贴心地为用户提供了需求管理块,解决了传统方式编制PRD的复杂。今天小编就用CORNERSTONE的需求管理,来建立一个让开发和测试都受益PRD。 创建分类首先在需求块中创建需求分类。创建需求接下来创建需求,团队的成员可以一起为产品提供需求,在这里可以直接分配好需求责任人、分类、优先级,以及需求的详细描述,也可以在之后进行补充和添加。 看视图为帮助产品经理对需求进行合理的安排与排期,CORNERSTONE的多种看视图同样发挥了作用,用户可以通过CORNERSTONE查看需求的进度统计,安排开发计划。

20440
  • 广告
    关闭

    腾讯云前端性能优化大赛

    首屏耗时优化比拼,赢千元大奖

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    人人都是产品经理 : 如何写出一份优秀的 PRD ? 精于心简于形 !

    ,同时将产品的思想提炼出来,用文字表示给开发者,给UI、给视觉、给老……PRD给的是一种思想,将产品的整体思想和核心需求灌输给产品的相关人员,都说PRD是个承上启下的功能,因为上接MRD,下对MRD进行技术性的描述 修订日期以修改当日的日期为修订日期,修改人显示修改内容块的人,可能是当前用户也可能是其它产品人员。 场景描述,产品在哪种情况下会被用户使用,就是用户场景拟。优先级是指用户对于当前产品功能需求的优先级,哪些是用户最想要的功能优先级则排前。 第三坑——行文逻辑不清晰在写开发文档的时候,凭着直觉来写文档,在写之前并没有梳理清楚其中的逻辑,以至于最后写出来地文档逻辑混乱,各个块互相穿插。 如果说排版有什么技巧,我想可能是这几个:以功能划分大块,大块标题醒目 把大块简单拆分,并用小标题区分 用点号罗列观点 对于文档排版,统一文字格式后,做好以上几点就能确保文档基本整洁和可读性。

    88740

    想做产品经理,先从写一篇PRD开始吧

    开发可以根据PRD获知整个产品的逻辑;测试可以根据PRD建用例;项目经理可以根据PRD拆分工作包,并分配开发人员;交互设计师可以通过PRD来设计交互细节。 产品也是这个道理,产品是由功能和内容组成,这些功能和内容,按照某种纬度,组成频道块,最终形成产品的整体结构。由于产品的结构一般比较大,这里仅以产品结构中的个人中心这个块为例:? 以会员中心→内容管理这个块为例,这个块下面包含的用例有:①新增文章②修改文章③删除文章④查看文章列表⑤查看文章详情现在,就可以按照上面这个列表,来一一的描述用例。 通过用例描述需求,最好用文档,并且有统一的用例,而功能描述只需要在Axure里,以注释的方式描述即可。其实,关于需求怎么描述,没有完全正确的方式,只有最合适的方式,具体因人而异。 三、PRD文档的格式目前市面上各种需求文档,五花八门,千万不要试图找到一个100%完美的文档版,PRD文档,只有最合适的,没有最好的,每个人所在的公司背景都不一样,大公司要求文档规范,细节到位,小公司可能只需要记录关键信息

    93270

    作为产品经理在设计产品过程中你需要使用哪些文档?

    相信产品原型、PRD这两个文档名称肯定是大家听的最多的,但是在一个产品的设计中光有这两个就够了么,显然答案是否定的,下面我就把我在产品的设计中会用到的文档类型及其作用做一个详细说明。 在很多的产品经理社区一直在讨论原型和prd能不能整合为一个文档,个人认为在原型中加入必要的功能说明和交互说明是很有必要的,但是PRD也是不可缺少的文档,所有文档的存在都有其价值所在,不明白其价值而讨论起存在的合理性都是耍流氓 原型多是在项目进行中使用,其特点:直观、有交互逻辑、能给项目成员真实的体验,在完成的过程中产品经理更多的是处于交互体验的角度去考虑问题;而PRD更多的是保证产品迭代的延续性,其特点:内容全面、定性定量, 而评审通过后,视觉进行UI设计(原型、界面跳转流程图)、开发进行技术实现(原型、PRD)、测试进行功能检测(功能列表 、PRD、原型)主要的参考依据都是以上文档,至于PRD优秀的太多了,我也就不再进行累赘了 而不同角色的特定或是专业知识也是不一样的,不可能通过一份文档对接所有的干系人,所以会衍生出各种各样的的文档,而这些文档也是必须在实际的项目中遇到问题之后才能体现其价值,而我也是出于希望你能够去实际体验、领悟的目的,故不提供以上文档的下载链接

    28031

    优质产品需求文档(PRD)写作三大原则

    PRD文档的写作会因公司、团队以及个人习惯而异,没有标准的规范和统一,但有三大原则是不可忽略的:文字简练、中低保真、测试验证。本文仅陈述个人对产品需求文档的理解,若有不正确的地方,还望多多指教。 BRD>MRD>PRD是一个逐步论证并产出结果的过程,也是产品经理思维升华的过程。? 2.业务说明及原型图 整个文档最核心的部分,其中包括产品功能主框架,比如:业务结构图/流程图、页面交互/功能块元素构成、权限说明表等。 事实上,即使你的PRD已经十分精练,团队成员也很有可能不会完完整整地看完,有时候甚至会忘记其中一些内容,然后认定是你当时没有添加。 对于很多产品来讲,有下面三个测试十分重要,而且对于PRD最终是否“接地气”有着不言自明的决定作用。

    1.2K50

    优质产品需求文档(PRD)写作三大原则

    PRD文档的写作会因公司、团队以及个人习惯而异,没有标准的规范和统一,但有三大原则是不可忽略的:文字简练、中低保真、测试验证。本文仅陈述个人对产品需求文档的理解,若有不正确的地方,还望多多指教。 BRD>MRD>PRD是一个逐步论证并产出结果的过程,也是产品经理思维升华的过程。? 2.业务说明及原型图 整个文档最核心的部分,其中包括产品功能主框架,比如:业务结构图/流程图、页面交互/功能块元素构成、权限说明表等。 事实上,即使你的PRD已经十分精练,团队成员也很有可能不会完完整整地看完,有时候甚至会忘记其中一些内容,然后认定是你当时没有添加。 对于很多产品来讲,有下面三个测试十分重要,而且对于PRD最终是否“接地气”有着不言自明的决定作用。

    63020

    基于JIRA的产品需求全生命周期管理实践

    为了让需求的过程管理更直观,我们使用“产品需求看”来管理功能 Story(如下图所示)。一个 Story 既可以表示产品 PRD 中的一个功能,也可以表示一个线上待优化的功能。 由于有赞零售产品包含了多条业务线,我们使用 JIRA“块”来区分来自不同业务线的 Story,跨多个业务线的 Story 需要标记为多个块,通过“业务块快速过滤器”查看仅该块的需求。 我们通常直接从 PRD 文档中批量创建产品功能点 Story 到产品需求看中,方法是:在功能列表中点击三次某个功能名称,会弹出 2 个“快捷菜单”,右侧那个为“创建 JIRA 问题”菜单(如下图所示) 我们在系统分析阶段会使用统一的技术方案进行技术评审,包括不同系统之间的依赖分析、业务流程分析和系统接口约定等。 提交测试 Bug 的弹窗会提示报告人按“Bug 描述标准”(包括:重新步骤、实际结果、期待结果和抓包数据)来填写,此外,测试 Bug 必须关联到 JIRA 块、影响版本和解决版本。

    2.2K41

    产品原型这么做,才叫真的爽

    除此之外,Axure 和 Sketch 需要额外安装一些包才能满足不同的设计需求,而且制作一些复杂点的交互动作也比较麻烦。对于这种本地软件,最让人不爽的就是因为版本差异导致源文件不兼容。 第二,支持的交互效果比较多,单独的页面组件和画都可以参与交互动作,灵活性很高。带交互效果的原型有一个好处,降低沟通成本。 另外,在 PRD 评审会上会对产品方案有一些调整,包括设计、文字描述、交互动作等。一般情况下都是调整完成后再给程序员或者测试再重新发一份,这样效率很低。 PRD 文档里通常少不了流程图,不管是业务流程图还是功能流程图,都是帮助阅读者理解并提高沟通效率的工具。这款原型工具支持标准流程图设计,用起来也非常顺手。 不仅提高了工作效率,它自带的一些也能让你快速构建原型。多的就不说了,建议你们实际体验一下,或许会有一种全新的感受。

    21320

    大学生毕业后想成为产品经理?那你得先从以下几个方面入手!

    并能够在没有实权的前提下协调全部资源把事做好,资源包括人力、资金、时间和老的支持! Visio:Visio能够获得推荐的原因是因为Visio的适用性非常之广,从网站界面、数据库型,到平面布置图到工艺流程图,Visio都提供了相应的元件库和来进行快速创建。 MindManager的比较丰富,产品经理可以用它快速创建优雅漂亮的思维导图,快速完成信息的捕捉、分析和利用。 3.写PRD需求文档的技能在学习如何撰写PRD之前,我们先要明白写PRD的目的是什么: PRD为Product Requirement Document的简称,其中文翻译为:产品需求文档。 开发可以根据PRD获知整个产品的逻辑;测试可以根据PRD建用例;项目经理可以根据PRD拆分工作包,并分配开发人员;交互设计师可以通过PRD来设计交互细节。

    37930

    响应式网页设计指南

    我们需要打破传统的思维式去思考设计,从纯粹传统的Web向移动应用过度。 具备一定的页面流程图制作能力(可用页面快照实现);具备一定PRD能力。Mockplus:简单易用的工作方式;快捷方便的交互设计方式。提供多种演示预览方式。 具备一定的PRD能力(有“UX文档”协作支持PRD)。可通过插件导入Sketch文件。 ? ,在这些不同的版本中,块A在1024的宽度下,可能会是黑色背景,但是到了768下面可能会变成白色背景,实现了在不同宽度的不同展现。 在以往设计更习惯的思维是针对某些设备(比如桌面、平电脑、手机)的数据来设置断点,比如1024 对应桌面、768对应pad、480 对应手机,但实际上,这些东西是靠不住的,因为这些屏幕尺寸会根据时代的发展不断的变化

    54690

    响应式网页设计指南

    我们需要打破传统的思维式去思考设计,从纯粹传统的Web向移动应用过度。 具备一定的页面流程图制作能力(可用页面快照实现);具备一定 PRD 能力。 Mockplus:简单易用的工作方式;快捷方便的交互设计方式。提供多种演示预览方式。 具备一定的 PRD 能力(有“UX文档”协作支持 PRD)。可通过插件导入 Sketch 文件。? ,块 A 在1024的宽度下,可能会是黑色背景,但是到了768下面可能会变成白色背景,实现了在不同宽度的不同展现。 在以往设计更习惯的思维是针对某些设备(比如桌面、平电脑、手机)的数据来设置断点,比如1024 对应桌面、768对应pad、480 对应手机,但实际上,这些东西是靠不住的,因为这些屏幕尺寸会根据时代的发展不断的变化

    40780

    【带着情商做产品系列①】产品经理与开发沟通的三

    本文主要是想和大家分享一下自身和外界沟通这方面,我对于“产品经理和开发gg沟通”这个问题的理解:从三个方面把控,提升沟通质量(权且称之为“三斧”)一、需求细节的把控这里所说的细节把控,尤其是指在产品经理策划 “提供给开发gg的PRD”时需要注意的:要将自己能考虑到的细节均描述在内。 这个时候即使开发gg同意了,心底里也会有反弹:不但考虑如何阅读天马行空的PRD,还要考虑如何在粗糙的PRD基础上自己去做完善,更要考虑如何加班加点把代码敲完。他的心情怎么能好起来呢? 通过了解发现,首先需要在微信公众平台找自己业务对应的行业,并在行业中选择需要的版,通过版的字段才能来定义和发送。首先选择版:?然后看具体版的定义字段:? 四、小结以上从需求、心态、能力三方面,分享了产品和开发沟通时的个人感悟,我把这3个要点称之为“产品和开发沟通的三斧”,并一直在工作中使用,对自己的工作也起到了很大的帮助。

    30670

    PM只是差一款全新的PRD利器

    他们更核心的工作,是对于公司整个产品式和商业式的思考和探索。在一些产品驱动的公司和团队,产品经理是和CEO接触最多的角色之一,甚至一些公司的CEO本身就是产品经理。 但我们如果再仔细看看优秀产品经理的工作本质,就不难发现,对于产品式和商业式的思考和探索,这些工作或许无法用原型和撕逼来解决,但却可以用产品文档一点一点沉淀。 广义上讲,它可以是产品和商业式的全部思考的记录。内容上讲,PRD至少包含了以下部分:1. 产品概述产品是一个团队甚至整个公司的业务,产品经理需要向整个团队解释说明产品研发的背景以及核心功能。 正因为如此,现在互联网的产品经理,也更加迫切地需要一种全新的PRD文档撰写式,既能够高效写作,又能够适应较快的产品开发节奏,不仅可以为实现产品的商业成功垫好基石,也能实现产品经理业务能力的质的飞越。 iDoc的PRD文档撰写功能是基于其协作设计的理念专门打造,几乎满足了产品经理PRD文档撰写的全部需求,摹客团队也在进一步创新中,打磨产品,为产品经理以及其他的产品角色带来高效的工作式。

    22330

    需求的全生命周期管理

    “已规划到项目”中的需求管理方式----为了让需求的过程管理更直观,我们使用“产品需求看”来管理功能 Story(如下图所示)。 一个 Story 既可以表示产品 PRD 中的一个功能,也可以表示一个线上待优化的功能。前者将规划到某个项目中完成,而后者将规划到日常需求周迭代中完成。?? 当产品 PRD 文档通过了产品内部的方案评审后,产品经理会给研发同学做产品需求宣讲。

    29130

    项目管理——产品文档规划

    产品文档按照版本号设子目录文件夹命名格式为“版本号+核心块名称”,比如客户端的详情如下。?每个版本使用迭代记录记录该版本的所有内容,首先是PRD、其次是视觉稿、交互稿、以及相关技术资料。? 我的产出物是PRD,是用Axure画出原型,然后带交互和逻辑,含流程图。源文件就是rp文件,如上所述。需要注意的是,对于涉及到前后端的版本,我一般放在客户端文件夹中。 分支版本往往是某个块,命名规则为“版本号+块名称+期数”,这样命名的好处是可以搜索出该功能的所有版本,方便回顾复盘。? 查看并回滚该PRD到任一历史版本最终生成了每一个文件夹的迭代记录,可在gitlab官网查看,并回滚到历史版本,方便团队复盘使用。?查看所有提交记录? 三、共享PRD给相关人员共享网址给项目组成员问负责搭建git的同事提供在线网址,然后将它给到对应的项目组成员即可。?

    79850

    PRD文档如何撰写

    写在前面的话好久没有写文章了,一方面是因为最近的工作比较忙,另一方面还在不断的学习一些新知识,今天给大家聊一聊产品经理的基本功之一的需求文档,江湖俗称PRD,其实这类的文章和资料很多,这里我仅分享我个人工作中的心得 ----一、撰写PRD的目的说起这个话题要牢骚几句,因为自己也在一些群里,经常会看到一些人聊起这样的话题,我到了这家公司,老让我做产品优化,但是不知道从哪里下手,我说你把需求文档找出来,看看这个需求当时是怎么产生的 三、PRD的结构前面啰嗦了一大堆,也不能说没用,一切事情有因才有果。下面说下一份PRD的结构大概有哪些内容,这里强调下,这个结构不是固定的,根据自己团队的实际情况添加或删减内容都是可以的。 4、产品概述这里面包括三个点要阐述清楚 (1)、产品背景-->为什么要做这个产品 这个部分可以从几个点去写:生态+需求可靠性+价值+成本 生态:这点从第三方报告或者老的描述中获取,比如某某市场空间巨大 5、功能性需求这个部分是PRD的核心,我们团队的成员大部分时间也是看这部分,这一大块主要包含几个部分,分别是: 一、产品架构 在网上找的,就是用思维导图把产品的架构梳理出来,这个图就是让参与者知道我们这个产品大概的样子

    1.3K73

    SAP ABAP BAPI_TRANSACTION_COMMIT的使用方法

    REQUISITION_ITEMS, ITEMS); function.SetValue(REQUISITION_ACCOUNT_ASSIGNMENT, ACCOUNT); function.Invoke(prd RETURN.GetString(TYPE).ToString().Trim() == E) { Error.Text = RETURN.GetString(MESSAGE).ToString(); } prd = null; } 取得资产编号 public string GetASSET(RfcDestination prd, int i, DataSet ds) { RfcFunctionMetadata ); function.Invoke(prd); 提交调用BAPI_FIXEDASSET_CREATE1 生成资产编号 function1.Invoke(prd); 提交调用BAPI_TRANSACTION_COMMIT 进行COMMIT一下 RfcSessionManager.EndContext(prd); twMsgbox.AjaxAlert(function.GetValue(ASSET).ToString()

    42410

    图论 最短路 SPFA 1 #include 2 #include 3 #include 4 using...

    396110

    后台设计的一些总结

    3.竞品分析,了解竞品的设计思路;优化自己项目的设计思路;4.选择对应的后台原型;5.设计原型界面;6.撰写PRD;7.可以直接在原型上写需求文档,也可以单独通过文档写 PRD。 二.后台设计的一些基础块1.账户权限:1)有现成的直接套用基础服务;2)其实根据角色分配权限即可,创建一个账户分配对应的角色即可使用对应角色的权限;3)角色的权限可以根据业务逻辑来设定,也可以地理位置等设置对应的权限 ;4) 通过管理员创建对应的账户(账号,密码),使用对应的账户登录即可使用后台对应角色的功能;5)权限的精确度:可以精确到对应的大块,也可以到小块,亦或者到按钮,看业务需求;6)等级关系:可以通过角色设定 7.配置管理1)根据业务需求,前端一些服务协议等可在后台配置;2)系统整体价格的规则配置等;3)一些的配置;4)App发布版本的一些基础配置等。

    98880

    相关产品

    • 自定义模板 OCR

      自定义模板 OCR

      自定义模板OCR基于业界领先的深度学习技术和图像处理技术,提供针对任意固定版式的卡证票据的结构化识别能力,产品可由用户建立键值对应关系自主定制模板,提升信息数据的提取和录入效率。

    相关资讯

    热门标签

    活动推荐

      运营活动

      活动名称
      广告关闭

      扫码关注云+社区

      领取腾讯云代金券