去哪儿产品总监手把手教你如何撰写一份合格的产品需求文档PRD

怎样写好PRD 讲师：施沈阳PRD遇到的挑战? „ 文档是哪个SB设计出来阻塞项目进展的 „ 产品总监、开发、测试干嘛老不断挑刺 „ 交接一个新产品，翻看原文档发现不知所云   什么是PRD? Product Requirement Document 产品需求文档  „ 对产品需求的完整描述 „ 开发和测试的唯一依据 „ 产品经理考核依据 „ 后续历史追溯和备案   写PRD的理想境界 多、快、好、省  „ 多——完整   l 各功能点无遗漏，无缺失。 „ 快——高效   l 从方案确定到文档完成耗时短。 „ 好——准确   l 无歧义，结构合理，便于开发及测试人员阅读和理解。 „ 省——低沟通成本   l 讨论、评审、后期修改通报，流程合理，沟通顺畅。 基本步骤 „ 是否立项 „ 搭建框架 „ 梳理主线 „ 填充细节  第一步：是否立项 1. 老大让立项不代表真的值得立项 „ 经验、直觉不代表真理 2. 问题---目标—论证—资源（性价比）---研发周期---测量方法 „ 不能发现问题的PM是不合格的 „ 建立指标模型，如果需求不紧扣这些模型，那估计哪错了 „ 不能量化的目标不值得做 „ 没有推导过程订立的目标小心无法完成 „ 不能评估工作量的需求没法进行性价比评估 3. 这部分只所以重要原因如下 „ 如果模型评估，发现目标太低，性价比太低，你就不用写文档了 „ 如果发现目标可以特别高，恭喜你资源向你奔来 „ 如果一开始没有想明白就开始动手写文档，50%概率你会写偏 第二步：搭建框架 将产品所有功能进行合理分解和排序，确定PRD各节标题。  基本规则： „ 按页面元素分解  上—下、左—右 „ 按用户操作步骤分解  提交—展示—展示后编辑 „ 按在系统中所处位置分解  前台页面—用户管理后台—官方管理后台 „ 按功能主次分解  主要功能—次要/附属功能（特殊权限、广告位、 其它相关说明等）  第三步：梳理主线 按照已确定的PRD章节顺序，用关键示例图+简要文字描述 的方式对主要功能点进行说明。  „ 此步骤只关注功能主线，不用有过于详细的描述，也不用涉及各种特殊状态和细节的处理。 „ 使产品所包含的主要功能在PRD中有完整体现。 „ 在主要功能点的整理过程中，对PRD的结构及时进行合理调整 „ 时刻回顾下主线跟目标关系 „ 此步骤完成之后，可与开发人员进行初步沟通  第四步：填充细节 „ 对产品功能及其它相关需求进行完整说明 „ 包括所有操作流程、判断逻辑、权限区别、页面效果、特殊状态处理、错误提示、已有功能说明等 „ 此步骤完成之后可发起内部需求评审  细节说明通常会占到PRD篇幅的70%以上。一份细节清晰完整 的PRD是项目顺利进行的有力保障，也是PM对产品理解和 掌控程度的重要体现。   1.任何页面都要说明“从哪来，到哪去” „ 页面入口 „ PC时代有title、DESC、KEYWORD „ 页面初始状态 „ 页面展现和功能细节，按一定顺序描述 „ 各链接点击效果、指向地址、打开方式、刷新方式 „ 浮动层具体策略  是否自动关闭  右上角是否展示关闭按钮，点击效果如何  若在浮动层中可打开新页面，原浮动层是否关闭  关闭后是否刷新页面  ……  tips：如果能用低保真交互原型进行表现，可以丰富你的文档。 2.不要只考虑普通用户 若页面对不同权限用户有不同展示和功能，要完整 说明并提供准确示意图。 „ 审核人员 „ 普通用户 „ 登录会员 „ 酒店方 …… 3.形成条件反射的错误提示 „ 输入为空  包括输入空格/空字符串 „ 超过字数上限  前台以汉字数提示，技术上以字符数限制 „ 含特殊字符  可用字符集一般分常用字符（汉字、字母、数字、下划线）和GBK字符两种，由输入内容的应用范围而定 „ 含过滤词  需明确过滤词表 „ 其它输入无效的情况  有特殊格式要求/不能重复/有特定范围限制/ „ 无提交权限  退出登录/被封禁/不符合权限要求  …… 4.输入框里陷阱多 „ 是否可以为空 „ 是否有初始内容，是否默认选中 „ 大小写/全半角/繁简体是否转换 „ 任何输入框都需要字数上限 „ 允许的字符集 „ 空格出现在首尾和中间部分，或者连续多个空格的各自处理方式  „ 多行文本框的连续空行、不连续空行、空格、tab键、回车键等处理方式  „ 是否允许快捷键控制 5.事情的发展总可能脱离理想状态 „ 对于满足一定条件才有效的功能，需要说明流程中遭遇各种极限情况时的处理策略  6.不要轻易写“与线上保持一致” „ 升级类项目，可以只说明有改动的部分 „ 新产品移植或调用线上已有功能，需重新进行详细需求描述 „ 搜索框、翻页等通用模块，可以不再单独说明，但需要写上引用哪个文档 „ 拿捏不准时可与项目组同事沟通后达成一致 7.无结果页/边界限制/统一出错页/ „ 初始无数据/搜索无结果 „ 无论实际上限或理论上限，PRD中最好给出各种边界值，并说明是否要求灵活可配置。 „ 除已说明的错误提示外，需要给出在其它情况下默认的统一出错页。 全部页面错误： 局部页面错误： 操作类错误： 8.特殊上线要求需说明 „ 是否分批开通 „ 是否初期只支持特定用户 „ 是否需要先上线但隐藏用户入口 „ 是否对上线时间有精确要求 „ 是否对各功能有上线顺序要求 „ 是否有其它前置项目 如果上线要求比较复杂，而且原PRD内容已经非常多，最好 单起文档说明 9.图文一致，符合实际 „ 页面截图和文字说明必须保持一致 „ 前后文中的截图必须保持一致 „ 截图必须与实际情况相符 „ 我最怕听到的是，对不起，我图忘记改了  如果评审后有修改…… „ 文档中记录修改历史和时间 „ 与相关开发和测试人员明确修改细节 „ 邮件通知项目组成员 „ 在PRD中对修改点进行特殊标注，必要时进行宣讲  小贴士 „ 关于截图  一个页面至少需要一个完整示例图  页面各模块至少需要各一个示例图   其它细节说明，在不影响理解的前提下，截图越局部越好  截图在PRD中加边框以便和文字区隔 小贴士 „ 一千个文字比不上一个图表          城市家数区域不合格有logo和⽔水印疑似重复不美观不合格率桂林187详情展⽰示图691.36%47.70%50.68%36.90%⻄西安690详情展⽰示图725.75%98.71%28.75%10.43%北京300详情展⽰示图740.00%52.70%47.03%24.67%深圳270详情展⽰示图924.11%35.80%59.87%34.07%总计1447详情展⽰示图3072.88%57.30%47.56%21.22%再啰嗦几句 „ 关于check list „ 关于通用策略文档  结束谢谢大家！