前言
其实我的文章都会有一个前言,我认为前言就是为什么想写这篇文章,很多书都会有前言,介绍的就是作者写这本书的原因,而这次的原因其实挺难以启齿的,因为这次不是想分享技术,而是分享软技能,可能有些人还没明白软技能是什么,或者已经隐隐的能够理解什么是软技能,说来也不怕笑话,我是24年10月份也才知道软技能这个词的,而写这篇文章同样也离不开10月份的国庆节。
首先给大家打个预防针,这篇文章就是讲述了我自己个人在26岁这个年龄的感悟,可能是不对的,大家看到后面可能会觉得我在pua大家或者写了个鸡汤什么的,如果大家觉得无聊就直接关掉,不用看这篇没啥“营养”的文章~
时间回到24年的10月,从4月换新工作已经6个月了,截止目前我的职业生涯已经满4年了,对我来讲,现在我认为自己具有在软件工程领域中应付基本需求的技术能力和工作能力,我的评判标准就是需求的完成质量和完成时间,再具体点讲如果一个需求到来我知道如何根据当前的代码设计来完成这个需求,并且知道这个需求需要那些外部同学的资源然后按时或提前完成资源协调并完成需求、监控、告警、日志打点、报表观察等等工作时,我认为我已经实现了当前层级的“工作自由”,这样的人也是公司最喜欢的劳动力。
但是,做完这些,当我继续拿起《代码大全》、《重构改善既有代码设计》等书籍时,我突然觉得自己蛮努力的,这样一直下去可以吗?(后来知道,其实可以,但在国外会更好些),有没有成功的程序员自传或者感悟能够让我找到接下来努力的方向,因为我一直信奉 正确的方向比努力要更加重要,所以我去互联网上查找了一些对于程序员职业生涯一些看法的书籍(本来想看些博客就完事儿的,但书籍才是真正的一手信息源,非常系统,这点很重要。我也是从书里学到拿来讲的哈哈),每天都会抽出时间来阅读几章(时间真的是可以挤出来的就看你想不想),书里讲到跟主管面谈时的几个对自己有用的关键问题,刚好最近我跟领导进行了一次面谈。谈完之后,也思考了很久,总觉得应该写点什么有用的留给自己,多年之后再来看一遍的时候也许真的会感触良多吧。
谈话内容提炼
首先,我认为直接给主管讲自己想要什么会有些过于直白,虽然领导都明白,但是我们可以换个方式,这个方式就是:提问。在提问的过程中领导会立刻知道你的诉求和志向,所以我选择了直接提问而不是等领导开口,如果领导直接问了你最近有什么困惑什么的,那简直太好了,我的主管就是这样的人!这个时候千万别害怕,更别说没啥问题!
在《程序员软技能2-软件开发者职业生涯指南》的43章中讲到提问的几个基本的信息点,那么我按照书中的去做,去问了一下我们的主管,之后将内容尽可能还原并提炼,供大家参考一下:
1、您目前对于咱们团队的最大期望是什么?
其实这个问题,不仅我的主管,我相信任何一个主管都能够讲的很明白,这个层面其实跟业务是强相关的,因此我实际的内容对你可能没有帮助,如果你实际跟主管谈话,一定要记得问他这个问题,他如果真的没回答上来的话我认为他一定不合格!
我的主管跟我讲了我们团队的形成历史,以前是如何组织的,现在是如何组织的,为什么最终变成了现在这样的组织结构,而现在他期望我们的组织未来会如何,业务未来是如何对外提供能力的。
讲到这里,我基本就了解我们的主管对我们团队的期望是什么,而这个期望会直接影响到我们做事情原则和方式,比如他期望我们团队能够将业务贯通融合,那么我们在排查线上问题时就最好能够了解更多的业务,协作时互相了解而不是“各司其职”,如果一个线上问题原来需要三个组各出一个人来解决,现在一个人就可以解决的话,效率则会是翻倍的增加(组的维度很小,目的就是为了负责的领域相同,当前三个组的业务领域必须相同,订单和账号领域就不能混为一谈)。
当你知道主管想要什么的时候,你就知道你应该做什么了。(我知道网上的戾气比较重,很多人觉得这种行为是为了让老板住上别墅,开上奔驰,但是我们不得不面对现实,既然我们选择了打工,就需要将自己的时间卖给公司,而不认真工作对自己不好对老板不好,这是一种负向反馈,如果认真工作,有效工作就会得到正向的反馈,我们会变得越来越好。就像我前言中讲到的,我写的很像鸡汤,但确实是我自己做的,如果你做了你也会发现这不是鸡汤,它会让你变得更好,也会让你获得更多价值)
2、您对于我们小组的期望是什么?
小组的期望与团队不同,主管规划好团队方向之后,各小组更多的是针对现阶段的形势来做些什么,而不是再像团队一样的“畅想未来”了,很多人觉得小组要怎么做需要小组自己来想,但是小组的想法同样也需要和主管对其,那么这个时候小组需要参考一下主管对小组的期望。
比如我们主管讲到了小组需要在稳定和安全的基础上完成链路的修复和体验的提升,那么根据这个目标再去写总结和展望时,总不会出现太大的偏差,起码你知道主管希望我们小组是一个什么样的状态。
3、您对于我们这个层级的期望是什么?在您心目中,什么样的我们才能让您觉得很棒?
其实这个问题才是我们最关心的,如果你想努力在这个年纪,那么这个问题你一定要问,这个问题其实就是你的主管对于人的评判标准,也就是绩效。
因为绩效通常是同级别之间互相比较,所以提问时一定要问自己的层级下如何努力,这里我也比较关心,所以分享给大家我的主管是怎么想的:
首先,主管认为我们这个层级是非常好拿好绩效的(好不好我不知道奥),然后他将这个层级的程序员分了三个层次:
1、按时完成需求,质量达标,没有线上问题,完成稳定性要求(小组期望)
2、在1的基础上,能够让需求完成的更快,为业务提高效率,让代码能够更加健壮
3、在1,2的基础上,能够将自己的需求融汇贯通,连点成线,用切实的数据描述对团队目标的贡献程度。
4、最后一个没必要但挺重要的问题:您觉得我目前在工作中存在什么缺陷?
这个问题是我自己想的,我很喜欢问面试官、或者我的上级这个问题,因为这个问题在职场上你不问是没有人会说的,因为大家都觉得这个是伤自尊的事情,更甚者会被认为是pua。因为如果主动说我的缺点,我真的第一想法是反驳并认为你在pua我,这个是人的本性,特别是领导没有给你非常好的绩效时,这种感觉会更加明显。
所以相对来说主管一般不会主动的说你的缺点,只会说你很好,辛苦了,这些话你应该听了很多了,这才是没营养但又不得不说的话,不说又觉得做的不好:)。
我刚工作一年的时候真的被“pua”过,当然也许是我自己认为的吧,我认为评判pua的标准是,当你做的不好的时候,主管是否仅仅在说你不好,而不是在说完后教你如何变得更好,后者才是最有营养的话。
所以综上所述,这个问题我建议你在跟主管单独聊的时候问一下,同样这个问题也会让主管了解你,知道你是一个敢于直面自己缺点的人,而不是一个狂妄自大的“井底之蛙”。
工作模式的调整
针对主管对我自己的评价,有优点,也有需要提升的点(其实就是缺点,自己没有意识到的缺陷),目前我做出了自己以前工作模式的调整:
1、首先如果主管提出了你的缺点,那就立刻改正吧,除非你打算跑路~,否则你应该让自己变得顺眼些。
2、对于所有需求不再使用平均分时方式完成。所有的需求都有对团队目标和团队收益的贡献值,优先做团队收益最大的需求
3、每天一定要留给自己思考的时间。虽然都是"牛马",但我们都有大脑,可以什么都不做,就仅仅是思考,想到什么写什么,因为有了点才会有线。
4、所有的需求完成之后回顾一下,看看有没有什么能够让后面相似类型需求能够更快的,更好的接入,屎山归屎山,雕花照样还得雕~
5、需求上线后,一定要可以监控和统计,这样既可以保护自己及时发现线上问题,同时也可以量化需求对团队的收益,好的报表还能够发现更深层次的隐形需求,再次产生想法。
6、如果你觉得“害怕”工作,经常盼望着周五,没事儿,我也是,但一直这样也不是个办法,《程序员软技能2-软件开发者职业生涯指南》里面讲到如果咱们喜欢做某个事情觉得工作占用了时间,那我们就在工作之前做这个事情,我看作者早睡早起,工作之前去骑车,写博客,那么我也学一学他的方法,至少我已经试行了1个月目前感觉不再那么的害怕我的工作了。
后记
我非常赞同《程序员软技能2-软件开发者职业生涯指南》这本书里面的最终写的一句话:改变只能始于你采取行动。包括耗子叔写的《左耳听风》里面同样强调的就是 这类书籍最重要的点是读者一定要去做,如果只是理解深刻,而没有行动起来,那么也只能做个无法成功的明白人。
如果看到这里说明你多少和我有些相似的困惑,那么希望我这篇文章能够解开你1%的困惑吧。

55

被折叠的 条评论
为什么被折叠?



