技术人员架构方案
目前国内大部分公司的人员架构方案都是按技术栈划分，分为前端、后台、服务端等等，然后一个人可能会同时管理很多项目。技术上大家虽然有个大概的框架模型，但是大多都是直接在框架，没有将通用的部分抽取出来。这样的架构方案有如下几个弊端：
- 有框架上的bug或优化，所有的项目都要手动去改，有些甚至因为沟通问题会漏掉。
- 技术开放度不够，很多人做着相同的工作，没有及时分享出来，在公司层面浪费了资源。
- 人员成本高，新人或者应届生很难全面掌握相关技术栈独立完成业务开发工作，遇到技术难点也没有标准解决方案。
- 老员工成长瓶颈明显，工作很多年的老员工虽然能在自己感兴趣的一个技术上深钻，但是成果很难被其他项目吸收，而且他还是必须负责几个实际的业务项目。
技术架构
技术架构的主要思路是业务层开发不直接使用开源框架，而是基于公司成熟的产品框架开发，产品框架也是基于优化和标准化之后的封装框架开发。这样层层服务，最后会让公司技术人员分层，每个人都可以在自己专长的领域钻研，而业务开发只需要熟悉公司封装的产品框架即可，可以大批量招用实习生来培养。
技术架构
人员架构
最终的人员架构是分为三层：
- 技术专家：在某个领域的技术专家，负责维护开源框架的二次封装和公司自研框架，为技术大牛搭建框架服务。
- 技术大牛：负责搭建公司产品需要的通用框架，做性能瓶颈优化研究，为业务开发同学服务。
- 业务开发：负责开发维护公司业务代码，每个业务开发负责一个或几个完整的项目。
这样的好处是产品开发沟通成本会减少，不存在同一个功能各个端的沟通问题，开发也没有技术难度，遇到技术难点有专人提供支持。
演变过程
这样的架构演变对大部分公司而言是很难一蹴而就的，因为不可能停下业务开发而去专门做框架开发。
建议可以先建立简单的共同依赖项目，所有人都可以提交代码，每个开源项目封装由一个人负责审核即可。这样慢慢累积，最终形成完整的类似于springboot一样的开发框架，业务开发只需要少量的配置即可拿来即用。
老项目可以暂时不动，由新项目来依赖和完善框架，老项目再逐步接入调整。
