本人从事b端后台产品已有1年时间，目前负责面向公司内部人员使用的管理平台，先后参与过后台商品中心、订单中心、营销中心和资源中心的产品设计工作。现将这1年的后台产品工作进行简单的总结，后期抽空再针对每一个项目进行详细的输出。

1.尽可能的熟悉业务

入职初期，尽可能的通过同事和导师了解和熟悉公司的业务。例如了解公司的商业模式，主要的竞品、公司的阶段性目标和愿景。

多找业务部门领导进行沟通，站在业务部门的角度去思考问题，能够拓展思维；

2.了解需求背景和明确目的

当leader基于某个业务的需求，向你安排任务时：

你需要了解你的需求方是谁？目标用户是谁？

尽可能了解需求背景和需要实现的目的，只有在了解的基础上,你才会知道为什么会有这个需求、要解决什么问题以及期望达到的效果；这些都有助于你在产品设计中把控需求的边际和划分产品功能的优先级；

3.基于场景去设计产品

无论是c端产品还是b端产品，都要基于用户角色、使用场景和功能去思考和设计。产品经理需要将角色、场景和功能组织成一个个用户故事，定义清楚每个功能的主要场景。只有这样，无论是开需求评审，还是交互设计、ui设计、测试用例评审，你的产品设计才具有说服力，相关同事才能基于你设计的场景去思考和联想，有助于对方理解。

4.借助图形描述产品逻辑和流程

不同模块功能的产品设计，描述产品逻辑的图形也有侧重点。好的产品经理不仅是一位会讲故事的人，同时也是一位画图高手。画图的目的主要是通过图形化的语言简单明了的将你的产品逻辑进行表达，画图也是梳理和思考产品逻辑的过程，有助于定义核心业务主线和明确产品目标。

我在商品中心和营销中心时主要使用流程图、订单中心主要使用状态机和泳道图、资源中心因为设计的端和业务较多，前期主要借助业务地图描述产品主逻辑，后期利用流程图描述具体业务场景。在产品框架建设完成的基础上，主要借助脑图进行详细功能点的输出。

5.MVP最小化可行产品

我在接触业务需求方时，发现他们对于当前的业务有时候也会存在需求不明确，不知道当前阶段需要什么。这时候，我会用MVP的方法去设计产品，基于用户的核心需求和目标，以最小化的产品版本让产品主流程跑通。后续再根据用户反馈进行产品迭代和优化。

6.需要考虑业务的拓展性

后台产品是为公司业务发展服务的，在接手一个需求时，最好能够结合公司的战略和发展目标去思考和设计，这样在产品和代码设计时会为未来做预留。比如当前公司商品的类型只有实物类商品，你在设计时需要考虑后期会有服务类商品，因此在设计筛选、搜索和列表时，要考虑这两种不同商品的共性，提炼共同的字段。

7.不同后台产品的特点

后台产品从产品类型分为工具类、记录类、配置累和关系类，目前我负责的产品接触最多的是记录类和配置类。

（1）记录类

记录类产品的主要功能是增删改查，方便业务人员进行管理和操作。我总结了记录类产品在产品设计时的注意点：

需要知道数据的来源、产生和过滤的条件以及数据的流向；

列表展示需要考虑对于操作人员哪些是关键和重要的字段，哪些非关键字段可以放在详情页中展示，避免列表展示冗余；

筛选和搜索的目的是通过多维度的查询条件帮助业务人员快速找到需要的信息，提高工作效率，因此筛选和搜索要精简和准确。可以和业务人员多沟通，哪些字段是他们使用频率较高和关注的字段；

操作的限制条件需要考虑全面。业务人员会进行输入、编辑、删除等操作，在操作时需要考虑哪些字段是可修改、哪些字段是不可修改的、操作的条件是什么、操作后带来的影响；

需要考虑可逆性和容错性。操作前通过一定的指引和提示告知用户误操作带来的后果；操作时对于一些重要操作二次确认避免出错；另一方面发生误操作时可以进行恢复和还原，减少损失；

(2)配置类

配置类产品主要面向运营人员提供服务和营销工具。常用的配置产品包括活动和优惠券配置、内容管理配置、推荐配置、角色权限配置等。

需要考虑配置项的合理性。配置类产品期望通过设置、推送、推荐或者干预等人为手段达到某个效果，因此选取或者输入的配置项要符合关键条件，避免选取大量无用信息；

配置生效的影响范围。配置后台一般与前端产品具有很强的关联性和联动性，需要明确前端生效的触发条件、配置会对前端造成什么影响、影响的范围以及影响的时间。

编辑配置项时需要考虑哪些项是可编辑的，哪些是不可编辑的以及可编辑的条件。