并不是所有的產(chǎn)品經(jīng)理都是懂技術的產(chǎn)品經(jīng)理，那么讓產(chǎn)品經(jīng)理來設計數(shù)據(jù)庫表，是否合適呢？這篇文章里，作者表達了他的觀點，并闡明了觀點提出的背后原因，一起來看看吧。

前段時間，讀友群里有朋友吐槽產(chǎn)品經(jīng)理設計表多次給開發(fā)挖坑，引起了群內讀友的大討論，產(chǎn)品經(jīng)理到底該不該設計數(shù)據(jù)庫表？

其實這個問題也不僅僅只有他們公司存在，估計很多公司也存在產(chǎn)品設計數(shù)據(jù)庫表的情況。我曾經(jīng)接手的項目，就是產(chǎn)品設計數(shù)據(jù)表，研發(fā)根據(jù)產(chǎn)品設計數(shù)據(jù)表創(chuàng)建數(shù)據(jù)庫表開發(fā)。我當時感覺到很震驚，還有這么干的？

產(chǎn)品經(jīng)理很多是不太懂技術的，他們設計數(shù)據(jù)結構，程序開發(fā)同學能用嗎？估計也會像上圖的朋友所說的，錯位處理吧。好無奈??！

在我負責的技術團隊，數(shù)據(jù)結構的設計是一件非常高層次的工作，一般只有架構師和資深工程師才能參與，我技術評審最核心的內容就是數(shù)據(jù)庫的設計。

所以，我先表達一下自己的觀點：產(chǎn)品經(jīng)理不應該設計數(shù)據(jù)庫表！具體原因，我們接下來分析。

一、表單和表不一樣

產(chǎn)品經(jīng)理做產(chǎn)品設計，不可避免的會涉及到大量的業(yè)務表單，對于系統(tǒng)，特別是企業(yè)級的系統(tǒng)來說，大部分的業(yè)務都是通過業(yè)務單據(jù)的流轉來體現(xiàn)的。

以一個老人的生活狀況評估表單為例。

從產(chǎn)品的角度來說，表單不僅是業(yè)務數(shù)據(jù)的體現(xiàn)，而且充滿了用戶的交互體驗，視覺體驗，還有數(shù)據(jù)規(guī)則的校驗。所以表單是用戶視角的元素，是為用戶使用系統(tǒng)來處理業(yè)務使用的。所以產(chǎn)品經(jīng)理在數(shù)據(jù)化表單的時候，一般會向開發(fā)呈現(xiàn)如下的數(shù)據(jù)表說明。

在數(shù)據(jù)庫設計層面，表結構雖然來源于產(chǎn)品設計的表單，但如果完全參考產(chǎn)品經(jīng)理甚至是產(chǎn)品經(jīng)理來定義表機構，很容易造成直接將表單翻譯成表的情況，如下圖：

但實際我們在數(shù)據(jù)庫設計中，數(shù)據(jù)表和表單并不是完全一致的。

表單的作用是采集數(shù)據(jù)或者展現(xiàn)業(yè)務數(shù)據(jù)，只需要考慮業(yè)務需要即可。而數(shù)據(jù)庫表的作用是存儲數(shù)據(jù)和管理數(shù)據(jù)的，數(shù)據(jù)存在查看，新增，更新，刪除等操作，在這個過程中要保證避免臟數(shù)據(jù)、錯誤數(shù)據(jù)、重復數(shù)據(jù)等情況的發(fā)生，還要考慮存取數(shù)據(jù)的性能和效率。

所以數(shù)據(jù)表設計需要考慮數(shù)據(jù)庫范式，需要適當做數(shù)據(jù)冗余，需要設計輔助字段等等。

如上圖所示，一個老人基礎評估表單可能涉及的數(shù)據(jù)結構，是由三個表組成，甚至更多。而且為了配合程序更好的使用，需要補充一些非業(yè)務型的數(shù)據(jù)字段，如紅色部分。為了更好的管理枚舉屬性的字段內容，還需要引入數(shù)據(jù)字典。

因為表單和業(yè)務關聯(lián)，所以不同的場景，不同的人群，甚至不同客戶的個性化需求，表單內容會隨之調整，但是數(shù)據(jù)結構作為整個應用系統(tǒng)的底層架構，它是需要穩(wěn)定的，最好是以不變應萬變的。

下圖數(shù)據(jù)結構為了擴展性的需求，很有可能將基礎評估表里的那些評估內容，抽象成一個通用的數(shù)據(jù)結構：評估模版表（evalution_form_tpl）、評估問題表（evalution_form_question），從而可以擴展制作各種各樣的評估表單。然后用評估表（evalution_form）和評估結果表（evalution_form_reply）來存儲評估數(shù)據(jù)。

表單是具象的，而數(shù)據(jù)結構是抽象的！

這就是自定義問卷的最簡單結構！通過這個結構我們就能支持各種各樣的評估表的功能，從而可以開發(fā)一個適應業(yè)務能力更強的系統(tǒng)或者產(chǎn)品。

最后總結一下表單和DB表的區(qū)別：

二、跨層兼任不可取

從前文分析我們也知道，表單不同于DB表，產(chǎn)品經(jīng)理設計更多的是表單，而不是表。但是為什么還是有很多公司，讓產(chǎn)品經(jīng)理來負責設計表呢？

粗略分析，有以下幾個原因：

1. 產(chǎn)品或者系統(tǒng)中的表單反應了業(yè)務的數(shù)據(jù)結構，產(chǎn)品經(jīng)理直接以此確定數(shù)據(jù)結構，不用做兩遍工作，比較高效。
2. 產(chǎn)品人員具備一定的技術背景，能同時兼任產(chǎn)品和數(shù)據(jù)結構設計工作，合一起做，提升效率，節(jié)約成本。
3. 企業(yè)對于產(chǎn)品經(jīng)理的職責定位不清晰導致，賦予的職責范圍過大。

首先，我們先來分析，產(chǎn)品經(jīng)理做DB表設計是不是本職工作。我們還是從一個產(chǎn)品或者系統(tǒng)的組成來看：

從這個分層結構上來看，產(chǎn)品經(jīng)理的主要本職工作處在這個分層結構的第一層，有更具象的功能模塊組成。而數(shù)據(jù)建模層要在倒數(shù)第二層，和產(chǎn)品功能層相差較遠，顯然應用表現(xiàn)層上的主要內容才是產(chǎn)品經(jīng)理更加核心，更本職的工作內容。

為什么數(shù)據(jù)建模層不能成為產(chǎn)品經(jīng)理的核心本職工作？我們都知道在企業(yè)里一般都有兼任的情況，第一是領導兼任下一級崗位的，第二是平級崗位間兼任的，很少出現(xiàn)跨級兼任的情況！

每個相鄰層級之間，因為相互依賴，相互支持，對對方領域會更有了解和理解。相鄰層級里兼任部分工作，從工作關聯(lián)度上來說和專業(yè)度上來說，都更比跨級領域要高。所以，如果數(shù)據(jù)建模沒有專門的人和團隊負責，交給相鄰層的技術團隊也許會更加合適。

就像前文的那個數(shù)據(jù)結構，技術團隊可以融合技術選型，比如可以采用MongoDB作為評估表存儲，用redis緩存xx數(shù)據(jù)，應用支撐層的相關技術的使用，這些都會影響數(shù)據(jù)建模層的設計。所以數(shù)據(jù)建模需要依賴下層數(shù)據(jù)層的技術選型，需要充分考慮上層應用支撐層的技術實現(xiàn)，這些都是絕大多數(shù)產(chǎn)品經(jīng)理都無法勝任的。

而對于技術出身的產(chǎn)品經(jīng)理，像老譚這樣從開發(fā)到架構都做過的產(chǎn)品人員，做點數(shù)據(jù)建模是完全可以勝任的。但是不是勝任就要去做的，我們要明確自己角色的轉換，我現(xiàn)在是一名產(chǎn)品經(jīng)理，我的工作和精力要更貼合業(yè)務，更貼合用戶，而不是考慮技術實現(xiàn)。

更何況，我們不再做技術，很難深入技術細節(jié)，跟不上最新的技術趨勢，我們設計的DB表很難思考全面，照顧周全，所以可以參與討論，但不能具體負責。

綜上所述，產(chǎn)品經(jīng)理跨層負責DB表設計，我認為并不是非常合理的選擇！你覺得呢？