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

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

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

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

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

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

呸，我特么哪天不划水？呸呸，我特么哪天干活了？

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

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

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

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

包括零。

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

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

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

这咱能忍？

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

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

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

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

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

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

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

怎么办？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

都是客观情况，怎么办？

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

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

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

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

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

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

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

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

明白了这个道理，这就简单了：

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

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

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

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

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

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

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

作者

产品大峡谷，公众号：产品大峡谷，七年B端产品经理，供应链物流与金融领域，擅长需求设计、业务指导、商业观察等。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！