首页
业务
关于
客户
服务
联系
13520390899
资 深 的 互 联 网 开 发 服 务 商
专注于 网站开发 / 小程序开发 / APP开发 / 软件开发
网十科技 > 动态

廊坊小程序开发论述: 浅析后台产品的实现过程

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

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

需求调研

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

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

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

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

原型设计

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

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

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

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

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

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

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

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

需求评审

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

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

7x24
售后服务支持
10
故障时长赔付
16
16年行业服务经验
20
售后服务人员
70
设计、开发团队
10
国内顶尖技术专家
1000
大型及上市企业
版权所有 © 北京网十互动科技有限公司 网站 APP 小程序 软件 备案号:京ICP备16050073号-2

电话咨询