后台产品知识点总结

努力向上终会有收获html

  1、写在前面架构

  本人入行产品从后台产品开始,已经有一年时间。在此作出这一年的作后台产品的总结,其实有些部分不管作什么产品都是相通的,重要的是方法。经过总结一是梳理一些知识,二是跟你们分享讨论心得。总结将会涉及到后台产品前期的设计-后台产品迭代-后台产品运营-后台产品特征这几部分。ide

  2、后台产品设计工具

  147070947453478070.PNG

  前期后台产品关注点布局

  1.产品定位与目标用户性能

  当从零开始,进行咱们的产品设计以前,切忌动手画原型,一步一步梳理。spa

  首先,弄清楚作这款产的最终目的是什么,是为了提升内部人员的工做效率,从线下切到线上;是为了对公司的前台系统作出强有力的支撑等等。另外须要弄清楚系统的边界,哪些业务的实现是咱们系统该完成的,而哪些是不该该参杂到系统中的。架构设计

  那咱们这个系统是给哪一个部门哪些人用的呢?这些人根据职能能够分类为哪几个角色呢?例如呼叫中心系统为公司的客服部门服务,用户就包括负责接电话的客服,专门外呼的客服,还有负责资源来源的运营人员,固然还包括客服的组长,须要作一些管理工做等。设计

  理清楚后台产品的定位和目标用户以后,咱们开始规划后台产品的用户权限体系。orm

  2.用户权限体系

  对于后台系统来讲,很重要的一点就是用户的权限管理部分。每一个角色各司其职,然后台系统的数据通常涉及敏感信息,须要有严格的权限控制。

  在用户权限体系的设计中,须要明白的是用户权限包括哪几个部分。据我本身的理解,用户权限的管理以下:

  ①权限细分为两部分:功能权限和数据权限。功能权限就是能够看到哪些菜单功能;数据权限即我能够看到哪些数据,能够看到哪些人的数据等,数据权限通常根据系统业务的不一样会有不一样的划分。

  ②角色管理:根据目标用户的类型,对系统中的角色进行管理。角色的权限也包括有功能和数据权限。

  ③组织管理:不能的用户在公司属于不能的组织级别,例如一个小组长只负责他们小组的成员;可是一个总经理则是负责部门全部成员。因此有一个组织树的管理,一是能够清晰地看到系统中用户的组织关系;二是根据组织树,默认有一我的员权限的逻辑,即组长能够看到下面组员的数据。

  ④用户管理:给用户赋予某一个或多个角色,归属于某个组织,固然用户还能够单独设置本身的功能和数据权限。

  3.业务流程与业务逻辑

  作后台系统,须要对涉及的业务十分熟悉与理解。这样才能在一个大的业务目标前提下,理解用户为何会这样作还不那样作。整个业务的主流程是什么,会有哪些分支流程。在这些流程中有状态变化的流程用状态图呈现,还有业务流的动做变化用流程图呈现,对于不一样角色不一样不一样职能须要用跨职能流程图实现。

  梳理业务流程后,咱们才懂得其中的逻辑进而把他们搬进系统里。

  4.产品架构设计

  根据梳理出来的产品流程逻辑,咱们能够规划系统的产品架构。

  ①应该有哪些菜单模块构成

  ②每个菜单模块下有哪些页面,每一个页面之间的交互关系是怎么样的

  ③每个页面有什么功能,这些功能服务于哪些角色

  梳理产品架构时使用xmind/mindmanager这样的思惟导图工具时有利于理清思路。

  注意点:对于产品架构的设计咱们还要考虑它的可扩展性,由于业务在不一样那个时期会有变化,咱们怎么才能作到更大程度适应这种变化,怎么作到可以复用如今已有逻辑和功能,最大化减小开发的人力和时间成本。我认为其中很重要的一点就是系统中各个功能以及对接其余系统的交互逻辑不要强耦合,尽可能减小依赖。

  5.原型输出

  对于原型的设计,咱们也遵循一个基本的步骤。

  ①系统页面布局:整个系统的页面主要以什么样的布局方式呈现,导航是顶部仍是侧边栏。不一样的展示方式各有优劣,须要咱们根据自身系统来决定。

  ②页面主色调:系统页面主色调决定第一眼看上去的感觉。对于后台系统来讲,大多用一些深蓝色等的冷色调。

  ③交互方式:交互控件如筛选/弹框等元素的打开方式,视觉效果的一致性。

  ④页面内设计:后台产品设计主要以简约原则为主,页面内对于信息的显示及按钮/文本框等的设计,都要起到引导用户的做用不能给用户留疑惑,让用户以最少的成本去完成想作的事情。例如操做层级不能太深,给用户少而够的选择,文本框给以适当的提示等。

  注意点:对于功能点和交互设计时,一样须要考虑到可能的性能问题,不要为了某个功能而使系统性能降低,致使某些功能速度很慢。后台产品产品界面设计能够不要炫酷,可是要保证基本的功能/性能体验好,这才是基础。

  3、产品迭代

  这里总结一些产品迭代的原则,其实应该是适用于全部产品的。

  ①肯定大目标是前提。通常近几个月/本季度/半年内本产品的目标。

  ②把握迭代节奏。产品迭代如今推崇快速迭代,基本是一周或一周半一迭代,发现不合理时能够及时修正。

  ③肯定需求优先级。在需求池中根据是否紧急是否重要的原则,肯定出每一个需求的优先级,并预估每一个需求的工做量,根据迭代节奏将需求安排到每一个迭代中。

  ④每一个迭×××发中原则上不插入其余需求。每次迭代的计划都已肯定好的状况下,除非有特别紧急且重要的需求插入,不打破现有工做进度,不然咱们的产品迭代计划会被打乱而且不利于管理。

  其实,对于后台产品经理来讲除了对业务需求系统化,还须要对本身的产品有一个规划,即在特定的时间咱们的系统要实现怎么样。在大目标前提下,咱们能够提出更好的业务流程及产品解决方案。

  4、后台产品运营

  后台系统也包含对于用户的运营对于数据的运营。

  1.用户运营

  后台系统的用户是公司内部的人员,我以为这对于产品经理来讲很是好。由于咱们能够常常面对面地去跟用户沟通,了解他们的想法。

  ①需求挖掘:跟用户多沟通,能够了解到表层下真实的用户需求

  ②真正的用户而非内心所想的用户:有时作出一个满怀自信的功能,用户反而不用。为何不用,功能没用处?体验差?这证实了用户的心声,可是咱们都有机会去了解用户的真实想法,这样咱们就能够不断进步。

  2.数据运营

  对于后台系统输出的数据通常涉及公司某个业务下的关键数据,这时数据沉淀积累与分析显得特别重要。

  ①数据分析:经过每周对业务数据的相关分析,能够看出一些涨幅跌幅,进而发现一些问题,提出对业务的一些改进。另外一方面能够对一些重要的数据产品化,在系统中作成数据图表的形式。

  ②数据沉淀:数据慢慢积累下来,造成一个庞大的库,这对于之后的业务开展须要的数据分析及利用有很大的帮助。

  5、后台产品特征

  ①业务导向

  ②重功能实现而非用户界面设计

  ③用户基数通常不大

  ④须要跟各业务部门沟通:跟其余部门对接时要肯定对接逻辑/技术对接细节(甚至细到什么字段)/统一时间点。当须要两方合做时,不要贸然按照一方的想法作或者不通知对方直接上线,任何涉及两方的信息都须要共享,以避免出现意想不到的影响,由于每一方都有本身内部的业务逻辑。

  好了,写到这里就差很少总结完了,仍需继续努力!

原文连接: http://mt.sohu.com/20160809/n463285525.shtml