起點(diǎn)課堂會(huì)員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會(huì)特權(quán)
個(gè)人IP打造特權(quán)
30+門專項(xiàng)技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會(huì)員專屬社群
榮耀標(biāo)識(shí)產(chǎn)品經(jīng)理該不該設(shè)計(jì)數(shù)據(jù)庫表？
并不是所有的產(chǎn)品經(jīng)理都是懂技術(shù)的產(chǎn)品經(jīng)理，那么讓產(chǎn)品經(jīng)理來設(shè)計(jì)數(shù)據(jù)庫表，是否合適呢？這篇文章里，作者表達(dá)了他的觀點(diǎn)，并闡明了觀點(diǎn)提出的背后原因，一起來看看吧。
前段時(shí)間，讀友群里有朋友吐槽產(chǎn)品經(jīng)理設(shè)計(jì)表多次給開發(fā)挖坑，引起了群內(nèi)讀友的大討論，產(chǎn)品經(jīng)理到底該不該設(shè)計(jì)數(shù)據(jù)庫表？
其實(shí)這個(gè)問題也不僅僅只有他們公司存在，估計(jì)很多公司也存在產(chǎn)品設(shè)計(jì)數(shù)據(jù)庫表的情況。我曾經(jīng)接手的項(xiàng)目，就是產(chǎn)品設(shè)計(jì)數(shù)據(jù)表，研發(fā)根據(jù)產(chǎn)品設(shè)計(jì)數(shù)據(jù)表創(chuàng)建數(shù)據(jù)庫表開發(fā)。我當(dāng)時(shí)感覺到很震驚，還有這么干的？
產(chǎn)品經(jīng)理很多是不太懂技術(shù)的，他們?cè)O(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)，程序開發(fā)同學(xué)能用嗎？估計(jì)也會(huì)像上圖的朋友所說的，錯(cuò)位處理吧。好無奈啊！
在我負(fù)責(zé)的技術(shù)團(tuán)隊(duì)，數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)是一件非常高層次的工作，一般只有架構(gòu)師和資深工程師才能參與，我技術(shù)評(píng)審最核心的內(nèi)容就是數(shù)據(jù)庫的設(shè)計(jì)。
所以，我先表達(dá)一下自己的觀點(diǎn)：產(chǎn)品經(jīng)理不應(yīng)該設(shè)計(jì)數(shù)據(jù)庫表！具體原因，我們接下來分析。
一、表單和表不一樣
產(chǎn)品經(jīng)理做產(chǎn)品設(shè)計(jì)，不可避免的會(huì)涉及到大量的業(yè)務(wù)表單，對(duì)于系統(tǒng)，特別是企業(yè)級(jí)的系統(tǒng)來說，大部分的業(yè)務(wù)都是通過業(yè)務(wù)單據(jù)的流轉(zhuǎn)來體現(xiàn)的。
以一個(gè)老人的生活狀況評(píng)估表單為例。
從產(chǎn)品的角度來說，表單不僅是業(yè)務(wù)數(shù)據(jù)的體現(xiàn)，而且充滿了用戶的交互體驗(yàn)，視覺體驗(yàn)，還有數(shù)據(jù)規(guī)則的校驗(yàn)。所以表單是用戶視角的元素，是為用戶使用系統(tǒng)來處理業(yè)務(wù)使用的。所以產(chǎn)品經(jīng)理在數(shù)據(jù)化表單的時(shí)候，一般會(huì)向開發(fā)呈現(xiàn)如下的數(shù)據(jù)表說明。
在數(shù)據(jù)庫設(shè)計(jì)層面，表結(jié)構(gòu)雖然來源于產(chǎn)品設(shè)計(jì)的表單，但如果完全參考產(chǎn)品經(jīng)理甚至是產(chǎn)品經(jīng)理來定義表機(jī)構(gòu)，很容易造成直接將表單翻譯成表的情況，如下圖：
但實(shí)際我們?cè)跀?shù)據(jù)庫設(shè)計(jì)中，數(shù)據(jù)表和表單并不是完全一致的。
表單的作用是采集數(shù)據(jù)或者展現(xiàn)業(yè)務(wù)數(shù)據(jù)，只需要考慮業(yè)務(wù)需要即可。而數(shù)據(jù)庫表的作用是存儲(chǔ)數(shù)據(jù)和管理數(shù)據(jù)的，數(shù)據(jù)存在查看，新增，更新，刪除等操作，在這個(gè)過程中要保證避免臟數(shù)據(jù)、錯(cuò)誤數(shù)據(jù)、重復(fù)數(shù)據(jù)等情況的發(fā)生，還要考慮存取數(shù)據(jù)的性能和效率。
所以數(shù)據(jù)表設(shè)計(jì)需要考慮數(shù)據(jù)庫范式，需要適當(dāng)做數(shù)據(jù)冗余，需要設(shè)計(jì)輔助字段等等。
如上圖所示，一個(gè)老人基礎(chǔ)評(píng)估表單可能涉及的數(shù)據(jù)結(jié)構(gòu)，是由三個(gè)表組成，甚至更多。而且為了配合程序更好的使用，需要補(bǔ)充一些非業(yè)務(wù)型的數(shù)據(jù)字段，如紅色部分。為了更好的管理枚舉屬性的字段內(nèi)容，還需要引入數(shù)據(jù)字典。
因?yàn)楸韱魏蜆I(yè)務(wù)關(guān)聯(lián)，所以不同的場景，不同的人群，甚至不同客戶的個(gè)性化需求，表單內(nèi)容會(huì)隨之調(diào)整，但是數(shù)據(jù)結(jié)構(gòu)作為整個(gè)應(yīng)用系統(tǒng)的底層架構(gòu)，它是需要穩(wěn)定的，最好是以不變應(yīng)萬變的。
下圖數(shù)據(jù)結(jié)構(gòu)為了擴(kuò)展性的需求，很有可能將基礎(chǔ)評(píng)估表里的那些評(píng)估內(nèi)容，抽象成一個(gè)通用的數(shù)據(jù)結(jié)構(gòu)：評(píng)估模版表（evalution_form_tpl）、評(píng)估問題表（evalution_form_question），從而可以擴(kuò)展制作各種各樣的評(píng)估表單。然后用評(píng)估表（evalution_form）和評(píng)估結(jié)果表（evalution_form_reply）來存儲(chǔ)評(píng)估數(shù)據(jù)。
表單是具象的，而數(shù)據(jù)結(jié)構(gòu)是抽象的！
這就是自定義問卷的最簡單結(jié)構(gòu)！通過這個(gè)結(jié)構(gòu)我們就能支持各種各樣的評(píng)估表的功能，從而可以開發(fā)一個(gè)適應(yīng)業(yè)務(wù)能力更強(qiáng)的系統(tǒng)或者產(chǎn)品。
最后總結(jié)一下表單和DB表的區(qū)別：
二、跨層兼任不可取
從前文分析我們也知道，表單不同于DB表，產(chǎn)品經(jīng)理設(shè)計(jì)更多的是表單，而不是表。但是為什么還是有很多公司，讓產(chǎn)品經(jīng)理來負(fù)責(zé)設(shè)計(jì)表呢？
粗略分析，有以下幾個(gè)原因：
- 產(chǎn)品或者系統(tǒng)中的表單反應(yīng)了業(yè)務(wù)的數(shù)據(jù)結(jié)構(gòu)，產(chǎn)品經(jīng)理直接以此確定數(shù)據(jù)結(jié)構(gòu)，不用做兩遍工作，比較高效。
- 產(chǎn)品人員具備一定的技術(shù)背景，能同時(shí)兼任產(chǎn)品和數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)工作，合一起做，提升效率，節(jié)約成本。
- 企業(yè)對(duì)于產(chǎn)品經(jīng)理的職責(zé)定位不清晰導(dǎo)致，賦予的職責(zé)范圍過大。
首先，我們先來分析，產(chǎn)品經(jīng)理做DB表設(shè)計(jì)是不是本職工作。我們還是從一個(gè)產(chǎn)品或者系統(tǒng)的組成來看：
從這個(gè)分層結(jié)構(gòu)上來看，產(chǎn)品經(jīng)理的主要本職工作處在這個(gè)分層結(jié)構(gòu)的第一層，有更具象的功能模塊組成。而數(shù)據(jù)建模層要在倒數(shù)第二層，和產(chǎn)品功能層相差較遠(yuǎn)，顯然應(yīng)用表現(xiàn)層上的主要內(nèi)容才是產(chǎn)品經(jīng)理更加核心，更本職的工作內(nèi)容。
為什么數(shù)據(jù)建模層不能成為產(chǎn)品經(jīng)理的核心本職工作？我們都知道在企業(yè)里一般都有兼任的情況，第一是領(lǐng)導(dǎo)兼任下一級(jí)崗位的，第二是平級(jí)崗位間兼任的，很少出現(xiàn)跨級(jí)兼任的情況！
每個(gè)相鄰層級(jí)之間，因?yàn)橄嗷ヒ蕾?，相互支持，?duì)對(duì)方領(lǐng)域會(huì)更有了解和理解。相鄰層級(jí)里兼任部分工作，從工作關(guān)聯(lián)度上來說和專業(yè)度上來說，都更比跨級(jí)領(lǐng)域要高。所以，如果數(shù)據(jù)建模沒有專門的人和團(tuán)隊(duì)負(fù)責(zé)，交給相鄰層的技術(shù)團(tuán)隊(duì)也許會(huì)更加合適。
就像前文的那個(gè)數(shù)據(jù)結(jié)構(gòu)，技術(shù)團(tuán)隊(duì)可以融合技術(shù)選型，比如可以采用MongoDB作為評(píng)估表存儲(chǔ)，用redis緩存xx數(shù)據(jù)，應(yīng)用支撐層的相關(guān)技術(shù)的使用，這些都會(huì)影響數(shù)據(jù)建模層的設(shè)計(jì)。所以數(shù)據(jù)建模需要依賴下層數(shù)據(jù)層的技術(shù)選型，需要充分考慮上層應(yīng)用支撐層的技術(shù)實(shí)現(xiàn)，這些都是絕大多數(shù)產(chǎn)品經(jīng)理都無法勝任的。
而對(duì)于技術(shù)出身的產(chǎn)品經(jīng)理，像老譚這樣從開發(fā)到架構(gòu)都做過的產(chǎn)品人員，做點(diǎn)數(shù)據(jù)建模是完全可以勝任的。但是不是勝任就要去做的，我們要明確自己角色的轉(zhuǎn)換，我現(xiàn)在是一名產(chǎn)品經(jīng)理，我的工作和精力要更貼合業(yè)務(wù)，更貼合用戶，而不是考慮技術(shù)實(shí)現(xiàn)。
更何況，我們不再做技術(shù)，很難深入技術(shù)細(xì)節(jié)，跟不上最新的技術(shù)趨勢，我們?cè)O(shè)計(jì)的DB表很難思考全面，照顧周全，所以可以參與討論，但不能具體負(fù)責(zé)。
綜上所述，產(chǎn)品經(jīng)理跨層負(fù)責(zé)DB表設(shè)計(jì)，我認(rèn)為并不是非常合理的選擇！你覺得呢？
專欄作家
菜根老譚，微信公眾號(hào)：CGLT_TAN，人人都是產(chǎn)品經(jīng)理專欄作家。經(jīng)歷程序員、技術(shù)Leader、產(chǎn)品經(jīng)理、研發(fā)Leader等多種崗位。現(xiàn)負(fù)責(zé)某科技公司整體產(chǎn)品研發(fā)，擅長企業(yè)IT架構(gòu)及互聯(lián)網(wǎng)產(chǎn)品架構(gòu)。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載
題圖來自Unsplash，基于CC0協(xié)議.
該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。
除非產(chǎn)品懂?dāng)?shù)據(jù)庫原理，做出最優(yōu)表結(jié)構(gòu)。
我遇到過一種情況是需要產(chǎn)品經(jīng)理直接設(shè)計(jì)數(shù)據(jù)庫表的，那就是開發(fā)人員只會(huì)按原型的字段來設(shè)計(jì)，不考慮任何抽象，冗余或者通用的邏輯合并等，這種情況我一般就直接抽象好給到他們
這種情況應(yīng)該是給技術(shù)團(tuán)隊(duì)補(bǔ)充一名擅長架構(gòu)設(shè)計(jì)的人，而不是職責(zé)轉(zhuǎn)移。產(chǎn)品經(jīng)理都可以抽象設(shè)計(jì)了，技術(shù)人員還不行，只能說技術(shù)太拉胯了。
這種情況通常都是因?yàn)轭I(lǐng)導(dǎo)是技術(shù)出身，就要求產(chǎn)品經(jīng)理懂點(diǎn)他們覺得很簡單的東西。在這些領(lǐng)導(dǎo)收下干活的產(chǎn)品經(jīng)理很悲催。
誠然，產(chǎn)品懂用UML梳理數(shù)據(jù)結(jié)構(gòu)，表達(dá)數(shù)據(jù)之間的關(guān)系就行，其他的交給技術(shù)即可。
產(chǎn)品不需要設(shè)計(jì)表結(jié)構(gòu)，但是要懂；開發(fā)設(shè)計(jì)的表結(jié)構(gòu)，產(chǎn)品要參加開發(fā)設(shè)計(jì)評(píng)審一起看，尤其是后臺(tái)重邏輯型產(chǎn)品。
術(shù)業(yè)有專攻，產(chǎn)品經(jīng)理設(shè)計(jì)數(shù)據(jù)庫表確實(shí)不太合適，后期容易和開發(fā)扯皮，反而增加與開發(fā)的溝通成本。這篇文章讓我了解了數(shù)據(jù)庫表，不是按照原型設(shè)計(jì)的表單而建立的表，而是建立的數(shù)據(jù)結(jié)構(gòu)會(huì)有多張表來支撐，穩(wěn)定還有擴(kuò)展性。
產(chǎn)品小白，運(yùn)營轉(zhuǎn)過來的，純個(gè)人觀點(diǎn)哈，涉及數(shù)據(jù)表結(jié)構(gòu)的時(shí)候我以為理論上來講我不需要過多介入，畢竟數(shù)據(jù)是產(chǎn)品的根本，從研發(fā)的角度來講會(huì)更明白把數(shù)據(jù)如何處理更利于使用，不過我們?nèi)瞬欢啵蠹叶际羌紡V益，研發(fā)思考的時(shí)候偶爾會(huì)問我的意見，我一般思考的角度是，數(shù)據(jù)的存儲(chǔ)是否是否方便做清洗、是否利于使用、如果業(yè)務(wù)場景等因素有變化的數(shù)據(jù)是否可以再加工，新增和刪除是否容易因關(guān)聯(lián)邏輯復(fù)雜產(chǎn)生其他連鎖反應(yīng)。關(guān)聯(lián)邏輯復(fù)雜這種情況我覺得在產(chǎn)品迭代過程中（也許？）是一種不可避免的現(xiàn)象，所以我比較偏向于前三個(gè)角度，數(shù)據(jù)庫結(jié)構(gòu)更偏向于邏輯精簡也就是盡可能原始做基礎(chǔ)數(shù)據(jù)，有需要再建其他業(yè)務(wù)表，設(shè)計(jì)時(shí)寧愿多做列也不要為了圖方便直接按業(yè)務(wù)字段“組裝”好，想也知道后續(xù)會(huì)很不利于拆分（那時(shí)候考慮后續(xù)想做用戶行為的標(biāo)簽分析，有業(yè)務(wù)同事覺得圖方便直接每次行為的一堆標(biāo)簽存進(jìn)去展現(xiàn)出來只做記錄，后續(xù)迭代再做分析，當(dāng)時(shí)就覺得這種情況操作起來不見得便捷，因?yàn)楫a(chǎn)品初期哪怕按標(biāo)簽類型分開存儲(chǔ)再組裝其實(shí)數(shù)據(jù)量不會(huì)很大還支撐的住，相較于直接堆積在一起存儲(chǔ)麻煩點(diǎn)但不復(fù)雜，如果有新的標(biāo)簽類型后邊再加列，業(yè)務(wù)字段邏輯調(diào)整不大，就我們當(dāng)時(shí)的業(yè)務(wù)需要，二者相較來說從工作量上差異不算巨大；而從后續(xù)迭代的角度來講，每一堆數(shù)據(jù)可能都是無序的，長度不一，難做拆解和清洗，到時(shí)候還是要經(jīng)歷一遍重建的過程，相當(dāng)于費(fèi)了兩遍勁，沒必要，最后還是覺得拆開來存方便）。
不好意思稍微跑題了，打小孩子作文兒就不好，先不說我這個(gè)思考角度對(duì)不對(duì)，想說就參與深度而言，產(chǎn)品可以參與，但不能完全拍板，一定要有開發(fā)一起參與（不是為了分鍋，有鍋我從來都是自己的問題自己主動(dòng)認(rèn)，反正我一個(gè)女的豁出臉來怎么的也不至于被收拾太慘，純是這方面更信任同事的專業(yè)度），所謂術(shù)業(yè)有專攻，每個(gè)產(chǎn)品的誕生不同的部分大家的專業(yè)度有差異，如果可以，我個(gè)人比較喜歡開發(fā)有自己的想法，根據(jù)業(yè)務(wù)邏輯做更清晰的處理，業(yè)務(wù)邏輯不清晰的部分協(xié)同產(chǎn)品來做梳理，想問我的隨便問，真的有幾次他們問的問題正是因?yàn)槲业摹斑壿嫼辈判枰臀颐鞔_的，想當(dāng)然是大忌，正好方便我進(jìn)一步梳理。
數(shù)據(jù)這部分工作，更側(cè)重于研發(fā)，還是專業(yè)的人做專業(yè)的事。
說的很好，受用了