PDR产品需求文档模板.docxVIP

PDR产品需求文档模板 1、产品需求文档只是一个工具，具体一个需求怎么从一个想法变成可落地实施的需求 方案，从参考之前写过的文章?《从o到1设计产品——我的产品心得大起底?（一）》 ?《从o到1设计产品——我的产品心得大起底?（二）》 2、产品需求文档模板，只是一个规范化的格式，比拟快速的把需求文档框架产出。 但根据每个具体需求，侧重点的描述不同。比方做后台交易等等，侧重于状态机的 流转。前端页面除了流程外，更重要在于页面闭环和异常提示等。所以在这个模板 下，每一块信息的表达，采用什么图示都是需要根据需求灵活处理的。最重要是把 你想要传达的信息表达清楚。 3、产品需求文档写的步骤三部曲： 建框架：通过需求背景、竞品分析，梳理大致流程。如优惠券需求大框架是：发放- 领取-使用闭环搭骨头：按照这个大框架，梳理流程图（泳道图）、思维导图（信息结构图） 填细节：最后画原型、填文案、异常处理细节 文档修改记录 编号 文档版本 修订章节 修订原因 修订日期 修订人 1概述产品需求的来源，定义清晰要解决的问题，提供的用户价值或商业价值，即回 答〃要做什么〃和〃为什么要做〃的问题。 1.1需求来源（重点）清晰交待想法来源，一般会有如下情况: .数据变化，此时需要交待数据分析过程和结论; .用户反应，最直接的就是放上用户真实反应截图，说明出现频次、数量 等影响范围； .市场或竞品分析，需要结合以上两点来大致说明这个需求〃是否值得做 〃，例如，竞品上了某个功能数据有了增长，或是通过调研的结论侧面推导 出某个机会点； .脑暴和猜测，要明确风险，交待验证思路和佐证方法；用户故事 （重点）回到本质，站在用户角度阐述场景和价值，以及每个故事对用户 的重要程度。 一般情况下，一个需求最好只对应一个用户故事，如果出现对应不同角色 相同场景，或确实和不同场景的故事都相关，需要列出全部用户故事。 用户故事写法：作为〈角色〉，我想要活动/功能，以到达价值，比方：作 为〃网站管理员〃，我想要〃统计每天有多少人访问了我的网站〃，以便于〃向 我的赞助商展示我的网站给他们带来了多少价值〃。 产品目标确认需求对应的产品短期目标与长期目标 短期目标：让开创造确这一期最小闭环是什么。同时上线后，怎样的数据 结果才代表需求是符合预期的 长期目标：同时长期来看开发上有什么需要预留考虑的/数据效果名词解释 文档中涉及的术语解释 名词 说明 2解决方案设计回答〃我们准备怎么做，但没有会让人陷进去的细节。 现有方案分析（如有） 通过和客户现存的方案进行比照，我们可以初步估计完成这个需求或用户 故事的紧急程度，这里引出俞军的价值公式：价值=（新体验?旧体验）-迁移本钱。 通过和市场上的竞品方案相比，我们可以清晰这个机会点所面临的竞争情 况，辅助进一步判断适合我们自身的投入程度和方式，比方，选择和第三 方合作，或直接先对齐竞品等；解决方案图示 （重点）略去繁复的交互细节以及视觉样式，用逻辑解释方案的思路，可 通过以下列图示表达 L基本流程图，用来展示完成一个功能所需要经历的步骤 .跨职能流程图（泳道图），功能涉及多角色或多模块时，可以更清晰整 个过程各个角色的动作及前后关系或各模块的逻辑关系 .页面流程图，多页面产品需要表达页面层级和跳转关系（更适用于C端 产品） .功能模块图，可用思维导图表达系统包含的一级模块，一级模块包含的 二级模块，子模块中包含的功能点等附属关系3迭代功能列表和详细说明 前面都是准备，接下来要真刀真枪地实干了。原那么上细节越丰富，实际开 发过程中的风险就越低，但也不用刻意追求完美，注意迭代的节奏。另 外，和团队中的其他角色共同完善，补充会是一个更好的选择。 功能总览 先简单讲要做的功能及优先级罗列，便于一眼看过去进行时间与工作量的 评估，优先级判断，便于如果规定上线时间的话，可砍优先级低需求。如 下范例： 模块：注明产品模块，假设需求仅包含小功能点，那么去掉该列。假设模块还有 子模块，那么可添加子模块列。 功能：用简短名称概述需求的功能点说明：对功能点的描述 优先级：给每个功能点定义优先级，如PO, Pl, P2…其中，P0优先级高 功能详细设计 （重点）将满足需求的方案拆解成更具操作性的颗粒度，一项一项的功能 可以对应一个个具体的开发任务，辅助技术方案也方便后续跟踪进度。在 这里尽量展现隐藏魔鬼的细节，有一些也是让用户〃啊哈〃的高光。 通常使用列表和表格来罗列所有功能，同时给出每个功能对应的线框图、 交互原型以及视觉设计稿，最后附带界面元素级别的详细说明。 模块：注明产品模块，假设需求仅包含小功能点，那么去掉该列。假设模块还有 子模块，那么可添加子模块列。 功能：用简短名称概述需求的功能点说明：对功能的详细描述，需要包含所有细节点考虑 原型图：假设有原型图那么附上（