今天参加了米随随的培训课程《如何和产品经理交流》，灰常实用，上午的课程下午回来就用上了。事情是这样的：

之前总觉得有些产品经理好烦人啊，根本都没想好产品是什么样的就进入到重构环节，后期要加浮出层、改按钮样式，甚至有“他们是故意刁难我们”的想法。我想，总不能他们一说哪儿要改，我就马上去改，然后给他们吧，那样他们会觉得这样做没有成本。而且手上还有别的需求，改之前的需求还要重新配环境，打开原来的文件，切换思维，甚至重新提测试单，这都是人力资源的浪费。我就干脆让他们RTX窗口亮着，一个小时后再开始做。 今天我的思维得到了一些转变，产品也是希望做出来的东西能完美，这跟我们追求代码完美是一样的。

所以接到一个让我协助修改的页面（外包制作设计稿，产品经理通过CMS上传部分图片）的时候，我马上打电话给产品经理仔细询问问题在那里（打电话是最快的定位问题的方法）。然后发现一个是开发人员输出图片分辨率不对，在FF下看着没问题，但IE6/7的渲染引擎太烂图片锯齿严重，产品碰到IE6/7问题就想到找我了。另一个问题是body背景色要改，这个我也已经写在HTML里面而不是样式表中，在邮件中也说明了让开发人员做CMS接口了。

我耐心地在群里分别说明了这两条问题的出现原因和解决办法，然后打电话给开发，告诉他希望背景颜色能做成接口以后给产品经理上传，他表示下次就做在接口里面。

然后我随意浏览了一下页面在各浏览器中的效果，发现一个png8的模板图片在外包给的设计稿上面有锯齿，是因为设计稿颜色太深的缘故。这个本来不是我的责任范围，但我想想随手就能解决了，于是把图片down下来，询问了下设计师MM的意见，加了点渐变，然后把图片传到群里，告诉产品经理我发现了一个bug，替换这个图片就可以解决了。产品经理很惊喜，因为她完全没有在群里提这个问题，还准备找外包去沟通。

这个事情给我的触动就是，产品经理对产品有深刻的热爱，她提出需求的时候我们不要只是去做，然后说好了，再修改，再说好了……接到需求和需求变更的时候，马上打电话过去聊天和询问，主要目的有两点：1.了解逻辑，让产品经理看到我们对产品的热爱。2.了解可能的变更，提出专业意见。重构工程师是最接近设计师的工程师，最接近设计师的工程师，一定要在页面实现上多想。跟产品经理的关系混好了，也能更好地贯彻我们的代码之道。另一个更直接的好处就是，产品经理知道你付出的思维上的和体力上（敲代码）的努力，建立了自己的专业度上的权威，而不只是一个切图仔，需求变更也会少一些。

从怀有抵制的心理拖延时间、消极对待到积极地参与到项目中，我觉得这个转变很让人快乐。