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

9 评论 6490 浏览 0 收藏 9 分钟

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

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

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

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

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

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

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

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

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

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

包括零。

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

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

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

这咱能忍?

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

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

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

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

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

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

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

怎么办?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

都是客观情况,怎么办?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#专栏作家#

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。

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

题图来自 Pexels,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 哈哈哈哈我看完文章的第一瞬间发出了和首楼一样的评价 ,很实用!受教了受教了

    回复
  2. 你他娘的真是个人才!

    回复
    1. 算盘砸头.jpg

      回复
  3. 导语里有个逗号放在了行首,强迫症来了…

    回复
    1. 谁让你说的,我也有强迫症额~

      回复
  4. 大聪明

    回复
    1. [旺财].jpg

      回复
  5. 确实是很有效的手段,受教了,也遇到过尴尬到扣脚趾的情况。。。

    回复
    1. 客气客气~

      回复