浅析后台产品的实现过程

2017-11-17 11:04:00

本文主要介绍后台产品从0-1的产品实现过程。最近在负责公司的一个后台项目，本人是技术转型开发，之前负责的也多数是后台管理系统，希望跟大家分享一些个人心得。

后台产品一般都是办公使用，或者内部人员使用，实现过程一般来说有以下几个步骤，需求调研、原型设计、需求评审、开发、测试、上线，此篇着重讲一下开发前期的需求调研，原型设计和需求评审。

需求调研

后台产品的需求相对比较明确，大部分的需求来自领导，少部分的需求来自各个部门，比如市场、客服、人事、财务等。

需求调研的过程中，一定要明确调研的目的，比如客户管理功能，市场部、客服部员工会比较关注新注册客户、今日使用客户、我根据的客户等，对于研发部、职能部门可能就只是看一下客户记录，因为他们不需要去关注客户的具体跟进情况。跟不同部门人员沟通需求时候，要有侧重点，员工不关注或者几乎不用的功能问了也是鸡肋，并不能给实际的工作带来帮助。

需求调研以后，就要进行需求整理。收集到的需求都是分散的，可使用XMind（或者MindManager）软件绘制思维导图，进行简单的逻辑整理，把相关的业务或者功能进行分类，然后再细化模块，采用分-总-分的模式。我们之前的后台分类是按照业务线划分，比如移动端，PC端产品，然后产品模块下会有客户管理、订单管理等，后面在重新规划后台的时候，采用的是功能划分，比如客户管理，然后模块下会有移动端产品客户、PC端产品客户等。这两种模式没有对错之分，因为后续考虑到角色权限，按照功能划分容易规划权限。

需求整理分类以后，要开始归类划分，学会区分真假需求。比如用户反馈需要加一个功能，不是盲目去加功能，要考虑需要此功能的目的，有时候他需要B功能去实现C功能，那如果直接提供一个C功能岂不是更好。需求分类以后，要根据时间情况规划优先级，可根据四象限法则来定义。

原型设计

框架定了以后，开始进行页面原型设计，目前使用的软件是Axure，后台产品的终端大多是PC或者笔记本，Axure功能比较强大，比较适合做PC的原型设计。

针对后台产品原型设计的过程中，要把握几个点：考虑使用场景、功能要强大、行为路径要短、效率要高、要有容错机制。具体到页面细节，需要注意的比如尺寸适配、数据的增删改查、字段的长度、必填项、交互样式等。如果有设计功底的话，在原型的页美观度上可以进行优化，输出中保真、高保真原型图。

考虑使用场景：就拿分页功能来说，之前我们做的后台一般一页显示20条，最多50条记录，我在设计后台的时候想当然也按照这样分页记录，后面跟领导讨论后才知道，只是客户量就上万，每页显示20条记录根本不符合使用场景，至少每页100条或者200条记录才可满足需求。

功能强大：比如客户管理，除了查询、添加、编辑、删除、详情，还要跟进业务情况考虑是否需要添加任务、添加订单、跟进情况、日志记录等等。最好考虑到业务的各个方面，并有所侧重。

行为路径要短：用户可以通过1次或者0次交互可达到目的，就不要让他2次或者更多次交互才达到目的。比如查看客户列表，客服部、市场部比较关注我的客户，那页面在加载的时候默认就加载我的客户数据，并高亮显示。而不是先显示全部客户，再点击我的客户才可以看到需要的数据。

效率要高：这个一般针对大数据的时候，要考虑加载速度，系统性能问题，需要技术层面多多优化。

要有容错机制：后台系统一定要有容错机制，不能说用户操作错误或着误操作，就无法挽回。比如针对禁用按钮，要点击按钮时提示是否确认禁用，禁用后会带来哪些影响，尽量在操作前给出相应提示。

原型设计的同时还需要输出的是PRD文档，一般会花费60%的时间画原型，40%的时间写需求文档，但是实际上PRD文档的重要性要大于原型，因为原型很多交互，功能细节等需要通过PRD来进行描述。需求文档方面，主要的是把需求描述清楚，条例清晰，逻辑严谨，至于格式参考公司原有的就可以。

需求评审

需求评审分为内部评审、团队评审。

内部评审一般参与人员有产品总监、产品经理，主要目的是针对有疑虑的点，大家提出一些可行性方案，择优决定，另外就是看看原型、文档哪里有问题的提出来再进行优化。比如列表项的选填，PC端产品支持可选，可填，手机端考虑到屏幕尺寸问题只支持可选，这样显然是不合理的，考虑一致性的话，手机端也需要支持可填。

团队评审一般参与人员有产品经理，项目经理，测试主管，设计师（需要设计的话），主要目的是针对产品流程，产品实现展开讨论，为了确保产品落地，另外项目经理也要根据产品的原型设计，考虑技术可行性。特别是对于已有功能做优化的时候，要考虑到不破坏原有的数据结构，项目经理就需要对一些产品细节进行把控，比如字段长度，必填项等，需要兼容原来的产品设计规则。