立即登录 项目重建这件事，耗人耗力，远比从零开始做一个新项目麻烦得多。你得先钻进别人留下的系统里，把来龙去脉摸清楚，才敢动手改。作者最近刚经历了一回，下面是他实打实踩过的坑。
上个月，我接下了职业生涯第一个重建项目。项目本身不大，但波折程度远超预期——有些弯绕，接新项目时绝对碰不到。
---
公司是一家大型家电企业，两年前开发人员自研了一套短信发送平台。当时没有专职产品经理，也没上CRM，各系统用户数据各自为政。两年过去，业务量上去了，老平台在功能和流程上都显得捉襟见肘，重构势在必行。
业务调研
老系统的硬伤，聊下来主要有这几处：短信内容和投放人群无法复用，每次都得重新配置；客户筛选粒度太粗，没有合适标签，做不到精准圈人；大促期间同一用户可能收到多条相似短信，体验很差；发完就完了，没有数据回流，效果根本没法评估。
细究起来，问题出在设计上。业务流程是单线的，只有"短信发送"这一个实体，人群、内容都没独立出来，自然谈不上灵活组合。当时公司也没有CRM和DMP，客户数据只能粗分。更没设接收规则，一天内重复触达没人管；发完的数据也没沉淀，运营两眼一抹黑。
解决思路也定了优先级：短信内容和人群复用、对接CRM系统，这两件事最急；建数据库输出效果数据接口次之；制定客户接收规则可以往后放放。
改版目标
理顺整体流程，实现内容复用；调用CRM的用户数据服务辅助精准发送；收集数据，帮业务人员看清效果。
业务流程优化
短信业务的核心使用方是运营总监，逻辑相对简单。除了平台自身的流程，还要考虑CRM调用短信服务的场景。最终流程定稿后，才进入下一步。
确认数据
系统主要处理三类数据。
客户数据来自重构后的CRM，人群筛选基于历史购买记录和后续运营标签，分组后直接调用。
号码数据有点特殊。短信系统要对销售公司开放，而销售公司和门店手里有一部分客户数据，对总部是保密的。所以除了CRM直连获取，还要支持系统导入。
运营商返回数据目前只能拿到发送成功数和失败数，到不了单号级别。这个缺口，后续功能设计得想办法补上。
功能框架设计
结合业务流程和访谈结果，系统拆成四大模块。
短信管理为后续扩展第三方平台做准备，细分为短信签名、短信模板、短信发送，所有发送最终以任务形式执行。设置当前先做发送设置和名单管理，更深的功能要等运营商合作深化后再说。统计分析反映推送效果，方向是从整体Receipt效果逐层下钻到单个手机号，但现阶段还拿不到单号执行数据。账户管理主要是充值——公司不允许线上支付，只能走财务线下充值或平台转充。
信息架构设计
这里得为后续迭代留足空间，还要考虑未来与DSP平台的大规模集成。结合功能框架，信息架构最终成型。
数据建模
老系统的核心是"短信"和"客户"两个实体，多对多关系。优化后变成发布任务、短信模板、短信签名、人群、客户，实体间的关系重新梳理了一遍。
项目细节设计
任务全生命周期有六个状态：待审核、审核中、审核通过、发送成功、发送失败、已终止，状态间的流转条件要提前定义清楚。
最核心的两条线是短信模板和发送任务。短信模板要注意运营商的敏感词限制，编辑时要实时屏蔽；短信里的网站链接通常很长、占字数，为节省成本需转短链。发送任务这边，运营商按条计费，超过70字算多条，编辑时得提前告知用户；要过滤投诉用户号码；还要不要加测试发送环节、测试要不要审批，都得想清楚——跳过审批的话，内容风险可能控制不住。充值流程、终止任务流程也是类似逻辑，不展开。
系统页面不多，重点说发送任务页。这是整个流程的核心操作界面，包含发送时间、号码设置、效果预览。为保证流畅性，加了不少快捷入口和短信预览功能，帮用户把效果关。
权限方面，公司自有权限体系支持创建角色和分配权限。短信系统的权限分功能和数据两层，按实际需要配置即可。
---
这个项目做了一个多月，整体不算复杂，但作为第一个重建项目，确实碰到了意料之外的问题。
没有文档
前面说过，老系统没有产品经理，三个开发人员搭的。等到重建时，后端已经走了一个，文档更是一份没有。我们只能先扒老系统的逻辑，流程类的还能梳理，隐藏功能根本挖不全，连原开发都不一定记得全。比如提交页面时的敏感词提醒和发送条数提示，还有个邀请码功能——能在小程序上注销，这些不细查根本发现不了。
用户习惯
老系统虽然功能弱，但跑了两年，操作简单。新系统功能多了，操作也复杂了。销售公司、代理商、门店的人员电脑水平参差不齐，上线后问题不会少。更要命的是，用户对重建期待很高，他们不只是要个工具，想要的是整套解决方案。
重构的边界
重建是因为老功能撑不住了，新需求肯定要加。但研究了一堆竞品、聊完业务后，需求会堆成山。这时候得清醒：哪些必须做，哪些做得了。尤其要看清公司和运营商的合作深度，不能照搬竞品。比如黑名单管理，竞品都有，但我们拿不到单号发送数据，这功能就只能往后放。