侧边栏壁纸
博主头像
IT技术分享社区博主等级

一个有态度的互联网技术交流平台

  • 累计撰写 178 篇文章
  • 累计创建 17 个标签
  • 累计收到 23 条评论

目 录CONTENT

文章目录

你在公司混的差,可能和组织架构有关!

IT技术分享社区
2023-07-07 / 0 评论 / 0 点赞 / 82 阅读 / 2,167 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2023-07-07,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,非公众号转载保留此声明。

如果你接触过公司的面试工作,一定见过很多来自大公司的渣渣。这些人的薪资和职位,比你高出很多,但能力却非常一般。

如果能力属实,我们大可直接把这些大公司的员工打包接收,也免了乱七八糟的面试工作。但可惜的是,水货的概率通常都比较大,新的公司也并不相信他们的能力。尤其是这两年互联网炸了锅,猪飞的日子不再,这种情况就更加多了起来。

反过来说也一样成立,就像是xjjdog在青岛混了这么多年,一旦再杀回北上广,也一样是落的下乘的评价。

除了自身的努力之外,你在上家公司混的差,还与你在组织架构中所处于的位置和组织架构本身有关。

一般公司会有两种组织架构方式:垂直化划分层级化划分

1. 垂直划分

垂直划分,多以业务线为模型进行划分。各条业务线共用公司行政资源,相互之间关联不大。

各业务线之间,内部拥有自治权。

image.png

如上图所示,公司共有四个业务线。

  • 业务线A,有前端和后端开发。因为成员能力比较强,所以没有测试运维等职位;
  • 业务线B倡导全栈技能,开发后台前端一体化;
  • 业务线C的管理能力比较强,仅靠少量自有研发,加上大量的外包,能够完成一次性工作。
  • 业务线D是传统的互联网方式,专人专岗,缺什么招什么,不提倡内部转岗

运行模式

  1. 业务线A缺人,缺项目,与业务线BCD无任何关系,不允许借调
  2. 业务线发展良好,会扩大规模;其他业务线同学想要加入需要经过复杂的流程,相当于重新找工作
  3. 业务线发展萎靡,会缩减人员,甚至会整体砍掉。优秀者会被打散吸收进其他业务线

好处

  1. 业务线之间存在竞争关系,团队成员有明确的奋斗目标和危机意识
  2. 一条业务线管理和产品上的失败,不会影响公司整体运营
  3. 可以比较容易的形成单向汇报的结构,避免成本巨大且有偏差的多重管理
  4. 便于复制成功的业务线,或者找准公司的发展重点

坏处

  1. 对业务线主要分管领导的要求非常高
  2. 多项技术和产品重复建设,容易造成人员膨胀,成本浪费
  3. 部门之间隔阂加大,共建、合作困难,与产品化相逆
  4. 业务线容易过度自治,脱离掌控
  5. 太激进,大量过渡事宜需要处理

修订

为了解决上面存在的问题,通常会有一个协调和监管部门,每个业务线,还需要有响应的协调人进行对接。以以往的观察来看,效果并不会太好。因为这样的协调,多陷于人情沟通,不好设计流程规范约束这些参与人的行为。

image.png

在公司未摸清发展方向之前,并不推荐此方式的改革。它的本意是通过竞争增加部门的进取心,通过充分授权和自治发挥骨干领导者的作用。但在未有成功案例之前,它的结果变成了:寄希望于拆分成多个小业务线,来解决原大业务线存在的问题。所以依然是处于不太确定的尝试行为。

2. 水平划分

水平划分方式,适合公司有确定的产品,并能够形成持续迭代的团队。

它的主要思想,是要打破“不会做饭的项目经理不是好程序员”的思维,形成专人专业专岗的制度。

这种方式经历了非常多的互联网公司实践,可以说是最节约研发成本,能动性最高的组织方式。主要是因为:

  • 研发各司其职,做好自己的本职工作可以避免任务切换、沟通成本,达到整体最优
  • 个人单向汇报,组织层级化,小组扁平化。“替领导负责,就是替公司负责”
  • 任何职位有明确的JD,可替换性高,包括小组领导

这种方式最大的问题就是,对团队成员的要求都很高。主动性与专业技能都有要求,需要经过严格的面试筛选。

坏处

  • 是否适合项目类公司,存疑
  • 存在较多技术保障部门,公共需求 下沉容易造成任务积压
  • 需要对其他部门进行整合,才能发挥更大的价值

分析

image.png

如上图,大体会分为三层。

  • 技术保障,保障公司的底层技术支撑,问题处理和疑难问题解决。小组多但人少,职责分明
  • 基础业务,公司的旗舰业务团队,需求变更小但任何改动都非常困难。团队人数适中
  • 项目演化,纯项目,可以是一锤子买卖,也可以是服务升级,属于朝令夕改类需求的聚居地。人数最多

可以看到项目演化层,多是脏活,有些甚至是尝试性的项目-----这是合理的。

  1. 技术保障和基础业务的技术能力要求高,业务稳定,适合长期在公司发展,发展属性偏技术的人群,流动性小,招聘困难
  2. 项目演化层,业务多变,项目奖金或者其他回报波动大,人员流动性高,招聘容易

成功的孵化项目,会蜕变成产品,或者基础业务,并入基础业务分组。

从这种划分可以看出,一个人在公司的命运和发展,在招聘入职的时候就已经确定了。应聘人员可以根据公司的需求进行判断,提前预知自己的倾向。

互联网公司大多数将项目演化层的人员当作炮灰,因为他们招聘容易,团队组件迅速,但也有很多可能获得高额回报,这也是很多人看中的。

3.组合

组合一下垂直划分和层级划分,可以是下面这种效果。

image.png

采用层级+垂直方式进行架构。即:首选层级模式,然后在项目演化层采用垂直模式,也叫做业务线,拥有有限的自治权。

为每一个业务线配备一个与下层产品化或者技术保障对接的人员。

绩效方面,上层的需求为下层的实现打分。基础业务和技术保障,为绿色的协调人员打分。他们的利益是一致的。

End

大公司出来的并不一定是精英,小公司出来的也并不一定是渣渣。这取决于他在公司的位置和所从事的内容。核心部门会得到更多的利益,而边缘的尝试性部门只能吃一些残羹剩饭。退去公司的光环,加上平庸的项目经历,竞争力自然就打上一个折扣。

作者简介:小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

0
广告 广告
博主关闭了所有页面的评论