跟技术扯的时候当测试测出来bug或者验收时发现用户体验不佳的情况下，但技术认为设计如此的时候，那就开始扯了。产品设计原型、效果图、流程图、需求说明书等等都拿出来了，原来发现这种情况，当初设计的时候就没有考虑到。这个时候，我就把针对于这个问题的所有有可能的情况都画出来，立即展开需求变更，放入迭代开发中。不要讲究设计的详细，画个高保真的交互图出来，因为没有这个时间让你去做这个事情；最快的就是画流程图理清楚业务逻辑，把原来的效果截图出来，示意标上需修改的部分。大家都是知道做技术的都是逻辑性很高的一群人，他很快就能明白你想表达什么，并提出他的对问题自己的见解，那么这个淡就扯完了，嘿嘿。

跟其他部门扯的时候再开上线评审会议的时候，一堆人就开始总结出一大推的问题。总结出来他们说的最多的就是：“我提出来的问题你们还没有给我解决好，又或者什么什么需求你们什么时候弄好…”

被坑多几次后，我总结的教训是：在会议提纲上写明今天的会议内容是什么，而不是在快要安排上线的时候，跟我们扯这些，一句话回拒。这些问题都不是影响系统上线的问题，系统有bug或者需要优化的，已经经过跟各方面沟通，安排好时间。详细见给大家发的邮件，每个问题都有记录，后面都有反馈，那么也算是理清这些淡了，不会影响我们想要达到的目的了。

总结出有效扯淡方法跟大家共享，不要正面跟市场、技术或者其他有关系的有冲突，更不能带情绪工作。是什么问题就什么问题，寻找问题的根源，理清关系，都能找到协调解决问题的方法。不要讲究过多的形式，在做的过程中多沟通，多理解，任何问题都能迎刃而解，就能达到『草木为剑』的境界。产品迭代快，才是我们的目的。