如何成为领导眼中不可或缺的人
这篇文章主要还是阅读所感,总结出来共勉,不喜勿喷,也欢迎有不同意见的指教。
首先,主要是以问题起步,如何成为一个优秀的架构师?
这个问题主要分成两种情况,其一就是所谓的面霸架构师,其二则是领导眼中不可或缺的人。
第一种,只要经历过项目的架构,并且理解项目背后所要解决的场景问题,以及把里面所用到的技术背后的原理搞清楚,那么你就是一个面霸架构师,可是面霸架构师并不一定就是领导眼中不可或缺的人。那么问题就来到了,如何成为一个领导眼中不可或缺的人。
以下以一个大佬的真实经历来解答这个问题。
ps: 下文中的我指 xx 大佬。
无关职责,帮助领导解决技术难题
第一个经历,我工作第三年的时候,认识了一个老板。某个周六,他打电话给我,说他们的系统碰到了一个问题,做了某一个操作之后,整个页面就会冻结,怎么点都没有用,他们的技术人员没有头绪,客户也一直在催,让我赶紧帮忙看看。
我打开看了一下,的确是做了操作之后,整个界面都无法点击或者输入信息了,然后我重现了很多次问题,发现整个界面冻结的时候,好像颜色有点不一样,会不会是一个透明的浮层置顶了?最终确认,确实是 bug 造成浮层没有退出。
那么为什么他们的技术人员都没有头绪?因为他们主要是后端开发,js 工作经验比较少,而我的经历也属于偏向后端,可是我能跟领导说,这个问题不属于我的专业范围,因为我是做后端的吗?
领导并不会在乎你的职责是什么,领导喜欢的是可以帮他解决技术难题的人。
总结: 要有能够帮助领导解决技术难题的能力(无关职责)。
理解领导的非技术难题
第二个经历,这是我在外企当中碰到的一个问题。
有一天,公司的领导过来问我,"你有没有觉得我们的开发速度很慢?是不是我们的技术不行?"
"您能跟我详细说说,是哪些地方慢?"
"产品部的人跟我说,他们现在提一个需求,经常要好几个月才能上线,有时候一个简单改文字的需求都是这样。"
这个问题确实不好解释清楚,因为这次沟通一开始就不在一个维度上。开发人员认为,说开发速度慢,应该是指开始开发到最终上线的时间久。可是领导认为,一个需求从提出到最终上线的时间久,就是开发速度慢。
那么开发速度慢算是一个技术问题吗?可以算,也可以不算。那么最终如何解决?开发团队最终一起讨论列出了所有影响开发效率的问题,然后能用技术解决就用技术解决。
所以有时候领导跟你谈的问题并不是单纯的技术问题,你需要把领导的问题转化成技术可以解决的问题。
总结: 理解领导的非技术难题,并最终转化成技术可以解决的问题。
搞清楚领导对你的期望值
可能有人会想,开发效率低这种事情不应该找架构师,这是管理的问题。下面接着说第三个经历。xx 公司系统用了 4 年,架构相对比较老旧,然后有一个新的项目,需求比较多,一位架构师提议,趁着这次的需求把架构更新一下,
然后就跟领导仔细讨论了架构更新的代价和好处,最终达成了一致的意见。
可是任何一个项目都会有各种各样的变数,比如业务方的临时需求变更,再比如有些系统可以不用迁移,只需要对接一下,也会有有一部分人不熟悉新架构,就需要多花一点时间去学习,最终项目延期了。
某一次会议,领导说架构师不行,这次系统上线以后如果不稳定,就把架构师开了,主要还是因为项目延期了。开发也解释了一下不全是架构师的问题,还有一些需求变更,可是领导认为需求改动不大,不至于延期一两个月。然后开发团队私下商量着保住这个架构师,不能让他一个人担责。
后来一次聚餐,领导解释他的压力也很大,本来跟老板说好可以按时完成,结果拖了这么久。
事后团队回顾了一下,这件事情之所以是架构师担责,其实最重要的一个原因就是老板对架构师的期望值是什么,是开发效率,系统稳定性保障,还是复杂问题的突破?
所以整件事由架构师承担的原因就是,大家对架构师的期望值是不一样的。所以,作为架构师最重要的一点就是要明白公司对你的期望值。
总结: 明白公司或者领导对你的期望值。
最后
当然,以上经历并不能代表所有公司的评判标准,并且架构师的优秀也有很多维度可以讲,但是这三个故事可以给我们一些启发。
- 要有能够帮助领导解决技术难题的能力(无关职责)。
- 理解领导的非技术难题,并最终转化成技术可以解决的问题。
- 明白公司或者领导对你的期望值。
以上的三个要点,个人也比较赞同的。
来源:juejin.cn/post/7340834858275389492