前情提要：转型的一年时间里，我在做着怎样的工作
过去两年多的时间里，我差不多70%的时间是在做数据库产品经理，剩下30%在做测试相关的东西。回顾这两年的职业经历，有些事让人忍俊不禁，诸如“当初我怎么会这么想”，“这事竟然是这么结束的”，“会不会有一个更好的方案”。每每想到这些，又有一个新的问题在我脑中冒出来——数据库真的需要产品经理吗？
数据库产品经理的职责
既然要讨论数据库是否真的需要产品经理，那就要先确定一件事情，数据库产品经理到底是干什么的。根据chatGPT的回答，有这么几个：
1. 产品策略
2. 需求分析
3. 产品规划和设计
4. 项目管理
5. 市场推广和销售支持
6. 用户反馈和改进
7. 竞争分析
8. 技术支持和培训
从这些职责列表来看，一个人想要胜任数据库产品经理，确实是要求很高，既要了解数据库发展的趋势又能做出符合自身的判断，又要了解数据库的底层原理和功能，还要有足够的表达沟通能力，这一连串的要求，我相信很多人没有办法完全兼顾，最终以团队的方式取长补短。当然，我相信在这个行业，经过长期的磨合锻炼，是有可能有高人把这8项都贯通，人外有人，山外有山。保持敬畏，承认自己的狭隘和愚蠢，是我踏足一个新岗位不断告诫自己的事情。
而我在上家公司的分工里，日常做得比较多的是2、3、4、8，其他几项有所涉及，但自认为比例不高。这样的分工是因为我过往的个人经历所致，DBA背景对数据库的使用和后期运维相对了解多一点，加上自己对数据库功能的理解，能够去上手做。但是作为一个常年在甲方工作的人，5、6、7是我的短板，尝试过也做不来；1之前是公司决策层做的事，我无权置喙。
数据库产品经理的可替代性
职责划分完了，那么就回到了标题，到底需不需要产品经理这个岗位，又或者说，这个岗位有没有什么可替代性，能不能把一些职责分散出去，让不同部门不同岗位的人来做？还是先从我个人之前的四个职责开始逐个讨论，从我个人的经历为切入点。
需求分析，这个是很多公司产品部门最重要的工作内容。从客户、从社区用户、从公司内部甚至从产品经理本人这里收集来的需求，都要做分析并且和数据库的使用做对应。这项工作既要理解为什么会有这些需求，又要明白该怎么去拆解这些需求，最终转化成数据库的东西。这些都需要对数据库的基本原理和使用有足够的积累和认知。
产品规划和设计，数据库作为一个基础软件，和业务软件最大的区别在于，对产品的稳定性以及性能有非常高的要求。而且在很多功能点，都有着互相的关联和依赖，在实际规划和设计中，永远存在着计划赶不上变化以及开发中的重大调整。甚至有时候，做好的功能在论证之后，都要干掉重来。这一点上，既要了解开发，又要了解数据库的原理，有时候颇让我力不从心。
项目管理，实际上任何一个功能的设计和开发、需求的排期和验收，都是项目管理的一个环节。区别在于，这里面管理的粒度和参与度。由于没做过开发，实际项目管理中，我能做的不多，一方面是去协调一些东西，另一方面是对开发过程中遇到的各类问题，尽量找到一个平衡点，能够让诸方有一个都能接受的结果。
技术支持和培训，在过去两年的时间里，这一项我确实是做了不少。很多同事在这之前没有系统学习过数据库的体系结构，通过录制课程的方式，帮助大家解惑，也成为了我给自己定的绩效之一。而开发过程中遇到的各类不确定的东西，需要去深入调研其他数据库技术的时候，也是我义不容辞的责任。
那么，这几样东西，其他岗位的同事可以替代吗？我的观点是，可以。但是建立在对数据库有着深度了解的基础上。
例如产品规划和设计，如果是一味资深的数据库开发者，实际上是可以通过过往的开发经验以及对数据库的理解，去做好设计和规划，而且更重要的是，因为了解开发的难点，实际上比起单纯做产品管理的人对工作量的评估更加精确，这也是我个人的经验之谈。
反过来说，哪些东西不能被替代？可能要从5、6、7三个点来入手。市场和销售的思维，有时候与产品设计和研发是反过来的。作为数据库产品经理，我不喜欢浮夸的描述，我相信很多研发也有类似的想法。然而市场和销售，有时候就要适度的夸大其辞，才能吸引眼球，获得更的机会。竞争、用户反馈和改进，也是需要立足于整个产品做出判断和思考。这些东西的岗位替代性就没有那么强，无论是市场、研发还是售前支持，所获得的信息都是有限的，反倒是产品组的信息最全面。
所以经过这一趴论证，我的结论是，无法实现完全的替代，但是如果有足够的人才储备，是可以大幅减少产品经理的编制和工作量的。
到底要不要数据库产品经理
先说结论，要，但是要界定好权限。数据库账号需要权限，而数据库中的权限是对现实世界的抽象。既然在数据库中需要位每个用户和角色限定权限，那么实际工作中，对每个岗位也需要界定好权限。
数据库作为基础软件，既有具体功能的开发，又有架构的设计。而每个公司的功能开发和架构设计的分工又不尽相同。比如我上家公司，架构设计是CTO主导的，理论上具体功能的设计应该以产品部门为主导。但是实际操作就是另一个故事了。
所以仔细回想这2年的经历，从一开始CTO和产品经理的分工就需要明确界定好，谁有什么样的权限从一开始就要明确。红线在哪，哪些不能轻易动摇，都是需要提前定下来，以后实际开发过程中，严格执行。即便有时候大家有分歧或者对对方的工作内容有想要参与的想法，也要与对方沟通后来进行。也就是我们俗称的先小人，后君子。
否则的话，大概率会出现两种情况：
产品经理干涉开发，如果这个产品经理有过开发经验还好，如果没有就会对开发的进度和实现方式产生干扰。一线的研发同事有时候面临的是两难的境地，到底听谁的，会让他们很困惑，影响开发进度和实现。
CTO干涉功能设计，每个阶段产品经理可能已经定下了范围和未来一段的规划，如果CTO绕过产品经理，直接给研发下发新的功能设计任务，同样也会影响一线研发的工作，并且很可能出现孤立的某个功能放在整个产品中格格不入。
据我所知，这类型事情在很多软件企业都有过类似的情况，在数据库一个注重稳定的领域，开发节奏的稳定、人员分工的稳定、工作环境的稳定，同样十分重要。橘生淮南则为橘，生于淮北则为枳，这也就是很多人和团队，离开了某个环境就大相径庭的原因。一切东西都是有自己匹配的土壤。
仍然还是习惯在文章结尾再来一句，这些东西都是基于我的主观经历和判断，不具备普遍代表性，如果你的经历和感想与我有着不同，还请指正。
