##和UE沟通
在文库做两个项目过程中，都有被UE劈头痛批的经历，这是我在之前从未体验过的。我想了一下，出现这种沟通问题的原因在以下两个方面：
工作性质：这个要拿我之前在广研的经历来比较了，由于之前在邮箱做的是重构工作，和设计师走的很近，像是相亲相爱的一家人，从来没出现过这种问题。而现在不同了，我们FE是属于研发联盟，这意味着，做事的方式和流程都会有很大的不同。
具体一点说：做重构，我们和设计师直接沟通，（几乎）随时沟通，我们甚至可以跟设计师提出自己对某个设计的看法。而做研发，有两个重要的不同点，一是过程：开发之前，一份设计稿定稿并标注明了；开发之后上线之前，反馈UE走查确认效果；开发过程中，UE不会全程跟着你改。二是方式：UE不直接跟工程师沟通，而由PM充当中间人的角色。开发时发现缺什么图了，跟PM说，PM找UE补；交互设计有矛盾了，UE找PM确认，PM确认无误再给研发。少数情况下，页面中细小的细节，UE可以和研发直接沟通。UI规范和细节标注：首先讲UI规范，指的就是项目的设计规范：主要链接什么颜色，辅助链接什么颜色，整站字体系列，以及色彩系统，品牌色系等。其实文库有设计规范，只是我之前对这个并不知情，为了确认一个效果还跑去问UE，结果UE就嫌烦了。
其次是细节标注的缺失，比如对页面元素的间距，字号等一些细节的标注。通常我们做完页面丢给UE，UE总会觉得这里字号不对啊，那里间距不对啊！可是我明明是对着psd量的啊，你又没给标注！UE就生气了，你要标注提前说嘛，怎么做这么烂了再丢过来！所以标注这事得一开始就当规范去实行。
当然，沟通的问题，我觉得很多时候需要双方共同努力来解决的，我这里就从我的角度，反思我的过错，分析解决方案，谈谈我今后该做的事。
转变角色：上面说到了两种工作方式，且不说哪种效率更高，因为不同的部门，不同的产品是会有差异的。所以这里只提针对性的解决方案，首先是我要转变角色，适应开发流程，尽量做到，拿着明明白白的图开发，调完所有效果所有浏览器，一再确认百分百还原后，再给UE过效果。这是我之前没有做到的，拿了一份半完成状态，未接入数据的页面请UE确认，那UE哪知道是数据的问题，他一看页面跟设计出入太大，自然就不爽了。设计师产出的是一份设计稿，下一个阶段这份稿子将转变成实际的页面，我们作为工程师，认真对待每一份设计稿，既是对上游工作的尊重，也是对产品负责的表现。
建立完整的设计规范。这是针对第二点需要做的事。UI规范，为什么这个很重要呢，是因为这可以在减少不必要的沟通成本，加快研发速度。有了规范不是终点，大家都认同规范的重要性，照着规范去做才是我们要达到的目的。这里我需要检讨下。
另外就是标注好必要的细节，这是为了页面设计细节在UI规范里找不到答案的情况下，工程师也能顺利的对着设计稿写样式，省去多余的取色，量间距的环节。而且这事也需要放到流程规范里去完善，如果有详尽的标注文件，交付开发，那最后出现偏差，就有证据说明是谁的问题了。
##和QA沟通
在春苗测试的过程中，我们需要频繁的接受测试给的反馈。这次的项目我感觉总体来讲和QA同学合作比较愉快，但是也有些注意事项需要记录。
细读MRD。MRD即需求管理文档，这份文档会详细的描述产品的细节。通常来讲，对于一个前端页面，文档会对页面的不同区块分别展开描述，比如具体的交互效果描述，极端情况下（如没有数据，数据溢出）的展现。一般来说QA会根据这份文档比对各种情况的不同效果。
我在开发的过程中，犯的一个错误就是只看设计稿而没看MRD，设计稿往往只是确定页面在标准情况下的样子，而页面最终在不同用户手中会有各种不同的展现，举例来说，譬如没有登录，那么用户信息区块只显示足迹；如果没发表帖子，那么主页帖子页面也不能空空如也，如果是管理员，那么可能有额外的操作按钮。设计稿往往不能将这些情况全部考虑到，这就需要我们从MRD里找。这就避免测试阶段，QA发现各种我们没考虑到的问题。定好时间当面过bug。进入测试的环节中，QA会把bug记录到相关项目的需求平台中，比如我们使用icafe系统，这样很方便管理，修复好了的bug只要在系统中改一下状态，交给测试去回归。但是当bug增加到几十个甚至更多以后，可能就会有混乱的情况出现，这就需要定期定时间当面沟通了。
比如今天处理了10个bug，约定下午四点，大家当面过一遍。那么这一次沟通的重点是：一，核对处理的前10个bug，标注哪些是较难解决的，哪些是服务器端RD需要去修的，其余的状态改为“待测试”并由QA稍后回归；二，浏览待修复的后10个bug，哪些是无法复现的，哪些是有矛盾需要PM确认效果的，以及预估解决这些问题需要的时间。转换语言。这里指的是当QA跟你讲述，或向你询问一个问题可能的原因时，用尽量通俗的语言描述实现的环节是怎样的，最终应该是怎样的，而不该是怎样的。有的时候QA可能会武断的给一个bug的产生下结论，他看不到代码实现的复杂流程是怎样的，不知道这个bug和其他bug的相关性。当我们解释的时候，千万不能带有炫耀的想法拖长沟通的内容，简单明了为佳。
其实这一点讲的是和测试同学交流的一些技巧，我倒还是很乐意为测试同学解释问题的。记得有次QA跑来说他那边node服务挂了，我这边跑的好好的啊，查了半天代码也没问题啊。作为开发要尽责嘛，协助QA一起追查原因，最后定位到QA造数据时写的php代码的问题，导致传给node的数据格式不对了。这虽然是QA对代码的理解错误导致的，但找到原因前谁也不知道原因的，这就需要耐心沟通，乐意协助，逐步排除了。
##和PM沟通
这次我参与的项目中和PM的沟通都挺顺畅的，可能是我参与进来较晚，没有完全参加前期的需求评审的缘故。所以对于这一点我体会并没有那么深，但组内同学有经历过一些问题，并且对此开过研讨会议，所以觉得有必要把会议记录贴上来。
理想的H5&NA项目流程 ###一般项目 需求评审 测试排期 ###需求确认阶段 需求评审 走心!!! 需求反诉 多参与进去 ###设计排期阶段 FE到底算什么 承担一样的压力，为何不承担一样的权利? ###研发阶段 人总是习惯做自己最擅长的事情 视觉 提前确定需求 接口 子项目 项目负责人(接口问题, 优先确定, 需求文档, checkList) ###面对其他问题 干扰 … ###临上线阶段 deadline 问题提早暴露 上线通报和PM确定 为什么大事都是最后出 视觉走查放在最后吗? 上线前两三天完成 项目排期较长的时候要及时up代码 ###上线后 开放式提问 (不要问是非性问题，what性问题) 承揽拭回答 ###问题反馈(check)
觉得其中最有体会的是需求评审的时候需要“走心”，多参与进去，这是我一直做的不好的地方。当PM在解释需求的时候，我一言不发，就不可能真正理解需求的设计，在开发过程中就会遇到问题。只有多想，多发问，才能掌握具体的设计细节，PM也能评估出可行性。
还有就是临上线阶段，前面第一部分已经描述过，我在视觉走查阶段吃的亏。其实这个问题换个角度，放到更大的范围讨论，就是要把握deadline这个点。我们安排工作的时候，不要眼盯着deadline去做，而需要给自己定一个稍提前于deadline的时间点，这样就留下一个缓冲的时间段，便于让问题提早暴露，顺利解决而不拖延最后的上线。
上线后还有一点需要补充的是，我们要有责任意识。前端工程师不该只是把页面扔上线就觉得完成任务了，我们需要像运维工程师那样时时关注线上问题，及时处理和规避风险。这点扩展开来还有很多，就不属于和PM沟通的范畴了。目前就这么多啦。
