截止至本月，我从前端研发转岗为产品经理已经一年左右了。这篇文章就讲讲我这一年中的一些经验和总结，希望能为同样身为前端也有想法转产品的你提供一点帮助。
为什么转产品
工作原因
我是2022年毕业的，在刚刚毕业的那段时间，我还是对前端开发很有热情的，经常把工作中的一些内容给总结成文章发布，而且开发时我会比其他人更加注重整体的代码质量和实现的完整度，毕竟也要写文章嘛，输出倒逼输入。但是随着工作年限的增加，我渐渐的感觉公司的业务没有什么挑战性了。最开始同事们还比较注重代码质量，但随着业务越来越复杂，排期越来越紧张，代码质量慢慢的就开始妥协了。
而且有一些功能实现方式比我想象的复杂很多，但是他们依然执着的要引用一些我不认可的框架或者库。代码这件事大家应该清楚，写的爽是很重要的。如果一个项目的实现都是我不喜欢的实现方式，为了一些虚无缥缈的性能优化把代码写的很复杂，这会让开发者失去动力。
不知道大家有没有用过 SWR 这个请求库，我曾经写过一篇文章介绍这个工具，这是我很喜欢的一个请求库。它可以帮助我们在组件中获取请求数据时，不用在父组件获取后一个个通过 props 传递，而是直接在子组件中获取请求数据，并且不用重复请求。但我有个同事认为直接使用 SWR 性能不好，因为每个组件都调用 hook 去请求，虽然 SWR key 是一样的，那肯定有个判重机制，这个判重机制对性能有影响。我当时就很无语，我说判重机制不就是用来避免重复请求这件事情的嘛。更无语的是，他的解决方法是在父组件中使用 react context 创建上下文，通过 SWR 获取数据，将 SWR 中的数据传入 Context，然后在子组件中消费 Context。我当时就觉得这种写法就是脱裤子放屁行为，这么写何必用 SWR，直接用 Axios 请求后传子组件得了，为什么不直接在子组件里面调用 SWR 拿数据？
后面我与他掰扯，说我们按照 SWR 官方文档的方式来用就好了，无需多此一举，他的观点是'SWR 又不是 React 官方的，他们的用法也不见得合适'。其他前端同事也没有很大异议，后续就是那段代码依然合并进去了，而且后续他都是这么写的。除此还有很多在 js 代码中使用单字母简写的变量，问就是跟 xxx 语言学的，我个人是觉得前端项目的变量名还是写全称，尽可能完整，让代码可读性更强，但我也懒得去争了，一旦大家的代码规范不同，那对我来说写代码就是很难受的一件事情了。
职业规划
其次是职业规划，这个倒不是说我最初就决定了想走产品这条路，而是我不太想一直走前端的路子了。我最初之所以选择前端开发的岗位，是由于我的大学专业是计算机相关，并且在我毕业前有过一段创业的经历，在那段经历中我担任的就是产品经理 + 前端开发的角色，因此找工作时也自然而然的投递前端相关的岗位。
但慢慢的，我在工作中感受不到前端技术很大的热情，脑袋里的灵感越来越少，工作上的代码写起来越来越乏味，而且社区里还是各种面试拷打，八股文，算法题最吃香。我是真的很讨厌八股文，我知道基础对于前端来说很重要，但还是讨厌，想到一旦要跳槽就要重拾八股文，我就觉得真的很无聊，所以我心理也埋下了要转产品的种子。
兴趣驱动
前面有讲到我在大学期间有创业过一阵子，当时我们一边做外包项目，一边做自己的一些校园产品，不论是网页还是移动端的产品，各个主流组件库都门清儿，而且也画过原型图，对一个产品从零到一的流程比较清晰，自己也对设计一个优秀的产品有执念，虽然至今还不算完成，但毕竟如果一件事情能让你有成就感，那么它就会推着你向前走。
怎么转的产品
在去年八月份，我们公司的产品要做一个大版本的迭代，很多功能都需要重新设计实现。在一个新产品诞生的初期，研发是依赖非常产品经理的产品文档，而产品经理则需要进行产品调研，概念设计等等流程才能写出一份产品方案，这就导致了产品有很大的产品方案设计的工作量，而研发只能先做一些基础框架搭建，写写技术方案，一旦这些简单工作做完就必须停下来等产品出文档，十几个研发两三天没活儿干，对于一个企业来说肯定是无法接受的。因此我们的领导就开始招聘产品经理，与此同时也在内部会议时主动问到有没有愿意尝试一下产品的工作。我本身就与公司里的产品比较熟悉，又有这么一个机会，于是我就毛遂自荐，并且当时在会上主动提出参与的也就我一个，于是就顺理成章的开始了研发向产品的转变。
遇到的问题
相信点进这篇文章的同学，有很多都是有过转岗为产品的想法的，那么我就说说从我自身出发，在从研发转为产品之后遇到了哪些问题是我没有意料到的。
专业知识
当研发时，每一次产品需求评审会上，我会去看这次新增了什么概念，思考这个需求如何实现，产品画的原型图交互流程有没有可以优化的地方，似乎自己对需求的理解能力还是很强的，也能够理解业务。
例如一个微信朋友圈的功能，产品经理提出放在发现页面，然后单击右上角加号可以选择照片发布，长按加号可以直接发布文字，那么我就会想长按这个操作是不是不够直观呢，会不会有用户很长时间了都没有发现这里是可以长按直接发布文字的？于是我就提出问题与产品探讨，长此以往，我会觉得我们的产品有时候考虑问题也不是特别全面嘛，给了我一种我上也行的错觉。
到了实际转变为产品经理后，你就会发现你要做的不只是思考朋友圈的发布是从个入口进去，而是老板给了你一个需求，是用户如何在微信中分享自己的动态。那这时候你就要想：
- '我是不是加一个类似 QQ 空间的功能？这个功能就叫动态？还是空间？还是叫微博？还是叫圈子？'
- '这个功能要放在我的页面还是聊天页面，还是说新增一个底部栏？'
- '这个功能和微博或 QQ 空间有什么本质上的不同？'
或者评审时有同事或领导问你'为什么要叫朋友圈？我觉得叫朋友圈我完全 get 不到是什么意思？'，你应该如何应对？