Skip to main content
德胜云
  万速智能9 > 编程学习

居然可以这样「产品重构之旅回顾——“一场取精华、弃糟粕的产品革命” 再石资本夏中宝:用责任投资推动气候技术革新」重工品的定义重工业产品

2023-05-08 00:20:11 浏览:

居然可以这样「产品重构之旅回顾——“一场取精华、弃糟粕的产品革命” 再石资本夏中宝:用责任投资推动气候技术革新」重工品的定义重工业产品

如果产品的架构不良,或者业务的方向发生了变化,这时就需要对产品进行重构。本文作者在一次产品重构之旅中,收获了一些经验,有了飞速成长,遂将本次产品重构经历和经验进行分享,希望能给你带来帮助。

文章导读:

通常意义上讲,一个产品为什么要重构?

我们团队的产品为何要重构?

重构的目标是什么?

最终结果如何?

我是如何做的?

过程中遇到了哪些问题?分别是如何解决的?

收获与成长

最后谈一下 0-1 与产品重构哪个难?哪个易?

这次产品重构之旅,是我在漫漫产品路上,接触到的第一次关于 " 重构 " 的实践,收获了颇多经验,个人也因此在这 4 个多月中,有了飞速的成长,遂将本次产品重构经历和经验进行分享,以期帮助到有类似 " 重构 " 任务或有着 " 重构困惑 " 的产品 er 们。

01 通常意义上讲,一个产品为什么要重构?

先引用《业务中台产品搭建指南:电商业务平台全流程设计与实战》一书中,作者关于重构的原因及必要性的解读:

每个系统的诞生都源于业务需要,为了能够支撑飞速发展的业务,很多时候我们需对多个方案进行一些妥协来赢取时间。方案的妥协往往会造成架构不良,只能满足中短期需求,对于长期的延伸都有致命的伤害。

还有一种情况是业务的方向发生了变化或者融合,导致原有设计的结构需要进行重新设计调整。

如果把一个系统看作是一个人,那么人身体里面的骨骼、血肉就可以看作是系统的逻辑和技术架构,它们支撑着身体的稳定运行。而产品架构的逻辑和规则,则代表着这个人的精气神和性格,一个人身体再好,精气神如果不顺畅,身体早晚也会出问题。

所以每次重构既是对这身体的血肉和骨骼进行大刀阔斧的改造外,也需要对它的精气神和性格做重新的审视和定位。

结合我本次重构的经历来看,无不印证了上述书中作者的观点和看法。

1)我新加入的产品团队,组建时间不算短不算长,一年左右,为了满足团队初期的生存和发展,会承接一些商业化项目,基本上都是定制的,因此在架构设计上,也仅最大程度上考虑了多个项目的复用性,没有考虑 " 产品化 "。

举个架构不良的例子(真实例子):

团队前台产品(姑且叫做产品吧,实际是为几个商业化项目建的业务应用系统)运转用到的后台系统有:采集系统、数据治理与融合系统、信源管理系统(现在重构后的名字,之前的产品名字与产品功能极度不符)、工单管理系统、扫描系统等等。

其中 " 信源管理系统 " 的定位是用于运营和管理各类信源数据的,即增删改查和打各类标签用的。但是,在给各个前台应用使用数据时,却仅将采集到的数据经过【AI 模型】打标后,直接给到业务去用,完全没有 采纳 " 信源管理系统 " 的 " 运营管理成果 ",信源管理系统用的数据与客户业务系统用的数据,是两份孤立的数据岛屿。

很显然,这是极度不合理的业务架构设计。

如果不及早解决,任由这样的态势发展下去,很难想象团队会在多久的将来,会因为这些问题 "over",几个月?一年?——但可以明确预见的是:如果不解决这些问题,团队的资源将永远都不够、团队也将无法拓展更多新的业务,因为忙着修修补补每一个孤岛上 " 零零散散的部件 "。

2)团队此前有一个标品,但是是试水的 v0.1 产品,只有 1 个在线系统,没有产品需求文档、没有产品使用手册、没有技术设计文档,也没有什么人维护了。

02 我们团队的产品为何进行重构?

读完上面我举的例子,换作任何一个产品经理 / 技术都不能忍受吧,鉴于那么多问题,所以我们需要重构。再总结一下,我们团队的产品为何进行重构:

技术架构上有诸多问题,如后台各系统边界不清晰、数据是孤岛、无标准化前台产品等;

团队此前标品没有人运营维护了,且文档资料缺失。

团队核心业务发展的需要。需要整合几个核心业务系统(为项目做的)为一个 " 一体化平台 ",重新进行产品定位、打造标品并持续迭代,并努力成为行业内标杆产品。

03 重构的目标是什么?

——弃糟粕、取精华,对产品重新定位。包括产品目标行业与目标客户、产品形态、产品商业模式、产品价值主张的重新明确,产品架构和技术架构的重新调整和设计,以重塑产品的骨骼和血肉,让产品恢复精气神儿,让产品可以解决客户问题的同时为团队 " 挣钱 "。

本次产品重构的目标,是基于当时团队的业务背景需要,分成了几个阶段,每个阶段有着不同的目标:

阶段一:重新明确产品定位,设计产品业务架构,整合三个不同的业务应用(但业务流程及业务逻辑基本相同)至一个 " 一体化平台 " 中,共用一套后台系统,通过各类权限配置为不同类型的客户及用户提供产品服务。

阶段二:优化线上系统逻辑漏洞、功能优化完善,提高用户使用体验。

阶段三:重新设计后台产品架构,厘清各系统职责和边界,并分版本分别重构有问题的后台系统。

阶段四:随业务发展,再将各个系统中的一些功能模块剥离出去,形成单个子系统运转。

比如后续可将采集系统中的采集优先级判断、采集状态的管理从 " 采集系统 " 中剥离出去,形成 " 采集调度模块 ",而采集系统仅做采集的执行,这样整体的业务逻辑就会清晰很多。

再比如将积分规则设置、积分分配、积分管理等从用户管理中剥离出去,形成单独的 " 积分管理系统 ",这样也会减轻用户管理的负担。

为什么这样划分产品重构的阶段?

——在当时,我不能特别领悟为何要这样划分。只是按照老板的大致意思那样去做了。

甚至现在,团队研发在做后台系统重构时还在说:"XXX 后台系统本就该优先重构,然后再重构前台业务系统!现在都是反的 ~"

但真的是研发说的这样吗?

现在回过头来看,我想我理解了按上述节奏和周期去划分工作的原因:

1)为了维持团队业务的生存和发展,所以需响应市场需求、响应客户需求。

有市场需求了,有客户需求了,就需要赶快出客户用户 " 可见的 " 东西(产品 v1.0),后台乱成怎么样,客户和用户看不到。

2)为了占据客户及用户心智,所以要不断打磨产品,让用户看得见我们的变化。

后台不急着重构,原因是:在产品初期,占据客户及用户心智是很重要的,因此 " 俘获用户芳心的新功能 " 与 后台优化的需求相比,仍是 " 俘获用户芳心 " 的功能更重要。

3)等业务运转起来,且用户没有其它显著的使用问题后,再花时间和精力好好优化后台系统。千万要注意,后台的优化升级,不能影响到线上正常使用。

如遇其它重构任务,该如何合理地安排每个阶段的产品迭代工作呢?

——可以按照如下金字塔来执行(从底到顶):

(图引自《业务中台产品搭建指南:电商业务平台全流程设计与实战》一书,如有侵权,联系删除)

通俗一点概况就是:让业务 RUN 起来 ->让业务闭环 ->让业务流程完善 ->提高用户体验 ->再拓展其它新的东西。

上面的这个做事情的优先级顺序,同样也适用于生活、学习。比如学跳舞这件事:

目标是——老师教一支新的舞蹈,本节课你要学会这支舞蹈,长期目标是:你要学会自己跳舞。

可以怎么去做呢?

step1:你首先要将老师教的新舞蹈中的难的部分学会;

step2:然后将完整的片段记住,要能完整地跳下来;

step3:然后再是完扣每一块的动作,做得尽量标准;

step4:然后再是提高你跳舞的可观赏性(比如表情管理啊)考虑下台下观众;

step5:然后再是学习新的动作。

04 最终结果如何?

历时 1 个月,完成了阶段一的目标。最终成果是:完成了团队标品 v1.0(网络情报侦察一体化 SaaS 平台)的构建,并重新明确了产品对外服务的模式、以及产品所服务的目标行业及目标客户群体。

又历时 1 个月,完成了阶段二的目标。最终成果是:1 个月内完成了 2 个大版本的迭代,在春节复工后,正式开放给客户使用。

当前处于阶段三(第 4 个月),即在重构和优化后台的几个系统 / 模块,同时打磨客户高频使用的模块中。目前平台已经有数十个试用客户以及十多个正式签约客户了。

05 我是怎样做的?

这里分成这样两个大阶段:重构 0.1 阶段和重构 1.x 阶段,来分别介绍我具体是如何做的。

1. 关于产品重构 0.1 阶段

这个阶段主要是:明确重构的产品的业务目标是什么。

——即解决谁在什么场景下的什么问题?——你打算用什么路径去解决?计划什么时候可以解决?

带着这些问题,我开始行动了。

首先是与老板、与其它产品同事,沟通要一些产品资料进行学习和线上系统的亲自体验,目的是了解团队以前的业务都有哪些,以及与老板沟通当下及未来的业务重点或目标是什么。(攻哪个细分市场?当然是带着自己对行业的见解与老板谈)

接着,大致掌握了团队的业务及产品现状、团队及公司资源情况(技术人员情况等)以及产品未来的发力点(姑且认为方向正确,先入行再懂行)后,我开始着手调研目标市场、目标客户需求,目的是加深对行业、对客户的了解。

确认了目标行业、目标客户后,结合目标行业及客户的特点,制定产品对外服务的模式。像我们的产品,主要是有几种对外服务模式:一是 SaaS 系统,二是人工服务(如写舆情报告、人员调查报告等),三是数据服务。SaaS 是产品对外服务的主要模式。

2. 关于产品重构 1.0、2.0、3.0

这个阶段产品定位、产品形态已基本明确,主要任务是:具体产品的规划设计,包括业务模块的划分,产品架构设计以及每个版本功能模块的设计。

在这个阶段里,我是按照先搞前台,后优化后台的思路来进行的。

1)搞前台,是要将 3 个系统(一个舆情系统,一个公安核查工具,一个开源数据监测系统)进行整合,整合为一个前台应用,并通过各类权限配置为不同类客户提供服务。

主要是怎样做的?

先按照数据流向,梳理业务架构,并按不同的业务场景,划分功能模块。

接着,上手整合现有几个系统,功能合并去重、原有功能优化、缺少功能新增,最大程度复用原来的页面和接口,重点设计 rabc(基于角色的访问控制)部分。2)v1.x 版本已经上线,解决了 " 迈进市场第一步 " 的问题,但仍有很多问题和漏洞需要修复。

在这个阶段,主要是修复系统的诸多逻辑不一致、逻辑漏洞、业务未闭环、功能不完善等问题。

我是怎样做的??

逻辑漏洞第一优先级,逻辑不一致其次,业务闭环其次,最后优化不完善的功能。

注:逻辑漏洞问题应该在 v1.0 版本前解决掉,但因本产品推出时间紧迫,且初期仅开放给少量用户使用,所以放在了 1.1 版本解决。

本产品的逻辑漏洞例子:模块 A 和模块 B 用到了同样的 " 付费数据 " 查询功能,但模块 A 考虑了 " 扣除积分 ",另一个模块 B 不扣除积分,用户完全可以 " 钻空子 " ——这是由于之前模块 B 的系统是私有化部署交付给客户的,所以模块 B 并没有积分扣除逻辑。

3)x 版本已经上线,在 " 迈进了市场第一步 " 基础上,也积累了一部分用户了,这个阶段可以系统优化后台架构了,同时兼顾前台的优化。

在这个阶段,系统的稳定性、良好的架构设计、系统的数据准确性 & 及时性 & 全面性(做数据服务的厂商需要视业务重心酌情考虑),将能够帮助支撑更多用户的使用,让产品活的更久远。

4)搞后台,梳理出几个必要的核心的后台系统,明确它们的各自定位以及职责边界,以及它们之间的交互关系(还是可以参照数据的流向思路来梳理)。

06 过程中遇到了哪些问题?分别是如何解决的?

整个重构过程对我来说挑战极大。

一是我从来没做过后台,也从未参与设计过 rabc 模块,SaaS 系统当然也没有设计过了。

二是我 10 月 25 日入职,在 11 月上旬就要考虑重构事情,新环境、新同事、新业务、新行业,对我来说处处是挑战。

我是如何克服并解决的??

1)首先充分认识自己,对自己的不足与优势重新认识,对知识盲区疯狂查漏补缺。

我过往的优势是:有较丰富的 AI 类产品设计经验,以及可以很熟练地掌握产品规划的一些方案论,如华为的 " 五看三定 " 等,同时有着非常强的学习能力,以及调研能力。

对不足的地方,进行知识的查漏补缺。

比如 rabc 是什么,不清楚。

——我就去网上、去和前同事沟通交流、去看书,以此来构建这块相对完善的知识体系,然后才能上手设计我要负责的 SaaS 产品。

再比如,对团队的业务及产品目标不是很明确。

——我就逮住机会,和老板沟通交流(了解核心业务是什么、核心客户是谁),充分利用上班及空闲时间,亲自上手体验他们以前做的系统,并与相关同事请教,去了解每一个功能模块设计的初衷是什么、解决的是什么业务问题,并提出自己的思考

再比如,对后台的几个系统的重构和优化,从来没做过,大多系统没有界面,看不见摸不着,一头雾水。

——我就从数据流向开始梳理每个系统的作用和价值,然后搞清楚这几个系统当前是怎么互相配合(它们的交互关系)支撑业务前台运转的,然后再和每一个系统的研发沟通交流系统的主要功能以及核心逻辑,然后再基于自己的思考,发现当前逻辑的不足,并据此提出优化需求。

2)对我效率提升最大的就是:按照五看三定框架进行调研和设计。

整理文档,按照 " 五看三定 " 方法论(看趋势、看客户、看竞品、看自身、看机会;定目标、定控制点、定路径),来整理文档,每一块都由浅入深地去了解。

对于不是自己做的系统,唯一可以加深体验和了解的就是(尤其是在没有文档资料的情况下):自己亲自上手体验,有必要可以写一下操作手册,以方便后续回顾。

07 收获与成长

关于重构的实践与审视。

关于 SaaS 的实践与审视。

关于采集系统、运营管理后台系统的实践,以及系统前后台架构的整体设计。

关于知识图谱的实践(还不是很深入,主要是图谱可视化工具,以及简单的本体关系)。

关于抽象化思维的锻炼。

比如我们要管理 10 多类信源,每个页面如果都要开发的话,需要开发 10 遍,而将问题转化成提炼共性,去开发一个动态配置页面,将变得灵活许多也方便拓展,主要工作变为抽象提炼共性以及业务流程的设计。

08 最后谈一下 0-1 与产品重构哪个难?哪个易?

谈不上幸运的是:0-1(前两年)和产品重构,我均经历过。

从个人亲身经历感受来说,我认为产品重构相对难一些,难在于你要 " 填坑 "、你要 " 擦屁股 "、你要 " 复用 ",不像 0-1,你有很多发挥空间。

而不论是 0-1 还是产品重构,都需要你对行业、客户、市场调研了解,产品重构若只是后台系统的重构,不涉及面向目标客户的重构,则不需要了解市场这些,但也要清楚业务逻辑和业务流程。

写在最后

希望本文的内容,能够对你有所帮助。

产品经理,说难也难,说易也易。不知道自己会在产品这条路上坚持多久,至少现在还算热爱,期望每天都能比昨天的自己优秀一点,加油!产品 er 们共勉 ~~ : )

本文由 @南方碟道 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

居然可以这样「产品重构之旅回顾——“一场取精华、弃糟粕的产品革命” 再石资本夏中宝:用责任投资推动气候技术革新」重工品的定义重工业产品

  • 怎么可以错过「中国数据中心(IDC)行业发展现状分析 中国数
  • 学到了「中国IDC行业的定义和分类:数据中心、云服务和边缘计
  • 这都可以「三料冠军!IDC:金蝶位居中国SaaS第一」金蝶排
  • 不要告诉别人「全方位支持:选择华为云打造小程序轻松上云之旅」
  • 这样也行?「从0-1快速开启独立站市场(一)丨注册域名相关注