如何正确的看待:产品需求文档和产品需求

其实那会还在北京的时候,就曾经写了篇文章叫《正确的写">产品需求文档(PRD)》后来被转载无数,现在想想那会还仅仅是停留在技能的熟练度一样,或者说通过这篇文章可以让大家掌握一种快速文档的套路。

因为最近还是有很多新人问我要产品需求文档,他们很想看看一个典型的产品需求文档应该是什么样的,我直接拒绝了,我一般会说:“请多想想”。我是这么的理解:看文档本身其实是没有意义的,特别是产品需求文档,其实是需求的产物。作为产物就好比是你今天用一个手机,看手机的说明书一样,你已经知道了这个产品是什么样子,但是为什么这么做,如何做?先做什么,后做什么,你还是不知道!

所以从产品需求而言,文档本身没有个推导的过程。这也就回到一个问题上,很多产品经理新人本身是意识不到,如何做需求,如何写需求文档的差别的。在他们的潜意识里,反正公司是需要有产品需求文档这么一种载体来表达他们的想法,所以很自然而然的认为,学会了写需求文档,就掌握了如何做需求,处理需求一样。

这样听起来有点绕口,但我表达的观点是:想与做的过程是分开的。一个是过程,一个是因为有这个过程的产物,很可能很多时候产物本身可能没有太多的意义。但从表象上来看,文档写的有没有逻辑感,有没有层次感,表述的文字是否清晰、清楚也是一种境界。

很多时候我们写方案做PPT,很多人写出来的东西是完全不一样的。那PPT的宗旨是:简单、标题化、有视图、也不乏空洞。之所以举这个例子,其实是所以一样的情况。写产品需求文档本身其实更多的是:产品需求推导的过程。因为先有了推导的过程,然后再有了推导的结果。很顺利成章的,各位产品经理新入门的朋友,你是否也具有:“产品推导”的过程呢?

产品推导的过程是:做什么,为什么要这么做,谁来做,怎么做,一步步怎么做,最后做成什么样,最什么要做成这样,不做成那样。写需求文档的过程其实就是处理需求的过程,所以以上这几点有没有写想明白?很多公司要做一个产品,可能高层是想要一个东西,但在执行的过程中因为上下级之间认识、理解的不一样,所以在执行的过程中或多或少有所偏差。所以在这个过程中,回答上面几个本质的问题,是会纠正你做需求的思路,不会做弯路。

产品经理这个群体是个很奇怪的群体,他们的主观性非常的强,喜欢把产品按自己的兴趣和喜好去做,所以得出一个结果本身不难。因为这个结果很可能是出于产品经理主观喜欢的结果,但如果从过程出发得到一个结果,这个时候大家相比一下过程和结果本身而言,对于结果的认识想必也会不太一样。

结合今天说的主题:《如何媒体正确的看待:产品需求文档和产品需求》,产品需求文档可以是没有固定格式的,大家不要把产品需求文档想象的怎么样怎么样。写产品需求文档,是做产品经理的一个基本能力,写的逻辑感怎么、层次感怎么样,写的是否清晰和明白,是有一定差别的。但本质上不管是excel、word、rose、还是txt,其实都是次要的。

宗旨:让给你需求拍板的人,知道你的逻辑是什么,让和你一起做的程序员很清晰的知道需求是什么,让给你一起测试的人员知道你的细节就可以了。以后也方便于版本升级,知道你一个版本、一个版本都加了哪些需求,改了哪些需求,删了哪些知道需求就可。 所以文档本身起到的东西就是这个,一个是告知,一个是存档。

但产品需求是本质核心的东西,只有你想明白要做什么,怎么做,谁来做,一步步推导的过程是否合理、是否让自己信服,让别人信服,这才是最根本的。有了这个做保障产品需求在文档化的过程中,才会层次分明,结构清晰。所以当很多朋友一直在问我文档怎么写的时候,请大家好好的想一想:我应该在哪几个方面处理这个需求,需求的维度怎么切割?需求的优先级怎么切分?哪些是核心的,对整个产品起到重大关键的?哪些是锦上添花的?哪些是可有可无的?需求的主线是什么?……等等

只有想明白了这些,才会轮到如何把产品需求,进行文档化的阶段。这个时间,我们再回顾头看看《正确的写产品需求文档(PRD)》,通过一些小的思维方式把写文档的技能组织起来,发现所有的一切都是那么顺利成章。最后也忠诚的建议大家:要想学会写需求文档,请先学会怎么样分析需求开始。生活也一样,从本质看起,这样我们感受到的会不一样。

本文作者: 费杰

发表日期: 2010-08-15

文章链接: 如何正确的看待:产品需求文档和产品需求

时间: 2024-12-23 11:52:04

如何正确的看待:产品需求文档和产品需求的相关文章

好的产品需求文档(PRD)怎么写?

PRD(Product Requirement Document,产品需求文档),顾名思义是阐述产品需求的一种文档,其核心是将需求描述清楚. 通过PRD可以看出一个产品经理对产品理解的逻辑思维,产品经理在相关领域的认知和专业的深度以及对产品全局的认识.如何才能写出好的PRD,让产品研发团队成员,开发.测试.运营同学了解产品需求,让其他人能从该文档中看到产品的价值和意义,估计很多人都思考过,如何让PRD不被其他人挑战,如何获得他们的认可估计是产品经理经常考虑的问题.也有人可能认为PRD只要中心思想

互联网产品商业需求文档(BRD)的设计

文章描述:互联网产品商业需求文档(BRD)的设计. BRD是英文"Business Requirement Document"的缩写,根据英文直译过来就是"商业需求文档"的意思,指的就是基于商业目标或价值所描述的产品需求内容文档(报告),其核心的用途就是用于产品在投入研发之前,由企业高层作为决策评估的重要依据. BRD与PRD的差异 BRD不同于常见的MRD(Market Requirement Document-市场需求文档)和PRD(Product Requir

产品-写需求文档 并做项目原型的商务PPT有人会做吗?

问题描述 写需求文档 并做项目原型的商务PPT有人会做吗? 听说产品经理会做这种项目原型ppt,但是没有做过,不知道从哪里入手,有人可以告知一下吗?谢谢 解决方案 **我以前做过类似作用的PPT,我觉得主要还是从项目的功能及各方面亮点着手. 一开始先介绍一下项目背景,然后讲解一下项目各模块. 讲清楚项目所能实现什么功能,能够做一些什么事, 最后再总结一下就差不多了.**

产品需求文档(PRD)的写作方法之笔记一

1.写前准备(思维导图): http://www.woshipm.com/?p=80070 1.在写之前,请先很区分清楚什么是MRD文档(市场需求文档),BRD文档(商业需求文档),什么是PRD文档(产品需求文档) 可查阅知乎https://www.zhihu.com/question/19655491 2.规划产品的思维导图(信息结构图) 在写作这份文档前,我们需要先做一些准备,把BRD.MRD的相关需求消化并融合规划出产品的结构图.因为这些准备工作是属于思维类的,所以我推荐使用思维导图软件(

怎样编写一个优质的需求文档

编写需求文档,这在嵌入式开发领域是非常普遍的情况.需求文档是被用来定义开发任务,从而协调大规模的研发计划.而对于最终的产品,需求文档是扮演着一个在开发者行为和消费者行为之间沟通纽带的角色.而当需求文档书写正确的时候,那么就可以发挥巨大的作用.然而,要是你在嵌入式的开发领域工作工作了足够长的时间,那么你就会很快发现,在这个领域里不合格的需求文档实在是太多了.而当你尝试着对这些不合格的文档进行修复时,那么你又会很快发现,书写正确的需求文档绝对不是一件易事.而在这里,我们将会给出一些建议,希望能把书写

如何写出连方舟子都满意的需求文档?

内容索引 1.一个高质量需求的经典要素 1.1 评估需求:确定目标和优先级 1.2 细化需求:SMART原则的运用 2.反例:低质量的需求 3.实践:亲手制造高质量需求 3.1举例:自动告诉妈妈,我快到家了 4.总结:从好需求到好产品 ========================= 1.一个高质量需求的经典要素 何谓高质量的需求?一是需求本身有价值,二是需求被清楚明晰的表达没有疏漏.所以,需求从"一个想法"蜕变为"高质量的需求文档"需要经历评估和细化的过程. 1

互联网产品设计:产品设计文档(PDD)

传统上写产品需求文档(PRD)的做法,就是把用例.流程图和网页原型图一股脑的放到一个Word文档里.一般一个产品都包含乃几十个乃至上百用例,每个用例都有自己的流程图,每个流程图又包含了少则几个多则几十的网页原型图,结果就是产品需求文档变得庞大无比,写的人费事儿,读的人更惨. 自从我受到了这样文档的折磨,我就一直都在琢磨怎么才能把文档写得更简单一点,让阅读的人-通常是设计师和程序员-能够在最短的时间内领会产品的设计. 原来做UI设计师的时候,我创造了一种用流程图来表示产品交互的办法,这个方法受到了

实战从需求文档到设计文档的书写规范(一)

1.前言 本文有两个目的:实现每晚构建平台和探讨一个软件从需求文档到设计文档的书写规范. 每晚构建是软件研发管理中极具价值的手段,对于加快发现和改正缺陷,降低集成风险,提高产品质量,加强成员沟通与协作,缩短产品上市时间,增加项目开发透明度,提高项目组成员信心和斗志有着非常重要的作用和意义.本文从软件工程过程:需求定义,分析,设计出发描述了实战每晚构建平台的大部分过程. 软件工程中文档有着极其重要的地位,良好的文档风格和习惯是一个团队成熟的重要标志.目前有些软件研发人员特别是刚刚走上岗位的研发人员

第一次担任项目经理从零开始架构自己的网站(二) 需求文档定稿,开始建表,建库(转)

       今天上午的半天时间,我们开发部一直都在和产品部门开会,扯皮.吐槽.最终砍掉了几个功能.产品的小姑娘对我说,你们第一期就做一个挂号支付的功能,后台就10几个页面,大多数是增删该查,还说22天不够用??听到这话之后我也没有反驳.产品和程序猿的故事说也说不清楚.会议上老板宣布加班没有加班费,纯属义务,说是在项目完成之后可以多发点项目奖金,我听到这话之后只能呵呵了.下图是我们开会的场景.最终定稿的需求文档和原型图我已经上传到了昨天那个地址.有兴趣的朋友可以下载.开完会后我们大家又看了一会需