时间: 2021-07-30 11:33:01 人气: 13 评论: 0
近半年多以来一直在做重构的项目,从运营后台重构,到中台passport重构,最后换了家公司继续做纯C端的前台页面重构。踩过很多很多坑,积攒了挺多经验,总结出来准备产出一篇文章。
主要总结重构项目的前期准备,前期准备工作是产品经理应该投入时间最多的阶段,包括了需求调研、数据分析、老系统/老版本逻辑梳理、重构版本逻辑定义等等。甚至前期准备工作决定了重构项目的质量以及重构后的用户满意度,本文将各种场景下重构项目必不可少的准备工作抽象出来,以实例进行拆解。
文章较长,其实浓缩出来也就一张图,下面所有内容都是对这张图的注释:
关于重构项目,本人有一个核心观念:重构项目一定是在填历史遗留的坑。当老板发现系统不足以支撑业务发展,或者严重阻碍业务发展时,“重构”的需求就开始从中高层酝酿起来。
比如之前规划后台时没有一个好的架构师,没有预想到后面的业务发展和业务形态变化,十几个运营后台堆起来,运营操作一个流程需要频繁切换多个后台才能完成,这时候运营的老大**喷设计这些乱七八糟后台的人,同时也**提出“统一运营后台”的需求,具体需求为:“所有运营操作集成到一个后台,流程能简化的全部简化。”
需求就这么一句话,拆解起来就得看具体有多少后台了(产品背锅原因之一:业务侧需求不明确,一句话需求)。如果说只有三五个分别控制不同模块的后台,并且不太复杂,建议不要重构,而是应该在做第六个后台时候考虑到后面的业务发展场景,做一个高扩展性的后台,然后再陆续将前五个容纳到这个后台来。如果有十几个后台,并且其中耦合了大量的交叉逻辑,那么只有重构一条路可走。
(产品也不易,背锅且珍惜)
“重构”需求大多是自上而下的需求,管理层出于对各种原因的考虑,提出重构的需求。作为基层产品经理,需要有自己的判断,到底是“重构”更好还是“优化”更佳。
评估重构价值需要先明确重构的原因,一般而言重构只有以下四类原因:
还有一种常见的原因:年久失修。不管用户还在不在,领导层决心再捡起来做的话,老代码老逻辑的维护成本远高于重构一番。此时请一定好好善待那些不离不弃的老用户,他们很可能因为重构没有契合他们的习惯就走掉了,临走前还要喷你一顿:“改的什么玩意儿!”。
(改版后的B站-UI&布局整体调整)
根据重构原因,评估重构能够带来的价值,同时评估正常迭代能带来的价值,当“重构价值>迭代价值”时,“重构”需求才能接手,否则可能就是“瞎重构”,或者重构完了也没人愿意用。
那么如何评估重构价值?
这是一个需要量化的多维度指标,可能是节省了运营多少人天的工时,可能是提升了用户留存,可能是提高了某个核心指标等等。在这些重构带来好处的维度指标中,选择最为核心的一点或者亮点,作为重构的核心目标。
例如统一运营后台,核心目标就是节省运营工时;统一中台化服务,就是节省前台开发工时;C端产品重构,就是为了拉升某个核心指标。
作为产品经理,在做“重构”项目时,其实最重要的就两个词:梳理和定义,梳理旧的逻辑,定义新的逻辑。无论是后台、中台还是前台相关的重构,基本上大同小异,都可以按照下面的方法去操作。
其中,后台和中台大多数还是给公司内部人使用,重构得不是很好还有机**继续迭代优化,而前台ToC的产品重构,做得不好可能就得承担用户血喷甚至流失的压力,同时前台的重构一定**涉及到后台或中台的调整。因此,本文以重构压力和产品发挥空间最大的ToC前台为例进行说明。
产品确定要进行重构之后,立即新建两个文档,一个调研文档,用来辅助产品设计,一个需求文档,逐渐更新为最终输出的PRD。同时,需要督促开发也新建技术文档,对核心重构内容进行技术调研,对于初步明确的大方向提前做好技术准备,减少开发说“这个实现不了”的概率。
调研文档必须包含的六个版块:旧版拆解、数据分析、用户画像、竞品分析、需求池、重构目标。六块少了任何一部分,我认为都**对产品方案的制定产生影响,也**对最终的重构效果产生影响。
无论旧版是不是你做的,只要是重构,一定要详细拆解旧版,拆得越细越好。一般重构项目,可参考的历史文档都非常有限,即使有文档也最好自己亲自细细体验。拆解旧版最终要产出的四个东西:页面结构图、前台与中后台交互的流程图、交互说明文档(关系到后面的继承性产品设计)和特殊处理说明。
(虎扑M站改版前后对比)
曾经一位开发对我提的老版本加上埋点的需求不以为然,认为都要重构的东西了,没必要在老版本上面加埋点。我列了三条理由说服了开发加埋点:
用实例进一步解释这三条理由,假如知乎文章发布页重构,首先确定一个核心数据指标,假定为发布成功率。那么需要知道老版本的这个数据是多少,重构版本与此对比来看改版效果(这里还需要限制约束条件:在发帖页平均UV波动不**过5%的前提下)。
其次,分析功能点,假如数据分析发现用户在上传视频的时候有5%的概率的失败,失败后又重新传,那么新版断点续传的功能优先级很高,同时进一步分析失败原因,新版要大幅降低这个值。
用户画像简单说就是给用户打标签,用户是男是女,喜欢什么东西,什么时候活跃,活跃时候都看了些什么。无论是在做什么项目,了解用户画像都很有必要。可能在重构项目期间,产品经理不清楚用户画像也能很好地完成重构项目,但是了解用户画像的产品经理思考的深度和视野的广度都远甚于前者,换句话说:了解用户画像能让产品经理逼格上升一个档次。
曾经有一位前辈看过我写的需求文档之后,给我提出了一些指导建议,其中有一条是:“可以在需求文档或者其他地方专门写一个部分——帮助运营做得更好”。
前辈的意思是产品在进行方案设计时候,也应该站在运营的角度去思考,如何能够帮助运营更好地开展工作或者提高效率。随着经验的积累和阅历的增长,发现不仅是站在运营的角度,还需要站在更多人的角度以及更高层次的视野去看待产品设计。
这里的提升就不得不清晰地了解用户画像,因为用户画像主要功能有四个:精准营销、广告投放、个性化推荐、辅助产品设计。在做产品设计的时候,如果能将前面三者都思考在内,虽然做出来的东西可能差别不大,但是境界和视野的差距可见一斑。
将用户画像运用得最好的一个产品我认为是虎扑,用户画像非常清晰:20-35岁的男性,以大学生和上班族为主,喜欢篮球,热爱运动,喜欢以实力论英雄。这样的用户被定义为“直男”。围绕“直男”做球鞋球衣广告投放、做吴亦凡/蔡徐坤相关内容营销、推荐评分投票帖等。虎扑的产品体验并不算好,但是围绕“直男”的运营做得在国内确实无出其右。
(知乎的用户画像-来自:https://zhuanlan.zhihu.com/p/59935630)
这也是产品经理的基本功,在此不做详细描述,但是提醒两点:
避免没有结论的功能点罗列:这是最常见的竞品分析误区,一定要有自己的分析结论,竞品在做什么——他们为什么这么做——我在做什么——我应该怎么做。
不要只关注页面结构和前端交互,多注意一些细节和隐藏功能。比如知乎的文章发布页,上传图**可以选择本地,还可以直接复制图**到编辑器中,而复制进去的图**是直接上传云端的,展示出来的就是知乎域下的图**,而虎扑的发帖页编辑器中复制图**是直接base64解析的原图地址,并未执行上传云端操作。
在体验老版本的时候经常**发现一些问题,记录下来,可能是一些功能bug,可能是一些细节的纰漏,甚至可能是一些提示文案等。但是仅自己体验后记录的需求远远不够,一定**存在很多遗漏的点,以下有三条经验可供参考:
需求池建立后开始做筛选工作,第一步先筛出来接受的需求,有些不合理的需求直接pass。在接受的需求池中,标注好每一条的优先级,以及解决方案,按照优先级制定重构版本需求范围和重构后迭代版本的迭代规划,而解决方案则落实到需求文档中。
下图为一个较大重构项目的原始需求池,未经筛选和标注优先级,小圆圈内的数字代表需求条数。
(某重构项目搜集的需求池)
重构目标不是将产品做出来,而是数据层面达到怎样的水平。重构目标需要具体可量化,而不是模糊的“提升用户体验”。
【反面示例】
改版目标:通过改版内容详情页,提升用户体验,给用户更好的阅读体验。
目标解读:首先不够具体,“提升用户体验”范围太大,其次没有量化,“更好的阅读体验”如何用数据衡量?
【正面示例】
改版目标:通过改版内容详情页,在详情页访问UV波动不**过5%的前提下,将PV/UV提升10%
目标解读:明确了改版后重点看的数据指标PV/UV,反应单个用户对于内容的沉浸程度。有约束条件:新版总体UV相较老版波动不**过5%。因此,针对这个目标设计内容详情页,可以考虑增加详情页里面的关联内容推荐、优化互动模式和通知提醒等,以达到新版让用户更多地访问到内容详情页。
总之,在一些目标导向的公司,有一个清晰的重构目标,有利于产品的设计,也容易出成果。如果能再增加一些行业数据或者竞品数据进行对标,那么在写绩效总结的时候绝对是一大亮点。
完成了以上调研文档的六个步骤,再来看需求文档其实就已经很清晰了。按照各自业务场景和调研文档的结论进行设计,在前面调研文档很清晰的情况下,需求文档的撰写应该是相对水到渠成的事情。可以在调研文档进行的同时将已经明确的改版方案细节列在需求文档中,不断扩充和积累之后,需求文档也相对趋于完善。
唯一要注意的一点:继承性产品设计,千万不能一次性大幅改变用户的操作习惯,否则后果自负。
“重构”项目产品经理的工作70%的精力在前期的梳理与定义,需求评审完成后就陆续跟进视觉稿、开发和测试,有不明确的地方相关方**再来找你确认,如果你文档够细,评审够清晰,这种不明确的询问就**相对较少。
在项目开发中,其实产品经理很多时候还**兼任项目经理的职责,一般而言总**出现一些临时需求和紧急需求需要占用开发资源,如果影响项目进展的话,这时候产品经理需要做出权衡,哪些是一定要在DDL前完成,哪些可以先灰度后再迭代加上,合理把控好整体的项目节奏。
在开发提测之后,我认为项目才开始进入到中期,中期主要讲究策略,如何让用户更自然和更乐意地接受新版的策略。
我个人总结的策略分为三部分:灰度策略、选择页策略、沟通策略。总体思路为灰度放量进到选择页,选择页筛出愿意体验新版的用户,对反馈强烈的用户拉群沟通。
灰度的目的是为了降低产品BUG风险,试验新版本和新交互的用户反馈,在数据层面上对新版功能、性能、稳定性、兼容性等指标进行评价,在灰度期间不断迭代优化新版,以达到较为完善的用户体验后全量上线。
灰度上线策略可以很简单,但是一般发布**比较复杂,产品经理可以在定义合适的灰度策略之后与开发沟通是否可行,若不可行可调整为怎样的策略。
最常见的两个灰度策略大类就是定量和定时间,定量为筛选一部分属性的用户进入新版本或者直接设置前x万的访问进到新版(注意爬虫的量),定时间则是简单粗暴地开放某个时间段访问全部进到新版。在新版的设计中需要增加“返回原版”的入口,支持用户手动回到旧版。
示例:
多数用户相对比较排斥改版/重构,**影响他们本身的使用习惯。选择页策略则是在灰度策略之后,给命中灰度策略的用户展示中间页,在中间页给用户说明改版的原因和改版功能点,让用户自主选择体验新版还是回到原版。
(虎扑M站在进行灰度时的中间页)
沟通是产品经理的强项技能之一,不仅对内对接开发设计测试等,对外对接用户也应该展现很强的沟通能力。
重构/改版一定**遇到用户侧的阻力,改版不当很可能用户就再也不见了。灰度上线后一定要做好用户反馈搜集,可以考虑在新版悬浮一个新版反馈的入口。灰度期间就是不断迭代的过程,将用户反馈的点列表记录,制定解决方案,排定优先级。
重构/改版后有人喷是好事儿,说明还有用户在用,对产品还有期待。真正可怕的是改版后用户一声不吭地直接走了。对于愿意反馈的用户可以考虑联系用户,拉群沟通,没有什么问题是沟通无法解决的,只要把用户真心放在第一位,尊重用户的反馈,改版阻力**大大减少。甚至可以考虑对一些忠实用户做认证标签,比如”热心XX“,这对于忠实用户是一个非常有效的激励。
中期灰度发布,逐步迭代完善后趋近于最终的产品形态,接着就可以全量替换上线了。其实到这里产品经理针对这个项目的核心工作基本上已经结束了,但是好产品永远是打磨出来的。
以全量上线的版本为x.0版本,持续关注数据和可优化的点,积攒一段时间后再进行迭代优化。这个时候的产品相对比较稳定,可以使用A/B测试、MVT测试等方法打磨产品。前端对于加载性能优化,后端对于响应速度升级等,都是在迭代过程中可以重点去提升的方面。
大多数情况随着项目结束,产品趋于稳定,同时又有新的项目接手,根本无暇顾及已经全量上线的新版本。
这无关痛痒,但是有心的产品**把自己做的每一个项目做到尽善尽美,将每一个可以优化的点记录下来,在后面当开发有空闲时间时安插需求,当开发看到一个用心做产品的伙伴,不**拒绝的。
作者:全导,微信公众号:零向度(lingxiangdu)
本文由 @全导 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自 Unsplash ,基于 CC0 协议