B端产品,如何系统性进行重构?

1 评论 6725 浏览 93 收藏 20 分钟

产品经理一定要经历完整的从0~n才能在产品设计方法上比较游刃有余吗?这个想法还是太天真了。重构产品的方法与从0~1区别非常大,难度与挑战也远高于0~1。下面这篇文章作者就结合自己的经历,对产品重构做了梳理总结,想要了解产品重构的小伙伴赶紧来看看哦。

一、背景

曾经一度简单的认为产品经理一定要经历完整的从0~n才能在产品设计方法上比较游刃有余,后来经过一年多对一个产品重构后,发现以前的认知还是天真了,重构产品的方法与从0~1区别非常大,难度与挑战也远高于0~1,相信无论是做过还是正在做产品重构的同学,一定深有体会,这篇文章就结合自己的经历,对产品重构做个梳理总结。

我所重构的这个内部系统,在接手前已经做了一年左右,曾经的模式都是业务方一句话需求直接提到开发团队,然后各个开发根据自己的理解哼哧哼哧做两个星期,无论能不能用,好不好用,因为公司强制要求都在无奈使用,过程中也埋下无数坑,以致于用户使用起来痛苦万分,体验极差,领导对这个现状也不太满意。

经过一年多的改造和优化,我们的北极星指标–用户满意度(NPS)提升了49%,也达成了我们的预期目标,今天就把这个过程中总结出的方法、经验教训分享出来。

本文侧重讲解重构步骤方法,涉及部分细节就不在此展开过多了。

二、重构的方式

重构一般有三种方式

  1. 推倒重来:在原系统基础上重新开发,仅保留数据库等基础内容,上层代码重新开发;
  2. 另起炉灶:原系统保持运行,另起新项目,重新做个新系统替换,做数据迁移;
  3. 运行中改造:保持现有系统持续、稳定运行,同时对所需模块持续改造,直至达成目标

这里对这三种方式做个对比:

方式一是在原系统打算或已经废弃的时候才适用,而这种情况其实比较少,更多时候,我们所面临的重构场景是在方式二、三中选择。

从业务方和领导们的角度,通常倾向方式三,因为风险更小,感觉上成本更低,但实际上如果需要改造的模块较多,方式三的成本其实更高,因为有很多兼容、填坑、还技术债的事情;而从产研的角度,通常倾向方式二,因为不用考虑过多的历史包袱,处理起来更方便,如果需改造内容多,综合成本也更小。

至于最终选择哪种,就得结合实际情况来判断了。不过很明显方式三的挑战会更大,对产品经理的要求也更高,后面的内容,将基于方式三总结。

三、重构步骤

1. 前期调研

(1)内容

业务调研

所有的调研都是先从业务开始,在这部分的调研中,我们需要了解两部分:

  1. 业务所在行业的通用玩法,知道行业内一般都是怎么运作的,有行业认识;
  2. 公司的整体业务流程、业务特色、形成的历史渊源,其中要特别注意公司与行业的不同之处,一旦忽略就容易在后面改造中照搬行业玩法,导致与实际业务需求不符。

这两部分学习、调研的内容是相互促进的,通过观察公司业务运作可以更好的理解行业做法的含义,通过将行业玩法作为参考系可以发现公司当前所处位置及优劣。

用户调研

首先需要了解有哪些用户在使用现有系统,通过提炼用户差异性,将用户从多个维度进行分群(后面细聊如何做B端用户分群),然后就能找出对应群体中一些典型用户,通过一对一访谈深度了解他们使用系统的目的、路径、痛点、期望

不过一对一访谈效率还是比较低,所以需要增加问卷等方式,大批量收集用户目前的需求、槽点

(2)目的

  1. 从业务方、领导层、用户各方充分了解为什么要进行重构
  2. 对现有系统情况做一个整体的摸排,初步形成较为全面的认识

(3)输出

  • 公司业务流程
  • 公司业务特色总结,形成文档记录
  • 各角色用例图
  • 用户调研报告。包含用户体验地图
  • 用户问题/需求池

2. 旧逻辑梳理

(1)内容

对系统现有主体逻辑进行梳理,包括系统主流程、产品架构、产品结构、功能模块、功能点等。

由于还没到具体模块的改造,所以有些细节暂时可以不用太深入,等到改造到那块时再梳理即可,一方面因为有些细节即使提前了解了,时间长了到后面可能也忘了,另一方面是可能由于文档缺失或更新不及时,已经没有人能记得很清楚了,需要开发通过代码看出原有逻辑,所以细节梳理需要耗费巨大的时间、人力成本,影响前期进展。

(2)目的

这一步的目的是为了对系统现有功能、逻辑有整体认知,便于后续对比业务需求,发现全局性、架构上、偏底层的一些问题。

(3)输出

  • 产品主流程图
  • 产品架构图
  • 产品结构图(脑图)
  • 通过表格整体的各模块功能逻辑清单

3. 对比分析

(1)内容

通过对比业务实际需求与现有规则的差异,发现、挖掘出系统现存的一些问题,明确后续需改造的内容。

(2)目的

很多同学在对现有系统做重构时,需改造内容的信息来源是调研结果或自我感受,但从我的经历来看,这些信息还不够,主要原因有两个:

  1. 很多调研内容用户无法告知你应该怎么做,相当大比例的问题是普通用户意识不到的,用户反馈由于自身的很多局限,认识不够全面,同时也认识不到系统底层问题,更多的还只是一些交互、视觉层面的问题;
  2. 很多看起来不合理的逻辑,其实是符合业务特点和要求的,也有其特殊背景,只有最适合你的业务需求的才是好的设计。

这就是专门对比业务需求与现有规则差异的目的。

(3)输出

补充用户问题/需求池。通过对比发现的系统现存问题清单,与前面调研结果进行合并在一张表里

4. 问题/需求整理与分层

(1)内容

问题/需求整理

通过前面的调研、分析,我们就有了一份用户问题/需求池,内容非常多,这就需要对这份问题/需求池进行整理。

  • 按功能模块归纳
  • 将重复问题/需求合并
  • 将明显不合理问题/需求删除

问题/需求分层

除了将这些问题/需求按模块划分,还要对它们进行提炼总结,然后将这些问题按数据层–模型层–领域(业务逻辑)层–交互层–UI层五个层次进行分层

  1. UI层:纯视觉问题,如icon语义、颜色、样式问题等;
  2. 交互层:页面交互上的问题,常见的如菜单结构、操作控件;
  3. 领域层:各种业务逻辑问题;
  4. 模型层:底层模型设计相关,如原设计不合理,与业务需求不匹配,扩展性差
  5. 数据层:常见如数据混乱,不统一、来源不一致等

(2)目的

问题/需求的整理是大多同学都会做的,就不做过多解释,但分层则是很多同学没有意识到,其实非常重要的事情,接下来就说一下为什么要对问题/需求进行分层?

当我们面对大量的问题、需求时,往往会是一脸懵逼、茫然无措的状态,主要有两个原因:

  1. 问题太多,不知道从何下手,先从哪里开始;
  2. 当我们深入这些问题/需求会发现,很多问题/需求都是相互依赖的,由于是对现有系统改造,很多功能已经成型,当我们选定一块内容时,往往牵扯其他很多部分,一类是横向关联,即模块与模块间的关联影响,另一种是纵向关联,即表面上是交互问题,但很可能会涉及业务逻辑层、甚至模型层的改动。

而我们在对已有系统改造时,很容易出现影响面评估不足导致线上bug的情况,所以除了将问题/需求从横向功能上整理归类,还要从纵向涉及层次划分,这样可以更好的分析出关联影响面,另外,不同层次的问题改动成本、策略、方法、时间差异很大,对我们后面优先级评估也有较大影响,所以需要有纵向划分。

(3)输出

整理分类后的用户问题/需求反馈清单

5. 明确重构目标与指标

(1)内容

重构不是为了改而改,需要有目标的改,改造的范围、最终希望达成的结果,如何衡量,都是在改之前要考虑清楚的问题。

明确了目标,就需要定义相应的指标进行量化评估,包括评估最终结果的全局指标和评估每块功能的功能指标,以便有数据支撑。

根据明确的指标,需要做好前期数据收集工作,提前做好埋点等,才能对比优化前后的结果。

(2)输出

数据指标定义:

6. 分析优先级

(1)内容

对用户问题/需求整理后,就要分析优先级,确定改造重构的先后顺序,主要从四个方面综合评估:

  1. 价值收益。在看重构价值时,需要同时看短期和长期两方面,短期收益大(如交互体验上吐槽较多的问题)和长久的事情(如模型、数据层的动作)需要同时做,不要完全搁置某一类;
  2. 依赖关系。根据依赖关系,一方面可以明确先后顺序,另一方面对于依赖过多的内容,尤其底层的改动,需要多花时间好好分析、好好讨论;
  3. 改造成本。需要根据成本评估ROI
  4. 资源支撑。

(2)输出

用户问题/需求反馈清单中的优先级结论

7. 模块调研

(1)内容

第一步的调研,主要是为了形成整体认知,还没深入到具体模块的细节中,当我们确定要重构的内容及优先级后,再对具体要改造的内容有针对性的做用户、竞品调研,就会更有收获,集中精力琢磨透一块内容,用户的痛点有哪些,使用的场景有哪些,同时看看其他竞品的针对这些问题的处理方式,也可以称为功能调研。

(2)输出

  • 对应场景用户调研结论
  • 对应功能竞品调研结论

8. 制定、实施优化方案

接下来就是根据规划的优先级来逐步改造优化了。

无论是一个产品还是模块的重构,这个流程方法都是通用的

四、感悟

最后从产品设计和心态分享几点在重构中体会比较深的感悟。

1. 产品设计

(1)敬畏用户习惯

重构需要改很多内容,当涉及到交互层,需要改变用户原有的使用习惯时,一定要三思而后行,首先要考虑的是能否保留用户的使用习惯,哪怕这个习惯不那么符合规范,与通用做法不太一样,也要首先考虑保留,其实很多交互方式没有对错之分,只有是否合适之分,用户用得舒服才叫合适。

如果实在需要改,就要好好考虑如何延续系统的风格,过渡更平缓,怎么更好的告知。

用户习惯不是仅仅“考虑过”就足够了,是真的需要敬畏的心态面对,否则用户会用中华国粹回敬你。

(2)不可避免的“浪费”

为了节约成本,我们大多希望一步,尽量减少后面的反复变动,不过产品重构有时候会出现一些不得不做的“浪费”,主要有两个原因:

  1. 为了让用户、数据平稳过渡,有时会增加一段过渡期,这段过渡期可能是临时方案,等后面时机成熟会再变化;
  2. 因为是在进行中改造,所以有时需要兼容新旧两套逻辑,从而增加额外成本

(3)用户价值=(新体验-旧体验)-替换成本-感知门槛

所有产品动作根本上都是用户价值驱动的,俞军老师的用户价值公式大家应该都很清楚了,在这个公式的基础上我在后面增加了一个【感知门槛】,即用户感知到你新体验带来价值的门槛有多高,门槛越低,带来的价值越大。

可能俞军老师已经把【感知门槛】算到【替换成本】里了,这里我单独列出来,目的是想强调这部分,因为有时候会出现自己感动自己的情况,觉得我们做了一个非常棒的优化,用户这群白眼狼怎么就不领情呢,原因可能你这个优化确实很好,但用户没感知到。

(4)随时可回滚

没有人能保证每一次改动都是向好的,哪怕不出bug,可能由于有的场景没考虑到导致新功能产生负面影响,所以从功能上要保证随时可回滚,从数据上每次数据库刷数据前有备份。

功能回滚基于现在的代码管理能力大多都具备,只要分支与需求关联比较规范,不过数据库备份是容易忽略的,所以要特别提醒服务端同学,做大改造需要刷数据前,做好数据备份以便数据回滚。

(5)小细节能有大回报

产品重构很多是用户使用太痛苦,而改变这种痛苦不一定都是要做大的变动才能让用户减轻痛苦,很多细节优化能有大的回报,例如增加最近使用、操作记忆等。

2. 心态

(1)重构是对产品能力淬火的绝佳机会,而不是火坑

接手一个前人留下的产品,是很多同学极不情愿的事情,就觉得是一个大火坑,都不知道怎么下手,都希望自己可以从0~1做一款产品,挖的坑让后面的人填。

我最开始的心态也是如此,但随着一年多的重构,会发现这其实不是火坑,而是对你产品能力二次打磨的火炉,当你深度长时间跟进后,你会对用户、场景、业务这几个词的理解更深。

(2)锻炼大心脏

产品重构确实很容易变成吃力不讨好的事情,你会随时受到多方的压力:

  • 用户会喷你。因为改了用户习惯被喷,因为加了些“乱七八糟”的被喷,因为不被理解被喷,总之有各种理由;
  • 前人留下的坑。你永远都不知道下个坑会在哪里,测试也回归不到,等到线上用户发现,就成了线上事故;
  • 上级压力与用户适应节奏矛盾。上级希望在短时间内看到变化,但其实这比从0~1花的时间要更长,除了各种挑战外,更重要的是要给用户适应的时间,不适合在短时间做大幅度的变动,而这种矛盾难以调和;
  • 不确定的风险。你也不知道这个版本的改造、优化上去能不能被用户接受,最终能否拿到你要的结果。

你需要同时面对更多的压力,所以调整好心态,锻炼大心脏才能更面对各种质疑和压力。

专栏作家

周翔,微信公众号:B端产品周翔,人人都是产品经理专栏作家。畅销书《不枯燥的B端产品实战课》作者,前钉钉产品经理

本文原创发布于人人都是产品经理。未经许可,禁止转载

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

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 文章不错,经历过深有体会!

    来自四川 回复