传统软件行业中技术团队的发展(现状篇)

传统软件行业中,技术团队人才梯度如何迭代和演进? 技术人员如何破局,实现个人发展与公司发展的契合?

认清它,承认它,然后改变它。

1. 前言

以下这些是我的一些个人思考,关于我们这样做电子政务的传统软件公司,相匹配的人员结构的应该是怎么样的? 以及如何实现在此基础上,人员组成的良性发展。

以下这些文字,一来算是个人的总结,二来也是希望大家能够从中找到自己的利益契合点,找到自己的位置,思考自己的发展方向。

再次强调一下,这只是个人的所感所悟,并且我这个感悟也很可能是个错的。

原本准备一篇文章写完的,但最终发现越写越多,因此将其拆分为几篇来分别叙说。

本篇主要解释传统软件行业技术团队的特点,以及人员组织结构,工作流程的形成原因。

2. 公司/行业特点

以笔者所从事的电子政务为例,类似这样的传统软件行业公司,大都有这么几个特点:

  1. 非技术方面的影响因素远大于技术本身。
  2. 技术使用层次浅,迭代慢,一年经验足以应付90%的工作需要。
  3. 业务受政策影响大,变动频繁。
  4. 行业门槛不高,竞争激烈。

3. 相匹配的人员组织结构

这样的行业特点,造成业内公司对应形成的人员结构大体上会是这么两种:

  1. 岗位工资高于平均水平的高薪,精英流打法
    a. 信奉"一个高效程序员抵得过十个普通程序员",要求个人素质。
    b. 花1.5倍工资雇佣一个人,干2-3个人的活。
    c. 通过增加完成效率和减少返工率来支撑源源不断的业务压力。
    d. 优点是做事效率高,沟通顺畅。
    e. 缺点就显而易见了,人力成本居高不下,公司业绩很容易陷入增产不增利的怪圈。
  2. 岗位工资低于平均水平的低薪,堆人流打法
    a. 信奉"三个臭皮匠赛过诸葛亮"。质量先搁一边,先把数量堆上去。
    b. 大力出奇迹,业务压力大我就堆人,没有堆人解决不了的问题。
    c. 优点很明显,人力成本比较容易控制。
    d. 缺点也很明显,沟通成本高,问题解决效率低。

总之以上两种方式各有千秋,每种方法都有其拥趸。公司也不会僵硬地死搬一种方式莽到底,更多的是以某一种为主。大家可以用自己比较了解的一些公司对比分析下。

4. 关于"堆人流" 派别

笔者所在的公司所采取的正是"堆人流"这一派别。所以接下来的部分我们的讨论重点就是它了。

传统软件行业中,"堆人流"派别的人员组成特点是:

  1. 高级人才,少。他们成为高级人才往往是因为更熟悉当下公司的工作流程,更熟悉业务,以及踩过的坑多一些(唯"手熟"尔)。
  2. 中级人才,少。相较于高级少了几年经验。
  3. 初级人才,多。初入行业不久,虽然技术上基本够用,但业务理解,以及经验上还比较缺失。

最终你就会发现,堂堂一个技术类工种,在传统软件行业公司生生给玩成了熬资历大赛了。(当然任何事情都不绝对,我确实也见到了靠着技术热情实现越级升迁的,毕竟再传统,它也是软件公司不是)

以上只是陈诉一个事实,无意批判,而且随着职场经验的增加,也是越来越体会到这种状况的现实性和合理性。

4.1 形成纺锤形的人才组织结构

但是熬年限的方式很容易让"堆人流"的人员组织结构熬成纺锤形:

先解释下环境因素:

  1. 本身传统软件行业公司在人才吸引力上就处于比较低的层次。相关人员不论是在技能水平,还是主观意愿上都是较为缺失的。
  2. 于是即使有后知后觉,大器晚成的,只会将传统软件行业公司作为跳板,磨砺一两年后直接闪人。
  3. 那剩下的还能是什么人? 年纪大了跳不动的老油条;家里几套房收租,就想当条咸鱼,上班就是为了有点事做的二代;在当下环境熟悉多年,虽然对薪资或环境有些不满,但对于改变又畏首畏尾的大多数。

再来看看人员本身组成因素:

  1. 高级的变动不会很大,离职少,入职的也不多。正如前面所说的,除非业务新增,否则对于业务远重于技术的传统软件行业公司来说,更偏向于内部提拔高级人才。而且公司再控制人力成本,为了既有业务的平稳和团队稳定,对于高级别的,一般也会参考业内平均水平,给出一个相对合理的价格。
  2. 然后就是中级的,这一集团不论在绝对数量还是比例上,增加的速度会比较快。早期业务高速发展阶段为了抢业务蛋糕,公司肯定会大量招聘,而等到后期业务进入平稳阶段,这些可能以初级人才身份进入公司,随着对公司工作流程的熟悉和工作经历的增加,已经够到了公司中级人才的标准。
  3. 最后是初级。这一集团在划分之处就是做好了高速更新准备的,毕竟软件开发名虽高端,但还是存在着大量“键盘上撒把米,鸡都能干得来”的活。因此出于成本考虑,公司也会保持对于初级的招聘,也能形成对于中级人才的补充。

4.2 补丁方式形成的工作流程

而且,能够形成这样人才组织结构的,公司在工作流程上一定属于顺其自然流派。

公司起步阶段,看到业务来了就组织一波人开干,接着业务量多了就开始堆人,人太多为了控制成本就招聘能力比较低的,低级的太多就多调一个中级或高级的过去给擦屁股。经典的"水多了加面,面多了加水"操作。

这些决策都属于下意识的反应,而这些在当时看似属于最优解的决策,堆积作用之下,除非高层能够在初期就意识到并且花费专门的精力坚持进行迭代,否则最终形成的工作流程,一定是强依赖于人工操作,缺乏流程追溯的单向夺命狂奔。并且中间充斥着各类让人诧异,但仔细想来又很"合理"的"省力"操作。(典型例子就是Java程序里的class文件替换式更新)。

但正如笔者一直强调的"一切美好的事物,一定是刻意为之才能得到的;如果在追寻某件事物过程中,每一步的决策都是顺应人性,从阻力最小的方向选择解决方案,那最终得到的一定不会是理想中的效果"。

慢慢公司发展壮大,陪着公司一路拼杀上来的老人逐步高升,占据了各个部门的关键岗位,而在这过程中自发形成的工作流程和一系列协作习惯也被作为公司规定和团队默契固定了下来。

4.3 大家都不满意

最终结果就是,技术团队里绝大部分人都不满意:

  1. 高级人才梯队觉得下面这帮人做事怎么效率这么低,错误一犯再犯。满眼看上去都是问题,临到头又发现都是隔靴挠痒,只能哪个催得急先解决哪个。然后一直处在这种疲于救火中。
  2. 中级人才梯队一肚子火,产品经理一堆奇葩要求,工期又紧张,底下这帮人脾气比能力大,帮不上忙不说,造问题比解决问题快得多,总是牵连自己在后面追着擦屁股。
  3. 初级人才梯队也没好脸色。天天让我一会做这,一会做那的,都是些一点技术含量都没有的破事来回干,工作流程又混乱,完全看不到前途发展,我要不提离职算了,这点工资哪干不是干。

5. 总结一下

传统软件行业公司,因为强业务,低门槛,高竞争的特点,使得公司发展壮大过程中对于技术和管理方向的投入都是比较薄弱的,进而非常容易选择"堆人流"的发展方式。

造成的结果就是在早期业务高速发展时候形成的倒图钉式人才组织结构,在业务发展进入平缓期后,很快演化为纺锤状的人员组织结构。

早期业务高速发展过程中,靠着走一步看一步的方式建立起来的工作流程,也随着公司发展立下汗马功劳的老员工走向公司的各个关键性岗位,这一套带着各类"抄近路"思想的工作流程就被作为公司内部规范固化下来。

中级人才不断增长的人员组织结构,加上自然形成的重短期,轻长远;重人治,轻规范的"纯天然"管理流程,在业务高速发展期,相关的问题尚可以被掩盖在一片"勃勃生机万物竞发"的景象之下。

但是一旦业务进入平缓期,没有其他新的高速发展业务顶替上来; 或是客户关注点从交付速度转向交付质量,对产品不断提出更高的要求时候,产品缺乏规划,代码维护成本高,技术债重,工作流程效率低等等问题将开始对团队里的每一个人施加负面压力。

最终结果是上至高层领导,下至一线人员,大家都不满意。

6. 技术人员如何破局

这个话题,笔者曾经写过一个百来字的个人思考 —— “能够高效地自我复制”是传统软件行业公司中高级人才认定的关键 。

至于更详细的,就让我们留待下一篇。

7. 后续章节

  1. 传统软件行业中技术团队的发展(团队破局篇)
  2. 传统软件行业中技术团队的发展(个人破局篇)
  3. 文集 - 走出软件作坊

你可能感兴趣的:(传统软件行业中技术团队的发展(现状篇))