阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 小姐姐味道 「小姐姐养的狗」欢迎转载，保留摘要，谢谢！

• 1. 垂直划分
  • 运行模式
  • 好处
  • 坏处
  • 修订
• 2. 水平划分
  • 坏处
  • 分析
• 3.组合
• End

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

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

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

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

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

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

1. 垂直划分

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

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

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

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

运行模式

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

好处

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

坏处

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

修订

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

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

2. 水平划分

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

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

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

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

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

坏处

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

分析

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

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

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

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

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

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

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

3.组合

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

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

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

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

End

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

以上，仅限IT行业哦。