老汤还是那句话，把MRD做好，做PRD就是水到渠成的事情，因为MRD已经为PRD的撰写奠定了基础，需要做的无非就是把市场需求中对产品介质的需求描述规格化而已，以便相应的研发生产部门（主要是研发部门）能够按照既定的规格进行产品的设计。
好，废话少说，还是沿着给大家的PRD模板一一说明如何进行撰写。
PRD 模板 下载在底部
第一部分：概要介绍
在这个部分里有五个小部分，分别是：
1.1 文档目的
1.2 市场问题
1.3 产品问题
1.4 技术问题
1.5 产品概念
在这个部分里，前四个部分不用多说，1.1撰写的思路同MRD中介绍的，这里就不再重复了，1.2-1.4部分其实就是和MRD的2.2-2.5一样的，直接复制过来就可以了，新增加的就是1.5，产品概念。
那么怎么来写产品概念这个部分呢？
首先咱们再回忆一下，什么是产品概念。
产品概念是“介于产品需求和实体产品之间的一个说明，它能够定义出要做的产品的目标市场、客户特征、功能结构以及成本预估等框架性的内容”。
因此，在写这部分内容的时候，可以这样来写。
例如：
XXX产品定义为“服务型产品（SAAS）”，该产品具有以下特点：
1）该产品的目标市场主要为视频转换应用的一般用户。
2）该类用户具有“产品使用频率低，对价格敏感，对计算机操作熟悉，熟悉互联网应用……”的特征。
3）服务型产品能够让用户不再依赖本地电脑操作，完全通过WEB端实现。
4）服务型产品能够降低用户使用成本，按照用户接受的服务数量和质量进行收费。
5）服务型产品对于我方来说，需要强大的服务器和带宽环境支持，需要我方有很强的网络架构技术。
6）……
这里说明一下，因为PRD通常是要交给研发部门的，因此，在PRD中，多用一些专业规范的专业术语是必要的，反而描述性太多的语句会增加研发部门的对理解的不确定，能用一个标准词来说明的，千万不要用一大堆语句来描述。
咱们不是常说，产品经理一定要多了解，多熟悉一些技术名词，这里就是一个最好的例证，和研发沟通起来比较方便，也比较精确，可以提高沟通效率。
第二部分：项目概要
在这个部分里有三个小部分，分别是：
2.1 本章摘要
2.2 目标市场描述
2.3 目标客户描述
2.1的撰写亦然参照MRD相同部分的思路，这里不重复，2.2和2.3也同样是MRD里已经有了详细介绍的，同时，PRD又是提供给研发部门看的，因此，这里只简单提及即可，无需写的很详细。
大家记得在MRD里，第三部分和第四部分就是对目标市场和目标客户的详细说明，在PRD里就是针对的2.2和2.3，我们只需要把那么多详细的内容简化成列表的描述即可，因为对于研发部门来说，这部分不是他们重点关注的，提及即可。
在这里也不详细说明了，只要把MRD的相应部分写好了，这部分很容易写的。
第三部分：产品环境
在这个部分里有三个小部分，分别是：
3.1 本章摘要
3.2 约束条件
3.3 假设条件
3.1部分的思路依然参考MRD，这里多了两个部分：约束条件；假设条件。
那么，这又是什么意思呢？
先来看第三部分的主旨是什么，就是对“产品环境”的定义。
我们做产品的都知道，我们做的产品不是放到任何环境下都能够完全表现出我们所定义的性能来的（或是用户具体的使用环境的多样化，或是用户对产品操作能力的不一致化），例如咱们在PMAS里举过的宾利汽车的案例就是这个意思，简单的说，这部分就是要求我们定义出那些情况会影响到我们产品性能的充分发挥，做软件的朋友都知道，我们经常会在产品包装上定义一个“最低安装配置”，一个“推荐安装配置”，其实就是这个部分的一个具体体现。
这部分会因为产品的不同而有所侧重，有些产品容易受到用户使用条件的影响，有些产品则容易受到外界环境的影响，例如羽绒服，应季食品等。
因此，这部分可以这么写：
3.2 约束条件
1）使用服务型产品的用户必须拥有能够宽带接入互联网的电脑。
2）使用服务型产品的用户必须提供给我方所支持的视频格式，例如MPEG1、MPEG2、RM/RMVB等。
3）我方需要提供独立的视频转化服务网站，用独立域名（例如http://www.videoc.com）或者二级域名（例如：http://videoc.xxx.com）.
4）……
那么，假设条件又是什么什么呢？
如果说约束条件是针对我们自身提出的要求的话，那么假设条件就是对用户具体使用的一种评估。
因此，这部分可以这么写：
3.3 假设条件
1）如果用户的网络环境非宽带接入，那么我们应该采取以下方式：提示用户在此网络环境下将花费更多的时间，让用户做出决定。
2）如果用户对视频转换的格式不够熟悉，那么我们就应该采取以下方式：限制用户上传的视频格式为我方定义的格式。
3）如果用户上传了我方不支持的视频格式，那么我方系统能够在转换开始之前进行提示。
4）……
约束条件和假设条件定义的越详细，越准确，那么对于产品的标准化和日后的推广越有帮助。
第四部分：产品需求
这部分就是PRD的核心部分了，一共包括十三个小部分，分别是：
4.1 本章摘要
4.2 功能需求
4.3 开发需求
4.4 兼容性要求
4.5 性能要求
4.6 扩展要求
4.7 产品文档说明
4.8 产品外观说明
4.9 产品发布说明
4.10 产品支持和培训说明
4.11 产品其它说明
4.12 流程概述
4.13 产品需求概要表
在4.1中，既然是本章摘要，同时又是给研发部分看的，因此，用表格来定义是比较合适的，例如可以这样写：
本章对以下功能进行详细的说明，指导研发，UE和UI部门进行工作。
4.2 功能要求
这部分是我们以往在撰写PRD中花费时间最多的一个部分，在PMAS里咱们也提到过如何来写，写作思路如下：
我记得咱们重点讨论过“约束条件”这个项的写法，现在常见的写法主要是定义功能的详细指标，我们不妨可以参照一下使用约束条件这种写法，打个比喻，前者就像是告诉研发应该做什么，后者则是告诉研发部门不做什么就可以了，前者需要我们想的必须非常清晰和全面，而后者则需要研发有足够的主动性去思考，这样不至于限制死研发的思维，能够给予研发足够的发挥空间。
4.3 开发需求
这部分的意思就是我们要定义出研发在开发过程中应该注意的方面，例如：
1）从输入看
符合用户正常的输入习惯，可以使用户使用右键快速进入转化状态
2）从输出看
使用户可以在转化后，管理自己的转化文件目录
3）从过程看
过程要透明，能使用户随时了解转化信息
4）从需求满足程度看
需提供更高级别的硬件支持和增值部分
5）从时代要求看
目前所有的流行产品（无论软硬件），都有一个共同特征——“流线型外观”，分析后，可以大致得出一个结论：在当前社会知识迅速膨胀，城市飞速发展，竞争压力急剧加大的全球化环境下，人们对空间感、弹性、延伸的要求提升，因此，灵活的使用“曲线”是容易获得用户认可的。
6）从产品体系发展的趋势看
Video Convert基于两个原因才可能生存，第一：支持大量不同的视频源；第二：每种转化后的格式必须有相应的应用范围，也就是应用领域的大小。
这部分的撰写思路就是站在用户的角度来告诉研发用户会关注那些部分，用一个测试的专业术语来说，就是“黑盒”级别的。
4.4 兼容性要求
这个不用多说，地球人都知道该怎么写。
4.5 性能要求
这个似乎是不太容易写的，其实也不难，依据是什么呢，就是3.2部分我们所定义的“约束条件”，我们来评测产品的性能，不是靠想，不是靠经验，而是靠我们定义出来的约束条件，我们得出的性能指标一定是要有一个标准平台的，否则以后出了问题，说也说不清楚。
例如：
性能标准平台参考3.2约束条件。
4.6 国际性要求
如果我们的产品还面向非母语用户，那么就要定义一下。
例如：
支持中文和英文两种版本。
这句话写起来容易，问题的关键在于要求产品经理必须熟悉不同的用户的文化环境和对产品术语的理解，也就是说，我们必须要知道对于一个产品词汇，用户会有几种不同的认识。
例如，一个视频文件，大陆的用户习惯于叫“视频文件”，而台湾地区的用户就习惯于叫“视讯文档”，这在做多语言版本的时候就要定义好。
当然，如果这个工作是交给第三方来做的话，你就省事了，但是要交给你来做，对你可就是一个考验了。
通常可以定义一个表格，来说明这部分的标准。
4.7 文档要求
这部分是比较容易忽视的，主要包括说明书文档规范（印刷版）和帮助文件规范（通常为CHM格式）。
按理说公司应该有这两个文档的撰写规范，如果有的话，这里只简单提一句即可。
例如：
1）说明书规范
严格按照说明书规范撰写
2）帮助文件规范
严格按照帮助文件制作流程进行
如果没有的话，建议先完成这两个文档的规范。
4.8 外观要求
也就是我们说的UI要求了，关于这个部分，做互联网和软件的朋友都有自己的习惯和思路，具体怎么写呢，我个人觉的只是通过界面草图来表示还是有些不够全面，不但要直观的告诉UI界面是什么样子的，同样也要告诉UI应该注意和重点关注的部分。
例如：
1）确定整体界面风格
整体外形体现流线，符合现在流行的XP风格，使用户感觉舒适和朦胧，界面上主要元素的布局要合理，考虑到大多数用户使用鼠标来完成操作，所以要符合用户使用鼠标的习惯，比如按钮的布局
2）将操作模式以最简单的方式实现在界面中
界面上用户完成一次操作时点击鼠标的次数要合理，不要让用户进行重复操作，鼠标移动的轨迹要短
3）界面测试过程
向至少3个人讲述界面的操作模式，告诉他们外观的布局，然后把最尖锐的问题和提出者进行讨论，直至得到一个解决方案，或者说服他，把说服他的理由记录下来
4）界定界面语言字体，字号
字体：MS Sans Serif
字号：8
5）界面草图
如果产品所涉及到的界面比较多，可以用一个独立的文档来说明，例如现在许多互联网产品经理都在试着用aurex做产品原型，这就是一种具体的表现形式（虽然我个人并不建议产品经理在这个方面花太多精力）。
4.9 发布要求
这个就比较多了，但是都是细节方面的，通常定义完成后，一般不会有大的变化。
例如：
4.10 支持和培训要求
这个部分也比较简单。
例如：
开通产品官方网站，提供的版块如下：
1）产品最新信息
2）产品问题反馈
3）产品用户交流
4）视频资源交流
4.11 其他要求
除了以上提到的要求外，可能还会有一些需要研发部门整体注意的，这里提出来即可。
例如：
需要发扬的
1、安装过程
（1）多语言选择安装
（2）安装界面和背景图片色彩搭配合理，能够在整个安装过程中体现出软件的特点
（3）安装完成后有感谢提示
2、初始化过程（第一次运行软件的印象）
（1）能够以不同的方式正确的启动软件
（2）启动过程迅速，不会让用户有太多等待时间
（3）简单，使用户移动鼠标和使用键盘次数最少
（4）强大，主界面能够告诉用户有多种可配置的选项，但要提供几种实现主要需求的推荐模式，以免用户错误设置后认为是软件的问题
（5）清晰，使用户知道“共有多少种方式实现他的需求”，以及从界面可以看出能实现何种功能
3、使用过程（整个功能实现，即用户享受使用价值的阶段）
（1）来源：位置，名称，允许的类型，大小，时间（绝对固定）
（2）输出：位置，名称（可改变），允许的类型，根据设置估算大小
（3）设置（输出）：可以方便的使用户进行设置，避免使用生涩，专业的名词，而使用户不知从何下手
（4）进度条：单元，整体进度，转换时间记录，剩余时间估计，使用户对使用进程有一个清晰的认识
（5）能够在转化完后使用户能够方便的管理文件
（6）不会影响用户使用其他软件
4、卸载过程（留给用户最后的印象，这是品牌递延的机会）
（1）能够正常的启动卸载功能
（2）卸载完成后要有相关的提示，并且自动删除垃圾文件，如果不能，要说明
（3）卸载完成后要有感谢提示
需要避免的
1、界面问题
（1）界面各元素布局不合理，主次不分，使用户在完成一个操作时比较麻烦
（2）界面死板，没有流行界面的特点
2、操作模式问题
（1）设置过于复杂：用毫无意义的专业术语来定义转换后的视频文件，使普通用户望而却步
（2）忽略品牌递延和增值：过于强调“转换”，忽略管理和播放，使用户感觉转换过程是个纯粹的黑匣，也就没什么忠诚度可言
（3）不能做到随处转化，应该加强右键操作，使用户可以在看到视频文件的时候点击右键就可以迅速调用转化功能
3、技术问题
（1）支持的功能繁杂，就像一个大杂烩，有些功能对大多数用户并不实用或者实现后的效果很差
（2）占用系统资源太多，影响用户的正常使用
（3）不能为用户着想，要么对系统要求太高，要么不能顺应硬件发展的趋势
（4）转化后的文件不能正常使用
4.12 流程概述
说明产品的使用流程，如果多的话，同样可以用一个独立的文档来说明。
例如：
4.13 产品需求概要表
写完了上面的内容，最后再附上一个需求概要表，这样做的目的是能够让不需要全面浏览PRD的读者（例如CTO）可以一目了然的看到产品的需求都是什么，节省对方的时间。
例如：
第五部分：支持信息
这部分就比较好写了，不做详细介绍了。
PRD的关键就在于写好第四部分，第四部分中的十三个小部分，通常来说都是需要的，当然如果有特殊的情况，也可以进行删减或者增加，模板只是一个参考，具体的使用和用好，还要看大家在工作中的体会，总之一句话，我开个头，大家一块来完善！
0 条评论