惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
IT之家
IT之家
Hugging Face - Blog
Hugging Face - Blog
J
Java Code Geeks
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 叶小钗
MyScale Blog
MyScale Blog
G
Google Developers Blog
Microsoft Azure Blog
Microsoft Azure Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
大猫的无限游戏
大猫的无限游戏
博客园 - 三生石上(FineUI控件)
Google DeepMind News
Google DeepMind News
Engineering at Meta
Engineering at Meta
The Cloudflare Blog
Martin Fowler
Martin Fowler
酷 壳 – CoolShell
酷 壳 – CoolShell
N
Netflix TechBlog - Medium
MongoDB | Blog
MongoDB | Blog
I
InfoQ
WordPress大学
WordPress大学
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
H
Help Net Security

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
产品经理该不该设计数据库表?
菜根老谭 · 2023-10-07 · via 人人都是产品经理

并不是所有的产品经理都是懂技术的产品经理,那么让产品经理来设计数据库表,是否合适呢?这篇文章里,作者表达了他的观点,并阐明了观点提出的背后原因,一起来看看吧。

前段时间,读友群里有朋友吐槽产品经理设计表多次给开发挖坑,引起了群内读友的大讨论,产品经理到底该不该设计数据库表?

其实这个问题也不仅仅只有他们公司存在,估计很多公司也存在产品设计数据库表的情况。我曾经接手的项目,就是产品设计数据表,研发根据产品设计数据表创建数据库表开发。我当时感觉到很震惊,还有这么干的?

产品经理很多是不太懂技术的,他们设计数据结构,程序开发同学能用吗?估计也会像上图的朋友所说的,错位处理吧。好无奈啊!

在我负责的技术团队,数据结构的设计是一件非常高层次的工作,一般只有架构师和资深工程师才能参与,我技术评审最核心的内容就是数据库的设计。

所以,我先表达一下自己的观点:产品经理不应该设计数据库表!具体原因,我们接下来分析。

一、表单和表不一样

产品经理做产品设计,不可避免的会涉及到大量的业务表单,对于系统,特别是企业级的系统来说,大部分的业务都是通过业务单据的流转来体现的。

以一个老人的生活状况评估表单为例。

从产品的角度来说,表单不仅是业务数据的体现,而且充满了用户的交互体验,视觉体验,还有数据规则的校验。所以表单是用户视角的元素,是为用户使用系统来处理业务使用的。所以产品经理在数据化表单的时候,一般会向开发呈现如下的数据表说明。

在数据库设计层面,表结构虽然来源于产品设计的表单,但如果完全参考产品经理甚至是产品经理来定义表机构,很容易造成直接将表单翻译成表的情况,如下图:

但实际我们在数据库设计中,数据表和表单并不是完全一致的。

表单的作用是采集数据或者展现业务数据,只需要考虑业务需要即可。而数据库表的作用是存储数据和管理数据的,数据存在查看,新增,更新,删除等操作,在这个过程中要保证避免脏数据、错误数据、重复数据等情况的发生,还要考虑存取数据的性能和效率。

所以数据表设计需要考虑数据库范式,需要适当做数据冗余,需要设计辅助字段等等。

如上图所示,一个老人基础评估表单可能涉及的数据结构,是由三个表组成,甚至更多。而且为了配合程序更好的使用,需要补充一些非业务型的数据字段,如红色部分。为了更好的管理枚举属性的字段内容,还需要引入数据字典。

因为表单和业务关联,所以不同的场景,不同的人群,甚至不同客户的个性化需求,表单内容会随之调整,但是数据结构作为整个应用系统的底层架构,它是需要稳定的,最好是以不变应万变的。

下图数据结构为了扩展性的需求,很有可能将基础评估表里的那些评估内容,抽象成一个通用的数据结构:评估模版表(evalution_form_tpl)、评估问题表(evalution_form_question),从而可以扩展制作各种各样的评估表单。然后用评估表(evalution_form)和评估结果表(evalution_form_reply)来存储评估数据。

表单是具象的,而数据结构是抽象的

这就是自定义问卷的最简单结构!通过这个结构我们就能支持各种各样的评估表的功能,从而可以开发一个适应业务能力更强的系统或者产品。

最后总结一下表单和DB表的区别:

二、跨层兼任不可取

从前文分析我们也知道,表单不同于DB表,产品经理设计更多的是表单,而不是表。但是为什么还是有很多公司,让产品经理来负责设计表呢?

粗略分析,有以下几个原因:

  1. 产品或者系统中的表单反应了业务的数据结构,产品经理直接以此确定数据结构,不用做两遍工作,比较高效。
  2. 产品人员具备一定的技术背景,能同时兼任产品和数据结构设计工作,合一起做,提升效率,节约成本。
  3. 企业对于产品经理的职责定位不清晰导致,赋予的职责范围过大。

首先,我们先来分析,产品经理做DB表设计是不是本职工作。我们还是从一个产品或者系统的组成来看:

从这个分层结构上来看,产品经理的主要本职工作处在这个分层结构的第一层,有更具象的功能模块组成。而数据建模层要在倒数第二层,和产品功能层相差较远,显然应用表现层上的主要内容才是产品经理更加核心,更本职的工作内容。

为什么数据建模层不能成为产品经理的核心本职工作?我们都知道在企业里一般都有兼任的情况,第一是领导兼任下一级岗位的,第二是平级岗位间兼任的,很少出现跨级兼任的情况!

每个相邻层级之间,因为相互依赖,相互支持,对对方领域会更有了解和理解。相邻层级里兼任部分工作,从工作关联度上来说和专业度上来说,都更比跨级领域要高。所以,如果数据建模没有专门的人和团队负责,交给相邻层的技术团队也许会更加合适。

就像前文的那个数据结构,技术团队可以融合技术选型,比如可以采用MongoDB作为评估表存储,用redis缓存xx数据,应用支撑层的相关技术的使用,这些都会影响数据建模层的设计。所以数据建模需要依赖下层数据层的技术选型,需要充分考虑上层应用支撑层的技术实现,这些都是绝大多数产品经理都无法胜任的。

而对于技术出身的产品经理,像老谭这样从开发到架构都做过的产品人员,做点数据建模是完全可以胜任的。但是不是胜任就要去做的,我们要明确自己角色的转换,我现在是一名产品经理,我的工作和精力要更贴合业务,更贴合用户,而不是考虑技术实现。

更何况,我们不再做技术,很难深入技术细节,跟不上最新的技术趋势,我们设计的DB表很难思考全面,照顾周全,所以可以参与讨论,但不能具体负责。

综上所述,产品经理跨层负责DB表设计,我认为并不是非常合理的选择!你觉得呢?

专栏作家

菜根老谭,微信公众号:CGLT_TAN,人人都是产品经理专栏作家。经历程序员、技术Leader、产品经理、研发Leader等多种岗位。现负责某科技公司整体产品研发,擅长企业IT架构及互联网产品架构。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议.

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。