现在公司大了,遇到的人员类型多了,渐渐觉得程序员有大局观是一件很难得的事情。在加上现在一直盛传的华为辞退34以上的员工,引起了开发人员极大关注,也开始了新一轮的焦虑。

怎样的成长才能避免因为年龄大而走入死胡同呢?个人成长有太多方面可以总结,需要做的也很多,但不要成为螺丝钉是避免这种困境最低的标准了。

0. 案例

在实际工作过程中时常会遇到下述场景:

做业务对接或问题排查时,找到指定团队的对接开发Team,一般情况下会有一个指定的开发人员做对接,比如A,在解决问题的过程中涉及到同一团队另一开发的工作范围,这时候开发A会告知我去找开发B,然后这件事情就会变得与A完全没有关系,于是我就需要和开发B阐述我的需求,然后B又会和A一样使用她们自己的工作知识来和我沟通,完全不会理会我理不理解他们的业务。很多时候可能只是意见简单的问题,却需要走流程般的一个个传递下去,甚至会变成一个环,让人苦不堪言。

大公司中部门和团队划分较细,部门利益和团队利益纠缠,导致每个团队负责的业务范围较为确定,因为团队KPI所限,所以不是自己KPI范围内的事情非常排斥,也就导致团队中的开发人员只能慢慢变成螺丝钉。很多程序员慢慢也就习惯其工作氛围,眼界局限在自己的业务范围内,甚至对同团队内其他人做的事情都不熟悉,也缺乏熟悉的动力。

这种开发人员就给我一种个个都是螺丝钉,在一个点上能做好,但却需要别人指挥才能做成一件事情;我都会思考这种开发人员在做技术的时候技术深度能达到什么程度,技术广度又能达到多宽,在遇到问题的时候能全面的来分析吗?

1. 不甘于做一个螺丝钉

公司中的螺丝钉是很容易被替代的,以内即使少了几颗螺丝钉也不会产生多么重大的损失,至少找几个差不多技术能力的,短期交接就可以保证业务顺畅;这种方式对公司很有利,但落到个人上就是一个悲剧。

怎么才能不只是一个螺丝钉,以下这些方面可以作为一个参考。

2. 熟悉自身团队的业务

当技术团队变大之后,一般超过6-7个人之后,就会变成更小的开发小组,每个小组会有更喜欢的负责范围,细化到每个人也有确定的业务范围和系统职责。比如在KTV预订团队就分了交易和商品信息两个开发小组,在交易小组里面又会按照业务和系统划分到每个人,因此每个人最后做的就是KTV预订业务中的一小块。

如果限制自己在一小块业务里,或者某几个系统开发中,自己的眼界就会相对狭窄,上升空间也非常优先。因此在团队内部,最快拓展自我知识领域的方式就是熟悉上下游的业务系统。上下游的业务系统是与个人工作利益最相关的,即使在日常开发中不够熟悉上下游业务系统也很容易出现问题。

2.1 那怎么才算是熟悉业务系统?

  • 熟悉上游系统的业务模型及系统设计
  • 下游系统对自身依赖的情况,其依赖在自身系统的内部实现
  • 下游系统的业务模型及系统设计
  • 上下游核心系统的代码逻辑
  • 能够在紧急情况下排查上下游系统的问题

2.2 如何熟悉业务系统

  • 关注系统设计

    本团队开发一般都会做系统设计,在技术评审或者技术交流时都是了解系统设计很好的机会。这些系统设计的优缺点,如果是自己去设计会怎么做。

  • 阅读系统核心代码

    一个系统的架构设计确定了,系统大致结构也就很清晰了,但系统内部的实现还依赖与代码的实现,特别细节部分。

3. 部门及相关部门的业务

很多时候我们系统上下游并不一定是本团队负责,很多需要有其他团队甚至是其他部门来负责。比如KTV预订的供应链系统、搜索和结算系统就是其他部门的技术团队在开发。因为跨团队跨部门,熟悉程度很难达到自身业务团队业务那样深入,而且其他团队/部门负责的内容可能是自己上游的上游或者下游的下游,并不一定和自己业务产生关系。

3.1 熟悉到何种程度

  • 自身业务紧密相关的需要了解上游系统的原理,逻辑细节
  • 下游系统对自身系统的依赖,重要模型及字段级别的依赖,为什么依赖这些
  • 感兴趣的业务,其实现的原理,将该团队的代码拉下来看看。

    比如搜索涉及到的搜索原理,相关工具以及其中的技术难点;结算系统里面财务的概念。

3.2 如何熟悉

  • 对应团队的共享文档

    比如团队提供的对接文档,技术设计或者公开的分享文档。

  • 项目代码

    公司里的代码基本都是公开的,直接找到对应的代码,很多细节就清晰了。

  • 请人吃饭

    这个就不多解释了,真能找到相关开发一起吃饭是一件很受益的事情,可以将想了解的事情一下了解清楚,当面沟通也是效率很高的,除了这些好处之外,拉近与同事的距离,在以后的合作和学习中都大有裨益。

4. 正确的业务对接方式

熟悉了业务,还需要将自己掌握的都用起来,这样才能算是融会贯通。我们时常在对接其他业务或者让其他业务对接进来。

4.1 其他业务对接本团队业务

  • 对接负责人

    对接负责人需要梳理整个业务对接过程,及时发现节点中的问题,能够分辨相关功能的节点负责人,并且能将需求方的需求准确转述给本团队的节点负责人,能够向需求方屏蔽掉自身团队业务的技术细节。节省业务方时间的同时也能大大提高本团队的开发效率。

  • 对接流程的一个节点

    作为对接中的一个节点,能够准确理解需求方的需求对应到自己业务范围内的相关技术点,如果不是自己业务范围内,也可以帮助需求方找到相应的节点,并且帮助需求方将需求阐述的更清晰。

4.2 对接其他业务

对接其他业务时,有些时候并没有一个明确的技术负责人,就像在开头的案例一样,需求会被当作皮球一样踢来踢去,沟通成了环。这时候只能尽量先研究好对方提供的对接文档,然后整理自己的疑问,一下问清楚,尽量避免无效沟通。剩下的也都是沟通技巧了。

5. 总结

列举的这些只是提升自己专业能力和影响力的一小方面,但要做到这些却要求自己具有很好的主动性。