产品经理该不该设计数据库表?
并不是所有的产品经理都是懂技术的产品经理,那么让产品经理来设计数据库表,是否合适呢?这篇文章里,作者表达了他的观点,并阐明了观点提出的背后原因,一起来看看吧。
前段时间,读友群里有朋友吐槽产品经理设计表多次给开发挖坑,引起了群内读友的大讨论,产品经理到底该不该设计数据库表?
其实这个问题也不仅仅只有他们公司存在,估计很多公司也存在产品设计数据库表的情况。我曾经接手的项目,就是产品设计数据表,研发根据产品设计数据表创建数据库表开发。我当时感觉到很震惊,还有这么干的?
产品经理很多是不太懂技术的,他们设计数据结构,程序开发同学能用吗?估计也会像上图的朋友所说的,错位处理吧。好无奈啊!
在我负责的技术团队,数据结构的设计是一件非常高层次的工作,一般只有架构师和资深工程师才能参与,我技术评审最核心的内容就是数据库的设计。
所以,我先表达一下自己的观点:产品经理不应该设计数据库表!具体原因,我们接下来分析。
一、表单和表不一样
产品经理做产品设计,不可避免的会涉及到大量的业务表单,对于系统,特别是企业级的系统来说,大部分的业务都是通过业务单据的流转来体现的。
以一个老人的生活状况评估表单为例。
从产品的角度来说,表单不仅是业务数据的体现,而且充满了用户的交互体验,视觉体验,还有数据规则的校验。所以表单是用户视角的元素,是为用户使用系统来处理业务使用的。所以产品经理在数据化表单的时候,一般会向开发呈现如下的数据表说明。
在数据库设计层面,表结构虽然来源于产品设计的表单,但如果完全参考产品经理甚至是产品经理来定义表机构,很容易造成直接将表单翻译成表的情况,如下图:
但实际我们在数据库设计中,数据表和表单并不是完全一致的。
表单的作用是采集数据或者展现业务数据,只需要考虑业务需要即可。而数据库表的作用是存储数据和管理数据的,数据存在查看,新增,更新,删除等操作,在这个过程中要保证避免脏数据、错误数据、重复数据等情况的发生,还要考虑存取数据的性能和效率。
所以数据表设计需要考虑数据库范式,需要适当做数据冗余,需要设计辅助字段等等。
如上图所示,一个老人基础评估表单可能涉及的数据结构,是由三个表组成,甚至更多。而且为了配合程序更好的使用,需要补充一些非业务型的数据字段,如红色部分。为了更好的管理枚举属性的字段内容,还需要引入数据字典。
因为表单和业务关联,所以不同的场景,不同的人群,甚至不同客户的个性化需求,表单内容会随之调整,但是数据结构作为整个应用系统的底层架构,它是需要稳定的,最好是以不变应万变的。
下图数据结构为了扩展性的需求,很有可能将基础评估表里的那些评估内容,抽象成一个通用的数据结构:评估模版表(evalution_form_tpl)、评估问题表(evalution_form_question),从而可以扩展制作各种各样的评估表单。然后用评估表(evalution_form)和评估结果表(evalution_form_reply)来存储评估数据。
表单是具象的,而数据结构是抽象的!
这就是自定义问卷的最简单结构!通过这个结构我们就能支持各种各样的评估表的功能,从而可以开发一个适应业务能力更强的系统或者产品。
最后总结一下表单和DB表的区别:
二、跨层兼任不可取
从前文分析我们也知道,表单不同于DB表,产品经理设计更多的是表单,而不是表。但是为什么还是有很多公司,让产品经理来负责设计表呢?
粗略分析,有以下几个原因:
- 产品或者系统中的表单反应了业务的数据结构,产品经理直接以此确定数据结构,不用做两遍工作,比较高效。
- 产品人员具备一定的技术背景,能同时兼任产品和数据结构设计工作,合一起做,提升效率,节约成本。
- 企业对于产品经理的职责定位不清晰导致,赋予的职责范围过大。
首先,我们先来分析,产品经理做DB表设计是不是本职工作。我们还是从一个产品或者系统的组成来看:
从这个分层结构上来看,产品经理的主要本职工作处在这个分层结构的第一层,有更具象的功能模块组成。而数据建模层要在倒数第二层,和产品功能层相差较远,显然应用表现层上的主要内容才是产品经理更加核心,更本职的工作内容。
为什么数据建模层不能成为产品经理的核心本职工作?我们都知道在企业里一般都有兼任的情况,第一是领导兼任下一级岗位的,第二是平级岗位间兼任的,很少出现跨级兼任的情况!
每个相邻层级之间,因为相互依赖,相互支持,对对方领域会更有了解和理解。相邻层级里兼任部分工作,从工作关联度上来说和专业度上来说,都更比跨级领域要高。所以,如果数据建模没有专门的人和团队负责,交给相邻层的技术团队也许会更加合适。
就像前文的那个数据结构,技术团队可以融合技术选型,比如可以采用MongoDB作为评估表存储,用redis缓存xx数据,应用支撑层的相关技术的使用,这些都会影响数据建模层的设计。所以数据建模需要依赖下层数据层的技术选型,需要充分考虑上层应用支撑层的技术实现,这些都是绝大多数产品经理都无法胜任的。
而对于技术出身的产品经理,像老谭这样从开发到架构都做过的产品人员,做点数据建模是完全可以胜任的。但是不是胜任就要去做的,我们要明确自己角色的转换,我现在是一名产品经理,我的工作和精力要更贴合业务,更贴合用户,而不是考虑技术实现。
更何况,我们不再做技术,很难深入技术细节,跟不上最新的技术趋势,我们设计的DB表很难思考全面,照顾周全,所以可以参与讨论,但不能具体负责。
综上所述,产品经理跨层负责DB表设计,我认为并不是非常合理的选择!你觉得呢?
专栏作家
菜根老谭,微信公众号:CGLT_TAN,人人都是产品经理专栏作家。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。现负责某科技公司整体产品研发,擅长企业IT架构及互联网产品架构。
本文原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议.
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
除非产品懂数据库原理,做出最优表结构。
我遇到过一种情况是需要产品经理直接设计数据库表的,那就是开发人员只会按原型的字段来设计,不考虑任何抽象,冗余或者通用的逻辑合并等,这种情况我一般就直接抽象好给到他们
这种情况应该是给技术团队补充一名擅长架构设计的人,而不是职责转移。产品经理都可以抽象设计了,技术人员还不行,只能说技术太拉胯了。
这种情况通常都是因为领导是技术出身,就要求产品经理懂点他们觉得很简单的东西。在这些领导收下干活的产品经理很悲催。
诚然,产品懂用UML梳理数据结构,表达数据之间的关系就行,其他的交给技术即可。
产品不需要设计表结构,但是要懂;开发设计的表结构,产品要参加开发设计评审一起看,尤其是后台重逻辑型产品。
术业有专攻,产品经理设计数据库表确实不太合适,后期容易和开发扯皮,反而增加与开发的沟通成本。这篇文章让我了解了数据库表,不是按照原型设计的表单而建立的表,而是建立的数据结构会有多张表来支撑,稳定还有扩展性。
产品小白,运营转过来的,纯个人观点哈,涉及数据表结构的时候我以为理论上来讲我不需要过多介入,毕竟数据是产品的根本,从研发的角度来讲会更明白把数据如何处理更利于使用,不过我们人不多,大家都是集思广益,研发思考的时候偶尔会问我的意见,我一般思考的角度是,数据的存储是否是否方便做清洗、是否利于使用、如果业务场景等因素有变化的数据是否可以再加工,新增和删除是否容易因关联逻辑复杂产生其他连锁反应。关联逻辑复杂这种情况我觉得在产品迭代过程中(也许?)是一种不可避免的现象,所以我比较偏向于前三个角度,数据库结构更偏向于逻辑精简也就是尽可能原始做基础数据,有需要再建其他业务表,设计时宁愿多做列也不要为了图方便直接按业务字段“组装”好,想也知道后续会很不利于拆分(那时候考虑后续想做用户行为的标签分析,有业务同事觉得图方便直接每次行为的一堆标签存进去展现出来只做记录,后续迭代再做分析,当时就觉得这种情况操作起来不见得便捷,因为产品初期哪怕按标签类型分开存储再组装其实数据量不会很大还支撑的住,相较于直接堆积在一起存储麻烦点但不复杂,如果有新的标签类型后边再加列,业务字段逻辑调整不大,就我们当时的业务需要,二者相较来说从工作量上差异不算巨大;而从后续迭代的角度来讲,每一堆数据可能都是无序的,长度不一,难做拆解和清洗,到时候还是要经历一遍重建的过程,相当于费了两遍劲,没必要,最后还是觉得拆开来存方便)。
不好意思稍微跑题了,打小孩子作文儿就不好,先不说我这个思考角度对不对,想说就参与深度而言,产品可以参与,但不能完全拍板,一定要有开发一起参与(不是为了分锅,有锅我从来都是自己的问题自己主动认,反正我一个女的豁出脸来怎么的也不至于被收拾太惨,纯是这方面更信任同事的专业度),所谓术业有专攻,每个产品的诞生不同的部分大家的专业度有差异,如果可以,我个人比较喜欢开发有自己的想法,根据业务逻辑做更清晰的处理,业务逻辑不清晰的部分协同产品来做梳理,想问我的随便问,真的有几次他们问的问题正是因为我的“逻辑含糊”才需要和我明确的,想当然是大忌,正好方便我进一步梳理。
数据这部分工作,更侧重于研发,还是专业的人做专业的事。
说的很好,受用了