前端er的日常基本就是写代码、改bug、与产品互撕，产品吐槽这个产品做的太难用了，我的很多idea研发实现不了；研发吐槽这个原型设计的太2了，一定是拍脑门子想出来的，我们有很多种方案实现这个效果
笔者曾经也有这个想法，导致每次需求评审跟产品互怼，因为一点改动争执面红耳赤，结局输多胜少，因为产品关键时刻会发大招，“这是业务提的，就是要这么做 ”，研发的血槽直接见底，最近几年一直做B端的产品居多，产品几乎天天放大招，那该如何接住产品大招而不掉血，而且还能与产品做朋友，我也总结一些经验和大家交流，如有不妥之处，还请多多批评指正！
如何深入理解业务
前端不是一直在做需求，要学会思考需求
这是我老板经常跟我说的话，这也是前端工程师通病，觉得业务与我无关，我只负责把需求进行输入、UI设计稿结合组件库找到符合组件引入，Select选择下拉、DatePicker时间控件、Table列表等等，额外写些交互逻辑、与后端联调下接口就万事大吉，至于开发出来好不好用，交互是否有好、体验是否流畅，从不不关心，所以当我们想在公司内长久发展或者向上晋升的话，这种心态是不可能赢得领导的信赖
出现这种心态的原因
往往在需求评审中，大部分时间是后端跟产品讨论，后端更需要深入了解业务，后端的底层架构设计、数据库选型、建表等是基于业务需要设计的，而前端选择是团队主技术栈React或Vue、团队通用脚手架搭建好就开始一把梭了...，实际上我们并没有实际参与到原型评审中去，而是成为了执行者
学会分析产品原型，与产品做朋友
首先要熟悉产品需求，在需求评审前我一般会来回看2到3遍，期间要思考以下几个问题
理解产品要干什么
现有的技术能否全部覆盖到了，哪些实现不了，哪些需要调研，如果一个产品你能够从头到尾讲出来，相信对这款产品已经很熟悉了，在团队讨论一些技术实现的时候能从产品视角去分析会给你提供一个很好的思路
理解为什么要这么做
是否有更好的交互方式替代现有交互
例如下图，一个同步任务需求，产品根据用户反馈需要一个支持上传本地文件进行同步任务需求，交互非常简单，用户上传文件后，配置下需要同步到哪个表即可，产品的设计也满足用户要求
分析需求时会发现存在的问题，就是用户每次同步任务都要上传一次文件操作，如果一个文件需同步到多个表就要重复上传，小文件还好说，那么大文件就不友好了，而且上传文件有点改动就需要从新建个任务再次上传，需要用户在本地一直有备份，这是很难受的，所以在评审中给出的方案，此处不做选择文件上传，额外提供一个页面做脚本文件管理，支持版本查看、下载，用户不需要本地备份，想看上次同步任务脚本直接下载即可，同步任务界面选择文件改为从列表中选择自己维护的文件
例如下图，产品需求是根据上面几个条件动态生成Table列表,且里面的值可编辑，切换条件、维度、粒度任一条件都会从新生成列表，原来输入的值清空
这个需求实现起来非常简单，但是当我考虑用户使用行为时会发现只要触发上面条件就会重置列表数据、也就是如果已经编辑好列表内容，只要上面的规则改变就会重置，建议产品改成分步提交，做成上下步骤完成该交互，或者当前页添加一个按钮手动触发生成列表，增加二次友好提示
是否形成闭环
是否需要埋点、做数据统计、有无后台管理、统一登录、数据权限等，这个就看产品链路是否形成闭环，做人要有始有终，产品也一样，只给用户使用，哪些功能用户频繁使用或者不用，上线了多少任务，频繁调度的时间段，报表分享次数等等，需要我们做统计以便后续优化，如果后端只负责业务开发，那么是否前端用node服务来做这些数据统计，这时你会发现前端对于一个好产品是多么重要
如何推动业务增长
技术永远是为业务服务的
首先要充分理解业务，对业务增长负责，建议深入到需求中、参与到需求中，提出自己的问题，想想需求的闭环
学会以架构师思维分析需求
具备全局思维，不要老是盯着自己负责的模块，也要从整个产品视角出发，发现业务痛点并解决问题或者推动团队成员一起参与解决
关注线上质量
不能只管功能开发，一旦需求上线，立刻做甩手掌柜，这是缺乏责任意识的表现，对于上线产品我们是否有埋点做数据分析，是否有用户行为统计，或者收集到一些线上人员反馈，根据这些数据我们建议产品如何优化交互，相信产品同学也会发自内心的与你做好朋友
结束
希望大家随着年龄增长尽快找到一个适合自己发展的公司，不要频繁依靠自己的技术去跳槽，而是深耕自己所在领域内业务深度，做一个有技术、业务深度于一身的前端er，祝大家脱贫脱单不脱发！