编辑导语：有时候，产品出现问题，虽然需求本身没问题，但在需求传递过程中出现了瑕疵，一点小的瑕疵便能够牵扯出很多的问题，这就很考验产品的智慧。因此，遇到需求传递中出现的错误，该如何解决？作者分享了他的一些相关经验，一起来看下。
不得不承认，大多时候，灵活的头脑比强健的肌肉，更有用。
峡谷队友都知道，镜同学这两天工作繁重，都没时间开黑。
加之领导制定的KPI比他的腰还粗，导致团队压力巨大，天天主动加班，蹭完晚饭蹭夜宵，好几天都没有峡谷开黑了，俨然优秀新农工的楷模。
以至于连二傻子都疑惑了，不断地对我灵魂拷问：阿镜，你近来不对劲儿啊，工作期间怎么还干起活了？
呸，我特么哪天不划水？呸呸，我特么哪天干活了？
经过我们团队刻苦的努力，连续几天的通宵鏖战：我们特么终于被考核了。
似乎印证了一句老话：干得越多，错的越多，嗷，嗷嗷。
当时的需求是这样的：在我们应收账款融资产品的授信管理功能里面，其中，有个字段叫做“开单服务费”，是由我们自己平台收取的。
按照需求，“开单服务费”是区间比例值，区间规则为：0-10%。
包括零。
结果测试同学在执行用例测试时，漏掉了0这种情况，忘记测试0了。
而我作为产品汪，在验收测试时，也没有验收到该用例，只是验收了主流程，所以也需要附带连带责任。
说心里话，咱当时的心情和李团长差不多：老子从哪儿突围不是突围，验证主流程不就行了，能有啥影响？还要求全部验收完毕么？这不是欺负老实人么？不行，得给老子昭雪平反。
这咱能忍？
可镜同学再次被打脸（虽然我已经习惯了），事实再一次验证了墨菲定律。
昨天集团地产板块作为核心企业开始正式使用我们的金融产品，但是我们平台不能收取开单服务费。
于是运营人员设置成零时，发现竟然无法设置成功，直接报错提示。
有业务经验的同学都清楚，在真实业务遇到这种问题很棘手，搞不好就会客户流失，最要命的是，时间很紧，必须马上付款，也就是系统不能耽误一丝一毫时间。
就这么一个小错误，竟成了滑铁卢，直接导致了重大的实单运营事故。
我们似乎听到运营人员在说：测试同学拉出去祭旗，产品经理直接枪毙。
甚至看见他们在本子上画圈圈。
怎么办？
虽然需求本身没问题，但需求传递过程中出现了瑕疵，是应该挥泪斩测试，但眼下怎么办？
没有项目经理，产品经理就是第一负责人，解决问题是当务之急。
看着他们还在本子上画圈圈，急得镜同学原地转圈圈，祭旗测试事小，当下不行，他还欠我俩待测模块呢。
于是，怒从心头起，恶向胆边生，我急中生智，果然，打败魔法的还得是魔法：
咱和运营商量，还先正常按千分之二收取平台服务费，我们再出具一个减免协议，不实质收取。
这样就不至于阻断流程，当务之急是抓紧走流程。
运营同学一听靠谱，好在客户也不懂，跟客户一说减免，他们还挺高兴，似乎占了便宜。
也乐的运营同学直夸咱：你特娘的可真是个人才。
我特么亲手看到他把我的名字从小本本上划掉了。
镜同学现在发掘自己，除了吹牛皮和脸皮厚这俩优秀品质之外，讲故事有望解锁为第三技能。
我再讲一个昨天发生的真实小故事：
因为工作繁重，人手不足，新功能的界面设计图，UI同学无法面面俱到，于是提出相似界面不再出图，这其实也是敏捷流程下的常规操作。
前端在开发时，发现好多列表展示时，有的是左对齐（比如，操作按钮），有的是右对齐（比如，金额类数据），还有的是居中对齐（比如，企业名称，系统编号等）。
这可难坏了前端，因为页面图不全，好多字段他就不知道怎么放，UI只是说，固定字段靠左，金额类靠右，可前端也不知道哪些是固定字段，人也怕写多了bug被考核啊。
于是，前端提出来，将页面图补全，他们对照着页面图去设计。
老实说，人家说的也没错，前端展示重点就是按照设计图去设计啊，很难发挥主观能动性的，担心发挥错了也是可以理解的。
一面是Ul设计时间不足，一面是前端要求全部出图，僵持不下，各说各理。
都是客观情况，怎么办？
如果反馈到双方领导，同样是各自站队自己部门，而且又伤和气，也不好。
事情的发展再一次证明了一个古老的谚语：内事不决找产品。
于是，镜同学突然就站到了前面，原来我没有动，是他们特么后退了两步。
看着这个皮球，怎么看怎么像口锅。
产品经理嘛，最关键的就是要有方案解决力，不仅要上知天文，下知地理，还要洞察人心，学会灵活应对。
有时候，最好的解决方案往往很简单，灵活变通一下就好了，但是前提是要深挖背后真正的原因。
原来是技术部考核是按bug数计算的。
所以，前端才要求设计图标准、齐全，要不然禅道的bug记录，就是他们的支出流水啊。
明白了这个道理，这就简单了：
镜同学把他们喊到会议室，告诉他们，UI设计时间比较紧，全部出图不现实，但前端的主张绝对合情合理。
这样吧，前端还先参考设计图，拿不定主意的自己先灵活处理，比如都居中处理，等到界面验收时，UI发现不合理的直接提出来，不做为bug缺陷，也不提到禅道。
于是，皆大欢喜，他们只夸：还是特么产品经理鬼点子多。
事实上，需求传递过程中会遇到很多小瑕疵，好多都是小问题，但是会影响整体效能，有时候，越是小问题，越考验产品智慧。
而我们产品同学在坚持原则性的基础上，在洞察问题本质的前提下，要多一些灵活性，要考虑解决问题，并思考提高问题的解决效率。
本来嘛，对于我们产品人来说，最关键的，不就是解决问题么？
最近在研读《易经》，发现其伟大之处，恰恰就在于灵活，也正如伟人的智慧：严肃、活泼。
#专栏作家#
产品大峡谷，公众号：产品大峡谷，人人都是产品经理专栏作家。七年B端产品经理，供应链物流与金融领域，擅长需求设计、业务指导、商业观察等。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Pexels，基于CC0协议。