前端转产品一年总结！

黑帽子唐哥

于 2024-08-05 10:38:46 发布

阅读量743

点赞数 15

文章标签：前端语言模型 pdf 人工智能 AIGC 机器人

本文链接：https://blog.csdn.net/weixin_59191169/article/details/140920739

版权

截止至本月，我从前端研发转岗为产品经理已经一年左右了，这篇文章就讲讲我这一年中的一些经验和总结。希望能为同样身为前端也有想法转产品的你提供一点帮助。

为什么转产品

工作原因

我是22年毕业的，在刚刚毕业的那段时间，我还是对前端开发很有热情的，经常把工作中的一些内容给总结成文章在掘金发布，而且开发时我会比其他人更加注重整体的代码质量和实现的完整度，毕竟也要写文章嘛，输出倒逼输入。但是随着工作年限的增加（其实也没多少），我渐渐的感觉公司的业务没有什么挑战性了，而且最开始同事们还比较注重代码质量，但随着业务越来越复杂，排期越来越紧张，代码质量慢慢的就开始妥协了。

而且有一些功能实现方式比我想象的复杂很多，但是他们依然执着的要引用一些我不认可的框架或者库，代码这件事大家应该清楚，写的爽是很重要的，如果一个项目的实现都是我不喜欢的实现方式，为了一些虚无缥缈的性能优化把代码写的很复杂。

不知道大家有没有用过 SWR 这个请求库，我曾经写过一篇文章介绍这个工具《都什么时代还在发传统请求？来看看 SWR 如何用 React Hook 实现优雅请求》，这是我很喜欢的一个请求库。它可以帮助我们在组件中获取请求数据时，不用在父组件获取后一个个通过 props 传递，而是直接在子组件中获取请求数据，并且不用重复请求。

但我有个同事认为直接使用 SWR 性能不好，因为每个组件都调用 hook 去请求，虽然 SWR key 是一样的，那肯定有个判重机制，这个判重机制对性能有影响。我当时就很无语，我说判重机制不就是用避免重复请求这件事情的嘛。更无语的是，他的解决方法时在父组件中使用 react context 创建上下文，通过 SWR 获取数据，将 SWR 中的数据传入 Context，然后在子组件中消费 Context。我当时就觉得这种写法就是恶心，脱裤子放屁行为，这么写何必用 SWR，直接用 Axios 请求后传子组件得了，为什么不直接在子组件里面调用 SWR 拿数据？

后面我与他掰扯，说我们按照 SWR 官方文档的方式来用就好了，无需多此一举，他的观点是 “SWR 又不是 React 官方的。他们的用法也不见得合适”，其他前端同事也没有很大异议，后续就是那段代码依然合并进去了，而且后续他都是这么写的。除此还有很多在 js 代码中使用单字母简写的变量，问就是跟xxx语言学的，我个人是觉得前端项目的变量名还是写全称，尽可能完整，让代码可读性更强，但我也懒得去争了，一旦大家的代码规范不同，那对我来说写代码就是很难受的一件事情了。关于这件事情我希望能在评论区看到大家的看法。

职业规划

其次是职业规划，这个倒不是说我最初就决定了想走产品这条路，而是我不太想一直走前端的路子了。我最初之所以选择前端开发的岗位，是由于我的大学专业是计算机相关，并且在我毕业前有过一段创业的经历，在那段经历中我担任的就是产品经理+前端开发的角色，因此找工作时也自然而然的投递前端相关的岗位。

但慢慢的，我在工作中感受不到前端技术很大的热情，脑袋里的灵感越来越少，工作上的代码写起来越来越乏味，而且社区里还是各种面试拷打，八股文，算法题最吃香。我是真的很讨厌八股文，我知道基础对于前端来说很重要，但还是讨厌，想到一旦要跳槽就要重拾八股文，我就觉得真的很无聊，所以我心理也埋下了要转产品的种子。

兴趣驱动

前面有讲到我在大学期间有创业过一阵子，当时我们一边做外包项目，一边做自己的一些校园产品，不论是网页还是移动端的产品，各个主流组件库都门清儿，而且也画过原型图，对一个产品从零到一的流程比较清晰，自己也对设计一个优秀的产品有执念，虽然至今还不算完成，但毕竟如果一件事情能让你有成就感，那么它就会推着你向前走。

怎么转的产品

在去年八月份，我们公司的产品要做一个大版本的迭代，很多功能都需要重新设计实现。在一个新产品诞生的初期，研发是依赖非常产品经理的产品文档，而产品经理则需要进行产品调研，概念设计等等流程才能写出一份产品方案，这就导致了产品有很大的产品方案设计的工作量，而研发只能先做一些基础框架搭建，写写技术方案，一旦这些简单工作做完就必须停下来等产品出文档，十几个研发两三天没活儿干，对于一个企业来说肯定是无法接受的。因此我们的领导就开始招聘产品经理，与此同时也在内部会议时主动问到有没有愿意尝试一下产品的工作。我本身就与公司里的产品比较熟悉，又有这么一个机会，于是我就毛遂自荐，并且当时在会上主动提出参与的也就我一个，于是就顺理成章的开始了研发向产品的转变。

遇到的问题

相信点进这篇文章的同学，有很多都是有过转岗为产品的想法的，那么我就说说从我自身出发，在从研发转为产品之后遇到了哪些问题是我没有意料到的。

专业知识

当研发时，每一次产品需求评审会上，我会去看这次新增了什么概念，思考这个需求如何实现，产品画的原型图交互流程有没有可以优化的地方，似乎自己对需求的理解能力还是很强的，也能够理解业务。

例如一个微信朋友圈的功能，产品经理提出放在发现页面，然后单击右上角加号可以选择照片发布，长按加号可以直接发布文字，那么我就会想长按这个操作是不是不够直观呢，会不会有用户很长时间了都没有发现这里是可以长按直接发布文字的？于是我就提出问题与产品探讨，长此以往，我会觉得我们的产品有时候考虑问题也不是特别全面嘛，给了我一种我上也行的错觉。

到了实际转变为产品经理后，你就会发现你要做的不只是思考朋友圈的发布是从个入口进去，而是老板给了你一个需求，是用户如何在微信中分享自己的动态。那这时候你就要想：

“我是不是加一个类似 QQ 空间的功能？这个功能就叫动态？还是空间？还是叫微博？还是叫圈子？”
“这个功能要放在我的页面还是聊天页面，还是说新增一个底部栏？”
“这个功能和微博或 QQ 空间有什么本质上的不同？”

或者评审时有同事或领导问你“为什么要叫朋友圈？我觉得叫朋友圈我完全 get 不到是什么意思？”，你应该如何应对？

我在刚刚转产品的初期几乎每次评审都是心惊胆颤，因为我很难接住同事问的问题，而且我也不是一个性格刚猛的人，可以接受讨论但不太喜欢很激烈的争论。这个问题出在两个方面：

一是刚刚转产品，我对于过往的一些概念只是了解但没有深入了解。例如领导问道：“xxx功能为什么要这么设计？”，这个功能并不是一个新功能，而是一个存在已久的功能，但是设计上有些许不合理，但是你并不清楚这个功能具体的上下文，那么人家一问，我也只能支支吾吾。这样的经历在有过几次后就会给人一种你不够专业的感觉，你连系统里的功能设计都不清楚，你还配当产品经理？

二是对自己的职责定位及权限边界还不够清晰，以上面朋友圈的例子来说，我觉得我拍板不了朋友圈具体的名称，我得去找更有经验的同事一起讨论，虽然同事会给你提供意见参考，最终的决定还是得你来做。在方案评审时，发现领导对朋友圈这个概念设计有很多疑问，例如问你：“为什么不参考竞品？”，“这个入口放在发现页也太隐蔽了吧，我作为用户完全不会点进去？”

诸如此类的问题，刚开始我是完全接不住的，总是想着领导说的也有道理，那我就按照他的想法改吧。这样一来，领导提出的意见一旦比较尖锐，你就只能顺从，说明你没有自己的想法，没有自己的主见，即使有想法也不能坚持。尤其是你还没有足够的经验，更容易被人质疑。此时如果没有一颗大心脏，没有一个非常全面的调研和思考，就容易变得很不自信，从而丧失对产品这个岗位的工作热情。

刚刚转产品的那个月我非常煎熬，每次做方案和评审前都特别紧张，有时候睡觉前都在想要是每天同事问了这个问题要怎么回答？

与研发的对接的边界

在我还是前端的时候，我单纯的认为很多边界情况就是需要前端去考虑的，例如页面的加载状态是骨架屏还是加载动画，表单字段在输入时是失焦时触发表单验证还是点击提交按钮时触发表单验证，返回上一个页面是否需要保留页面状态，文本溢出时的省略效果如何。

但当我自己转为产品后，似乎这些情况还是得我来考虑，每天需要面对各种研发提出的各种组件边界情况如何处理，很多边界情况如果你的文档中没有写，那么研发可能就不考虑了，不做任何处理，直到问题被领导或用户发现了，这时候只要你文档中没有提，那多半就要背锅了。一个你自认为通用的空数据页，你这个页面画了图，那个页面没有画空页面的图，那么研发就可以理所当然的在这个页面没有数据时啥都不展示。

这个现象主要出现在产品初期。随着产品迭代到一定程度，产品团队和研发团队通常会达成共识。此时前端的组件已经覆盖了大多数边界场景，产品团队也了解研发团队可能在哪些地方容易疏忽，因此需要特别强调这些方面。

时间分配

前面讲到研发会时不时找你对各种事情，这就导致了你平时可能很少有大段的时间专注于做一件事，每天上午研发问几个小问题，下午问几个小问题，一天就这么过去了。相比于写代码，有时思路清晰的话就可以一整天都在写，遇到问题了再停下来查一查想一想，相对来说还是会有大片的时间去做事。

对于我个人来说，有时候一个需求给到我，我可能一时半会儿没有一个好的思路，这时候你即便怎么想，怎么查都很难有突破，但有时你睡个午觉，或者放空一下，就突然有解决方向了。这导致了我做为产品经理时比较少进入心流状态，我需要思考，需要头脑风暴，但有时候想不出来也不能僵在那儿，而一件事情悬而未决又让我很难受，就容易有焦虑的情绪。

职业规划的变化

虽然很多人说技术人员越老越不吃香，产品就不一样了，可以积累经验，未来的道路也更加广阔，有机会走的更远。话虽如此，但实际上对于前端开发来说，基本上工作的两三年就基本上对整体的前端技术栈有个深入使用的经验，无非就是 React 和 Vue 以及相关的生态，，再深入点就是一些特殊协议或者可视化方面的更深入的技术，在跳槽时，只要技术栈匹配基本都可以尝试。但是产品经理的话，通常都会要求有同个赛道的经验，例如做社交产品的公司，当然希望找有社交产品经验的产品经理，而产品的赛道可就多了

前端转产品的优势

前面提了这么多研发转产品可能遇到的问题，也不能光抽巴掌不喂糖，所以下面再讲下前端转产品的优势，这些点大家可能会更有共鸣一些。

技术背景

关于这一点，有很多网上的文章唱反调说你有研发背景，肯定满脑子技术思维，做产品的时候创新能力肯定不行，你被你技术背景束缚啦。

这一点从我个人出发，我只能说产品懂技术绝对是一个优势，无论是从功能设计，到与研发沟通，天然的少了一层隔阂，尤其我们公司的产品是基础软件，用户群体本身就是相对懂技术的人。刚刚转为产品经理时，产品相关专业能力虽然不足，考虑事情不周全，但是懂技术起码给你兜了底，你不会有过于天马行空的想法，研发在你面前不能也信口开河，大致的实现成本，排期时间你能够做到心里有数。

前端思维

前端思维和技术背景还是有些不同的，前端和后端对产品的理解方向有些不同，前端偏向交互，后端更偏向业务。因此这里我将技术背景和前端思维分开讲。

不同公司使用的原型工具可能不同，我们公司是直接由产品来出高保真原型，因此我们使用的工具是 Figma，在我转岗产品一个月左右《👨‍💻 Figma 协作设计工具：前端开发者视角快速上手指南》我就写了一篇关于 Figma 的使用文章，我认为我的 Figma 上手速度是非常快的，这可能由两方面的因素。

一是我大学的时候就有自学平面设计，对于 PPT，PS 这类创意类工具的使用方式比较了解。
二就是前端思维了，因为做原型其实和用代码写页面的思路是一致的，你看到了一个页面，首先你会想这个页面会由哪些组件组成，这些组件是否已经实现过了？如果没有实现过是否可以抽离到组件库进行复用？

Figma 这个工具是我转产品后，公司才开始使用的，因此大家都不熟悉，那么交互设计的大头就落在我身上，我就拉着我们的 UI 同学一起搭建了一个组件库，这个组件库中包含了常用的所有表单组件，表格组件，还有一些页面组件，其中我根据过往的经验为组件配置了很多参数和插槽，保证插件的拓展性。

如果我没有前端相关的经验，我敢肯定从头要去了解这套组件体系，并熟练的去构建出一套兼容性好的组件库。是要花很多时间的。

后续我们还用上了 Figma 的分支管理功能，这一点和 Git 的分支管理也有些许类似，逻辑上的快速迁移学习为我上手相关工具增速了很多。

对未来的思考

虽然在当前公司已经当了一年的产品经理了，大部分的事情都可以轻松 cover，也算是处于舒适圈了，但是心里还是会焦虑，毕竟目前只是身处一个小公司，而且在产品方面的专业能力又难以评估，网上想要学习关于产品经理的相关专业知识几乎都是卖课的，而且我愈发觉得产品相关的知识不是看任何书籍或课程可以快速提升的，产品经理相关的能力以及可能碰到的问题都是要在解决实际需求的过程中去提升，而且专业的能力与产品的赛道息息相关，你在一个赛道的积累可能换个赛道就派不上用场了，因此还是得持续学习，让自己不论做什么行业都能保持竞争力。

代码的话现在偶尔写写自己感兴趣的小项目，只是没那么多了，公司内偶尔也需要我去支援研发。如果大家有有意思的小项目，小比赛欢迎拉我一起去折腾（不做外包）。