基于Aure的PRD写作思考.pdf

基于Axure 的PRD 写作思考 本文想说的事情是，那个叫 PRD 文档的家伙只是个称呼而已， PRD 的问题不在于如何写而在于如何 被传递与执行。这里简单介绍一下我基于 axure-rp 的一种新的 PRD 写法。（友情提醒：从来不 用axure ，认为他笨重无比的人请路过。） 从半只脚迈入产品经理这个大门的那天起我就被 2个文档的名称深深的纠缠着，他们是市场需求文 档（ MRD ）、产品需求文档（ PRD ）。先不论你是什么方向的 PM ，这2个玩意一定会一直伴随你 的Title 跟着你。这 2 个文档在不同的团队中有不同的叫法和写法，我也见过有团队的 MRD 其实就 是 PRD ，不沾半点商业市场分析的边的，当然，这些不是本文探讨的内容。 长久以来，有个很有趣的现象： 有没有“ PRD 模板， PRD 该咋写 ”这个问题已经成为新手入门经典必 问题目之一；如果 1年以后这个家伙还在这行里混，他一定会抱怨，娘滴，我们的 QA 压根就不看我 的文档、我们的交互（如果有这个职位的话）还是会问我一些我写的很明白的问题、我们的测试拿 着文档问我该咋测试、 …. Web 页面之间的关系是网状的，而 Word 文档只能树状的表述，这无疑是矛盾的； PRD 文档无法做 到实时更新发布，我回顾了我第一年写的 PRD 文档，很多下面的修改栏都是空的，惭愧之至 ….；所 谓一图胜千言，万言刚够文档标准，每个 PRD 都是臭长臭长的，这样的东西别说交互设计师了，很 多PM 自己写完了都不想看。所以，我武断的认为，撰写某些 PRD 文档实在是一个既耽误时间又费 劲且不敏捷的事情（很多 PRD 都是一夜情，写完了就不会修改更不会有人乐意看 100P 以上的文档） ，是在让产品经理实现慢性自杀！ 个人认为，一个 PRD 文档需要包含以下的内容： 1 、概述 1.1、名词说明：文档中涉及到的名词 1.2、产品概述及目标 1.3、产品风险预估 1.4 、产品开发进度：产品开发阶段及责任人与时间节点 2 、使用者需求 2.1 、使用者需求描述：定义用户是谁 2.2 、管理员需求描述：后台管理部分（很多人会忽略这个部分） 2.3 、任务流程图：从业务逻辑流程到产品逻辑流程转化 3 、功能需求 3.1 、功能总览 3.2功能需求分解：界面分解及交互说明和用例 4 、非功能需求：与该产品相关联的辅助产品等 5 、上下线需求：产品的生命周期 6 、运营计划：产品的上线后的反馈与改进 整个文档中，最大的部分其实是对功能需求的分解，但是最核心的部分是使用者需求与功能需求 部分。使用 Axure 后，我发现 Axure 可以很好的承载我平常写的这个产品需求文档的全部内容，最主 要的问题是， Axure 是可以网状的展示的。下面是举个例子： 在Axure 的站点导航中，默认的 Home 页面承担了 PRD 文档的第一部分内容；而使用者需求描述及任 务流程图也可以由 Axure 自带的流程图功能完成；任务流页面的分解本来就是 Axure 中完成的；最后 的非产品功能部分也可以由 axure 完成（文本块组件） 同时， Axure 支持多种格式的输出，一般情况下我是发送给团队 Html 文件包，也可以是 .chm格式的 文件（团队协作目前还没有尝试）。该文件包打开后，左侧是整个系统的导航菜单，右侧是相应的 说明。最主要在于，原型中的页面是可以相互跳转的（得益与 axure 的强大交互功能），同时页面有 注释功能。所以，整个产品需求文档真正实现了基于产品的模拟，网状的传播，而不是 Word 式的树 状阅读。 1）见过不少新手使用 Axure 生成的原型有页面是空白的，我问为什么，他说这个