Word成品须求文书档案,已经过时了

点击观看视频课程

威尼斯官方网站,结语

我所说的都是错的

上述,就是我在平时工作中根据公司和团队的实际情况不断调整和摸索出来的一套方法。相对来说,对于规模较小的开发团队,这种原型PRD非常推荐。大家在平时工作中,一定要根据公司和团队的实际情况灵活调整。写文档本身就是在做产品,如何让大家接受并且易读、易懂,则需要我们在日常工作中多思考、多总结。

下面我就不讲思路了,先展示我的产品需求文档的历史版本和最新版本对比。

产品需求文档V1.0 版     
这是我一年前的原型加标注,只有很粗糙的标注,现在看来真的是很low啊

产品需求文档v2.0版本
这个是第二个大改版,做成了网页的形式,有一级导航,二级导航,还有版本号。左边的站点地图也进行了清晰的逻辑分组。

产品需求文档v3.0 
这是现在我用的版本,导航栏变得精致了有没有。所有标注都进行了像素级排版,所有的间距都用准确的像素测量,然后布局。

随着每个版本的调整修改,其实都伴随着视觉效果提升、逻辑架构更清楚,也更加提升了用户体验。

文档变更说明

威尼斯官方网站 1

示例 文档变更说明

尽管产品经理会反复模拟产品的使用流程,但实际项目中PRD还是很难做到一步到位。除了一些临时新增需求,一些异常或边界条件如果PM之前没有经验,很难在一开始就考虑到。这时候,如果你的RD是一个负责任的老司机,他可能会提醒你并给予一些建议(不过,一些情况下老司机会自动帮你脑补你未完成的部分)。

所以,如果不得已要更新已提交的PRD,更新日志就显得尤为重要了。文档更新后,要及时通过邮件或内部IM告知相关项目人员。大家通过查看更新日志就能大致了解变更内容,可以直接定位查看。

<small>注:如果是文档的话,还可以用Beyond
Compare来查看两份文档修改前后的差异。但程序员们一句git
diff 就搞定了,有木有···
</small>

下面继续来展示更多页面

产品简介   
我将PPT做的商业需求文档贴在了里面,真可谓时时刻刻不忘商业目标啊

版本说明   
是非常重要的版块,整个版本所有的需求都列在这里,并且已经写好了版本升级的提示内容,市场同学可以直接拿去用。开发同学通常都是参考这里来进行工作分配,点击详情按钮,可以直接跳转到原型图页面,那里有详细的需求描述

开发周期   
此页面我没有进行详细丰富,其实还可以写具体什么功能,由谁负责,工期多久等内容

版本历史   
这个页面也是很重要的页面,所有的版本迭代都可以展示在此表格,可以清晰地看到你们团队的版本迭代周期

修订历史   
此页面是非常重要的页面,虽然他是排在最后一个位置,但是,每次打开Axure文档都会先显示此页面。就拿需求文档来说,我还没遇到哪个版本不用进行修改的,所以产品经理一定要把每次文档调整的地方在这里清晰地写出来,方便文档读者观看,也方便自己记录

思维导图   
这个版块下,全是产品相关的图表,比如产品结构图、信息结构图、流程图等。我曾经尝试用Axure自带的流程图部件来画流程图和思维导图,但得出的结论是,太耗时间,而且布局很费力。所以,这里我都是用mindmanager导出图片

全局说明   
这个页面其实是展示整个产品的设计规范,一些很多页面通用的规则都可以在这里展示

交互原型   
此页面就是所有的原型+标注页面了,在这里,我会将这个页面所有的功能与跳转逻辑标注清楚,并且用红色将重要按钮凸显出来,用蓝色标记可点击的链接。而功能标注的布局我是仿照sketch的风格设计的,但比sketch更优秀的地方在于,很多地方是可以点击的,具有交互的

用例文档   
其实,这个用例文档的页面,是我闲的无聊时做的,并没有什么卵用,测试人员也不会使用此表,更加方便的还是Excel

需求卡片   
这个页面到现在也已经放弃了,因为对需求的整理,最好还是在Excel中

版本更新说明

威尼斯官方网站 2

示例 迭代版本更新说明

版本更新表中,主要描述该PRD涉及到的功能或改动。因为,在产品迭代过程中,一次更新可能会涉及到多个PM负责的业务或者模块,有时候多份PRD未必会汇总提交给开发。因此,在文档开始处声明该PRD中涉及的需求,能够让RD对文档有个大致的了解。

重视用户体验的产品需求文档该怎么写?

威尼斯官方网站 3

结尾

到这里,我的产品需求文档就讲完了。从最粗糙的原型到现在精细的原型,历时一年。我能从表象的产品需求文档中看出,自己本身的能力也在逐步提高。其实,文档也是帮助产品经理梳理思路的一种手段。突然想到,什么是产品思维?不断发现问题,解决问题就是产品思维。只有不断思考,不断发现问题,不断总结,才能优化出更优秀的产品。

点击观看视频课程

图片来源于网络

说来有些惭愧,写这篇文章是用来教大家写需求文档的,但其实,我很少会写传统意义上的产品需求文档,甚至,我连word都很少用。用惯了Axure的任意布局方式,再用word感觉非常别扭,尤其是在添加图片时,简直感到捉急。当然,这不是我不用word写需求文档的根本原因。

流程图

威尼斯官方网站 4

示例 页面结构说明

如果涉及新的业务流程或者页面逻辑,建议提供一份清晰的流程图或树状图。一方面,可以更直观地梳理逻辑和查找漏洞;另一方面,这种逻辑性很强的东西更符合程序员的思维方式,效果远远好于仅提供一个可交互的原型,让可怜的程序员自己去琢磨你的逻辑。

<small>注:如果只是简单的页面改动,可以没有这一部分内容。</small>

简单来谈一下,为什么软件开发项目中,需要需求文档这么个东西?

在稍微大一点的开发团队中,产品经理未必能向所有开发人员,传达具体的产品开发需求。这时就需要一份文档来供所有的项目参与人员阅读。而产品经理又常常爱拍脑袋、容易变卦,所以文档也是开发人员约束产品经理的一项武器。在产品上线前的测试环节,测试人员也同样会拿产品需求文档来验收产品质量。当团队进入新人时,文档也可以让新人更快地了解产品。

总的来说,产品需求文档有三个核心作用:

1、传达产品开发需求;

2、保证各部门沟通有理有据

3、产品质量控制有具体标准

由此可见,产品需求文档是必不可少的。那一份好的需求文档,就应该能准确传达出产品的开发需求。那么产品需求文档该用什么方式写,才能更好地传达出产品开发需求呢?

就我所见,行业大多产品经理都是用Word+Axure原型的方式组成产品需求文档。那这种方式,是否真的能方便地表达出产品需求?我问了很多程序猿,他们在开发时,一般都是看着效果图和原型图写代码,只有在遇到问题时,才会查看word文档。也就是说,开发需要一边写代码,一边看效果图,一边看原型,还要时不时查看文档。而且,大多数程序猿都不会逐字逐句去读产品经理的长篇大论。那产品经理写word真的合适吗?这样的用户体验真的好吗?花费大量时间写word真的有价值吗?在Axure画原型的同时,我们为什么不能直接在旁边标注呢?这样岂不是方便快捷很多吗?

其实,当下流行一种直接在原型图上标注的需求文档撰写方式。在新版的Axure8中,也已经推荐了原型加标注的需求文档样式。Axure8新增了一组部件—不干贴,就是方便产品设计人员进行功能标注。

原型说明

初期,用Axure制作的原型在通过了需求评审和设计评审后(这时候,UI可以开始正式做设计和切图了),就可以进一步完善成为PRD。

用Axure制作PRD的好处主要有以下几点:

  • **
    原型和说明文档可以同步更新**。在项目进行中,我们提交的原型因为种种原因,会存在变动的可能。当我们在Axure中修改了原型后,可以很方便的对说明进行同步更新。

  • 文件左侧的站点地图有天然的逻辑分组。Auxre的树状组织结构使得页面间的逻辑关系非常的清晰。新的
    Axure
    8
    新增了很多流程图和控件,功能更加的强大。

    威尼斯官方网站 5

    site map of Axure 8

  • 方便程序员的工作。大多数的程序员至少会有两块显示屏,一个用来开
    IDE
    撸代码,另一个就用来查资料和看文档。如果PRD和原型分开来做,那么无形中增加了他们的切换成本,降低了开发效率,程序员肯定不买账。最后的结果很可能就是,不仅辛辛苦苦写的PRD没人看,就连原型图也成了摆设,有问题全跑来问产品。

威尼斯官方网站 6

图片来自网络

为了最大程度降低RD大大们的阅读疲劳感,使他们不遗漏PRD中的一些重要细节和说明。在Axure的一个Page中,我尽量只描述一个页面。甚至该页面上的一些事件或弹框,如果有必要的话,我也会单独新建一个同级的Page来进行说明。

威尼斯官方网站 7

示例 原型说明

事实证明,这种 “一个Page只说一件事儿”
的方法更能激发RD的阅读欲望,使他们更加专注于该页面的细节和逻辑。因为,少了很多无关页面的干扰,UE说明的字数也会减少。研究证明,适当的文字篇幅更有利于人们阅读。(<small>虽然如此,但是页面的前置条件、说明文案、边界情况、异常流程,甚至是算法,还是必不可少的。</small>)

另一方面,因为每个页面说明都在一个独立的Page中,所以页面间的跳转关系,可以通过超链接来完成(整体的页面逻辑已经在前面的流程图中体现了)。只需要在说明处标明,其他人点击查看即可,如示例中左上角返回按钮处的说明。

<small>注:不建议用点击事件来代替显性的超链接说明。除非是高保真可交互原型,否则其他人不知道哪些地方可以点击或者交互。</small>

This entry was posted in 亚洲历史 and tagged , , . Bookmark the permalink.

发表评论

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