产品从0到1，会遇到哪些问题，涉及到哪些方面？如何解决这些问题？本文作者从自身经验出发，结合实际案例对问题进行了分析。

一、背景介绍

笔者从事产品经理一月有余，自己之一个版本的PRD也从原本写在Wiki上的一些功能，在研发的努力下，成为了现实世界中真实可用的功能。

但是，从写在wiki上的功能，到成为现实中可用的功能，中途肯定是遇到问题。在这个过程中，我都遇到了什么问题？这些问题又是如何被解决。问题解决之后，通过整理复盘，我们又能收获哪些呢？

 二、一些基础知识

在开始我们后台设计的复盘之前，我们需要补充一些基础知识：

静态页面与动态页面

数据库

用户账号管理

以上这3个知识点，单点之间联系有限，但是在一个web上，彼此之间相互影响。我们先来了解一下，这三者分别是什么。

1. 静态页面与动态页面

静态页面（Static Pages）服务器上真实存在的文件对应的网站页面。《SEO实战密码》

在网站设计中，纯粹HTML格式的网页（可以包括图片、视频、 *** （前端功能实现）、CSS）通常被称为“静态页面”，早期（2000年左右）大多都是由静态网页 *** ，静态网页时相对动态网页而言，指没有后台数据库、不含程序、不可交互的网页。
——《跟老男孩学Linux运维：Web集群实战》

给静态页面划重点：

服务器上真实存在

不与数据库交互

动态页面通常指与数据库发生交互的页面，内容展示丰富，功能非常强大。
——《Linux企业运维实战》

动态页面并不真实存在于服务器上，没有一个真正存在的文件对应。动态页面是由数据库驱动、脚本生成的页面。当用户访问动态页面时，程序查询数据库，并实时生成一个页面。
——《SEO实战密码》

给动态页面划重点

不真实存在于服务器上

与数据库交互，当用户访问动态页面时，数据查询数据库，并实时生成一个页面。

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. 发生了什么问题

首先，从目标/结果阐述一下，为什么给我带来了麻烦。

原来，通过申请表单收集的数据，是展现正在后台的，业务方可以直接看到。现在，申请表达不收集数据了，原来为后台传输数据的上游没有了，造成的结果就是后台不显示 *** 号码了。

要知道哦，我们是To B，商务全靠申请试用的 *** 号码，来联系顾客，这一产品修改，连客户的联系方式都丢了。

问题说完了，我来说说为什么会造成这个问题。需要用户输入信息的交互界面，数据的保存。这里，一共有两个需要用户输入信息的交互界面，一个是注册，一个是产品试用申请。

分别说一下这两个界面所收集的信息，以及涉及到的数据库。

注册页面

所收集的信息 用户名 手机号

数据库 数据库A

产品试用申请

所收集的信息 试用产品 公司等

数据库 数据库B

原来后台管理界面，用户数据是从数据库B中调数据，现在调的时候，数据库中是NULL，所以前端界面无任何展示。问题就是这样发生的～

3. 解决措施