欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  新闻

一点小启发:专治需求传递中的各种不服

程序员文章站 2022-07-05 10:43:00
有时候,产品出现问题,虽然需求本身没问题,但在需求传递过程中出现了瑕疵,一点小的瑕疵便能够牵扯出很多的问题,这就很考验产品的智慧。因此,遇到需求传递中出现的错误,该如何解决?作者分享了他的一些相关经验,一起来看下。...


一点小启发:专治需求传递中的各种不服


不得不承认,大多时候,灵活的头脑比强健的肌肉,更有用。

峡谷队友都知道,镜同学这两天工作繁重,都没时间开黑。

加之领导制定的kpi比他的腰还粗,导致团队压力巨大,天天主动加班,蹭完晚饭蹭夜宵,好几天都没有峡谷开黑了,俨然优秀新农工的楷模。

以至于连二*都疑惑了,不断地对我灵魂拷问:阿镜,你近来不对劲儿啊,工作期间怎么还干起活了?

呸,我特么哪天不划水?呸呸,我特么哪天干活了?

经过我们团队刻苦的努力,连续几天的通宵鏖战:我们特么终于被考核了。

似乎印证了一句老话:干得越多,错的越多,嗷,嗷嗷。

当时的需求是这样的:在我们应收账款融资产品的授信管理功能里面,其中,有个字段叫做“开单服务费”,是由我们自己平台收取的。

按照需求,“开单服务费”是区间比例值,区间规则为:0-10%。

包括零。

结果测试同学在执行用例测试时,漏掉了0这种情况,忘记测试0了。

而我作为产品汪,在验收测试时,也没有验收到该用例,只是验收了主流程,所以也需要附带连带责任。

说心里话,咱当时的心情和李团长差不多:老子从哪儿突围不是突围,验证主流程不就行了,能有啥影响?还要求全部验收完毕么?这不是欺负老实人么?不行,得给老子昭雪平反。

这咱能忍?

可镜同学再次被打脸(虽然我已经习惯了),事实再一次验证了墨菲定律。

昨天集团地产板块作为核心企业开始正式使用我们的金融产品,但是我们平台不能收取开单服务费。

于是运营人员设置成零时,发现竟然无法设置成功,直接报错提示。

有业务经验的同学都清楚,在真实业务遇到这种问题很棘手,搞不好就会客户流失,最要命的是,时间很紧,必须马上付款,也就是系统不能耽误一丝一毫时间。

就这么一个小错误,竟成了滑铁卢,直接导致了重大的实单运营事故。

我们似乎听到运营人员在说:测试同学拉出去祭旗,产品经理直接枪毙。

甚至看见他们在本子上画圈圈。

怎么办?

虽然需求本身没问题,但需求传递过程中出现了瑕疵,是应该挥泪斩测试,但眼下怎么办?

没有项目经理,产品经理就是第一负责人,解决问题是当务之急。

看着他们还在本子上画圈圈,急得镜同学原地转圈圈,祭旗测试事小,当下不行,他还欠我俩待测模块呢。

于是,怒从心头起,恶向胆边生,我急中生智,果然,打败魔法的还得是魔法:

咱和运营商量,还先正常按千分之二收取平台服务费,我们再出具一个减免协议,不实质收取。

这样就不至于阻断流程,当务之急是抓紧走流程。

运营同学一听靠谱,好在客户也不懂,跟客户一说减免,他们还挺高兴,似乎占了便宜。

也乐的运营同学直夸咱:你特娘的可真是个人才。

我特么亲手看到他把我的名字从小本本上划掉了。

镜同学现在发掘自己,除了吹牛皮和脸皮厚这俩优秀品质之外,讲故事有望解锁为第三技能。

我再讲一个昨天发生的真实小故事:

因为工作繁重,人手不足,新功能的界面设计图,ui同学无法面面俱到,于是提出相似界面不再出图,这其实也是敏捷流程下的常规操作

前端在开发时,发现好多列表展示时,有的是左对齐(比如,操作按钮),有的是右对齐(比如,金额类数据),还有的是居中对齐(比如,企业名称,系统编号等)。

这可难坏了前端,因为页面图不全,好多字段他就不知道怎么放,ui只是说,固定字段靠左,金额类靠右,可前端也不知道哪些是固定字段,人也怕写多了bug被考核啊。

于是,前端提出来,将页面图补全,他们对照着页面图去设计。

老实说,人家说的也没错,前端展示重点就是按照设计图去设计啊,很难发挥主观能动性的,担心发挥错了也是可以理解的。

一面是ul设计时间不足,一面是前端要求全部出图,僵持不下,各说各理。


一点小启发:专治需求传递中的各种不服


都是客观情况,怎么办?

如果反馈到双方领导,同样是各自站队自己部门,而且又伤和气,也不好。

事情的发展再一次证明了一个古老的谚语:内事不决找产品。

于是,镜同学突然就站到了前面,原来我没有动,是他们特么后退了两步。

看着这个皮球,怎么看怎么像口锅。

产品经理嘛,最关键的就是要有方案解决力,不仅要上知天文,下知地理,还要洞察人心,学会灵活应对。

有时候,最好的解决方案往往很简单,灵活变通一下就好了,但是前提是要深挖背后真正的原因。

原来是技术部考核是按bug数计算的。

所以,前端才要求设计图标准、齐全,要不然禅道的bug记录,就是他们的支出流水啊。

明白了这个道理,这就简单了:

镜同学把他们喊到会议室,告诉他们,ui设计时间比较紧,全部出图不现实,但前端的主张绝对合情合理。

这样吧,前端还先参考设计图,拿不定主意的自己先灵活处理,比如都居中处理,等到界面验收时,ui发现不合理的直接提出来,不做为bug缺陷,也不提到禅道

于是,皆大欢喜,他们只夸:还是特么产品经理鬼点子多。

事实上,需求传递过程中会遇到很多小瑕疵,好多都是小问题,但是会影响整体效能,有时候,越是小问题,越考验产品智慧。

而我们产品同学在坚持原则性的基础上,在洞察问题本质的前提下,要多一些灵活性,要考虑解决问题,并思考提高问题的解决效率。

本来嘛,对于我们产品人来说,最关键的,不就是解决问题么?

最近在研读《易经》,发现其伟大之处,恰恰就在于灵活,也正如伟人的智慧:严肃、活泼。


一点小启发:专治需求传递中的各种不服