如何从0到1做后台产品的.docx

1、如何从 0 到 1 做后台产品的一 写在前面本人做后台产品已经不少时间了，在此根据自己的经历梳理出后台产品知识点，其实有些部分无论做什么产品都是相通的，重要的是方法。通过总结一是梳理一些知识，二是跟大家分享讨论心得。从整个流程来看总结为后台产品前期的设计-后台产品迭代-后台产品运营-后台产品特征这几部分。二 后台产品设计前期后台产品关注点1.产品定位与目标用户当从零开始，进行我们的产品设计之前，切忌动手画原型，一步一步梳理。首先，弄清楚做这款产的最终目的是什么，是为了提高内部人员的工作效率，从线下切到线上；是为了对公司的前台系统做出强有力的支撑等等。另外需要弄清楚系统的边界，哪些业务的实现是我

2、们系统该完成的，而哪些是不应该参杂到系统中的。那我们这个系统是给哪个部门哪些人用的呢？这些人根据职能可以分类为哪几个角色呢？例如呼叫中心系统为公司的客服部门服务，用户就包括负责接电话的客服，专门外呼的客服，还有负责资源来源的运营人员，当然还包括客服的组长，需要做一些管理工作等。理清楚后台产品的定位和目标用户之后，我们开始规划后台产品的用户权限体系。2.用户权限体系对于后台系统来说，很重要的一点就是用户的权限管理部分。每个角色各司其职，而后台系统的数据一般涉及敏感信息，需要有严格的权限控制。在用户权限体系的设计中，需要明白的是用户权限包括哪几个部分。据我自己的理解，用户权限的管理如下：权限细分为

3、两部分：功能权限和数据权限。功能权限就是可以看到哪些菜单功能；数据权限即我可以看到哪些数据，可以看到哪些人的数据等，数据权限一般根据系统业务的不同会有不同的划分。角色管理：根据目标用户的类型，对系统中的角色进行管理。角色的权限也包括有功能和数据权限。组织管理：不能的用户在公司属于不能的组织级别，例如一个小组长只负责他们小组的成员；但是一个总经理则是负责部门所有成员。所以有一个组织树的管理，一是可以清晰地看到系统中用户的组织关系；二是根据组织树，默认有一个人员权限的逻辑，即组长可以看到下面组员的数据。用户管理：给用户赋予某一个或多个角色，归属于某个组织，当然用户还可以单独设置自己的功能和数据权限

4、。3.业务流程与业务逻辑做后台系统，需要对涉及的业务十分熟悉与理解。这样才能在一个大的业务目标前提下，理解用户为什么会这样做还不那样做。整个业务的主流程是什么，会有哪些分支流程。在这些流程中有状态变化的流程用状态图呈现，还有业务流的动作变化用流程图呈现，对于不同角色不同不同职能需要用跨职能流程图实现。梳理业务流程后，我们才懂得其中的逻辑进而把他们搬进系统里。4.产品架构设计根据梳理出来的产品流程逻辑，我们可以规划系统的产品架构。应该有哪些菜单模块构成每一个菜单模块下有哪些页面，每个页面之间的交互关系是怎么样的每一个页面有什么功能，这些功能服务于哪些角色梳理产品架构时使用 xmind/mindm

5、anager 这样的思维导图工具时有利于理清思路。注意点：对于产品架构的设计我们还要考虑它的可扩展性，因为业务在不同那个时期会有变化，我们怎么才能做到更大程度适应这种变化，怎么做到能够复用现在已有逻辑和功能，最大化减少开发的人力和时间成本。我认为其中很重要的一点就是系统中各个功能以及对接其他系统的交互逻辑不要强耦合，尽量减少依赖。5.原型输出对于原型的设计，我们也遵循一个基本的步骤。系统页面布局：整个系统的页面主要以什么样的布局方式呈现，导航是顶部还是侧边栏。不同的展现方式各有优劣，需要我们根据自身系统来决定。页面主色调：系统页面主色调决定第一眼看上去的感受。对于后台系统来说，大多用一些深蓝色

6、等的冷色调。交互方式：交互控件如筛选/弹框等元素的打开方式，视觉效果的一致性。页面内设计：后台产品设计主要以简约原则为主，页面内对于信息的显示及按钮/文本框等的设计，都要起到引导用户的作用不能给用户留疑惑，让用户以最少的成本去完成想做的事情。例如操作层级不能太深，给用户少而够的选择，文本框给以适当的提示等。注意点：对于功能点和交互设计时，同样需要考虑到可能的性能问题，不要为了某个功能而使系统性能下降，导致某些功能速度很慢。后台产品产品界面设计可以不要炫酷，但是要保证基本的功能/性能体验好，这才是基础。三 产品迭代这里总结一些产品迭代的原则，其实应该是适用于所有产品的。确定大目标是前提。一般近几

7、个月/本季度/半年内本产品的目标。把握迭代节奏。产品迭代现在推崇快速迭代，基本是一周或一周半一迭代，发现不合理时可以及时修正。确定需求优先级。在需求池中根据是否紧急是否重要的原则，确定出每个需求的优先级，并预估每个需求的工作量，根据迭代节奏将需求安排到每个迭代中。每个迭代开发中原则上不插入其他需求。每次迭代的计划都已确定好的情况下，除非有特别紧急且重要的需求插入，不打破现有工作进度，否则我们的产品迭代计划会被打乱并且不利于管理。其实，对于后台产品经理来说除了对业务需求系统化，还需要对自己的产品有一个规划，即在特定的时间我们的系统要实现怎么样。在大目标前提下，我们可以提出更好的业务流程及产品解决

8、方案。四 后台产品运营后台系统也包含对于用户的运营对于数据的运营。1.用户运营后台系统的用户是公司内部的人员，我觉得这对于产品经理来说非常好。因为我们可以经常面对面地去跟用户沟通，了解他们的想法。需求挖掘：跟用户多沟通，可以了解到表层下真实的用户需求真正的用户而非心里所想的用户：有时做出一个满怀自信的功能，用户反而不用。为什么不用，功能没用处？体验差？这证明了用户的心声，但是我们都有机会去了解用户的真实想法，这样我们就可以不断进步。2.数据运营对于后台系统输出的数据一般涉及公司某个业务下的关键数据，这时数据沉淀积累与分析显得特别重要。数据分析：通过每周对业务数据的相关分析，可以看出一些涨幅跌幅，进而发现一些问题，提出对业务的一些改进。另一方面可以对一些重要的数据产品化，在系统中做成数据图表的形式。数据沉淀：数据慢慢积累下来，形成一个庞大的库，这对于以后的业务开展需要的数据分析及利用有很大的帮助。五 后台产品特征业务导向重功能实现而非用户界面设计用户基数一般不大需要跟各业务部门沟通：跟其他部门对接时要确定对接逻辑/技术对接细节（甚至细到什么字段）/统一时间点。当需要两方合作时，不要贸然按照一方的想法做或者不通知对方直接上线，任何涉及两方的信息都需要共享，以免出现意想不到的影响，因为每一方都有自己内部的业务逻辑。