原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，非公众号转载保留此声明。

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

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

反过来说也一样成立，就像是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行业哦。赵家人不在此列。

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

推荐阅读：

1. 玩转Linux
2. 什么味道专辑

3. 蓝牙如梦
4. 杀机！
5. 失联的架构师，只留下一段脚本
6. 架构师写的BUG，非比寻常
7. 有些程序员，本质是一群羊！