侧边栏壁纸
博主头像
M酷博主等级

祝君一帆风顺 ⛵️⛵️⛵️

  • 累计撰写 40 篇文章
  • 累计创建 36 个标签
  • 累计收到 240 条评论

目 录CONTENT

文章目录

前端工程师如何通过业务提升自我价值?

M酷
2022-01-16 / 0 评论 / 3 点赞 / 180 阅读 / 1,023 字 / 正在检测是否收录...

在一个公司中,前端工程师通常都扮演了一个非常重要的角色,他们去实现产品需求,实现各种交互效果,让需求能够最终落地。

但是很多时候,产品和后端往往对需求和业务的理解更加透彻,决定权几乎都偏向他们,而作为前端,由于并不太能够有机会理解太多的业务数据和更深层次的用户痛点,这样就导致自身发展受限,话语权不够,积极性下降。

那么前端工程师该如何通过业务来更进一步实现自己的价值呢?

在这里,我主要从以下几个点来分析一下

技术架构

  • 技术选型,预见未来,比如是否有跨端需求,提前选择跨端框架
  • 可维护性、可复用性、可测试性

降本提效

  • 目录自动生成,参考 egg.js(提效)
  • 低代码运营页面自动搭建(提效降本)
  • 快捷键工具
  • 自动化测试工具
  • 批量处理国际化(提效)
    • nodejs-translate
    • react-intl 以及 I18N-loader

业务场景

  • 大文件批量断点续传及优化
  • 微应用模板、组件库和脚手架(提交)
  • SSO 登录,CAS
  • 异步流程控制

技术驱动业务

  • 主动推进项目
    • 和后端约定接口规范
    • 推荐适合当前场景的技术
  • 提出建设性的需求
    • 样式:美观、统一
    • 性能:首屏性能
    • 交互&体验:简单高效
    • 多端兼容
  • 砍除不合理的需求
    • 实现成本,可行性分析
    • 替代方案
  • 开发周期
    • 需求优先级
    • 开发排期

无论你想做什么事情,首先都要以开放积极的心态去面对,而不是打定了一个主意后就立马埋头苦干,在做之前先倾听其他人的意见,看看是否有更好的解决思路,或者是否已经有人做过类似的事情,不要重复造轮子。

作为前端,你可以提需求,也可以砍需求,也可以在对业务足够了解的情况下挑剔后端的接口设计(当然,还是要谦虚一点),但前提是一定要有足够的底气,而实际的数据和证据可以赋予你这个底气,比如文档或者视频,领导也比较喜欢你提供有力的证据,而不单单是一张嘴。

在绝大多数公司,一般都是由 PM 来主导产品研发流程,前端毕竟是开发人员,想要在产品层面上跟产品经理 battle,无异于是业余挑战专业,既不合适也没有胜算。

但并不意味着开发就完全无法参与到业务中去了,PM 对于整个产品的宏观把控肯定比你深,但在一些细节的实现上就不一定比一线开发人员清楚了,而细节往往是从具体的需求中体现出来,不可能在一开始就完全考虑到,这也是为什么会经常有需求变更和需求答疑环节。

当需求评审的时候,PM 更多地询问你的意见,当约定接口的时候,后端更习惯你来制定接口规则,当你关心的事情越来越多范围越来越大,这个时候,你还觉得自己只是个画页面的 CV 工程师吗?

总结

  • 积极主动
  • 多思考
  • 多沟通
  • 多参与
3
广告 广告

评论区