通过一个例子，来聊聊 To B 的后端产品重构

从大众的观点来看，后端产品是给少量管理人员使用的产品。相对C端，后端产品在交互和流程上对易用性和可用性的要求较低，产品应用只要能完成基本的功能需求即可。这个产品设计思路导致很多 to B 的产品在流程和过程上就不够清晰，增加了使用困难。用户在使用后端产品时苦不堪言，却又迫于要完成工作而不得不使用。

笔者所在的公司就是一家典型的 to B 的教育行业的公司，为中小学提供教育信息化的软件产品。在笔者入职之后，接手的一些产品由于开发时间比较古老，交互和易用性上有很大问题，导致在软件产品销售和使用上都产生了极大的隐患，因此在笔者就职的三年间，利用各种资源开始各种产品重构。重构之后的效果是毋庸置疑的：在 to B 的软件依靠销售量存活的情况下，某个重构后的产品从多次竞标PK失败，到一跃成为销售额占产品线前3，效果让人惊喜。

一、后端产品重构的规划该怎么做？

1. 确定后端产品重构的目的

产品重构就工作量和消耗公司资源而言无疑是巨大的，并且不是那么容易被老板所能理解和接受的。当决定重构一个产品前，首先我们要确定重构他的目的是什么，重构所消耗的资源是否能够解决当前的问题并在之后提高产品的销售量和市场竞争力。

常见的产品重构原因有：

1. 交互老旧，易用性差，需要复杂培训才能使用；
2. 功能间逻辑关系混乱，流程不清晰；
3. 底层结构不支持新需求，拓展性差。

常见的重构目的有：

1. 用新的交互模式提高易用性，增加可以看懂的说明来避免大量复杂培训，降低培训成本
2. 将不合理、无人使用、不通用的功能砍掉，将功能间的关联尽量扁平，方便使用。
3. 利用界面美观来提升用户第一观感，增加竞标的优势。

终极目的：

1. 增加产品销售额
2. 减少使用者的沟通成本

2. 产品重构的流程

当你接触一个产品，并且决定对这个产品重构的时候，首先就是要了解这个产品的所有功能以及功能之间的关联关系。尤其是 to B 的后端产品，每个产品都有大量不同的角色和权限，经常导致新用户无法快速的了解和使用。

作为产品经理，当你接手一个产品时，首先就是要掌握整个产品的所有功能的关联关系。尽管PRD文档或者产品白皮书能够让你快速了解这个产品有哪些功能，但是功能之间的逻辑关系仍然可能不够清晰（完全取决于上一个写文档的人是否认真）。

我的方法是，不论是否有相关的PRD文档，在决定产品重构时，第一步就是自己把这个产品的全部的角色、菜单、权限甚至于每个页面上的每个功能都是做什么的，整理成一个脑图，并且标注上自己认为不合理或者需要改进的功能点。如果这个产品有复杂的流程，最好还要写清楚产品应用的流程是怎样的，确定流程是否合理。

以最近重构的一个应用：在线选课为例，简单讲讲产品经理在重构过程中都做了什么。

在线选课，旨在给K12的学校用户提供校本选修的选课功能的一个应用，可以支持教师申报课程，教务管理员审批，学生在特定时间选课的功能。

（1）梳理流程和主要角色对应的权限和菜单

在线选课涉及到三个角色：管理员、授课教师及学生。先需要整理出原有产品设计的流程和拥有的菜单。可以看到，大部分复杂的流程和功能都集中在管理员端。

（2）对整个产品的流程进行优化，并且需要达到最后你想达到的目的

to B 后端产品的特点就是功能多、角色多、菜单多、逻辑复杂。在重构时，假设产品是有固定流程的，那么将你认为合理的、符合逻辑的流程标识出来。然后在充分调研的情况下，对一些没有任何用处的、不通用的功能砍掉。最后整理成一个菜单、角色、权限的功能列表。整个过程其实和做一个全新的产品类似，梳理流程，梳理功能，梳理角色。甚至于因为有一些原有的逻辑和设计缺陷，你不得不重新思考设计产品的新方法。继续以在线选课为例，原有系统流程不清晰，重构的目的是要让用户在没有培训的状态下就能快速使用和了解对应的功能。因此在重构新版时，需要标识出新流程及新流程上的一些需要解决的问题。如图所示（脑图内容未全部展示）。这其实和写一个完整的PRD没区别，但是用脑图的方式反而让整个流程更加简单明了，而且效率更高。

（3）原型设计阶段

在原型设计阶段，你需要和UED（如果有）部门进行深入的探讨如何让流程更加清晰。这个流程清晰不仅仅体现在界面的展示上，包括一些提示信息及使用帮助都能让你完善整个流程，减少用户使用的培训成本。在原型设计上，就不多做赘述，如果能整理出来清晰的流程却画不出来清晰好用的原型，那可能你需要一个专业的交互设计师来拯救你的产品重构了。最后画好的原型建议让用户体验一下，或者是让其他的产品经理体验一下，提出一些意见，说不定有些就会成为产品的亮点。

（4）协调资源，给老板画个大饼

在产品重构中，需要用改进的目标和试图达到的效果让老板知道你在做的这个事儿很重要，能够提升销售量和减轻工作量。同时你还要跟研发、测试讲清楚，重构的目的是为了让别人少来骚扰他们，保证大家对重构这个事儿没有怨言。毕竟重构，还是一个很费事费力的事情，基本上一个后端产品想要完全重构到没有bug，少说半年，多则一年。

总结一下，产品重构的流程4步：

1. 整理旧版本功能、逻辑、菜单、权限
2. 确认新版本功能、逻辑、菜单、权限
3. 画原型
4. 通过给老板画大饼的方式，协调对应资源

3. 重构的效果评估：不同人的关注点不同，效果评估的周期十分漫长

在花费大量的时间和成本将产品进行重构之后，老板肯定会关注这个重构的效果是怎样的，销售的数字有没有变好看。而作为一个产品经理，你要确认的是重构之后的产品有没有达到你想要的易用性强、减轻培训工作量、是否有拓展性等等。这时，通过新版本上线后的用户的使用反馈就能感觉出来重构的第一印象。

笔者就职的公司由于产品流程复杂，导致很多应用都是公司的交付人员协助用户使用，因此产品的第一使用人群实际上不是最终的用户，而是公司的交付人员。可以直接在产品发布前，让这些人提前使用一下，通过观察他们面对新版本时是否惊喜、是否觉得满足了需求，来暂时判断重构的效果。

当然，销售和盈利也是评估重构效果的一部分。但是往往销售和盈利需要经过一段时间才能看出来，例如一年，两年。

例如笔者曾经重构的一个用于教师备课的平台，在15年重构完成，但是15年的销售业绩并没有过高增长，反而在16年被很多学校客户使用和推荐之后，销售额有了质的飞跃。

二、其他一些小感想

通过整理产品的功能列表和清单，笔者还在这中间发现了很多有趣的事情。

笔者前后带过4个产品新人，每次给他们出的第一个工作任务，就是整理某个产品的功能清单和内部逻辑并提出疑问。

这个工作看起来很简单，就是把整个产品的流程过一遍，写下问题。但是几个人给出的成果物是完全不同的。同样都是没有做过产品的新人，在他的产品素质还不能确定的情况下，这个任务竟然能够轻松的看出来谁对产品的sense更强，谁能提出更好的优化方案，谁的逻辑更清晰。

这是一个很有趣的事情。如果是让新人做一个全新的产品，可能难度还是比较大。因此对已有产品做功能整理这个简单的工作，是考验产品新人逻辑思维能力、工作认真程度、独立思考能力甚至执行力、沟通能力（毕竟有些细节还要去问具体的研发或者测试或者带她的产品）的很好的方法。

题图来自 摄图网，基于 CC0 协议

作者：CresYan

来源：人人都是产品经理