wxya（个人网站）项目管理和技术管理
这样说吧，大多数的项目所用的技术，其实都是用很平庸的技术，无非是增删改查，或者写一些调用api的代码去实现业务功能。做项目所需要的技术，其实并不是体现在写代码的过程中，而是体现在项目部署的过程中，体现在用（项目基础设施）组件实现高并发之类值钱需求的过程中，更体现在排查解决问题的过程中。
所以说，很多情况下，不是说程序员转管理后技术变差，而是本身技术根本就没好过。
比如做java项目，写业务代码其实不需要用太多的技术，熟悉业务并不代表技术好，而不少程序员会把了解spring boot单机版的api以及熟悉java核心接口，当成技术好，但实际上，做java项目时，怎么才能算技术好呢？
1 在什么都没有的情况下，能搭建一套系统，手下的小弟能在这个基础上写业务代码。或者是拿个现有的模板，能稍作改动，同样，手下的小弟能在这基础上写业务。
3 开发好代码以后，能通过配置jenkins或docker或k8s或service mesh，从而实现基于ci/cd的自动化部署，把代码部署到客户指定的服务器。或者再进一步，能主导项目发布的流程。发布的过程中，如果有运维方面的问题，能主导解决。
4 能解决各类问题，业务层面的问题就不说了，比如来个内存oom，或者数据库性能问题，这要能排查解决。或者再进一步，用kafka或redis遇到问题，也要能解决。
5 能搭建针对项目的监控系统，比如用cat或zabbix监控机器或数据库，并且并设计出针对性的预案。比如服务器宕机了怎么办，数据库性能慢又怎么办。
上述的技能，其实不是简单的记api，而是需要靠经验积累的，甚至如果有5,6年开发经验，但只写了代码，估计连边都未必能摸到。
但是在不少中小型公司里，不少领导或开发，认为技术好，就是熟悉业务，出现了业务问题能很快定位并排查，或者是熟悉各种单机版的排查问题的手段，比如debug，再如用postman发请求调试，或者会认为熟悉linux搜索日志看cpu的命令就认为是技术好。但这类技术，顶了天一般只是熟悉单机版开发技术，最多算个高级开发的熟练工，都不能算是初级架构。
而这种靠记忆api或业务知识的所谓技术，其实不用一般就会退化，所谓一做管理就平庸。但如果真正做到架构师级别，领导不会让转管理，因为技术架构上不可替代。
比如大家可以去看，在很多公司里，项目经理甚至项目小组长好找，比如做久了熟悉业务了熟悉人际关系就可以做，但要去找个能支持公司整体项目架构的，很难。
再说大公司互联网公司里的场景，做技术架构和做管理，一般也是两条路线，技术好一些的架构师，拿的薪资未必比项目经理要低。而且大公司里技术好，比如熟悉各种架构技能，由于有更值钱技术的实践机会，所以技术一般不会差，公司更会当成宝，不会轻易让转管理。
本人平时也会接触到不少开发，其实还也是发现，只要技术做到了架构这个层面，哪怕管人了，技术也不会退化，因为架构层面技术，更多是体现在使用组件搭建架构，以及解决各种问题。但是话说回来，也见到不少开发转管理后，所谓技术好转管理后退化，其实技术还一个样，原来是熟悉单机版api编程的，现在还是老样子。
其实不少程序员是身处中小公司，这部分程序员其实去转管理，就相当于另外去专研一个新的领域，毕竟管理需要和人打交道。如果不是在大公司，哪怕是有管理20,30号人的经验，只要技术上依然停留在做增删改查，跳槽时第一技术未必有竞争力，第二，中小公司的所谓管理岗，一般都是从自己公司的底层提拔，或者是要熟悉本公司的业务，所以靠管理技能跳槽也未必更有竞争力。
所以如果在中小公司，开发转管理这不是不可以，但如果年纪接近30岁，那还真不如准备些技术面试，争取进个好公司，找个包含更值钱技术的项目继续专研（架构等）技术。毕竟哪怕是32,33，甚至35，有值钱技术的实践经验，如果公司还行，后面依然能找个好公司做技术。
但如果年纪快35，技术不行，身处中小公司，哪怕平时威风凛凛管好几十号人，但如果公司有变动，或者是业务线有变动，那之后真可能就高不成低不就了。大家应该听说过“伪高管危机”。
Loading...