首页 > 读 文 > 如何合理解决需求变动的问题
2021
10-20

如何合理解决需求变动的问题

昨天,在微信上有个兄弟问我如何能够更好的处理需求变动的情况,我就把自己的经验大致说了一下,但是因为时间有限,我感觉没有和这个兄弟说的太清楚,因此就答应写篇文章,总结一下我在这个方面的一些个人想法,希望我的这些个人想法能够对现在处在这个困惑中的朋友有一点启发。

需求变化是个老生常谈的话题,当然,我们也知道,在产品的发展过程中,需求不变化的情况几乎是不存在的,就算是世界级的公司,这也是一种正常的情况,但是,如果需求频繁的发生变化,甚至因为需求的变化而造成产品定位的改变,这就是不正常的了。

这就像一个人总会有些脾气,偶尔发发是没问题的,但是三天两头发脾气就不得不考虑这个人是不是精神上有问题了。

因此,在本文中,我就简单说说如何合理的解决需求变动的情况,换句话说,就是我们如何把需求管理体系中可能存在的造成变动的窟窿堵住。

要解释这个问题,我们必须首先清楚,在需求管理体系中,可能会影响到需求变化的因素都有哪些,我总结了一下,大致可以包括三个方面:

1、人的因素:这里主要包括需求的控制者(通常为高层)、需求的管理和处理者(也就是产品经理),需求的执行者(也就是各个业务执行团队);

2、平台的因素:这里主要包括需求管理的体系和流程、需求管理的方法和工具、需求管理的制度和规范;

3、管控的因素:这里主要包括对人和平台进行管理和控制的机制。

这三个方面的因素是如何对需求产生作用的呢,大家看下图:

怎么来看这张图呢,因为不是本文的重点,只简单说一下,和需求相关的利益者(也就是人),在相应的平台上对需求进行操作,而所有的操作过程都要受到公司和产品级的管控机制的管理。

接下来我们还是把重点放到在这三个方面中,都会出现哪些典型的造成需求变动的因素。

1、人的因素

先来看控制者,也就是C级管理层,通常会以评审委员会的形式出现,他们会如何影响需求呢?

我们还原一个场景。

产品已经进入到技术化阶段了,这个时候,某个C级的管理者突然和你说,我刚看到一个产品,其中有个功能挺不错的,你考虑一下咱们是不是也加上。

但我们都知道,说是让你考虑,其实就是你得做的意思,这个时候,产品经理就比较为难了,加吧,还得分析一下这个需求到底是否符合自己的产品,如果符合,还得考虑要增加多少工作量,还得和研发确定可行性什么的,不加吧,面子上过不去。

我也相信,大部分的产品经理最后还是很不情愿的去做了。

实话实说,C级管理者这类和需求相关的人所造成的影响,其实最难解决,我到现在也没有一个很合理的方法来搞定这类人,在我以往的工作中,尽管也尝试了很多努力,不管是苦口婆心的交流,或是期望他们也按照管理需求来做,但是效果都很一般,因此,我也只能喊一句口号:需求面前,人人平等。

既然暂时没有合适的方法,那就先搁置起来。

再来看处理者,也就是我们这些产品经理,这个就好说,自己解决自己,也就是一枪的事。

产品经理自己通常会如何造成需求的变动呢?

还是先还原一个场景。

在PRD通过评审,并交付研发后,某天,你突然灵光一现,觉得PRD中的某个需求说明还可以再完善一下,于是就和研发说,有个需求不要按照原来的PRD去做了,我有更好的想法,于是,研发就开始骂娘了。

那么,针对这种情况,我以前是怎么做的呢,我们会给自己制定一个叫“需求变动量”的指标,什么意思呢,简单说,就是我们会记录一个需求在发展过程中,会出现多少次变动,比方说变动量上限为3次,只要不超过这个上限,就是可以接受的,但是一旦超过了,那么,我们就会暂停这个需求,分析是什么原因造成的,是因为产品经理对需求分析不到位,还是市场原始问题输入的就有问题。

这种方法对我们有什么好处呢,主要有两点:

1)强迫产品经理要对每个需求做足够到位的分析,一遍一遍的思考和权衡,甚至时不时推翻自己已有的想法,要在规定的时间内尽可能把每个都深思熟虑的需求交付给研发。

当时我们这样做的原因就是因为我们发现,人的大脑是有懒惰区的,经常会认为想的不错了,想的到位了,但,那其实只是因为大脑有些累了而释放出来的一个自我满足的信号,因此,通过一个外界的刺激(量化标准)来把这种自我满足的可能压到最低。

当然,并不是说这样就圆满了,而是我们希望把原来的60分提高到80分。

2)有利于复盘的时候发现经验教训,复盘的时候,我们会统计每个需求和整体需求的变动比如何,以及对照以往的数据,看看是增长了还是降低了,还有就是,变动的需求主要集中在哪些类别上,然后就会寻找原因,并加以进一步的完善和优化。

最后看执行者,执行者最普遍的影响因素在哪里呢?

还是还原一个场景。

需求评审会,你把所有的需求都介绍完了,问研发,这些需求明白了没有,研发说明白了,于是大家就签字,开干了。

但是会后,研发却指着PRD中的某个功能说,这个功能怎么这么设计啊,这个功能完成两天不可能,至少得三天,于是,扯皮大战就开始了。

问题出在哪里呢?

很简单,就是研发(也包括其它业务团队成员)在评审会上根本没认真、全面评估每个需求,只是参加了一个会,而不是一个有效的会,因此,会后你才发现,研发要咨询你的问题竟然还是一大堆。

我们当时是怎么解决的呢?

主要采用了三个策略:

1)在评审会之前,我们会规定提前多少天要把PRD提前发到相关利益人手里,并且规定提前看,评审会主要探讨每个需求能否解决,多少时间,谁来做,而不是去解释。

2)评审会上,我们会针对研发给出的每个答案做记录,如果大家都没有问题了,那就把进入到“数据冻结”点,言外之意,就这么定好了大,大家都不能动了啊。

3)评审会后,我们会形成会议记录,并发送到各个参会人手里,大家都留个纸面的东西,别过几天不承认自己说过的话。

这三个策略总结起来就是十二个字:提前准备;只听方案;留底存档。

整体上看,就是希望通过这些策略的使用,逼迫执行团队的成员不要把开会当成是一种负担,而是要把每一次业务会议重视起来,最终解决“会上不想,会后乱想”的情况。

2、平台的因素

We get brilliant results from average people managing brilliant systems. Our competitors get average results from brilliant people working around broken systems.

我们的非凡成果来自于普通人管理着非凡的体系。我们的竞争对手得到普通的成果是因为非凡的人周围都是支离破碎的体系。

这是丰田公司的主席张富士夫说的一句我认为对体系的作用和价值最到位的一句话。

需求管理系统作为产品管理四大体系之一,如何构建好,是个需要并值得深入研究的课题,产品管理中的需求管理系统,绝不是我们现在看到的这样,我说过了,现在大部分的产品管理中的需求管理系统其实很多都是脱胎于已有的研发管理中的需求管理体系的,两者之间有联系,但是肯定不能直接搞过来用啊,毕竟产品经理涉及到的需求分为三个层级:

商业需求;市场需求;产品需求。

我们的需求管理系统是要管理这三个层级的需求的,研发的需求更多的是项目层面的需求。

那么,平台的因素会如何造成需求的变化呢,这个从大面上说,其实很简单,没有合理的需求管理系统自然就会造成混乱,而混乱必然会出现很多影响因素,因为篇幅原因,我还是还原一个场景。

一个需求确实需要变动了,你看了看,认为变动不大,于是就通过了,然后研发就按照变动后的需求去做了,但是刚做了没多长时间,你的上级看到了,然后问你,为啥这个需求变动我不知道,谁让你通过的,记住,以后所有的需求变动都得经过我,于是,你就把挑子撂了,管他娘的呢,就按你说的来,我没事找骂这不是吃饱了撑的吗。

这其实就涉及到一个需求变更的管理,我也知道很多朋友的公司都有这个需求变更的制度,但是通常是形同虚设,按说不同级别需求的变动只要通过对应级别的人的审核就可以了,但是我就一直很奇怪,为什么就不能按照这个来呢?

我也观察了一些企业的情况,抛开人的因素,平台的因素也占了很大的比例,比方说,我们在定义需求变动级别的时候,往往都是比较粗粒度的,也就是说,在遇到具体情况的时候,往往很难直接从定义好的级别中找出标准,例如,产品经理可控制的需求变动级别,其中有一项是“不会对产品操作造成严重的影响”,这种定义就太宽泛了,啥事严重的影响,最好是定义清楚,这样才能方便操作。

当然,一开始构建这些标准的时候,谁也不能一下子想到位,想全面,但是体系和平台本来就是不断完善,不断优化的过程,丰田的TPS干了快40年了,不依然在不断改进吗!

3、管控的因素

有了合格的人,有了合理的平台,是不是就可以保证需求的管理不会出现混乱了呢,肯定不是了,再牛的人也会犯错,再好的平台也有漏洞,但是人往往是“当局者迷,旁观者清”,而平台自己又不具备自我发现问题,自我纠正的能力,因此,就需要有第三方来对人和平台进行管控。

这个机制好像我在那篇文章中提到过,一时也想不起来了,再简单说一下啊,就是在我以前的一家公司里,有一个叫“质量改进小组”的团队,这个团队干什么呢,就是每天审核整个产品小组的每项工作成果,比方说,产品经理写了一个PRD,那么,他们会去审核你写的这个PRD是否符合公司的撰写要求,其中的内容是否清晰明白,是否能够让程序员看懂,如果有问题,就会打回去让你重写。

这种机制有啥好处呢,做个类比,就有点像军队里的宪兵,警察里的督察,只要发现你有违规的行为,就会立刻进行纠正,避免出现“法恩法则”提到的情况。

尤其是对于刚刚开始构建需求管理系统,甚至产品管理体系的企业来说,这种管控机制尤其重要,因为大家都需要学习和适应新的体系,这个不断学习和训练的过程,一定是需要有第三方来管控的,学车还得有个教练了,是吧。

小知识:

法恩法则:是指每起严重的事故的背后,必然有29次轻微事故和300次未遂先兆及1000处事故隐患。

好,我就大概说这么多,看起来是在讲如何处理一个需求变动的问题,但事实上,我更想表达的是一个小小的需求背后,其实牵扯到的是一个需求管理系统的质量和操作这个系统的人的素养,因此,我个人的想法是,与其纠缠于枝枝蔓蔓,不如从根上好好思考一下如何来解决。


本文》有 0 条评论

留下一个回复