浅析后台产品的实现过程

　　本文主要介绍后台产品从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端产品支持可选，可填，手机端考虑到屏幕尺寸问题只支持可选，这样显然是不合理的，考虑一致性的话，手机端也需要支持可填。

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

　　开发

　　原型定稿以后，交由设计师设计，一般后台产品为内部人员使用，设计部分相对弱化。开发可根据原型或设计稿，进入开发阶段。项目经理要根据产品原型，制定出项目排期(研发一般区分前端和后端，排期方面尽量详细)。产品经理要按照项目排期，推动产品落地，及时掌握工作进度。

　　在开发过程中，如有需求变更，及时通知到相关负责人，共享文档及时更新，避免开发人员拿到旧版本的原型或文档进行开发，重复劳动。

　　测试

　　开发人员功能开发完毕以后，首先要保证单元测试通过(开发人员进行单元测试一般在开发服务器进行)，然后交付测试。测试人员根据具体情况，可按照业务线、功能模块等进行测试，测试人员一般在测试服务器(模拟线上服务器)进行测试。产品经理在此阶段也要参与测试，主要关注一下产品的流程实现是否合理。

　　测试过程中提交的Bug，要及时进行修复。产品也要关注Bug的数量和修复进度，需要去定义哪些是需求，哪些是Bug。我们之前的处理是测试阶段每天16:00之前的Bug当天修复，一方面可保证工作进度，另外也方便统计数据。

　　上线

　　测试人员测试通过以后，产品人员进行最后的验收测试，没问题的情况下，项目发布线上环境。最后测试人员和开发在线上环境再次进行验收测试，确保无误后，正式对外公布上线。

　　以上是个人针对后台系统实现分享的个人心得，欢迎大家多多交流，共同进步!

　　本文由 @lihuakai 原创发布。未经许可，禁止转载。

　　题图来自 Pexels，基于 CC0 协议

*请认真填写需求信息，我们会在24小时内与您取得联系。