如何防止架构师PM化

一、什么是架构师PM化

和一些做项目主架构或者一号位的同学聊天，经常会听到一种说法：项目主架构做着做着就会做成PM。这背后什么含义呢，细品下来有几层意思：

• 整个集团的架构非常复杂，涉及的域众多，做主架构或者一号位需要大量的协调投入；

• 不同域之间的资源错配现象严重，需要投入大量精力在锁定资源和推进排期上；

• 项目结构过于复杂，PM催主架构，主架构催域架构，域架构催开发，层层订，各种站会，代码没几行，会议一大堆；

• 现在做的一些项目和产品，技术含量其实是不高的，面条式架构，在架构设计和技术上的投入感觉不多。

 架构师PM化，其实就是脱实向虚的一种表现。

架构师和PM其实都是需要对项目的进度和里程碑关心的。

不同的是，PM是用表格和数字关心的进度，是没有任何实体内容的，就是一个死的燃尽图；架构师对进度的把控应该是更solid的，背后应该有架构设计和模型拆解做支撑，架构师对进度的把控是对交付物的把控，风险和进展都是有实体内容支撑的。

二、架构师PM化的特点

什么迹象可以表明架构师已经PM化或者走在PM化的道路上呢？

大量参加各种评审会议和汇报，在架构方案、系分、编码、测试上的产出却越来越少甚至没有。

对于项目的把控在架构层面的减少，在管理层间的增多。喜欢：

• 拉会过进度；

• 钉钉催进度；

• 收集进度向上汇报。

排查问题和定位原因已经不能独立完成，需要拉各种开发同学一起。甚至于，还拉不对人，要一个拉一个。

碰到资源和进度问题，喜欢从流程上去排期和上升，通过技术手段架构调整解决的少。

三、架构师PM化的危害

一个项目中有两个PM，而没有架构师的话，对项目进度的把控是很虚的，只是在例会上对各个模块开发的一个进度汇总。

模块和模块之间是割裂的，风险也不太容易识别出大小和优先级。

PM和PM之间，一定会产生踩脚，卷就来了。

同时，合格的架构师会越来越少，架构的升级和演变会变得越来越困难。

架构师是一个综合的要求。项目管理只是架构师能力要求的很小一部分。

如果PM化之后，架构师其他部分的能力在项目过程中就没有办法得到验证和锻炼，对业务的理解力、架构设计能力、架构落地能力、架构管控能力会逐步弱化。

最终，变成一个只能做项目的PM，而失去了做架构师的基础。

一个项目中的主架构如果空心化之后，是没法对开发同学形成有效的指导的。

会只关注进度条的走动，而不关注开发质量和风险，一些跨域之间的架构问题可能就会下放到开发同学去讨论和决策，最终是否全局合理全局最优，很难评判。

同时，主架构是项目中开发同学的一个职业模版，一个PM化的架构师，会将项目中同学的成长带偏。

四、如何防止架构师PM化

架构师PM化其实就是架构师的脱实向虚，要杜绝，需要从组织、个人和文化上采用手段。

首先，需要在组织层面将考核体系脱虚向实，更多的看战功看产出。

这个虚其实就是考察形成体系、自洽和表述的能力。

我们是需要一个完美的地心说体系，还是一个有用但还不完善的日心说，值得思考。

架构师需要在每个项目中落到实处去。

• 架构方案要自己产出；

• 架构决策一定要做而且要有记录；

• 最好有编码；

• 测试要参与测分和执行。

要形成一个氛围，开发同学可以拒绝整天拉会催进度的架构师。

如果一个项目中架构师架构方案和架构决策也不做，可以直接by pass他，开发不如自己上。

作为管理者，对于脱实向虚的架构师，要尽早点醒。

如果项目中的架构师PM化，所有的问题交流都要拉下面的同学，我们也可以直接by pass他们，并且在绩效上反应，让PM架构师没有生存的空间。

通过自动化的pipeline，将协调、沟通、事务性的工作固化在流程中。我们目前的自动化只能cover到CI这一部分。

如果自动化可以cover到契约测试、功能测试、回归测试甚至发布，通过pipeline就可以驱动事情的推动和可视化，PM也就自然而然没有啥存在的必要了，反过来可以倒逼架构师回归到本职工作上。