六年技术人的转行之路

9 评论 3434 浏览 17 收藏 15 分钟

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

大家好,作者本硕均是计算机专业科班出身,毕业后一直从事软件开发工作,先后经历了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 产品工作的一些体会

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

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

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

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

 

作者:李生才;联系作者:lscncut@163.com

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

题图来自 Unsplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
2人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 题主可以留个联系方式吗 最近也在准备这方面的东西,想请教交流下

    回复
  2. 内部转的? 还是?

    回复
  3. 分析非常到位,赞

    回复
    1. 谢谢 😐

      回复
  4. 加油

    回复
    1. 谢谢你 😉

      回复
  5. 同为教育行业产品经理~~我个人感觉技术转项目经理更有前途

    回复
    1. 技术转项目经理也蛮不错的,很多大牛也是这么做的,看个人情况而定

      回复
  6. 感谢作者大大的分享,读到这篇文章的您,

    如果想具备系统产品知识技能,
    有一套体系化的个人项目作品,
    想工作和求职,都更加的顺畅!

    那体系化的学习训练就很有必要,
    点这里,先看看公开课: http://996.pm/7GVQ4

    回复