0岁产品经理:如何写需求文档

移动开发
作为一个产品新人,入职之后,首先就要开始撰写各种文档。而在我看来,其中最重要的非产品需求文档莫属。产品需求文档的英文名称为:product requirement document,简称PRD。

 [[156712]]

作为一个产品新人,入职之后,首先就要开始撰写各种文档。而在我看来,其中最重要的非产品需求文档莫属。产品需求文档的英文名称为:product requirement document,简称PRD。该文档是将一个产品由抽象到具体最重要的步骤之一,也是让技术人员详细了解一个产品的【三部曲】之一,其他两步分别是产品原型和语言沟通,会在接下来的两篇文章中细说。而PRD也是令很多产品新人比较头疼的东西,那么PRD到底该怎么写?

要明白写文档的直接目的!

一般PRD大约会给以下这三类人看:技术人员,公司BOSS以及客户,而本文以及接下来的两篇文章所说的内容目标用户均是【技术人员】。

即然目标人群已经明确,那么将PRD交给技术人员最直接的目的是什么?那就是让技术人员看完PRD之后,便会知道你的产品具体是一个什么样子。一个好的PRD会有什么样的效果?那就是技术人员只有你的PRD,没有原型,不经过语言沟通,他做出来的东西依然是你心中理想的样子。

我该写什么?

写什么

上图便是我为了写这篇文章特意写的一个PRD,是一款快速原型设计软件的PRD,类似于Axure的手机版。我个人偏爱用Axure去写文档,这样可以把产品原型直接嵌套进去,更加方便和直观,而且个人推荐用Axure去写PRD。当然,工具只是辅助性的,文档好坏看的还是内容,大神用word同样可以将文档写的栩栩如生。

接下来进入主题:首先看右侧内容,你们只需看一点,就是【文档的版本】:一个文档诞生之后,肯定是要经历不断修改的过程,那么修改之后,为了让他人清楚的知道你修改的内容,你就需要更新你的版本号,并写好日期与修改的内容。

然后看左侧的列表,也就是目录,只有三条,因为我喜欢三这个数字,既简约而又不简单,使人看起来一目了然。每条都有四个字,因为我有点轻微强迫症,如果不对齐就会浑身难受,而且用过五笔的都知道,无论是两字词组还是四字成语,都只需要敲击四下键盘就能输入。

列表的三条分别是:【项目概述】、【需求评估】和【阶段规划】,可能会有人说:为什么这么少?能问出这点的人们,首先你们需要先明确我们写文档的目的:只要能让技术人员完全了解一个产品的样子,哪怕是你只写一条也不会有人说你。下面我们举个反例。

反例

上图是在百度找的需求文档,我以一个技术人员的角度去看这个文档,看完前六条之后,我甚至不知道我要去做的是什么东西,那么它错在哪?

  1. 不能快速进入主题。
  2. 无关开发的内容太多。

那什么是【无关开发】的内容?我曾见过的有:市场调研、竞品分析、用户研究、产品价值观、以及上图的开发风险分析,以上内容基本都可以单独拿出来做为一个独立的文档去写,不要一厢情愿的认为技术人员会去看这些内容,我只想说:我!不!看!

我该怎么写?

知道了写什么之后,我们再谈谈怎么写:

项目概述

由于以前是搞安卓开发的,我对tablehost和viewpager情有独钟,于是就仿照做了一个Tab分页,如上图。

项目概述,顾名思义,就是要做到看完之后让人大概对这个产品有一个初步的了解,并且心中对产品有一个雏形。那么目的明确了,怎么去实现:首先说明使用人群,使用人群明确之后,才好针对他们的需求,去设计和开发功能,也就是用户需求,而用户需求往往都是多而杂的,需要对其分类之后,再详细描述,如下图:

用户需求

用户需求大致可以分为以下三点来分类说明:基本需求、期望需求和兴奋需求。

  • 基本需求,便是我们产品初级开发阶段要去满足的内容,也是用户使用你产品的必要不充分条件。
  • 期望需求,便是在基本功能可以实现的基础之上,用户希望你去添加的功能,也是开发中后期以及运营前期我们去要实现的功能。
  • 兴奋需求,便是用户没有想到,但是你不但做到了,而且用户很需要,用户使用之后会感到兴奋,甚至推荐给他人使用。也是运营中后期要去做的事情。

但是在我过去开发经历中,并没见到过什么另人眼前一亮的功能,这不得不算是一种遗憾,甚至有的时候PRD只看了开头,便已经猜到了结尾,这不得不说是业内互相模仿的悲哀。

项目概述写完之后,大概功能就已经了然于心,那么我们就需要将它具体化,而实现这一目的***的方式就是需求评估,如下图:

需求评估

图中我只列举了四个例子,当然实际开发中要实现的功能远远不只这些。这个表格有三列,分别是:需求等级、功能名称和功能简介。

我只说一下需求等级:生活中无论做什么事情,先后顺序都是按轻重缓急去分的,开发亦是同理,所以你需要给产品的功能加上需求等级,让技术人员清楚的知道开发的优先级。做完这步之后,你就需要详细的描述每一个功能,如图中左侧的画图功能和跳转事件,这个我就不放图了,大家根据具体情况去写就可以了。

基本上写完以上内容,你的需求文档就已经成型了;如果技术人员看完之后还不知道要去做什么,那只能说明你的PRD不合格。但是真的不合格该怎么办?你需要做的不是去改,毕竟连写都写不好,你又能改成什么样子?你现在所需要的是补救!那么怎么去补救?你需要去写一个阶段规划,如下图:

阶段规划

所谓的阶段规划就是:将一个产品的开发过程一步一步的分解开,详细的说明技术人员在接下来的这段时间具体要做些什么,如果用文字描述不清,那就借助工具:比如说大家用的最多的流程图,你需要在图中把你的产品逻辑顺序画清楚,既要简洁,又要全面,这并不矛盾。除了流程图,你也可以用N-S图,PAD图以及E-R图等,你要记住,用工具不是目的,目的是用工具去解决问题。基本上阶段规划写完之后,PRD就可以结稿了,接下要做的事情就是随着需求的变更而不断的去修改内容了。

本文到这里就即将结尾,如果阅读本文之后,你还是无法写出令技术人员满意的文档,导致技术人员无法理解你的意图,那么不要担心,请等待我下一篇文章的发表,在下一篇文章里,我会去教你们:如何用Axure中最简单的功能去制作一个另人满意的产品原型。

责任编辑:倪明 来源: woshipm.com
相关推荐

2022-10-26 08:48:55

IT岗位产品经理

2016-03-07 10:32:15

Facebook产品经理故事

2011-10-13 09:29:04

产品经理

2011-05-26 09:39:53

程序

2012-03-20 09:44:39

编程开发

2013-09-05 11:05:29

2016-03-09 11:19:01

2018-12-19 17:20:17

2020-02-28 11:13:35

办公阿里周报

2013-05-27 10:37:54

产品经理产品管理

2013-04-07 17:22:29

产品经理

2013-12-26 16:45:22

产品产品经理

2013-05-02 09:36:44

代码项目

2020-12-14 08:17:50

代码

2021-01-22 10:09:23

简历求职者面试

2012-11-08 10:38:06

产品经理项目管理

2012-10-31 10:30:22

产品经理

2012-12-04 10:15:06

2022-10-08 00:06:00

JS运行V8

2013-12-10 09:50:03

技术技术博客
点赞
收藏

51CTO技术栈公众号