做架构师不好么？做什么产品经理

两周前我写过一篇名为 演化：这五年里，我们对架构师职责的思考与定位 的文章，在发布后的一周内，居然累计收到几十条的朋友圈评论与后台留言，更是引发某群的激烈争论。面对历史性的话题，引发互怼，这都是人之常情。因为经历不同，视角不同，或者价值观不同，但我觉得挺好，抛一个话题，大家可以讨论讨论，也能实际去尝试，去反思。

在诸多留言中，有不少人提出类似问题：

你说，有架构师则专职负责中间件平台的建设，并挑选出几位不但精于技术领域，还能有跨团队、部门沟通，推进事情能力的架构师担当负责人，对技术落地的进度、风险进行把控……这些事项难道不应该是技术老大去做的事吗？架构师难道不该聚焦技术本身吗？能否就中间件负责人的工作职责深入聊一聊？

我不止一次谈到，在互联网时代下，企业为了将产品迅速推向市场，通常在前期需求不明确时就开始向 IT 部门不断地提出需求，而为了满足业务在效率追求上的永无止境，同时在业务复杂度与用户访问量的双重压力下，我们开始把应用服务拆的更小，功能分得更单一，我们还把技术服务下沉为中间件，功能变得更标准，我们甚至把服务陆续放上 DevOps 平台，使其跑的更快，相互间干扰更少。

微服务也好，中间件也罢，互联网时代一切皆产品，如果你满脑子还一根筋觉得 “架构这玩意该 CTO 强推啊……不靠行政命令强压，架构升级这玩意没法搞啊……”，那恭喜你，你已经被淘汰了。

类似观点，在 演化：这五年里，我们对架构师职责的思考与定位 中我也提到过，比如 2017 年，我们的团队规模达到 200+人，应用系统拆成上百个，功能接口上千个，组织结构按不同功能产品的 FeatureTeam（开发、测试、运维在一个组里，听一个老大的）进行调整。

在这样的客观环境下，每个产品，每个服务，都需要有一个角色站出来思考 “（Who）谁是我的用户，我该如何抓到你？” 的问题，并对规划、设计及研发过程加以控制，最终达成把产品卖出去的目标，而像中间件这种 “重技术渗透，轻用户体验” 的产品，在现有团队中挑选一名架构师承担产品经理的职能，显然是最合适的。

从一名中间件架构师走向一名中间件产品经理，除需具有架构设计、控制质量、技术攻坚与评审等技术核心能力外，还需具备哪些核心能力呢？

1、建立产品标杆（如阿里云），收集行业信息，确定产品发展目标及实施路径。

2、基于业务战略与公司价值观，给出技术实施成本方案。

3、负责产品开发的立项，团队搭建，人员招募，并对实施全权负责。

4、负责产品版本迭代流程标准化的制定、推进、培训与现场指导。

5、负责对产品用户的培训、通知与宣贯。

6、提交产品迭代的运营报告，对当前版本的使用情况进行分析。

这些能力，不仅涵盖了产品经理的职能，甚至项目管理与技术管理的部分职能也包含其中，但这些都无关痛痒。

在过去的一年中，针对中间件产品经理，我们通过定向培养与招聘，逐渐在这条路上摸出一些门路，并通过人才梯队的方式，刻意为每条产品线配备 1-2 名具有一定技术深度，且对技术攻坚有兴趣的高级开发，以弥补中间件产品经理在技术精力投入中的不足。

小结

读到这里，也许有人怒而发问：“你们没有独立的中间件运营，或产品经理专职人员吗？硬给架构师按上这样的工作恐怕不合适吧，你们可以学学阿里或腾讯，设立产品专岗，让专业的人来做专业的事，毕竟术业有专攻嘛。”

您说的很对，以上所述都处于尝试阶段，毕竟阿里是阿里，腾讯是腾讯，无论过去，至少现在的规模、收入都足以支撑「专人专岗，专人专精」的团队模式，对我们来说，至少当下还没这个必要。

反观这些中间件产品经理，一切选择都是自愿的，没人逼他们。

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/atH8Z-yASeNBlhjZLJCnEA