从技术转产品已有一段时间了，第一个项目也正常运营了，那么跟大家分享下我这一段时间的转型之路。今年5月公司正好有个新项目启动，作为技术部的唯一女生，我顺利成章的被拉过去做需求，文档出来之后就一直在负责整个产品需求和设计上，只有经历过后，才知道『产品汪』这个称呼不是随便起的，而是有切身体会。
那么谈谈这段时间起早贪黑的到底做了一些什么工作，其实现在回想起来，最多的就是在扯皮，不是在扯皮就是在被扯皮。蓦然回首，人与人的沟通是有多么重要，产品汪的情商要求是有多高。下面就跟大家分享下扯皮的事。
跟技术扯的时候
当测试测出来bug或者验收时发现用户体验不佳的情况下，但技术认为设计如此的时候，那就开始扯了。产品设计原型、效果图、流程图、需求说明书等等都拿出来了，原来发现这种情况，当初设计的时候就没有考虑到。这个时候，我就把针对于这个问题的所有有可能的情况都画出来，立即展开需求变更，放入迭代开发中。不要讲究设计的详细，画个高保真的交互图出来，因为没有这个时间让你去做这个事情；最快的就是画流程图理清楚业务逻辑，把原来的效果截图出来，示意标上需修改的部分。大家都是知道做技术的都是逻辑性很高的一群人，他很快就能明白你想表达什么，并提出他的对问题自己的见解，那么这个淡就扯完了，嘿嘿。
跟其他部门扯的时候
再开上线评审会议的时候，一堆人就开始总结出一大推的问题。总结出来他们说的最多的就是：“我提出来的问题你们还没有给我解决好，又或者什么什么需求你们什么时候弄好…”
被坑多几次后，我总结的教训是：在会议提纲上写明今天的会议内容是什么，而不是在快要安排上线的时候，跟我们扯这些，一句话回拒。这些问题都不是影响系统上线的问题，系统有bug或者需要优化的，已经经过跟各方面沟通，安排好时间。详细见给大家发的邮件，每个问题都有记录，后面都有反馈，那么也算是理清这些淡了，不会影响我们想要达到的目的了。
总结出有效扯淡方法跟大家共享，不要正面跟市场、技术或者其他有关系的有冲突，更不能带情绪工作。是什么问题就什么问题，寻找问题的根源，理清关系，都能找到协调解决问题的方法。不要讲究过多的形式，在做的过程中多沟通，多理解，任何问题都能迎刃而解，就能达到『草木为剑』的境界。产品迭代快，才是我们的目的。
第一次写，跟大家共勉。
