早前，平安产险科技一名外包程序员和一名外包产品经理干架的视频几乎在互联网圈都传遍了，因为产品提了一个需求：要求用户App的主题颜色能根据手机壳自动调整。
首先说这个需求对于应用开发工程师来说，确实是有点奇葩，当然并非不能实现。这块涉及图形图像处理，用机器学习和人工智能来提取图像颜色，这是基本图像识别过程，对于采集图像，可以提示对着镜子自拍一张，上传图片，通过大量的训练数据，来识别手机体颜色。当然并不能保证百分百成功，因为图像可能模糊或者，不明显等其他原因，就算不断用CNN(卷积神经网络)卷积运算。还是有可能不成功。这是对这个需求本身一些看法。下面进入今天的主题：程序员如何和产品经理优雅的干架（这里优雅的干架，主要是有效的沟通）
每次产品来提需求时，是这样的
每次产品来改需求时，是这样的
我在初出茅庐的时候，总是被产品牵着鼻子走，一个需求，接到后就做。开发过程中，发现各种坑，于是又和产品沟通，然后好不容易完成。提测后，一堆Bug，有些同时满足多种情况，本身就是定义矛盾，最后自己填坑。后来虽然涨了记性，每次和产品讨论需求时，想让对方不这么做，总是没有很好的理由说服别人。这个问题我曾不只一次向老大去请教，每次都受益匪浅。我姑且总结如下，以后干架撕逼定能派上用场：
1、弄清楚产品需求出发点是什么？
产品不会无缘无故提需求，就算是看到被的产品实现了某个功能，我们要实现。出发点是什么？如暴露会员权益，暴露广告位。给公司创更多收益。定义上是否和以前冲突，后续计划是怎样？想别人之所想，而不是你所想。你得站在产品上思考问题，不断反问，正向推演，反向推演。如果没有把握，给定一个时间调研，在此之前，不答复一定能做下这个需求。答应后，做不到，你就是背锅侠。因为很多事情我们都是没有做过的。
2、需求文档需要定义清晰
差一字差千里，尤其多Case时，流程图，产品需要画的清楚，这种情况怎么处理，那种情况怎么处理。异常时又怎样。要是不会，你教他。
你在反问对方时，对方也是在学习和成长。他就会想，这人厉害了，能想这么个场景，有些他自己都没想到。时间长了，他下次就会事先把各个场景想清楚，然后再和你讨论。这样产品的质量和健壮度也会更好。所以，不要觉得程序员不要做这些事，你这样，不光能得到别人的敬重，还能推进后续愉快的合作。帮助别人就是帮助自己，这是我最大的体会。而不是，这不关我事，我只搞我的开发就行。
3、留取证据
和你口头沟通的需求，一定要发出正式邮件或者写入需求文档更改项，不然万一他哪天忘记了，你就百口莫辩了。比如，某天产品突然找到你，说之前某个定义有点问题。能不能改成这样？虽然你很容易改，还是需要让他发出邮件，让你的领导知晓。大家都有可能犯错，很正常，犯错才会深刻成长，尤其你被别人怼你的日子，你肯定难忘，反思后，搞清原因，以后你肯定能走更长远。
4、需求背景要明确
很多产品，其实自己也不知道产品要做成什么样，大家都是互相借鉴，互相学习其他产品。这么做为了什么？不然脑袋一热，我们屁颠屁颠开发后，其实用户一点都不想用，需要看产品的重点战略方向，商业价值最大化，还是体验最优化，既要体验好，又要商业价值好，只有付费模式才是出路。当然无论是知识付费，还是其他付费，已经越来越被大家所接受。
5、对事不对人，学会甩锅，甩锅也是要证据充分。
这样体现你的专业度，沟通过后的东西，用邮件复述一遍。表示确认。最怕产品突然来一句，这个需求不是这样的，我没提过这个需求。
6、学会收敛
路还长，碰上不讲道理的产品，你问我怎么办，道理行不通，只有来拼刺刀了。不过相信经过这次之后，产品经理和程序员都会收敛些吧~