P7架构师——话说IT人员职业生涯规划

目标的重要性——新生活是从选定方向开始的

比塞尔,非洲撒哈拉沙漠深处一个1.5平方公里绿洲旁的一个小村庄。在很久以前,比赛尔是一个只能进、不能出的贫瘠地方。在一望无际的沙漠里,一个人如果凭着感觉往前走,他只会走出许多大小不一的圆圈,最后的足迹十有八九是一把卷尺的形状。因为人们没有认识到这一点,所以他们一直都没走出去过。后来,一位青年出现了,他发现比赛尔四处都是沙漠,一点可以参照的东西也没有,于是,他找到了北斗星,在北斗星的指引下,他成功地走出了大漠。这位青年人于是成了比赛尔的开拓者,他的铜像被竖在小城的中央。铜像的底座上刻着一行字:新生活是从选定方向开始的。

我相信几乎每个人刚投入职场的时候都是雄心万丈的,总是计划着有一天能通过自己的努力变成高富帅、迎娶白富美。但是五年、十年的职场生涯下来,当初在同一起点的人却处在不同的位置——有人依然在起点附近转悠,有的人已经在迎娶白富美的路上。为什么会出现这么大的差距呢?就如同比塞尔的村民那样,不是他们没有努力过,但是他们就是不能走出沙漠,因为方向不对,再努力也没有用。铁棒可以通过努力磨成针,而木棒再努力也只能磨成牙签。

职业生涯规划的意义

以既有的成就为基础,确立人生的方向,提供奋斗的策略。

突破生活的格线,塑造清新充实的自我。

准确评价个人特点和强项。

评估个人目标和现状的差距。

准确定位职业方向。

重新认识自身的价值并使其增值。

发现新的职业机遇,增强职业竞争力。

将个人、事业与家庭联系起来。

当年刚从学校毕业的时候,由于大学学的是工民建专业,除此之外其它方面都没有太多拿得出手的东西,尽管我立志想从事计算机相关的工作,但是从各方面分析却又不具备直接从事计算机相关工作的条件。这时候面临着两条路可走,一是通过参加培训班或者自学或者考计算机方面的研究生来学习计算机方面的知识,二是边工作边业余自学计算机相关的知识。考虑到当时的家庭条件不是很好,于是我选择了第二条路。工作带来的收入可以让我生活得到了保障,业余时间的利用可以弥补我将来期望工作岗位上的知识的不足。

因为在当年周围没有从事计算机相关工作的熟人,我就利用了招聘网站来帮我分析目标与现状的不足。尽管每家公司在招聘的时候不会说出他们给出的薪水,但是都会说出这些岗位的技能要求。通过收集多家单位的岗位技能要求,我列出常见的技能然后分析这些技能之间是否存在因果关系(比如某些技能是要求掌握了其它技能之后才能学习领悟得了的),然后依次列出学习计划以及相应的检查计划,检查计划主要是如何利用前面所学的知识技能实现一个综合的小项目,以求把所掌握的知识点融会贯通。

职业生涯阶段划分

从周围的朋友及本人的经历来看,我觉得在职业生涯的前几年可以划分为如下几个阶段:

入门阶段(<1 year):大学毕业或从其它行业转行,具备一定的理论知识,但缺乏真实环境历练,需在指导下工作。

初级阶段(1-3 year):具备较为丰富的理论知识和一定的实践,一定程度上可以独立工作,但无法独自处理复杂业务。这个阶段大约为参加工作

中级阶段(3-5 year):基本可独立应对复杂业务,通过实践总结将知识初步形成体系,但大多数情况下缺乏灵活性和前瞻性,有一定总结归纳能力,技术方面具有一定深度,通常广度不够。有一定协调管理能力和表达能力。

高级阶段(5-10 year):熟练应对负责业务,有自己的知识体系,总结归纳能力强,技术方面有一定深度和广度。具有较强的管理能力和表达能力。对业务或技术的未来走向有一定预判能力,并能带领小团队攻坚。如:分析师、架构师等。

顶级阶段(10+ year):对业务和技术都有非常深厚的掌握,面对复杂场景时能够根据自己所掌握的知识做出判断且灵活有效处理。能够管理协调较大团队,并且能够技术或者公司业务发展走势做出相应规划。如:总工、CTO、CIO等。

注:以上数据根据是的按照一般的工作强度和方式来评估的,如果工作强度极大或极小,不在此例。

BTW,讲个笑话,一个工作一年的开发人员去另一家公司面试,简历上写着有三年工作经验,面试人员通过技术问题面试也发现和三年经验的开发人员相当。于是很不解的问:“你明明只工作了一年,怎么会有三年的工作经验?”该面试人员平静地回答:“加班加来的,同时这也是我为什么要换工作的原因”。虽然上面是一个笑话,但是我想这也可以作为一个回答,经常有人问:“我转行而来、我底子薄,我怎么样才能快速适应工作需要”,答案是多利用一下业务时间学习呗。

职业规划的重要性

为什么说职业生涯规划很重要呢,因为它是一个让你明确方向及如何朝目标努力的工作。很多人在网上向我咨询的人想转行从事IT的目的主要有三个:一是听说IT行业收入很高,所以为了高收入而做IT;二是讨厌自己当前从事的工作,大家说搞IT不错,所以就想转行搞IT了;三是自己确实喜欢钻研IT技术,享受技术提高带来的成就感。前面两种人的IT职业之路可能就不会走得很远,第三种人有可能会走得远。。

现在经常有人提到“一万小时定律”,即要成为某个领域的专家,需要10000小时,按比例计算就是:如果每天工作八个小时,一周工作五天,那么成为一个领域的专家至少需要五年,这就是一万小时定律。在前面所提到的职业生涯阶段中,入门阶段和初级阶段的收入并不会很高——因为很简单,你的工作并不会给公司带来很大的利润、挑战性也不会高,如果一开始就想着高福利或者只是因为听别人说而想从事这个行业,是很难有激情坚持五年甚至更长时间的,毕竟基础知识的学习掌握过程并不是一个能带来高收入且具有高挑战性的过程。而且当你处在低级阶段的时候被分派的工作大多数是没有太多技术分量的活,即使在初期会觉得有一些新鲜感,干的时间长就会厌倦。一旦你是应付的态度而不是积极的态度去工作,你就会在这个工程中失去进一步深究的兴趣。即使是相同的事情,然不同的人去做,最终两个人的进度也会不一样,感兴趣的人会去琢磨当前这机械重复的工作是否有可以优化的地方或者可以使用小工具软件(自己写的或者别人写的)来代替自己某些环节的操作,而如果不是真正感兴趣的人就不会这么做。前者通过工作获得了经验,而后者只是混得了经历而已。

从入门到顶级是一个金字塔式结构,只有越处于顶端的人的职业道路才会越宽广,相应收入等各方面也是越好,但是大多数人并没有持续攀登这个金字塔中上部,其原因是缺乏勇气和毅力,但根因还是因为缺乏对将来有一个清晰的规划。有了规划不一定能到达目的地,只不过相当于在茫茫大海上航行时有可以指引方向的东西,如指南针。

如何制定职业规划

制定职业规划之前首先要做好自我剖析工作。比如:

个人情况方面:

拥有哪些专业知识,知识的水平?

拥有哪些技能,技能的水平?

拥有哪些兴趣,为兴趣投入的精力?

学习(工作)动机是什么,强烈程度?

学习(工作)态度怎样?

拥有怎样的沟通能力?

拥有怎样的组织能力?

个人掌握的资源方面:

本人的家庭情况?(经济状况、家人期望、家族文化等以及对本人的影响)

本人的专业情况?(在学校学的哪些学科对今后发展方向有帮助)

本人的朋友情况?(哪些朋友,甚至朋友的朋友在就业和发展上能给你的帮助)

本人的其他关系圈?(那些关系圈是否有人能给予直接或者间接的支持帮助)

目前岗位要求方面:

目标岗位要求有什么的专业知识和技能水平?

目标岗位要求我有什么样的沟通能力?

目标岗位要求我有什么样的组织能力?

目标岗位还有哪些其它要求(如英语水平、项目经历、行业背景,etc)

做好自我剖析之后,就可以指定行动计划了,在指定行动计划时可以将岗位要求方面的差距逐一进行分析:

如下图:

如何执行计划

对于计划的执行,这里借用一个别的行业术语:PDCA

1、P (plan) 计划,包括方针和目标的确定,以及活动规划的制定。

2、D (Do) 执行,根据已知的信息,设计具体的方法、方案和计划布局;再根据设计和布局,进行具体运作,实现计划中的内容。

3、C (check) 检查,总结执行计划的结果,分清哪些对了,哪些错了,明确效果,找出问题。

4、A (action)对总结检查的结果进行处理,对成功的经验加以肯定,并予以标准化;对于失败的教训也要总结,引起重视。对于没有解决的问题,应提交给下一个PDCA循环中去解决。

以上四个过程不是运行一次就结束,而是周而复始的进行,一个循环完了,解决一些问题,未解决的问题进入下一个循环,这样阶梯式上升的(是不是类似于Srum)。

总结

个人觉得个人职业生涯发展像是一个项目,一个重要不同是项目有明确的起点和结束点,而个人职业生涯没有(当然你也可以认为退休了就算到了结束点,实际上现在很多人到了退休年龄仍在公司担任要职,我就见过不少老专家仍在学习和著述)。

有过大型项目管理或参与经历的都知道,项目启动之前要进行很多准备工作,比如计划投入的资源(包括人力、资金等)、项目的风险、项目的里程碑等,一旦项目启动后,就对项目的各项指标进行监控,特别是是否能按期达成里程碑目标,如果不能就要分析是投入更多资源来保证按期实现里程碑目标还是调整里程碑目标的时间。

对于个人目标同样如此,首先要明白差距,然后制定行动计划,之后就是执行计划,在执行计划过程中再对比行动计划的节点,看是否如期完成,如果不是如期完成就要调整策略,比如投入更多时间或者将节点时间延后。总之,一定要有计划,可以有变化,变化后要及时调整计划。如果没有计划,今天学Java,明天学C++,后天学C#,这样的学习肯定不会有太大的进步。

最后一句,大多数人都有目标和计划,但是大多数人都输在执行上了。

原文地址:https://www.cnblogs.com/gongchengshidemeng/p/9306517.html

时间: 2024-10-18 12:40:59

P7架构师——话说IT人员职业生涯规划的相关文章

阿里P7架构师:通往架构师路上的经验总结

困扰架构师日常问题 架构师应不应该写代码为什么别人的系统总是那么烂成为架构师最困难的门槛是什么?如何更高效的学习?面对目前流行的技术不知如何下手?一家公司待久了,过得很安逸,但跳槽时面试碰壁?觉得现在的技术基础感觉到很扎实,但就是自己的技术提升不上?觉得自己很牛B,一般需求都能搞定,但是所学的知识点没有系统化,很难在技术领域继续突破?现在觉得自己技术还可以,但就是薪资涨不上去? 以上这几点,做为开发人员的你们,有遇到过么?有为自己想过么?有细心仔细的去解决过这些问题么?有深刻的想过么?虽然这几个

阿里P7架构师告诉你Java架构师必须知道的 6 大设计原则

在软件开发中,前人对软件系统的设计和开发总结了一些原则和模式, 不管用什么语言做开发,都将对我们系统设计和开发提供指导意义.本文主要将总结这些常见的原则,和具体阐述意义. 开发原则 面向对象的基本原则(solid)是五个,但是在经常被提到的除了这五个之外还有 迪米特法则和合成复用原则等, 所以在常见的文章中有表示写六大或七大原则的: 除此之外我还将给出一些其它相关书籍和互联网上出现的原则: S单一职责SRP Single-Responsibility Principle, 一个类,最好只做一件事

重读《从菜鸟到测试架构师》-- 开发人员也需要做测试

小艾经过了安装测试的历练,明显对软件测试又有了更深刻的了解.而在进行测试过程中,小艾遇到一个导致他手里大部分case失败的bug,而这个bug的幼稚简直令小艾忍不住想骂开发人员. 而就在小艾质疑为什么开发人员没有发现这么简单的bug的时候,小艾作为支援人员被调进了开发组协助开发工作,忙碌的开发组也立刻给小艾下达了第一份任务,完成某user story的代码开发及单元测试. 可是小艾的编码能力有限,紧赶慢赶才在限定的时间里完成了开发任务,没时间做单元测试了,只是简单测了测,就提交了代码,于是出现了

P7架构师带你构建高可用ZooKeeper集群

前言: ZooKeeper 是 Apache 的一个顶级项目,为分布式应用提供高效.高可用的分布式协调服务,提供了诸如数据发布/订阅.负载均衡.命名服务.分布式协调/通知和分布式锁等分布式基础服务.由于 ZooKeeper 便捷的使用方式.卓越的性能和良好的稳定性,被广泛地应用于诸如 Hadoop.HBase.Kafka 和 Dubbo 等大型分布式系统中. 本文的目标读者是对 ZooKeeper 有一定了解的技术人员,将从 ZooKeeper 运行模式.集群组成.容灾和水平扩容四方面逐步深入,

阿里P7架构师对Java虚拟机、类加载机制是怎么理解的?

概述 类从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期包括:加载 (Loading).验证(Verification).准备(Preparation).解析(Resolution).初始化 (Initialization).使用(Using)和卸载(Unloading)7 个阶段.其中验证.准备.解析 3 个部分统称为连接(Linking) 于初始化阶段,虚拟机规范则是严格规定了有且只有 5 种情况必须立即对类进行“初始 化”(而加载.验证.准备自然需要在此之前开始): 1)遇到

阿里P7架构师是如何解决跨域问题的!你有遇到吗?

现在越来越多的项目就算是一个管理后端也偏向于使用前后端分离的部署方式去做,为了顺应时代的潮流,一前后端分离就产生了跨域问题,所以许多同学把跨域和前后端分离项目联系在了一起,其实跨域产生的原因并不是前后端分离导致的,那我们一起来看一下,希望可以靠这一篇文章解答大家所有的跨域问题 一.跨域产生的条件 使用xmlHttpRequest,即我们通常说的ajax请求 浏览器做了这个事 访问的域名不同,即访问的html页面是a域名下的,但内部js发送的ajax请求的目标地址却是b域名 以上三个条件缺一不可,

阿里P7架构师分享:15分钟快速掌握SpringCache(使用详解)

缓存的策略有很多,在应用系统中可根据情况 选择,通常会把一些 静态数据后者变化频率不高的数据放到缓存中,如配置参数.字典表等.而有些场景可能要寻找替代方案,比如,想提升全文检索的速度,在复杂场景下建议使用搜索引擎,如Solr或 ElasticSearch. 通常在Web开发中,不同层级对应的缓存要求和缓存策略全然不同,如下图:下面了解一下缓存中的两个比较重要的基本概念: 1. 缓存命中率 即从缓存中读取数据的次数与总读取次数的比率.一般来说,命中率越高越好. 命中率 = 从缓存中读取的次数 /(

全栈软件工程师和系统架构师的异同

看完后.发现.不用怕....因为程序员不会看完.只有"架构师"才有耐心看这么长的. 一 每个好架构师都是一位出色的程序员(卓越的程序员) 架构师,听起来是如此神秘的一个称号.尤其是在开发领域刚入门不久的菜鸟级程序员眼中,架构师都是高手,都是牛人,都是如此高高在上的存在. 不过,在搞了四.五年编程之后,程序员们往往早已失去了当年对这些"高级"职位的神秘感,甚至会对自己所在项目的架构师抱怨不已,背后里称他们是一群水王.所以有江南白衣曾撰文述说:"国内的架构师到

资深架构师的经验分享——软件项目开发和决策

这篇文章是关于什么的 参与项目决策的人必须意识到他们的决定对项目的成功和成本以及时间和金钱的影响. 对于我20多年的软件开发经验和10多年的咨询工作,我作为架构师或开发人员参与了许多项目 - 其中大多数成功,有些失败,但每个项目(无论成功与否)都涉及好的和不好的决策由各种人制作. 本文的目的是通过提倡根据我的经验做出的决定以及避免错误的决策来为项目成功奠定基础. 总的来说,我拥有C ++,Java,C#和JavaScript的经验,但在过去的10年中,我一直主要致力于C#桌面应用程序.尽管如此,