潘若迪 prd( 二 )


3、目录
4、请与以下部门讨论PRD
PRD作为一个承接作用的“载体”,会与技术、运营、财务等人员的沟通,而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上,需要与相关人员确定“沟通内容”,这对于产品整体流程将是很重要的 。
5、概述
概念就是总结,它包括的点有:名词说明、产品概述及目标、产品roadmap、产品风险 。
6、使用者需求
使用者需求一般只有个需求描述 。需求描述有以下几项内容:目标客户、需求描述、场景描述、优先级 。
7、可选方案
列出所有可以选择的达到该产品目标的方案要点(主要思路),给各方案适当的评价,并推荐最优方案 。
8、效益成本分析
产品经理是个全才,在这点上得到了体验 。产品经理得知道财务知识 。很大一部分是产品的环境搭建成本和支持人员的成本 。一般的效益成本分析包括三个方面:效益预测、产品技术中心成本、非产品技术中心支持成本 。
9、功能需求
功能需求一般是由四部分组成,功能总览、功能详情、整合需求、BETA测试需求 。
10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上,利用公司现有的资源或外部资源(合作公司等)实现产品功能需求的整合 。
11、BETA测试需求
很多产品都有BETA版本放出,为了就是收求意见和一些性能测试 。
12、非功能性需求
都说产品经理是全才,在这点上得到彻底的体现 。很多产品经理在这点上忽视了,但很多方面使用到的,只是在产品过程中弱化了 。
13、上、下线需求
上线时限需求:此产品预定上线日期?上线日期有无任何特殊依据或规定?
下线需求(活动类需求必须明确下线时间):此产品预定下线日期?下线日期有无任何特殊依据或规定?
14、运营计划
说明产品的后续运营计划 。包括与运营部的协作运营 。更多的是给产品经理如何让更多的产品功能展示给用户,产品经理是核心需求的把握者,参与到产品整体运营计划显得特别的重要 。
……
写PRD并不是产品经理的全部工作,但却是不可少的一部分,很大程度上反应了产品经理的思维和产品核心功能把握上,同时对产品经理沟通、协调、规划等
想学习更多PRD文档写作方式,可以来官网学习
产品经理文档之PRDPRD:产品需求文档,全称是Product Requirement Document,是产品文档中最底层最细致的文档 。文档侧重对产品功能和性能的说明,主要是把产品规划与设计中的产品流程,界面,功能等定义向研发、设计、测试等团队做清晰的描述说明 。
1、帮助团队存档产品信息
产品实现过程中,有很多的逻辑、算法需求,没有文档的记录,容易在团队变更、交接班的时候出现较大风险 。通过产品需求文档记录产品的各种需求与实现方式,能有效降低团队的风险,同时也能提高交接效率 。
2、提升内部信息沟通的效率
虽然需求可以口述,但是不代表说一次全员就都能记得,会遇到开发、设计或测试记不清楚的地方,可以直接查看文档 。结构明确、表达清晰的文档仍然有不可取代的作用 。
3、产品工作有据可查
各方需求理解不一致,或延期产品工作的时候,通过产品需求文档都可以有效的找到问题根源 。
研发人员:由于研发人员本身专注于功能的实现与性能,所以他们相对于其他岗位比如运营,时长,设计等,表现相对不太关系,对于产品更多地了解来自于产品经理的产品宣讲 。
设计人员:设计人员本身更多的会关注产品的表现形式与原型,所以对PRD的需求是相对较弱的 。
还有老板、项目经理、运营、市场、客户、财务……
所以,PRD文档,根据阅读对象,可以用最平铺直叙的话,把产品描述清楚就行 。
文字模式 :Word 。时间较为充裕的或岗位责任制分明,有文档要求规范的团队,建议选择Word撰写文档 。
原型图模式 :Axure 。追求时间效率灵活性的团队,建议选择Axure撰写文档,原型搭配产品说明,无需切换,只用一个文件就可,方便快捷 。
无论哪种方式,都是大同小异,本质上并不影响PRD文档的使用效果 。
1、修订记录:版本号、修订日期、修订章节、修订内容、修订人等 。
版本号说明,以1.25举例:
版本号( 1 .25):重大调整升级,一般是产品结构功能等有调度 。
子版本号(1. 2 5):在原有基础上对局部功能进行了升级或调整 。

秒懂生活扩展阅读