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

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

01

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

02

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

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

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

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

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

为什么呢?

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

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

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

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

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

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

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

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

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

03

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

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

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

这里谈谈我个人的一些看fǎ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这些,都需要通盘考虑。

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

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

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

切忌囫囵tūn枣、一知半解。

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

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

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

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

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

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

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

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

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

其实不然。

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

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

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

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

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

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

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

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

6. 需qiú变更所需要的时间成本,需要与需qiú方和X说明清楚

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

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

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

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

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

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

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

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

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

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

简单说“需qiú很紧急”,是没X义的。

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

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

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

我觉得这样不对。

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

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

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

04

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

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

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

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 需求变更时,初级产品经理应该关心的是如何尽快落实 https://www.xiongfawang.com/2075.html

常见问题

相关文章

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

分享本文封面