引言：什么是架构师PM化
和一些做项目主架构或者一号位的同学聊天，经常会听到一种说法：项目主架构做着做着就会做成PM。这背后什么含义呢，细品下来有几层意思：
1.整个蚂蚁的架构非常复杂，涉及的域众多，做主架构或者一号位需要大量的协调投入；
2.不同域之间的资源错配现象严重，需要投入大量精力在锁定资源和推进排期上；
3.项目结构过于复杂，PM催主架构，主架构催域架构，域架构催开发，层层订，各种站会，代码没几行，会议一大堆；
4.现在做的一些项目和产品，技术含量其实是不高的，面条式架构，在架构设计和技术上的投入感觉不多。
架构师PM化，其实就是脱实向虚的一种表现。
架构师和PM其实都是需要对项目的进度和里程碑关心的。不同的是，PM是用表格和数字关心的进度，是没有任何实体内容的，就是一个死的燃尽图；架构师对进度的把控应该是更solid的，背后应该有架构设计和模型拆解做支撑，架构师对进度的把控是对交付物的把控，风险和进展都是有实体内容支撑的。
架构师PM化的特点
什么迹象可以表明架构师已经PM化或者走在PM化的道路上呢？
亲力操刀的实质性工作越来越少
大量参加各种评审会议和汇报，在架构方案、系分、编码、测试上的产出却越来越少甚至没有。
更喜欢拉会催进度
对于项目的把控在架构层面的减少，在管理层间的增多。喜欢：
●拉会过进度；
●钉钉催进度；
●收集进度向上汇报。
越来越难直接回答问题
排查问题和定位原因已经不能独立完成，需要拉各种开发同学一起。
甚至于，还拉不对人，要一个拉一个。
喜欢流程
碰到资源和进度问题，喜欢从流程上去排期和上升，通过技术手段架构调整解决的少。
架构师PM化的危害
对项目的危害
一个项目中有两个PM，而没有架构师的话，对项目进度的把控是很虚的，只是在例会上对各个模块开发的一个进度汇总。模块和模块之间是割裂的，风险也不太容易识别出大小和优先级。
对组织的危害
PM和PM之间，一定会产生踩脚，卷就来了。
同时，合格的架构师会越来越少，架构的升级和演变会变得越来越困难。
对架构师个人的危害
架构师是一个综合的要求。项目管理只是架构师能力要求的很小一部分。如果PM化之后，架构师其他部分的能力在项目过程中就没有办法得到验证和锻炼，对业务的理解力、架构设计能力、架构落地能力、架构管控能力会逐步弱化。最终，变成一个只能做项目的PM，而失去了做架构师的基础。
对研发同学的危害
一个项目中的主架构如果空心化之后，是没法对开发同学形成有效的指导的。会只关注进度条的走动，而不关注开发质量和风险，一些跨域之间的架构问题可能就会下放到开发同学去讨论和决策，最终是否全局合理全局最优，很难评判。
同时，主架构是项目中开发同学的一个职业模版，一个PM化的架构师，会将项目中同学的成长带偏。
如何防止架构师PM化
架构师PM化其实就是架构师的脱实向虚，要杜绝，需要从组织、个人和文化上采用手段。
组织上要提倡做实事
首先，需要在组织层面将考核体系脱虚向实，更多的看战功看产出。
这个虚其实就是考察形成体系、自洽和表述的能力。
我们是需要一个完美的地心说体系，还是一个有用但还不完善的日心说，值得思考。
个人上要做点实事
架构师需要在每个项目中落到实处去。
●架构方案要自己产出；
●架构决策一定要做而且要有记录；
●最好有编码；
●测试要参与测分和执行。
文化上要对PM式的架构师说不
要形成一个氛围，开发同学可以拒绝整天拉会催进度的架构师。
如果一个项目中架构师架构方案和架构决策也不做，可以直接by pass他，开发不如自己上。
作为管理者，对于脱实向虚的架构师，要尽早点醒。
如果项目中的架构师PM化，所有的问题交流都要拉下面的同学，我们也可以直接by pass他们，并且在绩效上反应，让PM架构师没有生存的空间。
引入卓越工程实现自动化去除对PM的依赖
通过自动化的pipeline，将协调、沟通、事务性的工作固化在流程中。我们目前的自动化只能cover到CI这一部分。如果自动化可以cover到契约测试、功能测试、回归测试甚至发布，通过pipeline就可以驱动事情的推动和可视化，PM也就自然而然没有啥存在的必要了，反过来可以倒逼架构师回归到本职工作上。
