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