PRD 用 axure 完成有什么弊端？
回答·105
最热
最新
- 用炒锅炒菜有什么弊端
- 但凡做过产品经理，我感觉都不能问出来这问题
- 就目前看，本身不会有很大差别，甚至 axure 的展现效果要远远优于 word。毕竟 word 能够支持的元素 axure 都支持。 但是缺点是甲方不认。在项目上，甲方都要求以一定格式编写的 word 文档作为交付标准，axure 显然不行。由于 axure 的画布可以任意设置尺寸，后期想转为 word 也存在一定难度和工作量。
- 人家问的是 PRD 用 Axure 完成有什么弊端，那些说 Axure 不能做 PRD 的有点激进了。 先说 Axure 能不能写 PRD？当然能，不就是把 word 上的东西粘贴到 Axure 里吗？换个展现形式就不行了？ 再说 Axure 适不适合写 PRD？看团队。团队磨合好或者成员能力强，完全可以。 那么弊端有哪些？ 1.不利于过程文档的梳理和保存 很多公司有 iso，cmmi 之类的评审要求。如果你是乙方，可能还要按照甲方的模(mú)板去编写各种文档。很可能在这个过程中，PRD 的各个要素或者说组成部分都已经完成了，那只需要整理一下就可以汇总成 PRD，也就不存在这个问题了。 2.版本管理和需求变更较复杂 假如 v1.0 版的 Axure PRD 已经完成，在开发过程中很可能会面临着需求变更。在这点上 word 如果做好标题索引的管理，是可以很快速的定位到对应的需求位置的，而 Axure 不具备这一点。也就是说 word 可以把 PRD 做成结构化的文档，而 Axure 本身的特点不在于文档编辑，可能会更复杂一点。 3.对团队要求高 大公司有严格的文档过程要求，可能不会允许这么做。小公司尤其创业公司为了效率和时间可能会选择这么做。 我以前的创业公司最开始也是这么做的，旁边是 php 主程，基本上就是我梳理完需求、画好了前端的原型图，并在 Axure 上标明流程图、约束条件、包含的要素等等，后台和前端就同时开搞了。php 主程甚至都不需要我画原型，结合着前端原型就把后台管理系统做出来了。有问题就随时沟通，立即解决。 我们俩都是十几年的经验，俩客户端也都是五六年经验，所以整个团队做起来会很顺畅且高效。 如果你的团队具备能力强、磨合好的特点，为了快速上线产品，这么做也是可以的。但如果项目做大了，还是建议按照项目管理过程按部就班的制作 PRD。
- 居然还有人用 word 写，看着不累吗
- 好像很多人对于 PRD 理解存在一定的偏差。PRD 的阅读对象主要包含产品经理、产品设计师(UX/UI)、测试工程师、开发工程师(前端/后端)。那目前的轻量级系统来说交互设计师会看功能文档从而影响他的信息架构设计、交互设计和具体功能的设计，前端一般会看原型图来决定他的前端开发工作，后端开发和测试最苦什么都得看，因为这涉及了接口开发、数据库/表设计、测试用例等。 参与文档的建设人员也不止产品经理一个人。好的 PRD 文档不仅只对功能本身和功能界面进行说明之外，还需要对产品架构、功能架构、功能内在逻辑关系、功能外在逻辑关系进行体现并进行详细说明。除此之外还涉及系统版本管理、功能版本管理、文档本身的更新和变更记录等内容的维护工作。 好的 PRD 文档，根据不同系统、系统不同规模和复杂程度，分为静态原型设计与对应的交互注解、系统详细说明书、业务流程图、功能流程图、界面交互流程图、系统架构图、接口设计文档、数据库设计文档、补充说明文档(例：专有名词等) 等内容。 一般来说面向用户端的系统(例如移动端 APP)，相对复杂程度会简单一些。如果是游戏、后台管理系统、业务中台系统、或者重量级系统(例如:CRM 或 ERP）相对来说文档结构和文档内容会非常庞大。提醒写文档的新手，切记“文档结构≠界面结构”，所见并不所得，不要把界面交互和 PRD 混为一谈。 最后还需要补充说明的是，文档虽然很重要，但并不是没有文档就不能进行开发工作，沟通仍然是推动效率的最佳方式，只不过不能满足长期的经验传承罢了。满足商业目标和用户需求是首位。文档也可以逐步完善、逐步迭代。写文档的过程也是在逐步提升自己的一种锻炼。最终产出的文档是企业的重要资产之一。
- 首先 axure 图文说明更方便，但是对于开发来说，批注不方便，不能像 word 那样留下不同角色的痕迹，这点非常重要。 prd 是不仅是说明性文档，更是追溯的依据
- axure 写的 prd，相较于 word，弊端主要还是在追溯上。不过蓝湖这款产品很大程度上解决了这一点。但它的优势也很明显，我所碰到的程序员里（尤其自己比较有想法的），大部分都是看原型不太看 word，用 axure 写原型和说明基本上能同时呈现，对于程序员比较友好。
- 年轻产品经理容易陷入一个工具误区 工具只是一种手段，prd 的主要目的是让研发同学搞懂为什么要做，搞懂逻辑关系，针对不同的产品项目，不同的研发团队配合度自己拿捏就好了，不必过度拘泥于用某些工具做某些事
- 故意问一个傻问题引起你们的争议，带活 app 的流量