產品從0到1，會遇到哪些問題，涉及到哪些方面？如何解決這些問題？本文作者從自身經驗出發，結合實際案例對問題進行了分析。

一、背景介紹

筆者從事產品經理一月有余，自己第一個版本的PRD也從原本寫在Wiki上的一些功能，在研發的努力下，成為了現實世界中真實可用的功能。

但是，從寫在wiki上的功能，到成為現實中可用的功能，中途肯定是遇到問題。在這個過程中，我都遇到了什么問題？這些問題又是如何被解決。問題解決之后，通過整理復盤，我們又能收獲哪些呢？

?二、一些基礎知識

在開始我們后臺設計的復盤之前，我們需要補充一些基礎知識：

1. 靜態頁面與動態頁面
2. 數據庫
3. 用戶賬號管理

以上這3個知識點，單點之間聯系有限，但是在一個web上，彼此之間相互影響。我們先來了解一下，這三者分別是什么。

1. 靜態頁面與動態頁面

靜態頁面（Static Pages）服務器上真實存在的文件對應的網站頁面?！禨EO實戰密碼》

在網站設計中，純粹HTML格式的網頁（可以包括圖片、視頻、JS（前端功能實現）、CSS）通常被稱為“靜態頁面”，早期（2000年左右）大多都是由靜態網頁制作，靜態網頁時相對動態網頁而言，指沒有后臺數據庫、不含程序、不可交互的網頁。
——《跟老男孩學Linux運維：Web集群實戰》

給靜態頁面劃重點：

1. 服務器上真實存在
2. 不與數據庫交互

動態頁面通常指與數據庫發生交互的頁面，內容展示豐富，功能非常強大。
——《Linux企業運維實戰》

動態頁面并不真實存在于服務器上，沒有一個真正存在的文件對應。動態頁面是由數據庫驅動、腳本生成的頁面。當用戶訪問動態頁面時，程序查詢數據庫，并實時生成一個頁面。
——《SEO實戰密碼》

給動態頁面劃重點

1. 不真實存在于服務器上
2. 與數據庫交互，當用戶訪問動態頁面時，數據查詢數據庫，并實時生成一個頁面。

2. 數據庫

我們討論的是關系數據庫，關系數據庫基于關系模型使用一系列表來表達數據以及這些數據之間的聯系。

表是數據庫中重要的一個概念。

每個表有多個列，每個列有唯一的名字。

上圖展示了一個關系數據庫示例，它由三個表組成：其一給出銀行客戶的細節，其二給出賬戶，其三展示了哪個賬戶屬于哪個客戶。

1. 第一個表是 customer 表，表示例如，customer_id 為192-83-7465的客戶名字叫做Johnson，住在Palo Alto的Alma大街12號。

2. 第二個表是account表，表示，例如賬戶A-101有500美元的余額，賬戶A-201有900美元的余額。

3. 第三個表表示哪個賬戶屬于哪個客戶。例如，賬號A-101屬于customer_id為192-83-7465的客戶，他的名字叫Johnson，客戶192-83-7465和019-28-3746共同擁有賬號A-201。

——《數據庫系統概念》

3. 用戶賬號管理

什么是用戶賬號？

用戶賬號是一種身份驗證機制，每一用戶賬號都包括用戶唯一的身份標識。

用戶系統，主要分為用戶賬號體系和用戶信息兩大類。賬號體系包括，登錄驗證、注冊、第三方授權，以及權限管理。用戶信息包括，用戶地理位置、用戶屬性、用戶設備信息、還有用戶日志信息。

三、Case回顧

熟悉了上述3個概念后，我們開始來回顧復現case。

1. 背景

在官網的注冊申請產品試用流程中，本來用戶需要在申請試用表單中填寫手機號，這個手機號對于業務方來說非常重要，因為業務方需要通過這個號碼聯系到客戶，進行產品銷售。

但是其實用戶在官網注冊時候，就已經填寫了手機號，并且這個手機號還通過了驗證碼驗證。因此，本來這次產品設計的目標就是流程優化，很自然地，我們就將申請試用表達中填寫手機號的要求給刪除了。

也就是這個修改，給我帶來了一些麻煩。

2. 發生了什么問題

首先，從目標/結果闡述一下，為什么給我帶來了麻煩。

原來，通過申請表單收集的數據，是展現正在后臺的，業務方可以直接看到?，F在，申請表達不收集數據了，原來為后臺傳輸數據的上游沒有了，造成的結果就是后臺不顯示電話號碼了。

要知道哦，我們是To B，商務全靠申請試用的電話號碼，來聯系顧客，這一產品修改，連客戶的聯系方式都丟了。

問題說完了，我來說說為什么會造成這個問題。需要用戶輸入信息的交互界面，數據的保存。這里，一共有兩個需要用戶輸入信息的交互界面，一個是注冊，一個是產品試用申請。

分別說一下這兩個界面所收集的信息，以及涉及到的數據庫。

注冊頁面

1. 所收集的信息 用戶名 手機號
2. 數據庫 數據庫A

產品試用申請

1. 所收集的信息 試用產品 公司等
2. 數據庫 數據庫B

原來后臺管理界面，用戶數據是從數據庫B中調數據，現在調的時候，數據庫中是NULL，所以前端界面無任何展示。問題就是這樣發生的～

3. 解決措施

解決方案是什么？我們重新去數據庫A中開了一個接口。TAT，所以其實有時候，優化一個產品功能，不是那么簡單的事，所涉及到的前后端的協同，需要很多思考。

上面的解決方案中，提到了調接口，關于調接口這里，我也想多講一點。

作為產品經理，在工作中，我們會經常聽到接口二字，當我們談論接口的時候，我們在談論什么呢？

在軟件測試中，常說的接口一般有兩種：圖形用戶接口（Graphical User Interface, GUI），它是人與程序的接口；應用程序編程接口（Application Programa Interface, API），在產品設計中，我們談論的接口是第二種，API接口。

API是一組定義程序以及協議的集合，API可實現計算機軟件之間的相互通信。API的一個主要功能是提供通用功能集。程序員通過試用API函數開發應用程序，從而可以避免編寫無用程序，減輕編程任務。

很多公司將開發崗位分為前端工程師和后端工程師，他們之間相互配合完成工作。他們會協商接口的定義方式，其中一方定義接口（一般由后端工程師定義接口），另一方調用接口，以實現預期功能。前后端分離是近年來Web應用開發的一個發展趨勢。這種模式由以下優勢：

1. 后端工程師不用精通前端技術（如HTML、JS、或CSS）只專注于數據的處理、對外提供API即可

2. 前端工程師的專業性越來越強，其通過API獲取數據，并專注于頁面設計

3. 前后端分離可以擴大接口的應用范圍，開發的接口可以應用到Web網頁上，也可以用到APP上

接口可以分為以下3類

1. HTTP接口，基于超文本傳輸協議開發的接口，但不能排除沒有使用其他協議

2. Web Service接口，它是系統對外的接口，比如你要從別的網站或服務器上獲取資源，一般來說，別人不會把數據庫共享給我們，他們會提供一個他們寫好的方法，讓我們用來獲取數據，我們使用他們寫好的方法就可以引用他們提供的接口，從而達到同步數據的目的

3. RESTful接口，簡稱REST，描述了一個架構樣式的網絡系統，核心是面向資源

——《接口自動化測試持續集成：Postman+Newman+Git》

上面提到的我們解決手機號顯示在后臺管理系統的方法，是提供一個接口，就是后端給了一個從數據庫A調用用戶手機號的接口，前端通過調用這個接口，將這些數據呈現在前端界面上。

四、總結

從問題的發現，到最后的總結。涉及到了業務方、產品、以及前后端。產品在中間的角色，是定位問題，與研發協同思考解決方案。

如果，在一開始設計產品的時候，就考慮到了與數據庫的聯動，會好很多。對我而言，產品經理，必須懂技術。

本文由 @一顆西蘭花 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議