如何防止架构师PM化 - 阿里技术
本文从什么是架构师PM化、架构师PM化的特点、危害等方面讲述如何防止架构师PM化。
引言:什么是架构师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也就自然而然没有啥存在的必要了,反过来可以倒逼架构师回归到本职工作上。