初级产品,如何避免返工带来的效率低下?

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

当产品面试官问你:你认为初级产品经理的主要工作内容是什么,你会怎么回答呢?

初级产品,如何避免返工带来的效率低下?

产品经理的工作本质上是围绕着挖掘、对接、分析以及实现需求来展开的。不同阶段的产品经理,在需求的挖掘,对接,分析,实现中的时间占比也是不一样的。 而初级阶段的产品经理,在整个工作当中,主要是接收leader下发的需求,进行产品设计,即分析,实现需求。

需求的实现,从方案设计到上线验收,中间要经历内外两道评审,即产品内审、研测外审,这两道评审,则是初级产品经理的日常战场。

评审,为什么是日常战场

我见过一些初级产品经理,辛苦设计的产品方案,在评审过程中, 被参会评审的产品告知其方案逻辑存在缺陷,质疑你的用户场景考虑不全,某个功能细节描述不清晰…评审讲到一半时就被怼的哑口无言,最终方案需要返工修补逻辑,甚至有时整个产品方案都被否认,需要重设计。

这样的评审结果,糟心不说,遇到加班改方案还伤身体,笔者便有过惨痛的教训。无论是整个方案进行重设计,还是在原方案上修补底层逻辑,方案的返工都需要我们花费额外的时间去完成,这导致我们推进需求实现的效率大大降低。

返工的低效率

说起返工,它对我们需求实现的推进影响有多大呢?

初级产品,如何避免返工带来的效率低下?

图中我们可以看出,在产品方案进入研发之前,发生返工的工作总时长,足足比不返工时高出一半,本来2天完成的工作可能变成了3天。而当需求本身较为复杂,返工工作量大,或遇到大家都比较忙,二轮内审难以组织时,我们的推进效率越发低下!

举个例子:笔者所在的公司,一轮的产品内审若不通过,无法进入研测外审,需要返工修改方案后,申请二轮产品内审,而二审组织起来,至少需要1天,甚至是几天的时间,最后改完方案并通过二轮内审,可能是3、4天后的事情了。

这样的推进效率,无疑是很低的。但问题的根源是产品方案的设计不够合理,所以避免方案的不合理设计,保障自己一次性通过评审,自然就避免了返工的发生,保证了我们的推进效率。

如何避免产品方案的设计不合理?

1. 对接需求时,明确工作目标

(1)为什么要明确工作目标

职场关注结果,无论我们的产出过程有多艰难,只要最终结果不是leader想要的,那就为自己祈祷吧。而明确工作目标,是确保自己对需求的理解、思考方向与leader在同一条线上,即我们最初就是朝着领导想要的结果在前进。

(2)具体明确哪些点

  • 需求的背景:确保自己理解为什么要做这个需求,做了要解决哪些问题;
  • 需求的范围:在这一期实现过程中,这个需求具体要做到什么程度,是完美解决所有问题,还是先解决部分核心问题;

一个需求的实现,定然是有一个时间限制的,大而全的设计方案固然能解决更多的问题,但也意味着更高的实现成本,更长的研发时间。而通常我们期望的是优先解决某些核心问题,小而轻的设计方案足以。因此确定需求在这一期的实现范围,能够避免自己在方案的设计上过于复杂,轻化自身的工作量。

(3)怎么明确目标

直截了当地问:

当我们从leader手中接过新的需求时,如果对新的需求理解不足,这时直接向leader提问,是合乎情理的,这时我们抛出自己对于需求的疑问点,不会体现自己的理解能力不足,反而认真确认需求的态度容易给leader正面的印象,当然,最重要的,是确保自身对需求的理解与leader在同一条线上;

委婉的提问:

根据自己对于需求的理解,可以用导图描述自己的大概思路,与leader进行沟通,沟通过程中观察leader反应,判断自己的思考方向是否正确,不正确则借机问领导的想法,来确保自己的设计思路与其同步;

2. 产品设计中,降低犯错成本

(1)集中确认的风险

我都不知道什么时候会犯错,何来降低犯错成本一说呢?

通常我们从需求对接,一步步走到产品内审时,产品方案才会进入到大家的视线中,如下图

初级产品,如何避免返工带来的效率低下?

这意味着,产品方案一旦前期思考不全,所有问题将集中暴露在内审会议上,评审不通过的风险大大的增加,而此时一旦确定方案需要返工,从方案的底层逻辑开始修改,整个需求文档必然是大面积的改动。这样的犯错成本,无疑是巨大的;

多阶段沟通产出信息,“预知”错误节点

集中确认的风险点在于方案的信息同步偏晚,因此,确定基本方案之后,我们都可以将产出的信息进行同步。如下图:

多阶段的沟通确认,能让我们更早的发现错误,而在错误伊始便进行修补,这样的犯错成本就小的多了。当然,工作中我们不可能频繁的与leader确认同一件事情,这样既打扰了leader的工作,也无法突显自身的能力。

因此我们可以选择在需求的基本方案确定后,或在需求的基本原型确定后,带上已有的产出,主动找leader碰一下,确保对方知晓且认可你的方案,如果基本方案或者原型不被认可,那么当场记录问题点,回去立刻做修改。

而当基本方案、或者原型在前期就经过leader的肯定后,我们即可放心的进行需求文档的编写了,这样最终诞生的产品方案,即使在内审、外审上存在一些细节上的小问题,产品方案在方向上,完整性上,肯定也是ok的,最后的结果定然就是迅速过审,需求的实现也能继续推进。

总结

保障需求的实现能够更准,更快,是初级产品经理的天职,所以:

  • 为了更准的结果,我们在对接需求时,要敢问,第一时间向leader提出自己的疑问,确保自己一开始就朝着正确的方向前进。
  • 为了更快的实现,我们在产品设计中,要敢说,多阶段主动与leader沟通产出情况,预知错误节点,保障自己始终在正确的方向上行驶。

需求实现的过程中我们难免会遇到各种各样的问题,无论如何,我们都要优先保证结果的正确性,在这个前提下提高自身的推进效率。所以,避免返工,让我们对结果负责,对效率负责,对自己负责。

 

作者:橙言。微信公众号:橙言。非资深产品经理,会一个人旅行,一个人吃火锅,一个人看电影的一个懒人。

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

题图来自Unsplash,基于CC0协议

本文被转载1次

首发媒体 人人都是产品经理 | 转发媒体

随意打赏

提交建议
微信扫一扫,分享给好友吧。