如何防止架构师PM化
和一些做项目主架构或者一号位的同学聊天，经常会听到一种说法：项目主架构做着做着就会做成 PM。这背后什么含义呢，细品下来有几层意思：
整个集团的架构非常复杂，涉及的域众多，做主架构或者一号位需要大量的协调投入；
不同域之间的资源错配现象严重，需要投入大量精力在锁定资源和推进排期上；
项目结构过于复杂，PM 催主架构，主架构催域架构，域架构催开发，层层订，各种站会，代码没几行，会议一大堆；
现在做的一些项目和产品，技术含量其实是不高的，面条式架构，在架构设计和技术上的投入感觉不多。架构师 PM 化，其实就是脱实向虚的一种表现。
架构师和 PM 其实都是需要对项目的进度和里程碑关心的。不同的是，PM 是用表格和数字关心的进度，是没有任何实体内容的，就是一个死的燃尽图；架构师对进度的把控应该是更 solid 的，背后应该有架构设计和模型拆解做支撑，架构师对进度的把控是对交付物的把控，风险和进展都是有实体内容支撑的。
什么迹象可以表明架构师已经 PM 化或者走在 PM 化的道路上呢？
大量参加各种评审会议和汇报，在架构方案、系分、编码、测试上的产出却越来越少甚至没有。
对于项目的把控在架构层面的减少，在管理层间的增多。喜欢：
拉会过进度；
钉钉催进度；
收集进度向上汇报。
排查问题和定位原因已经不能独立完成，需要拉各种开发同学一起。
甚至于，还拉不对人，要一个拉一个。
碰到资源和进度问题，喜欢从流程上去排期和上升，通过技术手段架构调整解决的少。
一个项目中有两个 PM，而没有架构师的话，对项目进度的把控是很虚的，只是在例会上对各个模块开发的一个进度汇总。模块和模块之间是割裂的，风险也不太容易识别出大小和优先级。
PM 和 PM 之间，一定会产生踩脚，卷就来了。
同时，合格的架构师会越来越少，架构的升级和演变会变得越来越困难。
架构师是一个综合的要求。项目管理只是架构师能力要求的很小一部分。如果 PM 化之后，架构师其他部分的能力在项目过程中就没有办法得到验证和锻炼，对业务的理解力、架构设计能力、架构落地能力、架构管控能力会逐步弱化。最终，变成一个只能做项目的 PM，而失去了做架构师的基础。
一个项目中的主架构如果空心化之后，是没法对开发同学形成有效的指导的。会只关注进度条的走动，而不关注开发质量和风险，一些跨域之间的架构问题可能就会下放到开发同学去讨论和决策，最终是否全局合理全局最优，很难评判。
同时，主架构是项目中开发同学的一个职业模版，一个 PM 化的架构师，会将项目中同学的成长带偏。
架构师 PM 化其实就是架构师的脱实向虚，要杜绝，需要从组织、个人和文化上采用手段。
首先，需要在组织层面将考核体系脱虚向实，更多的看战功看产出。
这个虚其实就是考察形成体系、自洽和表述的能力。
我们是需要一个完美的地心说体系，还是一个有用但还不完善的日心说，值得思考。
架构师需要在每个项目中落到实处去。
架构方案要自己产出；
架构决策一定要做而且要有记录；
最好有编码；
测试要参与测分和执行。
要形成一个氛围，开发同学可以拒绝整天拉会催进度的架构师。
如果一个项目中架构师架构方案和架构决策也不做，可以直接 by pass 他，开发不如自己上。
作为管理者，对于脱实向虚的架构师，要尽早点醒。
如果项目中的架构师 PM 化，所有的问题交流都要拉下面的同学，我们也可以直接 by pass 他们，并且在绩效上反应，让 PM 架构师没有生存的空间。
通过自动化的 pipeline，将协调、沟通、事务性的工作固化在流程中。我们目前的自动化只能 cover 到 CI 这一部分。如果自动化可以 cover 到契约测试、功能测试、回归测试甚至发布，通过 pipeline 就可以驱动事情的推动和可视化，PM 也就自然而然没有啥存在的必要了，反过来可以倒逼架构师回归到本职工作上。
警方通报网传中电科加班事件调查结果；拼多多解散恶意功能团队；逼死程序员诈骗千万的“翟欣欣案”一审宣判 ｜ Q资讯
谷歌正式发布WebGPU！90多位贡献者研发6年，浏览器终于可以利用底层硬件了
4 月 21-22 日，我们即将在上海举办一场 ArchSummit，内容涵盖人工智能前沿技术、AIGC 应用探索、金融业数字化转型探索、架构标准化和质量评估、大数据 + 架构、DataOps 落地实践、ToB 软件质量保障、制造业数字化转型架构创新、架构师成长、以及企业架构演进、数字化转型下的应用现代化、架构稳定性保障等专题。可扫码下方海报了解更多...