在公司混的差，不一定是能力不行，可能和组织架构有关！
点击上方“芋道源码”，选择“设为星标”
管她前浪，还是后浪？
能浪的浪，才是好浪！
每天 10:33 更新文章，每天掉亿点点头发...
源码精品专栏
如果你接触过公司的面试工作，一定见过很多来自大公司的渣渣。这些人的薪资和职位，比你高出很多，但能力却非常一般。
如果能力属实，我们大可直接把这些大公司的员工打包接收，也免了乱七八糟的面试工作。但可惜的是，水货的概率通常都比较大，新的公司也并不相信他们的能力。尤其是这两年互联网炸了锅，猪飞的日子不再，这种情况就更加多了起来。
反过来说也一样成立，就像是xjjdog在青岛混了这么多年，一旦再杀回北上广，也一样是落的下乘的评价。
除了自身的努力之外，你在上家公司混的差，还与你在组织架构中所处于的位置和组织架构本身有关。
一般公司会有两种组织架构方式：垂直化划分和层级化划分。
1. 垂直划分
垂直划分，多以业务线为模型进行划分。各条业务线共用公司行政资源，相互之间关联不大。
各业务线之间，内部拥有自治权。
如上图所示，公司共有四个业务线。
业务线A，有前端和后端开发。因为成员能力比较强，所以没有测试运维等职位； 业务线B倡导全栈技能，开发后台前端一体化； 业务线C的管理能力比较强，仅靠少量自有研发，加上大量的外包，能够完成一次性工作。 业务线D是传统的互联网方式，专人专岗，缺什么招什么，不提倡内部转岗
运行模式
业务线A缺人，缺项目，与业务线BCD无任何关系，不允许借调 业务线发展良好，会扩大规模；其他业务线同学想要加入需要经过复杂的流程，相当于重新找工作 业务线发展萎靡，会缩减人员，甚至会整体砍掉。优秀者会被打散吸收进其他业务线
好处
业务线之间存在竞争关系，团队成员有明确的奋斗目标和危机意识 一条业务线管理和产品上的失败，不会影响公司整体运营 可以比较容易的形成单向汇报的结构，避免成本巨大且有偏差的多重管理 便于复制成功的业务线，或者找准公司的发展重点
坏处
对业务线主要分管领导的要求非常高 多项技术和产品重复建设，容易造成人员膨胀，成本浪费 部门之间隔阂加大，共建、合作困难，与产品化相逆 业务线容易过度自治，脱离掌控 太激进，大量过渡事宜需要处理
修订
为了解决上面存在的问题，通常会有一个协调和监管部门，每个业务线，还需要有响应的协调人进行对接。以以往的观察来看，效果并不会太好。因为这样的协调，多陷于人情沟通，不好设计流程规范约束这些参与人的行为。
在公司未摸清发展方向之前，并不推荐此方式的改革。它的本意是通过竞争增加部门的进取心，通过充分授权和自治发挥骨干领导者的作用。但在未有成功案例之前，它的结果变成了：寄希望于拆分成多个小业务线，来解决原大业务线存在的问题。所以依然是处于不太确定的尝试行为。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/ruoyi-vue-pro 视频教程：https://doc.iocoder.cn/video/
2. 水平划分
水平划分方式，适合公司有确定的产品，并能够形成持续迭代的团队。
它的主要思想，是要打破“不会做饭的项目经理不是好程序员”的思维，形成专人专业专岗的制度。
这种方式经历了非常多的互联网公司实践，可以说是最节约研发成本，能动性最高的组织方式。主要是因为：
研发各司其职，做好自己的本职工作可以避免任务切换、沟通成本，达到整体最优 个人单向汇报，组织层级化，小组扁平化。“替领导负责，就是替公司负责” 任何职位有明确的JD，可替换性高，包括小组领导
这种方式最大的问题就是，对团队成员的要求都很高。主动性与专业技能都有要求，需要经过严格的面试筛选。
坏处
是否适合项目类公司，存疑 存在较多技术保障部门，公共需求 下沉容易造成任务积压 需要对其他部门进行整合，才能发挥更大的价值
分析
如上图，大体会分为三层。
技术保障，保障公司的底层技术支撑，问题处理和疑难问题解决。小组多但人少，职责分明 基础业务，公司的旗舰业务团队，需求变更小但任何改动都非常困难。团队人数适中 项目演化，纯项目，可以是一锤子买卖，也可以是服务升级，属于朝令夕改类需求的聚居地。人数最多
可以看到项目演化层，多是脏活，有些甚至是尝试性的项目-----这是合理的。
技术保障和基础业务的技术能力要求高，业务稳定，适合长期在公司发展，发展属性偏技术的人群，流动性小，招聘困难 项目演化层，业务多变，项目奖金或者其他回报波动大，人员流动性高，招聘容易
成功的孵化项目，会蜕变成产品，或者基础业务，并入基础业务分组。
从这种划分可以看出，一个人在公司的命运和发展，在招聘入职的时候就已经确定了。应聘人员可以根据公司的需求进行判断，提前预知自己的倾向。
互联网公司大多数将项目演化层的人员当作炮灰，因为他们招聘容易，团队组件迅速，但也有很多可能获得高额回报，这也是很多人看中的。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/yudao-cloud 视频教程：https://doc.iocoder.cn/video/
3.组合
组合一下垂直划分和层级划分，可以是下面这种效果。
采用层级+垂直方式进行架构。即：首选层级模式，然后在项目演化层采用垂直模式，也叫做业务线，拥有有限的自治权。
为每一个业务线配备一个与下层产品化或者技术保障对接的人员。
绩效方面，上层的需求为下层的实现打分。基础业务和技术保障，为绿色的协调人员打分。他们的利益是一致的。
End
大公司出来的并不一定是精英，小公司出来的也并不一定是渣渣。这取决于他在公司的位置和所从事的内容。核心部门会得到更多的利益，而边缘的尝试性部门只能吃一些残羹剩饭。退去公司的光环，加上平庸的项目经历，竞争力自然就打上一个折扣。
以上，仅限IT行业哦。
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
微信扫码关注该文公众号作者