管理产品需求————产品经理的本职工作

零、废话

常常听到有人说：“产品经理原来并不是一种职业，只是做的人多了，就仿佛成了一种职业”。这种话放在一两年前是非常正确的，然而在互联网产品急速发展的今天，产品经理早已职业化了。正因为早期的产品经理并不是一个专门的职业，担任产品经理相关工作的人可能来自运营岗、技术岗、设计岗或是其他任何岗位，导致人们对产品经理产生了一些误解，觉得产品经理必须懂设计、懂技术、懂运营。然而这完全是本末倒置。产品经理的本职工作应该是经营好产品本身，设计、技术、运营和管理这些技能只能算是产品经理的附加技能。正如同郭德纲经常强调的，相声演员本门的唱是太平歌词，这属于基本功，其他的唱只能算是附加技能。
　　那么问题就来了，产品经理应该怎样做好本职工作呢？正如前文所述，我认为产品经理必须做好的工作是经营好产品本身。因为我一直从事的是互联网行业，所以下文所说的产品主要是指互联网产品。对于用户而言，产品是由功能组成的，对设计师而言，产品是由页面组成的。对于开发者而言，产品是由代码组成的。对于产品经理而言，产品应该是由需求组成的。想要经营好产品，必须先经营好需求。

一、需求的生命周期

什么是需求？产品是有生命的，产品必然会经历从产生到成长最终走向死亡的过程。正因如此，组成产品的需求也应该是有生命的，应该拥有完整的生命周期，产品经理最基本的工作就应该是管理好需求的生命周期。那么需求的生命周期是怎样的呢？我认为应该是这样的：

1、产生

需求并不会凭空产生，瞎扯到哲学的高度，需求是人对客观现实的主观感受，它必然是来自于某个或者某些人，并且是这些人为了某个客观目的所产生的主观想法。感觉不好理解？来一麻袋栗子！

客户/用户需求
　　用户李大爷：你们这个爱啪啪我不会用啊，有说明书吗？
　　客户小王：你们这产品看上去很简陋啊，真的有效吗？
　　
　　经营者需求：
　　运营李大哥：我们下个月想做个抽奖的活动提高下活跃，能给开发个抽奖功能不？
　　销售小马：客户说XXX的产品功能比我们的更好用，你能把XXX的功能都给加上不？不然我们不好销售啊！
　　老板陈总：小刘啊，我看最近直播好像很火啊，给我们的产品也加上直播功能吧。
　　
　　参与者需求：
　　设计师杨大大：你确定要把这个功能放在首页？这样会影响整个设计的一致性，不美观啊，不如放到二级页面吧。
　　程序员刘大神：你这个功能不太好实现啊，现在时间也挺赶的，要不下期再做吧。

上面这些是互联网产品生命周期中最常遇见的各类需求，这些需求都属于原始需求，需要经过产品经理的挖掘和处理，将其转化为真正的产品需求。

2、转化

原始需求通常是不能直接作为产品需求使用的，因为它们通常是特定个人的主观感受，需要产品经理对其进行挖掘和提炼，最终得到的才是产品需求。挖掘和提炼需求的方法是一个相当复杂的过程，就不做展开了，还是利用上面的例子简单说明下：

用户李大爷作为老年人，可能对移动应用的使用有一定的学习难度，所以他需要的是更加简单和直观的操作以及一定的使用指引。
　　客户小王因为没有具体的身份属性说明，所以只能粗略的判断他所需要的是更符合他审美观的设计，或者更加丰富的功能，需要和他进行更多的沟通才能做出准确的判断。
　　。。。。。。

转化成产品需求后，就需要为需求设置优先级，以便确定在什么时候实现需求。

3、实现

这个阶段就是最痛苦的编写产品需求文档的时间了，还要设计产品原型等一大堆的文档、协调给岗位井然有序的参与到开发工作中来，并且要时刻关注着开发的进度，一不小心还要遭到各岗位的大神们的嫌弃，想想就心累！

4、验收

需求验收和产品验收还是有差别的，产品验收只要保证做出来的产品与设计保持一致并且产品的质量达标即可。但是需求验收除了产品达标外，还要保证产品和最初的需求一致，需要保证成品和需求提出者想要的是一致的。

5、结束

需求完成了并不代表一个需求的生命周期就此终结了，因为当产品策略进行到达不同阶段或者产品开发到不同阶段时，需求也是需要跟着升级的，比如增加新模块时，之前的通用功能是否要加进去？之前无法实现的需求，现在可以实现了吗？所以需要给需求添加相应的版本号，并加上方便检索的便签或关键词，说不定哪天一个沉睡着的需求，会为产品带来令人惊喜的创新！
　　

二、怎样管理产品的生命周期

“君子生非异也，善假于物也”。一个适合的工具能让需求管理事半功倍。能够帮助管理需求的工具非常多。

各种项目管理工具：redmine、worktile、禅道等
GTD工具：OmniFocus和各种todolist
笔记软件：印象笔记等
其他如需求卡片、excel等

每个人都可以选用自己管用的工具，还是以项目管理工具为主，可惜的是在项目经理已经完全职业化的今天，似乎并没有一款专业化的产品经理工具，例如能够帮助产品经理管理需求，管理和生成PRD之类的各种文档，管理和展示原型之类的各种资源。（隐约觉得可以在这个方向上做些什么！）

三、一个需求管理的纯虚构小例子

1、需求的产生

假设我现在正在负责一款名叫“需余”的需求管理工具的产品经理工作，项目已经完成基本功能，并且我们已经获取倒了一定量的用户了。
　　有一天，客服小韩突然突然抖了下我的窗口，我兴奋的以为有什么幸福的事情即将发生，打开窗口后看到：“”。在简单的调戏了一下客服后，我立马将这条需求记录了下来。

2、需求转化

在获取到新的需求后，并不一定要立刻将其转化为产品需求，具体什么时候做转化这一步，主要还是看自己的时间和习惯。
　　因为这个例子中的需求是确定的，不需要再自己瞎捉摸了，所以确定产品需求的过程也变得相对简单了。用户需要的是管理需求文档的功能，对于我们的项目，可以把这个需求分为两个部分，一是管理文档的功能，包括但不仅限于产品需求文档，还可以是各种商业文档。还有一个部分当然就是针对产品需求文档本身了，

在获得了真正的产品需求后，我们可以很方便的对其进行排序了。排序的方法可以有很多种，因为基本上是由产品经理个人决定的，所以是一种非常主观的行为，我个人比较喜欢根据紧急性和重要性进行排序。我的方法是，紧急性和重要性按照高中低分为三档，分别用2、1、0三个数字表示，我觉得紧急的事情需要有更高的优先级，所以再给紧急性1.5的权重，最后的公式是：紧急性*1.5+重要性=优先级。

3、需求的实现

这一期的需求正在如火如荼的开发中，也是时候开始准备下一期的需求了，于是乎默默的翻开了小本本，看看之前记录下来的各种需求。按照优先级排序，排第一的居然是“管理产品需求文档”这个需求，多么神奇的巧合啊！于是乎很无奈的提取出这个需求，开始痛苦的写起了“产品需求文档管理”的产品需求文档。。。
终于赶在需求评审会的前一秒完成了产品需求文档的编辑，会议进行的很顺利，大老板奇迹般的没有毙掉这个需求，于是这个需求进入了正常的开发环节。接下来要做的只有把需求的状态改成“进行中”，然后乖乖的跟进项目的进度即可。

4、后续
开发完成后，做好验收工作、做好各种跟踪和反馈，并做好各种文档的归档工作即可。