项目重构——文本短信推广重构

编辑导语：项目重构是一件特别耗费时间和人力的事情，项目重构比接手一个新项目更难；要在之前的系统基础上进行修改，首先要对之前的系统足够了解，对修改过程思路明确；本文作者分享了自己在接手一个项目重构时遇到的难题。

在近一个月我接手了我的第一个重构项目，虽然项目很小，但还是遇到了之前接手新项目时从未经历的波折，总结一下这一个多月我所踩过的坑和这个项目。

一、项目背景

我司为一家大型家电企业，在两年前直接由开发人员搭建了自己的短信发送平台。

随着业务的发展，原短信发送平台在功能、流程上难以支持现阶段的业务发展，为此需要对短信发放平台进行重构。

二、业务调研

1. 原业务分析

原短信系统在搭建之时，我司尚未有专门的产品经理，完全由开发人员开发，且没有搭建CRM系统，且各个系统的用户数据并未打通。

在此情况下短信业务流程如下：

在经过和实际业务人员访谈后存在以下问题：

短信内容、投放人群无法复用（原系统不支持复制）。客户筛选颗粒度太大，缺少合适的标签进行筛选。难以支持大型活动中所需的短信的精准营销，同一用户可能在当天会受到多条类似的活动运营短信。发送之后没有任何数据，难以评估短信效果。

2. 问题原因

原短信推广系统业务流程成单线业务流程，只存在短信发送一个实体，没有投放人群、短信内容等实体使得不能自由匹配。原系统开发时我司尚未有CRM和DMP系统等相关客户数据分析处理系统，所以只能自行对客户数据进行粗颗粒的划分。在原系统中未制定针对于客户接收短信的规则导致客户在一天之内接收过多短信。原系统未将短信发送后的数据进行整合、分析，导致运营无法估量效果。

3. 问题解决思路

实现短信内容、投放人群复用。（高优）实现CRM系统和短信推广系统关联。（高优）制定客户接收短信规则。（低优）建立数据库，制定数据界面反映短信回执效果。（中优）

三、改版目标

通过修改业务整体流程实现内容的多次复用，并通过调用CRM用户数据服务来辅助短信精准发送，收集相关数据帮助业务人员分析发送效果。

四、业务流程优化

短信业务主要涉及人员只有运营、运营主管；其业务比较简单，在项目重构时除了考虑短信平台本身的业务流程，还需要考虑在CRM系统中调用短信服务的流程。

最终业务流程如下：

五、确认数据

对于短信系统来说主要数据为：

客户数据：客户数据来源于重构后的CRM系统，人群筛选维度取决于之前客户购买记录和后续运营人员对于标签的管理，并通过分组和人群直接分类客户；在短信系统中直接调用CRM系统服务即可。

号码数据：由于考虑到短信系统之后会开放给销售公司，我司销售公司和门店自己保留着一部分客户数据（对总部保密）；所以除了直接从CRM系统中直接获得的客户号码外，还会有部分数据通过系统导入。

运营商返回数据：在短信发送整个业务中，我司能够从运营商拿到的数据仅有短信发送成功条数、短信发送失败条数，拿不到每个号码发送情况。

整体来说能够从运营商返回的数据有限，所以在之后的功能设计中需要增加更多数据收集方式。

六、功能框架设计

结合业务流程，以及与参与人员的访谈可以将整个系统划分为4个模块，分别为短信管理、统计分析、设置、账户管理。

除了考虑到之后功能扩展外还需要考虑到实际数据情况。

短信管理：为了之后的系统功能上的扩展性（我司有意做第三方平台类产品），将短信分为短信签名、短信模板、短信发送三部分，所有短信发送最终以发送任务的方式执行。设置：主要考虑对发送的设置和名单的管理，其余功能需要在和运营商深入合作后再扩展。统计分析：其实就是为了反映短信推送产生的效果，其分析大方向为从大颗粒—整体回执效果到小颗粒—手机号码进行分析，但现阶段我司还无法拿到每个号码短信执行情况。账户管理：主要考虑账户充值功能，现阶段我司还不允许直接线上支付，需要走财务部线下充值方式和平台转充的方式。

七、信息架构设计

在信息架构上更多考虑到之后项目迭代时功能扩展，以及之后整合至大型DSP平台，在结合功能框架后其信息架构如下：

八、数据建模

原短信系统中核心数据实体为短信、客户，对应关系为多对多，而优化后的短信系统主要数据实体为发布任务、短信模板、短信签名、人群和客户。

它们之间的对应关系如下：

九、项目细节设计

1. 状态设计

在整个过程中发布任务存在待审核、审核通过、审核未通过、发送成功、发送失败、终止6种状态。

在发布过程中送涉及到多个状态的转化，需要事先定义每种状态以及状态之间的切换条件。

2. 关键流程设计

在整个业务流程中最为关键的流程为发送任务发送、短信模板创建。

在短信模板流程中需要注意以下两点：

由于运营商的限制，短信内容中不得包含敏感词，在编辑过程中需要屏蔽敏感词输入。在短信中常常会含有网址链接，而网址链接会占有比较多的短信字数，为了减少占用的短信字数需要转换为短链。

而在发送任务发送流程中，主要需要考虑以下几点：

短信运营商收费按短信条数收费，一调短信内容字数超过70字就会算作多条短信进行收费，在用户编辑发送时就需要预先告知短信字数。运营人员上传或选中的号码，需要进行筛选，屏蔽掉投诉过的用户号码。在发送时需要考虑是否需要增加测试发送，以及测试发送是否需要审批，如果跳过审批可能导致短信内容不可控。

以上只是最为重要的两个业务流程，除此之外还需要考虑充值流程、终止任务流程等，在此就不全部展示。

3. 页面设计

系统涉及的页面不多，主要只展示关键的创建发送任务页面。

发送任务是整个短信发送业务流程的关键页面，有运营进行操作；页面涉及发送时间设置、发送号码设置、以及效果预览等。

在页面中增加了很多功能快捷入口保证整体流程的流畅性，提供短信预览帮助用户掌控效果。

4. 权限设计

因为我司已有权限系统，在我司权限系统中允许创建角色并分配权限，所以只需列出所需权限即可。

我司权限系统分为功能权限和数据权限，短信权限设计如下：

功能权限

数据权限

十、总结

这个项目总共花费了1个多月的时间，总体来说比较简单，但这是我接手的第一个重构项目，还是遇到了我没有想到的一些问题。

1. 没有文档

正如我前面提到的，原系统开发时科室还没有专门的产品经理，完全由3个开发人员开发，在重构时原本3位开发人员已经走了一位后端，且没有任何文档，所以首先需要梳理老系统中的逻辑。

在一些业务流程方面可以通过使用梳理流程，但很多隐藏功能却不容易发现，甚至原本的开发都不一定记得。

比如：原本短信内容敏感词提醒、发送短信数量显示是在整个短信在提交页面时才显示；原系统中还能加入邀请码，邀请码能够在手机小程序上核销等等。

2. 用户习惯

虽然之前的系统功能不足以支持我司的业务，但已运行了两年，且操作很简单；而重构后的产品新加了很多功能，但操作方面比原系统复杂了很多。

尤其是我司的销售公司、代理商、门店人员操作电脑的水平不一，在新系统上线后需要解决的后续问题还有很多。

用户会对重构后的系统抱有很大的期待，而且用户不会希望工具类产品只发挥工具的作用，他们实际上想要的是一套方案。

3. 重构后做什么不做什么

原本原系统重构就是因为功能无法支持我司短信业务的扩展，所以新增需求是肯定的；在调研阶段参考很多文本短信系统和与业务人员沟通后，手中就会有一堆功能点和需求，这个时候一定要区分哪些是系统所需要的。

而且必须要考虑公司与运营商合作的深度，不能照搬竞品的功能。

比如说很多短信系统中有号码黑名单的管理，但我司拿不到每个号码发送情况的数据，所以虽然黑名单功能有必要但也只能之后考虑。

本文由 @遥遥爱唠叨 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。