浅析后台产品的实现过程
本文主要介绍后台产品从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 协议
有个问题想请教下,怎么才能提高后台产品的设计能力呢?有时候觉得自己能够将产品逻辑整理得比较清楚,但是却拿不准用什么样的交互和展示形式去实现比较好?
可以说是很详细了,我做了一年多的后台,大致也是这样纸一步步过来的。
不懂技术,天天别后台怼,每次增加一项功能,技术就自己定好了开发,我就跟进跟进进度= =
这个就需要沟通到位,还有就是产品人员要起到主导作用,不然被开发牵着走,很容易跑偏,毕竟产品对于需求的理解肯定是最透彻的
对于刚从事产品的人很有帮助
楼主 好文章,希望还能你的下一篇。
很受用的文章,公司主要做后台的,感觉一直都做不好,希望楼主以后多多分享
我们总监都只是扫一眼,根本不会仔细看的,所有很多时候,我交给程序员的需求文档都被他们说的不成样子,什么数据来源啊,什么这样可不错的,总之很多,我没跟他们交流一次,我都要气的吐血。(真的是我错误的话,我也会改的,但是有些只是很简单的文案更改,还需要文档,真的是气死人的)
干活,下次多来点,能猜到我是谁吗?嘿嘿
干货!!!最近也正在做公司业务上使用的后台管理系统,目前在研发阶段。需求调研不是本人做的,不过基本是按照需求来设计功能。现在每天测试、沟通,时不时会有些改动,挺麻烦开发人员的。从中认识到,很多地方在设计的时候要考虑到整体的关联性,一动则动全身的地方要多思考可能出现的情况。还有就是角色权限上的问题,数据的增删改也要好好把握。
踩过的坑多了,慢慢就有经验了,考虑问题越来越全面,后续可以多多交流。
好的,期待越来越多的干货!今天在做旧系统数据转移的整理。
b端最重要的就是角色权限了,之前的公司做的还好,现在的公司产品最初设计的时候对角色权限这块考虑欠缺,导致现在有些功能想按权限来做,不方便,坑!
我现在接触到的角色权限基本上就是数据的增、删、改、查,业务流程上功能模块的分配,其他的还没有。你这边都有什么问题?举例给我分享一下吧
没什么新的,只是刚开始架构没设计好,没得这种权限的设计,导致后续加功能不好加
干货
我跟你一样,也是之前做开发的,现在做后台产品经理,我这边好像没你们那么明确,创业公司目前没有测试,也没有项目经理,需求排期需要我自己直接去对接开发,然后跟进项目
恩,创业型公司没有那么明确,这样刚好可以锻炼下,本来产品就需要对各个流程熟悉的。
我也是 🙂
干货!
多谢支持,第一篇文章 😉