刚入行产品新人,你其实可以写一份合格产品需求文档.pdfVIP

刚入行的产品新人 ，你其实可以写一份合格产品需求文档 产品需求文档是产品项目由“概念化”阶 进入到“图纸化”阶 的最主要的一个文档 ，其作用 就是“对MRD中的内容进行指标化和技术化” ，这个文档的质量好坏直接影响到研发部门是否 能够明确产品的功能和性能。 一、简述 产品需求文档是产品人员非常核心的基本功 ！是协调研发、测试、UED、业务非常重要的重要工具 。但是 ，往往很多新入行的PM与互联网领域的PM ，产出的文档往往不尽人意 ，主要体现在 ： 缺乏逻辑 ，语言啰嗦不精练 ； 通俗的用词过多 ，整体显的不专业 ； 无法将字 的数据结构、逻辑关系清晰的表达出来 ； 缺乏开发思维 ； 而出现这种原因在于 ： 新人入职 ，没有经过严谨的文档撰写、流程设计训练 ； 大多数的PM非研发出身 ，对前后台的业务逻辑、数据结构了解不清晰 ； 分工细 ，版本迭代迅速 ，对功能点理解不够透彻 ； 完善的产品需求文档 ，不但利于PM对所承接的功能进行有效的管控 ，将业务逻辑梳理清晰 ，对分解 的功能点 ，进行协调测试、研发、设计、运营同时开展工作 ； 模块化的功能点 （倒爷当年做的一个功能 ） 虽然 ，不同的公司拥有不同的产品需求文档模板 ！但 ，不论模板格式如何 ，文档的本质在于 ：“有效 的将功能清晰的表达出来 ，并且能支撑后续的业务交接与版本迭代参考 ，对上与下进行价值传递。” 并且 ，随着平台业务的发展 ，归档、仓储起来的业务文档 ，便是极其有价值的知识库 ，里面汇总了 各个时期里PM、研发、测试、项目经理、设计….对业务是如何进行思考 ，对文档研究的本身 ，侧 面也反应了企业是如何将战略进行细节落实。 而 ，“业务描述、功能描述、其它需求”是组成产品需求文档非常重要的模块 ；本篇章 ，将以通用版 的角度 ，对这些模块行介绍 ； 的角度 ，对这些模块行介绍 ； 二、业务描述 任何的业务或需求 ，都有业务提出方 ，业务提出是相关的业务部门或产品经理自身。 业务来源的本质 ，便是希望通过这个业务解决那些实际的问题 ，达到提升某些转化率或某些目的 ； 业务描述清晰的表达出来即可 ，不需要多复杂 ，但常规包括 ： 业务背景 产品功能概述 产品前景分析 产品功能整体流程 产品逻辑关系 面向对象 应用对象 名词解释 参考文档 上述的这些层面 ，以通用版的角度 ，将产品的价值传递给研发方与业务方 ，实现之间有效的衔接。 为什么 ，我们需要进行业务、功能、概述这些偏宏观不实际的描述呢 ？这样不是很麻烦 ，且浪费 时间 ？ 我们要知道 ，每新增或删除一个功能 ，狭义来看也没啥大不了。但站在宏观的角度去看 ，功能研发 是需要耗资企业运营成本。如果处理不完善 ，浪费运营成本同时 ，甚至影响整个用户体验与开发 规则。 身为产品人员在未传达产品的业务价值前提条件下 ，便强势驱动研发人员进入开发阶 ，这是错 误的 ！我要是研发 ，我也会拍死这位PM。那么业务描述的本质便很清晰了 ，便将业务价值 ，传递给 团队成员。 另一方面 ，非常多的企业 ，内部的项目流程是不完善的 ，且并非每一位研发人员都是善类。产品经 理往往需要兼备着项目经理的职责 ，推动着项目实现研发上线。在这种情况下 ，如果业务价值描述 不清晰 ，功能在开发与上线后出现问题 ，这个锅注定是要背的。 BT W ，这些我就不都说了 ，自己工作中慢慢积累 ！ 下面 ，我对组成业务描述的组成元素进行描述 ： 业务背景描述 ： 这里 ，你必须将业务提出方描写出来 ，并且细致到业务方为什么将这个需求提出来 ！为什么 ？一 方面 ，你要告诉研发人员 ，你为什么设计这个产品或功能 ，这个需求从来源到设计是有原因的。另 一方面 ，拉上相关业务部门 ，你至少不是一个人在战斗。 产品功能描述 ： 对当前功能进行概述 ，所设计的产品或功能的功能模块 ，新增、完善、优化那些产品功能 ； 产品前景描述 ： 本产品或功能 ，希望对那些转化率指标或实现那些目的 ； 产品的整体流程 ： Visio 、Axure （Axure画的流程图好丑 ）。 通过而言 ，简单的需求将主业务流与逻辑关系流表达出来便可以 ；但涉及复杂的业务 ，便将产品或 功能涉及的主要流程绘制出来 ；而流程目的 ，主要是清晰的将前后台的逻辑关系与数据结构表达 出来 ；一方面方便开发理解业务与数据流 ，另一方面也方便产品人员梳理自身需求的业务逻辑 ；利 于后续与研发进行沟通。 具体的流程数量 ，根据业务的复杂