需求移交会
一、运营
希望运营上传尺寸亮暗合适的图片，尺寸不合适，会出现图片压缩或拉长，亮暗不合适，比如图片上有文字，图片太亮的白字看不见，图片太暗，黑字看不见，请注意配图。另外，有些效果不能把图片事先规定死，要用JS做动画，再次强调图片尺寸的规范性。如果不惜用户体验，那就另当别论了。
二、设计师
1、设计稿相关
需求是否合理，设计稿是否美观，虽然我不是最终决定者，但我有权利发表我的意见。并不是运营产品设计师让怎么做，我们就怎么做？我们应该从实际出发，对最终的产品负责，而不是一味的埋头做，出了问题才改，设计师的作品并不一定是最完美的。
对设计稿的修改，我们这边要求少于3次，必须给全，如果是大改动，开发这边会发邮件出来重新评估提测时间。设计师作图时，希望多考虑极限数据，比如价格很长，标题很长，点击操作前后状态变化。
2、动画相关
动画分间歇性持续动画（一直在动）、间断性不持续动画（比如页面加载后几秒内停止，或者鼠标放上去动画出现之类）。如果一个gif能解决的问题，我是不会考虑代码写一个小动画的，从性能的角度出发。我们不会一味的用一种方法，这个需要灵活对待。并不是说这次用SVG写动画，下次还这么干。前端开发这边需要设计师提供的关于动画的东西有SVG，gif，AI，动画的具体参数（运行多少秒，比如圆半径，圆心角，变化前后的透明度，变化中的半径值），序列帧图。根据情况，可能会需要其中一个。设计师给一张图，但是我们不仅要解决兼容性（不同设备，不同浏览器），还要考虑页面性能，提高用户体验。前端不同的实现方式，兼容性，性能方面都有差异，我们根据产品需求，会折衷选取各方面不错的方式做。至于什么方式，视情况而定。制作动画的确依赖经验，但经验归经验，我们还是要有标准的，希望设计师能够给出一个demo，直接口述，我无法想象要做成什么样子，到时候测试也不好测效果。当然，如果产品经理这边可以放宽浏览器的兼容性验收，前端开发这边的自由度也会相对扩大。
zeplin让设计师提供标注图不再痛苦，但是动画方面，你们也应该考虑下方案。任乐之前提议我研究一下airbnb，据说可以把ae和代码对接起来，经过调查，我发现它并不适合前端，目前适用范围仅限于APP安卓，IOS，React Native。
三、产品经理
1、质疑
产品经理自己对需求是否足够了解，文档是否具体到每个细节？如果时间紧急，没有及时给出完美的文档，是否有抽空补齐并告知开发，还是最后不了了之？
2、需求提问
A、活动持续多久，后面大概会改动几次，做哪些地方改动？
本次项目定好的需求，如果有变动或者新加，小变动像改文本内容或者颜色，我们可以改，但是牵扯dom结构的变动及js特效或css3动画，我们拒绝修改，你们这边发邮件出来，我们下次优化。我们评估项目开发时间更专业，你们所谓的小改动有可能是个坑，存在未知的兼容性问题，性能问题等等，这些都不确定，只能具体问题具体分析。
B、页面布局
- 如果没有数据块，页面怎么显示？
- 横向菜单，点击菜单按钮和滑动页面事件同时触发，某些城市的某个数据块不存在时，怎么办？无法形成循环。
- 如果搜索为空，页面怎么显示？
- 如果没有广告，还需要间隔吗？
- 超链接是图片，标题，还是一整块？
- 文字显示是按长度计算，多则省略，css，还是字数，php，js？
- 如果按字数省略，要知道，汉字，数字，字母，同样的个数占据长度不同。
- 如果显示两行，这里比较靠谱的是按宽度控制，如果是字数，尤其是字母，可能不会占据两行。
- 描述如果小于等于5行，就具体显示文字，隐藏展开按钮。如果大于5行，仅显示5行文字和展开按钮。
- 没有户型怎么显示，没有物业类型怎么显示？你这里写的有则显示，无则隐藏有问题！你要考虑大量留白的情况，我建议这里写暂无户型，暂无类型。
- 地图悬浮效果，在页面底部，如果地图太高，房源太高，底部模块太高，三者将无法共屏，容易出现模块重叠，设计师需要注意每块的高度。
- 电话是直接调用，还是另做弹窗？安卓和iphone对电话a标签的解释有差异，安卓手机会直接进入拨打界面，iphone会先弹窗，点击系统弹窗中的呼叫，才开始拨打。
- 一期弹框高度是相同的，二期优化会因为修改不同弹框中的内容造成弹框高度不一致吗？有图案背景的弹框高度是否相同，对前端实现方式有影响。
- 东南西北地图高度是否合适？保证露出第一个楼盘。如果后期改图，前端改动比较大，要重新切图画热区。
C、注册弹窗
不同需求，我这边不会机械式复用弹窗，所以希望产品以后不要随便说复用现有的弹窗之类的话。尤其是活动，一个版面偏蓝色的风格用固有的弹窗，有些牛头不对马嘴，因此一切以最新的设计稿为准。
- 有图片验证码吗？是一开始显示，还是隐藏，中途显示？
- 如果用户输错手机号，提示出现3秒消失，还是直到用户输入正确的后才消失？
- 输入正确的手机号，图片验证码，错误的短信，点击提交，提示短信验证码错误，这时应该停止倒计时还是继续倒计时？我认为产品应该对这里做一个统一，否则不同的产品，不同的测试，让开发一会儿做成这样，一会儿做成那样，没有标准。
- 表单验证，点的太快，阻止重复提交。
- 如果输入信息错误，提示样式是怎样的？提交失败弹框，提交成功弹窗。
四、测试
1、建议测试多熟悉测试环境，PC端品牌公寓列表页在测试环境一直引用不到最新资源，查了一两个小时，没有找到原因，从st12换到st11就好了，希望有人能告诉我为什么。
2、另外，建议测试充分了解需求后，再提BUG。移动端海南活动html5页面，我这边退回了不下于5个非缺陷确认的JIRA，明明正常的功能为什么要来回改？
3、建议测试及时测页面，开发能够及时改，不要等到每次下班的时候，或者开发并行其他项目的时候，才开始提BUG。
五、认真参加评审会，给自己探坑
比如UI改版，说是只调整前端样式，但是需求有可能涉及逻辑变更。比如移动端页面去头去尾修改跳转内嵌APP项目，或许线上页面本身就有很多bug，只是测试当时没发现。比如框架迁移，如果牵扯后端变数据，格式，接口，前端要跟着变，尤其是移动端页面，测不同机型。
1、后端数据问题
2、APP兼容性问题
3、历史隐藏性bug
4、隐形需求
5、开发环境搭建耗时间
6、多个项目并行，开发分支来回切换耗时间。