在上一篇中,我们提到了我们交付给团队(主要是研发团队和营销团队)的需求呈现形式有三种:PRD;用户故事(User Stories);工作故事(Job Stories)。

并且在最后也提到了一点,就是所有的这些呈现形式都是由我们的团队成员,而不是由我们这些产品经理设计出来的,这其实说明了两个问题:

1、对于实现需求的团队来说,他们到底需要什么样的需求;

2、对于产品经理来说,如果从我们的角度来看的话,我们该做些什么。

在本篇中,我们就来聊一下如何解决这两个问题。

先来看第一个问题,什么样的需求更能适合现在团队成员的要求。

这个我们就得站在他们的角度来分析。

作为实现需求的团队,我们向他们提供的每一个需求应该具有三个特征:1、清晰;2、合理;3、可实现。

接下来,我就通过三个真实的案例进行说明,这些案例都是我曾经做过的一个产品真实的需求情况。

先来看“清晰”。

什么是“清晰”呢?就是这个需求必须要能说明在产品中一个明确的实现目标。

其实这个看起来简单,但是在做的时候却容易出一些问题。

最容易出问题的地方是什么呢?就是一个需求没有被分割好,从而让实现团队无法准确理解这个需求的目的到底在哪里,简单说,就是看起来是一个需求,事实上则存在多个需求目的在里面。

比方说,有这样一个需求:

可以定义输入DV设备上的影像,通过我们的软件直接播放或者制作成某种格式的视频文件。

当时,我提这个需求的目的是实现一个功能,就是我们的软件可以直接支持DV传输过来的视频(在那个时候,通常是AVI格式的)进行播放和编辑。

这个需求看起来似乎是说明了这个问题,但是当时开发就给我提了四个问题:

1、这个“定义”是指什么?

2、这个“直接播放”是指什么?

3、这个“制作”是指什么?

4、这个“某种格式”是指什么?

然后我就开始给他们解释:

“定义”是指可以让用户自定义输入的AVI格式的相关参数,比方说要保存的文件夹,文件名,视频文件的选择(单个导入,还是批量导入),文件排序等。

“直接播放”是指文件导入完成后,可以提供两种播放模式,一种是直接播放,一种是选择播放,这个可以在设置中进行管理,默认为直接播放。

“制作”是指可以对导入的文件进行后期编辑,后期编辑包括帧的删除、合并,添加水印、添加字幕、片段截取等。

“某种格式”是指可以把制作完的文件导出为mpeg1、mpeg2、mpeg4、rmvb、asf这些格式。

在我解释完后,开发的伙计只说了一句话,你解释这么多,干嘛不在PRD中分开写出来呢。

是啊,为什么不把这一个需求分成四个需求写呢,这样多清晰啊。

因此,清晰也可以这样理解,就是我们一定要把需求尽量分割为最小可执行的单位,千万不要有笼统的说明。

再来看“合理”。

什么是“合理”呢?就是这个需求必须要存在现实意义,确实是要解决消费者的某个真实存在的问题。

很多时候,我们只是假设某个需求是有现实意义的,这只是我们的主观认为,而不是消费者的客观需要。

比方说,有这样一个需求:

可以输出定义的画面,进行声音的分离,把声音独立输出为DAC格式可以导入到PDA中。

这个需求我是参考了当时一个电视产品的一个功能,或许有些朋友有印象,就是“打开电视听音乐”,什么意思呢,比方说你正在电视上看一个音乐剧,但是呢,你只是想听音乐,而不想看画面,有了这个功能,你就可以关闭屏幕,只听声音,说的通俗一点,就是把电视当音响用。

暂且不说这个电视的功能是否有合理性,但是至少有一点,就是这个功能是很容易操作的,只要用遥控器把电视屏幕一关就可以了。

但是如果放到电脑软件上,仅仅这个操作就是很麻烦的,首先得导入视频,然后通过软件把声音和图像分离,只导出DAC的音频文件,然后把文件再导入到PDA这些移动设备中,很麻烦的。

但是否存在这样的现实场景呢?我其实是不知道的,只是觉得这是个噱头,是个自认为有意思的特征。

这就是不合理的需求,有了不合理的需求,才会有了不合理的特征,才会做了一大堆没有现实应用价值的功能,也才会有了不被市场认可的产品。

最后看“可实现”。

什么是“可实现”呢?就是指一个需求必须适配于企业当前的资源。

清晰的,具有合理性的需求,如果实现不了,其实也就失去了现实的意义。

比方说,有这样一个需求:

无线模式的互转,可以使电脑和家电之间进行内容(音频,视频,图画)的交互。

这个需求好不好,其实挺不错的,毕竟当时电脑的屏幕尺寸还是集中在15-17寸,如果能够像投影一样把电脑上的多媒体文件传输到电视上会大大提升视听体验的。

但是,这个需求要实现的关键是“无线传输”,这在05年左右,还真的是一个技术难题。

靠什么传输?在当时的民用领域中,我能想到的就是蓝牙,但是就靠当时蓝牙2.0的版本,想都别想,即使是现在最新的5.0的版本,传输速度也就是2M,现在用蓝牙听个歌还有延迟,更别说传输动辄几百兆,上G的视频文件了。

或许公司有自己的黑科技我不知道,但现实的情况是,这个功能一直没有实现。

通过以上三个案例,我们知道了,对于实现团队来说,他们希望的是需求是什么样子的呢?

如果用一句话来概括的话,就是:拿过来就可以直接开始执行,且不会出现工作浪费的的需求

但是,现实的情况却是,我们很多产品经理提交的需求会让实现团队的伙计们动不动就把菜刀拿到桌子上,因此,我们怎么样才能提交清晰、合理、可实现的需求给伙计们,关键不在伙计们,而在于我们。

这就涉及到本文要探讨的第二个问题:面对这样的期望,我们应该做些什么。

要回答这个问题,我们首先还是得搞清楚客户遇到的问题和我们要实现的需求之间是什么关系,见下图:

基本上就是这样,但是,这也仅仅是说明了“问题”和“需求”之间一种简单的关联性,而我们也知道,在市场中,不可能存在这种简单的关系的,两者是在一个复杂的市场环境中存在的,因此,我们这张图就变成了这样,见下图:

如何来看这张图呢?

在市场中,客户的问题是客观存在的,但是想解决这些问题的不是只有你一家企业,并且每家企业对问题所形成的需求各有各的判断以及解决方案,那么,这个时候,挑战就来了,你不但要基于自己企业的情况来把问题分析好,需求想到位,还要尽可能的分析、识别、判断竞争企业他们会怎么做,这样才能形成自己的富有明显特征的解决方案出来。

这个道理很简单,涉及到的工作无非就是RPM提到的三大活动,十一个阶段,三十四项工作。

有朋友会有疑问,一个需求,至于牵扯这么多工作吗?

还真是,我来举个例子:

比方说在上一篇中,我提到了,在用户故事中,实现团队希望看到的需求描述是这样的:

作为一个【角色】,想【做什么】,从而我能够【获得什么利益】

这是我们最终交付出去的需求,但是这三个括号里的信息,和我们做的哪个工作有关系呢,我也提到了,就是问题分析矩阵,那么,这个工作是怎么表现的呢?看下图:

我们可以把问题分析矩阵中的成果信息带入到用户故事的需求呈现格式中,就是这样的:

作为一个【乘客】,想【有更多的气囊保护】,从而我能够【在汽车追尾的时候不会产生致命的损伤】

看到了吧,就是这么回事,但是正如前面提到的,要形成这个矩阵,产品经理肯定需要做相关的工作来支持,比方说市调的工作(发现市场上存在有安全担忧的消费者有多少),客户细分的工作(在对安全担忧的消费者中,对气囊数量不满的消费者是什么情况),竞品分析的工作(已经有谁开始着手解决这个问题),产品定位的工作(我们如何扬长避短的去做),产品规划的工作(我们应该在什么阶段实现什么目标)等等。

你能说这些工作不是产品经理该去做的吗,而这些工作哪个和最终交付的需求没有直接和间接的关系。

至于最终是否可以按照矩阵交付的需求设计解决方案,这就是研发团队和你共同来商定的了,我们只需要在用户故事中说明相关的背景信息和期望目标就可以了。

这样有个好处,就是可以让实现团队发挥最大限度的想象力,并基于他们擅长的工作来评估和构建有针对性的解决方案,这也从侧面再次说明了,作为产品经理,你不能也不该去干涉太多具体实现的事情,哪怕你确实懂这个。

有些朋友可能又有问题了,这么多工作做完,那得产生多少文档啊,我也知道,一说到文档,好多朋友脑袋就疼,不过没事,其实真正核心的总成性的文档就是四个:BC(商业案例);BRD(商业需求文档);MRD(市场需求文档);PRD(产品需求文档)。

不过有的观点认为MRD和PRD其实是可以合并到一起的,那么,关键的文档就是三个。

而在本系列中讲到的无论是传统的需求呈现形式,还是用户故事,或是工作故事,其实都是我们描述需求的一种表现形式而已,而这其实也给了我们一个启发,就是:

在需求的描述和交付上,我们不要只把功夫花在形式的推陈出新上,而是要把重心放在产出合格需求的工作上。

当然,随着实现团队对需求描述要求的不断提高,我们在保证相关工作到位的情况下,能够创新出一些新的表现形式也是未尝不可的。

其实,我们也应该能感觉到了,对于实现团队而言,他们越来越希望能够看到的不是冷冰冰的描述,而是带有背景表述的需求,他们也希望我们这些产品经理和他们之间的协作不再是上传下达式的机械化的执行,而是能够把自己的工作再往前移,能够积极的和客户进行接触,从而能够更加懂得客户,并更好的为客户服务。

基于这样一种趋势,实际也给产品经理提出了一个挑战,就是我们需要不断提升我们的“脑瓜子、笔杆子、嘴皮子”。

UCPM
关于 UCPM

UCPM 小编

发表回复

电子邮件地址不会被公开。 必填项已用*标注