需求变更时,初级产品经理应该关心的是如何尽快落实

5 评论 4260 浏览 22 收藏 12 分钟

作为一个初级产品经理,经常会遇到需求变更的情况,新手这个时候往往就会很崩溃。本文作者基于自己的工作经验,提出了一点思考,希望对你有帮助。

01

项目开发,简单来说,包含3个步骤:设计、执行、验收。

围绕这3个步骤,我们一般会有2个朴素的愿望:

设计时,要考虑周全,安排妥帖。执行时,要按照要求开发,按时按质按量落实。验收时,要遍历用例,把好关。

设计完成了,需求确认无误了,不会再改了,再提交执行。执行完成了,按照要求全部落实了,自测没有问题了,再提交验收。

但是,愿望仅仅只是愿望,现实往往是另外一回事。

比如说,“敏捷开发”,大家说得很多了。它的思想,大家也都基本认同。

但是,现实中,能真正按照“敏捷开发”的要求去实施的团队,却非常少见。

不同的项目开发理论,虽然内容大不相同,但都包含了一种“分割”的思想。

“设计”确认无误了,再执行。开始“执行”了,就不能再随意修改设计了。

然而,在小厂的实践中,情况往往不是这样。

比较常见的情况是,“设计”环节不受限制地往后延伸。

“执行”时,还在完善“设计”。甚至“验收”时,都还在修改“设计”。

在需求还是暧昧不清的时候,产品经理可能就需要设计方案,然后不得不着急着开始执行。

在执行过程中,需求的内容可能才开始明朗。

甚至要到项目上线时,需求才算是“暂时”明确了。

这就导致,一个项目,在开发过程中,产品经理可能需要再补3、4个需求单,再发5、6个工作邮件,频繁地进行方案调整。

02

有时候,技术同事会非常崩溃地对我说:“你们这次可得确定好啊!这次改完,咱们能不能别再改了?”

对此,我也只能表示无能为力。因为这不是产品经理所能控制的。

为什么我们不能将“设计”和“执行”进行分割,合理地安排项目开发?

相关的分析和吐槽,已经很多了,我就不再赘述。

这里我想强调的是,某种意义上讲,这和初级产品经理没有什么关系。

为什么呢?

能够合理安排项目开发节奏的,只有少数有实力的大厂。大部分公司,或多或少都有些混乱。

如果公司想要改善这种情况,肯定需要领导来统筹。初级产品经理没有能力,也没有权力,去处理这样的问题。

哪怕之后情况会逐步改善,也不可能说,我们先停下来,等情况变好了再开始推进项目。

如果有得选,那肯定是优先选择那些协作机制更合理的公司,没必要给自己添堵。

但是,如果没得选,那我建议,还是尽快“接受现实”为好。

我们当下,就是需要在这么一种混乱、不合理的机制下,开展我们的工作。

这是一个客观存在的现实。

网上有很多相关的讨论。比如说,国外先进的开发理念是怎样的,如何重新打造公司的协作机制,要怎么进行组织变革,等等。

我觉得,至少对于初级产品经理来说,这些都是空谈,没有多少价值。

03

作为一名初级产品经理,我们可能会经常碰到需求变更的情况。

我认为,不管变更的原因是什么,作为一线的“执行者”,初级产品经理在接到变更需求时,首先要关心的是“如何将之尽快落实”。

那么,面对需求变更,初级产品经理应该如何处理呢?

这里谈谈我个人的一些看法。

1. 过去的事情就让它过去,不要扯皮,不要推诿

需求要变更,某种程度上讲,意味着之前的做法存在“错误”。

出于自卫心理,我们本能地会想要把锅推出去:“之前是谁谁谁这么说的,怎么又要改了?”

我认为,这是没有意义的,而且会显得自己很没有担当。

当前最重要的是,明确需求是否确定要改,以及具体要怎么改。

任何一句推诿,都是在浪费时间。

哪怕之后有人需要为错误负责,哪怕那个人就是我自己,那也是之后的事情。

2. 快速回忆起,原来这么设计,是基于什么样的场景、出于什么样的原因

我们策划时,虽不敢说“算无遗策”,但大部分的情况,都还是有考虑到的。

备选项被舍弃,是出于什么原因?

采用这个设计,是基于什么考虑?

这些,我们需要快速回忆起来。

一方面,如果领导问到了,我们能有个交代。

“我之前这样设计,是有一定考量的,不是乱搞的。”

不该背的锅,我们不要随便乱背。

另一方面,这也有利于我们重新对需求进行评估。

原来是基于这样的考虑做出的设计,现在要进行变更。

那么,是原来的逻辑有问题?还是现在的情况变了?

这些,都需要通盘考虑。

3. 确保自己理解新的需求内容,最好再三确认

需求方在说明新的需求内容时,要确保自己确实理解了对方的意思。

如果没听明白,直接表示不明白,让对方复述一遍。

切忌囫囵吞枣、一知半解。

同时,要结合原先的需求设计,以及当前的开发情况,对有问题的地方一一确认。

最后,自己把需求复述一遍,确保没有理解错误。

如果有需要另外确认的事项,一一列举出来,标出相应的负责人,要落实到具体的个人。

需求变更,是一个很容易造成混乱的事情。我们要非常谨慎,不能慌乱。

4. 做好需求管理,安排好开发节奏

需求变更,有时候可能同时会有好几个变更点。

这时候,需要产品经理结合需求的优先级,以及当前的开发情况,合理安排。

比如说,需求方希望替换支付方式。而当前的情况是,正在使用的这个支付方式存在一点问题,正在处理。

表面上看,正好!原来的支付方式都不用改了,直接上新支付方式就行了。

其实不然。

如果直接上新支付方式,那就得等新的支付方式完全弄好了,才能重新上线。等待的时间比较长。

如果我们先把原来的支付方式快速改好,恢复上线。那么在开发新支付方式的时候,就能暂时先用着原来的支付,不至于长时间下架。

需要注意的是,改完一个需求点,要改下一个需求点时,最好重新与需求方确认。

因为很有可能,这个时候,情况又有了新变化。

5. 制定解决方案时,需要与技术团队共同协商

因为项目已经开发了一半,有些东西可能已经做了,不好改了。

这个时候,要满足新需求,哪些方案能做,哪些方案调整起来成本低一些,只有负责的程序员才清楚。

所以,需求变更的时候,产品经理尤其需要听取技术团队的声音。制定解决方案时,需要与技术团队共同协商。

6. 需求变更所需要的时间成本,需要与需求方和领导说明清楚

改需求,其实没什么,毕竟大家就是来上班干活的嘛。

怕的是,既要改需求,又不能多给点时间,这就有些强人所难了。

产品经理向需求方和领导说明解决方案时,需要清楚说明该方案所需要的时间成本。

让领导知悉,可能需要花费比预想中更多的时间,或者可能会占用其他项目的开发资源。

至于领导能不能多给点时间,那就是领导的事情了。

7. 每个需求点的紧急程度,需要清楚告知给团队各成员

产品经理需要清楚告知团队各成员,需求方和领导的意思是如何。

这个项目里面,哪些需求点是必须在某个时间节点内完成的,哪些可以适当延后。

如果某处碰到困难,无法解决,要及时切换到Plan B。

当前有几个项目,如果撞在一起,先做哪个,后做哪个。

简单说“需求很紧急”,是没有意义的。

因为每个项目都是紧急的。

8. 后续的全部沟通,尽量在大群里面进行

有些人喜欢建小群,有问题在小群里面私下沟通解决。

我觉得这样不对。

我觉得,建群,就要建大群,把相关领导都拉进来的那种。当然,涉及的所有人员,都要在里面。

所有沟通,都在大群里面进行。

这样才能确保,所有人都能知悉当前的所有情况,降低沟通成本,避免遗漏。

04

我觉得,某种意义上讲,“需求变更”,尤其是“紧急的需求变更”,是对初级产品经理的一次突击考试。

因为它需要初级产品经理,在非常短的时候内,在非常混乱的情况下,快速把握现状,迅速制定方案,并马上落实推进。

它是一场综合性的考试,需要严肃对待。

 

作者:简明产品论,个人公众号:简明产品论(ID:JianMingPM)

本文由 @简明产品论 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 变更应该还好. 和相应的开发人员讨论一下就有技术路线了. 后面就是评估成本和反馈了.

    回复
  2. 很不错,去年6月转行做产品,12月份自己负责一个新的项目,到现在7个月的时间项目落地,所有情况都遇到过,正在写项目复盘,正好借鉴,感谢作者。

    回复
  3. 建大群很真实!

    回复
  4. 正遇到这样的问题

    回复
  5. 替初级产品发声!!
    感觉作者非常务实,特别适合在一线打仗的那种

    回复