关于职业生涯调整的一些思考

说起来惭愧,走了快二十年的职业道路,除了几个值得回忆,给自己带来成长的项目之外,并无任何出彩之处。同时我也目睹很多朋友起起伏伏的职场故事,加上我自己的惨痛经历,所以我也会常常反思是否需要主动做调整这件事。虽然一直以来,都在做技术工作,偶尔在项目中会承担一部分项目管理工作,但往往没有正式的职位,所以只能谈谈主动调整和被动调整这档子事。

我把跳槽、主动调整自己的工作内容,比如内部换组,这一类的称为主动调整;而我经历更多的则是被动调整,业内常见的被动调整包括:公司倒闭,部门倒闭,公司裁员,公司因为业务需要进行业务重组(re-org)导致的内部调整等等。我自己经历过一次裸辞跳槽(那时正是我高产的黄金岁月),一次因为个人生活需要主动要求调整部门,多次因为业务重组而导致的被动调整。总的来说,可以看出我是个极其不愿意瞎折腾的人,当然这很大程度和个人性格以及机遇有很大关系。

从目前我自己的经验来看,主动调整大概率会对个人职业生涯成正向作用,而被动调整则常常给个人带来负面影响较多。原因在于,主动的调整通常目的性较强,符合个人意愿,从工作方式和主动性上都更契合。而被动的调整,则往往是临时搭台唱戏,如果个人不是很强势的话,是很难获得唱主角的机会,多数时间都是在戏台子上唱配角,跑龙套,有时真的只是浪费时间混口饭吃。

因此做人还是应当主动调整自己,如果没有好的机会发挥自己的个人专长,就应该作出调整,正所谓人挪活,树挪死。我自己也是有几点体会,一定想清楚自己要什么,否则不要乱动,要综合考虑自己当前的阶段最需要的是什么,带着目的进行调整,如果想不清楚,还不如不要动。例如,是单纯希望加薪解决当前下买房的需求,还是希望有个氛围良好的工作环境,抑或是想多学点东西等等;二是看看是否当前的工作是一定没有机会了吗,你对目前的工作掌握了吗,是否有所心得?是否真的自己无法在当前的组织里创造价值了吗?有时候虽然在当下碰到了困难,但是不妨坚持一下,也许还可以海阔天空;三是,新的机会会给自己带来什么,能否带来提升?如果只是出卖青春的 996 重复劳动,多赚点钱还是算了吧;再说说成本中心和利润中心的问题,如果所在的部门是成本中心,那么人力成了公司的成本,而成本中心往往不直接创造利润,那么情况通常是,干得再苦再累也很难在薪酬等方面的目标获得很好的提升,因为在这个方向上,个人目标和公司始很难做到双赢,晋升会相对慢很多(很不幸我现在正处于这样的状态,所以是肺腑之言)。如果真想多赚点钱,还是尽量去能够帮公司直接赚钱的部门,直接服务企业客户创造价值,相比获得提升的机会会更多。

最后,即使有好的机会,也不要轻易变换行业。虽然做程序员虽然都是做技术工作,但是程序员实际上是在各种细分行业里的,例如:金融IT、互联网(可以分的更细:视频、零售、新闻……)、大数据、AI 等等。频繁变换行业实际上没有任何好处,因为业务知识经验价值无法最大化。换句话说就是以前的业务经验在新的行业里没有用了,再加上纯技术领域各种前后端技术的快速变换,作为技术人频繁换行业的结局就是被快速淘汰。

所以,总结起来就是:不忘初心,认清现实;积极主动,坚持一会;端正心态,选好行业;目标明确,再做调整。

139 次阅读

回归

2019可谓是风云变幻的一年,贸易战打得如火如荼,股市像过山车一样,金融市场暴雷不断,科技巨头不断收缩,房价高企,忽然之间仿佛连苹果都吃不起了,相信所有的人或多或少都能感觉到无形的压力。印证了个人命运和国家命运是紧密相连的。

本来我在公司的“新项目”进展还算不错,和几个合作很好的同事将一艘满是漏洞的船修缮的相对完整,在 Kubernetes 世界里几乎可以自由航行,最近很长一段时间,我都在给内部用户做演示宣讲,渐渐我们也积累了不少用户。就在项目干得如火如荼之际,一场裁员却来的很突然,这次裁员和绩效无关,同一个部门的三位其他同事必须有一位必须离开,两位需要转组,被裁的同事可以拿到补偿。我这位被裁的同事是成都人,海归90后,因为反正在北京也买不起房,平时也很洒脱,不多的工资和假期干脆都拿来周游世界,增长见识。毕业一两年却已去了好几个国家。他恰好正准备过段时间辞职,这也算是种幸运。我问他后面有什么打算,他说已经和妻子决定离开打拼了两年都北京,返回成都创业。在为他们几个办的散伙饭上,我倒是为他感到坦然和释放。有时放弃了才能得到,回归到家乡,换个环境重新开始新的生活,新的起点,所以年轻真好,就在于拿起放下的成本很小,未来总有无限的可能性和广阔性。而我们这些老油条,还得在这里日复一日的重复朝九晚六(晚上还得开会)的非健康生活。

这场裁员对我的项目也是冲击不小,由于人手少了,管理层决定把这个项目停了,项目成员也都被分散到其他更紧急的项目组里。包括我自己,本来计划调整自己的职业生涯往管理方向走一走,现在短期内已不可能,几乎调整好的姿态现在又必须完整地调整回来,回归纯技术。好在我对纯技术还是有热情的,而在大公司做管理就面临大量的会议和办公室政治,做技术就显得存粹多了。所以,我对这样的“回归”,倒也很坦然,我也正需要一点时间来继续调整自己。至于我的 “新项目”,积累了不少用户,项目组成员依然热情高涨,所以我们自然也不会就此放弃,我们会利用自己的时间来做一些事情,包括支持内部客户,等到过一段时间公司的人手又富裕了,我们就又可以“东山再起”了。

所以人的命运常常是和时代关联在一起的,国际政治的“蝴蝶效应”会形成无形的飓风,将我们每个人都裹挟在一起。在无力抗争时,大概能做的,也只有坦然的“回归”了。

99 次阅读

银行网点转型

招行的银行卡到期换卡,最近忙到没有时间,新卡片制好了收到短信通知后,都拖了将近一个月没去取。感谢支付宝和微信,现在真的是不需要现金了。于是周末专门花了半天时间去了北三环的招行换卡,首先是坐地铁,然后再换共享单车骑行一会儿。我本以为银行人不多,只是取一张卡而已,可以很快办完,谁知竟然花了40多分钟。

首先,现在这家招行的网点居然没有取号机了,而是要求我用招行网银App扫一个二维码取号。我在想这分明是为了推广网银App,要是我没用智能手机怎么办?要是我没有安装网银,还得当场下一个不成?取了一个B开头的号之后就开始等了。银行里人的确不多,一个诺大的网点其实只有三、四个客户,开了两个普通高柜窗口,两个普通理财窗口,还有金葵花理财也在开门营业,外加大堂经理一人,迎宾员一人。

一开始前面有两个客户C开头的号,办完了又直接叫了一个C起始的号码,然后很我就等了将近半个小时,最后我实在有点不耐烦了,于是去问了大堂经理为什么不叫 B 开头的号。大堂经理感觉对客户还是比较尊重的,立马就进去协调一下,过了一会儿就来了一个柜员开了个新的窗口叫了B号。我顺便问了问,C开头的号是什么意思,柜员告诉我C开头是普通卡,B开头的是金卡。所以这还真符合我之前来招行网点的印象,好像现在金卡客户好像多于普通卡客户,每次办理业务都需要排队。就这样,我的业务大概4分钟不到就办完了,我却等了将近40分钟。

2012年我就曾经做过银行网点转型的解决方案和项目,例如大堂经理在客户进入网点之后(至少是排队之后),就能够获取到客户的等级级别,从而提供相应等级的服务。特别在人工智能兴起,支付宝的扫脸支付都已经成熟应用的今天,识别到客户并不是有很大的难度,银行网点是应该能够通过技术手段提供更好的服务。当然,从银行角度,是否真的愿意花心思服务好中低端客户,就是另外一回事了。而能否维护好存量客户,并且从存量客户里挖掘出高端客户,则是另外一个仁者见仁,智者见智的问题了。

现在看来,普通的银行网点,离智能智慧还差得远,银行网点人员的服务水平也需要加强,银行网点转型还有很长的路要走。

另外回来的路上试了试青桔单车,还是比较方便的。共享单车企业第一波已经死在了沙滩上,最终谁能胜出还是看资本实力、运营和服务,潮水退去,就知道谁在裸泳了。做什么都是长跑,笑到最后的,才是赢家!

100 次阅读

Shell 中 grep 的副作用

最近在 Jenkins 中编写项目的 Build 脚本时碰到一个关于 grep 的副作用的问题,让人感觉挺费解,解决时需要用一点小技巧,因此在这里记录一下。

先描述一下所碰到的问题的现象,我需要用 Jenkins Shell script 将为我们的项目部署到 Kubernetes cluster 上,在部署之前会进行一些权限的检查和设置,因此在脚本中直接使用了 kubectl 查询资源并结合 grep 的方式来判断资源是否已经创建出来了,例如:


...
is_service_account_exists=$(kubectl get sa --name myns | grep 'my-service-account')
if [ -z "$is_service_account_exists" ]; then
  echo "The service account does not exist, will create it ..."
fi
...

当 Jenkins Job 开始运行时,虽然 service account 并不存在,但是该 Job 却莫名其妙失败了,并没有看到期待的输出 “The service account does not exist, will create it …”。经过一番检查发现问题出在 grep 命令上。当 grep 正确执行,且从标准输入上匹配到期望的内容时,它会返回错误代码 0,例如:


$ kubectl get sa --namespace kube-system | grep tiller
tiller                               1         392d
$ echo $?
0

否则如果没有匹配到任何内容,该管道命令会返回 1,还是以上面的例子为例,当我故意查找并不存在的内容时,返回结果如下:


$ kubectl get sa --namespace kube-system | grep not-exists
$ echo $?
1

而 Jenkins Shell 脚本在执行时默认使用了 -xe 参数,-x 参数将打印每一行执行的命令, -e 则在运行 script 时检查每一行的输出结果,如果结果是非 0 则立即停止脚本执行。在本例子中,我们只想通过获取 grep 结果的输出来判断是否获得期待的结果,因此我们希望 ‘kubectl get sa –name myns | grep ‘my-service-account’ 无论如何都返回 0。解决办法是将 ‘|| true’ 添加到命令的最后,我们知道 shell 脚本通过布尔操作符连接时,会根据命令的返回结果来决定是否运行布尔操作符连接的其他命令。通过 || 操作符,可以保证 true 始终被执行,从而保证该命令的执行始终能够返回 0。例如:


$ kubectl get sa --namespace kube-system | grep not-exists || true
$ echo $?
0

最终将 Jenkins 脚本修改如下,并成功执行。


...
is_service_account_exists=$(kubectl get sa --name myns | grep 'my-service-account || true')
if [ -z "$is_service_account_exists" ]; then
  echo "The service account does not exist, will create it ..."
fi
...

参考:https://stackoverflow.com/questions/22814559/how-when-does-execute-shell-mark-a-build-as-failure-in-jenkins/22816074

128 次阅读