產(chǎn)品從0到1，會(huì)遇到哪些問題，涉及到哪些方面？如何解決這些問題？本文作者從自身經(jīng)驗(yàn)出發(fā)，結(jié)合實(shí)際案例對問題進(jìn)行了分析。

一、背景介紹

筆者從事產(chǎn)品經(jīng)理一月有余，自己第一個(gè)版本的PRD也從原本寫在Wiki上的一些功能，在研發(fā)的努力下，成為了現(xiàn)實(shí)世界中真實(shí)可用的功能。

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

?二、一些基礎(chǔ)知識(shí)

在開始我們后臺(tái)設(shè)計(jì)的復(fù)盤之前，我們需要補(bǔ)充一些基礎(chǔ)知識(shí)：

1. 靜態(tài)頁面與動(dòng)態(tài)頁面
2. 數(shù)據(jù)庫
3. 用戶賬號(hào)管理

以上這3個(gè)知識(shí)點(diǎn)，單點(diǎn)之間聯(lián)系有限，但是在一個(gè)web上，彼此之間相互影響。我們先來了解一下，這三者分別是什么。

1. 靜態(tài)頁面與動(dòng)態(tài)頁面

靜態(tài)頁面（Static Pages）服務(wù)器上真實(shí)存在的文件對應(yīng)的網(wǎng)站頁面?！禨EO實(shí)戰(zhàn)密碼》

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

給靜態(tài)頁面劃重點(diǎn)：

1. 服務(wù)器上真實(shí)存在
2. 不與數(shù)據(jù)庫交互

動(dòng)態(tài)頁面通常指與數(shù)據(jù)庫發(fā)生交互的頁面，內(nèi)容展示豐富，功能非常強(qiáng)大。
——《Linux企業(yè)運(yùn)維實(shí)戰(zhàn)》

動(dòng)態(tài)頁面并不真實(shí)存在于服務(wù)器上，沒有一個(gè)真正存在的文件對應(yīng)。動(dòng)態(tài)頁面是由數(shù)據(jù)庫驅(qū)動(dòng)、腳本生成的頁面。當(dāng)用戶訪問動(dòng)態(tài)頁面時(shí)，程序查詢數(shù)據(jù)庫，并實(shí)時(shí)生成一個(gè)頁面。
——《SEO實(shí)戰(zhàn)密碼》

給動(dòng)態(tài)頁面劃重點(diǎn)

1. 不真實(shí)存在于服務(wù)器上
2. 與數(shù)據(jù)庫交互，當(dāng)用戶訪問動(dòng)態(tài)頁面時(shí)，數(shù)據(jù)查詢數(shù)據(jù)庫，并實(shí)時(shí)生成一個(gè)頁面。

2. 數(shù)據(jù)庫

我們討論的是關(guān)系數(shù)據(jù)庫，關(guān)系數(shù)據(jù)庫基于關(guān)系模型使用一系列表來表達(dá)數(shù)據(jù)以及這些數(shù)據(jù)之間的聯(lián)系。

表是數(shù)據(jù)庫中重要的一個(gè)概念。

每個(gè)表有多個(gè)列，每個(gè)列有唯一的名字。

上圖展示了一個(gè)關(guān)系數(shù)據(jù)庫示例，它由三個(gè)表組成：其一給出銀行客戶的細(xì)節(jié)，其二給出賬戶，其三展示了哪個(gè)賬戶屬于哪個(gè)客戶。

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

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

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

——《數(shù)據(jù)庫系統(tǒng)概念》

3. 用戶賬號(hào)管理

什么是用戶賬號(hào)？

用戶賬號(hào)是一種身份驗(yàn)證機(jī)制，每一用戶賬號(hào)都包括用戶唯一的身份標(biāo)識(shí)。

用戶系統(tǒng)，主要分為用戶賬號(hào)體系和用戶信息兩大類。賬號(hào)體系包括，登錄驗(yàn)證、注冊、第三方授權(quán)，以及權(quán)限管理。用戶信息包括，用戶地理位置、用戶屬性、用戶設(shè)備信息、還有用戶日志信息。

三、Case回顧

熟悉了上述3個(gè)概念后，我們開始來回顧復(fù)現(xiàn)case。

1. 背景

在官網(wǎng)的注冊申請產(chǎn)品試用流程中，本來用戶需要在申請?jiān)囉帽韱沃刑顚懯謾C(jī)號(hào)，這個(gè)手機(jī)號(hào)對于業(yè)務(wù)方來說非常重要，因?yàn)闃I(yè)務(wù)方需要通過這個(gè)號(hào)碼聯(lián)系到客戶，進(jìn)行產(chǎn)品銷售。

但是其實(shí)用戶在官網(wǎng)注冊時(shí)候，就已經(jīng)填寫了手機(jī)號(hào)，并且這個(gè)手機(jī)號(hào)還通過了驗(yàn)證碼驗(yàn)證。因此，本來這次產(chǎn)品設(shè)計(jì)的目標(biāo)就是流程優(yōu)化，很自然地，我們就將申請?jiān)囉帽磉_(dá)中填寫手機(jī)號(hào)的要求給刪除了。

也就是這個(gè)修改，給我?guī)砹艘恍┞闊?/p>

2. 發(fā)生了什么問題

首先，從目標(biāo)/結(jié)果闡述一下，為什么給我?guī)砹寺闊?/p>

原來，通過申請表單收集的數(shù)據(jù)，是展現(xiàn)正在后臺(tái)的，業(yè)務(wù)方可以直接看到?，F(xiàn)在，申請表達(dá)不收集數(shù)據(jù)了，原來為后臺(tái)傳輸數(shù)據(jù)的上游沒有了，造成的結(jié)果就是后臺(tái)不顯示電話號(hào)碼了。

要知道哦，我們是To B，商務(wù)全靠申請?jiān)囉玫碾娫捥?hào)碼，來聯(lián)系顧客，這一產(chǎn)品修改，連客戶的聯(lián)系方式都丟了。

問題說完了，我來說說為什么會(huì)造成這個(gè)問題。需要用戶輸入信息的交互界面，數(shù)據(jù)的保存。這里，一共有兩個(gè)需要用戶輸入信息的交互界面，一個(gè)是注冊，一個(gè)是產(chǎn)品試用申請。

分別說一下這兩個(gè)界面所收集的信息，以及涉及到的數(shù)據(jù)庫。

注冊頁面

1. 所收集的信息 用戶名 手機(jī)號(hào)
2. 數(shù)據(jù)庫 數(shù)據(jù)庫A

產(chǎn)品試用申請

1. 所收集的信息 試用產(chǎn)品 公司等
2. 數(shù)據(jù)庫 數(shù)據(jù)庫B

原來后臺(tái)管理界面，用戶數(shù)據(jù)是從數(shù)據(jù)庫B中調(diào)數(shù)據(jù)，現(xiàn)在調(diào)的時(shí)候，數(shù)據(jù)庫中是NULL，所以前端界面無任何展示。問題就是這樣發(fā)生的～

3. 解決措施

解決方案是什么？我們重新去數(shù)據(jù)庫A中開了一個(gè)接口。TAT，所以其實(shí)有時(shí)候，優(yōu)化一個(gè)產(chǎn)品功能，不是那么簡單的事，所涉及到的前后端的協(xié)同，需要很多思考。

上面的解決方案中，提到了調(diào)接口，關(guān)于調(diào)接口這里，我也想多講一點(diǎn)。

作為產(chǎn)品經(jīng)理，在工作中，我們會(huì)經(jīng)常聽到接口二字，當(dāng)我們談?wù)摻涌诘臅r(shí)候，我們在談?wù)撌裁茨兀?/p>

在軟件測試中，常說的接口一般有兩種：圖形用戶接口（Graphical User Interface, GUI），它是人與程序的接口；應(yīng)用程序編程接口（Application Programa Interface, API），在產(chǎn)品設(shè)計(jì)中，我們談?wù)摰慕涌谑堑诙N，API接口。

API是一組定義程序以及協(xié)議的集合，API可實(shí)現(xiàn)計(jì)算機(jī)軟件之間的相互通信。API的一個(gè)主要功能是提供通用功能集。程序員通過試用API函數(shù)開發(fā)應(yīng)用程序，從而可以避免編寫無用程序，減輕編程任務(wù)。

很多公司將開發(fā)崗位分為前端工程師和后端工程師，他們之間相互配合完成工作。他們會(huì)協(xié)商接口的定義方式，其中一方定義接口（一般由后端工程師定義接口），另一方調(diào)用接口，以實(shí)現(xiàn)預(yù)期功能。前后端分離是近年來Web應(yīng)用開發(fā)的一個(gè)發(fā)展趨勢。這種模式由以下優(yōu)勢：

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

2. 前端工程師的專業(yè)性越來越強(qiáng)，其通過API獲取數(shù)據(jù)，并專注于頁面設(shè)計(jì)

3. 前后端分離可以擴(kuò)大接口的應(yīng)用范圍，開發(fā)的接口可以應(yīng)用到Web網(wǎng)頁上，也可以用到APP上

接口可以分為以下3類

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

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

3. RESTful接口，簡稱REST，描述了一個(gè)架構(gòu)樣式的網(wǎng)絡(luò)系統(tǒng)，核心是面向資源

——《接口自動(dòng)化測試持續(xù)集成：Postman+Newman+Git》

上面提到的我們解決手機(jī)號(hào)顯示在后臺(tái)管理系統(tǒng)的方法，是提供一個(gè)接口，就是后端給了一個(gè)從數(shù)據(jù)庫A調(diào)用用戶手機(jī)號(hào)的接口，前端通過調(diào)用這個(gè)接口，將這些數(shù)據(jù)呈現(xiàn)在前端界面上。

四、總結(jié)

從問題的發(fā)現(xiàn)，到最后的總結(jié)。涉及到了業(yè)務(wù)方、產(chǎn)品、以及前后端。產(chǎn)品在中間的角色，是定位問題，與研發(fā)協(xié)同思考解決方案。

如果，在一開始設(shè)計(jì)產(chǎn)品的時(shí)候，就考慮到了與數(shù)據(jù)庫的聯(lián)動(dòng)，會(huì)好很多。對我而言，產(chǎn)品經(jīng)理，必須懂技術(shù)。

本文由 @一顆西蘭花 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議