两周前我写过一篇名为 演化:这五年里,我们对架构师职责的思考与定位 的文章,在发布后的一周内,居然累计收到几十条的朋友圈评论与后台留言,更是引发某群的激烈争论。面对历史性的话题,引发互怼,这都是人之常情。因为经历不同,视角不同,或者价值观不同,但我觉得挺好,抛一个话题,大家可以讨论讨论,也能实际去尝试,去反思。
在诸多留言中,有不少人提出类似问题:
你说,有架构师则专职负责中间件平台的建设,并挑选出几位不但精于技术领域,还能有跨团队、部门沟通,推进事情能力的架构师担当负责人,对技术落地的进度、风险进行把控……这些事项难道不应该是技术老大去做的事吗?架构师难道不该聚焦技术本身吗?能否就中间件负责人的工作职责深入聊一聊?
我不止一次谈到,在互联网时代下,企业为了将产品迅速推向市场,通常在前期需求不明确时就开始向 IT 部门不断地提出需求,而为了满足业务在效率追求上的永无止境,同时在业务复杂度与用户访问量的双重压力下,我们开始把应用服务拆的更小,功能分得更单一,我们还把技术服务下沉为中间件,功能变得更标准,我们甚至把服务陆续放上 DevOps 平台,使其跑的更快,相互间干扰更少。
微服务也好,中间件也罢,互联网时代一切皆产品,如果你满脑子还一根筋觉得 “架构这玩意该 CTO 强推啊……不靠行政命令强压,架构升级这玩意没法搞啊……”,那恭喜你,你已经被淘汰了。
类似观点,在 演化:这五年里,我们对架构师职责的思考与定位 中我也提到过,比如 2017 年,我们的团队规模达到 200+人,应用系统拆成上百个,功能接口上千个,组织结构按不同功能产品的 FeatureTeam(开发、测试、运维在一个组里,听一个老大的)进行调整。
在这样的客观环境下,每个产品,每个服务,都需要有一个角色站出来思考 “(Who)谁是我的用户,我该如何抓到你?” 的问题,并对规划、设计及研发过程加以控制,最终达成把产品卖出去的目标,而像中间件这种 “重技术渗透,轻用户体验” 的产品,在现有团队中挑选一名架构师承担产品经理的职能,显然是最合适的。
从一名中间件架构师走向一名中间件产品经理,除需具有架构设计、控制质量、技术攻坚与评审等技术核心能力外,还需具备哪些核心能力呢?
1、建立产品标杆(如阿里云),收集行业信息,确定产品发展目标及实施路径。
2、基于业务战略与公司价值观,给出技术实施成本方案。
3、负责产品开发的立项,团队搭建,人员招募,并对实施全权负责。
4、负责产品版本迭代流程标准化的制定、推进、培训与现场指导。
5、负责对产品用户的培训、通知与宣贯。
6、提交产品迭代的运营报告,对当前版本的使用情况进行分析。
这些能力,不仅涵盖了产品经理的职能,甚至项目管理与技术管理的部分职能也包含其中,但这些都无关痛痒。
在过去的一年中,针对中间件产品经理,我们通过定向培养与招聘,逐渐在这条路上摸出一些门路,并通过人才梯队的方式,刻意为每条产品线配备 1-2 名具有一定技术深度,且对技术攻坚有兴趣的高级开发,以弥补中间件产品经理在技术精力投入中的不足。
小结
读到这里,也许有人怒而发问:“你们没有独立的中间件运营,或产品经理专职人员吗?硬给架构师按上这样的工作恐怕不合适吧,你们可以学学阿里或腾讯,设立产品专岗,让专业的人来做专业的事,毕竟术业有专攻嘛。”
您说的很对,以上所述都处于尝试阶段,毕竟阿里是阿里,腾讯是腾讯,无论过去,至少现在的规模、收入都足以支撑「专人专岗,专人专精」的团队模式,对我们来说,至少当下还没这个必要。
反观这些中间件产品经理,一切选择都是自愿的,没人逼他们。
本文转载自头哥侃码公众号。
原文链接:https://mp.weixin.qq.com/s/atH8Z-yASeNBlhjZLJCnEA
评论