撰写后台需求文档需要注意的那些事儿

很多产品经理在撰写后台的需求文档时会一脸懵，很多时候不知道怎么开始，这篇文章主要根据自己工作中对后台的理解和需求文档撰写经验进行分享。

人员较小的公司，会要求产品经理后台管理和前台界面一起进行撰写。那么，我们在撰写后台需求文档时，需要对于后台有一定的了解。当然，要是技术转型做产品经理，对于这一块可以说是有优势。

产品经理要是技术小白，我们需要对后台有一定的了解并指导技术常用的词语，需要知道相应的后台的组成部分和作用。

在撰写后台需求文档时，要先将前台界面确定下来，最好和对应的人员确定好，开个需求评审会，将界面和业务明确。之后再开始后台需求文档的撰写，以我的亲身经历告诉你，修改是很麻烦的。

我们要知道一点，前台界面和对应的后台的界面字段要一致。因为数据库需要设计表，改动较大，后台的接口也需要调整，这样开发同学会很烦，要重新写接口。

 一、后台作用（后台是干什么的）

后台主要是管理整个系统软件，就像你是学生，需要去学校一样，学校就是管理你的。

不管是APP还是PC，都有一个管理后台，我们在写后台需求文档时需要记住四字秘诀“增删改查”，这是最核心的东西。

就用PC网站来说，一个PC网站上线后台需要准备哪东西呢？

首先，域名和服务器。

域名和服务器必须买，域名还需要备案，不然就发布不了。做完第一步就需要进第二步，环境搭建，这个技术会解决，感兴趣的可以了解一下后台常见的环境部署，主要有nginx，tomcat，还有第三方的工具，都可以使用。环境搭建完成就是配置文件，将你的配置文件放在购买的服务器的环境目录下面，找到对应文件进行配置就可以访问了。

后台对前端界面的设置和管理，这是最大的作用。我们需要对后台的业务非常熟悉，在产品设计的时候就不会乱七八糟一堆。如果后台逻辑混乱，页面流程不够流畅，你就是在挖坑，后面接手的产品经理会天天问候你的。

在撰写后台需求文档时，始终记着“增删改查”，每一个功能和页面都需要有这四点，这样你后面进行需求文档复查时错误会很少。在设计后台之前，需要将对应的人员角色进行充分的考虑和对应的场景进行分析。除了功能层面的增删改查还有一定的人员权限，如果权限不做特殊要求，也可以使用增删改查的方式进行设计。

注意：后台的模块需要进行划分合理，不然扩展维护比较困难。

建议：不要在公司正式的服务器环境进行操作，可以多和后台人员和运维人员进行沟通。

二、后台构成（后台关键的几个组件）

后台最核心的主要是数据库、接口、服务器环境，我们从简单的三个方面进行，在这里就用大白话说明这三个东西的作用。

数据库：数据的存储，常用的数据库是MySQL，SqlServer，Oracle。体量较小使用的是MySQL数据库，数据库包含的信息有字段和表以及权限等。

数据库就是仓库，我们APP中数据用户信息都是在数据库中进行存储。不同的信息会对应不同的表，这个表需要开发人员进行设计，对应的结构需要合理，不然数据多的时候就会影响APP的使用体验。

比如，有个表单你需要看，然后后台进行查询，结果查询数据太多，导致结果显示慢，用户可能需要等待几分钟才能看见相应数据。这种体验很差。

接口：接口中包含一定的信息数据，定义对应的返回值，更多的是我们前端界面请求后台接口时需要返回一定的参数，其中包含对应成功失败等的状态。

包含的信息和数据带着对应字段的信息，接口展示的形式是url地址，拿到这个地址进行解析，最后你会看见对应包含的信息在里面。

前端界面进行请求接口，也就是url地址，地址中会返回一定的参数，可以拿个接口在线解析看一下。

环境：后台需要一定的环境，没有环境就无法正常运行。一般环境分为正式环境和测试环境，环境的搭建主要是后台开发人员或者是运维部署。

可以手动尝试搭建对应的后台环境，测试一下，理解其中的原理，就会明白软件运行的原理。搭建环境需要专业的安装工具，百度上面有很多教程，具体的步骤：首先买服务器，其次域名进行备案，最后将服务器环境进行部署。阿里云上面有详细的教程，感兴趣可以看以对应的环境搭建。

建议：查看一下数据库，最好是亲自进行操作，可以尝试一下免费的数据库测试（测试数据库的地址https://demo.phpmyadmin.net/master-config/）。

注意：对应的数据库表设计要合理，前期架构时将对应的模块进行分类，后期进行扩展。

三、文档怎么写

文档撰写的流程和逻辑以及实现的思路，我们这里就用一个人员管理来进行说明：需求是人员的管理，包含人员的信息、登录、注册、开通、修改编辑、删除、查询，主要包含信息就是增删改查。

1. 确定需求

后台是根据前台界面来的，前台界面展示一个人员的信息，这个人名字就叫A；A的信息有姓名、岗位、部门、电话、开通日期、邮箱。

前台的信息已经确定，我们后台的信息也就可以确定，从新增功能点进行说明：

• 新增：姓名、岗位、部门、电话、开通日期、邮箱。
• 全权限设置：分配对应的权限，将权限设置好。
• 点击提交，这条数据就会在数据库存在。

建议：细小的功能将其模块化，就像一个人一样，整体是一个人，其中手眼睛鼻子等是身体的组件部分，产品也可以从小的组件进行组装。

2. 主要功能点

将对应的主要的功能点进行罗列，并且对应的细节需要考虑到和其他业务之间的关联，以下就将对应核心功能点进行罗列：

• 查询：支持类型为姓名、手机号、岗位和部门
• 状态管理：正常、冻结
• 账户管理：新增、修改、删除
• 分页加载：页面数据、分页加载对应数据
• 查看：个人信息查看、密码查看（建议设置点击空白区域三下查看）

建议：对应的功能点中细小的信息进来罗列，这样后期方便权限的分配。

注意：密码可见最好是先和管理人员确定，将可见状态设置权限。

3. 业务说明

业务的说明需要将对应的跳转，也注意事项仔细的进行说明。就像新增每个字段，我们支持对应的类型和不支持类型。

提交状态是否要求全部输入内容，没有输入内容按钮就不可进行点击提交，这样的说明我们需要一点一点添加进去。

首先，将业务流程进行思考清楚，对应的人员和对应的操作流程，这样你后期需求文档页面就是完整的。

如果业务流程不清楚，就从单独的功能点开始进行。将页面的布局进行点击，多点击几次，就会发现页面流程是不是完整，对应的需求是不是能够完整走完。

其次，如果需求太多实在理解不来，就一个一个进行拆分，务必将需求尽可能的理解到位，不然就会面临很大的改动。

最后，理解核心的流程。我们有时候会接收到一堆的需求和流程，但是流程太多会不容易理解，很多时候需求提出者更多的是口述，所以需要多问对方再确定。

建议：需求太多就用手机录下来。

注意：理解的偏差，再三确定需求，重要的事情说三遍。

 总结

后台需求文档需要将能放在一起的产品前端界面就放在一起，这样我们后期维护起来就方便。如果你的后台和对应的前台界面一样，那么这样的是不合理的。

在撰写后台的时候，需要将对应前台功能点进行整理。就像你看到的APP前台界面，想想后台的逻辑是怎么实现的。

最后，在撰写前台界面的时候，可以将对应的后台功能点一起进行撰写。当然实在觉得自己搞不了，在写文档的的时候，就多问问你们的后台大哥。

最后，附上一张自己做的项目结构图，包含前端和后台：

 

本文由 @李杭 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议