技术人员转行「转行做什么工作比较好」

今天带来技术人员转行「转行做什么工作比较好」，关于技术人员转行「转行做什么工作比较好」很多人还不知道，现在让我们一起来看看吧！

从程序员到产品经理，本文作者收获颇多，借此文对个人经历做个总结和复盘，也希望能够给大家一点思考和启发。

大家好，作者本硕均是计算机专业科班出身，毕业后一直从事软件开发工作，先后经历了Windows开发、Android开发、JAVA接口、微服务及HTML页面相关的开发工作。

本文作为作者从事技术开发工作6年后转岗产品经理的一些经历和心路历程，记录并分享出来给需要的小伙伴参考，仅作为个人的经历总结和复盘思考，欢迎大家留言讨论，一起进步。

一、前世1.1 把不擅长的事情变成擅长也是一种能力

在很多年以前，记得刚读大一的时候，第一次上C语言实验课，一段实验代码怎么都运行不出结果来，只好求助旁边看着比较厉害的同学，同学过来看了看错误日志，经过一番分析，准确快速地解决了问题（这个场景相信开发同学在日常工作中很常见）。第一次感觉到人和人之间的差距尽然会这么大，对于自己毫无头绪的问题，别人可以这么游刃有余的解决。

佩服之余，更多的是对自身的反思。有果必有因，经过后面不断的摸索和思考，总结原因可能是没有掌握程序调试的方法技巧；英语底子薄，错误日志读不明白；自身兴趣和态度问题等。

不同原因逐个攻破，在后续的学习工作中，不仅逐步加大了自己对“写代码”“调试代码”的实践能力，还对英语进行了恶补（当时也是为了考过四六级）。

在毕业时不仅编程能力显著提升，英语水平也提高了，最终以63分的英语考研成绩考入了北京某高校读取硕士研究生。

1.2 技术工作的成就感（编写一次，到处运行，控制机器的那种快感）

第一次接触商业软件开发是在读研期间，每一个小功能的实现，每一次SVN代码的提交都会让我欣喜若狂。看着自己实现的软件功能被很多人使用，看着自己写的代码在不停地运行，不断地产生数据，内心的成就感油然而生。

自此，未来的几年都是在代码的世界里不断探索，不断去寻求突破和成就感。基于此，在毕业那年顺利进入了一家知名企业担任Android软件开发工程师，自此开始了我的职业生涯。

（工作后的我也将近胖了20斤，可能是有了收入伙食变好了，也或许是到了该发胖的年纪。）

从拿到offer工作近两年后，由于公司大量使用H5页面替代Android原生开发，Android开发任务逐步减少。公司提供了两个转岗JAVA后端开发的名额，我毅然决然地转岗的JAVA后端开发，主要是出于两个原因：第一，我认为Android开发只是一整套系统开发的冰山一角，从事后端开发可以从整个项目的角度去思考，包括整体业务考虑、数据库设计、接口设计开发以及H5页面的实现等；第二，我在读研期间前后端开发工作都有涉及过，转岗只需要很少的时间和学习成本。

事实证明，这次转岗也是非常顺利成功，使我较深入理解了企业级商业软件前后端的开发模式和工作流程，即便是现在作为产品经理，也是受益匪浅。

1.3 转岗产品经理的原因

从开始C语言的学习到逐步入门软件开发行业，然后从单纯的软件开发工作走出来，我走过了近10个年头，也正是因为这样的年龄关口使我不得不重新思考未来的职业规划。从典型的软件开发转岗到产品设计岗，可能是我一条还不错的转型方案。

如果把产品经理工作比喻成建造房子，那么程序员的工作就相当于是建造房子所必须的木工或泥工，而项目经理则相当于是包工头，在规定的时间、地点、人力物力有限的情况下，按质保量完成房屋建造任务。

产品经理重于“想”，程序员重于“做”，程序员总是在不断实现产品经理的idea。

在这个实现过程中，程序员通过选择某种或某几种技术实现产品功能，从而获得功能实现和技术提升的成就感。而产品经理的成就感则来自于一个idea从脑海到落地，从上线和用户服务中获得。

做一个能给用户带来价值或者给企业带来效率提升的产品，将会极大提升产品经理的成就感。

二、转型（开发工作积累与产品思维）2.1 技术积累

对于一个软件开发者来说，如果只是专注于产品业务和功能模块的实现，而不注意个人技术矩阵的积累，那么在未来的职业生涯发展中可能带来较大的风险。

在我刚参加工作那会，更多的就是关注产品业务，实现产品功能，对软件某些业务模块的理解程度甚至超过当时的一些产品经理。后来，我发现，一些资深工程师不仅懂基本的产品业务，更加厉害的是他们的技术矩阵和学习能力特别强，在工作的时候总是在改进方法，使用新技术，在工作之余也是不断完善自身的技术架构，掌握时下热门应用技术和框架，比如大数据相关技术、微服务系列、docker、一些前端JS框架等。

基于此，我也开始注重个人技术积累，尝试使用新学的技术，并不断自学一些新技术。这样的一个过程，使我极大丰富了自身的技术架构，从开始入门的C/C/C#语言、到中期的Java语言，Android开发、SSH架构，SSM架构到时下流行的微服务架构、Vue.js，JQuery等前端框架以及linux、数据库等知识都有涉及，这都为我后续的产品经理工作打下了良好的基础。

2.2 产品与业务

不记得曾经多少次评审过产品经理JIRA上的需求文件，也曾为了完成需求文件的提问KPI而“被迫”进行提问。绝大部分的程序员都是不太情愿逐字逐句的去看需求文件，他们会觉着产品经理需求文件太啰嗦。

但是，从产品经理的角度看，需求文件描述不到的功能点，又会被开发吐槽，这个锅注定还是要产品经理背。所以，一般靠谱点的产品经理都会在需求文件中尽可能描述全面，细节描述到位。

曾经在老东家做一个智能组卷的需求，有一个新入职不久的产品经理负责这个需求，而我则负责这个需求的具体编码实现。

在做需求评审的时候，我发现他的需求原型上画了筛选条件，按章节/知识点进行匹配组卷，但具体的匹配规则则没办法提供。由于可能不懂数据库相关知识，不了解数据模型的原因，甚至连章节、知识点、试题的对应关系都搞不明白；知识点-试题，是个多对多的关系，章节-试题也是多对多的关系。

鉴于此，最终由我来设计智能组卷匹配方案的规则，上线后很好地满足了一线学校对此功能的需求。组卷匹配方案简单来说就是个加权算法，对每个匹配出来的试题结果进行打分，按分值高低进行优先级排序。

比如，用户选择了三个知识点，则将匹配出来的试题分为以下几类：试题刚好满足知识点要求且只包含这三个知识点（优先级最高）、试题包含知识点但没有全覆盖知识点（覆盖率越高，则优先级越高）、试题超出知识点范围（超出比例越小，则优先级越高），无匹配知识点试题（优先级最低）。

作为一个软件开发者，每做一个功能、一个产品，我都会去思考这个功能、产品到底能够给用户带来什么价值，公司又是如何通过这个产品来变现的，有没有可以替代的方案，新方案是不是可以简化开发流程、节省开发工时或者能提升系统性能，甚至可以提升产品的用户价值。通过对需求文件的深入评审，产品设计得到了较好的改进。

2.3 项目管理与整体研发流程

在几年的软件开发过程中，经常负责多个需求的开发对接工作。通过对各个需求文件的工时评估及人员工作分配和管理，到最终的测试上线，让我掌握了基本项目管理能力。当然，我也自学了一些项目管理的理论知识。

同时，作为新员工导师，对新入职员工进行必要的技术及业务流程培训，使我对已有工作进行梳理和总结的同时建立了与新员工的良好友谊，这些革命的友谊也将是未来持续发展的星星之火。

此外，我也积极参与公司号召的技术、业务分享会，也曾作为技术分享主讲人做过公司内部的技术分享会。

三、今生3.1 产品经理工作内容

转岗产品经理后的工作内容，做过开发的同学相信都比较清楚了，无非就是以下这几个方面：

需求收集（来源：竞品分析、运营需求、老板需求、产品迭代改进等）；需求分析（去伪存真、优先级划分）；产品设计及内部评审（需求提出方、产品同事、分管领导等）；需求PRD文档讲解；项目管理（工作量、进度、质量、性能要求等）；产品测试与验收；产品上线和数据分析。

在我转岗产品经理近一年的时间里，上面的所有工作我都经历过，也有一些较为丰富的实践经验，也有一些产品方法论沉淀，在此先不展开说明，后续抽空再做个详细记录和总结。

3.2 产品工作中技术出身的优越性与开发人员无障碍沟通，可以准确估算项目工时及兼任项目经理岗位；在需求原型设计时，有效考虑需求技术实现性和性能问题，给开发讲解需求顺畅；较好的需求管理能力，比如需求收集、排序，需求稳定性、版本迭代设计等方面具有较好的能力；具有较好的信息收集能力（如竞品数据分析）和数据分析能力（如统计报表分析）。3.3 转行需要跨过的一些坎需要进一步加强组织、协调、沟通能力，很多问题困扰太久，要是能尽早沟通，主动沟通可能就不是个问题；需要走出产品技术实现细节，进一步拓宽知识边界，包括基本的UI、运营知识，行业知识认知等；心态的转变，程序员喜欢做确定的事情，而产品经理做的几乎都是不确定的事情，本身不确定的事情被别人撕，容易出现心理障碍，因此需要摆正心态，积极面对；需要加强产品经理的决策能力，要对需决策内容利弊足够了解，果断裁决，对结果负责。3.4 产品工作的一些体会

产品工作的成就感虽然没有程序员敲代码那么强烈，但是产品经理的成就感是更深层次的。一个好的产品设计在满足用户需求和体验的情况下，还能为开发节省大量的工时，为企业节省成本开支。

对我来说，从无到有完成一个产品的设计、开发、上线，并对用户产生价值，这种成就感才是最真实的。

产品经理的工作可以让我更加贴近生活，更多地去思考身边的人和事，而不是只是钻在代码里，两耳不闻窗外事。慢慢地，我发现自己和身边的一切都在改变，因为我们看待事物的观念变了。

关于产品经理工作相关总结，后续我将进一步梳理和记录，期待与各位一起成长。

作者：李生才；联系作者：[email protected]

本文由 @李生才 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议