365体育投注人人小站 六年技术人的转行之路

2019-12-25 11:05:55 来源: 网络

365体育投注人人小站 六年技术人的转行之路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

题图来自 unsplash,基于 cc0 协议


相关新闻